AWS monolithic APP 고도화(2)
1. 개요
이번 글에서는 저번에 만들어 두었던 stateless한 application을 ALB와 Auto Scale을 통해서 대용량 요청에 대해 scability 하게 처리할수 있도록 구조를 변경한다.
2. 세팅
2.1 대상 그룹
대상 그룹은 ALB를 통해 관리되는 대상으로 해당 그룹 내에서 트래픽을 분배해 준다. 인스턴스 유형을 선택하고 앞서 생성해 준 VPC를 연결해 준다. 이때 상태검사 경로로는 기본 "/"를 선택하게 되면 코드 내부에서 추가적인 외부 api를 호출하기 때문에 응답이 느려지거나 외부 api에서 주기적인 연결로 인해 연결을 차단할 때 unhealty 판정을 받을 수 있다. 이를 해결하기 위해 "/suppliers" 주소로 상태 검사를 요청한다.
대상 등록하는 과정은 Auto Scale이 처리하기 때문에 아무것도 없는 상태로 생성한다.
2.2 Load Balancer
Auto Scale에 의해 증감하는 인스턴스들에게 트래픽을 분배하는 역할을 수행한다. 나중에 인증서를 통해 https 통신으로 변경할 것이기 때문에 Application Load Balancer를 선택한다.
ALB를 통해 private subnet에 접근하기 위해서는 ALB가 public subnet에서 동작해야된다. ALB도 동일하게 고가용성을 확보하기 위해 2개 이상의 AZ에 매핑한다.
리스너 및 라우팅에서 일단은 80 포트만 허용하고 앞서 생성한 대상 그룹을 매핑한다. 다음 글에서 ACM을 통해 인증서를 발급받고 https 설정 과정에 대해 다루겠다. 보안 그룹 또한 앞서 생성했던 80, 443 포트에 대해 허용하는 보안 그룹을 설정해 준다.
2.3 Auto Scaling 그룹
앞의 글에서 생성해 주었던 private Template을 사용한다. 또한 앞서 생성했던 인스턴스가 실행될 VPC, private subnet을 지정해 준다
앞서 만들었던 Load Balancer에 연결하고 대상 그룹도 연결해 준다. 대상의 기본, 최소, 최대 크기는 서비스에 맞게 설정해 주면 된다. 크기 조정 정책으로는 CPU availity를 사용해서 사용률이 50%를 넘어가게 되면 증가시키도록 한다. 이때 단계 조정 정책 방식이란 규모 조정 정책이 존재하는데 해당 방식을 사용해 인스턴스 증가량을 더욱 세밀하게 조절할 수 있다.
또한 인스턴스 유지 관리 정책으로는 무중단 서비스를 구현하기 위해서 종료 전 시작을 통해서 인스턴스 업데이트나, 재시작 시 새 인스턴스가 시작될 때까지 기존의 서비스를 유지하는 정책을 선택했다.
3. 결과
대상 그룹에 들어가 보게 되면 따로 인스턴스를 추가하지 않았음에도 설정했던 기본 개수만큼 인스턴스가 추가된 것을 알 수 있다. 또한 ALB DNS를 통해 서버에 접속해 보게 되면 요청 시마다 다른 서버로 접속이 되는 것을 보아 ALB와 Auto Scale이 정상적으로 작동하는 것을 볼 수 있다.
 |
 |
3.1 다음 글
다음 글은 이제 마무리로 route53을 통해 동일한 설정을 가지고 다른 region으로도 트래픽을 분배할 것이다. 또한 도메인 구매해서 실제 서비스처럼 public ip가 아닌 도메인을 통해 서비스에 접근할 수 있도록 설정한다. 그리고 해당 도메인을 통해 ACM에서 인증서를 발급받아 https 통신을 구축한다.