특정 시간대에 트래픽이 몰리는 서비스 특성상 '빠르고 간단한 오케스트레이션'을 주요 요구 사항으로 프로젝트를 진행했습니다.
기존의 인포크링크 서버는 AWS Elastic Beanstalk로 구성되어 있었습니다. Beanstalk는 사용이 간단하다는 장점이 있으나 오케스트레이션이 느리다는 단점이 있었습니다.
인포크링크 웹 스택은 이미 ECS를 사용 중이었기에 서버 스택 또한 ECS로의 이전을 통해 편리하고 포괄적인 관리가 가능하도록 ECS를 선택했습니다. ECS를 활용하면 편리한 컨테이너의 관리, 태스크 및 서비스 관리, 로드 밸런싱, 오토 스케일링 등 안정적인 서비스의 제공이 가능합니다.
Django API 서버를 구동하는 runserver 커맨드의 보안, 성능상 이슈로 인해 nginx를 함께 구성했습니다. nginx는 django 컨테이너 앞단에 추가되어 리버스 프록시로서의 역할을 하며, 클라이언트의 요청을 분산시켜주고 많은 트래픽을 동시에 처리할 수 있게 해줍니다.
CPU 사용륭이 예측 가능하고 안정적인 시스템에서 더 높은 효율을 발휘하는 EC2와 달리, Fargate는 유동적인 workload가 나타나는 환경에서 더 높은 효율을 발휘합니다. 스케일링의 빈도가 잦고 평소 상대적으로 낮은 workload가 부여되는 서비스 특성상 Fargate를 선택했습니다.
ECS 서비스 앞단에서 작동하는 로드 밸런서만을 통해 ECS에 접속할 수 있도록 보안 설정을 진행했습니다. ECS 서비스에는 로드 밸런서와 ElasticCache와의 통신을 위한 포트만 열려있느 보안 그룹을 설정하고, 프라이빗 서브넷에서 실행되도록 설정했습니다. 추가로, 외부 인터넷으로부터의 접속을 차단한 뒤, 특정 보안 그룹에서의 접속만을 허용해 안전한 서버 아키텍처를 구성했습니다.
ECS를 활용해 서버를 배포한 뒤 실제 서비스 환경과 비슷한 부하를 주어가며 스트레스 테스트를 진행했습니다. 이 과정에서 nginx, django 컨테이너의 CPU 할당량을 조젏해 최적의 성능을 발휘할 수 있도록 했습니다.
ECS의 태스크 및 서비스를 조절하고 배포하는 복잡한 과정을 코드를 통해 간단하게 관리할 수 있도록 AWS CDK를 활용해 배포했습니다. 이를 통해 개발자 누구나 서버 이미지를 관리하고 배포할 수 있게 됩니다.