Category: Amazon EC2*


EC2 Spot 인스턴스를 통해 가격에 민감한 앱 만들기

지난번에 EC2 Spot 인스턴스의 모범 사례 에 대한 기사를 연재할 계획을 말씀드린 바 있습니다. 그 첫번째로 Spot 인스턴스를 사용하여 어떻게 하면 가격 기반 응용 프로그램을 개발할 것인가? 라는 주제로 EC2 Spot 팀의 2 명의 시니어 개발자와 함께 이야기를 하였습니다. Dmitry Pushkarev (기술 개발 담당)와 Joshua Burgin(제품 관리자)과의 대화를 인터뷰 형식으로 편집해서 제공해 드립니다.



Jeff : Spot 인스턴스 가격의 진정한 의미는 무엇일까요?

Joshua : Spot 기반 무장애 응용 프로그램을 구축 할 때, 현재 가격과 과거 가격 기록은 중요한 고려 사항입니다. 가격을 잘 살펴봄으로서 가장 가능성 높은 용량 풀(Capacity Pool)에 응용 프로그램을 배포하거나, 서비스가 방해 받을 가능성을 줄이고 가격 성능을 전반적으로 향상시킬 수 있습니다.

Spot 시장에서 인스턴스 가격은 수요와 공급으로 정해집니다. 낮은 가격이라는 것은 수요보다 많은 용량이 있다는 것을 의미합니다. 낮은 가격이거나 낮은 변동폭으로 일정한 것은 그 용량 풀은 수요가 적다는 것을 의미합니다. 예를 들어, 이전 세대의 인스턴스가 그런 경향을 가집니다.(m1.small, c1.xlarge, cc2.8xlarge 등)


Jeff : 고객이 어떻게 (가격에 따라 인스턴스가 변동될 수 있는) 환경에서 애플리케이션을 구축할 수 있을까요?

Dmitry : (Spot 인스턴스를 이용하여) 장애가 나지 않도록 응용 프로그램을 설계할 때 ‘가격 기록’을 잘 사용하는 것은 중요합니다. 고객에게도 각각 배치 전략이있습니다만 일반적으로 두 가지 개의 성공 패턴이 있습니다. 하나는 가격 변동폭이 적은 용량 풀 (인스턴스 유형 및 가용 영역)을 선택하거나, 여러 용량 풀에 필요한 용량을 분산 배치하는 것입니다.

주식 시장이라는 좋은 예가 있습니다. “가장 좋은 성능”의 용량 풀을 찾아 정기적으로 그 선택에 대해 다시 확인 할 수 있으며, 관련이 없는 풀에 걸쳐 분산시켜 장애 위험을 크게 줄일 수 있습니다.


Jeff : 용량 풀의 배치 전략에 대해 자세히 알려주세요.

Joshua : 가격 변동 폭이 안정적인 풀을 찾기 위해 최근 Spot 가격 기록을 분석하는 아이디어가 있습니다. 용량 풀에서 입찰 희망 가격(매 시간에 지불한 최대 가격)을 초과 한 최근 시점부터 현재까지 기간으로 분석하는 방법입니다. 과거의 경향이 결코 미래의 결과를 보장하는 것은 아니지만, 처음 패턴을 보기에 좋은 방법입니다. 이 전략은 개발 테스트 환경이나 장시간 분석 작업을 하는 인스턴스에 좋습니다. Amazon EMR 클러스터에 용량을 추가하는 방법으로도 좋구요. 이익을 극대화하면서 용량 풀을 계속 사용하실 거라면, 입찰 후 어느 정도 경과 한 후에는 가격을 재검토하는 것도 추천합니다.

Jeff : 고객들이 Spot 가격 기록을 어떻게 볼 수 있습니까?
Dmitry : 콘솔 또는 SDK 및 AWS 명령어 인터페이스 (CLI) 프로그램에서 볼 수 있습니다.
또한, Spot 페이지에서 접근 가능한 웹 기반 Spot Bid Advisor을 새롭게 만들었습니다. 이 도구는 여러 가용 영역 평균 통계를 표시하고 가격 변동이 작은 인스턴스 유형을 찾아기 쉽습니다. 리전, 운영 체제, 입찰 가격 (온 디멘드의 25 %, 50 %, 100 %)을 선택하면 지난 주 또는 매월 변화, 과거 빈도를 표시합니다.

GitHub의 저장소 aws-spot-labs 에 또 다른 예가 있습니다. get_spot_duration.py 스크립트로 Spot 가격 정보를 취득하여 입찰 희망 가격을 초과한 기간에 근거하여 인스턴스 유형 및 가용 영역을 사용할 수 있습니다.


Jeff : 그렇군요. 큰 인스턴스 풀을 선택하고 정기적으로 다시 살펴봐야 하는군요.

Dmitry : 네. 그게 좋은 출발점입니다. Spot을 보다 쾌적하게 사용하는 다음 단계로는 동시에 여러 풀을 사용하는 용량을 분산하는 것입니다. 왜냐하면 각 용량 풀은 물리적으로 분리되어, 가격에 관련된 이슈가 거의 없기 때문입니다. 여러 용량풀이 단기간에 동시에 가격이 상승하는 일은 매우 드뭅니다. 이를 통해 문제가 발생할 영향을 줄일 수 되고, 필요한 용량을 확보하는 데 충분한 시간을 얻을 수 있습니다.

Joshua : 이러한 용량 분산 방법은 장기적인 가격 대비 성능도 개선합니다. 만약 여러 인스턴스 유형 및 가용 영역에 균등하게 용량을 분산하고 시간 단가는 여러 풀에서 과금되므로 결과적으로 좋은 가격 대비 성능입니다.


Jeff : 너무 좋네요. 그 다음 단계가 될 입찰 전략은 어떨까요?
Joshua : 지불하고자하는 가격에 적절하게 입찰하는 것이 중요합니다. 부당하게 높은 Spot 입찰을 하는 것보다 여러 용량 풀을 신중하게 선택하고 거기에 애플리케이션을 분산 배치하여 고가용성을 제공하는 것이 좋습니다. 현재 용량 풀 가격이 상승하고 있다는 것을 발견하면, 그것은 수요가 증가하고 있다는 의미입니다. 문제를 피하기 위해 더 저렴한 풀에 업무를 마이그레이션하거나 높은 가격으로 놀고 있는 인스턴스를 종료할 것을 추천합니다.


Jeff : 더 정교한 입찰 전략을 사용하는 고객이 있습니까?

Dmitry : 많은 고객이 Spot을 사용할 수록 경쟁력 면에서 중요합니다. 프로덕션 환경을 모두 Spot에서 실행하는 고객도 있습니다. 물론 그들의 SLA를 충족하도록 추가 엔지니어링이 필요하지만… Spot에 대한 생각에 대해 의미 있는 이야기는 “클라우드 친화적” 응용 프로그램이 Spot에 의한 효과를 얻고 있다는 것입니다. 설계에 의한 복원력, 유연성, 가격을 인식하고 있다는 것을 의미합니다. 가격을 인식하고 가장 비어있는 용량 풀에 응용 프로그램을 배포 할 수 있습니다. 특히 신생 기업은 빨리 확장시키고 보다 저렴 컴퓨팅 인프라를 사용하기 위해 독창적으로 Spot을 사용하고 있습니다.

Joshua : Auto Scaling, Spot 모음, Elastic MapReduce와 같은 도구는 Spot을 조합 할 수 있으며, 특별한 추가 개발을 하지 않고 여러 용량 풀을 동시에 사용할 수 있습니다.

Spot 인스턴스에 대한 정보를 얻기 위해 앞으로도 블로그를 계속확인해 주십시오! 언제든지 여러분의 Tips(과 질문)을 댓글에 써주세요.

– Jeff ;

이 글은 Building Price-Aware Applications Using EC2 Spot Instances의 한국어 번역입니다.

리눅스 인스턴스를 Simple AD에 추가하는 방법

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

EC2 인스턴스를 AWS Directory ServiceSimple 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 CloudWatchAmazon 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의 한국어 번역입니다.

AWS CLI를 통한 빠른 인스턴스 타입 변경 방법

클라우드 컴퓨팅 장점 중의 하나는 민첩성(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 활용 기술 팁을 보내드리는 코너로서, 이번 글은 박철수 솔루션즈 아키텍트께서 작성해주셨습니다.

신규 오토 스케일링 반응형 정책 업데이트

Auto Scaling은 서비스 트래픽 변화에 따라 Amazon Elastic Compute Cloud (EC2) 인스턴스를 추가 혹은 제거함으로서 효율적인 시스템 운영을 돕습니다.

이 글에서 지금까지 AWS에서 오토스케일링을 사용하는 방법을 한번 집중 해부해보고, 이에 대해 그 이면에서 어떤 일들이 일어나는지 사항을 먼저 이야기 해보면 좋을 것 같습니다.

리소스 실행 및 종료 – 오토 스케일링을 위해서는 EC2 인스턴스를 필요한 만큼 실행하거나 없애야 하는데, AWS API를 활용하여 RunInstancesTerminateInstances 그리고 부가적으로 DescribeInstances를 사용 합니다.:

리소스 모니터링 – CPU 사용량, 네트웍 트래픽 등 다른 요소에 의해서 인스턴스가 개별적 혹은 그룹으로 얼마나 많은 리소스를 사용하느냐는 스케일링을 선택하는 주요 기준이고 Amazon CloudWatch를 활용해 왔습니다:

알림 보내기 – 자원의 사용량을 추적하여 스케일-인/아웃 시에 CloudWatch를 통해 알림을 보낼 수 있습니다.:

스케일링 실행 – 마지막으로 알람이 오면 실행을 하는데 이는 오토스케일링이 시작이 되는 것입니다.

이 동작은 특정 오토스케일링 그룹 내에서 실행 되며, 이에 따라 특정 인스턴스를 시작 및 종료를 하게 되며 특정 퍼센테이지 혹은 숫자를 통해 인스턴스 숫자를 조정합니다.

신규 스케일링 단계별 정책
오늘 부터 이전 보다 더 유연한 새로운 오토 스케일링 정책을 수행하는 단계를 소개해 드립니다.

그 목적은 트래픽이나 로드가 갑자기 증가할 때 대응하는 오토 스케일링 시스템을 만드는데 있습니다. 이제 magnitude라는 알람을 기반으로 원하는 스케일링 정책을 정할 수 있습니다. 예를 들어 평균 CPU 사용량을 50%로 잡고 있는데, 조금씩 CPU가 늘어나는 구간 즉, 50-60% 혹은 60-70%, 80% 이상 등 다양한 구간에서 인스턴스를 추가할 수 있습니다.

위에서 보시다시피 고정된 숫자의 인스턴스가(1, 2, 4 또는 8) 그룹에 있습니다. 사용 퍼센티지 기반으로 인스턴스 숫자를 정하고 단계별로 50%, 100%, 150% 및 200%로 증가시킬 수 있습니다. 이러한 비율은 스케일을 줄일때도 정책을 활용할 수 있습니다.

이러한 단계별 정책을 통해 알람을 통해 평가하여, 스케일링이 일어나는 도중에 인스턴스 헬스체크를 해서 문제가 있는 것은 새 것으로 교체합니다. 이를 통해 더 빠른 요구에 응답할 수 있습니다. CPU 로드가 계속 올라갔다면, 정책 중 첫 번째 단계가 시작되어 첫 워밍업(약 120초 정도) 기간 동안 더 빠르게 반응할 수 있습니다. 시스템 로드가 계속 증가하더라도 유연하게 대처할 수 있습니다. 여러분이 같은 리소스에 대해 다중 단계의 (CPU 사용량 및 네트워크 트래픽을 기반으로) 스케일링 정책을 만들 수 있다면, 갑작스런 트래픽에도 유연하게 대처할 수 있을 것입니다.

새로운 오토스케일링 정책은 AWS Command Line Interface (CLI)이나 Auto Scaling API를 사용하시면 됩니다.

새로운 기능은 오늘 부터 바로 사용 가능합니다.

Jeff;

이 글은 Auto Scaling Update – New Scaling Policies for More Responsive Scaling의 요약 편집입니다.

AWS Lambda 동경 리전에 출시!

오늘 부터 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)를 번역 및 편집하였습니다.

EC2 스팟 인스턴스 – 베스트 프랙티스 소개

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

새 T2.Large 인스턴스 출시

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

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

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

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

인스턴스명 vCPUs 기본 성능 플랫폼 RAM (GiB) CPU Credits / Hour 가격/시간당(리눅스) 가격/월간(리눅스)
t2.micro 1 10% 32-bit or 64-bit 1 6 $0.013 $9.50
t2.small 1 20% 32-bit or 64-bit 2 12 $0.026 $19.00
t2.medium 2 40% 32-bit or 64-bit 4 24 $0.052 $38.00
t2.large 2 60% 64-bit 8 36 $0.104 $76.00

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

신규 M4 인스턴스 출시 및 M3 & C4 가격 인하!

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 인텔 터보 부스터가 제공됩니다. 아래는 자세한 사양입니다.

인스턴스 타입 vCPU 숫자
RAM
인스턴스 스토리지 네트워크 성능 EBS 최적화
m4.large 2 8 GiB EBS 만 중간 450 Mbps
m4.xlarge 4 16 GiB EBS 만 높음 750 Mbps
m4.2xlarge 8 32 GiB EBS 만 높음 1,000 Mbps
m4.4xlarge 16 64 GiB EBS 만 높음 2,000 Mbps
m4.10xlarge 40 160 GiB EBS 만 10 Gbps 4,000 Mbps

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

EC2 인스턴스 출시 기록

지난 밤 Steve Goldsmith ( ITOC Australia  AWS의 주요 컨설팅 파트너 및 예전에  AWS Customer Obsession 수상자)가 저에게  Amazon Elastic Compute Cloud (EC2) 인스턴스 출시 기록이 있는지 물어보았습니다.

생각해 보니 그런 기록이 없어서 잠시 작업을 해서 아래와 같이 출시 기록을 남겨보았습니다. 여러분에게 참고가 되시길 바랍니다.

Jeff;

본 글은 EC2 Instance History의 한국어 번역입니다.