Category: Amazon EC2

여러분이 다수의 Amazon Elastic Compute Cloud (EC2) 인스턴스에 리눅스 운영체제를 설치하고, 다수 계정을 만들어 로그인하고 관리하는데 어려움이 있으시다면, 이런 분들께 도움이 될 새로운 기능입니다.

EC2 인스턴스를 AWS Directory Service의 Simple AD 디렉토리에 추가하여, 표준 Active Directory 도구와 기술을 사용하여 사용자 로그인 인증 정보를 관리 할 수 있게 되었습니다. 사용자는 도메인 내 모든 인스턴스에 동일한 설정의 인증 정보를 사용하여 로그인 할 수 있습니다. 디렉토리 그룹을 생성하여 추가로 제어 권한을 만드실 수 있습니다.

여러분이 쉽게 사용할 수 있는 단계별 적용 방법을 소개해 드립니다. 최신 버전의 Amazon Linux AMI, Red Hat Enterprise Linux, Ubuntu Server 또는 CentOS 를 AWS Directory Service의 Simple AD가 그 속에있는 Amazon Virtual Private Cloud의 EC2 인스턴스로 이동해야합니다.

VPC를 위한 DHCP 옵션 설정을 간단히 만들어 디렉터리를 지정하고, Kerberos 클라이언트를 설치한 뒤 인스턴스를 도메인에 가입시킨 후 다시 시작합니다. 이것이 완료되면 SSH를 통해 디렉토리의 인증 정보를 사용하여 로그인 할 수 있습니다. 이 문서에서는 도메인 인증 정보를 사용하여 로그인 및 sudo 목록에 도메인 관리자 추가, 그리고 특정 그룹 멤버에 대한 접근 제한에 대해서도 설명하고 있습니다.

— Jeff;

이 글은 Joining a Linux Instance to a Simple AD (AWS Directory Service)의 한국어 번역입니다.

Amazon CloudWatch는 Amazon Elastic Compute Cloud (EC2) 인스턴스를 포함하여 다양한 클라우드 리소스를 모니터링 할 수 있습니다. 클라우드 시스템 및 응용 프로그램 수치(Metric)를 모니터링하여 그래프 형식으로 확인하고, 지정된 임계치를 초과하면 (CloudWatch 알람를 통해) 통보하도록 설정할 수 있습니다. 예를 들어, 알람이 발생했을 경우 EC2 인스턴스를 중지 혹은 종료 할 수 있습니다 (자세한 사항은 Amazon CloudWatch – Alarm Actions을 참고하십시오).

새로운 기능 – 인스턴스 재시작
오늘 네번째로 신규 기능을 추가했습니다. 즉, CloudWatch 알람이 발생했을 때 EC2 인스턴스를 다시 시작하도록 설정할 수 있게 되었습니다. 클라우드 시스템 및 응용 프로그램 모니터링과 알람을 함께 사용하면 높은 유연성을 제공해 드릴 것입니다.

인스턴스 상태 확인이 반복적으로 실패하는 경우 인스턴스를 다시 시작할 수 있습니다. 즉, 메모리 누수를 일으키는 응용 프로그램이나 서비스가 원인이 되어 메모리가 부족한 상태가 되었을 수도 있고, 이 때는 인스턴스 재시작이 상황을 개선하기 위해 가장 빠르고 쉬운 방법입니다. EBS-Backed 인스턴스 유형이거나 인스턴스가 깨진 경우에만 적용되는 극히 일부의 복구 작업과는 달리 이 작업은 모든 인스턴스 유형에서 사용할 수 있는 (인스턴스의 상태에 관계없이) 가장 효과적입니다.

응용 프로그램 수치를 모니터링하는 CloudWatch API 또는 AWS 명령어 인터페이스 (CLI)를 사용하면 응용 프로그램이 반복적으로 응답하지 않으면 인스턴스를 다시 시작할 수 있습니다. 프로세스가 막히거나 응용 프로그램 서버가 제대로 작동하지 않을 수도 있습니다. 이런 경우, (가상) 리셋 스위치를 누르는 것이 다시 정상 작동을 위한 쉽고 간단한 방법입니다.

알람 만들기
CPU 사용률이 장기간 90%를 초과 한 상태일 경우, 인스턴스 중 하나를 재시작하도록 알람을 생성하는 방법을 살펴 보겠습니다. AWS 괸리 콘솔에서 인스턴스를 찾아 Alarm Status란 아이콘을 클릭합니다.

Take Action을 클릭하고 Reboot Instance를 선택하여 매개 변수를 설정합니다 (CPU 사용률이 90% 이상 15분 이상 지속되는 경우).

필요하다면, 콘솔에서 단계 중에 IAM 역할 만들기를 진행합니다 (이것 역시 새로운 기능입니다.)

이 역할은 CloudWatch의 “Describe”기능과 EC2 API 호출을 허용하기 위한 것입니다. 또한, 인스턴스 재시작 및 종료에 대한 권한 역시 허용합니다.
Create Alarm을 클릭하면, 설정이 완료됩니다!

이 기능은 현재 모든 AWS 리전(Region)에서 오늘부터 사용할 수 있습니다.

— Jeff;

이 글은 New Amazon CloudWatch Action – Reboot EC2 Instance의 한국어 번역입니다.

클라우드 컴퓨팅 장점 중의 하나는 민첩성(Agility)입니다. 전통적인 IT환경에서 서버의 CPU나 메모리 또는 NIC 등의 부품 구성을 변경하는 작업은 운영자의 수작업이 동반됩니다. 하지만, AWS 환경에서는 웹 관리 콘솔을 통해서 몇 번의 클릭만으로 관련 작업을 신속하고 간단히 수행할 수 있습니다.

그러나, 수 십대 또는 수 백대의 인스턴스들을 운영하고 또 한정된 점검 시간 내에 관련 작업을 수행 해야한다면 이 작업 또한 그리 쉬운 일은 아닙니다. 이런 경우 AWS에서 제공하는 API나 CLI를 이용해서 간단한 프로그램이나 스크립트를 작성하면, 반복적인 작업을 일괄 처리 수행하여 쉽고 빠르게 목표한 결과를 얻을 수 있습니다.

이 글에서는 c3.large 타입의 인스턴스들을 새로운 세대인 c4.large 타입으로 한꺼번에 변경해야 하는 상황을 가정해서, 일괄 처리하는 스크립트를 작성하는 예를 소개합니다.

사전 준비 사항
스크립트를 작성하기 위해서는 아래 AWS 명령줄 인터페이스가 준비되어야 합니다. AWS 명령줄 인터페이스는 여기를 클릭하시면 다운로드 받을 수 있으며, 설치 가이드와 사용법도 확인할 수 있습니다.

스크립트 작성하기
위의 CLI 설치 작업이 완료되었다면, 이제 스크립트를 작성할 준비가 되었습니다. 인스턴스 타입을 변경하는 작업은 인스턴스가 정지된 상태서만 가능하기 때문에, 원하는 작업을 성공적으로 하려면 다음의 작업 순서를 따라야 합니다:

1. 대상 인스턴스 목록 추출
2. 인스턴스 정지
3. 인스턴스 타입 변경
4. 인스턴스 시작

1번에서 획득한 각 인스턴스를 대상으로 2, 3, 4번을 순차적으로 반복 수행하게 됩니다.

우선 인스턴스 목록을 얻기 위해서 describe-instances 명령을 이용합니다. 아래 명령어는 AWS 계정에서 운영되는 모든 인스턴스의 정보를 얻을 수 있습니다.

$ aws ec2 describe-instances 

작업 대상인 c3.large 타입의 인스턴스들에 대한 정보만 얻기 위해서는 필터 기능을 활용해야 합니다. --filters 옵션을 사용해서 instance-type이 c3.large인 인스턴스들만 추출합니다.

$ aws ec2 describe-instances  --filters "Name=instance-type,Values=c3.large"

위 명령어를 통해서 c3.large 타입의 인스턴스에 대한 모든 속성 정보를 볼 수 있습니다. 응답된 데이터에서 실제로 필요한 인스턴스 ID 정보만 얻기 위해서는 --query 옵션을 사용하고 그 값으로 Reservations[].Instances[].InstanceId 문자열을 사용합니다. 또한 스크립트에서 사용하기 용이하도록 출력되는 형태를 JSON 형태가 아닌 일반 텍스트로 출력되도록 변경합니다. 이를 위해서 --output 옵션과 옶션값으로 text 값을 선택합니다.

출력되는 결과의 필드 구분자는 탭문자(‘\t’)입니다. 즉, 인스턴스 ID들이 탭문자로 구분되어서 한 라인에 길게 나열되게 됩니다. tr(1)명령어를 이용해서 탭문자를 개행문자(‘\n’)로 대체시켜 한 줄에 하나의 인스턴스 ID가 출력되도록 변경합니다.

$ aws ec2 describe-instances  --filters "Name=instance-type,Values=c3.large" --query "Reservations[].Instances[].InstanceId"  --output text |  tr "\t" "\n"

이제 앞에서 얻은 인스턴스 ID 목록과 아래에 소개할 명령어들을 이용해서 인스턴스를 하나씩 c3.large에서 c4.large로 변경할 수 있습니다.

먼저 인스턴스 하나를 정지시킵니다.

$ aws ec2 stop-instances --instance-id=${INSTANCE_ID} 

위 명령어는 비동기 명령이기때문에 해당 인스턴스에 정지 명령을 실행시키고 결과에 관계없이 바로 리턴됩니다. 이 명령어 다음에 바로 인스턴스 타입을 변경시키면 에러가 발생할 수 있습니다.

따라서 인스턴스 상태를 주기적으로 체크하여 인스턴스가 정지(STOPPED)된 상태로 변경되었을 때 타입을 변경해야 합니다. 비동기 명령을 내릴 때마다 체크하는 부분을 스크립트 내에 코드로 작성한다면 다소 번거롭고 귀찮은 일입니다. 하지만 AWS 명령줄 인터페이스는 친절하게도 이를 대신 수행하는 명령을 제공합니다. 비동기 명령어가 수행되고 원하는 상태가 되었을 때까지 기다릴 수 있도록 wait라는 추가 명령 옵션을 제공하고 있습니다.

$ aws ec2 wait instance-stopped --instance-ids=${INSTANCE_ID}

위 명령어를 통해서 인스턴스가 실제로 정지될 때까지 스크립트는 다음 단계를 수행하지 않고 멈춰 있습니다. wait명령을 통해서 인스턴스가 정지할 때까지 아래 명령어를 수행하지 않고 대기합니다.

인스턴스 타입 변경은 modify-instance-attribute 명령을 이용해서 간단히 수행합니다.

$ aws ec2 modify-instance-attribute --instance-type=c4.large --instance-id=${INSTANCE_ID} 

타입 변경이 끝났다면, 이제 인스턴스를 다시 시작하기만 하면 됩니다.

$ aws ec2 start-instances --instance-id=${INSTANCE_ID}

인스턴스를 시작하는 명령도 비동기 명령입니다. 그렇기 때문에 인스턴스에 시작 명령을 내리고 실제 인스턴스가 정상적으로 실행되었는지와는 관계없이 바로 리턴됩니다.
아래와 같이 wait 명령어를 통해서 해당 인스턴스 상태가 정상적으로 시작된 상태인지를 확인한 후 다음 인스턴스에 대한 타입 변경 작업을 수행할 수 있습니다. 이 부분은 선택사항입니다.

$ aws ec2 wait instance-status-ok --instance-ids=${INSTANCE_ID} 

지금까지 스크립트를 구성하는 주요 부분에 대해서 설명드렸습니다. 아래 스크립트는 앞서 설명드린 내용들을 기반으로 작성한 간단한 bash 쉘 스크립트입니다.

#!/bin/bash
#
while getopts ":s:d:" OPT; do
  case $OPT in
    s)
      SRC_TYPE=$OPTARG
      ;;
    d)
      DEST_TYPE=$OPTARG
      ;;
    *)
      echo "Invalid option: -$OPTARG" >&2
      exit 1
      ;;
  esac
done

aws ec2 describe-instances  --filters "Name=instance-type,Values=${SRC_TYPE}" --query 'Reservations[].Instances[].InstanceId' --output text |tr "\t" "\n"| while read INSTID
do
    echo "Changing instance type for ${INSTID}... $(date)"
    aws ec2 stop-instances --instance-id=${INSTID} > /dev/null 2>&1
    aws ec2 wait instance-stopped --instance-ids=${INSTID} > /dev/null 2>&1
    aws ec2 modify-instance-attribute --instance-type=${DEST_TYPE} --instance-id=${INSTID} > /dev/null 2>&1
    aws ec2 start-instances --instance-id=${INSTID} > /dev/null 2>&1
    aws ec2 wait instance-status-ok --instance-ids=${INSTID} > /dev/null 2>&1
done
echo  "All done! $(date)"

스크립트의 간결성을 유지하기 위해서 모든 에러처리 루틴을 배제하였습니다. 따라서 범용적으로 사용하기 위해서는 적절한 에러 처리 루틴들이 추가되어야 하고 충분한 테스트를 거친 후 사용하시길 권장합니다.

아래 예는 실제로 두 개의 c3.large 리눅스 인스턴스를 c4.large로 변경하였을 때의 실행 결과를 캡처한 내용입니다.

$ ./migration.sh –s c3.large –d c4.large
Changing instance type for i-353294c7... 2015년 7월 20일 월요일 09시 27분 01초 KST
Changing instance type for i-253593d7... 2015년 7월 20일 월요일 09시 30분 22초 KST
All done! 2015년 7월 20일 월요일 09시 34분 44초 KST

이 스크립트를 통해 대규모 EC2 인스턴스 운영 환경에서 인스턴스 타입을 변경할 뿐만 아니다 각종 정보를 변경하는 등 다양한 운영 작업에 활용하시는데 도움이 되었으면 합니다. 감사합니다.

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

오늘 부터 AWS Lambda가 아시아 태평양(동경) 리전에서 사용할 수 있습니다.

AWS Lambda는 AWS 서비스 이벤트에 따라 코드를 실행하고 컴퓨팅 리소스를 자동으로 관리하는 클라우드 서비스이며, 서버 없이도 신속하게 기능을 수행할 수 있는 애플리케이션 구축을 쉽게 개발할 수 있습니다. 예를 들어, AWS Lambda는 S3에 이미지를 업로드하면, 이에 따라 썸네일을 만든다던지 백업을 한다던지 하는 작업을 수 밀리초 내에 실행할 수 있습니다.

인프라 운영자들은 AWS Lambda를 통해 컴퓨팅 자원의 변화에 따라 실행하는 새로운 백엔드 서비스를 만드는 데 사용할 수 있으며, 개발자들은 서버 없이도 원하는 기능을 수행하는 모바일 서비스를 만들 수 있습니다. AWS Lambda는 처리 된 요청 수와 코드 실행에 필요한 된 컴퓨팅 시간에 대해서만 비용이 청구됩니다.

AWS Lambda는 현재 US East (N. Virginia), US West (Oregon), EU (Ireland) 그리고 Asia Pacific (Tokyo)의 지역에서 사용할 수 있습니다. 자세한 내용은 제품 페이지를 참조하십시오.

본 글은 AWS Lambda Available in Asia Pacific (Tokyo)를 번역 및 편집하였습니다.

Amazon EC2 스팟 인스턴스가 글로벌 규모의 다양한 활용성이 높은 서비스를 구현할 수 있는 기능이라고 자주 언급했습니다.

전 세계에 걸쳐 많은 사용자와 업무 그리고 이를 위한 대규모 컴퓨팅 자원을 가지고 있지 않다면, 시장을 창출하는데 필요한 수요와 공급에 있어 변화에 크게 영향을 받을 필요가 없습니다. 이를 위한 해법인 스팟 인스턴스는 EC2 용량을 경매를 통해 구매해서 온디멘드 가격 보다 90% 정도 저렴하고, 누군가 여러분의 가격 보다 높은 가격을 쓰면, 2분 정도의 경고 시간을 가지고 인스턴스가 종료됩니다.

스팟 인스턴스는 바로 쓰고 버려지기 때문에, 이를 잘 활용해서 가치를 극대화하기 위해 지속적인 운영을 위한 경매 전략을 철저히 세울 필요가 있습니다. 여러분이 만약 제대로 응용 프로그램을 구축하고 있다면, 최대 90%의 비용 절감 효과(또는 고정 예산으로 10배의 계산 능력)를 얻을 수 있습니다. 여러분이 클라우드 아키텍트라면, 매우 흥미로운 사실로서 가격을 고려하면서 탄력성 높은 응용 프로그램을 만들거나 컴퓨팅 연산 능력의 비용을 줄이는 방법을 직접 훈련해 볼 수 있습니다. 스팟 인스턴스의 장점과 단점을 학습하면, 여러분에게 큰 이익을 드릴 수 있을 것입니다.

명확한 새로운 기술 경향
EC2의 과거를 돌아보면 (온 디맨드 인스턴스, 스팟 인스턴스, 컨테이너, 스팟 그룹), 기술 트렌드는 명확합니다. 지금까지 오랜 시간 실행 중인 인스턴스와 가격표에 신경 써 왔다면, 앞으로는 (동일한 속성을 공유하는 인스턴스 그룹)의 개별 처리 용량 내에서 수요와 공급에 따라 가장 최적의 가격을 제공하는 중간 단계의 라이프타임을 가지는 인스턴스의 집합을 생각해 볼 필요가 있습니다. 이러한 새로운 아이디어는 과거의 사고 패턴에서 좀 더 열린 방식으로 대량 컴퓨팅 용량을 빠르고 싸게 얻기 위해 새롭게 매력적인 방법으로 가격에서도 정말 멋진 응용 프로그램을 구축 할 수 있습니다.

스팟 인스턴스를 쓰기 시작하면 상호 윈윈 모델이라는 것을 말씀 드려야 할 것 같습니다. 그 시점에서 가장 경제적인 가격으로 컴퓨팅 파워를 얻을 수 있습니다. 이와 마찬가지로 아마존은 소유하고 있는 서버군(참고 : AWS 글로벌 인프라 페이지)에 대해 높은 가동률을 유지 할 수 있습니다. 높은 가동률은 아마존의 비용 구조를 개선하고 친환경적인 혜택도 제공합니다.

스팟 인스턴스 모범 사례
몇 개월 내에 EC2 스팟팀의 지원을 통해 스팟 인스턴스 활용에 대한 모범 사례를 공개할 계획입니다. 대부분은 실제로 우리 고객들이 공유해 주신 예제를 기반으로 합니다(이론이나 학술 적인 것은 아닙니다). 오늘은 몇 가지 모범 사례에 대한 간략한 개요를 소개하고자 합니다.

용량 풀(Pool)에 대한 정의 – 앞서 살펴본 봐와 같이 용량 풀은 지역(Region), 가용존(Availability Zone) 운영 시스템 (Linux/Unix 또는 Windows) 인스턴스 유형이 동일한 EC2 부팅 인스턴스의 모음입니다. 각 EC2 용량 풀은 가용성(그 시점에서 부팅 가능한 인스턴스 수), 수요와 공유를 통해 가격이 책정됩니다. 나중에 살펴 보겠지만, 하나 이상의 용량 풀에 걸쳐 실행 가능한 응용 프로그램은 저렴하게 컴퓨팅 파워를 접근할 수 있는 상태에 있고 풀의 용량은 온 디멘드와 스팟 인스턴스로 공유되기 때문에, 스팟 인스턴스의 수요와 온디맨드 인스턴스 수요에 따라 가격이 조금 올라갈 수는 있습니다.

이제 스팟 인스턴스의 몇 가지 모범 사례를 소개합니다.

가격 기반 응용 프로그램 구축 – 이전에도 언급 한대로 클라우드 컴퓨팅은 비즈니스 모델과 기술의 조합입니다. 가격을 고려하여 코드를 작성 (또는 시스템을 설계)할 수 있으며, 향후에 더 많은 클라우드 예산을 얻을 수 있는 가능성이 있습니다. 많은 개발자에 있어서 새로운 영역입니다. 여러분의 이력서나 직무 영역에 비용 절감을 위한 인프라 설계를 포함해보시기 바랍니다.

여러분의 시간을 투자하여 (EC2 API , AWS Command Line Interface (CLI) 등을 사용하여 도구를 만들어) 응용 프로그램이 사용하는 리전의 용량 풀을 이용해 볼 수 있습니다. 높은 가격과 높은 가격 변동성을 가진 경우, 같은 용량 풀에 경쟁이 많다는 것을 의미합니다. 보다 효과적이고 낮은 인터럽트 비율을 얻기 위해 (현재 또는 과거의) 더 저렴하고 안정적​​인 할인 가격을 가진 풀을 찾아보세요.

과거 가격 기록 확인하기 – 지난 90일(3 개월)에 거슬러 용량 풀 당 가격 기록을 볼 수 있습니다. 현재 고객에게 매우 인기 있는 인스턴스 (이 블로그를 작성하는 시점에서는 R3)는 스팟 가격이 불안정합니다. 이전 세대 (c1.xlarge, m1.small, cr1.8xlarge, cc2.8xlarge 등)은 비교적 안정된 경향을 가지고 있습니다. 일반적으로 이전 세대의 인스턴스를 선택하면 저렴한 가격으로 방해를 적게 받을 수 있습니다.

다중 용량 풀을 사용하기 – 다양한 응용 프로그램은 다중 용량 풀에 나눠져 실행할(또는 실행 할 수 있도록 쉽게 적용 가능) 수 있습니다. 다중 용량 풀에서 실행할 수 있게 되면, 어떠한 용량 풀 또는 두 개 용량 풀에 영향을 주는 가격 변동에 대한 과민도를 줄일 수 있습니다 (일반적으로 서로 다른 용량 풀 사이에 가격 상관 관계는 거의 없습니다). 예를 들어, 다섯 개의 용량 풀을 사용하면 가격 변동 및 방해 정도는 80% 가까이 감소합니다.

이러한 몇 가지 베스트 프랙티스를 통한 높은 수준의 접근 방식은 활용하면, 유연성 등 여러 측면에서 많은 용량 풀에 접근할 수 있습니다. 여러 AZ에 걸쳐 앱을 실행할 수 있고(실제로 Auto Scaling 및 스팟 그룹 API를 조합 가능), 또는 동일한 인스턴스 패밀리 중에서도 여러 인스턴스 타입에 걸쳐서 실행할 수 있습니다 (Amazon EMR 역시 같은 접근 방법입니다.) 예를 들어, 응용 프로그램이 필요한 vCPU 수를 알고 있다면 그 수를 확보하여 충분한 작업자 스레드를 시작할 수 있습니다.

이러한 모범 사례를 준수하는 것은 각 용량 풀이 거의 같은 양을 사용하도록 노력할 필요가 있습니다. 이것은 스팟 용량과 스팟 가격 변동에 의한 영향을 최소화할 수 있습니다.

더 자세히 알고 싶으신 분은 EC2 문서의 스팟 인스턴스를 참조하십시오.

더 자세한 정보를 기대하세요!

이미 언급했듯이 이 글은 서론이며, 앞으로 많은 아이디어와 실제 코드를 제공하고자 합니다. 의견이 있는 경우 또는 여러분의 스팟 Tips를 제공하고 싶은 경우 awseditor@amazon.com에 문의하십시오.

– Jeff ;

이 글은 Focusing on Spot Instances – Let’s Talk About Best Practices 한국어 번역입니다.

AWS는 지난해 여름 저가형 T2 instances를 새로 출시했습니다. (참고: 한국어 출시 뉴스). T2 인스턴스 타입은 기본 성능에다 필요할 때 마다 CPU 용량을 자동으로 최대로 쓸 수 있는 기능을 포함하고 있습니다. 이러한 버스팅 모델(Bursting Model)은 평소에 “CPU 크레딧”을 모아두었다가 필요할 때 한꺼번에 사용할 수 있는 장점이 있습니다.

고객들의 피드백과 사용량 통계에 따라 오늘 t2.large 인스턴스를 추가합니다. 우리 고객들은 버스팅 모델이 CPU 용량을 최대한 효율적으로 사용할 수 있으나, 메모리에 대한 부분도 필요하다는 의견에 따라 메모리 용량을 2배로 제공합니다.

많은 AWS 고객들이 개발 테스트 환경, 작은 데이터베이스 및 애플리케이션 서버 및 웹 서버에 T2 인스턴스를 활용하고 있고 이러한 서버들은 CPU가 크게 많이 사용하지 않고 필요할 때 가끔 CPU가 필요합니다.

아래에 T2 인스턴스 타입의 목록입니다.

AWS 고객 중 GoSquared(“People Analytics”)는 T2 인스턴스를 가장 잘 활용하는 고객입니다.:

“T2 인스턴스의 가장 좋은 점은 CPU 크레딧을 다 쓰지 않는 한 적은 비용으로도 더 큰 인스턴스 타입의 성능을 즐길 수 있다는 점입니다. 인스턴스의 서비스에 관한 한 고정된 성능을 보여 주고 있습니다.

JT, Co-founder and Lead Front-end Engineer, GoSquared

새 인스턴스 타입은 US East (Northern Virginia), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), South America (Brazil), 및 AWS GovCloud (US) 리전의 온디멘드 및 예약 인스턴스에서 사용 가능합니다.

— Jeff;

이 글은 New T2.Large Instances의 한국어 번역입니다.

2006년 처음으로 Amazon Elastic Compute Cloud (EC2)의 인스턴스 타입인 m1.small이 처음 공개된 이후로 고객의 요구에 따라 메모리와 CPU 프로세스 기술 향상을 통해 신규 인스턴스를 추가해왔습니다. (EC2 인스턴스 역사를 참고하세요.)

오늘 컴퓨팅, 메모리 및 네트워크 리소스의 균형을 이룬 일반적인 목적의 새로운 M4 인스턴스를 공개합니다. 한번 자세히 알아보겠습니다.

신규 M4 인스턴스
새로운 M4 인스턴스는 EC2에 최적화된 맞춤형 Intel Xeon E5-2676 v3 Haswell 프로세스와 클락 사이즈 2.4 GHz에서 최대 3.0 GHz 인텔 터보 부스터가 제공됩니다. 아래는 자세한 사양입니다.

m4.10xlarge 인스턴스에서 리눅스를 운영하신다면, C 상태 및 P 상태도 제어 가능합니다. (신규 C4 인스턴스 출시 참고). 신규 인스턴스에는 놀랄만한 코어 갯수로 인해 동시성 작업을 확보하기 위해 멀티 프로세스를 사용할 수 있습니다.

또한, 대체 그룹(placement groups) 내에서 높은 네트웍 I/O하에서 같은 지연 시간을 보장하기 위해 인스턴스의 패킷 비율을 4배 이상 올려주는 고성능 네트워킹을 제공합니다. 고성능 네트워킹은 인스턴스 간 평균 지연 시간을 50%이상 줄여줍니다. M4 인스턴스는 EBS-Optimized를 기본으로 제공합니다. 부가적으로 I/O를 위한 전용 네트워크 용량을 확보하며, VPC 내에서 64비트 HVM AMI를 지원합니다.

M4 인스턴스는 US East (Northern Virginia), US West (Northern California), US West (Oregon), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Sydney) 및 Asia Pacific (Tokyo) 리전에서 바로 사용 가능하며, 온디멘드 및 스팟 형태 뿐만 아니라 예약 인스턴스로도 구매 가능합니다.

M3 및 C4 인스턴스 가격 인하
오늘 출시와 함께 M3 및 C4 인스턴스의 온디멘드 및 1년 예약 인스턴스의 가격을 5% 정도 인하하며 US East (Northern Virginia), US West (Oregon), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo) 및 Asia Pacific (Sydney) 지역에 적용됩니다.

이번 인하는 2015년 6월 1일자로 시작되며, 2015년 6월 11일 이후 구매하는 예약 인스턴스에 적용됩니다. 자세한 사항은 EC2 가격표를 참고하세요.

— Jeff;

본 글은 The New M4 Instance Type (Bonus: Price Reduction on M3 & C4)의 한국어 번역입니다.

지난 9년간 Amazon Elastic Compute Cloud (EC2)의 서비스 진화를 살펴 보는 것은 매우 흥미롭습니다. 초기에는 단일 인스턴스 타입을 단일 리전에서 사전에 정해진 주문형 가격에서 시작하였습니다. 지금은 다양한 인스턴스 타입이 11개의 리전 (AWS GovCloud (US) 포함)에서 시작할 수 있으며, 예약 인스턴스 및 스팟 인스턴스(현재 9 지역)를 선택할 수 있습니다. 그동안 EC2에 많은 기능을 추가했고, Amazon EMR, AWS Elastic Beanstalk, Amazon WorkSpaces, Amazon EC2 Container Service, AWS Lambda 등 다른 서비스의 빌딩 블록으로 사용되고 있습니다.

신규 스팟 집합 API
오늘 스팟 인스턴스의 집합을 바로 시작하고 제어 할 수 있는 새로운 API를 추가하였으며, 이를 통해 더욱 쉽게 스팟 인스턴스를 사용할 수 있게 되었습니다. (스팟 집합은 분산 응용 프로그램에서 병렬로 작동하는 스팟 인스턴스의 집합입니다. 스팟 집합으로는 일괄 처리 작업 및 Hadoop 워크 플로우, HPC 그리드 컴퓨팅 작업을 할 수 있습니다.) 많은 AWS 고객은 가장 낮은 비용으로 다양한 업무 영역(분자 생물학 시뮬레이션 연구에서 지속적인 통합 환경에 이르기까지)을 수행하기 위해 여러 인스턴스 유형과 가용 영역에서 사용 가능한 컴퓨팅 용량을 찾고, 시장 가격을 모니터링하여 입찰 가격을 관리하는 자체 코드를 만들어 적게는 몇 백에서 몇 천의 인스턴스 그룹을 시작할 수 있습니다.

새로 공개한 API RequestSpotFleet를 통해 스팟 집합의 대상 용량 시간 당 입찰 가격 및 부팅 인스턴스 유형을 지정하기만 하면 인스턴스를 띄울 수 있습니다. 최저가의 용량을 찾아 스팟 집합의 목표 용량을 유지할 수 있습니다. 일단 API 호출에서 이러한 모든합니다.

API 요청 시작하기

한 리전에서 최대 1000개의 활성 스팟 집합을 가질 수 있습니다. 하나의 스팟 집합과 한 개의 리전에 대해 3000개의 인스턴스 제한이 있습니다 (일반 계정이나 리전마다 있는 EC2의 상한도 그대로 유효하므로, 부팅할 인스턴스 갯수나 만들 수 있는 Amazon Elastic Block Store (EBS) 볼륨 수에도 제한이 걸립니다).

API 및 CLI를 통해 각 요청은 다음 값을 지정 해야 합니다 :

• 대상 용량 – 스팟 집합에 넣고 싶은 EC2 인스턴스 수 (지정하지 않으면 기본값은 1)
• 최대 입찰가 – 지불하려고 최대 입찰가
• 시작 설정 – 시작하려는 인스턴스 수와 인스턴스 유형 및 시작 설정 (AMI Id, VPC 서브넷과 가용영역, 보안 그룹, 블록 디바이스 매핑 사용자 데이터 등). 더 싸고 사용하기 위해서는 일반적으로 부팅 설정에서는 특정 서브넷이나 가용 영역을 지정하지 않습니다.
• IAM 역할 이름 – EC2가 스스로 종료하기 위해 필요합니다.

각 요청은 다음의 옵션 값을 포함 할 수 있습니다.

• 클라이언트 토큰 –호출을 식별하는 고유한 문자열 (대소 문자 구분). 스팟 집합 요청을 위한 멱등 보장을 위해 사용할 수 있습니다.
• 유효 기간 시작 날짜 – 호출 시작 날짜 및 시간
• 유효 기간 종료 날짜 – 호출 종료 시간
• 유효 기간 종료시 종결 – TRUE를 지정하면 호출 종료 시간에 스팟 집합의 모든 인스턴스가 종료됩니다. FALSE(기본값)으로 스팟 인스턴스는 그대로 실행을 계속하지만, 새로운 인스턴스를 시작합니다.

RequestSpotFleet API가 성공적으로 호출 되면 스팟 집합 요청 ID를 반환하며, 요청이 이상한 경우는 오류를 반환합니다. 사용할 수 없는 인스턴스 유형을 요청한 경우에도 오류를 받게됩니다.스팟 집합 요청 ID를 사용하여 DescribeSpotFleetRequests, DescribeSpotFleetInstances, DescribeSpotFleetRequestHistory, CancelSpotFleetRequests 등 기타 스팟 집합 API를 호출 할 수 있습니다 (각 API는 명령 줄에서도 동일한 기능이 있습니다).

더 자세히 살펴 보기
일단 호출이 접수된 날짜가 정해지면 EC2 스팟 가격이 달라졌다 해도 요청한 용량을 유지하게 됩니다. 시작 설정에 따라 현재 현물 가격을 모니터링하기 시작합니다. 최저가로 용량을 확보하기 위해 상한에 들어가고 있으며 입찰 제한에 들어가고있는 경우 스팟 인스턴스 시작합니다. 스팟 가격이 상승하면 스팟 집합의 인스턴스는 종료됩니다, 그 시점에서 최저가의 시작 설정으로 교체됩니다.
이 설정은 요청이 만료 될 때까지 또는 취소 할 때까지 활성화됩니다. 스팟 집합의 인스턴스는 의도적으로 종결하지 않는 한 계속 실행됩니다. 앞서 언급 한 바와 같이, IAM 역할을 포함해야 합니다. 이를 통해 EC2는 자신을 종료할 수 있습니다.

고려해야 할 사항
다른 신규 AWS 기능과 마찬가지로 첫 번째 출시한 상태에서 해야 할 많은 기능을 계속해서 구현해 나갈 예정입니다. 예를 들어, 우리는 인스턴스 가중치 시스템을 추가할 계획을 가지고 있습니다. 이것은 각 부팅 설정의 상대적인 우선 순위를 수식으로 표현할 수 있도록 합니다. 대상 용량이라는 기능은 계산에 필요한 스팟 집합의 “마력”을 나타낼 수 단위를 표현합니다. 각 스팟 집합는 특정 AWS 지역에서 실행합니다. 장래 적으로는 두 개 이상의 지역에 걸쳐 스팟 집합을 지원할 예정입니다.

바로 이용 가능
오늘부터 공용 AWS 지역에서 스팟 집합 기능을 출시 할 수 있습니다. 스팟 집합의 기능은 무료로 시작한 EC2 인스턴스 현물 가격과 기타 이용한 자원에 대해서 지불합니다.

— Jeff;

이 글은 Amazon EC2 Spot Fleet API – Manage Thousands of Spot Instances with one Request의 한국어 번역입니다.