이전 두 포스팅인 플라워로드 시스템 아키텍처-개요편과 플라워로드 시스템 아키텍처-서비스 Flow편에서 대략적인 플라워로드 시스템의 구성을 살펴 봤고, 이번 포스팅에서는 플라워로드 시스템에서 사용중인 AWS services들이 어떻게 구성되어 있는지를 살펴볼 예정입니다.
<aside> 💡 해당 architecture는 2018년 후반에 설계를 시작해서 구성된 내용으로 Lambda를 이용한 MSA를 target로 설계 되었습니다. 현재는 AWS에 너무 의존성이 높아서 K8S(Kubernetes)를 이용한 MSA를 설계 중에 있습니다.
</aside>
너무 많은 service들을 사용중이기 때문에 여기에 일일이 모두 나열하기는 조금 힘든면이 있습니다.(글을 쓰고 있는 현재 모두 기억할 수 있을지도 모르겠네요...)
저희는 모든 서비스를 AWS에서 운영을 하고 있으며, computing 이나 DB, log monitoring등 외에도 source code repository도 AWS CodeCommit를 사용하며, CI/CD를 위한 tool들도 AWS CodePipiLine, AWS CodeBuild, AWS CodeDeploy를 사용하고 있습니다.
이것에 그치지 않고 개발시 VPC의 private한 환경의 접근을 위해서 (ex. AWS Aurora Serverless DB) AWS Cloud9도 사용하고 있으며, 저희 Domain의 routing을 위한 AWS Route53도 사용하고 있습니다.
물론 Data Analysis와 ML을 위한 AWS Athena, AWS SageMaker, AWS EMR, QuickSight등도 사용하고 있습니다.
해당 포스팅에서는 Data Analysis나 ML, build 환경같은 외적인 내용은 제외하고 저희 플라워로드의 서비스를 위한 AWS Service 구성만을 살펴보겠습니다.
대략적인 AWS Service들의 구성을 나열한 Diagram입니다. 하나의 Diagram에 모든 내용을 포함하기에는 너무 복잡하고 여기에서 굳이 다루지 않아도 될 내용들이 있었기 때문에 생략한 내용도 있습니다.(ex. security group, E-IP, NAT, Internet GW등)
위의 Architecture Diagram은 크게 세부분으로 나뉘어서 볼수 있습니다. 스쿠터와의 communication 및 스쿠터의 데이터를 처리/저장을 담당하는 부분, 사용자 및 관리자 앱의 요청을 처리/데이터 저장을 담당하는 부분, 마지막으로 source code repository, CI/CD 부분으로 나뉘어 볼수 있습니다.
앞선 포스팅에서 설명한것 처럼 스쿠터의 종류에 따라 TCP/IP socket 통신을 이용해서 연결 유지 및 데이터 송수신을 하고 있습니다. 따라서, 이를 위한 server 가 필요로 했습니다.
크게 고민하지 않고 docker image로 만들 작은 server program을 NodeJS로 구현을 하고 load balance, scale up/out 의 편의를 위해서 Network Load Balancer + AWS ECS + Fargate 를 이용하기로 했습니다. 이 당시 AWS에서 K8S를 서비스 하지 않았기 때문에 추후 K8S로 옮겨가는 것을 고려해서 docker image로 만들어서 운영을하게 되었습니다.
Network의 구성은 간략하게 Public Subnet에서 외부 포트를 하나 열어두고 Network Load Balancer를 이용해서 Private Subnet 내부의 ECS에 분산 접속 해주는 방식을 사용합니다. 당연히 하나의 Fargate가 임계점에 다다르면 ECS가 scale out방식으로 또 다른 Fargate가 생성 및 launch되고 Network Load Balancer 가 적당히 traffic을 분산해주게 됩니다.