[AWS] Elastic Beanstalk 내부 로직, 구성, 네트워크 연결 정리
그동안 프로젝트를 배포하면서 elastic beanstalk(엘라스틱빈스톡)를 애용해왔는데, 이번에 terraform으로 인프라 생성 과정을 코드화하려고 한다. 공부하다보니 내가 elastic beanstalk을 완벽하게 이해하지 못한 부분이나 놓치고 있는 setting variable들이 있어서 이번 기회에 정리하면서 공부해보고자 한다.
Elastic Beanstalk이란?
AWS에서는 아래와 같이 설명하고 있다.
'AWS Elastic Beanstalk는 Java, .NET, PHP, Node.js, Python, Ruby, Go 및 Docker를 사용하여 개발된 웹 애플리케이션 및 서비스를 Apache, Nginx, Passenger 및 IIS와 같은 친숙한 서버에서 손쉽게 배포하고 확장할 수 있는 서비스입니다.'
간단히 말하면 배포, 관리, 상태 모니터링 등을 쉽게 도와주는 PaaS 서비스인 것이다.
기존에 EC2에서 배포를 위해서 필요한 프로그램(자바의 경우 JDK, JS의 경우 node 등)의 설치 과정을 자동화해주고, Auto scaling, Load Balancing, Proxy 서버(nginx, apache) 구성 등 네트워크 구성에 대한 부분도 자동으로 해준다.
Elastic Beanstalk 네트워크 구성
위 그림에서 Route53을 제외하고는 모두 Elastic Beanstalk(이하 EB)에 의해 자동 생성된다.
Client가 도메인으로 요청하게 되면, Route53(DNS Service)에서 로드밸런서 주소를 가리키고 있다.
1. 로드밸런서는 서버에 가해지는 트래픽을 분산시켜주는 서비스로 EB로 국한 했을 때 실질적으로 가장 앞쪽에서 Client의 요청을 listen하고 있다.(기본적으로 80포트를 listen하는데, https를 listen해주고 싶다면 ssl인증서 등록 등 추가설정이 필요하다)
2. 이때 오토스케일링 설정을 해뒀다면 load balancer는 Auto Scaling Group(이하 ASG)를 바라보고 있고, ASG에서 정해진 알고리즘에 따라 EC2에 요청을 전달하게 됩니다.
2-1. 이때 Load Balancer는 하나의 VPC(virtual private cload, 가상 네트워크)안에 할당되어있고, ASG에서 각 서버는 다른 subnets에 할당할 수도 있습니다.(별다른 설정을 하지 않으면 하나의 subnets을 대상으로 하는듯합니다)
3. EC2로 들어간 client의 요청은 Proxy 서버인 nginx를 향하는데, 이때 EC2는 '80포트로 들어오는 로드밸런서의 요청' 이외에 다른 요청을 거부하고 있습니다.
4. nginx에서는 드디어 우리가 배포한 application으로 요청을 보내주는데, 이때 node.js는 8081과 같이 별다른 포트 지정이 없다면 default port가 정해져있기 때문에 유의해야 합니다. (만약 Docker로 배포했다면 docker 내부적으로 또 port의 변동이 있을 수도 있습니다.)
이렇게 보면 굉장히 네트워크 구성이 복잡합니다. 하지만 EB는 하나의 콘솔 설정만으로도 이것들을 한번에 설정할 수 있습니다.
Elastic Beanstalk에서 배포
EB 콘솔에서는 압축파일을 업로드하는 방식으로 프로젝트 배포를 손쉽게 할 수 있습니다. node의 경우 자동으로 npm install 등을 지원해서 프로젝트 환경설정까지 해주고, npm start를 실행하여 프로젝트를 무중단 배포해주게 됩니다.
또한 auto scaling의 이유로 인스턴스 여러개에 배포를 해야할 일이 생겼을 때에도, 배포 방식 등을 배포자가 선택하여 안정감있는 배포를 지원합니다.
이외에도 주기적인 ping check, 서버 상태 모니터링, 서버 로그 수집 등 서비스 관리에 공수를 줄여주기에 필자는 아주 애용하는 서비스입니다. (사실 배포하는 프로젝트가 대부분 토이프로젝트에 국한되기에 오토스케일링보다도 편한 배포와 서버상태 모니터링에 매력이 느껴졌던 것 같습니다)
다음 포스팅에서 EB 세팅을 terraform으로 하는 방법을 연구해오겠습니다.