최근 ECS를 도입하면서 Rolling Deploy 를 적용했다. 이전에는 EC2인스턴스마다 방문하면서 배포를 했다면 이제는 새로운 Fargate기반 태스크가 생성되면서 기존 태스크는 없애는 방식으로 배포된다.
테스트를 진행하다보니 ALB Target Group에 등록된 아이템이 Draining에 걸리는 시간이 긴 것이 눈에 들어왔다. 기본값으로 이 값은 300초가 주어지기 때문에 트래픽이 많지 않거나 커넥션을 오래 유지할 필요가 없다면 이 시간만큼 Fargate인스턴스를 더 사용하는 셈이다.
타겟그룹의 Draining에 걸리는 시간은 “Deregistration delay”항목에서 수정할 수 있다.
참고: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#deregistration-delay
오랜만에 Aurora MySQL의 최대 접속수를 다시 지정했다. 개발용도의 데이터베이스는 사용량은 작지만 여러 프로젝트들이 connection pool 을 생성하니 기본 정의값보다 올려서 사용하는 경우가 종종있다. max_connections를 다시 지정한 파라미터 그룹으로 교체하면 된다. 이건 TIL이라 할 것도 없다.
하지만 글로 남기는건 10분이면 될 일을 1시간이나 헤맸기 때문.
변경된 수치는 다음쿼리로 확인가능하다.
mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
| 300 |
+-------------------+
1 row in set (0.00 sec)
AWS의 Private Subnet에 있는 인스턴스가 외부와 통신하려면 NAT를 활용해야한다. 그렇다면 NAT인스턴스를 만들어 사용할지, NAT 게이트웨이(Gateway, 이하 GW)를 사용할지 결정해야 한다.
VPC의 NAT Gateway 가격은 서울리전에서 $0.059 이다. 1달이 월 720시간이라면 Multiple AZ를 고려해 2개를 설치하면 월 $84.96, 약 10만원의 추가부담이 생긴다.
NAT Instance로 구성한다면 EC2 1년 선결제 없는 경우의 예약 인스턴스 사용시 c5.large, m5.large, t3.large 정도의 가격이다.
NAT GW는 기본 5Gbps의 대역폭을 지원하고 45Gbps까지 확장가능하다. 또 관리 소요가 줄어들기 때문에 AWS에서는 GW를 활용할 것을 권고하고 있다. 하지만 이런 수치는 트래픽에 따라 달라질 것이라 우리 회사의 경우 가격 부담없이 사용할 수 있을지 확인해보고 싶었다. 특히 t3.nano를 적용했을 때의 성능이 활용할만한지 궁금했다. AWS홈페이지에 나와있듯 t3.nano의 네트워크 대역폭은 최대 5Gbps 이다.
참고:
AWS, NAT 인스턴스 및 NAT 게이트웨이 비교
AWS, Amazon EC2 인스턴스 유형
먼저 Public 서브넷의 호스트를 Private으로 옮긴 후 t3.nano 로 만든 NAT인스턴스를 각 AZ의 Public Subnet에 설치했다. 인스턴스의 AMI는 AWS 매뉴얼(참고: AWS, NAT인스턴스)에 설명된 대로 AWS에서 제공하는 AMI를 사용했다.
아래 수치들은 백엔드끼리 연결된 타사와의 트래픽이다(서비스 트래픽은 로드밸런서에 연결되어있다). 제휴사와의 트래픽 중 HTTPS 단일 호스트에 200 OK 로 제한한 결과다.
결론부터 말하자면 현재 우리 트래픽으로는 t3.nano NAT인스턴스 사용시에도 큰 차이가 나지 않았다. 특히 T3계열 네트워크 속도가 “최대5Gbps” 이고 경험상 때때로 네트워크가 지연되는 경우도 자주 봤지만(소위 튕기는 현상), 이번에는 편차면에서도 크게 차이가 없음을 확인할 수 있었다.
참고)
AWS의 T계열은 CPU사용률을 고려해야한다. 하지만 현재로써는 설치된 NAT인스턴스의 CPU사용률이 높지 않아 만약 더 저렴한 인스턴스 타입이 나온다면 전환하는 것도 가능할 것으로 보인다.
마지막으로 비용은 t3.nano, 표준 1년 선결제 예약인스턴스, GP 8GB EBS 를 사용해 인스턴스 대당 월 $3.5가량, 2대에 $7로 NAT GW의 $84.96에 비해 크게 비용을 아껴 구성할 수 있었다.
트래픽의 크기에 따라 다르겠으나 t3.nano 로 현재 트래픽에 대응되는 것을 확인했다. 비용면에서도 훨씬 저렴하기 때문에 소규모 스타트업이라면 적용해 보는 것을 추천한다.
AWS 의 VPC는 리전 내에 위치하고 서브넷은 AZ내에 위치한다.
한 VPC에 AZ에 대해 여러 서브넷을 둬서 고가용성(HA)를 확보할 수 있다.
서브넷의 통신 방법은 VPC의 라우팅 규칙(Route Tables)을 따른다.
라우팅 규칙은 아이피 대역(CIDR)에 따라 타깃을 설정할 수 있고, 서브넷에 붙이는(associate) 방식으로 서브넷의 통신 방법을 설정할 수 있다. 서브넷과 라우팅 규칙은 1:n 관계이다. 각 서브넷은 한개의 라우팅 규칙을 붙일 수 있고 한 라우팅 규칙은 여러 서브넷에 적용될 수 있다.
이 라우팅 규칙을 통해 VPC Peering이나 Public Subnet, Private Subnet의 설정을 할 수 있게 된다.
IGW는 VPC와 인터넷을 이어주는 가상 게이트웨이이다.
라우팅 규칙을 통해 IGW에 연결된 서브넷은 Public Subnet, 그렇지 않은 서브넷은 Private Subnet이라 한다.
Private Subnet 내의 인스턴스들은 Public IP를 갖지 않고 인터넷에 직접 노출되어있지 않다. Private Subnet에서 인터넷에 아이피가 노출되지 않으면서 인터넷에 접속하려면 NAT를 사용해야 한다.