하이브 런칭기 #5 - 웹서버 관리는 Beanstalk에게

관리 요소를 줄이기 위한 서비스 선택 고민

앞서 언급했던 것 처럼 오토스케일링 기능을 사용하기 위해서 AMI를 사용했었습니다. 하지만 AMI 를 사용한 자동 확장 구조에서는 컨텐츠나 설정과 같은 변경사항이 발생하게 되면 해당 AMI를 인스턴스로 구동시킨 후에 변경 사항을 적용해야 했습니다. 이렇게 변경된 EC2 인스턴스는 다시 AMI로 생성하여 이를 오토스케일링 그룹 설정에 적용을 해야 합니다. 이를 수동으로 할 경우 번거로울 뿐만 아니라 실수를 할 가능성이 크고, 그로 인해 빈번하게 배포를 수행하기가 어려워지게 됩니다. 이러한 절차는 서비스 개선에 있어서 악영향을 끼치게 될 것입니다. 그래서 조금더 편하게 배포를 할 수 있는 방법을 찾다가 AWS 의 서비스 중 Elastic Beanstalk 나 OpsWorks, ECS(EC2 Container Service)와 같은 관리형 서비스들을 검토하게 되었습니다.

사내 환경이 docker로 되어 있고, docker의 매력을 느끼던 차라서 조금 더 활용해보고 싶은 마음에 처음에는 ECS를 적용했었습니다. ECS에서 컨테이너가 동작하기 위해서는 AWS 상에 docker image들이 업로드 되어 있어야 하는데 이를 위한 서비스로 ECR(EC2 Container Registry)가 제공됩니다. 그래서 자연스럽게 사내에 docker registry를 구성하여 사용하고 있었는데, ECR을 통해 이미지들을 통합 관리하게 되어서 따로 repository 관리도 필요 없고 등록된 이미지들의 버전관리 또한 한 곳에서 할 수 있었기 때문에 편리했습니다. 하지만 ECS를 검토했을 당시에는 아직 서울 리전에 출시하지 않아서 도쿄 리전을 이용해야했고, Elastic Beanstalk 서비스를 살펴보면서 ECS를 사용할 생각은 아주 잠깐의 고민 후에(?) 접게 되었습니다. ECS 서비스보다 Elastic Beanstalk 서비스가 더 나아서가 아니라 저희가 구동할 서버가 tomcat 위에 아주 간단한 구조로 되어 있었기 때문에 tomcat을 지원하는 Elastic Beanstalk가 딱이라는 생각이 들었기 때문이었습니다. 앞서 얘기했던 잠깐의 고민은 docker를 활용하고 싶은 엔지니어의 욕심 때문이었는데 역시나 오버엔지니어링이라는 생각이 들어서 깔끔하게 접고, 이번 프로젝트의 프로덕션 환경에서는 docker를 사용하지 않는 것이 좋겠다는 판단이 들었습니다. 그래서 현재 사내 환경 구축에서만 docker를 활용하고 있습니다.

Elastic Beanstalk는 코드를 업로드하기만 하면 용량 프로비저닝, 로드 밸런싱, 오토 스케일링, 상태 모니터링까지 자동으로 구성해주고 처리를 합니다. 이러한 편리함을 얻으면서도 사용되는 리소스 외에는 추가 비용이 없다는 것이 큰 장점입니다. tomcat을 사용하다보니 war 파일을 업로드하여 배포를 하게 되는데 이 과정은 jenkins를 통해 자동화하였습니다. 빌드 시 마다 버전 번호를 붙여서 업로드를 하기 때문에 언제든지 이전 버전으로 배포를 할 수 있고, 롤링 패치를 지원해서 무점검 패치가 매우 손쉽게 가능합니다. 더 나아가서 Elastic Beanstalk의 상태에 따라 알람 설정을 해놓으면 문제가 발생할 경우 즉각적으로 인지를 할 수가 있습니다.

Elastic Beanstalk를 사용하면서 주의해야할 사항이 있는데, Autoscaling의 Launch configuration(시작 구성)을 변경하거나 VPC 설정을 변경하거나 인스턴스 type 변경, AMI 변경, ssh key 변경 등 인스턴스에 영향이 가는 설정들이 변경될 경우에는 Elastic Beanstalk 환경의 모든 인스턴스를 종료하고 다시 배포하게 됩니다. 처음에는 이에 대한 경고 메시지가 출력되지 않아서 생각없이 변경을 수행했었는데 ELB를 포함해서 EC2 인스턴스가 전부 터미네이트 되고 다시 생성되서 무척 당황했었습니다. 심지어 ELB 프리워밍 신청까지 해둔 상태에서도 설정 변경으로 인해 프리워밍된 ELB가 제거되어 다시 신청을 했던 적도 있었습니다. 최근에는 경고 페이지가 출력되어서 주의하면 이러한 실수를 방지할 수 있습니다. 그래서 Elastic Beanstalk 까지 적용한 아키텍처는 다음과 같았습니다.

다음 프로젝트에서는 마이크로 서비스까지는 아니지만 서비스를 조금 분할해서 진행해볼 예정이라서 ECS나 새로 출시된 EKS를 활용해볼 수도 있을 것 같습니다. 하지만 이번 프로젝트처럼 단일 서비스로 구성될 경우에는 Elastic Beanstalk를 적극 활용할 예정입니다.(너무 좋음)

같이 보면 좋은 포스팅

• 하이브 런칭기 #1 - 사내 환경 구성

• 하이브 런칭기 #2 - AWS 기본 구성

• 하이브 런칭기 #3 - 데이터베이스 구성

• 하이브 런칭기 #4 - 오토스케일링 및 알림 설정

• 하이브 런칭기 #5 - 웹서버 관리는 Beanstalk에게

• 하이브 런칭기 #6 - 부하테스트

• 하이브 런칭기 #7 - 로그 관리 및 지표/통계