아래는 개인 프로젝트 인프라 구성도이며, 서비스 2개가 배포된 관계로 ECS에 task 2개, RDS도 2개로 구성돼 있다.
AWS 프리티어 크레딧 소진 후 5월 서버 비용으로 22만 원을 냈다(미친 환율). 비용 절감 해야지 마음먹고 귀찮아서 미뤄왔는데, 그 결과 이번 달도 14만 원 이상 태워야 한다는 나태지옥의 형벌을 받게 됐다.
구조는 유지하면서 인프라 비용을 줄이기 위해 했던 작업들을 기록하겠다.
[요약]
1. 오토스케일링으로 특정 시간에만 ECS task를 띄운다.
2. NAT 게이트웨이 역할을 하는 EC2 인스턴스를 생성한다.
3. 새로운 프리티어 계정을 생성하고 인프라를 이전한다.
4. 안 쓰는 리소스는 제거한다.
1. 오토스케일링으로 특정 시간에만 ECS task를 띄운다.
- 귀찮음: ⭐️
- 효과: ⭐️⭐️⭐️
구글 애널리틱스를 통해 트래픽 발생하는 시간대를 확인해 보니 평일 오전~오후에만 task를 띄워도 되겠다는 판단을 했다. 오토스케일링 설정 전/후 ECS 비용을 비교해 보니 50% 절감됐다.
1) ECS > Clusters > 클러스터 선택 > 서비스 선택 > Service auto scaling에서 Set the number of tasks 클릭
맨 처음에는 tasks 최대/최소 개수를 설정해야 한다. 최소 개수는 0, 최대 개수는 1로 설정하고 저장한다.
2) Scheduled actions 생성
task를 띄우고 내려야 하니 총 2개의 scheduled action이 필요하다. 특정 시간대에 동작해야 하므로 cron으로 설정하고, 선택한 타임존에 맞게 작성하자.
2. NAT 게이트웨이 역할을 하는 EC2 인스턴스를 생성한다.
- 귀찮음: ⭐️⭐️
- 효과: ⭐️⭐️⭐️
장애가 발생해도 나 혼자만 알 것 같은 작귀(^_<)～☆ 프로젝트보다 내 통장이 소중하므로 NAT 게이트웨이 EC2 인스턴스를 생성해 비용을 줄였다. 실무에서 이렇게 사용하는 경우는 거의 없을텐데, 높은 대역폭을 감당할 수 있고 장애 발생 시 자동 복구 된다는 점에서 AWS에서 관리해 주는 NAT Gateways(VPC 페이지에서 NAT 게이트웨이를 생성 가능)를 사용하는 게 안정적이기 때문이다.
개인 프로젝트에서 AWS 완전 관리 NAT 게이트웨이를 사용 안 해봐서 정확한 비용 비교는 못했지만 gemini가 대략적으로 계산을 해줬다.
1) EC2 인스턴스 생성
NAT 게이트웨이는 Private subnet의 트래픽을 받아서 외부 인터넷으로 던져주고 다시 받아와야 하는 역할을 하기 때문에 Public subnet에 위치시키고, 공인 IP(Public IP)를 갖도록 한다.
2) EC2 인스턴스의 Source/Destination Check 비활성화
EC2 인스턴스는 패킷을 주고받을 때 보안상의 목적으로 출발지/목적지 IP가 자신의 IP와 동일한지 체크한다. NAT 게이트웨이는 포워딩 역할을 해줘야 하므로 해당 설정을 비활성화 해야한다.
3) 인스턴스 내부에서 트래픽 통과되도록 설정
마지막으로 운영체제 레벨의 설정을 하면 된다. 리눅스는 기본적으로 보안을 위해 IP 포워딩이 비활성화되어 있는데, 라우터 역할을 하게끔 IP 포워딩을 활성화한다.
# 커널에서 IP 포워딩 활성화 (기본값: 0)
sudo sysctl -w net.ipv4.ip_forward=1
그리고 패킷의 출발지 주소를 EC2 인스턴스의 공인 IP(Public IP)로 변조한다.
만약 출발지 주소를 NAT 게이트웨이의 공인 IP(Public IP)로 변조하지 않으면 어떻게 될까? 출발지 주소는 Pirvate Subnet의 사설 IP(Private IP)로 지정되어 버리기 때문에, 외부에서는 어디서 패킷이 출발했는지 알 수 없어 응답을 돌려주지 못한다.
# 보통 외부로 나가는 네트워크 인터페이스인 eth0 지정
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
3. 새로운 프리티어 계정을 생성하고 인프라를 이전한다.
- 귀찮음: ⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️
- 효과: ⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️
프리티어 계정을 만들면 기본 크레딧 100달러 + 5개 체험(?)을 통해 받을 수 있는 크레딧 100달러 = 총 200달러의 크레딧을 받을 수 있다. 이 정도면 약 1.5개월은 인프라를 무료로 사용할 수 있으므로 꼭 해야 하는 작업이었다. 실제 서비스라면 데이터 마이그레이션과 서비스 중단을 최소화할 수 있는 방법을 고민해야 한다. 내 경우에는 거의 다 테스트 데이터이므로 데이터 마이그레이션은 패스했고, 도메인 네임서버 변경 작업은 task가 내려간 시간대에 진행했다. 작업을 하면서 이전에 인프라 구축할 때 겪어보지 못했던 이슈가 있었다.
이슈 1) 무지성 복붙의 폐해
task 기반으로 배포를 하는데 계속 실패했다. 좀 더 자세히 말하면 ECS task 정의할 때 컨테이너 환경변수에 Secrets Manager에 저장한 값을 사용했는데, 새 계정의 Secrets Manger ARN이 아니라 예전 계정의 Secrets Manger ARN을 잘못 기입한 것이다. 로그에 이유가 찍혀서 망정이지 아니었으면 삽질할 뻔했다.
이슈 2) 'ACM 인증서 - Route53 - 가비아' 관계에 대한 이해 부족
ACM 인증서 발급 상태가 Pending validation에서 멈췄다. 원인은 가비아 네임 서버에 등록했던 기존 계정의 Route53 NS 주소를 지우지 않고 새 계정의 Route53 NS 주소를 추가했기 때문이다.
[올바른 작업 순서]
1. Route53 host zone 생성
2. 가비아에 접속한 뒤, 네임 서버에 새 계정의 NS 주소 모두 입력 및 기존 계정의 Route53 NS 주소는 모두 제거
3. ACM에서 SSL/TLS 인증서 발급 (인증서 발급 상태: 검증 대기)
4. Route53에서 CNAME 타입 레코드 생성
5. 발급된 인증서를 ALB 443 리스너에 연결
6. Route53에서 A 타입 레코드 생성
[추가 설명]
- 2단계: 가비아에 접속한 뒤, 네임 서버에 새 계정의 NS 주소 모두 입력 및 기존 계정의 Route53 NS 주소는 모두 제거
- 도메인 주소에 접근하면 새 계정의 Route53의 네임 서버에 접속된다.
- 4단계: Route53에서 CNAME 타입 레코드 생성
- CNAME 타입 레코드 생성 시 3단계에서 발급했던 인증서의 CNAME name/value를 사용한다.
- ACM이 인증서 검증 시, 도메인 주소에 연결된 네임 서버가 있는 host zone에 인증서의 CNAME name/value와 일치하는 CNAME 레코드의 존재여부 확인
- 일치하는 CNAME 레코드가 있다면 검증 완료
4. 안 쓰는 리소스는 제거한다.
- 귀찮음: ⭐️
- 효과: ⭐️
프로젝트용 VPC를 만들어 사용하는 중이기 때문에 default VPC는 삭제했다. 효과는 미미하겠지만 몇 달러라도 아끼기 위하여...
귀찮음을 이기면 돈을 아낄 수 있습니다 여러분.
이 글을 보는 분들은 경제학적으로 합리적인 삶을 사시길.
