들어가기 전에
기존에는 Elastic Beanstalk을 이용하여 개발 환경 배포를 진행했습니다. 개발 환경을 구축할 때 Elastic Beanstalk을 이용한 이유는 짧은 시간동안 기능 개발과 환경 구축을 한 번에 해야하다 보니, 간편한 방식이 필요했기 때문입니다. 또한, Docker 위에 이미지를 생성해서 띄울만큼의 여유가 없어 SpringBoot 자체를 EC2에 바로 띄웠습니다.
이번 포스팅에서는 Elastic Container Service와 Elastic Beanstalk에 대해 간단히 알아보면서 왜 Docker를 사용하는 지금도 Elastic Beanstalk를 운영 배포에 선택했는지에 대해 이야기해보겠습니다.
추가적으로, 개발 환경과 동일하게 서버 내 SpringBoot을 띄우지 않고 도커 내에 서비스를 띄우게 되었는지에 대해서도 작성해보겠습니다.
다음 포스팅
- [AWS, Github Action] Elastic Beanstalk에 SpringBoot 이미지 Docker로 배포하기(2) - ECR 리포지토리 생성 및 권한 설정
- [AWS, Github Action] Elastic Beanstalk에 SpringBoot 이미지 Docker로 배포하기(3) - EB 기본 세팅(RDS 포함)
- [AWS, Github Action] Elastic Beanstalk에 SpringBoot 이미지 Docker로 배포하기(4) - Github Action과 Dockerfile을 작성해서 배포하기
Elastic Beanstalk(EB)
Elastic Beanstalk(EB)은 웹 어플리케이션 및 서비스를 배포하고 확장하기 위한 AWS 서비스입니다. EB를 이용하면 필요한 AWS 리소스를 수동으로 실행할 필요 없이, Github Action과 같은 것을 사용하여 Docker 컨테이너 이미지를 업로드할 수 있습니다.
EB는 어플리케이션을 지원하기 위한 최신 패치 및 업데이트 제공을 포함한 인프라를 프로비저닝하고 기본 플랫폼을 관리하는 컨테이너 배포를 처리합니다.
EB 콘솔을 사용하면 어플리케이션을 단일 단위로 중지 및 시작하며 관리할 수 있습니다. 이때, autoscaling 설정값을 통해 필요할 때에 어플리케이션을 자동으로 확장 및 축소할 수 있습니다. 또한, EB를 구축할 때에 ALB 설정을 해주면 로드 밸런싱 또한 자동으로 처리가 가능합니다.
Elastic Container Service(ECS)
Elastic Container Service(ECS)는 Docker 컨테이너를 지원하는 오케스트레이션 서비스입니다. API 호출을 사용하여 수천, 수만개의 Docker 컨테이너를 빠르게 시작하고 관리할 수 있습니다. ECS는 가상 머신 클러스터를 관리 및 확장하고, 해당 VM의 컨테이너를 예약하고 VM 가용성을 유지 관리합니다.
ECS는 AWS Fargate를 사용하여 컨테이너를 배포 및 관리하므로 서버를 프로비저닝할 필요가 없습니다. ECS는 장기 실행에서 마이크로서비스에 이르기까지 광범위한 컨테이너화된 어플리케이션을 지원하며 클라우드에서 컨테이너화된 어플리케이션으로 실행할 수 있도록 Legacy Linux & Windows 어플리케이션을 마이그레이션할 수 있습니다.
ECS는 자체 Amazon VPC에서 컨테이너를 시작하여 세분화된 보안 제어를 제공하여 VPC 보안 그룹 및 네트워크 ACL을 사용할 수 있도록 합니다. IAM을 사용하여 컨테이너가 접근할 수 있는 서비스와 리소스를 결정할 수 있습니다.
ECS를 사용하면 ELB(또는 ALB), CloudWatch, Elastic Container Registry(ECR) 등과 같은 AWS 서비스를 기본 통합으로 사용할 수 있습니다.
Elastic Beanstalk을 언제 사용하면 좋을까?
AWS나 컨테이너화 개념을 처음 접하는 경우, 또는 Docker를 막 시작하거나 새로운 어플리케이션을 개발하는 경우 Elastic Beanstalk을 통해 Docker 컨테이너를 지원하면 좋습니다. Elastic Beanstalk은 간단한 인터페이스를 제공하고, 공개 또는 비공개 Registry에서 Docker 이미지를 가져올 수 있습니다. Elastic Beanstalk을 사용하면 어플리케이션 확장 및 용량에 대한 제어 권한은 줄어들지만, AWS에 Docker 컨테이너를 배포하는 것을 매우 간단하게 진행할 수 있습니다.
Elastic Container Service를 언제 사용하면 좋을까?
Elastic Beanstalk과 비교하여 Elastic Container Service는 Docker 컨테이너의 어플리케이션 아키텍처 및 오케스트레이션에 대해 더 많은 제어를 제공합니다. 클러스터 노드의 크기와 수를 지정하고 자동 크기 조정을 사용해야 하는지 등을 결정합니다.
Elastic Container Service는 Docker 컨테이너를 시작하기 위해 task를 사용합니다. task에는 함께 시작하고 동시에 종료해야 하는 그룹을 지정할 수 있습니다. ECS는 스케줄링, CPU 및 메모리 활용에 있어 높은 유연성과 사용자 정의를 제공합니다. 또한 ECS는 다른 AWS 서비스와 함께 작동하기 위한 특별한 통합 노력이 필요하지 않습니다.
따라서, Elastic Container Service는 다른 AWS 서비스와 통합이 필요한 마이크로 서비스를 실행하거나 사용자 지정 또는 관리형 스케줄러를 사용해 EC2 온디맨드, 예약 또는 배치 워크로드를 실행해야 할 때 적합합니다. 추가적으로 레거시 코드를 컨테이너화하고 코드를 다시 작성할 필요 없이 AWS로 마이그레이션하려는 경우에는 ECS를 선택해야 쉽게 마이그레이션이 가능합니다.
왜 운영 배포에 Elastic Beanstalk를 선택했을까?
사실 필자의 경우, Docker나 AWS에 익숙하지 않은 사람이기 때문에 Elastic Beanstalk을 통한 배포를 진행하는 것이 좋다고 생각했습니다. 처음에, ECS에 대해서도 찾아보고 실제 테스트해보고자 ECS를 생성해보기도 했습니다. 직접 ECS를 만나보니, Elastic Beanstalk 때는 간단하게 설정값 하나 넣는 것으로 끝났던 부분들이 좀 더 튜닝할 수 있게 되어 있는 것을 느꼈습니다. 현재 필자의 AWS에 대한 수준을 고려했을 때 ECS를 쓰는 것은 오버스펙이고, 좋은 코드가 되도록 클린 코딩에 더 집중하는 것이 옳다고 여겨 Elastic Beanstalk을 선택하게 되었습니다.
왜 운영 배포에 Docker를 이용하기로 결정했을까?
도커를 사용한 이유는, 이미지로 현재 버전의 어플리케이션을 만들어두기 때문에 어느 서버에 띄우던 동일한 환경으로 배포가 가능하기 때문입니다. 만약, EC2에 직접 SpringBoot을 올리게 되면 scaling이 필요할 때에 신규 서버를 구축하여 JAVA 설치 등 SpringBoot 실행에 필요한 항목들을 매번 설치해주어야 합니다.
- 물론, Elastic Beanstalk의 경우는 autoscaling 기능을 켜주면 알아서 신규 EC2를 만들고 프로비저닝된 환경을 기준으로 신규 서버에 배포가 가능합니다.
- 도커 내에 이미지로 만들어 서비스를 하게 되면, 서버 내 JAVA 설치 등 신규 서버 구성 시 세팅 필요한 부분을 신경 쓰지 않고 동일한 환경으로 서비스를 할 수 있습니다.
추가 개념
프로비저닝(Provisioning)
사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해두었다가 필요 할 때 시스템을 즉시 사용할 수 있는 상태로 미리 준비해두는 것을 말합니다.
AWS Fargate
