Category: Amazon EC2 Container Service*


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의 신규 서비스 소식입니다.

EC2 Container Service 신규 측정 기능: Clusters 및 Services 용

Amazon EC2 Container Service는 Docker 기반 응용 프로그램을 실행하고 관리하는 것을 도와주는 서비스입니다. EC2 Container Service – 최신 기능, 사례 및 관련 자료 총정리에서 보여 드린 대로 손쉬운 클러스터 관리 및 높은 성능, 유연한 스케줄링, 확장성, 이동성과 아울러 안전하고 효율적인 환경에서 AWS와의 연계가 가능한 장점을 가지고 있습니다.

콘테이너 기반 응용 프로그램은 Task에서 만들어집니다. Task는 같은 EC2 인스턴스에서 함께 실행되는 한 개 이상의 Docker 콘테이너입니다.각 인스턴스는 클러스터로 그룹이 됩니다. 그래서 인스턴스는 Task를 수행하기 위해 이용되는 리소스 풀과 같은 형태를 취합니다.

이러한 모델은 모니터링 및 측정에 대한 여러가지 이슈가 발생합니다. 클러스터를 너무 크지도 작지도 않은 적절한 크기로 유지하기 위해 별도의 인스턴스 보다는 클러스터 전체의 메모리와 CPU 사용율을 봐야 하기 때문입니다. 특히, 다양한 CPU와 메모리의 크기를 가진 EC2 인스턴스가 포함 된 클러스터에서 쉽지 않은 일입니다.

신규 Cluster 측정 기능
이를 위해서 클러스터의 자원을 제대로 측정하고 이를 기반으로 확장할 수 있도록 각 인스턴스의 크기 및 콘테이너의 설정을 기준으로 만들어진 Amazon CloudWatch 측정 기준과 모니터링을 시작합니다. AWS ECS 관리 콘솔에서 측정치를 볼 수 있으며 이를 기반으로 Auto Scaling을 할 수 있습니다.

각 인스턴스에는 ECS Container Agent가 실행되고 있습니다. 이를 통해 인스턴스 및 Task의 CPU 및 메모리 측정값을 수집하고 정규화를 위해 데이터를 보냅니다. 정규화 작업은 클러스터 전체의 CPU 및 메모리 사용을 표현하기 위한 통계가 생성됩니다. 이러한 통계치에 따라 전체 클러스터의 활용 상황을 파악할 수 있습니다.

간단하게 살펴보겠습니다. default라는 이름의 클러스터 아래 하나의 t2.medium 인스턴스를 가지고 있습니다.

이 시점에서 Task가 실행되지 않고 클러스터는 유휴(idle) 상태입니다.

전체 CPU를 소비하게 끔 2개의 Task를 실행했습니다.:

Task가 CPU를 소비하기 까지조금 시간이 조금 걸립니다. 이제 CPU 사용율은 아래와 같이 되었습니다.

그래서 또 다른 t2.medium 인스턴스를 클러스터에 집어 넣고 활용도를 다시 확인 보았습니다. 추가된 용량에 따라 전체 이용률은 50 %로 감소했습니다.

새로운 측정치(CPUUtilizationMemoryUtilization)는 CloudWatch를 통해 이용 가능하며, 알림을 만드는 데 사용할 수 있습니다.

신규 Service 측정치
올해 초반에 EC2 Container Service를 부하 분산을 통한 애플리케이션 본격 사용에 대해 발표하였습니다. Service 스케줄러를 통해 우리가 원하는 수준에 맞게 확장 가능하고 높은 품질의 유지 관리가 가능합니다. CPU 및 메모리 사용률 통계가 서비스마다 수집 되어 콘솔에서 볼 수 있습니다.

오늘부터 새로운 Cluster와 Service의 통계 모니터링은 바로 활용해 보실 수 있습니다.

Jeff;

이 글은 New Metrics for EC2 Container Service: Clusters & Services의 한국어 번역본입니다.

AWS OpsWorks 업데이트- ECS Container 인스턴스 및 RHEL 7 지원

AWS OpsWorks는 다양한 형태 및 크기의 응용 프로그램을 쉽게 배포 할 수 있습니다. AWS OpsWorks를 사용하면 리소스 프로비저닝, EBS 볼륨 설정, 구성 관리, 애플리케이션 배포, 모니터링 및 접근 제어를 포함한 전체 애플리케이션 라이프 사이클에 대한 통합 관리가 가능합니다. (자세한 내용은 AWS OpsWorks – Flexible Application Management in the Cloud Using Chef를 참조하십시오.)

Amazon EC2 Container Service 는 Docker 콘테이너를 지원하고 Amazon Elastic Compute Cloud (EC2) 관리 클러스터에서 응용 프로그램을 쉽게 작동시킬 수 있는 확장성 높은 콘테이너 관리 서비스입니다. (자세한 내용은 AWS OpsWorks – Flexible Application Management in the Cloud Using Chef를 참조하십시오.)

ECS 및 RHEL 지원

AWS OpsWorks는 ECS Container 인스턴스에 대한 지원을 추가합니다. Ubuntu 14.04 LTS 또는 Amazon Linux 2015.03 AMI에서 작동되는 ECS Container 인스턴스를 프로비저닝하고 관리 할 수 있습니다.

또한, Red Hat Enterprise Linux (RHEL) 7.1 지원을 추가했습니다.

이 기능을 더 자세히 살펴 보겠습니다!

ECS Container 인스턴스 지원
새로운 ECS Cluster레이어를 사용하면 쉽게 ECS Container 인스턴스를 프로비저닝하고 구성 할 수 있습니다. 간단하게 레이어를 생성하고 (기존에 만든) 클러스터 이름과 인스턴스 유형을 지정하여 EBS 볼륨을 연결하면 준비가 완료됩니다. 인스턴스는 Docker, ECS 에이전트 OpsWOrks 에이전트와 함께 프로비저닝되고 ECS 클러스터 레이어와 관련된 ECS 클러스터에 함께 등록됩니다.

아래와 같이 간단히 시작할 수 있습니다. 새 레이어를 추가하여 ECS Cluster Layer 유형을 선택합니다:

클러스터 및 프로파일을 선택합니다.

다음 단계는 클러스터에 인스턴스를 추가하는 것입니다. 인스턴스마다 몇 번 클릭하기만 하면 됩니다.

일반적으로 OpsWorks에서 사용하는 경우와 마찬가지로 인스턴스는 처음에는 stopped 상태가 되어 있습니다, 그리고 Start All Instances를 클릭하여 시작할 수 있습니다.(혹은 개별 인스턴스를 시작할 수 있습니다.)

인스턴스가 시작되면 그 위에 Chef 레시피를 실행할 수 있습니다. 또한 클러스터의 인스턴스에서 운영 체제 (Linux 전용)을 설치 및 패키지 업데이트 할 수 있습니다. (자세한 내용은 Run AWS OpsWorks Stack Commands을 참조하십시오.) 마지막으로, 간단한 JSON 래퍼(Wrapper)에 쉘 명령을 넣어 실행하는 방법은 Using OpsWorks to Perform Operational Tasks를 참조하십시오.

더 자세한 내용은 OpsWorks User Guide를 참조하십시오. OpsWorks에서 프로비저닝되는 콘테이너 인스턴스에 대한 ECS 작업을 수행하는 방법은 ECS Getting Started Guide를 참조하십시오.

RHEL 7.1 지원
OpsWorks는 RedHat Enterprise Linux (RHEL) 7.1을 지원합니다. 올해 OpsWorks 윈도우 지원을 알려드렸을 때처럼 많은 AWS 고객들이 레드햇 OS를 지원하해달라는 요청이 있었고, 이를 지원하게 되었습니다. 이제 RHEL 7을 실행하는 EC2 인스턴스를 시작 및 관리 할 수​​ 있습니다. 또한, 기존의 RHEL 7을 실행하는 온-프레미스 인스턴스를 관리 할 수 있습니다.

여기 가지 부팅 옵션이 있습니다. 새로운 스택을 만들 때 기본적으로 RHEL 7을 선택 할 수 있고 기존 스택에 기본으로 설정할 수 있습니다. 또한, 기본 설정은 그대로 보존하여 새 인스턴스를 시작할 때 RHEL 7을 선택할 수 있습니다. 여기에서는 새로운 스택을 만들 때 기본적으로 RHEL 7을 선택하는 방법을 소개합니다.

이미 알고 계시겠지만, 적은 금액으로 OpsWorks에서 실행하지 않은 인스턴스를 관리할 수 있습니다. OpsWorks를 사용하면 다양한 모니터링 및 관리 도구를 사용할 수 있는 혜택을 누릴 수 있으며, 간편한 사용자 인터페이스를 사용하여 모든 인스턴스를 관리 할 수​​ 있습니다. 이를 위해, 새 인스턴스를 시작하는 것이 아니라 기존 인스턴스를 등록하여 레이어에 인스턴스를 추가 할 수 있습니다.

마법사를 사용하여 마지막 단계에 OpsWorks 에이전트를 설치하는 방법과 OpsWorks에 등록하는 방법이 표시됩니다.

위의 명령어를 실행하면 에이전트를 다운로드하여 필요한 패키지를 설치하고 에이전트를 시작합니다. 에이전트가 자신을 OpsWorks에 등록하고, 인스턴스가 명령 라인에서 지정한 스택에 포함 됩니다. 이 시점에서 그 인스턴스는 스택 내 일부로 등록되지만 레이어는 아직 할당되지 않고, 또한 아직 어떤 설정도 구성되어 있지 않습니다. OpsWorks 사용자 관리 기능을 사용하여 사용자를 생성, 권한 관리, 필요한 경우 SSH 액세스를 제공 할 수 있습니다.

에이전트를 설치하면 1분 간격으로 CloudWatch 메트릭이 설정됩니다.

인스턴스를 설정하고 모니터링하고 있는지 확인 후, 레이어에 할당 할 수 있습니다.

바로 사용 가능
오늘 부터 위의 설명한 기능을 사용할 수 있습니다.

Jeff;

PS – Special thanks are due to my colleagues Mark Rambow and Cyrus Amiri for their help with this post.

이 글은 AWS OpsWorks Update – Provision & Manage ECS Container Instances; Run RHEL 7의 한국어 번역입니다.

EC2 Container Service – 최신 기능, 사례 및 관련 자료 총정리

작년 가을 re:Invent에서 처음 소개한 Amazon EC2 Container Service는 올해 4월에 정식 출시하였습니다. 그동안 많은 개선을 해왔기 때문에 이를 돌아보는 시점이 된 것 같습니다. 많은 AWS 고객은 이미 EC2 Container Service를 이미 잘 사용하고 있고, 그 속에서 어떤 이야기가 있었는지 공유하고 싶습니다. 고객들은 직접 클러스터를 구축해서 확장성이나 성능 및 관리를 하지 않아도 유연한 콘테이너 서비스를 만들 수 있게 되었다는 피드백이 많았습니다.

최신 기능

우리는 매우 많은 피드백 및 기능 요청을 받아 왔고 트윗, 이메일, Amazon ECS 포럼 및 블로그 글과 개발자 모임 등에서 무엇을 필요로 하고 계신지를 계속 전해 받았습니다. 여러분의 피드백과 의견 모두가 훌륭한 것이라고 생각하고 최대한 이해한 후, 로드맵에 반영 해 나가고 있습니다. 다음은 2015 상반기 로드맵으로 발표 해 온 것입니다.

고객 사례

Amaxon EC2 Container Service 사용하고 있는 많은 고객들은 규모 있는 클러스터에서 실전 애플리케이션을 직접 운영하고 있습니다. 아래는 몇 가지 사례들입니다.

  • Coursera는 ECS를 통해 대규모 일괄 작업을 실행하고 있습니다. 2 개월 만에 프로토 타입을 만들어 가동 하여 몇 시간씩 걸리던 소프트웨어 변경을 지금은 몇 분 안에 배포하고, 동적 부하에 맞게 확장 할 수 있게 되었습니다 . 더 자세한 정보는 Coursera Case Study를 참고하시기 바랍니다.
  • Remind는 EC2 Container Service를 사용하여 Empire PaaS를 AWS에서 구동하고 있습니다. Docker 컨테이너를 사용하여 종속성을 격리하여, 개발 환경 생산성을 향상 시키고 운영 부분의 수를 제한 할 수 있으며, 전체 자원 활용도를 높이고 있습니다. 더 자세한 정보는 Introducing Empire : A Self-hosted PaaS Build on Docker and Amazon ECS를 참고하시기 바랍니다.
  • Hailo는 Hailo 택시 호출 스마트 폰 앱을 AWS에서 서비스하고 있으며, 마이크로서비스(microservice) 기반 아키텍처를 위한 클러스터 관리의 방식으로 EC2 Container Service를 이용하고 있습니다. 서비스의 우선 순위 및 리스소 풀의 높은 자원 활용을 유지하기 위한 통계 수치를 기반한 맞춤형 스케줄링에 활용하고 있습니다. 더 자세한 정보는 Microservices and Elastic Resource Pools with Amazon EC2 Container Service를 참고하시기 바랍니다.

개발자 커뮤니티
아래는 몇 가지 개발자 커뮤니티 활동 및 이벤트에 대한 정보입니다.

  • DockerCon – Deepak Singh는 Docker ComposeDocker Swarm를 이용하여 응용 프로그램의 클러스터를 데스크톱에서 AWS 클라우드에 확장시키는 기능을 발표하였습니다.
  • 오픈 소스 – 소프트웨어 컨테이너에 대한 공통 사양을 만들기 위한 Open Container Project 참여하기로 하였습니다. ECS Container Agent 는 GitHub에서 여러분의 참여(pull request)를 언제나 기다리고 있습니다.

더 자세한 정보
Amazon ECS와 함께 Docker에 대해 더 자세히 알고 싶은 경우 참고하시기 바랍니다.

여러분의 피드백을 언제나 기다립니다.

– Jeff;

이 글은 의 한국어 번역입니다. 아래는 한국어 Docker 추천 자료입니다.

EC2 Container Service 따라하기

지난 AWS re:Invent 에서 Amazon EC2 Container Service(ECS) ‘미리 보기’를 처음 소개하면서 다양한 고객의 소리를 들었습니다. ‘미리 보기’ 신청에 많은 분들이 요청해 주신 점도 감사드립니다.  지금까지 ‘미리 보기’ 신청을 준 모든 고객 분들이 사용하실 수 있으며, 신규 신청에 경우도 24시간내에 사용 가능하십니다.

ECS는 Docker기반의 애플리케이션 빌드 및 실행 및 확장성(Scaling)을 돕기 위한 서비스입니다. 간단한 클러스터 관리 및 높은 성능과 유연한 스케줄링, 확장성 및 이동성 그리고 AWS외 서비스 기능과 원활한 통합을 할 수 있습니다.  기존 AWS에서 실행 환경 처럼  안전하고 효율적입니다.

ECS의 기본 사항
먼저 ECS의 용어와 기본 컨셉에 대해 알아보도록 하겠습니다.

  • Cluster -Task를 실행하기 위한 Container Instance의 논리적 그룹입니다
  • Container Instance -ECS가 가동되고 있는 EC2 인스턴스 즉, Cluster에 등록된 것입니다. Cluster내에서 움직이고 있는 인스턴스 집합은 Task를 실행하기 위한 리소스 풀(Resource Pool)을 만듭니다.
  • Task Definition– Task Definition은 Container 모음을 정합니다. 여기에는 Task Description이 포함되며, 한 개 이상의 Container를 정의합니다. 어떤 Task Definition에서 정의된 모든 Container는 동일한 Container Instance에서 가동합니다.
  • Task -Task Definition를 인스턴스화 합니다.
  • Container -Task의 일부로 생성된 Docker 컨테이너입니다.

ECS Container Agent는 Container 인스턴스에서 움직이는 에이전트입니다.  Container를 시작하는 역할 및 에이전트 자신도 Docker 컨테이너에서 실행 되며(Docker Hub에서 이용 가능), 인스턴스 내에 있는 Docker 데몬과 통신을 합니다.

우리가 클러스터 및 컨테이너 서비스를 언급할 때, “스케줄링”은 인스턴스에 작업을 할당하는 과정입니다. ECS는 다음의 3가지 스케줄링 옵션을 제공합니다.

  1. 자동(Automated)RunTask 함수는 Cluster에서 Task(Task Definition에서 정의)을 자동으로 진행합니다.
  2. 매뉴얼(Manual)StartTask 함수는 특정 Container Instance(또는 인스턴스)에서 Task(Task Definition에서 정의)을 진행합니다.
  3. 맞춤(Custom)ListContainerInstancesDescribeContainerInstances을  사용하면 Cluster내의 이용 가능한 자원의 정보를 수집할 수 있고, 스케줄링의 핵심을 구현하는 것입니다. (다시 말해 최적의 Container Instance를 뽑기 위한  정보로 할용 가능합니다.) 그 이후 StartTask를 실행하고 인스턴스에서 작업을 실행합니다. 이를 실행하는 것은 자체 RunTask 구현하는 것과 같은 의미가 됩니다.

EC2 Container Service 직접 해보기
ECS를 실제로 테스트해 보기 위해 미리 보기 등록을 하신 후, AWS CLI의 프리뷰 버전을 다운로드 후 설치합니다. 그 다음, IAM Role와 VPC를 작성해 클러스터를 만들기 위한 준비를 합니다. (ECS는 현재 US East 지역에서만 가능하나 점차로 지원 리전을 확대할 예정입니다.). 아래 명령어를 실행해 MyCluster라는 이름의 Cluster를 작성해 봅시다.

$ aws ecs create-cluster --cluster-name MyCluster --profile jbarr-cli

아래는 JSON 형식으로 신규 생성한 Clouster 정보입니다.

{
    "cluster": {
        "clusterName": "MyCluster", 
        "status": "ACTIVE", 
        "clusterArn": "arn:aws:ecs:us-east-1:348414629041:cluster/MyCluster"
    }
}

다음 단계로  ECS용 AMI(Amazon Linux AMI ECS용 미리보기 버전)를 이용하여,  자신의 VPC 중에 여러개의 EC2인스턴스를 만듭니다. EC2를 만들때, ECS용으로 만든 IAM Role(ecs라는 이름)를 선택합니다.

EC2 사용자 데이터 설정에서 자신의 Cluster(MyCluster)내에서 실행하도록 ECS 설정을 적습니다.(default클러스터 경우, 필요 없음)

인스턴스가 시작된 이후 자신의 Cluster에 포함되었는지 list-container-instances 명령으로 확인할 수 있습니다. 등록된 Container Instance은 각자 ARN가 할당됩니다.

$ aws ecs list-container-instances --cluster MyCluster --profile jbarr-cli
{
    "containerInstanceArns": [
        "arn:aws:ecs:us-east-1:348414629041:container-instance/4cf62484-da62-49a5-ad32-2015286a6d39", 
        "arn:aws:ecs:us-east-1:348414629041:container-instance/be672053-0ff8-4478-b136-7fae9225e493"
    ]
}

Cluster내 인스턴스를 선택한 후, 이용 가능한 CPU와 메모리 자원에 대해 질의를 실행하고 찾아낼 수 있습니다.

$ aws ecs describe-container-instances --cluster MyCluster \
  --container-instances arn:aws:ecs:us-east-1:348414629041:container-instance/4cf62484-da62-49a5-ad32-2015286a6d39 \
  --profile jbarr-cli

아래가 결과 데이터 샘플입니다.

{
            "registeredResources": [
                {
                    "integerValue": 1024, 
                    "longValue": 0, 
                    "type": "INTEGER", 
                    "name": "CPU", 
                    "doubleValue": 0.0
                }, 
                {
                    "integerValue": 3768, 
                    "longValue": 0, 
                    "type": "INTEGER", 
                    "name": "MEMORY", 
                    "doubleValue": 0.0
                }
            ]
}

ECS의 미리보기 개발자 가이드에 따라 아래와 같이 간단한 Task Definition을 작성하고 등록해 보겠습니다.

$ aws ecs register-task-definition --family sleep360 \
  --container-definitions file://$HOME/tmp/task.json \
  --profile jbarr-cli

그리고 10개를 실행해 보도록 하죠.

aws ecs run-task --cluster MyCluster --task-definition sleep360:1 --count 10 --profile jbarr-cli

실행 중인 작업은 다음과 같이 list-tasks 명령으로 볼 수 있습니다.

$ aws ecs list-tasks --cluster MyCluster --profile jbarr-cli

아래와 같이 실행 중인 컨테이너 목록이 반환됩니다.

{
    "taskArns": [
        "arn:aws:ecs:us-east-1:348414629041:task/0c949733-862c-4979-b5bd-d4f8b474c58e", 
        "arn:aws:ecs:us-east-1:348414629041:task/3ababde9-08dc-4fc9-b005-be5723d1d495", 
        "arn:aws:ecs:us-east-1:348414629041:task/602e13d2-681e-4c87-a1d9-74c139f7335e", 
        "arn:aws:ecs:us-east-1:348414629041:task/6d072f42-75da-4a84-8b68-4841fdfe600d", 
        "arn:aws:ecs:us-east-1:348414629041:task/6da6c947-8071-4111-9d31-b87b8b93cc53", 
        "arn:aws:ecs:us-east-1:348414629041:task/6ec9828a-cbfb-4a39-b491-7b7705113ad2", 
        "arn:aws:ecs:us-east-1:348414629041:task/87e29ab2-34be-4495-988b-c93ac1f8b77c", 
        "arn:aws:ecs:us-east-1:348414629041:task/ad4fc3cc-7e80-4681-b858-68ff46716fe5", 
        "arn:aws:ecs:us-east-1:348414629041:task/cdd221ea-837c-4108-9577-2e4f53376c12", 
        "arn:aws:ecs:us-east-1:348414629041:task/eab79263-087f-43d3-ae4c-1a89678c7101"
    ]
}

여기까지 작업을 실행하고 인스턴스를 정지시킨후 정리해 보겠습니다. 직접 실행해 본 결과, 다음의 세가지 점만 약간의 Tips으로 적어봅니다.

  1. VPC가 외부 연결이 있는지 확인해 두세요
  2. ECS가 이용 가능한 적절한 AMI을 사용하세요(미리 보기 단계)
  3. IAM Role이 필요하므로, AMI을 띄울 때 설정해 주세요

ECS 빠른 실행 템플릿
빠르게 ECS를 실행해 볼 수 있도록 CloudFormation을 사용한 ECS 실행 템플릿을 활용해 보세요. 이 템플릿은 IAM Role과 그 역할을 위한 Instance Profile을 생성합니다. 이 역할은 ECS 에이전트가 ECS와 커뮤니케이션을 할 수 있도록 허용하기 위한 것입니다. 템플릿에서는 이 Role을 통해 인스턴스를 시작하고, 그 결과 인스턴스에 접근할 수 있는 SSH 명령을 생성해서 돌려줍니다. 기존 클러스터로 인스턴스를 시작 및 등록하는 것도 가능하며, “default”라는 이름의 기본 클러스터를 이용하기도 합니다. 이 템플릿을 사용한 경우, 인스턴스는 Default VPC을 사용하게 됩니다.

지금 시작 하기
ECS를 하기 위해서는 먼저 미리 보기 등록을 하시기 바랍니다. 즉시 이용 가능합니다.

ECS에 대해 더욱 알고 싶은 경우, re:Invent의 다음 세션을 보시면 좋습니다. 대략 30분 정도 됩니다(주의하실 점은 현재 ECS 기능이 크게 변해있을 수 있으므로, 참고만 하시면 좋겠습니다.)

또한, 내년 Amazon EC2 Container Service Deep Dive(2015 년 1월 14일 미국 시간)라는 웨비나를 진행합니다. 이번 웨비나에서는 ECS 선임 매니저인 Deepak Singh가 왜 우리가 ECS을 만들었는가, 핵심 개념 및 고객 애플리케이션에서 ECS를 어떻게 사용하면 좋은지 등을 발표합니다..

또 한 가지는 CoreOS라는 현대적인 인프라 구조의 요구 사항을 만족하도록 설계한 운영 체제를 기반으로 CoreOS AMI의 ECS 지원이 가능해졌습니다! 자세한 것은 Amazon ECS on CoreOS를 참고하십시오.

마지막으로 AWS는 우리는 항상 고객 피드백을 받고 있습니다. ECS는 아직 미리보기 모드이므로 고객의 요구나 요청을 듣고 새로운 기능을 개선할 수 있습니다. 피드백은 ECS 포럼에 해 주시기 바랍니다.

– Jeff;

본 글은 EC2 Container Service In Action의 한국어 번역입니다.