[개발] AWS 아키텍처 구성하기

AWS 아키텍처를 구성할 때 어떻게 구성하면 좋을지 그리고 그게 왜 좋은지 단계별로 알아보자. best practice인지는 모르겠지만 그래도 좋은 아키텍처라고 생각했다.

 

1단계

EC2에 배포하기

가장 생각하기 쉬운 구성이다. EC2에 우리의 애플리케이션을 띄운 후 Route 53으로 도메인을 걸어주는 방식이다. 가장 간단한만큼 문제점도 많다. 일단 오토스케일링이 안된다. 오토스케일링을 위해 EC2를 띄우면 새로운 도메인을 할당해야 하므로 사용하기 힘들다. 오토스케일링이 안되면 대규모 트래픽을 감당하기 힘들기 때문에 어느정도 사용량이 많아지면 상황이 많이 안좋아진다.

 

2단계

리버스 프록시 사용하기

이제 오토스케일링을 하더라도 도메인은 리버스프록시에만 할당됐기 때문에 문제는 해결됐다. 이제 오토스케일링도 가능하고 로드밸런싱도 가능하다. 하지만 리버스 프록시 용도로만 EC2를 사용하려고 보니 비용에 비해 역할이 적은 것 같다.

 

3단계

로드밸런서 사용하기

이제 좀 가볍게 로드밸런싱이랑 오토스케일링이 가능하게 됐다. 이정도만 하더라도 쓸만한 아키텍처가 된다. 소규모 프로젝트라면 이정도면 충분하다. 하지만 로드밸런서의 단점은 변경에 약하다는 점이다. 극단적으로 로드밸런서의 이름만 바꾸려고 해도 삭제하고 다시 만들어야하는 상황이 생긴다. 금방 만들 수 있겠지만 그동안에 가용성 이슈가 생긴다. 또한 해당 로드밸런서와 다른 프로젝트와 도메인이 다르기 때문에 쿠키를 넣을 수 없는 등의 문제가 생긴다.

 

4단계

API게이트웨이 사용하기

API게이트웨이는 여러 로드밸런서에 사용할 수 있고 로드밸런서를 바꾸는 동안 api gateway가 다른 로드밸런서를 바라보게 하면 된다. (이렇게 하면 바꿀 필요 없이 그냥 삭제하면 된다.) 또한 도메인이 api gateway에 들어가기 때문에 다른 프로젝트와 같은 도메인을 사용할 수 있고 서브도메인으로 구분할 수 있다. 이제 충분히 좋은 아키텍처인 것 같다.

 

5단계

쿠버네티스 사용하기

쿠버네티스를 사용하여 애플리케이션을 관리하게함으로써 관리 포인트를 줄인다. 쿠버네티스에 로드밸런싱 기능과 오토스케일링 기능도 제공하니 로드밸런서를 대체하면 될 것이다.

 

6단계

방화벽 적용하기

이쯤되면 충분히 큰 프로젝트를 다루고 있는 정도일 것이다. 그렇다면 외부의 DDOS나 해킹시도가 빈번하게 발생할 것이다. 이를 방지하기 위해 API Gateway에 접근하기 전 WAF를 구성하여 외부의 공격을 막으면 된다.

 

이 외에 CloudWatch같은 모니터링 툴과 추가적인 서비스를 사용하여 구성하면 더 좋은 아키텍처를 구성할 수 있을 것이다.