Amazon Web Services 한국 블로그

Amazon EC2 스팟 인스턴스로 확장성 높은 웹 애플리케이션 운영하기

AWS는 2017년 re:Invent에서 새로운 Amazon EC2 스팟 인스턴스 요금 모델을 공개하였습니다.
기존의 예비 컴퓨팅 용량에 입찰하는 방법 대신 가용 용량이 있는 경우에는 인스턴스 실행 요청만으로 스팟 인스턴스를 사용할 수 있습니다.

새로운 요금 모델이 적용된 후 한가지 괄목할만한 점은 스팟 인스턴스의 중단현상이 감소되었다는 것입니다. 실제로 스팟 인스턴스 종료(terminate) 원인의 95% 이상은 EC2 중단이 아닌 고객에 의한 종료로 나타났습니다. 자세한 AWS 리전 별 인스턴스 유형 별 EC2 종료에 관한 정보는 스팟 인스턴스 어드바이저로 확인하실 수 있습니다.

스팟 인스턴스는 고객의 워크로드 유형에 따라 사용방식이 달라질 수 있습니다.

  • 가용 시간에 민감하지 않은 워크로드(time insensitive workload) – 가용성에 대한 요구사항이 상대적으로 적으며 대고객 서비스가 아닌 내부 워크로드. 공학용 계산 작업, 개발 및 테스트, 배치 작업, 머신러닝 또는 딥러닝 모델의 학습 등
  • 가용 시간에 민감한 워크로드(time sensitive workload) – 대고객 서비스와 같이 고가용성 및 내결함성(fault-tolerance)을 갖추어야 하는 워크로드. 웹 사이트 호스팅 및 웹 서비스, API, 로드 밸런서 뒤에서 실행되는 컨테이너 등

가용성에 민감하지 않은 워크로드, 특히 배치 등의 작업을 실행하던 중 스팟 인스턴스가 중단되면 기존에 실행되던 작업(Job)이 유지되면서 task들이 리스케줄링(reschedule)되어 새로운 인스턴스에서 실행되는 등 EC2 용량에 영향을 주기도 합니다.

하지만 이번 게시글에서는 스팟 인스턴스 중단이 최종 사용자에게 영향이 큰 가용성에 민감한 워크로드에 대해서 이야기하고자 합니다. 고가용성을 필요로 하는 워크로드의 경우 클라우드 모범사례를 참조하여 중단 2분 전 알림 후 인스턴스 중단 또는 연결 해제에 효과적으로 대응할 수 있는 아키텍처 적용이 매우 중요합니다.

해당 모범사례에는 특정 인스턴스와 사용자간 고정(User Stickiness) 방지, 내결함성 설계, 어플리케이션 구성요소와 큐잉 메커니즘의 디커플링, 그리고 컴퓨팅 자원과 스토리지 자원의 디커플링 등이 명시되어 있습니다.

스팟 인스턴스 사용하기

AWS 클라우드의 예비 컴퓨팅 용량을 사용하는 스팟 인스턴스는 온디맨드 대비 최대 90% 할인된 요금으로 고객에게 제공되고 있습니다.

스팟 인스턴스는 EC2 용량 반환이 요청되면 2분 간의 중단 알림 후 인스턴스 사용이 중단됩니다. 각 AWS 리전의 가용 영역마다 제공 가능한 인스턴스 타입별로 용량 풀이 제공되고 있는데요, 다수의 스팟 인스턴스를 사용할 때는 되도록 많은 용량 풀에 걸쳐 인스턴스를 배포하여 스팟 인스턴스 용량 확보와 중단을 방지하는 동시에 컴퓨팅 비용을 최적화 할 수 있습니다.

AWS Compute Blog의 게시물 Taking Advantage of Amazon EC2 Spot Instance Interruption Notices 에서는 인스턴스의 연결 드레이닝(connection draining)과 ALB(Application Load Balancer)로부터 분리 등 스팟 인스턴스의 중단에 대한 준비와 대응책을 소개합니다.

Appnext

광고 기술 업계는 주요 비즈니스 애플리케이션 운영에 스팟 인스턴스를 적극적으로 사용하고 있습니다. 그들의 워크로드를 운영하기 위해서는 높은 요청 비율(High Request Rate)과 저지연(Low Latency) 그리고 사용 중 트래픽 스파이크에 대한 지원이 입찰과정에서도 실시간으로 요구됩니다.

광고 기술 스타트업인 Appnext는 높은 기술력을 가진 AWS의 고객 중 하나로 비용 절감을 위해 스팟 인스턴스 상에서 주요 비즈니스 어플리케이션을 운영하는 좋은 예를 보여주고 있습니다. Appnext는 사용자의 일정 정보를 바탕으로 광고를 가장 효과적인 시점에 사용자에게 보여주는 서비스를 제공하고 있어 애플리케이션의 가용성 확보가 핵심이었다고 합니다.

인스턴스 다각화 및 용량 풀

Appnext는 스팟 플릿을 이용하여 손쉽게 애플리케이션 운영에 필요한 스팟 인스턴스를 다양한 용량 풀에 걸쳐 확보 하였습니다.

고가용성 애플리케이션에 스팟 인스턴스를 사용할 때 가장 중요한 것은 용량 풀의 다각화 입니다. Appnext와 같은 고객들은 가급적 각 리전의 가용영역에서 제공되는 모든 유형의 EC2 인스턴스 용량 풀을 사용하기 위해서(용량 풀을 다각화하기 위해서) 스팟 플릿을 구성합니다. 다각화를 구성 할 때는 애플리케이션에 실행에 적합한 하드웨어 스펙 가진 인스턴스를 선택하며, 적절한 할당 전략(Allocation Strategy)을 적용해 최적화된 가격의 스팟 인스턴스를 사용할 수 있습니다.

아주 드믈게 스팟 플릿으로 구성한 모든 인스턴스 유형의 용량 풀의 용량이 고갈되는 상황이 발생하기도 합니다. Appnext는 이와 같은 상황에 대비하여 Classic Load Balancer에 온디맨드 인스턴스가 자동으로 추가될 수 있도록 설정하였습니다. 다행히 용량 고갈로 인한 문제가 발생한적은 거의 없었다고 합니다.

모든 리전의 가용 영역별, 인스턴스 유형과 크기 별 예비 용량은 스팟 인스턴스의 용량 풀이 될 수 있습니다. 아래 그림의 주황색 사각형 각각이 스팟 용량 풀을 의미하는데, AWS 리전 내 모든 인스턴스 패밀리(C4, C5, M5, R4 등)가 여기에 해당됩니다(표시된 가격은 예시일 뿐, 실제 가격이 아닙니다).

스팟 인스턴스 상에서의 고확장성 웹 애플리케이션 운영

Appnext는 애플리케이션의 성능과 고가용성을 보장하기 위해 Classic Load Balancer 뒤에 충분한 용량의 EC2 인스턴스를 실행합니다. 이를 위해서는 오토스케일링을 통해 가능한 많은 스팟 인스턴스를 사용하는 동시에 스팟 인스턴스 중단에 따른 애플리케이션의 영향을 최소화해야 합니다. 스팟 인스턴스의 용량이 부족한 경우에는 Classic Load Balancer 뒤에 추가된 온디맨드 인스턴스가 신속하게 스케일 아웃(Scale Out)됩니다.

Appnext는 고성능과 고가용성을 얻기 위해 다음과 같은 설정을 적용 하였습니다(CloudWatch 지표의 임계값은 예시이며, 실제 임계값은 애플리케이션 및 리전에 따라 다를 수 있습니다).

  • 스팟 플릿 – 기본 인스턴스 공급자로 스팟 플릿을 사용하며, 오토스케일 정책을 사용하여 인스턴스가 시작 될 때 자동으로 Classic Load Balancer 뒤에 추가되도록 구성할 수 있습니다. 온디맨드 인스턴스 CPU의 임계값을 10분 이상 75% 를 초과하여 사용되면 스팟 인스턴스가 추가되며, 사용량이 임계값의 55% 미만으로 내려가면 인스턴스가 종료됩니다.
  • 온디맨드 인스턴스의 Auto Scaling 그룹 – Classic Load Balancer에 온디맨드 인스턴스를 추가하는 보조 인스턴스 공급자 입니다. Auto Scaling 그룹은 1~2개의 정적(Static) 온디맨드 인스턴스로 구성되어 있습니다. 인스턴스가 10분 이상 임계값의 90%를 초과하여 사용되면 스케일 아웃(Scale out)되며, 임계값의 75% 미만으로 내려가면 인스턴스가 종료됩니다.

용량 고갈로 인해 스팟 플릿에 설정된 용량만큼 스케일 아웃이 되지않는 경우도 있습니다. 이런 경우 스팟 인스턴스 대신 온디맨드 인스턴스가 시작되고 기존 EC2 Auto Scaling 그룹에 미리 설정한 온디맨드 인스턴스의 CPU 사용률이 증가됩니다. 이렇게 CPU 사용량에 따라 변경된다는 점 그리고 애플리케이션의 사용량 증가가 CPU 사용량에 바로 반영되는 점 때문에 Appnext는 스팟 인스턴스 상에서 웹 애플리케이션 운영할 때 위와 같은 설정이 적합하다고 판단하였습니다.

또한, 스팟 플릿으로 스팟 용량 풀을 다각화하였기 때문에 온디맨드 인스턴스가 추가되는 경우는 거의 없었습니다. 결과적으로 저렴한 비용으로 EC2 인스턴스 사용하면서 고가용성 아키텍처를 유지할 수 있었습니다.

마지막으로, EC2 Auto Scaling 그룹을 통해 스팟 플릿에 없는 인스턴스 유형을 사용할 수 있습니다. 이는 스팟 용량이 고갈된 풀에서 온디맨드 인스턴스를 시작하는 상황을 방지하기 위한 모범 사례입니다.

Appnext는 스팟 인스턴스 시작에는 스팟 플릿을, 온디맨드 인스턴스에는 Auto Scaling 그룹을 사용해 각 인스턴스 그룹의 지표와 오토스케일 정책을 분리하고 있습니다. 물론 스팟 플릿으로 온디맨드 인스턴스를 시작하는 것도 가능합니다.

아래 다이어그램에서 전체 구성 요소와 작동 방식을 참고할 수 있습니다.

Coming Soon

블로그 게시글 EC2 Fleet Manages Thousands of On-Demand and Spot Instances with One Request(EC2 플릿에서 단일 요청으로 수천 개의 온디맨드 및 스팟 인스턴스 관리하기) 에서 글쓴이는 EC2 플릿과 EC2 Auto Scaling 그룹이 곧 통합될 것이라고 언급하였습니다. 해당 기능이 출시되면 스팟 플릿 또는 EC2 플릿 대신 Auto Scaling 그룹으로 모든 작업을 수행할 수 있을 것입니다.

결론

이 게시물의 내용이 유용하셨나요? 아직 스팟 인스턴스를 사용하고 있지 않다면,  바로 스팟 인스턴스를 테스트하여 웹 애플리케이션의 컴퓨팅 비용을 최적화 해보시기 바랍니다.

이 글은 AWS Compute Blog의 Running high-scale web applications on Amazon EC2 Spot Instances의 한국어 번역으로 AWS 프로페셔널 서비스팀의 이진영 컨설턴트가 감수하였습니다.