[AWS, Github Action] Elastic Beanstalk에 SpringBoot 배포하기(1) - EB 기본 세팅

들어가기 전에

Elastic Beanstalk을 통해 Springboot CI를 진행하기 위해 Elastic Beanstalk 기본 설정을 진행하였습니다. 다음 포스팅에서는 Github Action을 통해 Elastic Beanstalk에 실 어플리케이션을 배포해볼 것입니다.

다음 포스팅

• [AWS, Github Action] Elastic Beanstalk에 SpringBoot 배포하기(2) - IAM 인증키 Github Action에서 사용하여 배포
• [AWS, Github Action] Elastic Beanstalk에 SpringBoot 배포하기(3) - EB에 RDS 사용하여 환경속성 통해 application.yml 주입받기

Elastic Beanstalk 어플리케이션 및 환경 기본 세팅하기

먼저, AWS Console에 접근하여 Beanstalk을 검색하고 Create Application을 클릭합니다.

AWS console에서 Beanstalk 검색 및 Create Application 클릭

Elastic Beanstalk Application 생성은 하기와 같이 진행하면 됩니다. 

Elastic beanstalk Application 생성

위와 같이 Application 생성 항목을 채운 후, 추가 옵션 구성을 클릭하면 자동 생성된 환경에 대한 구성을 변경할 수 있습니다.

추가 옵션 구성을 통한 환경 설정

• 사전 설정에서 단일 인스턴스가 아닌 사용자 지정 구성을 선택한 이유는, 단일 인스턴스 옵션으로 설정 시 로드 밸런서를 설정할 수 없어 Beanstalk으로 무중단 배포가 불가하기 때문입니다.
• 인스턴스의 보안 그룹 추가의 경우 자신의 PC에서 SSH와 HTTP(S)를 허용하는 보안 그룹이므로, 해당하는 보안 그룹이 없다면 하기에 작성한 보안그룹 설정을 읽고 생성한 보안그룹을 넣어주시면 됩니다.
• 용량에서 Auto Scaling 그룹의 최대 인스턴스를 1개로 지정한 이유는, dev이기 때문에 트래픽이 늘어날 확률이 없기 때문입니다. 만약 운영 환경이고, 돈이 충분하다면 auto scaling의 최대 인스턴스를 늘려볼 수 있습니다.
• 배포 방식을 추가 배치를 사용한 롤링으로 지정했습니다. 추가 배치를 사용한 롤링이 무엇인지는 하단에 설명 작성해두었습니다.
  • 간단히 말하자면, 현재 인스턴스는 1개이며, 추가 배치를 사용한 롤링을 이용하면 배포 시 신규 인스턴스에 신규 버전을 올리고 해당 인스턴스가 문제가 없으면 기존 인스턴스를 죽이는 것입니다.
  • 인스턴스가 1개이고, 배치 크기가 100%이기 때문에 위와 같이 설명했습니다.
• EC2 키 페어의 경우 EC2를 한 번도 만들어 본적이 없다면 따로 생성이 되어 있지 않습니다. 이 역시 하기에 SSH 접근을 위한 PEM.KEY 수동 생성하기 항목으로 작성해두었으니 해당 내용을 기반으로 생성하여 넣어주시면 됩니다.
• 로드 밸런서 유형은 기존에는 ELB로 불리던 Classic Load Balancer를 많이 사용했지만, 요즘은 다양한 라우팅 기능을 지원하는 Application Load Balancer(ALB)를 많이 사용하므로, ALB로 설정했습니다.

위와 같이 구성이 완료되면 아래와 같은 구성으로 생성할 수 있으며, 앱 생성을 눌러 Elastic Beanstalk Application 및 Environment를 생성합니다.

추가 옵션 구성 완료 후 앱 생성

생성이 완료된 후 Elastic Beanstalk > 환경에 들어가면 신규로 만든 환경이 뜨고 해당 환경을 클릭하면 해당 환경이 올라간 어플리케이션을 확인할 수 있습니다.

하나의 어플리케이션 당 여러 환경을 가질 수 있기 때문에 환경은 어플리케이션 하위에 있다고 보면 됩니다.

• 예를 들어, 어플리케이션이 뜨는 환경이 prod와 dev가 있다면 각각 다른 환경으로 구성하면 됩니다.

필자의 경우, 처음 어플리케이션 생성 시 함께 생성된 환경의 이름과 도메인이 마음에 들지 않아 하기와 같이 다시 환경을 세팅하여 진행하였습니다. 이름을 제외하고는 동일한 환경이니 순차적으로 진행하면 됩니다. 만약 필자처럼 환경을 재구성할 것이라면, 기존 환경은 반드시 환경 종료를 클릭하여 종료한 뒤 사용하셔야 합니다.

신규 환경 생성(도메인명 때문에 새로 생성)

추가 설명

보안그룹 설정

하기와 같이 보안 그룹을 생성하면 됩니다. EC2 페이지에서 네트워크 및 보안의 보안 그룹을 통해 작성하시면 됩니다.

• HTTP(S) 접근 및 SSH 접근을 위한 보안그룹 생성
• DB 연결을 위해서는 아웃바운드 규칙 또한 설정해주어야 하지만 아직 RDS 구성을 하지 않아 위와 같이 보안그룹 설정 진행
• 만약, 자신의 IP를 알지 못해 소스에 어떤 IP를 적을 지 모르겠다면, 하단의 참고 자료를 확인하면 좋습니다.
• 참고로 인바운드 규칙의 설명란에는 한글을 사용할 수 없습니다. 해당 내용은 참고용으로 작성한 것이기 때문에 한글을 제외한 후 보안 그룹 생성을 눌러야 합니다.

SSH 접근을 위한 PEM.KEY 수동 생성하기

SSH 접근을 위한 pem key 수동 생성

• EC2에 접근하여 네트워크 및 보안 > 키 페어를 클릭하여 PEM.KEY를 생성합니다.
• 키 페어 생성 버튼을 누르면 지정한 이름의 pem 파일이 생성됩니다. 해당 파일을 ~/.ssh/에 저장합니다.

추가 배치를 사용한 롤링(Rolling with Additional Batch)

추가 배치를 사용한 롤링

하단 참고 자료에 넣어둔 AWS Elastic Beanstalk DEV DAY 영상 캡쳐본입니다. 해당 영상을 보면 다른 배포 방식 역시 확인 가능하며, 현재 필요한 Rolling with Additional Batch에 대해서만 남겨두었습니다.

Rolling with Additional Batch

[ 유튜브 내용 정리 ]

• Rolling 배포 방식에서 50%를 capacity로 가져간다고 하면, 결국 특정 시점에 capacity가 100이 될 수 없습니다. 이때, capacity를 100%으로 유지하고 싶다면 Rolling with Additional Batch를 사용해볼 수 있습니다.
• Rolling with Additional Batch를 사용하면, 신규 버전의 인스턴스를 추가로 임시 세팅을 하여 세팅이 완료되면 순간적으로 capacity가 100이 넘어가게 됩니다. 물론, 이 배포 방식 역시 사람마다 버전이 상이하게 보일 수 있습니다.
• 그 후 기존 인스턴스들 일부(여기서는 절반씩 배포기 때문에 2개씩 진행) 떼어 버전 업데이트를 진행합니다. 버전 업그레이드가 완료되면 다시 서비스에 올리고, 이제 남은 인스턴스는 제거합니다.
  • 절반씩 배포를 하기 때문에 처음에 신규 인스턴스 2개를 추가로 넣었고, 기존 인스턴스 중 2개를 버전 업그레이드가 완료되었으므로 이미 4개가 업그레이드 완료된 상태라 남은 인스턴스 2개는 서비스에서 제거해서 날리면 됩니다.

Elastic Beanstalk 환경 삭제

AWS의 ClouadFormation에 접속하여 삭제하고자 하는 환경을 선택하고 삭제하면 됩니다.

Elastic Beanstalk 환경 삭제

참고자료

• PC의 외부 IP 알아내기
• AWS Elastic Beanstalk 배포 옵션 유튜브 영상
• AWS Elastic Beanstalk 배포 관련 document