Category: Management Tools


Amazon CloudWatch를 위한 collectd 플러그인 공개

대부분 고객들은 Amazon CloudWatch에 많은 애플리케이션 통계 데이터를 저장해 왔습니다. (자세한 내용은 New – Custom Metrics for Amazon CloudWatch 참고) 이 블로그에서 “사용자의 AWS 자원을 CloudWatch를 통해 통계 수치를 통해 그래프로 표시하거나 알림을 설정하거나, 자동화 작업을 할 수 있다.”라고 소개하였습니다.

오늘 부터 collectd 기반 새로운 CloudWatch 플러그인를 사용하여 사용자 시스템에서 통계를 수집하여, CloudWatch에 저장할 수 있습니다. 다양한 유형의 통계를 수집하는 collectd 기능과 저장 및 표시 그리고 경고를 알릴 수 있는 CloudWatch 기능을 결합하여 EC2 인스턴스의 상태와 성능, EC2에서 실행하는 온프레미스 하드웨어나 응용 프로그램에 대해 자세히 파악할 수 있습니다. 본 플러그인은 오픈 소스 프로젝트로 시작하였고, 여러분의 피드백을 기다리고 있습니다.

collectd 데몬은 성능을 위해 C로 작성되어 있습니다. 현재 100개 이상의 플러그인을 지원하고 ApacheNginx 웹 서버 성능, 메모리 사용량, 가동 시간 통계를 수집 할 수 있습니다.

collectd 설치 및 설정
실제 동작을 살펴보기 위해 collectd과 새로운 플러그인을 EC2 인스턴스에 설치하고 구성해 보았습니다.
먼저 CloudWatch에 통계 데이터를 쓸 수 있는 권한을 제공하기 위한 IAM 정책(Policy)을 만듭니다.

이 정책을 활용하여 만들어진 EC2에 접근할 수 있는 IAM 역할(Role)을 만들었습니다.

기존 서버에서 통계를 수집하기 위해 플러그인을 사용하려는 경우, (이미 EC2 인스턴스를 실행하는 경우) 이러한 단계를 진행하지 않고 적절한 접근 권한을 사용하여 IAM 사용자를 생성 합니다.

이제 IAM 정책 및 역할이 준비 되면, EC2 인스턴스를 시작하고 관련 역할을 선택합니다.

로그인 후, collectd를 설치합니다.

Bash
$ sudo yum -y install collectd

플러그인을 설치할 스크립트의 실행 권한을 설정한 뒤 실행합니다.
Then I fetched the plugin and the install script, made the script executable, and ran it:

Bash
$ chmod a+x setup.py
$ sudo ./setup.py

몇 가지 질문에 응답한 후, 문제없이 설정을 수행 할 수 있습니다. collectd 설정 완료 후 시작합니다.

Bash
Installing dependencies ... OK
Installing python dependencies ... OK
Copying plugin tar file ... OK
Extracting plugin ... OK
Moving to collectd plugins directory ... OK
Copying CloudWatch plugin include file ... OK

Choose AWS region for published metrics:
  1. Automatic [us-east-1]
  2. Custom
Enter choice [1]: 1

Choose hostname for published metrics:
  1. EC2 instance id [i-057d2ed2260c3e251]
  2. Custom
Enter choice [1]: 1

Choose authentication method:
  1. IAM Role [Collectd_PutMetricData]
  2. IAM User
Enter choice [1]: 1

Choose how to install CloudWatch plugin in collectd:
  1. Do not modify existing collectd configuration
  2. Add plugin to the existing configuration
Enter choice [2]: 2
Plugin configuration written successfully.
Stopping collectd process ... NOT OK
Starting collectd process ... OK
$

collectd을 수행할 플러그인 설치와 설정이 완료되면, 다음 단계는 필요한 통계 항목을 결정하여 CloudWatch로 보내도록 플러그인을 설정하는 것입니다 (각 통계마다 요금이 발생할 수 있으므로, 이것은 중요한 단계입니다).

/opt/collectd-plugins/cloudwatch/config/blocked_metrics는 수집한 통계 목록이 포함되어 있으나 CloudWatch에 보내지는 않습니다.

Bash
$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics
# This file is automatically generated - do not modify this file.
# Use this file to find metrics to be added to the whitelist file instead.
cpu-0-cpu-user
cpu-0-cpu-nice
cpu-0-cpu-system
cpu-0-cpu-idle
cpu-0-cpu-wait
cpu-0-cpu-interrupt
cpu-0-cpu-softirq
cpu-0-cpu-steal
interface-lo-if_octets-
interface-lo-if_packets-
interface-lo-if_errors-
interface-eth0-if_octets-
interface-eth0-if_packets-
interface-eth0-if_errors-
memory--memory-used
load--load-
memory--memory-buffered
memory--memory-cached

메모리 사용량에 대한 로그를 남기기 위해 /opt/collectd-plugins/cloudwatch/config/whitelist.conf를 추가합니다.

Bash
memory--memory-.*

collectd 설정 파일 (/etc/collectd.conf)는 collectd와 플러그인 설정을 포함하고 있습니다. 이번 경우는 변경할 필요는 없습니다.

전체 변경을 사항을 적용하기 위해, collectd를 다시 시작합니다.

Bash
$ sudo service collectd restart

메모리를 사용량을 높이기 위해, 인스턴스를 조금 사용하고 CloudWatch 콘솔을 열어 필요한 부분을 표시했습니다.

위의 스크린샷은 CloudWatch 콘솔에 탑재된 미리 보기 기능에 포함되어 있으므로 자신의 화면에 같은 것이 표시되지 않더라도 놀라지 마세요. (자세한 내용은 향후 알려드립니다).

정식 서비스 중인 인스턴스를 모니터링하는 경우, collected 플러그인을 하나이상 설치할 수 있습니다. Amazon Linux AMI에서 사용할 수 있는 목록은 아래를 참조하십시오.

Bash
$ sudo yum list | grep collectd
collectd.x86_64                        5.4.1-1.11.amzn1               @amzn-main
collectd-amqp.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-apache.x86_64                 5.4.1-1.11.amzn1               amzn-main
collectd-bind.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-curl.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-curl_xml.x86_64               5.4.1-1.11.amzn1               amzn-main
collectd-dbi.x86_64                    5.4.1-1.11.amzn1               amzn-main
collectd-dns.x86_64                    5.4.1-1.11.amzn1               amzn-main
collectd-email.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-generic-jmx.x86_64            5.4.1-1.11.amzn1               amzn-main
collectd-gmond.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-ipmi.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-iptables.x86_64               5.4.1-1.11.amzn1               amzn-main
collectd-ipvs.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-java.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-lvm.x86_64                    5.4.1-1.11.amzn1               amzn-main
collectd-memcachec.x86_64              5.4.1-1.11.amzn1               amzn-main
collectd-mysql.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-netlink.x86_64                5.4.1-1.11.amzn1               amzn-main
collectd-nginx.x86_64                  5.4.1-1.11.amzn1               amzn-main
collectd-notify_email.x86_64           5.4.1-1.11.amzn1               amzn-main
collectd-postgresql.x86_64             5.4.1-1.11.amzn1               amzn-main
collectd-rrdcached.x86_64              5.4.1-1.11.amzn1               amzn-main
collectd-rrdtool.x86_64                5.4.1-1.11.amzn1               amzn-main
collectd-snmp.x86_64                   5.4.1-1.11.amzn1               amzn-main
collectd-varnish.x86_64                5.4.1-1.11.amzn1               amzn-main
collectd-web.x86_64                    5.4.1-1.11.amzn1               amzn-main

알아 두실 점
collectd 버전 5.5 이상을 사용하는 경우, 아래 네개의 통계를 기본적으로 지원합니다.

  • df-root-percent_bytes-used – 디스크 속도
  • memory–percent-used – 메모리 사용량
  • swap–percent-used – swap 사용량
  • cpu–percent-active – cpu 사용량

원하지 않는 경우, whitelist.conf 파일에서 제거 할 수 있습니다.

현재 Amazon Linux AMI, Ubuntu, RHEL, CentOS 기본 저장소는 이전 버전의 collectd를 제공하고 있습니다. 사용자 저장소에서 설치하거나, 소스에서 직접 빌드한 경우 기본 설정이 다른 점을 유의하시기 바랍니다.

참고 사항
추가적인 collectd 플러그인도 whitelist.conf 파일을 설정하여, 더 많은 통계 데이터를 CloudWatch에 제공할 수 있습니다. CloudWatch 알람을 생성하고 사용자 정의 대시 보드 등을 할 수 있습니다.

시작은 GitHub의 AWS 연구소 를 방문하여 collectd의 CloudWatch 플러그인 을 다운로드하십시오.

더 자세한 사항은 GitHub에서 collectd CloudWatch 플러그인를 다운로드 하세요.

Jeff;

이 글은 New – CloudWatch Plugin for collectd의 한국어 번역입니다.

Amazon CloudWatch 대시보드 사용성 개선

Amazon CloudWatch는 AWS 인프라에서 발생하는 문제 확인, 진단, 대응, 해결을 위해 로그 데이터를 확인하고 처리할 수 있는 API를 제공하고 있습니다. 이를 위해 로그 분석 (CloudWatch 운영 체제 및 애플리케이션 로그 저장 및 모니터링 기능) 및 대시 보드 (CloudWatch 대시 보드 – 맞춤형 통계 보기 기능 제공)에 이은 추가적인 사용성 개선 기능을 오늘 선보이게 되었습니다.

CloudWatch Logs 사용성 개선
CloudWatch Logs는 운영 체제 및 응용 프로그램 로그 파일을 관리하는 가용성과 확장성 및 내구성이 높은 안전한 서비스입니다. 로그 데이터 수집, 보관, 필터, 검색, 보관을 위한 작업 부하를 줄이고 애플리케이션과 비즈니스에 집중할 수 있도록합니다.

로그 건수나 크기가 늘어나도 효율성과 생산성을 유지할 수 있도록하기 위해 AWS에서는 CloudWatch Logs 콘솔에 사용성 개선 사항을 일부 추가했습니다.

  • 로그 데이터의 포맷 처리 개선
  • 긴 로그 파일에 대한 접근 단순화
  • 로그 그룹 내에서 검색 용이
  • 로그 파일의 공동 작업 간소화
  • 특정 기간의 검색 개선

이번 기능 출시 전에 CloudWatch 대시 보드에도 개선점을 추가했습니다.

  • 전체 화면 모드
  • 어두운 테마
  • 차트에서 Y 축 범위 지정
  • 그래프 이름 변경 단순화
  • 그래프 설정 영구 저장소

CloudWatch 로그 콘솔 사용해 보기
개선점들을 직접 살펴보도록 하겠습니다. 먼저 CloudWatch Logs Console을 열어, 로그 그룹을 클릭한 후 그룹내 로그 스트림에서 오른쪽의 View options를 선택합니다.

다음과 같이 여러 행으로 확대한 상태에서 로그 메시지를 표시하려면 Expand all을 클릭합니다.

일반 텍스트 로그를 표시하려면 텍스트 표시를 전환 할 수 있습니다.

이 밖에도 로그 그룹 내의 스트림 모든 로그 데이터 표시 방식을 개선했습니다. 로그 그룹을 선택하고, strong>Search Events을 클릭하면 해당 로그 그룹 내의 스트림의 모든 로그 데이터를 볼 수 있습니다. 예를 들어, 하나의 Lambda 함수의 여러 호출에 대한 과금 대상 기간을 쉽게 찾을 수 있습니다.

또한, 제한없이 볼 수 있도록 스크롤 막대가 도입되었습니다. 이제 원하는 만큼 로그 파일을 스크롤 할 수 있게 되었습니다.

다음과 같이 특정 기간을 지정하거나, 한 번의 클릭으로 날짜를 지정하는 등 검색 범위를 좁힐 수 있게 되었습니다.

팀원으로 작업을 하는 경우, 자신의 로그 분석 세션의 URL을 공유 할 수 있게 되었습니다. URL은 검색 매개 변수와 필터가 포함 된 다음과 같은 형식입니다.

group=<log_group_name>_log;stream=<log_stream_name>;filter=<filter_parameter>;start=PT<time_frame>

위의 CloudWatch Logs 콘솔 개선점은 지금 바로 이용하실 수 있습니다. 자세한 내용은 Getting Started with CloudWatch Logs를 참고하시기 바랍니다.

CloudWatch 대시 보드 추가 개선 사항
먼저 대시 보드에 새로운 전체 화면 모드를 추가했습니다. Actions 메뉴에서 Enter full screen로 전환할 수 있습니다.

전체 화면 모드 상태가되면 Dark을 클릭하여 어두운 테마로 전환 할 수 있습니다.

전체 화면 모드에서 다크 테마를 사용하는 Redis의 예를 보실 수 있습니다.

경우에 따라 대시 보드에 그래프를 어떻게 표시할지 섬세하게 관리하고 싶을 경우, 예를 들어 데이터 이상 값으로 그래프를 읽기 어려울 때, 대시 보드에서 Y축의 특정 범위에 집중하고 싶은 때가 있을 수 있습니다. 다음의 예는 그러한 경우의 그래프입니다. 이상 값이 급증한 후 일어나는 경향을 확인하고자 할 때,

Y축을 편집하려면 도구 선택자를 클릭하고 Edit를 클릭합니다.

Graph Options를 선택하고, 원하는 상태에 그래프가 표시 될 때까지 Y 축 값을 편집합니다. 그 후 Update widget를 클릭하십시오.

편집된 그래프는 다음과 같이 됩니다.

AWS 고객 중에는 대시 보드에서 그래프 이름 변경하기를 원하는 분들이 계셨습니다. 이제 한 번의 클릭으로 이름 변경이 가능하게되었습니다 (그래프 이름 옆에 마우스를 이동시켜 연필 아이콘을 클릭하면됩니다).

Finally, CloudWatch now remembers the time range, timezone preference, refresh interval, and auto-refresh setting for each chart!

Amazon CloudWatch 파트너 소개
마지막으로 AWS 파트너의 우수한 솔루션에 대해 소개합니다. 다음 파트너는 CloudWatch를 기반한 분석 솔루션도 구축하고 있습니다.

  • Datadog 인프라 주요 항목과의 통합을 제공하고, 문제 발생 시 직접 고객 팀과 협력 제공
  • Librato 인프라 통합을 제공하고 복합 메트릭스와 시계열 데이터 변환 지원
  • SignalFx 통계에 따른 즉시성 데이터 제공 및 분석에 집중하고 서비스 규모 알림 가능
  • Splunk 머신 데이터의 수집 및 인사이트 탐지를 가능하게하는 운영 인텔리전스 플랫폼 제공
  • Sumo Logic 로그 관리 및 시계열 메트릭스 시스템 데이터 분석 서비스 응용 프로그램 구축 및 실행

AWS 파트너로서 CloudWatch를 활용하는 솔루션이 있다면 알려주시면, 업데이트하겠습니다.

Jeff;

Amazon CloudWatch Events 서울 리전 서비스 개시 – AWS 자원 변경에 대한 실시간 추적 기능

지난 1월에 처음 소개된 Amazon CloudWatch Events 서비스를 오늘 부터 Asia Pacific (Seoul) 리전에서 사용하실 수 있습니다.

본 서비스를 활용하시면, EC2 인스턴스, RDS 인스턴스 및 CloudTrails를 통한 다양한 API 실행 등의 이벤트를 CloudWatch를 통해 스트림 방식으로 실시간으로 얻을 수 있고, 이를 통해 빠르게 대응할 수 있는 기능입니다.

이를 통해 EC2  인스턴스가 종료되었을 때, SNS 토픽을 통해 알림을 받을 수도 있고, EBS 볼륨을 분 단위로 스냅샷을 만들 수도 있습니다.

아래 글은 Amazon CloudWatch Events를 설명한 New CloudWatch Events – Track and Respond to Changes to Your AWS Resources의 한국어 편집본입니다.

AWS에서 실행되는 응용 프로그램에서는 많은 이벤트들이 일어나고 있습니다. 시스템 부하에 따라 자동 스케일링(Auto Scaling) 정책을 통해 EC2 인스턴스 생성 및 제거를 할 수도 있고, DynamoDB 테이블이나 SNS 토픽, SNS 큐가 삭제 될 수 있습니다. 기존 클라우드 자원에 관해 AWS 관리 콘솔, AWS API, AWS Command Line Interface (CLI) 에서 다양하게 각 속성이 변경 될 수 있습니다.

대부분 고객들은 직접 높은 수준의 도구를 개발하여, AWS 자원 환경 전체 상황을 추적 및 감시, 운용하고 있습니다. 그리고 이러한 도구들은 지금까지 폴링(Polling) 형식으로 운영하고 있습니다. 즉, 정기적으로 DescribeInstances, DescribeVolumesListQueues (여기에서는 EC2 인스턴스, EBS 볼륨 및 SQS 큐) 등 AWS 함수를 호출하여 다양한 종류의 AWS 자원 상태를 추적합니다. 각 목록을 얻을 다른 API를 호출해야만, 과거의 데이터와 비교하여 변화를 감지하고 조치를 취할 수 있습니다. 따라서, 시스템이 커지고 복잡한게 될때는 이 부분에 대한 상태 관리가 어려워지게 됩니다.

CloudWatch Events 신규 기능
AWS 자원의 상태 변화를 보다 쉽고 효율적으로 관리할 수​​ 있는 CloudWatch Event를 출시합니다.

CloudWatch Event는 AWS 자원 변경 정보를 바로 스트리밍 방식으로 전달합니다. 간단한 전달 규칙을 몇 분 안에 쉽게 만들 수 있고, 여러 방식으로 이 기능을 연계할 수 있습니다. (AWS Lambda 함수, Amazon Kinesis 스트림, Amazon SNS 등과 연계 가능)

CloudWatch Event는 AWS 환경에서 주요 신경계와 같은 것이라고 생각하시면 됩니다. 각 자원 내 세부적인 환경 변화를 감지하도록 연결되어 있습니다. 특정 규칙에 따라 기능을 수행하여, 상태 확인 후 바로 조치를 취할 수 있도록 메시지를 전달합니다.

현재 대표적인 AWS 서비스에 대응하고 있으며, 추가적으로 나머지 서비스도 지원할 예정입니다.

CloudWatch Events 처리 방식
CloudWatch Events를 이용할 때, 이벤트(Events), 규칙(Rules), 대상(Targets) 등 세 가지 구성 요소에 대해 우선 이해하고 있어야합니다.

이벤트(Events): JSON 형식의 Blob으로 로 반환되는 blob으로 네 가지 방법으로 생성됩니다. 우선 첫 번째로 AWS 환경에서 상태가 변경되었을 때 생성됩니다. 예를 들어 EC2의 상태가 Pending에서 Running으로 변경되거나 AutoScaling 의해 EC2 인스턴스가 새로 만들어졌을 때와 같은 상황입니다. 두 번째는 API를 통해 호출되는 이벤트는 CloudTrial을 통해 CloudWatch Event에 전달됩니다. 세 번째로 여러분이 직접 개발한 코드를 통해 응용 프로그램 수준의 이벤트를 만들어 CloudWatch Event에 전달할 수 있습니다. 마지막으로 스케줄 기반에 일정 간격으로 Cron 형태 이벤트 작성도 가능합니다.

규칙(Rules): 생성된 이벤트와 규칙이 일치하는 경우 대상(Targets)에 대해 처리를 실행합니다. 규칙 적용에 특별히 정해진 순서가 있지 않습니다. 이벤트에 일치하는 모든 규칙이 적용됩니다 (이를 통해 독립적인 이벤트 처리가 가능합니다).

대상(Targets): 규칙을 통해 설정된 이벤트 처리 방식이 원하는 대상에 전달됩니다. 네 가지 타겟 타입을 준비하고 있습니다. 빌트인(Built-in), Lambda 함수, Kinesis 스트림과 SNS 토픽, SQS 큐 우선 해당되지만, 다른 방식 역시 계획 중입니다. (2016년 6월 현재 서울 리전에서는 Lambda 함수는 지원하지 않습니다.) 하나의 규칙에서 여러 대상을 설정할 수 있습니다. 모든 이벤트는 JSON 형식으로 대상에 전달되며 대상에 전달하거나 및 JSON으로 가공 할 수 있습니다. 또한, 이벤트를 그대로 전달할 수 있으며, 특정 Key (Value 값도 함께)를 전달하거나 문자열을 전달할 수 있습니다.

CloudWatch Events 직접 해보기
CloudWatch Events Console에 가서, Create rule을 누르고 이벤트 소스를 선택합니다. (여러 가지 선택 메뉴가 있습니다.)

일부 AWS 서비스는 이벤트를 직접 만들어 상단 메뉴에 표시됩니다. 그 외에는 CloudTrail 로그를 기반으로 작성되는 것도 있기 때문에 서비스는 CoudTrail를 활성화해야합니다. 이제 “EC2 Instances”를 선택하고 관련 규칙을 만듭니다.

위의 규칙은 새로 생성 된 인스턴스가 “running” 되는 것을 감시합니다. 현재 리전 전체 인스턴스에 적용 할 수 있으며, 특정 인스턴스에 적용 할 수 있습니다.

이제 무엇을 할 것인가를 설정합니다. 이번에는 대상을 선택합니다. 여기서는 SNS 토픽을 선택합니다.

규칙에 대해 간단하게 설명을 적고 Create rule을 선택합니다.

이제 설정이 완료되었습니다.

이제 테스트로 EC2 인스턴스 하나를 새로 시작해 보겠습니다. 인스턴스가 시작된 지 바로 SNS 토픽을 통해 메일을 통해 아래와 같이 알림을 받을 수 있습니다.

이벤트 내용에는 새로 시작된 인스턴스 정보 등 다양한 정보를 포함하고 있으며, 이를 통해  DescribeInstances API 호출로 더 다양한 정보를 얻어 올 수 있습니다.

규칙 실행 주기 설정
앞서 설명드린 대로, 각 이벤트는 Cron 형식으로도 설정할 수 있습니다.

API 접근하기
다른 AWS 서비스 처럼 CloudWatch Events 역시 API를 통해 제공합니다.

  • PutRule : 규칙 만들기
  • PutTargets 및  RemoveTargets : 대상 만들기 및 제거하기
  • ListRules, ListTargetsByRuleDescribeRule : 기존 규칙 찾기
  • PutEvents :  CloudWatch Events 만들기. 본 기능을 통해 CLI 기반으로 다양한 애플리케이션을 만들 수 있습니다.

이벤트 통계 보기
CloudWatch Events 역시 CloudWatch에 다양한 통계 수치를 제공합니다. AWS/Events 네임 스페이스를 살펴 보시면, 규칙에 따른 다양한 정보를 얻을 수 있습니다.

아래 수치를 보실 수 있습니다.

  • Invocations – 대상이 실행된 횟수
  • FailedInvocations – 대상에 대한 실행 실패 횟수
  • MatchedEvents – 규칙에 해당되는 실행 횟수
  • TriggeredRules – 규칙이 실행된 횟수

각 규칙에 대한 수치는 아래와 같습니다.

  • Invocations – 대상에 대해 규칙이 실행된 횟수
  • TriggeredRules – 규칙이 직접 실행된 횟수

다른 AWS 서비스 처럼  CloudWatch Events 서비스 역시 기본 기능으로 시작하지만,   AWS CloudFormation 지원 및 리전 확대 등 다양한 기능을 제공할 예정입니다.  더 자세한 것은 기술 문서를 참고하시기 바랍니다.

 

Amazon Kinesis 업데이트 – Amazon Elasticsearch Service 통합, 샤드 통계 및 시간 기반 반복 기능

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

AWS Config, 서울 리전 출시!

AWS Config를 이제 Asia Pacific (Seoul) 리전에서 사용 가능합니다. AWS Config는 AWS 자원 인벤토리, 구성 기록, 구성 변경 알림을 제공하여 보안 및 거버넌스를 실현하는 관리형 서비스입니다.

아래 글은 2014년 11월 AWS Config 서비스를 처음 소개하는 Track AWS Resource Configurations With AWS Config의 한국어 번역입니다.

인프라의 동적인 변경이 가능하다는 것은 클라우드에서 가장 멋진 기능 중 하나입니다. 클라우드에 있는 자원은 단 몇 분만에 자원 구성·추가·설정·사용·분리 및 삭제할 수 있습니다. 이러한 다양한 변화들은 관리자가 직접 하거나, AWS CloudFormation 혹은 Auto Scaling을 통해 자동으로 일어나기도 합니다. 클라우드 자원 자체의 연결 방법 및 설정 등 기타 속성은 시간이 지나면서 변화하고 있습니다.

이러한 변경이 발생했을 때, 회사의 인프라 관리자는 클라우드에서 자산 관리 · 재고 관리 · 변경 관리 · 관리 구조 등의 영역에서 새로운 도전에 직면하고 있습니다. 인프라 관리자는 언제 어느 구성에서 어떤 리소스가 변경되었으며, 그 변경이 다른 자원에 어떤 영향을 주었는지를 확인할 필요가 있습니다. 이러한 변화는 때때로 예기치 않은 구성 변경이나 시스템 장애 또는 보안 사고에 기인한 것일 수도 있습니다. 변경이 일어난 원인에 관계없이 올바른 데이터에 접근하는 것은 향후 깊이 있는 데이터 기반 분석을 가능하게합니다.

기존 인프라의 구성 관리 도구는 리소스들이 자주 변경되지 않는 예전에 만들어졌습니다. 이 도구들은 비싸고, 복잡하고, 관리자가 원하는 부분을 직접 만들어야 했습니다.

AWS Config 서비스 소개
이러한 고객들의 요구를 해결하기 위해 AWS Config를 제공합니다. 여러분의 AWS 자원들의 초기 상태와 관련성을 확인 및 생성 · 삭제 · 속성 변경 내용 추적하고, 이들 데이터를 분석하고 시각화하는 도구입니다.

AWS Config는 단 두번의 클릭으로 시작할 수 있습니다! 사용을 시작하면 Config는 현재 구성과 모든 변경을 감지합니다. 구성 데이터는 AWS 관리 콘솔에서 타임 라인으로 볼 수 있습니다. AWS Configs는 구성 변경이 일어나면, 선택한 Amazon Simple Notification Service (SNS) 토픽으로 전달 되고, 6시간마다 Amazon Simple Storage Service (S3) 버킷에 스냅샷을 저장합니다. 또한, 직접 만든 도구 및 파트너가 제공하는 도구를 이용하여 수집된 데이터를 분석 할 수 있습니다.

AWS Config는 AWS 자원 간의 관련성을 해석하고 추적합니다. EBS 볼륨은 EC2 인스턴스에 탑재되며, 인스턴스는 보안 그룹 Elastic IP Addresses, VPC, Elastic Network Interfaces 등과 연결되어 있습니다.

AWS Config를 이용하면 모든 AWS 자원을 시각화 할 수 있습니다. 시계열 변경 사항을 모니터링하고, 자원 구성이 일어난 변경 기록을 참고할 수 있습니다. 각 자원 사이의 연결을 확인하거나, 특정 자원의 수정 사항이 관련 자원에 어떤 영향을 미쳤는지를 확인 할 수 있습니다. AWS Config는 정기적으로 구성 및 자원 변경이 일어난 환경에서 유용한 정보를 제공합니다!

모든 AWS 자원에 대해 현재 회사 조직의 규정 및 정책에 맞는 것인지도 확인 할 수 있습니다. 예를 들어, 정식 서비스 환경에서 VPC로 구성되지 않는 자원이 있는지 확인한다던지, 지난 2주 동안 특정 EIP 주소가 연결된 인스턴스를 식별하거나, 특정 날짜와 시간에서 자원 상태를 알 수 있습니다.

AWS Config 사용해 보기
우선 AWS Config는 각 계정 및 리전 마다 활성화 해야 합니다. AWS 관리 콘솔, AWS CLI 및 API를 사용해서 시작할 수 있습니다.

우선 자신의 계정에서 특정 리전을 선택하고 Config를 활성화합니다. 사용할 SNS 토픽과 S3 버킷은 각각 새로 만들거나 기존에 있는 것을 사용하거나 적절한 권한이 설정된 다른 계정을 것을 사용할 수 있습니다.

AWS Config에 자신의 AWS 자원에 접근 할 수 있도록 IAM 역할(Role)을 할당해야합니다.

S3 버킷에 데이터가 저장되기 시작하면, 변경 사항을 SNS 토픽으로 보냅니다. 버킷에는 아래와 같은 방식으로 저장합니다.

Config를 이용하여 직접 자신의 운영 도구를 구축하는 경우를 제외하고 위의 버킷 데이터를 볼 필요는 없습니다.  (데이터 구조의 상세 내용을 알고 싶다면 아래의 Config 데이터 내용을 참조 하십시오). 대신 Config 콘솔이나 타사 도구를  사용하여,  자원을 선택하고 구성 변경의 타임 라인을 확인 할 수 있습니다.

파트너 지원
AWS Partner Network (APN)의 다양한 파트너들이   AWS Config 를 통해 다양한 분석 도구를 제공 합니다. 아래에 주요 파트너 목록입니다.

  1. 2nd Watch
  2. CloudCheckr
  3. CloudNexa
  4. Evident.IO
  5. Red Hat Cloud Forms
  6. RedSeal Networks
  7. Splunk

(역자 주: 자세한 파트너 목록이나 소개는 Track AWS Resource Configurations With AWS Config를 참고하십시오.)

AWS Config Data 내부 구조 (개발자용)
이제 Config에 의해 생성되는 데이터의 내용은 살펴 보겠습니다. 아래는 하나의 EC2 인스턴스 구성 스냅 샷 데이터입니다. 이 데이터는 인스턴스 ID, 할당 된 태그 목록 및  보안 그룹과 EBS 볼륨이 포함되어 있습니다.

JavaScript
{
  "configurationItemVersion" : "1.0",
  "configurationItemCaptureTime":"2014-10-28T02:30:36.989Z",
  "configurationStateId":2,
  "relatedEvents":["f8cdf490-3ddc-41ac-9cfd-9e1268dfba93"],

  "awsAccountId":"448164394201",
  "configurationItemStatus":"OK",
  "resourceId":"i-7053641e",
  "ARN":"arn:aws:ec2:us-east-1:348414629041:instance/i-7053641e",
  "awsRegion":"us-east-1",
  "availabilityZone":"us-east-1b",
  "configurationStateMd5Hash":"6ae267fafa03d87827137290c8b303e2",
  "resourceType":"AWS::EC2::Instance",
  "resourceCreationTime":"2013-04-26T19:36:06.000Z",

  "tags":{
   "UserTagDemo":"TemporaryTag",
   "Name":"RoadTripBlogServer"
  },

  "relationships":[
  {
    "resourceId":"sg-6e371c06",
    "resourceType":"AWS::EC2::SecurityGroup",
    "name":"Is associated with SecurityGroup"
  },

  {
    "resourceId":"vol-357a5f6c",
    "resourceType":"AWS::EC2::Volume",
    "name":"Is attached to Volume"
  }
  ]
}

Config 변경을 감지 할 때마다 SNS 토픽에 알림을 보냅니다. 알림 내용은 아래 정보를 포함합니다.

JavaScript
{
  "configurationItemDiff":{
    "changedProperties":{
    },
    "changeType":"CREATE"
  },

  "configurationItem":{
    "configurationItemVersion":"1.0",
    "configurationItemCaptureTime":"2014-11-04T02:28:33.146Z",
    "configurationStateId":1,
    "relatedEvents":[
       "f8cdf490-3ddc-41ac-9cfd-9e1268dfba93"
    ],

    "awsAccountId":"448164394201",
    "configurationItemStatus":"ResourceDiscovered",
    "resourceId":"vol-02fecb4d",
    "ARN":"arn:aws:ec2:us-east-1:348414629041:volume/vol-02fecb4d",
    "awsRegion":"us-east-1",
    "availabilityZone":"us-east-1a",
    "configurationStateMd5Hash":"16772ac8f8ccc7ed493a878f3bd88f8c",
    "resourceType":"AWS::EC2::Volume",
    "resourceCreationTime":"2014-11-04T02:25:10.281Z",
    "tags":{ },
    "relationships":[ ],

   "configuration":{
      "volumeId":"vol-02fecb4d",
      "size":2,
      "snapshotId":"",
      "availabilityZone":"us-east-1a",
      "state":"available",
      "createTime":"2014-11-04T02:25:10.281Z",
      "attachments":[ ],
      "tags":[ ],
      "volumeType":"gp2",
      "iops":6,
      "encrypted":false
    }
  },
  "notificationCreationTime":"2014-11-04T02:28:33.345Z",
  "messageType":"ConfigurationItemChangeNotification",
  "recordVersion":"1.2"
}

AWS Config가 현재 구성의 스냅샷을 구성 했을 때도 알림을 보냅니다. .

AWS Config APIs
Config는 자원 구성 정보를 수집하기 위한 2 개의 API를 제공합니다:

  • GetResourceConfigHistory – 시간 범위와 자원을 사용하여 구성 정보 검색하기
  • DeliverConfigSnapshot – 자원 스냅 샷을 만들고 S3에 보관하기

가격 및 사용 가능 리전
AWS Config는 2014년 11월 미리보기로 출시하여, 2015년 4월 9개 리전에 출시하였으며, 2016년 3월 부터 서울 리전에서 사용 가능합니다.

Config는 AWS 계정에서 지원되는 자원의 수량 및 구성 변경 횟수 (구성 항목)에 따라 과금됩니다. 초기 비용이 필요하지 않으며 언제든지 이용을 정지 할 수 있습니다.

1000 개의 구성 항목에 대해 매월 3 달러가 부과됩니다. 구성 내역 및 구성 스냅 샷의 스토리지 비용은 S3의 표준 요금이 적용됩니다. 또한 SNS를 알림을 이용할 경우, SNS 표준 요금이 부과됩니다.

만약 10000 개의 구성 항목이 매월 만들어지는 경우, 아마도 S3의 요금은 매월 기준 0.13 달러 이하가 될 것입니다. 매월 기준 100 만회의 SNS 알림을 AWS 무료 이용 범위 에서 사용할 수 있습니다.

Jeff;

Amazon CloudWatch 맞춤형 지표 생성하기

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

AWS Lambda와 Slack을 이용한 DevOps Chatroom 구현하기

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로 만들어진 예제를 사용하겠습니다.

원하는 폴더를 생성 후 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 RDS 확장 모니터링 기능 – MySQL 5.6, MariaDB 및 Aurora용

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

CloudWatch 대시 보드 – 맞춤형 통계 보기 기능 제공

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

CloudWatch Logs Subscription Consumer + Elasticsearch + Kibana를 통한 데이터 시각화

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

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

이벤트 데이터 시각화
오늘은 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의 한국어 번역글입니다.