Category: EC2 Container Service


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 한국어 번역입니다.

EC2 Container Service 신규 기능 – 콘테이너 레지스트리, ECS CLI, AZ-인식 스케줄링 등

최근 도커(Docker)를 기반한 콘테이너 기반 배포 모델이 빠르게 자리잡아 가면서 더 빠른 앱 빌드, 실행 및 업데이트 및 확장을 선호해 가고 있다는 점은 고무적입니다. 작년에 Amazon EC2 Container Service(ECS)를 공개한 이후 많은 고객들이 이를 실제로 적용하여 마이크로서비스(Microservices) 기반 웹 애플리케이션 개발과 일괄 처리 업무 등에 활용 중입니다.

많은 개발자들은 콘테이너를 통해 개발, 테스트 및 배포에 드는 작업 속도를 높힐 수 있다고 이야기합니다. 특히 개별 콘테이터들이 “표준” 개발 환경을 가지고 있기에 다양한 프로그래밍 언어, 프레임웍 및 미들웨어의 조합을 만들 수 있으며, 이러한 자유도 높은 격리 방식을 통해 전체 시스템을 하나로 만들어 큰 변경에 따른 위험 부담을 줄여 더욱 혁신을 이룰 수 있게 되기 때문입니다.

그동안 Amazon ECS와 도커 사용자로 부터 받은 다양한 피드백을 바탕으로 오늘 새로운 기능 몇 가지를 공개합니다. 바로 Amazon EC2 Container Registry(콘테이너 레지스트리), Amazon EC2 Container Service CLI(ECS CLI)입니다. 또한 Amazon ECS 스케줄러를 통해 가용 영역(Availablity Zones) 인식 및 신규 콘테이너 옵션 몇 가지를 추가 합니다.

한번 같이 살펴 보도록 하겠습니다.

Amazon EC2 Container Registry(콘테이너 레지스트리)
도커 또는 ECS 역시 가상 이미지라는 개념에서 시작합니다. 콘테이너를 실행할 때, 이러한 가상 이미지를 참고하고 이를 Docker Registry라는 저장소에서 가져옵니다. 레지스트리는 배포 과정에서 매우 중요한 부분입니다. 고객들과의 대화를 통해 우리는 레지스트리 자체가 매우 높은 가용성과 확장성 및 여러 리전을 지원하는 글로벌 접근 가능한 시스템으로 만들어져야할 필요가 있다고 배웠습니다. 또한, AWS Indentity and Access Management(IAM) 서비스와 연동하여 보다 세부적인 제어를 위한 인증도 필요합니다.

고객들의 이러한 요구사항에 맞추어 직접 레지스트리를 운영하다 보니 피해도 되는 관리 부담이 들게 되었습니다.

이에 저희는 Amazon EC2 Container Registry(Amazon ECR)를 공개합니다. 이전의 콘테이너 이미지의 저장 및 관리 배포 등의 운영 부담을 줄일 수 있는 관리형 서비스입니다.

Amazon ECR은 ECS를 통해 여러분의 프로덕션 워크플로와 쉽게 통합할 수 있습니다. 여러분의 개발 PC에서 도커 CLI를 통해 Amazon ECR로 콘테이너 이미지를 등록할 수 있고, Amazon ECS에서 배포 과정에서 가져올 수도 있습니다.

콘테이너 이미지를 S3에 저장하고, IAM 사용자의 역할을 기반으로 접근 제어와 함께 전환 과정에서 암호화도 지원 합니다. 여러분은 인터넷을 통해 전송되는 데이터와 저장하는 데이터에만 신경 쓰시면 됩니다.

아래는 관리 콘솔에서의 몇 가지 스크린샷입니다.

등록 페이지에서 방문하여 초기 접근을 위해 등록을 하실 수 있습니다. 이 프로그램에 관심이 있으시면 오늘 바로 하실 수 있습니다.

이를 함께 작업한 여러 파트너도 있습니다. Shippable, CloudBees, CodeShipWercker 등의 협력사와 Amazon ECS와 ECR의 통합 및 자동 빌드, 도커 이미지 배포 등을 제공합니다. 더 자세한 사항은 콘테이너 파트너 페이지를 참고하세요.

Amazon ECS CLI
ECS 커맨드라인 인터페이스(CLI)는 Amazon ECS를 위해 만들어진 것으로 로컬 개발 환경에서 클러스터, 태스크를 생성하거나 업데이트 및 모니터링 할 수 있도록 하는 간편한 명령어입니다.

Amazon ECS CLI는 Docker Compose를 지원하는데, 이 프로그램은 멀티 콘테이너 애플리케이션을 정의하고 실행하는 인기 높은 오픈 소스 도구입니다. 매일 일어나는 개발 및 테스트 주기에서 AWS 관리 콘솔이 아닌 새로운 간편한 방식입니다.

ECS CLI를 몇 분안에 사용해 보실 수 있습니다. 사용 가이드를 기반으로 다운로드 해서 설치만 하면 되며, 클러스터 설정의 경우 아래와 같이 간단한 샘플 명령어를 사용할 수 있습니다.

$ ecs-cli configure --region us-east-1 --cluster my-cluster

클러스터 실행을 다음과 같습니다.

$ ecs-cli up --keypair my-keys --capability-iam --size 2

Docker Compose는 설정 파일이 필요합니다. 아래는 간단한 docker-compose.yml 파일입니다.

web:
  image: amazon/amazon-ecs-sample
  ports:
  - "80:80"

이제 클러스터를 실행해 봅니다.

$ ecs-cli compose up
INFO[0000] Found task definition TaskDefinition=arn:aws:ecs:us-east-1:980116778723:task-definition/ecscompose-bin:1
INFO[0000] Started task with id:arn:aws:ecs:us-east-1:9801167:task/fd8d5a69-87c5-46a4-80b6-51918092e600

실행 중인 태스크가 있는지도 한번 살펴봅니다.

$ ecs-cli compose ps
Name                                      State    Ports
fd8d5a69-87c5-46a4-80b6-51918092e600/web  RUNNING  54.209.244.64:80->80/tcp

위에 지정된 주소에서 여러분의 샘플 앱이 돌아가고 있는지 확인해 보시면 됩니다.

ECS CLI는 여러 옵션을 지원합니다. (전체를 보시려면 -help를 해보세요.) 예를 들어, 장기 실행 서비스도 만들어 관리 가능합니다. 아래는 옵션 목록입니다.

ECS CLI는 Apache 2.0 라이선스 기반의 오픈 소스로 https://github.com/aws/amazon-ecs-cli에서 받을 수 있으며, 여러분의 풀 리퀘스트(Pull Request)도 기다립니다.

도커 콘테이너 신규 설정 옵션
태스크 정의(task definition)은 애플리케이션 정보입니다. 이를 통해 콘테이너를 정의하고 언제 어떤 EC2 인스턴스에 배포할 것인가를 정의할 수 있습니다. 몇 가지 파리미터를 통해 이러한 태스크 정의를 할 수 있는데, 사용할 도커 이미지, 각 콘테이너가 사용할 CPU 및 메모리 용량 및 호스트 콘테이너와 매핑할 포트 등입니다.

뿐만 아니라 도커 라벨, 작업 디렉토리, 네트워크 사용 여부, 실행 권한, 읽기 전용 루트 파일 시스템, DNS 서버 및 DNS 검색 도메인, 로그 설정 및 (/etc/hosts에 넣을) 추가 호스트, SELinux 등에서 지원하는 멀티 레벨 보안(Multi-Level Security) 등 보안 옵션도 있습니다.

ECS 콘솔 내부에 이러한 태스크 정의 편집기를를 통해 업데이트하거나 새로운 설정을 입력할 수 있습니다.

더 자세한 사항은 태스크 정의 파라미터 문서를 참고하시기 바랍니다.

가용 영역 인식 스케줄링 지원
장기 실행 서비스 및 애플리케이션을 위한 콘테이너의 스케줄링을 위해 올해 초 Amazon ECS Service Scheduler를 소개하였습니다. 서비스 스케줄러는 Elastic Load Balacing과 선택저그로 통합할 수 있습니다. 이를 통해 특정 숫자의 태스크를 항상 실행할 수 있고, 이게 실패하면 태스크를 재시작합니다. 고객들이 ECS를 프로덕션 환경에서 서비스를 할 수 있는 주요한 기능이고, 계속적으로 좀 더 쉽게 지원을 계속하려고 합니다.

오늘 부터 서비스 스케줄러는 가용영역을 인식합니다. 즉, 새 태스크를 실행하면 서비스 스케줄러가 태스크를 AWS의 다중 가용영역 기반으로 서비스 부하 분산을 하게 됩니다.

re:Invent Amazon ECS 배우기
여러분이 re:Invent 현장에 계시다면 여러분의 (경쟁자가 아닌) 동료들이 어떻게 콘테이너 기반 컴퓨팅 서비스를 만들고 운영하는지 그 노하우를 배우실 수 있습니다. 아래 세션들을 참고해 보시기 바랍니다.

  • CMP302 – Amazon EC2 Container Service: Distributed Applications at Scale (생중계 예정)
  • CMP406 – Amazon ECS at Coursera.
  • DVO305 – Turbocharge Your Continuous Deployment Pipeline with Containers.
  • DVO308 – Docker & ECS in Production: How We Migrated Our Infrastructure from Heroku to AWS.
  • DVO313 – Building Next-Generation Applications with Amazon ECS.
  • DVO317 – From Local Docker Development to Production Deployments.

— Jeff;

이 글은 EC2 Container Service Update – Container Registry, ECS CLI, AZ-Aware Scheduling, and More의 한국어 번역이며, re:Invent 2015의 신규 서비스 소식입니다.