Category: Amazon EC2 Container Service*


Sprinklr의 AWS 리전간 대용량 재해 복구 구축 사례

Sprinklr에서 통합된 고객 경험 관리 플랫폼을 통해 세계에서 가장 큰 브랜드 기업들의 마케팅, 광고, 조사, 관리, 상거래를 지원합니다. Facebook, Twitter, LinkedIn 및 전 세계 22개 기타 소셜 채널과 통합된 당사 플랫폼은 수천 개의 서버를 사용하고, 페타바이트 단위의 데이터를 조사하고, 매일 수십억 건의 트랜잭션을 처리합니다. Twitter 하나만 해도 하루에 몇 억 개의 트윗을 처리해야 합니다.

매일 처리하는 엄청난 데이터 양을 고려할 때 재해 복구(Disaster Recovery, DR)는 더없이 중요한 문제입니다. 자연재해나 인재가 발생하더라도 비즈니스 연속성이 보장되어야 합니다.

대부분의 기업은 DR 대신에 고가용성(HA)을 구현하여 서비스 가동 중지 상황에 대비합니다. HA 보장을 위한 서비스 폴백 메커니즘을 갖추고 있습니다. HA 모드로 실행되는 서비스는 여러 가용 영역에서 실행되지만 동일한 지리적 리전에 속하는 호스트가 처리합니다. 그러나 이러한 접근 방식은 리전 전체가 다운된 경우에 비즈니스의 정상적인 운영을 보장하지 않습니다. DR은 250마일 이상 떨어진 다른 리전에서 복구할 수 있다는 점에서 완전히 새로운 차원을 보여 줍니다. DR 구현은 액티브/패시브 모델로, 이는 여러 리전에서 중요성이 가장 덜한 서비스를 항상 실행하지만 필요할 때 인프라의 주요 부분이 시작 및 복원됨을 뜻합니다.

당면 과제

재해 발생 시 비즈니스 운영이 중단되는 위험을 감수하고 싶지 않습니다. 고객에 대한 약속의 일환으로 튼튼한 재해 복구 프로세스를 갖춰야 합니다. 이는 어느 비즈니스에나 매우 중요합니다. 예를 들어 허리케인 샌디가 기승을 부릴 때 미국 북동부 지역에 데이터 센터가 있는 일부 회사만이 홍수로 인해 오프라인 상태가 되었습니다. 당사 DR의 경우 복구 목표 시점(RPO)이 24시간입니다. 이는 복구할 데이터가 생성된 지 24시간이 지나지 않았음을 뜻합니다. 복구 목표 시간(RTO)은 DR이 선언된 시점으로부터 복원이 완료되기까지 걸리는 시간을 뜻하며, 당사의 경우 고객 SLA에 따라 6시간~24시간입니다. 테스트를 하면서 RTO를 4시간으로 정했습니다.

재해 복구(DR)를 위한 단계

규모 파악

Sprinklr의 리전 간 재해 복구 동기화

목표를 이해하려면 서비스 유형과 그 개수를 포함하여 현재의 작업 규모를 고려해야 합니다. MongoDB, Elasticsearch, SOLR, Mesos, RDS 등 광범위한 데이터/비데이터 서비스 목록이 있습니다. 따라서 서버가 수천 개에 이르는데, ELB는 거의 100개, route53 항목 약 4,000개, 1페타바이트 이상의 기본 데이터, 그리고 RDS 인스턴스 50개 이상이 있습니다. 이러한 서비스는 모두 복원 시점에 DR 리전에서 시작되어야 합니다.

목적 달성을 위해 사용자 지정 스크립트를 작성했는데, 이 스크립트는 주로 AWS API 호출을 통해 인스턴스를 시작하고, 스냅샷을 연결하고, elb 및 경로 항목을 생성합니다.

위 그림과 같이, 관련된 모든 백업은 복원을 위해 DR 리전으로 복사됩니다.

복사할 백업 유형은 크게 세 가지입니다.

  1. EBS 스냅샷: 사용자 지정 로직을 구축하여 사용 가능한 모든 백업과 그 진행 상황 및 완료 여부를 지능적으로 추적합니다.  AWS 한도를 넘지 않고 전체 스냅샷 사본을 얻고자 노력합니다.
  2. S3 스냅샷: cross s3 동기화를 사용하며, 이는 매우 효과적으로 작동합니다. 단 몇 분만에 기본 리전에서 DR 리전으로 데이터를 복사할 수 있습니다.
  3. RDS 스냅샷: AWS RDS CopyDBSnapshot API를 사용하여 RDS 스냅샷을 복사합니다.

DR을 위한 파일럿 라이트 설정

재해 복구 미리 설정빠른 시작을 위해, 재해 복구를 위한 게이트웨이를 얻으려면 몇 가지 서비스가 실행 중이어야 합니다. VPC, 서브넷, Route53 항목을 설정하는 것도 여기에 포함됩니다. 이를 위해 사용자 지정 도구를 구축했습니다. 비슷한 CIDR 구성과 서브넷 마스킹으로 VPC를 만들고, 경로 항목의 경우 새 서브넷이 생성될 때마다 DR 리전에도 자동으로 생성되도록 합니다. 이를 위해 AWS API 호출을 통해 기본 리전의 서브넷 정보를 파악하고, 서부 리전에 해당하는 서브넷을 만들었습니다.

없을 경우 복원을 시작하기 위한 항목을 얻을 수 없는 필수 서비스를 파악합니다. 이는 인증 서버(ldap/IPA, 있는 경우), 빌드 서버 또는 모니터링 서버일 수 있습니다. 이러한 서비스는 항상 실행 중이어야 합니다. 즉 시작 및 설정한 후 어떠한 예기치 못한 상황에서도 항상 DR 리전으로 항목을 가져올 수 있도록 이러한 서비스를 계속 실행함을 뜻합니다.

또한 종속된 AWS 서비스를 사용할 수 있어야 합니다. 예를 들어 S3 버킷을 DR 리전에서 사용할 수 있어야 하고 항상 기본 리전과 동기화해야 합니다. 많은 구성, 속성 파일, 바이너리가 S3에 있기 때문에 이 단계는 중요합니다. 애플리케이션이 계속 작동되도록 하려면 DR 리전에서 이를 사용할 수 있도록 해야 합니다. 이를 위해 S3 교차 리전 복제 기능을 사용합니다. 이는 객체를 빠르고 거의 동시에 동기화하여 놀라운 작업을 수행합니다.

재해 복구 용량 계획의 그림

용량 계획

이제 규모를 고려하여 DR의 필요 용량을 알아내야 합니다.

애플리케이션 관점에서 첫 단계는 DR 리전에서 필요한 구성을 사용할 수 있는지 확인하는 것입니다. 이때 필요한 구성이란 DB별로 다른 파라미터일 수도 있고 사용자 지정된 설정 관련 파라미터일 수도 있지만, 기본적으로 애플리케이션이 작동하는 데 필요한 모든 것을 말합니다. 위 그림과 같이, 복원하는 각 파트너가 당사 DB에 저장한 속성을 토대로 다양한 서비스의 필요 용량을 파악합니다. 예를 들어 파트너 Z는 ES 클러스터 70개, MongoDB 40개, RDS 30개, SOLR 20개가 필요합니다. 다음 단계에서는 모든 서비스를 종합적으로 고려하여 특이한 것을 찾아냅니다. 파트너 간에 클러스터 DB를 공유하므로, 최초의 필요 용량에 있던 클러스터 중 일부를 실제로 다른 파트너들도 공유할 수 있기 때문입니다. 이렇게 해서 최종적인 필요 용량을 파악하고, 이를 인스턴스 유형별로 나눕니다. 위 그림과 같이 Elasticsearch 등 서비스마다 인스턴스 유형이 서로 다릅니다. 마지막으로 해당 인스턴스 유형의 총 필요 용량을 파악하는 일이 남았습니다.

첫 번째 단계가 명확해지면 ELB 및 경로 항목을 몇 개나 생성해야 하는지 알아냅니다. AWS API로 얻은 ELB 및 경로 항목 정보에 대한 메타데이터를 보유하고 있습니다. 이 정보는 서부에 항상 준비되어 있습니다. 이 방법으로 필요 용량의 정확한 수를 알아내고, 인프라를 추정합니다. 여기에는 EC2, ELB 및 경로 항목을 위한 용량 계획도 포함됩니다.

원활한 복구를 위해서는 위 단계 모두 중요하고 서로 밀접하게 관련되어 있으며, 가급적 이를 자동화하는 것이 좋습니다. 우리는 AWS API 호출을 사용한 Perl로 사용자 지정 스크립트를 작성하여 이 모든 단계를 자동화했습니다.

재해 발생 시

우선 순위 정하기

존재하는 여러 서비스 중에 가장 중요한 서비스를 기준으로 시작의 우선 순위를 정하고 서비스의 EC2 인스턴스를 시작해야 합니다. 서비스를 세 가지 세트로 나누는 것이 좋습니다. 이는 핵심적인 서비스를 쉽게 시작할 수 있도록 하기 위한 중요한 결정입니다. 우리가 피하고자 하는 주요 방해 요소는 AWS의 용량 또는 한도 문제입니다.  서비스를 나누면 API 호출 수가 적어지며, AWS가 그 시점에 보유하고 있는 티어 1 서비스에 사용 가능한 인스턴스 유형을 모두 활용할 수 있습니다. 두 번째 세트와 세 번째 세트는 다음에 시도합니다. 이러한 접근 방법의 장점은 우선 AWS API 호출을 너무 많이 사용하지 않고, 복원이 충돌하지 않는다는 것입니다. 이를 위해 다시 사용해야 할 것 같은 AWS API 호출 출력을 캐시하는 캐싱 로직을 개발했습니다. 이를 통해 API 호출 수를 50% 줄일 수 있습니다. 두 번째는 사용 가능한 용량이 대부분 가장 핵심적인 서비스에 할당된다는 점입니다.

용량에 대비한 플랜 B

당장 재해가 발생하면 원하는 인스턴스를 마음대로 시작하지 못할 수 있으므로 실행 시간 인텔리전스를 구축할 필요가 있습니다.

우선 순위가 두 번째나 세 번째인 서비스를 할 때쯤이면 사용 가능한 용량을 다 써버렸을 수도 있습니다. 따라서, 용량 한도를 이미 늘렸습니다. 그러나 어떤 인스턴스 유형은 DR 시점에 AWS에서 사용하지 못할 수 있고, 이로 인해 전체 DR 작업이 위험에 빠질 가능성이 있습니다.

이러한 위험을 완화하기 위해 플랜 B를 수립했습니다. 플랜 B가 준비되고 자동화를 통해 인텔리전스를 구축하여 동일한 패밀리의 다른 인스턴스 유형을 시작합니다. 이 인텔리전스를 구축하기 위해 AWS CloudWatch를 사용합니다. AWS CloudWatch 측정치의 정보를 사용하여 기본 리전의 인스턴스 사용량을 분석합니다. 이를 통해 현재 인스턴스 패밀리 및 유형을 사용할 수 없는 경우에 사용할 수 있는 인스턴스 패밀리 및 유형을 알아낼 수 있습니다. 다시 말해 r3.xlarge 인스턴스 유형을 사용하는 특정 서비스를 예로 들면, CloudWatch 측정치 덕분에 이 서비스가 사용하고 시작해 볼 수 있는 다음 인스턴스 유형을 정하기 위한 모든 정보를 확인할 수 있습니다.

새 인스턴스 유형을 결정하고 나면 인스턴스 개수를 계산해야 합니다. 예를 들어 r3.2xlarge에서 r3.xlarge로 한 단계 아래로 가면 용량을 두 배로 늘려야 할 수 있으며, 한 단계 위로 가면 용량을 절반으로 줄여야 할 수 있습니다. 따라서 실행 시 이를 계산해야 합니다.

다른 AWS 서비스 복원 및 시작

ELB, Route 등 EC2 이외의 서비스 시작이 이제 트리거됩니다. 기본 리전의 S3에서 동기화된 메타데이터를 사용하여 이러한 서비스를 불러옵니다. 메타데이터 정보에는 이 서비스를 시작하는 데 필요한 정보가 들어 있습니다. ELB의 경우 ELB 유형(내부 또는 외부), 인증서 정보, 연결된 서브넷, 연결된 인스턴스입니다. 경로 항목의 경우 DNS 레코드 유형과 그 값입니다.

구성을 위해 EC2 인스턴스 정보가 필요할 수 있으므로 EC2를 시작한 후 이를 시작합니다. 예를 들어 경로 항목에는 EC2 인스턴스의 퍼블릭 IP 주소 정보가 필요할 수 있습니다.

애플리케이션 복원

위 단계를 실행했으면 절반은 온 것입니다. AWS에서 리소스를 가져왔고 애플리케이션 요구 사항에 따라 이를 구성할 수 있었기 때문입니다. AWS에서 얻고자 하는 필요 용량이 대부분 처리되었습니다. 나머지는 주로 애플리케이션 및 로직과 관련이 있습니다. 코드베이스를 사용할 수 있게 준비해 두는 것과 필요 시 DR 리전에 바로 빌드를 배포할 수 있도록 하는 것도 여기에 포함됩니다.

직면한 문제 및 수정

위 모델을 구현한 후 API 호출과 관련된 몇 가지 문제에 직면했습니다. 복원 규모로 인해 엄청난 수의 API 호출이 발생했고, AWS에서는 이를 조정했습니다. API에서 보내는 막대한 정보를 캐시하기 위해 인텔리전트 캐싱 시스템을 개발했습니다. 그 결과 AWS API 호출이 처음의 4분의 1로 줄었습니다.

이 블로그 게시물에서 DR 프로세스의 계획 방식에 대한 아이디어를 얻으시기 바랍니다. DR 계획을 수립하고 주기적으로 테스트하는 것은 자연재해나 인재 발생 시 비즈니스 운영이 중단되지 않도록 하는 데 매우 중요합니다. 자세히 알아보려면 Sprinklr 웹 사이트를 방문하십시오.

이 글은 소셜 미디어 통합 관리 서비스인 Sprinklr의 책임 설계자인Senthilkumar Ramaswamy와 DevOps 책임 엔지니어 Rakesh Pillai가 작성한 AWS Startup 블로그의 Large scale disaster recovery using AWS regions의 한국어 번역입니다.

Amazon ECR 수명 주기 정책을 통한 컨테이너 이미지 자동 삭제 기능 출시

오늘부터 Amazon EC2 Container Registry(Amazon ECR)의 일부인 수명 주기 정책을 사용하여 오래되거나 사용하지 않는 이미지를 자동으로 제거함으로써 컨테이너 이미지 리포지토리를 깔끔하게 정리할 수 있습니다.

Amazon ECR은 종합 관리형 도커 컨테이너 레지스트리로 서비스 규모 조정을 통해 수백 개의 이미지의 일괄 풀링을 처리하는 데 따른 일반적인 문제를 염려할 필요 없이 도커 컨테이너 이미지를 용이하게 저장하고 관리하고 배포할 수 있습니다. 규모가 커지면 Amazon ECR을 사용하는 개발팀이 여러 컨테이너 이미지 버전으로 리포지토리가 가득차는 현상을 자주 접하게 됩니다. 그럴 경우 코드 변경을 찾기 힘들어지고 불필요한 스토리지 비용이 발생하여 문제가 됩니다. 이전에는 리포지토리를 정리하려면 오래된 이미지를 직접 삭제하거나 스크립트를 작성하고 실행하는 데 많은 시간이 소요되었습니다.

이제는 수명 주기 정책을 통해 규칙 집합을 정의하여 오래된 컨테이너 이미지를 자동으로 제거할 수 있습니다. 또한 규칙 미리 보기를 통해 규칙을 실행할 때 영향을 받는 컨테이너 이미지가 어떤 것인지 정확히 파악할 수 있습니다. 결과적으로 리포지토리를 더 잘 구성하여 문제의 소지가 있는 코드 수정을 보다 용이하게 찾고 스토리지 비용을 절감할 수 있습니다.

그럼 수명 주기 정책의 작동 방식을 알아보겠습니다.

 

기본 규칙

컨테이너에 코드를 배포하는 것에 따른 가장 큰 이점 중 하나는 이전 버전을 신속하고 용이하게 되돌릴 수 있다는 것입니다. 무언가가 잘못되었을 때 이전 컨테이너 버전으로 쉽게 되돌릴 수 있고 잘못된 배포 전처럼 애플리케이션 실행되기 때문에 위험 부담을 덜 안고 배포할 수 있습니다. 대부분은 아마도 몇 개 버전씩이나 롤백하는 경우는 없을 것입니다. 상황이 비슷하다면, 수명 주기 규칙 하나만으로 최근 30개 이미지를 보관하는 데 충분합니다.

최근 30개 이미지

ECR 레지스트리에서 [Dry-Run Lifecycle Rules, Add]를 선택합니다.

  • [Image Status]에서 [Untagged]를 선택합니다.
  • [Match criteria]의 [Count Type]에서 [Image Count More Than]을 입력합니다.
  • [Count Number]에서 30을 입력합니다.
  • [Rule action]에서 [expire]를 입력합니다.

Save를 선택합니다. 어떤 이미지가 정리되는지 확인하려면, [Save and dry-run rules]를 선택합니다.

물론 규정 준수 이유 때문에 특정 이미지의 경우 횟수 기준이 아니라 기간 기준으로 보관하는 것을 선호하는 경우도 있습니다. 그와 같은 상황에서는 90일이 지난 이미지를 정리하는 것을 선택할 수 있습니다.

Last 90 Days(지난 7일)

방금 생성한 규칙을 선택하고 [Edit]을 선택합니다. 태그 없는 이미지의 경우 90일 간만 보관하도록 파라미터를 변경합니다.

  • [Match criteria]의 [Count Type]에서 [Since Image Pushed]를 입력합니다.
  • [Count Number]에서 90을 입력합니다.
  • [Count Unit]에서 [days]를 입력합니다.

태그

90일은 임의로 제시한 기간으로, 특정한 종류의 이미지에 대해서는 더 긴 기간을 요하는 정책을 시행할 수도 있을 것입니다. 그와 같은 상황에서도 계속하여 정리를 원하는 경우, 태그가 앞에 붙는 이미지를 삭제하는 것을 검토할 수 있습니다.

아래는 태그 없는 이미지, 개발, 스테이징 및 프로덕션 이미지를 정리하기 위한 규칙의 목록입니다.

  • 90일이 지난 태그가 없는 이미지 삭제
  • 90일이 지난 개발 태그가 붙은 이미지 삭제
  • 180일이 지난 스테이징 태그가 붙은 이미지 삭제
  • 1년이 지난 프로덕션 태그가 붙은 이미지 삭제

확인할 수 있듯이 새 Amazon ECR 수명 주기 정책은 강력하며, 필요한 이미지는 간단하게 보관하고 다시 사용할 일이 없는 이미지는 쉽게 삭제할 수 있게 해 줍니다. 이 기능은 Amazon ECR을 이용할 수 있는 모든 리전에서 추가 비용 없이 지금 바로 이용할 수 있습니다. 자세한 내용은 Amazon AWS 기술 설명서의 Amazon ECR 수명 주기 정책을 참조하십시오.

Brent;

이 글은 AWS Compute Blog의 Clean up Your Container Images with Amazon ECR Lifecycle Policies 글의 한국어 번역입니다.

Amazon EC2 Container Registry(ECR), 서울 리전 출시

지난 주 Amazon ECS 서비스 서울 리전 출시 이후, 오늘 Amazon EC2 Container Registry(ECR) 서비스도 서울 리전에 출시 합니다.

Amazon ECR 서비스는 콘테이너 기반 서비스 개발자가 Docker 콘테이너 이미지를 손쉽게 저장, 관리 및 배포할 수 있게 해주는 완전관리형 Docker 콘테이너 레지스트리입니다. Amazon ECR은 Amazon EC2 Container Service(ECS)와 통합되어 개발에서 프로덕션까지의 워크플로를 간소화할 수 있을 뿐 아니라 자체 컨테이너 레지스트리를 운영하거나 기본 인프라 확장에 대해 걱정할 필요가 없습니다.

또한, 콘테이너 이미지를 가용성과 확장성이 뛰어난 인프라에 호스팅하여 애플리케이션을 위해 콘테이너를 안정적으로 배포할 수 있습니다. 또한, AWS Identity and Access Management(IAM)와 통합되어 각 리포지토리에 대한 리소스 수준의 제어를 제공합니다.

Amazon ECS/ECR  출시에 맞추어 아래와 같이 온라인 세미나를 준비하였습니다. 관심 있는 분들의 많은 참여를 바랍니다.

기술 기초 | Amazon ECS/ECR 활용하여 마이크로서비스 구성하기
연사: 김기완 AWS 솔루션즈 아키텍트
일시: 2017년 11월 1일 (수) 오전 10:00 – 오전 11:30

콘테이너를 활용하여 마이크로서비스를 구성할 때는 효과적으로 콘테이너 및 서비스를 관리할 수 있는 방법이 필요합니다. 본 세션에서는 유연하게 콘테이너 환경을 관리/모니터링 할 수 있는 Amazon EC2 Container Service 및 EC2 Container Registry를 소개합니다. 아울러 Amazon ECS/ECR 환경에서 효과적인 자원 및 로그 관리, 마이크로서비스 관리에 대해서 자세히 살펴봅니다.

지금 등록하기

Amazon ECR에는 리포지토리에 저장한 콘테이너 이미지 데이터와 인터넷으로 전송한 데이터 양에 대한 요금만 지불합니다. 프리티어 고객은 1년간 500MB 데이터 저장 용량에 대해서 무료입니다. 더 상세한 것은 서울 리전에 대한 ECR 요금표를 참고하시기 바랍니다.

더 자세한 사항은 Amazon ECR 서비스 제품 페이지설명서블로그를 참조하십시오.

윤석찬 (Channy);

Amazon EC2 Container Service(ECS) 서울 리전 출시!

드디어 오늘 Amazon EC2 Container Service (Amazon ECS)를 아시아-태평양(서울) 리전에 출시합니다.

Amazon ECS는 Docker 콘테이너를 프로덕션 환경에 배포 및 확장하기위한 관리 서비스로서, Amazon ECS를 사용하면 클러스터 구성에 필요한 서버 용량을 추가하고, 콘테이너 이미지를 업로드 할 수 있습니다. Amazon ECS는  서버 클러스터 전체에 콘테이너를 배포하고 상태를 모니터링하며, 콘테이너 부하 분산 및 크기 조정을 처리하는 동시에 데이터베이스 및 기타 리소스에 대한 각 콘테이너 접근 제어를 안전하게 할 수 있도록합니다.

Amazon ECS는 이미 다양한 한국 고객들이 콘테이너 기반 애플리케이션에서 사용하고 있습니다. 삼성SDS  신우용 상무는 “AWS 클라우드를 선택한 이유는 Amazon EC2 컨테이너 서비스(Container Service)를 이용한 첼로 구축 POC를 진행하여 2시간 이내로 아주 빠르게 첼로를 구축할 수 있었고, 네트워크 응답 속도도 빠르고 안정적이었다. AWS 클라우드 서비스를 이용하여 고객에게 첼로를 빠르고, 안정적으로 서비스 할 수 있게 됐다”라고 설명하였습니다.

또한, 삼성전자 장수백 상무는 삼성 IoT 서비스인 Samsung Connect 구축을 위해 “오토 스케일링(Auto scaling) 적용, 아키텍처 재정비, 지역적이고 분산된 개발, 자동화 되고 독립적인 배포 및, 다양한 서비스에 최적화될 수 있는 인스턴스 타입이 적용돼야 한다. 이에 대한 적절한 해법이 AWS 클라우드를 사용한 마이크로 서비스 아키텍처(Micro services architecture) “라고 소개했습니다. 특히, 삼성전자 송주영 선임은 Samsung Connect를 위한 Amazon ECS 활용 사례를 들어 “Amazon ECS는 AWS 상의 멀티 계정을 지원하여, 다양한 보안 및 접근 제어, 그리고 확장성 및 비용 절감과 기술 지원을 받을 수 있다”라고 밝혔습니다.

좀 더 자세한 정보는 아래에서 주요 기업들의 사례를 보실 수 있습니다.

다양한 동영상을 통해 Amazon ECS에 대한 내용을 살펴 보실 수 있습니다.

지난 AWS DevDay에서 있었던 콘테이너 트랙의 최선 정보도 참고하시기 바랍니다.

Amazon ECS 서울 리전 출시와 함께, 앞으로 콘테이너 기반 서비스를 하는 많은 한국 고객들의 활용 방법도 안내해 드리도록 하겠습니다. 자세한 내용은 Amazon ECS 제품 페이지설명서블로그를 참조하십시오.

윤석찬 (Channy);

EC2 스팟 인스턴스로 Amazon ECS 콘테이너 클러스터 운영하기

Amazon EC2 컨테이너 서비스 (Amazon ECS)가 ECS 콘솔에서 Amazon EC2 스팟 인스턴스에 직접 ECS 클러스터를 시작하는 기능을 지원한다는 것을 알리게 되어 매우 기쁩니다.

스팟 인스턴스는 예비 Amazon EC2 컴퓨팅 용량에 입찰 할 수 있게 합니다. 스팟 인스턴스는 일반적으로 온 디맨드 인스턴스보다 50-90 % 저렴합니다. 스팟 인스턴스로 ECS 클러스터를 운영하면 기존의 컨테이너화 된 워크로드를 실행하는 비용을 줄이거나 동일한 예산을 유지하면서 컴퓨팅 용량을 2 ~ 10 배까지 증가시킬 수 있습니다. 혹은 둘 다 조합 할 수 있습니다!

스팟 인스턴스를 사용하면 인스턴스 시간당 지불 할 가격을 지정합니다. 스팟 인스턴스는 언제든지 당신의 입찰가가 현재 스팟 가격을 초과 할 경우 실행됩니다. 더 높은 스팟 가격으로 인해 인스턴스가 회수 된 경우 인스턴스가 실행된 부분 시간에 대해서는 비용이 청구되지 않습니다.

ECS 콘솔은 스팟 집합을 사용하여 스팟 인스턴스를 배포합니다. 스팟 집합은 최적의 가격으로 컨테이너 어플리케이션에 대해 요청한 목표 용량 (인스턴스 또는 vCPU 개수로 표현)을 배포하려고 시도합니다. 현재 입찰 가격 또는 사용 가능한 용량의 변경으로 인해 스팟 인스턴스가 회수 된 경우에도 스팟 집합은 목표 용량을 유지하려고 시도합니다.

컨테이너는 다수의 스팟 집합이 배포되는 여러 종류의 자원 풀과 잘 들어 맞습니다. 스팟 집합을 사용하면 여러 스팟 인스턴스풀 (인스턴스 유형 및 가용 영역 조합)에 용량을 프로비저닝 할 수 있어 애플리케이션 가용성을 향상시키고 시간이 지남에 따라 집합의 운영 비용을 절감할 수 있습니다.  스팟 집합과 함께 ECS가 제공하는 확장 가능하고 유연한 컨테이너 배치 시스템을 결합하면 컨테이너 작업 부하를 효율적으로 배치하고 비용의 일부만으로 규모에 관계없이 쉽게 클러스터를 관리 할 수 있습니다.

이전에는 스팟 인스턴스에 ECS 클러스터를 배포하는 것이 수동 프로세스였습니다. 이 글에서는 ECS 콘솔에서 새로운 스팟 집합 통합을 사용하여 컨테이너 작업 부하에 대한 고 가용성, 확장성 및 비용 절감 방법을 제시합니다. 또한 AWS CloudFormation을 사용하여 스팟 인스턴스에 자신의 ECS 클러스터를 구축하는 방법을 보여줍니다.

스팟 인스턴스에서 실행되는 ECS 클러스터 만들기
AWS 관리 콘솔을 사용하여 ECS 클러스터를 만들 수 있습니다.

  1. https://console.aws.amazon.com/ecs/에서 Amazon ECS 콘솔을 엽니다.
  2. 탐색 창에서 클러스터를 선택하십시오.
  3. 클러스터 페이지에서 클러스터 생성을 선택하십시오.
  4. 클러스터 이름에 이름을 입력하십시오.
  5. 인스턴스 구성에서 프로비저닝 모델에 대해 스팟을 선택하십시오.

스팟 인스턴스 할당 전략 선택하기
두 가지 가능한 스팟 인스턴스 할당 전략은 다각화와 최저 가격입니다.

스팟 집합에 대해 선택한 할당 전략에 따라 가능한 스팟 인스턴스 풀에서 스팟 집합 요청이 어떻게 수행되는지가 결정됩니다. 다양한 전략을 사용하면 스팟 인스턴스가 모든 풀에 분산됩니다. 가장 낮은 가격 전략을 사용하면 스팟 인스턴스는 요청에 지정된 최저 가격의 풀에서 가져옵니다.

모든 리전의 각 가용 영역 안에 있는 각 인스턴스 유형 (각 인스턴스 패밀리 내의 인스턴스 크기, 예 : c4.4xlarge)은 별도의 용량 풀이므로 별도의 스팟 마켓입니다. 가능한 많은 인스턴스 유형과 가용 영역을 다양화함으로써 스팟 집합의 가용성을 향상시킬 수 있습니다. 또한 시간이 지남에 따라 하나의 풀에서 스팟 가격 상승에 집합이 덜 민감해지도록 됩니다.

https://d2908q01vomqb2.cloudfront.net/1b6453892473a467d07372d45eb05abc2031647a/2017/06/05/06.06-Spot-3.png

스팟 집합에 사용할 최대 6 개의 EC2 인스턴스 유형을 선택할 수 있습니다. 이 예에서는 크기가 xlarge 인 m3, m4, c3, c4, r3 및 r4 인스턴스 유형을 선택했습니다.

https://d2908q01vomqb2.cloudfront.net/1b6453892473a467d07372d45eb05abc2031647a/2017/06/05/06.06-Spot-4.png

인스턴스에 대한 입찰가를 입력해야 합니다. 일반적으로 온 디맨드 인스턴스 가격 또는 그 근처에서의 입찰은 좋은 출발점입니다. 입찰가는 해당 스팟 풀에서 인스턴스 유형에 대해 지불할 최대 가격입니다. 스팟 가격이 입찰가 또는 그 이하인 경우 스팟 가격을 지불합니다. 낮은 입찰가는 낮은 비용을 보장, 높은 입찰가는 중단 가능성을 낮춥니다.

클러스터에 포함할 인스턴스 수를 구성하십시오. 스팟 집합은 요청에 지정된 목표 용량을 충족시키는 데 필요한 스팟 인스턴스 수를 배포하려고 시도합니다. 또한 스팟 집합은 스팟 가격이나 사용 가능한 용량이 변경되어 스팟 인스턴스가 회수되는 경우 대상 용량을 유지하려고 시도합니다.

ECS–optimized AMI가 인스턴스가 배포될 때 사용됩니다.

저장소 및 네트워크 설정을 구성하십시오. 다양화 및 고 가용성을 활성화하려면 여러 가용 영역에서 서브넷을 선택해야합니다. 단일 Spot Fleet에서 동일한 가용 영역에서 여러 서브넷을 선택할 수 없습니다.

ECS 컨테이너 에이전트는 사용자를 대신하여 ECS API 작업을 호출합니다. 에이전트를 실행하는 컨테이너 인스턴스에는 에이전트가 사용자에게 속한 것을 알 수 있도록 서비스에 대한 ecsInstanceRole IAM 정책 및 롤이 필요합니다. ecsInstanceRole이 없는 경우 ECS 콘솔을 사용하여 ecsInstanceRole을 만들 수 있습니다.

스팟 집합을 사용하는 관리형 컴퓨트 환경을 만드는 경우, 스팟 집합에 인스턴스에 대한 입찰, 실행 및 종료 권한을 부여하는 롤을 만들어야 합니다. ECS 콘솔을 사용하여 롤을 만들 수도 있습니다.

여기까지입니다! ECS 콘솔에서 생성을 선택하여 스팟 인스턴스에서 실행되는 새 ECS 클러스터를 시작하십시오.

AWS CloudFormation 사용하여 스팟 인스턴스에 ECS 클러스터 배포
이제 CloudFormation 스택을 쉽게 시작하고 스팟 인스턴스에 ECS 클러스터를 배포하는 방법을 보여주는 참조 아키텍처 AWS CloudFormation 템플릿을 게시했습니다.

CloudFormation 템플릿에는 앞서 언급한 스팟 인스턴스 종료 알림 스크립트뿐만 아니라 신속한 시작을 위한 몇 가지 추가 로깅 및 기타 예제 기능이 포함되어 있습니다. Amazon EC2 스팟 인스턴스 GitHub 레포에서 CloudFormation 템플릿을 찾을 수 있습니다.

시험해보고 당신의 환경에 필요에 맞게 사용자 정의하십시오.

 

Spot Fleet Architecture 종료 처리
스팟 인스턴스를 사용하면 지정한 가격 이상을 절대 지불하지 않습니다. 스팟 가격이 주어진 인스턴스의 입찰 가격을 초과하면 자동으로 종료됩니다.

스팟 인스턴스 중단을 방지하는 가장 좋은 방법은 컨테이너 애플리케이션을 내결함성으로 설계하는 것입니다. 또한 스팟 인스턴스 종료 통지라는 기능을 활용할 수 있습니다. EC2가 스팟 인스턴스를 종료하기 2 분전에 경고를 제공합니다.

이 경고는 인스턴스 메타 데이터의 항목을 사용하여 스팟 인스턴스의 어플리케이션에서 사용할 수 있습니다. 콘솔을 사용하여 스팟 인스턴스에 ECS 클러스터를 배포하면 AWS는 5 초마다 스팟 인스턴스 종료 알림을 확인하는 스크립트를 설치합니다. 통지가 감지되면 스크립트는 컨테이너 인스턴스 상태를 드레이닝으로 즉시 업데이트합니다.

스팟 인스턴스 종료 통지 스크립트의 단순화 된 버전은 다음과 같습니다.

Bash
#!/bin/bash

while sleep 5; do
  if [ -z $(curl -Isf http://169.254.169.254/latest/meta-data/spot/termination-time) ]; then
    /bin/false
  else
    ECS_CLUSTER=$(curl -s http://localhost:51678/v1/metadata | jq .Cluster | tr -d \") CONTAINER_INSTANCE=$(curl -s http://localhost:51678/v1/metadata \ | jq .ContainerInstanceArn | tr -d \")
    aws ecs update-container-instances-state --cluster $ECS_CLUSTER \
      --container-instances $CONTAINER_INSTANCE --status DRAINING
  fi
done

컨테이너 인스턴스를 드레이닝으로 설정하면 ECS는 새 작업이 컨테이너 인스턴스에 배치되지 않도록 합니다. 리소스가 가용한 경우, 교체 서비스 작업이 클러스터의 다른 컨테이너 인스턴스에서 시작됩니다. 컨테이너 인스턴스 드레이닝을 사용하면 클러스터의 작업에 영향을 미치지 않고 클러스터에서 컨테이너 인스턴스를 제거 할 수 있습니다. PENDING 상태에 있는 컨테이너 인스턴스의 서비스 작업은 즉시 중지됩니다.

RUNNING 상태에 있는 컨테이너 인스턴스의 서비스 작업은 서비스의 배치 구성 매개 변수 minimumHealthyPercent 및 maximumPercent에 따라 중지 및 교체됩니다.

스팟 인스턴스에 ECS 실제 작동
고객들이 어떻게 이미 스팟 인스턴스 위에 ECS 클러스터를 운영하고 있는지 알고 싶습니까? Mapbox에 있는 우리 친구들이 그 일을 하고 있습니다.

Mapbox는 맞춤 지도를 디자인하고 게시하기 위한 플랫폼입니다. 이 회사는 ECS를 사용하여 전체 일괄 처리 아키텍처에 전력을 공급하여 일일 1 억 마일이 넘는 센서 데이터를 수집하고 처리하여 지도에 사용합니다. 또한 스팟 인스턴스를 사용하여 ECS에서 일괄 처리 아키텍처를 최적화합니다.

Mapbox 플랫폼은 매달 5,000 개가 넘는 앱과 2 억 명 이상의 사용자에게 서비스를 제공합니다. 백엔드는 ECS에서 실행되므로 하루 13 억 건의 요청을 처리 할 수 있습니다. 그들의 ECS 로의 최근 이전에 대한 자세한 내용을 보려면 최근 블로그 게시물, We Switched to Amazon ECS, and You Won’t Believe What Happened Next를 읽으시기 바랍니다. 그리고 후속 블로그 게시물인 Caches to Cash에서 어떻게 그들의 전체 플랫폼을 스팟 인스턴스에서 운영하면서 EC2 비용을 50-90%이상 절약할 수 있었는지 배워보세요.

결론
스팟 인스턴스를 사용하여 규모가 크고 비용 효율적으로 컨테이너 응용 프로그램을 운영하는 것에 대해 우리만큼 흥분을 느끼시길 바랍니다. 자세한 내용은 다음 페이지를 참조하십시오.

의견이나 제안이 있으시면, 의견 부탁드립니다.

Chad Schmutzer, Solutions Architect Shawn O'Conner, Enterprise Solutions Architect
Chad Schmutzer
Solutions Architect
Shawn O’Connor
Solutions Architect

원문: Powering your Amazon ECS Cluster with Amazon EC2 Spot Instances

본 글은 아마존웹서비스 코리아의 솔루션즈 아키텍트가 국내 고객을 위해 전해 드리는 AWS 활용 기술 팁을 보내드리는 코너로서, 이번 글은 이창수 솔루션즈 아키텍트께서 번역해주셨습니다.

Blox – Amazon EC2 Container Service를 위한 오픈 소스 스케줄러

2014년에 처음 출시한 Amazon ECS은 Docker 기반 애플리케이션 빌드와 실행 및 확장을 하는데 도움을 주는 서비스로서, 당시 세 가지 콘테이너 스케줄링 선택 사항 (자동, 수동, 사용자 정의) 방식을 소개하고, 어떻게 스케줄러가 각 태스크를 인스턴스에 처리하는지 설명하였습니다

사용자 정의 스케줄링은 클러스터의 현재 상태를 확인하기 위해서 ListContainerInstancesDescribeContainerInstances 함수를 계속 호출해야 합니다. 올해 초에 이러한 과정을 좀 더 간단하게 만들고, 각 클러스터의 상태를 추적하기 위해 Amazon CloudWatch Events를 추가 하였습니다. (자세한 사항은 Monitor Cluster State with Amazon ECS Event Stream 문서를 참고하세요.)

신규 이벤트 스트림 방식으로 맞춤형 스케줄러를 직접 만들 수 있습니다.

오늘 BloxOSS라는 신규 오픈 소스 소프트웨어를 공개합니다. 이 프로그램은 이벤트 스트림을 가져와서 클러스터의 상태를 추적하고, REST API로 상태를 확인할 수 있도록 해줍니다. 본 패키지에는 클러스터 내 각 콘테이너 인스턴스의 태스크를 실행할 수 있는 스케줄러 데몬을 포함하고 있습니다. 콘테이너 당 하나의 모델을 통해 로그를 처리하고 통계치를 수집하는 작업을 지원합니다.

여기에 간단한 모식도를 공유해 드립니다.

이는 오픈 소스로 제공이 되며, 외부에 계신 분들의 많은 피드백 및 코드 공헌을 기대합니다. 더 자세한 사항은 Introducing Blox From Amazon EC2 Container Service 글을 참고하시기 바랍니다.

Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 Blox OSS – New Open Source Scheduler for Amazon EC2 Container Service의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

Amazon Linux 콘테이너 이미지 신규 제공

Amazon Linux AMI는 EC2에서 실행 중인 응용 프로그램을 위한 안전하고 안정적인 고성능 실행 환경을 제공합니다. 원격 접근을 제한하며(SSH키로만 접근 가능), AMI는 뛰어난 보안을 자랑합니다.

많은 고객이 Amazon Linux 이미지를 사내에서 특히 개발 작업과 테스트 작업에서 사용하고 싶다는 요청을 하였습니다.

클라우드 뿐만 아니라 온-프레미스에서 사용에 적합한 Amazon Linux Container Image를 오늘 출시합니다. 본 이미지는 EC2 Container Registry에서 구할 수 있습니다 (자세한 것은 Pulling an Image를 참조하십시오). AMI와 같은 소스 코드 같은 패키지로 구성되어 있기 때문에 콘테이너 도입을 쉽게 실행할 수 있습니다. 그대로 사용하거나 자신의 이미지를 만들기 위한 기초로 사용할 수 있습니다.

그것을 시도 때문에 나는 방금 EC2 인스턴스를 시작하고 Docker를 설치하고 새로운 이미지를 가져 와서 실행 해 보았습니다. 그 후, cowsaylolcat(종속성)를 설치하고 위의 이미지를 만들었습니다.

자세한 내용은 Amazon Linux Container Image를 읽어 보시기 바랍니다.

본 이미지는 Amazon EC2 Container Service에서 사용할 수 있습니다. 자세한 내용은 Amazon ECR 이미지를 Using Amazon ECR Images with Amazon ECS를 참조하십시오.

Jeff;

이 글은 New Amazon Linux Container Image for Cloud and On-Premises Workloads의 한국어 번역입니다.

콘테이너를 위한 AWS 플랫폼 기능 추가

콘테이너는 강력한 기능을 제공하지만 관리상에는 도전이 많습니다. 저희 고객 역시 AWS 기반에 마이크로서비스 부터 배치 작업 까지 다양한 클라우드 업무를 위해 콘테이너를 사용하고 있으며, EC2 인스턴사 상 클러스터 관리에 대한 부담과 로드밸런싱 및 확장성, 보안 및 모니터링 등 다양한 요구사항에 대응하기 위해 Amazon EC2 Container Service를 제공하고 있습니다.

Amazon ECS는 고객들이 실제 콘테이너 기반 애플리케이션을 서비스 환경에서 운용 가능하며, 별도의 콘테이너 관리 소프트웨어 없이 서비스로 이용 가능합니다. 클러스터에 필요한 EC2 용량만 추가하고, 콘테이너 이미지만 올리면 Amazon ECS가 나머지 콘테이너 배포, 모니터링, 헬스 체크 등을 알아서 처리합니다. ExpediaRemind 같은 고객사가 ECS를 통해 개발 워크플로와 PaaS 기반의 애플리케이션을 운영하며, PreziShippable 같은 고객 역시 ECS를 통해 콘테이너 운영의 복잡성을 해결하고 애플리케이션 배포에 도움을 받고 있습니다.

Amazon ECS에서는 오늘 공개된 애플리케이션 로드 밸린서, IAM 역할 (7월), and 자동 스케일링 (5월)등의 기능을 추가해서, 콘테이너 관리에 대한 기능 확장을 지속하고 있습니다.

애플리케이션 로드밸런싱
로드밸런싱 및 서비스 디스커버리 서비스는 마이크로 서비스 아키텍처에 필수적입니다. 오늘 제공된 애플리케이션 로드밸런서는 높은 성능을 가진 콘텐츠 기반 라우팅 규칙을 정의할 수 있으며, 콘테이너를 위해 동적 포트 기능을 통해 하나의 로드밸런서로 다중 서비스를 운영할 수 있습니다. 이제 ECS 태스크 정의 시, 동적 포트를 지정하고 이를 ALB에 연동하여 사용할 수 있습니다.

이전에는 ECS 서비스와 로드밸런서가 1:1 맵핑을 해야 했으나 이제 여러개의 서비스를 공유할 수 있게 되었고, 경로 기반의 라우팅을 통해 각 서비스가 각자 URI를 정의하여 트래픽을 분산할 수 있습니다. DNS 명을 환경 변수로 만들면 주식 서비스는 http://example.com/stock로, 날씨 서비스는 http://example.com/weather로 하여 같은 로드밸런서에서 처리 가능합니다.

ECS 태스트에 대한 IAM 역할 지원
Amazon ECS에서 IAM 역할(Role)을 사용할 수 있게 됨에 따라 콘테이너로 부터 API 호출 과정을 단순화 할 수 있습니다. 즉, 여러분의 AWS 크레덴셜(ACCESS ID 및 SECRET KEY) 값을 코드나 설정 화일에 저장하지 않고 보안성을 높일 수 있습니다.

최근 업데이트 된 IAM roles for ECS tasks 기능을 통해 좀 더 안전하게 EC2 콘테이너 인스턴스에 대한 IAM 기반 접근을 가능하게 되었고, 같은 IAM 권한으로 S3나 DynamoDB 테이블 등을 접근할 수도 있습니다.

오토 스케일링 기능 지원
세번째는 서비스 오토 스케일링 지원입니다. Amazon CloudWatch 알림을 통해 ECS 서비스에 대한 확장 정책을 정할 수 있으며, 이를 통해 ECS에 사용되는 EC2 인스턴스를 확장 및 감소할 수 있습니다.

정식 사용 가능
이들 주요 콘테이너 지원 기능들은 현재 Amazon EC2 Container Service가 제공되는 모든 리전에서 오늘 부터 사용 가능합니다.

Jeff;

본 글은 Powerful AWS Platform Features, Now for Containers의 한국어 요약본으로 AWS Summit 뉴욕 행사에서 새로 발표된 소식입니다.

AWS Application Load Balancer 서비스 공개

지난 2009년 Elastic Load Balancing (ELB) 서비스를 시작하였습니다.(New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatch 참고). ELB는 AWS 기반 애플리케이션의 가장 중요한 아키텍처의 구성으로서 자동 스케일링과 함께 고가용성을 유지하면서 손쉽게 확장 및 감소를 할 수 있도록 도와 주고 있습니다.

상위 레이어 로드 밸런싱 기능 지원
잘 알려진 OSI 모델에 따르면, 로드밸런싱은 일반적으로 Layer 4 (네트워크) 또는 Layer 7 (애플리케이션)에서 처리합니다.

Layer 4 로드밸런싱은 네트워크 프로토콜 레벨에서 제공 되며, 실제 패킷을 살펴 보지는 못하기 때문에 HTTP나 HTTPS 같은 특정 프로토콜을 인지하지 않고 부하를 분산합니다.

대신 Layer 7 로드밸런싱은 좀 더 정교하고 강력한 기능을 제공합니다. 패킷을 조사하고, HTTP 및 HTTPS 헤더에 접근해서 좀 더 지능적인 부하 분산 작업이 가능합니다.

AWS Application Load Balancing 서비스 제공
오늘 ELB의 새로운 옵션인 애플리케이션 로드밸런서(Application Load Balancer)를 공개합니다. 이 서비스는 Layer 7 로드밸런싱을 통해 많은 고급 기능을 제공합니다. 기존의 로드 밸런싱 기능은 앞으로 Classic Load Balancer라고 부르게 되며, 여전히 Layer 4 및 Layer 7 기능을 제공합니다.

애플리케이션 로드밸런싱은 콘텐트 기반 라우팅 및 콘테이너 상 애플리케이션을 지원합니다. 표준 프로토콜인 WebSocket 및 HTTP/2를 지원하며, 인스턴스 및 콘테이너의 추가 가시성을 제공하게 됩니다. 콘테이너 및 EC2 인스턴스에서 실행하는 웹 사이트 및 모바일 앱에 대해 부하 분산에 대한 효과가 매우 높을 것입니다.

이제 좀 더 자세하게 애플리케이션 로드밸런싱 기능을 살펴 보겠습니다.

콘텐츠 기반 라우팅
애플리케이션 로드밸런서는 HTTP 헤더에 접근해서 다른 백엔드 서비스에 따라 다른 요청을 처리할 수 있습니다. 예를 들어, URL에 /api라는 경로를 포함하고 있는 경우, 다른 서버 그룹(일명 target group)으로 요청을 보낼 수 있으며 /mobile은 또 다른 서버 그룹으로 보낼 수 있습니다. 이를 통해 여러 개의 마이크로서비스를 독립적으로 실행하고 확장할 수 있도록 할 수 있습니다.

각 애플리케이션 로드밸린서는 10개의 URL 규칙을 만들 수 있으며, 앞으로 더 많은 라우팅 방법을 제공할 계획입니다.

콘테이너 기반 애플리케이션 지원
많은 AWS 고객들이 자사의 마이크로서비스를 콘테이너 형식으로 만들어서 Amazon EC2 Container Service를 통해 배포하고 있습니다. Amazon ECS는 하나의 EC2 인스턴스에 한 개 이상의 서비스를 배포 및 운영할 수 있습니다. 그러나, 포트 맵핑 및 헬스 체크 등에 대해 전통적인 로드밸린서로는 어려운 문제가 있습니다.

애플리케이션 로드밸린서를 통해 콘테이너 기반의 애플리케이션 역시 같은 타겟 그룹 내에 다수의 포트를 사용할 수 있으며, 세부적인 포트 수준의 헬스 체크를 지원할 수 있게 되었습니다.

더 자세한 통계 수치 제공
애플리케이션 로드밸린서는 포트 기반의 헬스 체크에 대한 리포트를 실행할 수 있어, HTTP 응답에 대한 범위를 정의할 수 있고 자세한 오류 코드에 대한 부분도 확인할 수 있습니다.

콘텐츠 기반의 라우팅을 제공함으로서 각 마이크로서비스의 다양한 통계 수치도 얻어낼 수 있습니다. 이는 마이크로서비스 기반에서 운영하는 타겟 그룹 또는 특정 EC2 인스턴스 그룹에 대한 유효한 부수 효과입니다. 개별 서비스에 대한 부하에 대해 좀 더 자세히 살펴 볼 수 있음으로서 확장성에 대한 도움을 얻을 수 있습니다.

애플리케이션 로드밸린서는 CloudWatch에서 전체 트래픽 (overall traffic in GB), 액티브 연결 갯수, 시간당 연결 비율 등의 새로운 통계 수치를 제공합니다.

추가 프로토콜 지원
애플리케이션 로드밸린서는 WebSocketHTTP/2를 지원합니다.

WebSocket은 클라이언트와 서버간 긴 TCP 연결을 제공하는 프로토콜로서, 긴 연결이 필요할 경우 기존의 HTTP 연결을 통해 하던 고전적인 풀링 방식을 개선할 수 있습니다. 모바일 앱의 경우, 주식 가격이나 스포츠 경기 점수 등 다양한 동적 데이터를 서로 주고 받을 때 유용하며 ALB는 ws://wss:// 프로토콜을 지원합니다.

HTTP/2 역시 기존 HTTP 1.1에 비해 중요한 기능 향상을 가진 프로토콜로서 단일 연결에 멀티플렉스 요청을 처리할 수 있고, 바이너리 속성을 통한 네트웍 트래픽을 줄여줍니다.

애플리케이션 로드밸린서는 실시간 스트리밍 뿐만 아니라 WebSocket 로드를 최적으로 처리 가능합니다. 요청 및 응답에 대한 버퍼링 대신 스트리밍 방식으로 처리함으로서 지연 속도를 줄이고 애플리케이션의 성능을 눈에 띄게 높일 수 있습니다.

ALB 생성하기
이제 애플리케이션 로드밸린서를 만들어서 트래픽을 처리해 보겠습니다.

The Elastic Load Balancing Console에 두 가지 중 하나의 로드밸린서를 선택할 수 있습니다.

Application load balancer을 선택하고 이름(MyALB)을 넣고 internet-facing를 선택 후, HTTPS listener를 추가합니다.

같은 화면에서 VPC를 선택하고 (VPC만 지원함), 원하는 가용 영역과 서브넷을 선택합니다. 애플리케이션 로드밸린서를 태그하고 Configure Security Settings 설정으로 갑니다.

HTTPS listener를 선택했기 때문에 ALB는 인증서가 필요합니다. IAM에 있는 기존 인증서를 선택하거나, AWS Certificate Manager (ACM)에서 발급 받거나 또는 로컬 인증서를 업로드할 수 있습니다.

오른쪽에서 보안 그룹을 설정합니다. 새로운 보안 그룹을 만들었으나 기존 VPC나 EC2 보안 그룹을 사용하실 수도 있습니다.

다음 단계로 타겟 그룹(main)을 만들고, 헬스 체크를 기본으로 체크합니다.

이제 타겟그룹의 EC2 인스턴스 세트를 선택하여 애플리케이션 로드밸린서를 통해 분산할 80포트를 선택합니다.

마지막 단계로 모든 설정을 확인 한후 Create를 누르면 됩니다.

Create 누르고 나면, 애플리케이션 로드밸린서가 수 분 안에 만들어집니다.

추가 타겟 그룹을 만들 수도 있습니다.

각 타겟 그룹에 원하는 경로, 즉 /api 호출을 보낼 수 있습니다.

애플리케이션 로드밸린서는 Auto Scaling, Amazon ECS, AWS CloudFormation, AWS CodeDeployAWS Certificate Manager (ACM) 서비스와 연동해서 사용할 수 있습니다.

신규 로드밸런서로 이전하기
현재 기존 로드밸런서를 사용하고 있으시고, 애플리케이션 로드밸린서로 옮기고 싶으시다면, Load Balancer Copy Utility를 활욜하시기 바랍니다. 기존 설정을 그대로 애플리케이션 로드밸린서에 맞게 옮겨주는 Python 기반의 도그로서 기존 EC2 인스턴스를 신규 로드밸런서로 등록하는 기능도 있습니다.

가용성 및 가격
애플리케이션 로드밸린서는 모든 AWS 리전에서 오늘 부터 사용가능합니다. ALB의 시간당 사용 비용은 기존 로드밸런서 보다 10% 낮습니다.

ALB를 사용하시면 로드밸런서 용량 단위(LCU)를 기반으로 시간당 과금하게 되며, LCU는 초당 연결 갯수, 활성 연결수, 및 데이터 전송량 등을 측정하게 됩니다. 이 세 가지 측면의 데이터를 기반으로 비용이 결정됩니다. 하나의 LCU는 다음 중 하나를 선택합니다.

  • 25 초당 연결 수 (2 KB 인증서, 3,000 활성 연결 수, 2.22 Mbps 데이터 전송량) 혹은
  • 5 초당 연결 수 (4 KB 인증서, 3,000 활성 연결 수, 2.22 Mbps 데이터 전송량

시간당 1 LCU에 대해 0.008 달러가 과금되며, 저희의 계산에 따르면 모든 고객들이 기존 로드밸런서에서 ALB로 이전할 경우 기본적으로 총 비용이 감소할 것으로 생각합니다. 지금 부터 한번 활용해 보시기 바랍니다.

Jeff;

본 글은 New – AWS Application Load Balancer의 한국어 번역본으로 AWS Summit 뉴욕 행사의 신규 발표 소식입니다.

EC2 Container Registry 정식 출시

Andrew Thomas가 신규 EC2 Container Registry 출시 소식을 전해 주였습니다. 아래에서 자세하게 소개해 드리고자 합니다.

— Jeff;


Amazon EC2 Container Registry (ECR)가 오늘 일반 이용이 가능하게 되었음을 알려 수 있어 매우 기쁘게 생각합니다. Amazon ECR는 관리형 Docker 컨테이너 레지스트리로서 개발자는 Docker 컨테이너 이미지를 쉽게 저장하고 관리하고 배포할 수 있습니다. 지난 AWS re:Invent 사전 공지한 후, 많은 개발자로부터 관심을 받아 왔습니다.

Amazon ECR을 개발 한 이유는 많은 고객분들이 자신의 개인 Docker 이미지 레지스트리를 만들고, 이를 손쉽게 관리하면서 한 번에 수백개 이미지 보내는(Pull) 대규모 배포를 해야 등 많은 과제를 가지고 있기 때문입니다. 셀프 호스트라고 불리는 방식은 두 개 이상의 AWS 리전에 걸쳐 클러스터에 컨테이너 이미지를 배포하는 것이 특히 어렵습니다. 또한, 인증서 및 인증 정보를 관리하지 않아도 저장소 및 이미지 접근을 제어해야 합니다.

Amazon ECR은 이러한 모든 요구 사항에 맞게 있도록 설계되었습니다. 또한, 콘테이너 레지스트리의 인프라에 대한 설치 및 운영을 할 필요가 없습니다. Amazon ECR은 고객의 이미지를 높은 가용성과 확장 가능한 구조로 저장하고 앱플리케이션 컨테이너로 안정 배포 할 수 있도록 합니다. 또한, Amazon ECR은 매우 안전합니다. 각 이미지는 HTTPS에서 암호화 된 레지스트리 경로로 전송되며, 자동으로 암호화되어 S3에 저장됩니다. AWS Identity and Access Management (IAM) 사용자 및 역할을 활용하여, EC2 인스턴스에서 직접 인증 정보를 관리 할 필요도 없고, 권한 관리 정책과 이미지에 대한 접근 제어를 설정 할 수 있습니다. 이에 따라 특정 사용자 및 AWS 계정과 이미지를 공유 할 수 있습니다.

Amazon EC2 Container Registry는 Amazon ECS와 Docker CLI를 기반으로 하고 있기 때문에 개발 및 워크 플로우를 간소화 할 수 있습니다. 개발자 PC에서 Docker CLI를 사용하여 Amazon ECR에 컨테이너 이미지를 쉽게 가져올(push) 수도 있고 Amazon ECS에서 직접 보낼(pull) 수 있습니다.

이제 Amazon ECR과 Amazon ECS를 사용하여 Docker 컨테이너 저장, 관리, 배포가 얼마나 쉽게 할 수 있는지를 살펴 봅시다.

Amazon ECR 관리 콘솔
Amazon ECR 콘솔에서는 이미지 관리 및 저장소의 권한 설정을 쉽게 할 수 있습니다. 콘솔에 액세스하려면 Amazon ECS 콘솔 안에 있는 “Repositories”섹션을 클릭합니다. 여기에서는 예로 간단한 PHP 컨테이너 이미지를 Amazon ECR에 push하고 권한을 설정하고 Amazon ECS 클러스터에 이미지를 배포 해 봅니다.

Amazon ECR 콘솔에서 “Get Started”를 선택합니다. 다음과 같이 간단한 마법사에서 저장소를 만들고 구성 할 수 있습니다.

저장소 이름을 입력하면 Amazon ECR에 접근할 때 사용하는 엔드 포인트 URL을 볼 수 있습니다. 기본적으로 저장소에 대한 접근 권한을 가지고 있기 때문에 나중에 ECR 콘솔에서 설정할 수 있습니다.

Next step을 클릭하면 지금 만든 저장소에 Docker 이미지를 터미널에서 빌드(build)하고 전달(push)하는 데 필요한 명령을 볼 수 있습니다. Dockerfile은 ECS Docker basics tutorial에 있는 샘플을 사용할 수 있습니다. 여기 있는 명령은 AWS Command Line Interface (CLI)Docker CLI를 개발 PC에 설치했는지 여부가 필요합니다. 그런 다음, 각 명령을 복사하여 실행합니다. 즉, login 및 ECR URI에서 이미지에 tag를 붙여 리포지터리에 이미지를 보내는(push) 명령 실행이 가능합니다.

이 단계가 완료되면 Done을​​ 이미지를 관리할 저장소의 화면으로 이동합니다.

레지스트리 권한 설정
Amazon ECR은 AWS Identity and Access Management를 사용하여 누가 어떤 컨테이너 이미지에 접근할 수 있는지를 제어하고 감시할 수 있습니다. 또한, Amazon ECR 콘솔에서 저장소에 대한 자원 기반 정책을 쉽게 만들 수 있도록 권한 도구를 개발했습니다.

이 도구를 사용하려면 저장소 페이지에서 Permissions 탭을 클릭하고 Add를 선택합니다. 그러면, IAM에 대응한 양식 필드가 나옵니다. ID를 입력 한 후, 명시적으로 접근 거부 또는 허용 여부를 선택합니다. 그리고, AWS 계정 번호를 입력하거나 엔티티 테이블의 사용자 및 역할을 선택하여 누가 이를 실행할 지 설정할 수 있습니다.

필요한 엔티티를 선택한 후 접근 정책을 설정할 수 있습니다. 여기에서 왼쪽 토글을 사용하여 push/pull, 그리고 관리자 권한을 위해 필요한 조치를 쉽게 선택할 수 있습니다.

Amazon ECS와의 연계
레포지토리를 생성하고 이미지를 푸시(push)하고 권한을 설정 하면, ECS에 이미지를 배포 할 준비가 되었습니다.

ECS 콘솔에서 Task Definitions를 선택하고 새로운 Task Definition 작성 페이지에서 Image 필드에 Amazon ECR 저장소를 지정합니다. Task Definition을 설정하면, 콘솔 Clusters 페이지에 Task Definition을 위한 새로운 Service를 만듭니다. Service를 만들면 ECS Agent가 자동으로 ECR에서 이미지를 가져오고 실행합니다.

First-Run 업데이트
Amazon ECS 마법사를 통해 Amazon ECR에서 자신의 이미지를 ECS에 배포 할 수 있도록 업데이트했습니다.

ECS 파트너 지원
re:Invent에서 ECS에 컨테이너 배포 자동화를 도와주는 다수의 지속적 통합(CI) 및 배포(CD) 서비스 개발사와 제휴를 발표했습니다. 이제 AWS 파트너 역시 Amazon ECR 지원을 시작하여, 이미지를 AWS에서 자동으로 빌드, 저장 및 배포하기 위한 엔드 포인트간 컨테이너 파이프 라인을 쉽게 개발자가 만들고 작동할 수 있습니다. Shippable, Codeship, Solano Labs, CloudBeesCircleCI 솔루션을 확인해보십시오.

또한, ECR에 저장된 이미지의 취약점 탐색을 위해 TwistLock와 파트너십을 발표합니다. 이를 통해 개발자는 Amazon ECR에 푸시하기 전에 다양한 보안 위협을 보다 쉽게​​ 평가할 수 있고, 정식 서비스 환경에서 실행되는 컨테이너를 모니터링 할 수 있습니다. 우리의 파트너십에 대한 자세한 정보는 Container Partners Page를 참조하십시오.

서비스 가능 리전 및 가격
Amazon ECR은 오늘부터 US East (Northern Virginia)에서 사용 가능합니다. Amazon ECR 이미지가 사용하고 있는 스토리지 및 Amazon ECR에서 인터넷이나 다른 리전으로 데이터 전송 요금 만 부과됩니다. 자세한 내용은 ECR Pricing를 참조하십시오.

Amazon ECR에 대한 더 자세한 사항은 Getting Started with EC2 Container Registry 문서를 참고하시기 바랍니다.

Andrew Thomas, Senior Product Manager

이 글은 EC2 Container Registry – Now Generally Available 한국어 번역입니다.