라떼군 이야기
아마존 웹 서비스(AWS)를 이용한 글로벌 서비스 인프라 설계
AWS를 이용해 글로벌 서비스를 구성을 나름대로 설계해보았다.
최적의 서비스 구성이라기 보다는 구성경험과 아이디어를 공유하는 목적으로 글을 남긴다.
(1) Route53 Geo location
기본적으로 DNS를 통한 지역기반 라우팅 설정으로 시작하였다.
모든 지역에 서버를 구성할수 없기에 예시에서는 아시아(서울)과 미국을 기본으로 구성하였고, 추가로 유럽등 지역으로 같은 구성을 추가할 수 있다.
아시아에서 접속하면 서울의 Load Balancer로 그 외 지역에서 접속하면 미국의 Load Balancer로 접속하게 설정할 수 있다.
(2) Seoul, America
Region의 그룹 경계를 표시하였다. 예시에서는 서울과 미국의 Region을 나타내고 있다.
미국은 여러 지역의 Region이 있는데 어느곳을 설정하든 상관없다.
새로운 Region으로 확장이 필요한 경우 이 경계의 구성을 복제하여 구성할 수 있다.
(3) AWS Load Balancer
서비스의 안정적인 구성을 위해 Load Balancer를 구성하였다.
Load Balancer이외의 구성방법으로 DNS를 이용해 트래픽을 분산하거나 Nginx를 앞에 구성하여 트래픽을 분산할 수 있다.
이렇게 구성할 경우 Single Point of Failure에 신경을 써야한다.
Load Balancer로 구성할 경우 EC2 인스턴스는 두개 이상으로 구성해야 하고,
상태를 체크 인터페이스를 따로 구현하고 임계값 등을 설정하여 Load Balancer가 해당 인스턴스를 제외하거나 포함하도록 설정하였다.
(4) AWS Certification Manager
SSL을 이용하기 위해서 AWS의 Certification Manager를 사용하였다.
별도로 구매한 인증서가 있다면 추가해서 사용할 수도 있지만, AWS를 이용하면 추가 비용없이 서비스 구성이 편하다는 장점이 있다.
특이한점은 S3에 SSL 인증서를 사용하기 위해서는 반드시 버지니아 북부 Region의 Certification Manager에서 인증서를 생성해야 가능하지만,
Load Balancer에 적용하기 위해서는 해당 Region에서 생성해야 했다.
(5) EC2 Instance Group
Load Balancer를 구성하기 위해서 2대 이상의 EC2 인스턴스로 구성했다. 2대 이하로 구성해야할 경우 Load Balancer를 사용하는 이점이 없다.
(6) EC2 Instance
Load Balancer를 구성하였기 때문에 처음 생각한 성능의 인스턴스 성능보다 한두단계 아래의 인스턴스로 구성할 수 있다.
추후 트래픽이 몰린다면 자동으로 성능을 확장하는 옵션을 사용하거나 비슷한 인스턴스를 추가할 수 있다.
(7) S3
통합된 글로벌 Region의 S3는 지원하지 않기 때문에 EC2 인스턴스와 같은 Region의 S3 버킷을 만들어 별도로 사용하도록 구성했고,
다른 Region에서 접속이 필요한 경우 서버캐시와 클라이언트 캐시를 모두 구성해서 사용했다.
S3에서 SSL를 이용하기 위해서는 CloudFront를 추가로 구성하여 인증서를 할당했고,
DNS(Route53)에 해당 도메인에 CloudFront를 연결하는 작업할 하였다.
(8) RDS group
(9) RDS Sync (Replication)
Aurora를 사용했고 기본적으로 미국 지역을 마스터로 구성했다. 복제 기능을 활성화해서 다른 지역에서는 실시간으로 복제되게 했다.
Aurora이외에 MySQL 등을 사용할 수도 있지만 복제 기능의 구성에서 Aurora가 편했고 더 향상된 기능을 제공하고 있어서 이를 선택했다.
Read는 모든 Region의 RDS에서 가능하게 했고, Write는 미국지역에서만 가능하기 했다. 따라서 이부분에서 조금 지연시간이 발생하는데 이부분은 추후 개선이 필요한 부분이라 생각한다.
Read, Write의 구분은 sequelize와 같은 ORM을 사용한다면 설정을 통해 쉽게 적용이 가능할 것이며, 별도 구현이라도 크게 복잡하지 않게 구현할 수 있다.
Cloudfront 사용
리전2에서 write을 하는 경우, cloudfront에 태워 리전1의 RDS에게 빠르게 write처리를 하실 수 있다. 리전2에서 읽기 처리를 하시는 경우에도, cloudfront를 이용하시면 사용자 기준 지연 시간이 가장 낮은 엣지로케이션으로 라우팅 되기때문에 더 빠르게 배포하실 수 있다.
Cloudfront란?
짧은 지연 시간과 빠른 전송 속도로 데이터, 동영상, 애플리케이션 및 API를 전 세계 고객에게 안전하게 전송하는 고속 콘텐츠 전송 네트워크(CDN) 서비스이다.
SQS 사용(비동기화)
리전2에서 SQS를 두신 후, 리전2에서 write을 하면 SQS에 메세지가 쌓이고 이를 RDS에 넣어준다. 현재 read에는 문제가 없다는 가정하에, 리전1 RDS에서 읽어오는 방법이 있을 수 있다.
Amazon SQS?
마이크로 서비스, 분산 시스템 및 서버리스 애플리케이션을 쉽게 분리하고 확장할 수 있도록 지원하는 완전관리형 대기열 서비스이다.
외부 software를 통해 동기화
리전2에 별개의 RDS를 설치한 후 외부 software를 통하여 동기화하는 방법이 있을 수 있다.
(10) Redis
(11) Redis Sync (Replication)
모든 정보를 데이터베이스에서 가져온다면 비효율적인 부분을 개선하고, API와 토큰 방식으로의 인증을 지원하기 위해서는 세션서버가 필요한데 Redis를 그 용도로 사용했다.
Redis도 해당 Region마다 따로 구성했고, 각 Replication을 구성하여 서로 복제될 수 있게 하였다.
Replication은 필수적인 부분이라고 생각하지않는데, 이유는 한 사용자가 동시에 여러 Region에 접속할 가능성이 거의 없기 때문이다.
하지만, 관리페이지 등에서 세션을 모니터링하는 등 관리하기 위해서는 Replication으로 구성할 필요가 있었다.
하지만 필요에 따라 이부분은 선택 적용할 수 있을 것이다.
Deploy
백엔드 배포는 PM2를 이용하여 ecosystem을 구성했고 deploy 명령을 이용하여 배포했다.
배포시에는 서비스가 중지될 수 있기에 Load Balancer에서 제외하는 작업이 필요했다.
Load Balancer에서 제외는 배포 스크립트에 AWS CLI의 delete-load-balancer를 추가하는 것으로 사용했다.
프론트엔드 배포는 S3에 업데이트 하는것으로 구성했고, 이 또한 AWS CLI 툴을 이용했다.