Category: Compute


Amazon S3 기능 추가 – 알람 기능 및 버킷 측정 기준 향상

2006년 봄에 Amazon Simple Storage Service (S3)간단한 블로그 공지로부터 시작했습니다. 그동안 간편하지만 강력한 서비스 모델을 유지해 오면서, 가격 인하를 포함하여 중복을 감소한 스토리지, VPC 엔드 포인트, 리전간 복제 기능이벤트 노티피게이션 기능 등을 추가해 왔습니다.

작년에 이벤트 알림 기능을 추가한 이후 다양한 객체 이벤트에 대한 알림을 지원해 왔습니다. 예를 들어, PUT, POST, Copy, Multipart Upload 등의 이벤트가 있을 때 알람을 지원합니다. 이러한 알람 통지 기능은 모든 버킷의 객체가 대상입니다. 오늘 부터 객체들이 삭제 되었을 때, 접두사 및 접미사(prefixes 및 suffixes) 필터링을 지원합니다. 또한, 버킷 수준에서 Amazon CloudWatch 메트릭 지원합니다.

알림 통지 기능 향상
또한, S3 버킷에서 객체가 삭제 된 경우에 알람을 통지하도록 설정할 수 있습니다. 다른 형식의 통지와 마찬가지로, 삭제 통지는 SQS 큐(Queue)나 SNS 토픽(Topic), AWS Lambda function에 연결해서 보낼 수 있습니다. 이러한 객체 삭제 알림은 DELETE 수행이 될 때 S3 객체를 관리하기 위한 인덱스 업데이트 및 데이터 추적 등에 사용할 수 있습니다.

또한, 객체 이름의 접두사와 접미사를 사용한 필터를 사용할 수 있습니다. 다음 예제에서는 특정 버킷에서 “images /” 접두사 “.png” 접미사의 객체가 삭제 된 경우에 알람을 통지 할 수 있습니다.

관리 콘솔에서 여러 개의 알람 통지를 생성 및 편집 할 수 있습니다.

CloudWatch 스토리지 측정 기준
Amazon CloudWatch는 AWS 서비스 및 여러분이 추가한 응용 프로그램의 측정 값 추적 및 알람 기능을 가지고 있습니다. 알람 설정은 경과 시간 동안 임계값을 초과 할 때 발생합니다. S3의 모니터 및 알람 기능을 S3에 대해서도 할 수 있습니다. 지원되는 측정 지표는 버킷 당 총 바이트 수 (표준 및 RRS)과 총 객체 수입니다. 측정 기준에 따른 결과는 AWS 관리 콘솔에서 볼 수 있습니다.

측정 기준은 빌링과 함께 마찬가지로 매일 업데이트 합니다. 또한, 스토리지 라이프 사이클 규칙 등에 의해 Glacier로 이동하도록 설정 된 객체는 제외됩니다.

지금 사용 가능
이 기능들은 오늘 부터 바로 사용이 가능합니다.

Jeff;

이 글은 Amazon S3 Update – Notification Enhancements & Bucket Metrics의 한국어 번역입니다.

리눅스 인스턴스를 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 활용 기술 팁을 보내드리는 코너로서, 이번 글은 박철수 솔루션즈 아키텍트께서 작성해주셨습니다.

DynamoDB 신규 기능 – 스트림 및 Lambda 데이터 트리거 + 리전간 복제

Amazon DynamoDB에 여러 가지 새로운 소식이 있습니다. 먼저 DynamoDB 스트림 기능이 추가되었으며, AWS Lambda를 통해 스트림 데이터 활용이 가능합니다. 두 번째는 하나의 DynamoDB 테이블에서 다른 테이블로 복제가 가능하고, 리전(Regions)을 넘어서도 가능해졌습니다.

지금 부터 자세히 살펴 보겠습니다.

DynamoDB Streams
지난 가을에 re:Invent 행사 며칠 전 DynamoDB 스트림에 대한 미리 보기 기능을 출시했습니다. 많은 사용자들이 DynamoDB 테이블의 변경을 추적하기를 원하셨기 때문이었습니다.

이 기능은 오늘부터 정식으로 사용할 수 있으며, 바로 DynamoDB 테이블에 기능을 활성화하면 모든 변경 사항(put, update, delete)를 24시간 언제든지 stream record로서 실시간으로 스트리밍으로 받을 수 있습니다. 여러 개의 스트림 레코드는 빠르고 효율적인 처리를 위해 샤드(shard)에 그룹으로 만들어서 하나의 단위로 변환됩니다.

테이블 변경 순서의 상대적인 위치는 하나의 고유키로 만들어서 샤드안에 저장됩니다. 이를 통해 항목 변화를 정확히 추적할 수 있도록 샤드 내에 스트림 레코드를 쉽게 처리할 수 있게 됩니다.

“Interactive Intelligence는 Amazon DynamoDB의 리전간 복제 기능을 처음 테스트 해보고 매우 놀라웠습니다. PureCloud 플랫폼이 이 기능을 처음 도입을 해보고, 빠르고 쉽게 AWS 리전간 데이터가 쉽게 복제되어서 운영 및 기술 지원 비용을 확실히 감소할 수 있게 되었습니다.”
Mike Szilagyi, PureCloud Service Technology 부사장
Interactive Intelligence

프로그램 코드를 사용해서 샤드에서 레코드를 추출한 후, 변환 받은 다음 필요한 기능을 수행할 수 있습니다. 각 레코드는 미리 생성된 테이블 쓰기 용량 내에서 두 번 정도에 변환 받을 수 있습니다.

스트림 기능을 활성화하려면, 테이블을 만들 때 CreateTable를 호출하여 스트림에 대한 파라미터를 넣어 만들 수 있습니다. 기존 테이블에서도 UpdateTable에서 비슷한 파라미터를 넣으시면 됩니다. 각각의 경우, 표준 스펙에 스트림을 시작할지 말지에 대한 플래그(flag)와 보기 형식(저장 및 반환 항목키 만, 새로운 이미지, 예전 이미지 혹은 둘 다)를 포함해야 합니다.

좀 더 자세한 사항은 신규 기능에 대한 DynamoDB Streams Developer Guide를 참고하시기 바랍니다.

추가 비용 없이 여러분의 테이블에 스트리밍 기능을 바로 만드실 수 있으며, 스트림에서 데이터를 읽을 때만 과금이 되는데 GetRecords를 통한 호출 시 1MB까지 데이터를 꺼내 올 수 있습니다. 좀 더 자세한 것은 요금 정책을 참고하시면 됩니다.

DynamoDB 스트림 + Lambda = 데이터베이스 트리거
AWS Lambda는 (현재 Node.js와 자바)를 통해 만든 프로그래밍 코드를 클라우드 내에서 실행하는 신개념의 클라우드 함수입니다.  장애나 확장성에 대한 고려 없이도 100 밀리초 단위로 실행한 시간 만큼만 과금을 하는 경제적인 모델을 가진 서비스입니다.

오늘 DynamoDB 스트림 기능을 정식 출시함으로서 테이블이 더 커지거나 쿼리가 많아질 때, 확장성을 고려하지 않고도 기존의 프로그래밍 코드보다 훨씬 적은 노력만으로 (Lambda를 이용하여) 스트림 레코드를 처리할 수 있습니다.

즉,  이 두 가지를 조합해서 간단한 NoSQL 스타일의 데이터베이스 트리거를 만들 수 있습니다. 예전에 관계형 DB의 트리거는 엔진 내에서 구현되었고, 때문에 엔진에서 정의된 동작만 수행할 수 있는 제한이 있었습니다. Lambda를 이용하면, 데이터 추가, 삭제 및 테이블 항목 변경이 일어날 때 마다 관련되는 동작을 원하는 대로 구현할 수 있습니다. 신규 혹은 과거 이미지의 변경 사항을 분석하고, 데이터 양식을 변경하거나 특정 비지니스 로직을 동기 혹은 비동기로 강제하는 것도 가능합니다. 여러분이 좀 더 애플리케이션 개발에 중요한 부분에 집중하도록 Lambda를 통해 호스팅과 확장 문제를 관리하게 만들어 둘 수도 있습니다.

Lambda 코드를 설정해서 스트림 변경을 확인하는 것도 간단합니다. 새 테이블을 통해 하는 방법을 간단히 살펴 보겠습니다. 먼저 Lambda를 위한 IAM 역할을 만들고, 관리 콘솔에서 Create Lambda function을 실행해 봅니다. 예제들 중 dynamodb-process-stream를 선택해 보겠습니다.

먼저 Lambda 함수 예제 코드와 이벤트 소스를 설정합니다.콘솔 화면에 이벤트 소스로 user_table이라는 테이블을 연결해서, 100개까지의 스트림 레코드를 받아서 새로운 레코드로 처리하는 기능을 수행해 보겠습니다.

예제에는 현재 상태를 테스트해 보는 목적의 코드가 있으며, 간단한 이름을 정한 후 (ProcessUserTableRecords) DynamoDB에 접근할 수 있는 IAM 역할을 선택합니다.

이제 이벤트 소스를 활성화 해보겠습니다. (Lambda 코드를 테스트해 본 후에 실제 동작 하도록 하는 게 좋습니다.)

Create function을 눌러서 이벤트 소스로서 테이블 업데이트 스트림을 처리하는 함수를 만듭니다. Lambda 콘솔의 Event sources탭에서 상태와 다른 이벤트 소스도 보실 수 있습니다.

자, 이제 설정이 다 끝났고 여기서 테이블의 업데이트 스트림을 연결 한 후, 레코드를 처리해 봅시다. 이를 위해 DynamoDB 콘솔로 옮겨가서 데이터를 몇 개 추가해서 스트림에 변화가 생기도록 해 보겠습니다.

Lambda 콘솔에 들어와 보면, 기대했던 동작이 일어났는지 확인해 볼 수 있습니다. 모니터링 탭을 클릭해 보면 오류 없이 Lambda 함수가 두 번 실행된 것을 알 수 있습니다.

일단 잘 동작한 것으로 보고 CloudWatch 로그를 좀 더 자세히 보겠습니다.

만약 제가 실제 애플리케이션을 만들었다면, 기본 예제에 더 많은 기능을 추가해서 만들어 볼 수 있었을 것입니다.

AWS 고객인 Mapbox는DynamoDB Streams와 Lambda를 이용한 후기를 Scaling the Mapbox Infrastructure with DynamoDB Streams를 통해 소개하였습니다.

DynamoDB와 Lambda를 결합한 구현 방식에 대해서는 Using DynamoDB Streams and AWS Lambda 문서를 참고하시기 바랍니다. DynamoDB Trigger에는 추가 요금이 없고 Lambda 함수 실행에 대한 과금만 이루어 지며 자세한 것은 Lambda 요금 정보를 참고하시기 바랍니다.

이러한 조합을 통해 여러분의 애플리케이션이 더 간단하고 강력하며 반응성이 높은 기능을 추가할 수 있기를 기대해 봅니다.

리전(Region)간 DynamoDB 복제 기능
DynamoDB 스트림 기능과 아울러 AWS 리전 간 데이터를 쉽게 복제할 수 있는 기능을 소개해드립니다. 이 애플리케이션은 작년에 저희가 배포한 DynamoDB Cross Region Replication library를 통해 구현한 것입니다. (앞으로도 이 라이브러리를 여러분의 앱에 사용하셔도 됩니다.)

이를 통해 DynamoDB를 여러개의 리전으로 중복으로 복제할 수 있는데, 이는 재난 복구나 여러 지역에서 낮은 지연을 통해 접근이 필요한 여러가지 이유가 있을 수 있습니다. 보시다시피 아주 간단하게 리플리카를 만들어서 운영할 수 있게 됩니다.

이 앱은 AWS Elastic Beanstalk에서도 실행할 수 있고, Amazon EC2 Container Service를 사용할 수 있으며, AWS CloudFormation 템플릿으로도 구현 가능합니다. DynamoDB 콘솔에서 초기화 할 수 있으며 CloudFormation을 통해 스택이나 콘테이너를 생성하기 위한 템플릿 정보를 입력할 수 있습니다.

스택(Stack, 템플릿을 통해 만들어지는 AWS 자원에 대한 이름)을 입력하고 Next를 눌러 파라미터를 입력할 수 있습니다. (대부분 기본값을 그대로 두시면 됩니다.)

메타테이터 테이블은 복제에 필요한 정보를 포함합니다. 이는 어떤 테이블을 복제할 것인지 어디에 저장할 것인지를 설정합니다. 복제용 앱을 띄운 후, 온라인 설정 화면에 접속하술 수 있습니다. (CloudFormation 템플릿이 URL을 만들어 줍니다.)

이 기능 또한, 추가 요금이 없습니다. 이 기능을 활용하기 위한 기본적인 DynamoDB 리소스(미리 설정된 입출력 한도, 복제 테이블의 저장 용량, 리전간 데이터 전송 비용, 스트림으로 데이터 읽기 및 애플리케이션을 제어하는데 필요한 EC2 인스턴스 및 SQS 서비스 이용 비용 등)에 대해서만 과금이 됩니다. 더 자세한 것은 DynamoDB 요금페이지를 참고하시기 바랍니다.

리전 간 복제에 대한 더 자세한 정보는 Cross Region Replication를 참고하시기 바랍니다.

Jeff;

이 글은 DynamoDB Update – Triggers (Streams + Lambda) + Cross-Region Replication App의 한국어 번역입니다.

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

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

Alexa Skills Kit, Alexa Voice Service 및 Alexa Fund 소개

Amazon Echo는 음성 인식을 위해 만들어진 새로은 기기입니다. Echo는 AWS 기반 클라우드 음성 서비스인 Alexa와 연결됩니다. Alexa에게 질문에 대한 답을 얻거나, 음악을 재생하거나 뉴스 검색 결과 등을 요청할 수 있습니다.

Amazon Echo 근처에서 부팅 단어(Alexa 또는 Amazon 중 하나)를 말하고 질문이나 요청을 할 수 있는데 예를 들어, “Alexa 시애틀 매리너스의 다음 경기는 언제에요?” 혹은 “Alexa 시애틀에 비가 오고 있나요?”라고 물어보면, 클라우드기반 음성 인식 소프트웨어가 여러분의 질문을 이해하고 처리합니다.

오늘 Alexa Skills Kit(ASK)를 발표하여 Alexa 위한 새로운 음성 기반(음성 구동) 기능을 구현할 수 있게 되었습니다. 개발자들이 몇 줄의 코드로 몇 분만에 기존 서비스를 Alexa에 연결할 수 있습니다. 대화 인식과 자연어 처리에 대해 아무것도 배경 지식이 없다하더라도 몇 시간 만에 완전히 새로운 음성 인식 환경을 구축 할 수 있습니다.

이를 위해 미리보기 형태로 개발자 대상으로 Alexa Voice Service (AVS)을 공개합니다. 하드웨어 제조 업체와 Internet of Things (IoT) 관심자들께서는 오늘 등록해 주십시오. 스피커, 마이크 및 인터넷 연결이 되는 모든 장치는 몇 줄의 코드로 Alexa와 통합 할 수 있습니다.

여러분의 상상력을 자극하는 데 도움이 될 음성 기술 관련 혁신을 촉진하기 위해 Alexa Fund도 시작합니다. Alexa Fund는 개발자와 제조 업체, 그리고 고객의 삶을 향상시키기 위해 사람 목소리에 대해 새로운 프로젝트를 지원하기 위해 최대 1억 달러를 투자합니다.

ASK와 AWS Lambda
AWS Lambda를 사용하여 Alexa위한 새로운 기술을 만들 수 있습니다. Node.js를 사용하여 코드를 쓰고, AWS Management Console을 통해 Lambda에 업로드만 하면 됩니다. 업로드 콘솔에서 만든 샘플 이벤트를 사용하여 테스트를 한 후, Alexa Developer Portal에 로그인하거나 포털에서 (Alexa App 제작 과정을 따라) 코드 등록, ARN (Amazon Resource Name)을 응용 프로그램에 연결하는 데 사용할 수 있습니다. 테스트가 완료되면 응용 프로그램을 Echo의 소유자가 사용할 수 있도록 업로드 할 수 있습니다. Lambda는 확장 가능한 무장애 클라우드 환경에서 여러분의 코드를 호스팅하고 실행합니다. Alexa 기술을 지원하는 기능은 Lambda 무료 서비스 내에서 가능하며, Developing Your Alexa Skill as a Lambda Function을 참조하십시오.

웹 서비스로서 ASK
Amazon Elastic Compute Cloud (EC2)나 AWS Elastic Beanstalk 또는 기존 데이터 센터 서버에서도 응용 프로그램을 웹 서비스로 구축 할 수 있습니다. 음성 인식 서비스는 인터넷 접근이 가능해야하며, Alexa 응용 프로그램 인터페이스 사용을 준수해야합니다. 443 포트에서 HTTPS over SSL/TLS를 지원하고, 서비스 엔드 포인트의 도메인 이름과 일치하는 SSL 인증서를 제공하면 됩니다. 여러분의 코드에서는 실제로 Alexa에서 온 요청인지 확인하고, 시간 기반 메시지 서명을 확인할 필요가 있습니다. 이 옵션에 대한 자세한 정보는 Developing Your Alexa App as a Web Service를 참고하시기 바랍니다.

더 자세한 정보
ASK, AVS와 Alexa Fund에 관한 더 많은 정보는 아래 링크를 참고하시기 바랍니다.

– Jeff

이 글은 New – Alexa Skills Kit, Alexa Voice Service, Alexa Fund의 한국어 번역입니다.

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