AWS를 이용해 글로벌 서비스를 구성을 나름대로 설계해보았다. 최적의 서비스 구성이라기 보다는 구성경험과 아이디어를 공유하는 목적으로 글을 남긴다.

(6) EC2 Instance
(6) EC2 Instance
(6) EC2 Instance
(6) EC2 Instance
(1) Route53 Geo location
(1) Route53 Geo location
HTTPS
HTTPS
(3) AWS Load Balancer
(3) AWS Load Balancer
(2) Seoul
(2) Seoul
SSL
SSL
(4) AWS Certification Manager
(4) AWS Certification Manager
(7) S3
(7) S3
Read
Read
Write
Write
HTTPS
HTTPS
EC2 Instance
EC2 Instance
EC2 Instance
EC2 Instance
HTTPS
HTTPS
AWS Load Balancer
AWS Load Balancer
(2) America
(2) America
SSL
SSL
AWS Certification Manager
AWS Certification Manager<br>
S3
S3
Read
Read
Write
Write
HTTPS
HTTPS
TCP
TCP
(9) Sync
(9) Sync
(10) Redis
(10) Redis
TCP
TCP
(11) Sync
(11) Sync
Redis
Redis
(5) EC2 Instance Group
(5) EC2 Instance Group
EC2 Instance Group
EC2 Instance Group
Browser
Browser
(8) RDS group
(8) RDS group
PM2 Deploy
PM2 Deploy
PM2 Deploy
PM2 Deploy


(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을 이용하기 위해서 AWSCertification Manager를 사용하였다. 별도로 구매한 인증서가 있다면 추가해서 사용할 수도 있지만, AWS를 이용하면 추가 비용없이 서비스 구성이 편하다는 장점이 있다.

특이한점은 S3SSL 인증서를 사용하기 위해서는 반드시 버지니아 북부 RegionCertification 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 인스턴스와 같은 RegionS3 버킷을 만들어 별도로 사용하도록 구성했고, 다른 Region에서 접속이 필요한 경우 서버캐시와 클라이언트 캐시를 모두 구성해서 사용했다.

S3에서 SSL를 이용하기 위해서는 CloudFront를 추가로 구성하여 인증서를 할당했고, DNS(Route53)에 해당 도메인에 CloudFront를 연결하는 작업할 하였다.

(8) RDS group

(9) RDS Sync (Replication)

Aurora를 사용했고 기본적으로 미국 지역을 마스터로 구성했다. 복제 기능을 활성화해서 다른 지역에서는 실시간으로 복제되게 했다.

Aurora이외에 MySQL 등을 사용할 수도 있지만 복제 기능의 구성에서 Aurora가 편했고 더 향상된 기능을 제공하고 있어서 이를 선택했다.

Read는 모든 RegionRDS에서 가능하게 했고, Write는 미국지역에서만 가능하기 했다. 따라서 이부분에서 조금 지연시간이 발생하는데 이부분은 추후 개선이 필요한 부분이라 생각한다.

Read, Write의 구분은 sequelize와 같은 ORM을 사용한다면 설정을 통해 쉽게 적용이 가능할 것이며, 별도 구현이라도 크게 복잡하지 않게 구현할 수 있다.

(10) Redis

(11) Redis Sync (Replication)

모든 정보를 데이터베이스에서 가져온다면 비효율적인 부분을 개선하고, API와 토큰 방식으로의 인증을 지원하기 위해서는 세션서버가 필요한데 Redis를 그 용도로 사용했다.

Redis도 해당 Region마다 따로 구성했고, 각 Replication을 구성하여 서로 복제될 수 있게 하였다.

Replication은 필수적인 부분이라고 생각하지않는데, 이유는 한 사용자가 동시에 여러 Region에 접속할 가능성이 거의 없기 때문이다. 하지만, 관리페이지 등에서 세션을 모니터링하는 등 관리하기 위해서는 Replication으로 구성할 필요가 있었다. 하지만 필요에 따라 이부분은 선택 적용할 수 있을 것이다.

Deploy

백엔드 배포는 PM2를 이용하여 ecosystem을 구성했고 deploy 명령을 이용하여 배포했다. 배포시에는 서비스가 중지될 수 있기에 Load Balancer에서 제외하는 작업이 필요했다. Load Balancer에서 제외는 배포 스크립트에 AWS CLIdelete-load-balancer를 추가하는 것으로 사용했다.

프론트엔드 배포는 S3에 업데이트 하는것으로 구성했고, 이 또한 AWS CLI 툴을 이용했다.