Category: Amazon CloudWatch

Amazon Kinesis는 대용량 스트리밍 데이터를 클라우드에서 손쉽게 처리할 수 있도록 도와 줍니다.

Amazon Kinesis 플랫폼은 3개의 서비스로 구성되어 있습니다: Kinesis Streams은 개발자가 자신의 스트리밍 데이터 처리 애플리케이션을 구현할 수 있습니다; Kinesis Firehose를 통해 스트리밍 데이터를 저장하고 분석하기 위해 AWS에 저장하는 기능에 초점을 맞추었습니다; Kinesis Analytics 를 통해 스트리밍 데이터를 표준 SQL을 통해 분석 할 수 있습니다.

많은 AWS 고객이 스트리밍 데이터를 실시간으로 수집 · 처리하는 방식으로 Kinesis Streams와 Kinesis Firehose을 이용​​하고 있습니다. 이는 완전 관리 서비스이기 때문에 사용 편의성을 높아 스트리밍 데이터 처리를 위한 인프라를 직접 관리하는 대신 응용 프로그램에 개발하는 시간에 투자를 할 수 있다는 장점이 있습니다.

오늘 Amazon Kinesis Streams와 Kinesis Firehose 관한 3개의 새로운 기능을 신규 발표합니다.

• Elasticsearch 통합– Amazon Kinesis Firehose는 Amazon Elasticsearch Service에 스트리밍 데이터를 전달할 수 있습니다..
• 강화된 모니터링 수치 제공– Amazon Kinesis는 샤드 단위 메트릭을 CloudWatch로 매 분당 보낼 수 있습니다.
• 유연성 확보– Amazon Kinesis에서 시간 기반의 반복자를 이용하여 레코드를 수신 할 수 있습니다.

Amazon Elasticsearch Service 통합
Elasticsearch는 인기있는 오픈 소스 검색 · 분석 엔진입니다. Amazon Elasticsearch Service는 AWS 클라우드에서 Elasticsearch를 손 쉽게 설치하고, 높은 확장성을 가지고 운영할 수 있는  관리 서비스입니다.  오늘 부터 Kinesis Firehose 데이터 스트림을 Amazon Elasticsearch Service 클러스터에 배포 할 수 있게되었습니다. 이 새로운 기능은 서버의 로그 및 클릭 스트림, 소셜 미디어 트래픽 등으로 인덱스를 생성하고 분석 할 수 있습니다.

전송 받은 레코드 (Elasticsearch 문서)는 지정한 설정에 따라 Kinesis Firehose에서 버퍼링 된 후,여러 문서를 동시에 인덱스를 만들 수 있도록 벌크 요청을 사용하여 자동으로 클러스터를 추가합니다. 또한, 데이터는 Firehose로 전송하기 전에 UTF-8로 인코딩 된 단일 JSON 개체에 두어야 합니다. (관련 정보는 Amazon Kinesis Agent Update – New Data Preprocessing Feature를 참조하십시오).

이제 AWS 관리 콘솔을 통한 설정 방법을 알아보겠습니다. 대상(Amazon Elasticsearch Service)를 선택하고 전송 스트림의 이름을 입력합니다. Elasticsearch 도메인 (livedata 예제)을 선택 인덱스로 지정하고, 인덱스 주기(없음, 시간별, 매일, 매주, 매월)를 선택합니다. 또한, 모든 문서 또는 실패한 문서의 백업을받을 S3 버킷을 지정합니다 :

그리고 버퍼의 크기를 지정하고 S3 버킷에 전송되는 데이터의 압축 및 암호화 옵션을 선택합니다. 필요에 따라 로깅을 사용하고 IAM 역할을 선택합니다 :

1분 정도 이후에 스트림이 준비 됩니다 :

I can view the delivery metrics in the Console:

스트리밍 데이터가 Elasticsearch에 도달 한 후에는 Kibana와  Elasticsearch 쿼리 언어에 의해 데이터 시각화를 할 수 있습니다.

즉, 통합을 통해 여러분의 스트리밍 데이터를 수집하고 Elasticsearch에 전달 하기 위한 처리 방법은 매우 간단합니다. 더 이상 코드를 작성하거나 자체 데이터 수집 도구를 만들 필요가 없습니다.

샤드 기반 통계 모니터링
모든 Kinesis 스트림은 하나 이상의 샤드로 구성되어 있으며, 모든 샤드는 일정량의 읽기 · 쓰기의 용량을 가지고 있습니다. 필요에 따라 스트림에 샤드를 추가하면 스트림의 용량은 증가합니다.

여러분은 각 샤드의 성능을 파악하기위한 목적으로 샤드 단위의 통계 기능을 활성화 할 수 있게되었습니다. 샤드 당 6개의 메트릭이 있습니다. 각 통계는 1 분에 한 번 보고되고, 일반 통계 단위의 CloudWatch 요금이 부과됩니다.  이러한 신규 기능은 특정 샤드에 부하가 편중되지 않았는지, 다른 샤드와 비교하여 확인하거나 스트리밍 데이터의 전송 파이프 라인을 통해 비효율적 인 부분을 발견 및 변경할 수 있게 됩니다. 

아래에는 새로이 측정되는 수치입니다.

IncomingBytes – 샤드로 PUT이 성공한 바이트 수.

IncomingRecords – 샤드로 PUT이 성공한 레코드.

IteratorAgeMilliseconds –샤드에 대한 GetRecords 호출이 취소 된 마지막 레코드의 체류 시간 (밀리 초). 값이 0 인 경우, 읽은 레코드가 완전히 스트림에 붙어 있다는 것을 의미합니다.

OutgoingBytes – 샤드에서받은 바이트 수.

OutgoingRecords – 샤드에서받은 레코드 수.

ReadProvisionedThroughputExceeded – 매초 5 회 또는 2MB를 초과한 GetRecords 호출 수.

WriteProvisionedThroughputExceeded – 매 초 1000 기록 또는 1MB를 초과한 레코드의 수.

EnableEnhancedMetrics 를 호출하는 것으로  활성화 할 수 있습니다. 평소처럼, 일정 기간 동안 집계를 위해 CloudWatch API를 사용할 수 있습니다.

시간 기반 반복 기능
어떤 샤드에 GetShardIterator를 호출 시작점으로 지정하고, 반복 기능을 작성하여 애플리케이션에서 Kinesis 스트림 데이터를 읽을 수 있습니다. 기존의 시작점 선택 (시퀀스 번호 시퀀스 번호 뒤에 가장 오래된 기록, 가장 새로운 레코드)에 추가로 타임 스탬프를 지정할 수 있게되었습니다. 지정한 값 (UNIX 시간 형식)은 읽고 처리하려고하는 가장 오래된 레코드의 타임 스탬프를 나타냅니다.

— Jeff;

이 글은 Amazon Kinesis Update – Amazon Elasticsearch Service Integration, Shard-Level Metrics, Time-Based Iterators의 한국어 번역입니다.

Amazon CloudWatch는 AWS 클라우드 리소스와 AWS에서 실행되는 어플리케이션을 위한 모니터링 서비스입니다. 게임 개발자나 시스템 운영자가 서비스를 관리하기 위해서는 필수적으로 CloudWatch를 사용해서 여러 서비스나 어플리케이션의 지표(metric)를 확인해야 합니다.

CloudWatch는 사용자의 편의를 위해서 전체 AWS 서비스에 대해 총 300개가 넘는 기본(Built-in) 지표를 제공합니다. 예를 들어, EC2나 RDS의 CPU 사용률이나 네트워크 트리팩 인/아웃,  ELB의 지연시간(Latency) 등이 대표적인 기본 지표입니다.

일반적인 시스템 모니터링은 기본 지표로 충분합니다만 메모리나 각 마운트된 디스크에 대한 사용률을 확인하려고 할 때는 맞춤형 지표(Custom Metric)를 생성해야 합니다.

맞춤형 지표 만들기
맞춤형 지표란 모니터링하고자 하는 통계치를 여러분이 선정해서 CloudWatch로 보내 관리하는 지표를 말합니다. 맞춤형 지표를 CloudWatch로 보내는 것은 매우 간단합니다. CLI를 사용해서 여러분이 정의한 통계치를 보낼 수 있습니다.

$ aws cloudwatch put-metric-data --metric-name PageViewCount --namespace "MyService" --value 2 --timestamp 2016-01-15T12:00:00.000Z

put-metric-data 명령을 사용해서 원하는 값을 원하는 지표 이름으로 지정해서 보낼 수 있습니다. 위 명령은 “MyService”라는 새로운 서비스명(네임스페이스)으로 지표 이름은 “PageViewCount”로 2의 값을 보내는 명령입니다.

물론 이렇게 명령을 수행하기 위해서는 EC2인스턴스에 CloudWatch에 대한 접근 권한이 있는 역할(Role)이 할당되었거나 aws configure 명령을 사용해서 접근키(access key)와 비밀키(secret key)를 설정해 주어야 합니다.

맞춤형 지표를 퍼블리싱하는 것은 다음 문서에 매우 상세히 설명되어 있습니다.
http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/DeveloperGuide/publishingMetrics.html

맞춤형 메트릭을 등록하면 CloudWatch 콘솔의 좌측 메뉴 화면 하단에 드롭다운 박스가 생성되면서 본인이 등록한 서비스 명을 확인해 볼 수 있습니다.

Amazon CloudWatch의 차원(dimensions)
CloudWatch에는 차원(dimensions)이라는 개념이 있으며, 이는 데이터를 구분하기 위한 기준을 말합니다. 예를 들어, 아래와 같이 데이터를 보냈다고 가정합시다.

$ aws cloudwatch put-metric-data --metric-name "FileSystem Utilization" --namespace "OurService" --value 16 --unit Percent --dimensions FileSystem="dev/xvda1" --timestamp 2016-01-12T12:00:00.000Z

이렇게 보낸 경우에는 CloudWatch 콘솔에서는 아래와 같은 FileSystem에 대한 차원 정보가 화면이 나오게 됩니다.

만약 여기에 차원을 다음과 같이 해서 추가해 봅니다.

--dimensions FileSystem="dev/xvda1",HostId="ami-249b554a",MountPath="/"

이제 기존 차원에 더해 새로운 차원이 등록 됩니다. 맞춤형 지표에 대해 데이터를 보는 새로운 뷰가 추가된 것을 확인할 수 있습니다.

메모리와 디스크에 대한 지표 등록

이제 리눅스 계열의 OS를 대상으로 메모리와 디스크에 대한 지표를 새로 작성해 보도록 하겠습니다. AWS 문서 중에 이를 수행하기 위한 Perl 스크립트 사용법이 소개되어 있는데 다음 링크에서 볼 수 있습니다.

http://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/DeveloperGuide/mon-scripts.html

위의 Perl 스트립트를 이용해서 메모리와 디스크에 대한 맞춤 지표를 등록할 수 있습니다. 그런데 이 스크립트는 오직 예제로 기술 지원은 제공하지 않습니다. 많은 시스템에서 대부분 제대로 동작하지만,  혹시라도 동작을 하지 않는다면 Perl 스트립트를 수정하면서 적용하는 것은 쉬운 일이 아닙니다.

이를 해결할 간단한 방법 중의 하나가 쉘 스크립트를 이용해서 커스텀 지표를 등록하는 방법입니다. 이 글을 위한 블로그를 위한 커스텀 지표 등록 쉘 스크립트는 아래에서 다운로드 받으실 수 있습니다.

http://awsblogskr.s3-ap-northeast-2.amazonaws.com/articles/2016-01-cloudwatch-seonyong/custom_metric2.sh

이제 이 스크립트에 대해 처음 부터 살펴보겠습니다. 먼저 타임스탬프 값을 얻어오기 위해서 다음과 같은 쉘 스크립트 함수를 정의합니다.

get_time_stamp() {
	time_stamp=$(date -u +%Y-%m-%dT%R:%S.000Z)
	echo "$time_stamp"
}

타입스탬프는 UTF를 기준으로 하기 때문에 –u 옵션을 사용해서 생성합니다. 이 타임스탬프 값은 커스텀 지표를 보낼 때의 타임스탬프 값으로 사용합니다.

다음은 인스턴스의 아이디를 가져오는 함수이다.

get_instance_id() {
	instance_id=$(curl http://169.254.169.254/latest/meta-data/ami-id)
	echo $instance_id
}

여기서 특이한 점은 curl 명령을 사용해서 아이디를 얻어옵니다. 169.254.169.254 주소는 Amazon EC2 인스턴스 내에서 해당 인스턴스의 메타 정보를 가져오는 주소값입니다.

메타정보나 유저정보를 가져올 수 있는 내용에 대해서는 다음 문서에 잘 설명되어 있다.
http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#instancedata-data-retrieval

리눅스 계열의 서버에서 메모리 정보를 가져오는 방법은 여러가지가 있습니다. top, free, vmstat 등 다양하지만 여기서는 /proc/meminfo 파일 정보를 읽어와서 awk로 가공하는 방법을 사용합니다.

free_mem_ratio=$(awk '/MemTotal:/{total=$2} \
       /MemFree:/{free=$2} \
       END{ \
        print (free*100/total); \
       }' /proc/meminfo 

위 코드는 파일을 읽어와서 MemTotal, MemFree정보를 이용해서 자유 메모리의 비율을 계산하는 부분입니다.

디스크의 경우에는 df –h 명령을 이용합니다. 명령의 출력은 시스템 마다 다양한데, 보려고 하는 값들을 탭으로 구분된 문자열로 생성합니다.

declare -a fs_list=$(df -h | awk '$1 ~ /^ *\/dev\//{print $1, "\t", $2, "\t", $3, "\t", $4, "\t", $5, "\t", $6}')

기준은 /dev/로 시작하는 문자열만을 뽑아서, 원하는 지표를 탭 공백이 있는 하나의 문자열로 만듭니다. 물론 /dev/로 시작하는 볼륨이 여럿 있을 수 있으므로 fs_list는 배열로 정의합니다.

이후에 한 문자열에서 원하는 탭 구분 정보를 루프를 돌면서 추출합니다.  이때 G, %같은 문자는 sed를 이용해서 제거합니다.

fs=$(echo $f_info       | sed 's/[G%]//g' | awk '{ print $1}' )

이렇게 만들어진 정보(여기서는 파일시스템, 전체 크기, 사용 중 크기, 사용 가능 크기,  마운트 포인트)를 변수에 담아 CLI를 통해 CloudWatch로 전달합니다.

$ aws cloudwatch put-metric-data --metric-name "Filesystem Utilization" --namespace "OurService" --value $fs_util  --unit Percent --dimensions FileSystem=$fs,HostId=$instance_id,MountPath=$fs_mount --timestamp $time_stamp

시스템에 따라 변경 필요가 있는 부분은 아래 두 부분입니다.

declare -a fs_list=$(df -h | awk '$1 ~ /^ *\/dev\//{print $1, "\t", $2, "\t", $3, "\t", $4, "\t", $5, "\t", $6}')
sed 's/[G%]//g'

출력되는 정보의 위치나 제거해야 할 문자 등이 시스템마다 조금씩 다를 수 있는데, 이는 약간의 주의만 기울이면 쉽게 바꿀 수 있습니다.

이제 쉘 스크립트를 crontab에 등록하면 쉽게 자동화 할 수 있습니다. 다음은 본 예제를 crontab으로 설정 한 것이다. 1분에 한번씩 커스텀 지표를 등록합니다.

$ crontab –e
*/1 * * * * /etc/cronjob/custom_metric2.sh

마지막으로 맞춤형 지표를 등록하는 CLI 명령이나, EC2에 대한 조작을 하는 CLI는 모두 계정별로 일정 정도 성능 제한이 설정되어 있습니다. 따라서 특정 시점에 한꺼번에 요청을 하면 명령이 수행이 안될 가능성이 있습니다. 각 요청은 가능한 동시가 아니라 분산되어 수행되도록 하는 것이 바람직합니다.

이와 관련한 참고 문서는 다음과 같습니다.

http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/APIReference/query-api-troubleshooting.html#api-request-rate

맞춤형 지표는 서비스 모니터링을 강화시키는 효율적인 도구입니다. 가능한 CLI와 연계해서 메트릭을 자동화하는 것이 바람직합니다.

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

Slack이 제공하는 협업을 위한 채팅을 통해 DevOps팀에서 실제 운영이나 서로 의견이나 정보를 다양한 플랫폼에서 동시에 주고 받을 수 있습니다. 예를 들어, 스마트폰 앱을 이용하거나 맥에서는 클라이언트 도구도 제공하고 있습니다. 메시지를 다양한 형태로 전달할 수 있는 Amazon SNS(Simple Notification Service)를 통해 이벤트를 발생시키고, AWS Lambda 는 SNS를 통해 전달된 메시지를 이벤트 트리거(Event trigger)를 통해 원하는 코드를 직접 수행 할 수 있습니다.

Slack은 API를 통해 메시지를 보낼 수 있는 방법을 제공하고 있습니다. AWS Lambda에서 알림을 받아 Slack 대화 채널로 메시지를 전달할 수 있습니다. 이에 관한 간략한 소개는 ChatOps를 위한 AWS Lambda를 통한 Slack 통합 샘플 코드에서 제공하고 있습니다. 이번 글에서는 좀 더 상세하게 해당 기능을 소개하여 쉽게 구성할 수 있도록 도움을 드리고자합니다.

1. AWS Elastic Beanstalk로 웹 서비스 구성하기
AWS Elastic Beanstalk을 사용하면 아주 쉽게 웹 서비스를 바로 만들 수 있습니다. 또한, ELB(Elastic Load Balancing)과 RDS(Relational Database Service)를 같이 생성해 주며, Auto Scaling Group도 자동으로 생성하여 트래픽을 분산하고 스케일링을 자동화 할 수 있습니다. Auto Scaling을 위한 Policy 역시 생성되며, 확장을 위한 조건 및 정책 변경이 가능합니다.

Beanstalk은 로컬에서 개발한 코드를 AWS 환경에 바로 배포가 가능합니다. 로컬에서 Git을 이용하여 개발 후 EB CLI(Elastic Beanstalk CLI)를 통해 쉽게 업로드하여 배포할 수 있습니다. 로컬 환경에 EB CLI를 설치하고 웹서비스는 Github awslabs에 있는 Node.js로 만들어진 예제를 사용하겠습니다.

• EB CLI 설치 가이드: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb-cli3.html
• Github Node.js Sample: https://github.com/awslabs/eb-node-express-sample

원하는 폴더를 생성 후 Github에서 예제를 다운로드합니다.

$ git clone https://github.com/awslabs/eb-node-express-sample.git
Cloning into 'eb-node-express-sample'...
remote: Counting objects: 56, done.
remote: Total 56 (delta 0), reused 0 (delta 0), pack-reused 56
Unpacking objects: 100% (56/56), done.
Checking connectivity... done.

Git사용을 위한 초기화를 진행합니다.

$ git init .
Reinitialized existing Git repository in /Users/ilho/Github/ebsample1/ebsample2/eb-node-express-sample/.git/

EB CLI를 설정하면 $ eb라는 명령을 통해 Elastic Beanstalk을 로컬 환경에서 구성하여 사용할 수 있습니다. 처음에 개발하는 폴더를 Root로 지정하고 Beanstalk 환경에 대한 설정을 진행합니다. eb init이란 명령으로 수행합니다. Beanstalk을 어느 Region에 생성할지부터 서비스 이름 등 기본적인 설정을 진행합니다. 현재 AWS Lambda가 도쿄 리전에서 지원하고 있기 이를 활용하기 위해 Elastic Beanstalk을 도쿄 리전에서 시작해 보겠습니다.

AWS Elastic Beanstalk은 Node.js외에도 Java, .NET, PHP, Python, Ruby, Go, Docker를 모두 지원합니다.

a0999b0edcf5:eb-node-express-sample ilho$ eb init
Select a default region
1) us-east-1 : US East (N. Virginia)
2) us-west-1 : US West (N. California)
3) us-west-2 : US West (Oregon)
4) eu-west-1 : EU (Ireland)
5) eu-central-1 : EU (Frankfurt)
6) ap-southeast-1 : Asia Pacific (Singapore)
7) ap-southeast-2 : Asia Pacific (Sydney)
8) ap-northeast-1 : Asia Pacific (Tokyo)
9) ap-northeast-2 : Asia Pacific (Seoul)
10) sa-east-1 : South America (Sao Paulo)
11) cn-north-1 : China (Beijing)
(default is 3): 8

Select an application to use
1) MyNewTest
2) ebsample1
3) [ Create new Application ]
(default is 3): 3

Enter Application Name
(default is "eb-node-express-sample"): ebsample2
Application ebsample2 has been created.
 
It appears you are using Node.js. Is this correct?
(y/n): y
Do you want to set up SSH for your instances?
(y/n): y
 
Select a keypair.
1) example_key1
2) example_key2
3) example_key3
4) example_key4
5) [ Create new KeyPair ]
(default is 5): 4

Beanstalk Application을 AWS 콘솔을 통해서도 만들 수 있지만, EB 명령을 이용하여 로컬에서 바로 생성을 시킬 수 있습니다. Eb create 명령을 사용하여 Beanstalk 환경을 구성합니다. 아래처럼 필요한 환경을 구성하면서 만들어지는 내용을 확인할 수 있습니다. 명령을 실행하여 AWS 콘솔에서 환경이 구성되는 것을 확인할 수도 있습니다. 환경이 구성 중에는 회색으로 표기되며 모두 정상적으로 만들어지면 녹색으로 변경되어 상태를 구분할 수도 있습니다.

$ eb create web2-env
WARNING: You have uncommitted changes.
Creating application version archive "app-5529-160121_085131".
Uploading ebsample2/app-5529-160121_085131.zip to S3. This may take a while.
Upload Complete.
Environment details for: web2-env
Application name: ebsample2
Region: ap-northeast-1
Deployed Version: app-5529-160121_085131
Environment ID: e-immiw7zwnk
Platform: 64bit Amazon Linux 2015.09 v2.0.6 running Node.js
Tier: WebServer-Standard
CNAME: UNKNOWN
Updated: 2016-01-20 23:51:35.207000+00:00
Printing Status:
INFO: createEnvironment is starting.
INFO: Using elasticbeanstalk-ap-northeast-1-1234567890 as Amazon S3 storage bucket for environment data.
INFO: Created load balancer named: awseb-e-i-AWSEBLoa-5F13U6NNRGJT
INFO: Environment health has transitioned to Pending. There are no instances.
INFO: Created security group named: awseb-e-immiw7zwnk-stack-AWSEBSecurityGroup-59FO03AWS48X
INFO: Created Auto Scaling launch configuration named: awseb-e-immiw7zwnk-stack-AWSEBAutoScalingLaunchConfiguration-42NJ3UCM61ZD
INFO: Added instance [i-00952c8f] to your environment.
INFO: Created Auto Scaling group named: awseb-e-immiw7zwnk-stack-AWSEBAutoScalingGroup-1QP37B57TQ43O
INFO: Waiting for EC2 instances to launch. This may take a few minutes.
INFO: Created Auto Scaling group policy named: arn:aws:autoscaling:ap-northeast-1:1234567890:scalingPolicy:6b7c0afe-3c1e-436d-a2e0-fcbc96d9c3c2:autoScalingGroupName/awseb-e-immiw7zwnk-stack-AWSEBAutoScalingGroup-1QP37B57TQ43O:policyName/awseb-e-immiw7zwnk-stack-AWSEBAutoScalingScaleUpPolicy-6FX2ZY0A9VIG
INFO: Created Auto Scaling group policy named: arn:aws:autoscaling:ap-northeast-1:1234567890:scalingPolicy:e8e7a4c3-af2f-4557-98e2-2dc472470f2e:autoScalingGroupName/awseb-e-immiw7zwnk-stack-AWSEBAutoScalingGroup-1QP37B57TQ43O:policyName/awseb-e-immiw7zwnk-stack-AWSEBAutoScalingScaleDownPolicy-1RY0SZO4CF9VP
INFO: Created CloudWatch alarm named: awseb-e-immiw7zwnk-stack-AWSEBCloudwatchAlarmHigh-10PTC4TZJA6XR
INFO: Created CloudWatch alarm named: awseb-e-immiw7zwnk-stack-AWSEBCloudwatchAlarmLow-1485FJORPZ9R3
INFO: Environment health has transitioned from Pending to Ok.
INFO: Successfully launched environment: web2-env

eb 명령어를 이용하면 바로 브라우져를 통해 Beanstalk으로 구성된 웹페이지를 열어볼 수 있습니다.

$ eb open

2. CloudWatch Alarm에 Notification 추가하기
Elastic Beanstalk은 Auto Scaling Group, CloudWatch Alarm, ScalingPolicy, SNS를 모두 구성해 줍니다. 자동으로 만들어진 SNS Topic을 이용하여 Lambda 함수와 연계되도록 구성을 할 수도 있고, 별도의 SNS Topic을 구성하여 Lambda 함수와 연계할 수도 있습니다.

CloudWatch 메뉴로 이동하여 자동으로 생성된 CloudWatch Alarm을 찾아 알람이 발생하면 SNS로 Notification을 전달 할 수 있도록 추가합니다.

기본으로 CPUUtilization을 모니터링하여 알람이 발생하도록 구성되어 있습니다. 스케일인-아웃(Scaling-in/out)을 위한 두 개의 알람이 생성되어 있으며, 해당 알람을 선택하여 Modify를 선택하고 Notification을 아래와 같이 추가합니다.

3. AWS Lambda에 Slack메시지 전송 함수 생성하기
Lambda에서는 Slack을 위한 함수가 예제로 추가되어 있습니다. 아래와 같이 slack으로 검색하면 Node.js와 Python 을 지원하는 Slack-echo-command, cloudwatch-alarm-to-slack 함수가 있습니다. 여기서는 Node.js를 사용하도록 하겠습니다.

cloudwatch-alarm-to-slack을 선택 후 Event Source로 앞에서 확인한 SNS Topic을 선택합니다. 해당 SNS Topic에 메시지가 전달되면 Lambda 함수가 자동으로 실행됩니다. 다음으로 제공하는 코드의 내용을 원하는 Slack 채팅 그룹, 채널에 메시지를 전달하기 위한 내용이 Comment에 설명되어 있습니다. 우선 Slack Incoming WebHooks 을 사용하여 메시지를 전달할 수 있도록 정보를 확인합니다.

1. https://<your-team-domain>.slack.com/services/new로 이동합니다.
2. “Incoming WebHooks”을 검색하여 채팅 그룹와 채널을 선택하고, 추가합니다.
   
3. “Webhook URL” 을 확인하고 노트합니다.
   

Webhook URL이 노출되지 않도록 AWS KMS(Key Management Service)를 이용하여 Webhook URL을 암호화합니다. 별도의 암호화 관리를 하지 않고 쉽게 사용할 수 있는 서비스입니다. AWS CLI를 통해 직접 콘솔을 통하지 않고도 키 생성이 가능합니다.

1) AWS CLI로 KMS에 Key를 생성합니다. 이 예제에서는 Tokyo Region의 KMS에 키를 생성합니다.

$ aws kms create-key --region ap-northeast-1
{
"KeyMetadata": {
"KeyId": " xxxxxx-xxxx-xxx-xxxx-xxxxxxxx ",
"Description": "",
"Enabled": true,
"KeyUsage": "ENCRYPT_DECRYPT",
"KeyState": "Enabled",
"CreationDate": 1453342025.031,
"Arn": "arn:aws:kms:ap-northeast-1:1234567890:key/xxxxxx-xxxx-xxx-xxxx-xxxxxxxx",
"AWSAccountId": "123456789"
}
}

2) Key 사용이 쉽도록 Alias를 생성합니다. 이 예제에서는 SlackKey라는 이름으로 타겟 키를 지정하여 Alias를 생성합니다.

$ aws kms create-alias --alias-name "alias/SlackKey" --target-key-id " xxxxxx-xxxx-xxx-xxxx-xxxxxxxx " --region ap-northeast-1

3) WebHook URL을 생성한 키와 AWS CLI를 이용하여 암호화합니다. URL은 프로토콜 부분은 제외하고 입력합니다.

$ aws kms encrypt --key-id alias/SlackKey --plaintext "hooks.slack.com/services/abcdefghijklmnopqrstuvwxyz" --region ap-northeast-1
{
"KeyId": "arn:aws:kms:ap-northeast-1:1234567890:key/ xxxxxx-xxxx-xxx-xxxx-xxxxxxxx ",
"CiphertextBlob": "AbcdfghijksN8ta1n/abdefjiowl/x5RwtKZGSctHgnMVKeNo2xZjoAAACnMIGkBgkqhkiG9abcdefghijklmnb3DQEHATAeBglghkgBZQMEAS4wEQQMPWtiU2OmhyBJ9/swAgEQgGCZJ7fabcdefghijklmnUt6ltc1avMiWQawdgW9tj8Xv3drF7savCoL0oVDzRYRabcdefghijklmncIjX4LdXbAIg6nNWcF2JEa4v9Ze9WWNA9yrzJmmNs="
}

4) 암호화되어 생성된 WebHook URL을 Lambda코드의 kmsEncryptHookUrl 변수에 입력합니다. 입력할 Slack 채널명도 slackChannel 변수에 입력합니다.

var AWS = require('aws-sdk');
var url = require('url');
var https = require('https');
var hookUrl, kmsEncyptedHookUrl, slackChannel;

kmsEncyptedHookUrl = 'AbcdfghijksN8ta1n/abdefjiowl/x5RwtKZGSctHgnMVKeNo2xZjoAAACnMIGkBgkqhkiG9abcdefghijklmnb3DQEHATAeBglghkgBZQMEAS4wEQQMPWtiU2OmhyBJ9/swAgEQgGCZJ7fabcdefghijklmnUt6ltc1avMiWQawdgW9tj8Xv3drF7savCoL0oVDzRYRabcdefghijklmncIjX4LdXbAIg6nNWcF2JEa4v9Ze9WWNA9yrzJmmNs="';  // Enter the base-64 encoded, encrypted key (CiphertextBlob)
slackChannel = '#general';  // Enter the Slack channel to send a message to

5) Lambda 함수가 KMS를 사용하여 URL Decryption을 해야하므로 함수가 KMS를 사용할 수 있는 권한이 필요합니다. Lambda 함수가 사용할 Role에 KMS의 Decrypt API 접근 허용을 추가합니다. 아래 예제는 lambda_basic_execution role의 Policy에 추가한 화면입니다.

6) Lambda 함수에 lambda_basic_execution role을 지정하고 함수를 생성합니다.

7) Lambda Event Source의 처음 설정은 Disabled 이므로 Enabled로 변경합니다.

4. Slack 대화방에서 메시지 확인하기
Beanstalk에서 만든 사이트는 현재 트래픽이 없으므로, CPUUtilization이 낮아 Low CPU Alarm이 생성되어 메시지가 전달되게 됩니다. 아래와 같이 Slack 대화방에 해당 Alarm이 전달된 것을 확인할 수 있습니다.

Beanstalk을 활용하여 아주 간단히 웹서비스를 만들고 CloudWatch 알람 이벤트를 소스로 Lambda 함수를 활용하여 Slack 서비스에 메시지를 자동으로 포스팅하는 서비스를 상세히 구현해 보았습니다. Ops 혹은 DevOps팀에서 AWS의 여러 상태 정보나 메시지를 받아서 활용할 수 있습니다. Slack에서는 메시지의 포맷을 변경하거나 할 수 있는 여러가지 예제를 제공하고 있어 보아 다양한 메시지 구현이 가능합니다.

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

Amazon Relational Database Service (RDS)를 이용하여 손쉽게 관계형 데이터베이스의 설치 및 실행, 확장 등의 유지 보수를 할 수 있습니다. 여러분은 애플리케이션이나 비즈니스에만 주력할 수 있도록, 대부분의 관리는 AWS에서 수행합니다.

확장 모니터링
Amazon RDS를 활용하고 있는 고객들로부터 RDS 내부의 상세한 정보를 모니터링하고 싶다는 요청을 많이 받았습니다. 그래서, 오늘 확장 모니터링 기능을 추가했습니다.

데이터베이스 인스턴스에서 확장 모니터링 기능을 활성화하면 CPU, 메모리, 파일 시스템 및 디스크 I/O 등의 50개 이상의 측정치에 대한 정보를 얻을 수 있습니다. 본 기능은 데이터베이스 인스턴스 단위로 할 수 있습니다. 모니터링 및 측정 시간도 (1 초 단위까지) 세부적으로 설정 가능합니다. 사용 가능한 통계 목록은 아래와 같습니다.

아래는 제 RDS 인스턴스에서 얻은 샘플 데이터입니다.

RDS 콘솔에서 모니터링 설정을 구성하려는 데이터베이스 인스턴스를 선택하고 Instance Options 메뉴에서 Modify를 선택하여 이미 실행중인 데이터베이스 인스턴스에 설정할 수 있습니다.

기능을 활성화 한 후, IAM Role을 선택하고 단위를 선택한 후, Apply Immediately에 체크하고 Continue를 클릭합니다.

확장 모니터링은 CloudWatch Logs 및 Amazon CloudWatch에 로그를 게시 할 수 있습니다. 이와 같이 설정할 때는 측정치 필터를 설정해야 하며, 자세한 내용은 를 참조하십시오. 일단 CloudWatch Logs에 수치들이 저장된 후에는 타사 제품의 분석·모니터링 도구를 활용하는 것도 가능합니다.

정식 출시
확장 모니터링 기능은 오늘부터 US East (Northern Virginia), US West (Northern California), US West (Oregon) Europe (Ireland) Europe (Frankfurt), Asia Pacific (Singapore) Asia Pacific (Sydney), Asia Pacific (Tokyo) 지역의 t1.micro과 m1.small을 제외한 MySQL 5.6, MariaDB, Amazon Aurora의 모든 인스턴스 유형에서 사용할 수 있습니다.

일반적인 CloudWatch Logs 수집 및 데이터 전송 요금으로 이용하실 수 있습니다. (자세한 내용은 CloudWatch Logs 요금 페이지를 참조하십시오.)

— Jeff;

이 글은 New – Enhanced Monitoring for Amazon RDS (MySQL 5.6, MariaDB, and Aurora)의 한국어 번역입니다.

Amazon CloudWatch를 통해 AWS 클라우드의 자원 및 클라우드 기반 애플리케이션을 손쉽게 모니터링 할 수 있습니다. 측정치가 여러분이 지정한 제한을 넘어가는 경우 알림을 보내도록 설정할 수도 있습니다. CloudWatch를 통해 자원 활용에 대한 가시성, 애플리케이션 성능 및 운영 상태를 확인할 수 있습니다.

신규 CloudWatch 대시보드
오늘 CloudWatch 통계를 보여주는 맞춤형 대시보드를 공개합니다. 각 대시보드는 여러개의 측정치를 이미지와 텍스트로 표시할 수 있습니다. 원하시면 여러분의 환경에 맞는 특정 영역을 중심으로 만들 수도 있고 하나의 대시보드에 여러 리전에 있는 데이터를 가져와서 글로벌 데이터를 표시할 수도 있습니다.

한번 함께 만들어 보실까요?

대시보드 만들기
먼저 CloudWatch 관리 콘솔을 열어 Create dashboard를 선택 한 후 원하는 이름을 넣습니다.

그래프와 텍스트가 있는 위젯(Widget)을 대시보드에 추가할텐데, 선형 그래프로 값을 표시합니다.

다음에는 표시할 측정 지표를 선택하는데, 먼저 카테고리를 골라 봅니다.

EC2 Metrics를 선택 한 후, 이 중 한 개 이상의 측정치를 골라 위젯을 만듭니다. 선택한 모든 EC2 인스턴스의 측정치 이름으로 정렬을 하도록 한 후 Create widget을 선택 합니다.

이미 말씀드린대로 여러 AWS 글로벌 리전에 나눠져 있는 자원의 측정치도 함께 표시할 수 있습니다. 즉, 멀티 리전에 배포되어 있는 애플리케이션의 상황을 하나의 화면에서 볼 수 있다는 의미입니다.

여기 예제가 있습니다.

그래프 크기를 조절하거나 동적으로 데이터를 볼 수 있습니다. 즉, 대시보드의 특정 인스턴스를 클릭하면 다른 측정치도 보여줍니다.

여러개의 위젯을 추가하는 것도 가능하며, 수직 선을 통해 위젯을 잘 배치할 수도 있습니다.

그래프를 링크하거나 확대/축소할 수도 있습니다. (Actions메뉴를 통해 원하는 옵션을 고를 수 있습니다.) 클릭을 해서 원하는 시간대로 드래그하거나 마우스로 크기를 조절 할 수도 있습니다.

Action 메뉴에는 원래 크기로 다시 바꾸거나 기타 기능도 제공하고 있습니다.

텍스트 위젯을 이용해서 대시보드에 이미지와 텍스트를 조정할 수도 있습니다. 위젯 내 텍스트는 Github에서 사용하는 마크다운(Markdown)으로 작성 가능합니다.

이제 완성된 샘플 대시보드를 한번 보시기 바랍니다.

텍스트 위젯에는 버튼 및 테이블을 넣을 수도 있습니다. 즉, 도움말 페이지, 문제 해결 가이드, 내부 혹은 외부 상태 페이지 및 전화번호 등등 다양한 정보를 입력할 수 있습니다.

몇 가지 대시보드를 만들어서 이를 자유롭게 선택해서 볼 수 있습니다.

다른 대시보드로 직접 링크를 연결시킬 수도 있습니다.

그래프 표시 시간 구간 및 자동 갱신 시간 등 세부적인 기능 설정도 가능합니다.

대시보드 소유권 및 접속 권한
각 대시보드는 AWS 계정의 레벨에 따라 계정 내 IAM 사용자가 접근할 수 있습니다. 그러나, 관리적 측면에서 현재 조직 밖에서도 대시보드를 함께 볼 수 있기를 원하는 경우가 있을 것입니다.

매우 중요한 서비스 요구 사항 중 하나인데, CloudWatch 기능의 IAM 권한을 통해 대시보드를 바꾸거나 수치를 볼 수 있도록 할 수 있습니다.

• IAM 사용자가 PutMetricData 권한이 있으면 대시보드를 생성, 수정 및 삭제할 수 있습니다.
• IAM 사용자가 GetMetricStatistics 권한이 있으면 대시보드 내용을 볼 수 있습니다.

지금 사용하기
CloudWatch 신규 맞춤형 대시보드는 지금 부터 사용 가능하며, 모든 AWS 리전을 지원합니다. 3개까지는 무료로 대시모드를 만드실 수 있으며, 추가로 월 3달러로 50개까지 만드실 수 있습니다.

대시 보드 공유하기
신규 대시보드 기능으로 여러분 만의 대시보드를 만들어 보시고, 다른 분들에게도 유용하다고 생각되면 공유해 주셔도 좋겠습니다.

— Jeff;

이 글은 CloudWatch Dashboards – Create & Use Customized Metrics Views의 한국어 번역이며, re:Invent 2015의 신규 서비스 소식입니다.

최근 여러개의 AWS 서비스를 결합하여 만드는 흥미로운 사례를 자주 소개하고 있습니다. 이 글도 그 중에 하나로 오늘은 모니터링을 위한 서비스 조합을 소개해 드리고자 합니다. 먼저 사용하는 서비스에 대해 간단하게 소개하겠습니다. (아직 AWS에 익숙하지 않는 분들을 위해서입니다.)

• Amazon Kinesis는 실시간 데이터 스트림을 처리하기 위한 관리형 서비스입니다. 자세한 사항은 Amazon Kinesis – Real-Time Processing of Streaming Big Data를 참고하세요.
• Kinesis Connector Library를 사용하면 다른 AWS 서비스 또는 AWS 이외의 서비스에서 Kinesis에 연결하는 데 도움이 됩니다.
• AWS CloudFormation 템플릿을 사용하여 AWS 리소스를 정의하고 관리하는 데 도움이 됩니다.
• CloudWatch Logs를 사용하면 운영 체제, 응용 프로그램 및 사용자 정의 로그 파일을 저장하고 모니터링 할 수 있습니다. 자세한 내용은 Store and Monitor OS & Application Log Files with Amazon CloudWatch를 참고하십시오.
• AWS Lambda는 이벤트 기반 클라우드 함수(현재 Node.js와 Java)를 실행합니다. 컴퓨팅 자원에 신경 쓸 필요가 없고 단순히 프로그래밍 코드 개발에 집중할 수 있습니다. 자세한 내용은 AWS Lambda –클라우드 기반 함수 실행을 참고하십시오. 많은 개발자들은 AWS Lambda을 Amazon API Gateway와 함께 이용하여 확장성이 뛰어난 마이크로 서비스(MicroServices)를 구축 할 수 있습니다.
• VPC Flow Logs를 사용하여 VPC와 VPC 서브넷 또는 Elastic Network Interface 관련 네트워크 트래픽에 접근할 수 있습니다.
• 마지막으로 AWS CloudTrai 계정의 AWS API 호출을 기록하고 로그 파일로 저장합니다. 자세한 사항은 AWS CloudTrail – Capture AWS API Activity을 참고하십시오.

위의 마지막 세가지는 매우 중요한 속성으로 각각 효율적으로 저장된 데이터를 시각화하기 위하여 이벤트 데이터의 방대한 스트림을 만들 수 있습니다.

이벤트 데이터 시각화
오늘은 Kinesis와 CloudWatch Logs Subscription Consumer의 이용 방법에 대해 소개합니다. CloudWatch Logs Subscription Consumers는 특정 Kinesis Stream을 받아줍니다. Elasticsearch와 S3를위한 내장 커넥터가 포함되어 있어 다른 방식의 확장도 가능합니다.

우리는 EC2에 Elasticsearch 클러스터를 구축하고, 이벤트 데이터를 Elasticsearch로 제공되도록 하여 Kibana 및 시각화 도구를 사용하여 대시 보드까지 구축 하는 CloudFormation Template을 만들었습니다. VPC Flow Log, Lambda, CloudTrail을 통한 대시 보드도 설정합니다. 필요에 따라 사용자 정의 혹은 자신의 CloudWatch Logs 로그 그룹에 새 계정을 만들 수도 있습니다.

이 템플릿을 통해 필요한 모든 자원을 만드는 데 약 10 분이 소요됩니다. 완료되고 나면, CloudFormation 콘솔의 Output 탭에 대시 보드 및 관리 도구의 URL이 표시됩니다.

현재 스택은 이전 버전의 샘플 대시 보드와 함께 Kibana 3.0 및 4.0으로 구축됩니다 (Kibana 4.0를 사용하는 경우는 약간 수동 설정을 해야 합니다). 첫 번째 샘플 대시 보드는 VPC Flow Log가 표시됩니다. 보시다시피 상당한 양의 정보가 포함되어 있습니다.

다음 예제는 람다 함수 자체에 의해 생성 된 Lambda Function 실행 정보가 표시되어 있습니다.

마지막 세 가지 열은 아래의 Lambda Function 코드로 작성되었습니다. Function에서 Kinesis 스트림을 처리 후 각 호출에 대한 정보를 로그에 기록합니다.

exports.handler = function(event, context) {
    var start = new Date().getTime();
    var bytesRead = 0;

    event.Records.forEach(function(record) {
        // Kinesis data is base64 encoded so decode here
        payload = new Buffer(record.kinesis.data, 'base64').toString('ascii');
        bytesRead += payload.length;

        // log each record
        console.log(JSON.stringify(record, null, 2));
    });

    // collect statistics on the function's activity and performance
    console.log(JSON.stringify({ 
        "recordsProcessed": event.Records.length,
        "processTime": new Date().getTime() - start,
        "bytesRead": bytesRead,
    }, null, 2));

    context.succeed("Successfully processed " + event.Records.length + " records.");
};

여기에는 약간 재미있는 것이 있습니다. 유효한 JSON 객체임을 판단하고 ElasticSearch 각각 값에 인덱스를 붙입니다. 이것은 매우 편리하고 간단한 방식으로, 디자인 패턴에 대해 연구하는 분은 여러분 시스템에 활용해 보실 수 있습니다. 더 자세한 것은 awslabs Github의 CloudWatch Logs Subscription Consumer를 참고해 보시기 바랍니다.

— Jeff;

이 글은 CloudWatch Logs Subscription Consumer + Elasticsearch + Kibana Dashboards의 한국어 번역글입니다.

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 %로 감소했습니다.

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

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

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

— Jeff;

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

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

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

많은 기업에서 네트워크 연결 중 문제 해결 및 보안 문제 및 네트웍 상 접근 규칙이 예상대로 작동하는지 확인하기 위해 네트워크 플로우 로그의 수집, 저장 및 분석을 하고 있습니다.

지금까지 AWS 고객은 주로 Amazon Elastic Compute Cloud (EC2)에 직접 에이전트를 설치하여 데이터를 수집하고 있었고, 각 인스턴스에 오버 헤드의 부하를 줄 뿐만 아니라 매번 인스턴스마다 제한적으로만 보기(View)가 가능했습니다.

VPC Flow Logs 소개

네트워크 모니터링에서 로그 수집 기능을 향상을 위해 Amazon Virtual Private Cloud의 Flow Logs를 공개합니다. 특정 VPC에서 Flow Logs를 사용하여 VPC 서브넷과 엘라스틱 네트워크 인터페이스(ENI)의 네트워크 트래픽이 CloudWatch Logs를 통해 저장된 후, 자신의 응용 프로그램이나 타사 프로그램에서 분석 할 수 있습니다.

특정 유형의 트래픽을 감지하여 알람을 만들거나 트래픽의 변화와 패턴을 파악하기위한 통계를 만들 수도 있습니다.

로그 정보는 보안 그룹 및 네트워크 접근(ACL) 규칙에 의해 허용 및 차단 트래픽 정보가 포함되어 있습니다. 또한, 소스 / 목적지 IP 주소, 포트, 프로토콜 번호 패킷 바이트 모니터링 간격 시간, 그리고 이에 따른 액션(ACCEPT 또는 REJECT) 정보도 포함됩니다.

VPC Flow Logs 시작하기

AWS 관리 콘솔, AWS 명령 줄 인터페이스 (CLI) 및 EC2 API 호출을 통해 VPCFlow Logs를 활성화 할 수 있습니다. 아래는 VPC에서 Fow Logs를 사용하는 화면 스크린 샷입니다.

Flow Logs 구성 화면입니다.

VPC 대시 보드에 Flow Logs 탭이 표시됩니다.

Flow Logs는 CloudWatch Logs 로그 그룹에 저장됩니다. Flow Logs를 작성한 후 약 15분 후에 새로운 로그 그룹이 생성됩니다. CloudWatch Logs의 대시 보드에서 접근 가능합니다.

각 그룹은 엘라스틱 네트워크 인터페이스 (ENI)당 스트림으로 구성됩니다.

각 스트림은 다음과 같은 항목이 포함됩니다.

Flow Logs 유의 사항

VPC Flow Logs 사용 시 알아 주시면 좋을 몇 가지를 알려드립니다.

각 Flowsms 약 10 분 간격으로 캡처되어 윈도우에서 수집, 처리, 저장합니다. 로그 그룹을 만들고 첫 번째 레코드가 콘솔에서 확인 될 때​​까지 Flow Logs가 생성 된 후 약 10분 후에 가능합니다.

하나의 리소스에 대해 2개의 Flow Logs를 만들 수 있습니다.

Flow Logs에는 다음과 같은 트래픽 정보는 포함되어 있지 않습니다.

1. Amazon DNS 서버 트래픽(개인 호스트 영역 쿼리 포함)
2. Amazon에서 제공하는 Windows 라이센스 활성화 트래픽
3. 인스턴스 메타 데이터 요청
4. DHCP 요청과 응답

지금 사용하기

이 기능은 도쿄 지역 (아시아 태평양)를 비롯해 북부 캘리포니아 (미국 서부), 오레곤 (미국 서부), 북 버지니아 (미국 동부), 시드니 (아시아 태평양), 싱가포르 (아시아 태평양), 아일랜드 (유럽) 프랑크푸르트 (유럽)에서 이용이 가능합니다. 이용시 추가 비용이 필요하지 않습니다. CloudWatch Logs 스토리지 요금 만 청구됩니다. (자세한 내용은 CloudWatch 가격표을 참고하세요.)

— Jeff;

PS – 일부 AWS 파트너는 VPC Flow Logs 처리, 분석, 시각화 등의 도구 제공을 위해 노력하고 있습니다. 그 부분에 대해서도 알려드리겠습니다.

본 글은 VPC Flow Logs – Log and View Network Traffic Flows의 한국어 번역입니다.