AWS monolithic APP 고도화

1. 개요

클라우드 컴퓨팅 수업에서 첫 번째 과제로, 서버와 DB가 하나의 인스턴스로 결합된 coffeesuppliers라는 monolithic 앱을 고가용성 측면에서 개선하는 과제를 받았다. 이번에는 이 monolithic 앱의 문제점을 분석해보고자 한다.

2. 발견한 문제점

2.1 stateful 서버

DB와 서버가 같은 인스턴스에서 실행되기 때문에, 하나의 인스턴스에서 작업을 진행하다 다른 인스턴스로 변경되면 모든 작업이 사라지게 된다. 즉 DB에 대한 의존도가 높아 stateless 설계를 적용할 수 없다.

또한 서버와 DB가 같은 컴퓨팅 자원을 공유하기 때문에 리소스 경합(Resource Contention)이 발생한다. 이로 인해 해당 자원에 문제가 생기더라도 어느 어플리케이션에 의해 발생한 문제인지 파악하기 어렵게 되고, 이러한 자원의 사용률은 의미없는 지표가 되어 버린다.

2.2 reliability(안전성)

현재 단일 AZ만 사용하고 있어 해당 AZ에 문제(데이터 센터 정전, 네트워크 장애)가 발생하면 모든 서비스가 중단되는 문제가 생긴다. 이러한 문제가 발생할 경우 이를 자동으로 해결하지 못하고 그대로 유지하게 된다. 즉 스스로 복구가 되지 않기 때문에 관리자가 추가 작업을 하지 않는한 해당 문제는 해결되지 않는다.

또한 인스턴스 내의 모든 요소가 서로에게 영향을 끼치게 된다. DB에서 문제가 발생하게 되면 해당 DB를 참조하는 프로그램도 문제가 생기게 되고 이로 인해 또 다른 프로그램에 문제가 생기게 된다.(Fault Tolerance 하지 못하다)

2.3 scalability(확장성)

현재 단일 AZ로만 요청을 처리하기 때문에 시시각각 변화하는 수요를 따라갈 수 없다. 평소 요청이 적을때는 쉽게 처리를 하더라도 요청트래픽이 몰리게 되면 가볍게는 응답시간이 늘어나거나 최악의 경우에는 해당 서비스가 중지될 수도 있다.

Monolithic App은 확장성에 많은 제약이 따른다. 현재와 같이 대규모 요청을 처리하기 위해 인스턴스를 확장할 경우 DB 또한 함께 확장되면서 문제를 초래한다. 즉 인스턴스 마다 DB에 저장되어 있는 내용이 달라지게 된다. 이는 앞서 말안 stateful의 문제와 연결된다.

2.4 보안

해당 어플리케이션은 public subnet 에 배포가 되어있다. Security Group과 NACL 설정이 되어 있지 않아, Public IP 주소만 알면 누구나 접근할 수 있다. 이는 최소 권한 원칙(Principal of Least Privilege) 을 위반하고 이로 인해 예상치 못한 외부 공격(DoS, DDoS)으로 부터 취약해진다.

또한 현재 통신은 public ip를 통해 진행되고, http 통신을 통해 진행되기 때문에 wireshark 와 같은 도구들을 사용해 충분히 해당 통신을 가로챌수 있다.

3. 해결방안

3.1 stateless

DB와 서버를 분리하여 모든 서버가 Master DB를 참조하게 함으로써, 인스턴스가 변경되더라도 작업을 이어갈 수 있는 stateless 서버로 설계한다.

3.2 reliability

기존 단일 AZ 배포에서 다중 AZ 배포를 진행한다. 또한 Route53을 활용해 다중 Region에 서버를 배포하여 지역별로 빠른 서비스 이용이 가능하도록 설계한다. 이로 인해 하나의 AZ에서 문제가 발생하더라도 즉각적으로 다른 AZ에게 요청을 분배하기 때문에 사용자들은 서비스를 문제 없이 이용할 수 있다. 또한 다중 region을 통해 배포를 함으로 각각 다른 지역에 있는 사용자더라도 가까운 서버로 요청을 보내 빠른 응답을 받을 수 있다.

ALB와 Auto Scaling은 상호 보완적이기 때문에, ALB가 특정 인스턴스의 문제를 감지하면 Auto Scaling이 해당 인스턴스를 신속히 복구해 문제를 해결할 수 있다.

3.3 scalibilty

Auto Scaling을 사용해 특정 기준에 따라 트래픽이 몰리면 인스턴스를 추가하여 높은 트래픽을 감당할 수 있게 설계한다. CloudWatch 를 사용해서 각각의 자원들을 모니터링해서 특정 기준값을 넘어가게 되면 scale-in, scale-out 을 진행해 요구되는 요청 수준에 적절한 자원을 컨트롤 한다.

3.4 보안

DB는 외부에 노출할 필요 없이 서버에서만 참조하도록 설정하고, 서버도 Public Subnet이 아닌 Private Subnet에 위치시키며 ALB를 통해 접근하게 하여 외부의 직접적인 접근을 차단하고 예상치 못한 공격 노출을 줄일 수 있다.

domain 을 구매한 후 route53에 연결해서 public ip가 아닌 실제 서비스와 동일하게 domain name 을 통해 접근하도록 수정한다.

또한 ACM(Amazon Certificate Manager)을 통해 해당 도메인의 인증서를 발급하여 HTTPS 통신을 적용함으로써 보안을 강화한다.