[CSAPI] AWS 아키텍처 설계

기존 아키텍처

1. 링크로 접속하면 api를 사용할 수 있다. 그리고 잘 동작한다. 이미지 한 장을 처리하는데 16~18초 정도가 필요하다.
2. 비동기 task 큐를 사용해서 이미지가 처리되는 동안 무중단으로 잘 동작한다.
3. 하지만 이미지 처리 시간 및 트래픽이 많아졌을 경우 확장하기가 매우 힘들다. 이유는 다음과 같다.
   1. 업로드된 이미지, 처리된 이미지가 서버에 직접 저장된다. 서버가 2대로 확장되었을 때, 1번 서버의 이미지를 2번 서버가 가지고 있지 않는다면 문제가된다. 그래서 이미지를 공유할 수 있는 방법이 필요하다.
   2. 모든 서비스가 public ip를 갖는 server에 올라가다 보니 보안상으로도 좋지 않다.
   3. 트래픽에 따라 서비스가 확장되어야 하는데, server 자체를 확장하면 부하가 심하지 않은 서비스도 같이 확장된다. 물론 Docker가 잘 처리해 주겠지만... 이게 MSA가 맞나 싶기도 하다. = MSA 관점에서의 확장성이 좋지 않다고 판단했다.

 

새로운 아키텍처 설계 구성도

모든 컴포넌트는 Seoul Region에 생성된다. 그리고 확장되기 쉽도록 구성했다. 다만 메세지 브로커인 RabbitMQ와 사용자 정보와 이미지에 대한 정보를 저장하는 MariaDB의 확장 및 이중화는 고려하지 않았다. 그거까지 하기엔 한 달 AWS 사용 비용이 너무 부담된다. 먼저 구성한대로 동작을 잘 하면, RabbitMQ 대신 Amazon SQS 로 대체할 생각이다. Load Balancer를 설정하려면 subnet을 여러 개 두어야 하는데, 그림으로 나타내기가 어려워서 그림상으로는 생략했다.

• 외부에서 접근 가능한 Server는 Private subnet의 인스턴스에 직접 접근하는 용도의 Bastion 뿐이다.
• Load Balancer는 Nginx, Django 그룹에만 연결되어 부하 분산을 수행한다.
• 트래픽에 따라 Auto Scaling 되는 서비스는 Nginx와 Django, Celery다.
• RabbitMQ는 Django로부터 이미지 처리 요청을 Celery Worker로 전달한다.
• 이미지 파일은 S3에 저장되며 serving은 CND 서비스인 CloudFront가 사용된다.
  1. S3로 이미지를 업로드하는 Django와 Celery Worker는 Endpoints를 통해 S3에 접근한다.
  2. Django는 User로부터 받은 이미지를 그대로 S3에 업로드한다.
  3. Celery Worker는 User로부터 받은 이미지를 처리한 결과 이미지를 S3에 업로드한다.
• ECR은 개발한 서비스들의 Docker Image가 저장되는 곳이며, 두 개의 Auto Scaling group에서 접근할 때도 Endpoints를 이용한다.