AWS 서버 아키텍처 구축하기

REST API 서버가 필요한 상황이 와서

AWS를 통해 서버를 구축하게 되었는데 결과적을 구축된 아키텍처 와

왜 이렇게 사용했는지에 대해 기록하려 한다.

만약 나처럼 AWS는 처음 다뤄보는 사람에게는 도움이 되길.

 

요구 사항

• 1. 부하 테스트를 통해 적절한 스펙의 서버(5분마다 약 1만 건의 API 요청)
• 2. 부하 테스트를 통해 적절한 적절한 RDS 구비
• 3. 서버와 RDS의 이중화
• 4. 서버가 다운되더라도 다시 올라올 수 있게 가용성 유지
• 5. HTTPS 통신
• 6. 도매인 구입

​

 

요구 사항에 맞추기

1.  EC2

AWS는 다양한 플랫폼을 제공하지만 그중 대표적인 EC2를 이용하여 서버를 구축했다.

여기서 문제는 EC2 가 너무 다양하게 제공하는 것인데 운영체제부터 스펙까지 너무 다양했고

운영체제는 확장성을 위해 Amazon Linux 2로 선택하였다.

스펙은 t3a large를 선택하였는데

더 낮은 스펙으로 구성후 부하 테스트를 해보니 4CPU 16G 정도의 스펙이 필요하다는 걸 알게 되었고

이중화로 2개의 EC2를 구비할 것이니 절반인 2CPU 8G로 2개를 선택하였다.

​

 

2. RDS

RDS는 마리아 DB를 선택하였고 4CPU, 16G를 준비하였다.

RDS 또한 부하 테스트를 통해 적절한 스펙을 찾은 것이고

EC2와 같이 이중화를 할 것인데 RDS는 스펙을 절반으로 줄이지 않았다.

이유는 이중화에서.

 

3. 이중화

이중화를 하기 위해 사용된 것이 AWS의 로드밸런서(ELB)인데

로드밸런서를 통해 트래픽을 분산 시 키 2대의 EC2를 적절히 사용할 수 있다.

RDS의 이중화는 RDS 생성 시 혹은 수정해서 다중 AZ 배포를 활성화할 수 있는데

기존에 사용하던 Master RDS가 다운되었을 때 Slave RDS가 Master로 승격되어

사용자가 따로 건드릴 필요 없이 가용성을 유지시켜준다.

4. 서버의 가용성

서버의 가용성을 유지하기 위해 오토스케 링을 사용하였다.

오토스케일링 이를 사용하여 서버의 CPU 혹은 메모리의 정해둔 임계치까지 도달하면

서버를 늘리거나 혹은 서버가 다운되면 다른 서버를 생성하는 등 여려 방식이 있지만

나는 하나의 서버가 다운되면 다시 서버를 올려 서버의 개수를 유지하도록 하였다.

5. HTTPS

HTTPS에서 필요한 인증서는 로드밸런서를 사용하게 되면 공짜로 받을 수 있다.

따라서 이중화를 하면 자동으로 해결.

​

 

6 도매인 구입

도매인은 AWS에서 구입이 가능하지만

가비아에서 따로 구입해서 사용하였다.

​

​

구성도

​

​

 

동작 방식 시나리오

1. 일반 상황

사용자는 구입해놓은 도매인을 통해 API를 요청한다.

해당 도매인은 Route 53에 의해 연결된 로드벨런서로 요청이 전달된다.

로드벨런서는 요청에 대해 적절히 분산시켜 2개의 EC2에게 전달하여 처리하게 한다.

​

2. EC2 다운

만약 Public1 존 에 있는 EC2가 다운된 경우 로드벨런서에 의해 각 EC2는 체크를 하고 있다가

트래픽을 Public2 존 에 있는 EC2에게 모두 전달하게 하여 서비스가 중단되지 않게 한다.

​

그 후 오토스케일링에 의해 Public1에 EC2가 생성되고 이를 확인한 로드벨런서는 다시 트래픽을 분산시킨다.

​

3. RDS 다운

다중 AZ 배포를 한 RDS 중 Master RDS가 다운되었을 때

대기하고 있던 Slave RDS가 Master로 승격되어 EC2의 처리 요청에 응답해 준다.

​

​

​