Category: Compute


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

서버리스 Express 앱 개발을 위한 오픈 소스 패키지 공개

ExpressNode.js를 사용하는 인기있는 웹 프레임웍 중에 하나입니다. 이를 통해 손쉽게 “서버 없는(Serverless)” 웹 사이트, 웹 애플리케이션 및 API 서비르를 만들 수 있습니다. 서버 리스 환경에서 대부분 백엔드 로직은 필요에 따라 요청되는 무상태 기반인 경우가 많습니다. (Mike Roberts의 Serverless Architectures 글 참고. 한국어 번역)

AWS Lambda와 함께 사용 가능한 Amazon API Gateway를 통해 (얼마 전 새로 출시한 간편한 API 개발을 위한 신규 통합 기능을 기반으로) 기존 Express 애플리케이션에 서버리스 기능을 활용할 수 있습니다. API Gateway의 새로운 추가 기능 뿐만 아니라, 개발자별 API 사용량 제어 및 캐싱 등을 지원하는 Usage Plans을 통해 더 나은 API 서비스 제공이 가능합니다.

기존 Express 애플리케이션을 Lambda and API Gateway로 마이그레이션 하기 위해 aws-serverless-express 오픈 소스 패키지를 공개합니다. 여기에는 여러분의 이전 작업을 위한 시작점으로 필요한 샘플 예제가 포함되어 있습니다.

또한, API Gateway and Lambda를 통한 Express 앱 개발을 위한 두 가지 기술 정보를 참고하실 수 있습니다.

Jeff;

이 글은 Running Express Applications on AWS Lambda and Amazon API Gateway의 한국어 번역입니다.

EC2 예약 인스턴스 업데이트 – RI 변환 기능 및 리전 단위 적용

Amazon EC2 예약 인스턴스(Reserved Instance, RI) 구매 옵션은 8 년 전에 발표 되었습니다. 2009년에 시작 된 이 구매 모델에는 두 가지 장점이 있습니다. 먼저, 컴퓨팅 용량을 미리 예약함으로서 가용 영역(AZ) 내 특정 인스턴스 사용에 적용하는 대폭적인 할인율입니다. 몇 년 동안 고객 의견과 요구에 따라 이 모델을 개선하여 일정 기반 예약 인스턴스, 예약 수정 기능, Reserved Instance Marketplace를 통한 RI 매매 기능을 추가하였습니다. 오늘 두 가지의 기능을 강화하고자 합니다.

  • 리전(Region) 단위 할인 – 많은 AWS 고객이 용량 예약보다 할인율이 더 중요하며, 유연성이 증가한다면 할인율은 내려가도 무방하다는 의견을 주셨습니다. 그래서, 표준 RI에 용량을 예약하지 않고, 리전 내 중 하나의 AZ에서 실행한 인스턴스에 RI 할인이 자동으로 적용되도록 선택할 수 있습니다.
  • 변환 가능한(Convertible) 예약 인스턴스 – 변환 가능 RI는 유연성와 함께 높은 할인 (On-Demand에 비해 일반적으로 45%할인) 받을 수 있습니다. 예약 인스턴스와 연관된 인스턴스 패밀리 및 기타 매개 변수는 언제든지 변경할 수 있습니다. 예를 들어, 새로운 인스턴스 유형을 활용하기 위해 C3 RI를 C4 RI로 변환하거나, 응용 프로그램으로 인해 메모리 증가가 필요한 경우, C4 RI를 M4 RI로 변환 할 수 있습니다. 또한, EC2 가격 인하 를 계속 활용하기 위해 Convertible RI를 사용할 수 있습니다.

각각에 기능에 대해 자세히 살펴 보겠습니다.

리전(Region) 단위 적용
예약 인스턴스 (표준 또는 변환 가능)를 리전 내 모든 가용 영역(AZ)에 자동으로 적용하도록 설정할 수 있습니다. 이러한 리전 단위 적용을 통해 모든 가용 영역 내 RI 모델이 각 인스턴스에 자동으로 적용됨으로서, RI 할인 적용 범위가 넓어집니다. 이를 위해 별도의 용량 예약을 할 필요 없이, 인스턴스 가용 영역 선택이 필요합니다. 자주 인스턴스를 시작하고, 사용 및 종료하는 동적 환경에서는 이를 통해 컴퓨팅 용량 유연성이 증가하고 RI를 적용하는 최적 인스턴스 선택에 걸리는 시간이 짧아집니다. Auto Scaling를 통해 시작되어, Elastic Load Balancing의해 연결되는 인스턴스에서 수평적 확장이 가능한 아키텍처에서 큰 도움이 될 것입니다.

AWS Management Console 에서 Purchase Reserved Instances를 클릭 한 후 Search를 선택하면, 가능한 RI가 표시됩니다.

기존 처럼 하나의 가용 영역에 적용하는 용량 예약하는 RI를 구입하는 경우 Only show offerings that reserve capacity에 체크를 선택합니다.

RI 변환 기능
RI를 구입하는 고객의 목적은 일정하게 각 사용량에 맞는 인스턴스를 사용함으로서, 할인을 통한 가격적 이점을 보기 위함입니다. 그러나, 장기적인 관점에서 요구 사항에 따라 이에 대한 변경이 있을 경우, RI 인스턴스 타입의 변경이 필요합니다. 이를 위해서, RI 변환 기능을 사용할 수 있습니다. 요구 사항이 변경되는 경우, 변환 가능한(Convertible) 예약 인스턴스로 교체하면 됩니다. 계약 조건을 재설정하지 않고 새로운 인스턴스 유형 및 운영 체제를 설정한 변환 가능한 RI로 교체 할 수 있습니다. 교환은 무료로 언제든지 가능합니다.

교체 할 때, 원래 RI와 같거나 그 이상의 새로운 RI를 선택해야 하며, 경우에 따라서는 차액을 지불할 수 있습니다. 교환 프로세스는 각 Convertible RI의 정가를 기준으로 합니다. 이 가격은 교환하고자 하는 원본 RI 잔존 기간의 지불 금액 합계입니다.

Convertible RI를 구입하려면, Search를 클릭하기 전에 Offering ClassConvertible로 변경하십시오.

Convertible RI는 용량 예약 뿐만 아니라 On-Demand에 비해 일반적으로 45% 할인 받을 수 있습니다. Convertible RI는 3년 계약에 대한 모든 EC2 인스턴스 타입에 적용할 수 있습니다. 3개의 모든 지불 옵션 (선불없음, 일부 선불, 전액 선불)를 사용할 수 있습니다.

정식 출시
위의 구입 및 교환 옵션은 AWS Management Console, AWS Command Line Interface (CLI), AWS Tools for Windows PowerShell 또는 Reserved Instance APIs (DescribeReservedInstances, PurchaseReservedInstances, ModifyReservedInstances 등)에서 설정할 수 있습니다.

AWS Management Console , CLI, AWS Tools for Windows PowerShell 또는 Reserved Instance APIs ( DescribeReservedInstances , PurchaseReservedInstances , ModifyReservedInstances 등)에서 액세스 할 수 있습니다.

Convertible RI 및 리전 단위 적용 기능은 AWS GovCloud (US) 와 China (Beijing)을 제외한 모든 AWS 리전에서 사용할 수 있습니다. 이 두 리전에서도 곧 사용할 수 있을 예정입니다.

Jeff

이 글은 EC2 Reserved Instance Update – Convertible RIs and Regional Benefit의 한국어 번역입니다.

Amazon EC2 신규 GPU 인스턴스 타입 – P2 (16 GPU 지원)

컴퓨팅 하드웨어가 계속 발전하는 동안 CPU 연산 속도는 기하 급수적으로 증가하였습니다. 최근에 GPU (Graphics Processing Unit) 프로세스는 CPU 연산을 병렬적으로 처리하게 해줌으로서 기존 CPU의 병목을 줄여주는 핵심 하드웨어 장치가 되었습니다. 이를 통해 더 빠른 프로세스를 만들기 보다는 더 많은 병렬 컴퓨팅을 처리하게 되었습니다.

저희는 최근 많이 활용 요구가 높은 기계 학습 및 딥러닝(Deep Learning) 및 유체 역학 컴퓨팅 연산, 지진파 분석, 분자 모델링, 유전학 및 금융 분석 등 대량 컴퓨팅 연산에 도움이 될 P2 인스턴스 타입을 오늘 출시하게 되었습니다.

신규 P2 인스턴스 타입
신규 인스턴스 타입은 8 NVIDIA Tesla K80 Accelerators (각각 2개의 NVIDIA GK210 GPU)을 지원합니다. 각 GPU는 12GB 메모리를 가지고 있으며 (초당 240GB 메모리 대역폭 제공) 2,496개의 병렬 코어를 지원합니다. 또한, 더블 비트 오류를 검출해서 싱글 비트 오류를 고치는 ECC 메모리 보호 기능을 지원합니다. ECC 메모리 보호 가능 및 이중 플로팅 포인트 기능을 통해 위의 다양한 요구 사항을 수용할 수 있습니다.

아래는 오늘 출시한 인스턴스 타입 스펙입니다.

Instance Name GPU Count vCPU Count Memory Parallel Processing Cores
GPU Memory
Network Performance
p2.xlarge 1 4 61 GiB 2,496 12 GB High
p2.8xlarge 8 32 488 GiB 19,968 96 GB 10 Gigabit
p2.16xlarge 16 64 732 GiB 39,936 192 GB 20 Gigabit

모든 인스턴트 타입은 AWS에 제공하는 Intel Broadwell 2.7 GHz프로세스로서, p2.16xlarge는 C-states 및 P-states를 지원하며, 하나 또는 2개 코어를 제공할 때는 3.0 GHz까지 올릴 수 있습니다.

본 인스턴스의 GPU는 CUDA 7.5 이상, OpenCL 1.2 및 GPU Compute API를 지원합니다.  p2.8xlargep2.16xlarge 의 GPU는 PCI 파브릭으로 접속하고, 낮은 지연 속도와 피어간 GPU 및 GPU 전송을 지원합니다.

모든 인스턴스 타입은 Elastic Network Adapter (고성능 Amazon EC2 네트워크 어댑터)을 위의 표에 따라 지원하고, 최대 20 Gbps 네트워크 대역폭도 지원합니다.

P2  인스턴스는 VPC만 지원하며,  64-bit, HVM-스타일, EBS-지원 AMI에서 구동됩니다. 오늘 부터 US East (Northern Virginia), US West (Oregon)Europe (Ireland) 리전에서 온디멘드, 스팟 인스턴스, 예약 인스턴스 및 전용 호스팅(Dedicated Host)으로 사용할 수 있습니다.

아래는 어떻게 NVIDIA 드라이버 및  CUDA 툴킷을 설치하는 지 과정입니다. 먼저, 인스턴스를 띄운 후에 EBS 볼륨을 마운트 하고, 여기에 CUDA 및 관련 샘플을 설치합니다. (10GiB 이상 저장 공간 필요)

Bash
$ cd /ebs
$ sudo yum update -y
$ sudo yum groupinstall -y "Development tools"
$ sudo yum install -y kernel-devel-`uname -r`
$ wget http://us.download.nvidia.com/XFree86/Linux-x86_64/352.99/NVIDIA-Linux-x86_64-352.99.run
$ wget http://developer.download.nvidia.com/compute/cuda/7.5/Prod/local_installers/cuda_7.5.18_linux.run
$ chmod +x NVIDIA-Linux-x86_64-352.99.run
$ sudo ./NVIDIA-Linux-x86_64-352.99.run
$ chmod +x cuda_7.5.18_linux.run
$ sudo ./cuda_7.5.18_linux.run   # Don't install driver, just install CUDA and sample
$ sudo nvidia-smi -pm 1
$ sudo nvidia-smi -acp 0
$ sudo nvidia-smi --auto-boost-permission=0
$ sudo nvidia-smi -ac 2505,875

여기서 NVIDIA-Linux-x86_64-352.99.runcuda_7.5.18_linux.run 는 대화형 설치 프로그램으로서, 라이선스 동의 및 몇 가지 옵션과 경로를 설정합니다. 아래는 cuda_7.5.18_linux.run:를 통해 CUDA를 설치하는 과정입니다.

P2 및 OpenCL 실제 해보기
p2.8xlarge 인스턴스에서 Gist 를 받아서 컴파일을 할 수 있습니다.

Bash
[ec2-user@ip-10-0-0-242 ~]$ gcc test.c -I /usr/local/cuda/include/ -L /usr/local/cuda-7.5/lib64/ -lOpenCL -o test

테스트 실행 결과는 다음과 같습니다.

Bash
[ec2-user@ip-10-0-0-242 ~]$ ./test
1. Device: Tesla K80
 1.1 Hardware version: OpenCL 1.2 CUDA
 1.2 Software version: 352.99
 1.3 OpenCL C version: OpenCL C 1.2
 1.4 Parallel compute units: 13
2. Device: Tesla K80
 2.1 Hardware version: OpenCL 1.2 CUDA
 2.2 Software version: 352.99
 2.3 OpenCL C version: OpenCL C 1.2
 2.4 Parallel compute units: 13
3. Device: Tesla K80
 3.1 Hardware version: OpenCL 1.2 CUDA
 3.2 Software version: 352.99
 3.3 OpenCL C version: OpenCL C 1.2
 3.4 Parallel compute units: 13
4. Device: Tesla K80
 4.1 Hardware version: OpenCL 1.2 CUDA
 4.2 Software version: 352.99
 4.3 OpenCL C version: OpenCL C 1.2
 4.4 Parallel compute units: 13
5. Device: Tesla K80
 5.1 Hardware version: OpenCL 1.2 CUDA
 5.2 Software version: 352.99
 5.3 OpenCL C version: OpenCL C 1.2
 5.4 Parallel compute units: 13
6. Device: Tesla K80
 6.1 Hardware version: OpenCL 1.2 CUDA
 6.2 Software version: 352.99
 6.3 OpenCL C version: OpenCL C 1.2
 6.4 Parallel compute units: 13
7. Device: Tesla K80
 7.1 Hardware version: OpenCL 1.2 CUDA
 7.2 Software version: 352.99
 7.3 OpenCL C version: OpenCL C 1.2
 7.4 Parallel compute units: 13
8. Device: Tesla K80
 8.1 Hardware version: OpenCL 1.2 CUDA
 8.2 Software version: 352.99
 8.3 OpenCL C version: OpenCL C 1.2
 8.4 Parallel compute units: 13

보시다시피 정말 많은 용량의 컴퓨팅 리소스를 얻을 수 있습니다.

신규 Deep Learning AMI 제공
앞서 말씀 드린 대로, P2 인스턴스 타입은 기계 학습 및 딥러닝, 분자 모델링, 게놈 분석, 금융 데이터 분석 등의 요구 사항에 맞도록 설계되었습니다. 이를 위해 Deep Learning AMI 도 함께 제공합니다. 딥 러닝을 통해 더 많은 예측을 계산할 수 있습니다.

신규 AMI는 인기 높은 MNIST 데이터 베이스에서 추천하는 MXNet –  Caffe –  Theano –  TensorFlow –  Torch 등의 라이브러리를 기본적으로 설치 되어있습니다.

좀 더 자세한 사항은  ~ec2-user/src 내 README 파일을 참고하시기 바랍니다.

NVIDIA 지원 AMI
NVIDIA가 제공하는 아래 AMI도 참고하실 수 있습니다.

Jeff;

이 글은 New P2 Instance Type for Amazon EC2 – Up to 16 GPUs의 한국어 편집 및 요약본입니다.

Amazon EC2 업데이트 – 신규 Amazon Linux AMI 버전 및 M4.16xlarge 인스턴스 타입 공개

Amazon EC2에 사용하는 운영 체제인 이미지인 Amazon Linux AMI 새로운 버전을 출시했습니다.  2016.09 Amazon Linux AMI 버전은 모든 리전과 인스턴스 타입에서 바로 사용할 수 있습니다.

https://media.amazonwebservices.com/blog/2016/amazon_linux_2016_09_animated_cow_1.gif

Amazon Linux AMI는  HVM와 PV 모드, EBS 등을 지원합니다. 기존에 사용중인 인스턴스에서 새로운 버전으로 업그레이드 하시려면, 아래와 같은 커맨드를 실행하신 후 리부팅 하시면 됩니다.

Bash
$ sudo yum clean all
$ sudo yum update

새 버전에서는 Nginx 1.10, PostgreSQL 9.5, Python 3.5 , Amazon SSM Agent  등을 지원 하고 있으며, 더 자세한 것은 출시 소개서를 참고하시기 바랍니다.

추가적으로 기존 M4 인스턴스 타입에 더 규모가 큰 64 vCPUs 및 256 GiB RAM 메모리를 가진 m4.16xlarge 인스턴스 타입을 공개합니다.

Instance Name vCPU Count
RAM
Instance Storage Network Performance EBS-Optimized
m4.large 2 8 GiB EBS Only Moderate 450 Mbps
m4.xlarge 4 16 GiB EBS Only High 750 Mbps
m4.2xlarge 8 32 GiB EBS Only High 1,000 Mbps
m4.4xlarge 16 64 GiB EBS Only High 2,000 Mbps
m4.10xlarge 40 160 GiB EBS Only 10 Gbps 4,000 Mbps
m4.16xlarge 64 256 GiB EBS Only 20 Gbps 10,000 Mbps

새 인스턴스 타입은 Intel Xeon E5-2686 v4 (Broadwell) 프로세스를 사용하고 있으며, Elastic Network Adapter (ENA)를 이용한 20Gbps의 빠른 네트워크 대역폭을 지원합니다. m4.10xlarge와 같이 m4.x16large 역시 C states를 지원하고 C4 Instances 처럼 P status도 지원합니다.

새 M4 인스턴스 타입은 China (Beijing), South America (Brazil)AWS GovCloud (US)를 제외한 모든 리전에서 사용 가능하며, 자세한 사용 비용은 EC2 요금표를 참고하시기 바랍니다.

EC2 Spot Fleets – 신규 자동 스케일링 기능

EC2 Spot Fleet API – 한번에 수천개의 스팟 인스턴스 관리하기 글을 통해 한번의 요청에서 EC2 스팟 인스턴스 집합을 만들 수 있습니다. 스팟 집합 대상 용량을 지정하고 시간 당 입찰 가격을 입력하고, 인스턴스 유형을 선택하면됩니다.

백그라운드 작업을 통해 AWS는 최저가 스팟 인스턴스를 시작하여 필요한 대상 용량 (인스턴스 또는 가상 vCPU의 숫자로 표기)을 유지합니다. 인스턴스 집합 가격 상승으로 종료되면, 그 시점에서 최저가 인스턴스 교체가 시작됩니다.

신규 자동 확장 기능
오늘 스팟 집합 모델에 Auto Scaling을 추가함으로서 기능을 더욱 강화하였습니다. Amazon CloudWatch 메트릭을 기반으로 스팟 집합을 스케일-업 혹은 다운 할 수 있게되었습니다. 본 통계치를 통해 EC2, Amazon EC2 Container Service, 또는 Amazon Simple Queue Service (SQS) 등의 AWS 서비스 역시 사용할 수 있습니다. 또한, 응용 프로그램에서 만든 맞춤 통계수치를 사용하여 자동 스케일링이 시작되도록 할 수도 있습니다. 따라서, 이러한 통계 수치를 사용하여 스팟 집합의 크기 제어, 조건이나 부하가 바뀌더라도 응용 프로그램 가용성 및 성능과 비용을 세부적으로 제어 할 수 있습니다.

아래는 스팟 집합 자동 스케일링에 사용할 수 있는 애플리케이션의 예제들입니다.

  • 콘테이너 동작Amazon ECS에서 CPU 및 메모리 사용량을 기반한 콘테이너 기반 애플리케이션의 확장
  • 일괄 작업SQS 큐의 메시지 수를 기반한 일괄 작업의 확장
  • 스팟 집합MaxPercentCapacityAllocation와 같은 스팟 집합 통계를 기반한 집합 확장
  • 웹 서비스 – 초당 평균 요청 및 반응 시간에 따른 웹 서비스 확장

스팟 인스턴스 콘솔이나 AWS Command Line Interface (CLI), AWS CloudFormation, 및 AWS SDKs API 호출을 자동 스케일링을 설정할 수 있습니다.

잠깐 실제 콘솔에서 설정 방법을 살펴 보고자 합니다. 스팟 집합을 시작하고 이를 스케일업/다운을 하기 위해 Request and maintain 요청 형식을 선택합니다.

스팟 집합이 1분내로 올라옵니다.

예제로 SQS 큐를 만들고 일부 메시지를 큐에 넣은 다음 CloudWatch 알람​​(AppQueueBackingUp)을 정의했습니다. 메시지 큐에 10 건 이상의 메시지가 들어가면 알람이 시작됩니다.

또한, 알람 (AppQueueNearlyEmpty)도 정의했습니다. 이는 메시지 큐에 메시지가 2 건 이하가 될 때, 취소되는 것입니다.

마지막으로, 알람을 스팟 집합의 ScaleUpScaleDown 정책에 연결했습니다.

이 글을 쓰기 전에 SQS 대기열에 5개의 메시지를 넣었습니다. 스팟 집합을 시작하고 스케일링 정책을 설정한 후, 추가로 5개의 메시지를 보내 알람이 시작되는 것을 기다렸습니다.

스팟 함대 용량이 예상대로 증가한 것으로 나타났습니다. 이 결과는 History 탭에 표시되었습니다 ( “New targetCapacity : 5”).

마무리로 큐에서 모든 메시지를 삭제하고, 돌아 가면 스팟 집합이 예상대로 축소 된것을 알 수 있습니다 ( “New targetCapacity : 2”).

정식 출시
스팟 집합 자동 스케일링 기능은 스팟 인스턴스가 지원되는 모든 리전에서 지금 부터 바로 이용할 수 있습니다.

Jeff;

본 글은 New – Auto Scaling for EC2 Spot Fleets의 한국어 번역입니다.

AWS Lambda, Amazon API Gateway 서울 리전 출시!

2014년 AWS re:Invent에서 처음 발표된 AWS Lambda는 클라우드에서 서버 관리에 대한 걱정 없이 프로그래밍 코드를 배포하고, 실행 시간에 대해서만 비용을 지불하는 서버 없는(Serveless) 아키텍처를 구성할 수 있습니다.  특히, 2015년 6월 출시된 Amazon API Gateway와 연계를 통해 외부에서 들어오는다양한 API 호출 대한 실행도 가능하여, API Gateway와 함께 AWS 자원을 제어하는 모든 종류의 기능을 수행할 수 있습니다.

aws-lambda-in-icn

AWS의 핵심 서비스의 하나로 자리잡은 두 가지 서비스가 오늘 서울 리전에 출시 되었습니다. 이로서 국내 개발자 및 기업들도 서울 리전에서 모바일, 웹, 기업용 또는 IoT 애플리케이션에서 REST 기반 서비스 개발 및 AWS 서비스와 연계한 이벤트 기반 서버리스 클라우드를 구현해 볼 수 있게 되었습니다.

AWS Lambda와 API Gateway를 기반한 서버리스 아키텍처에 대해서는 아래의 온라인 세미나 강의 및 발표 자료를 참고하시면 좀 더 쉽게 이해하실 수 있습니다.

serverless-webinar-channy
AWS Lambda 및 API Gateway를 기반으로 한 ‘서버리스(Serverless) 아키텍처’

서버리스 아키텍처는 다양한 워크로드 사례에 적용할 수 있습니다. 아래는 웹, 모바일, 실시간 파일 및 스트림 처리, IoT 등의 샘플 아키텍처를 한국어로 제공한 것입니다.

아울러 AWS Lambda 소개 및 활용 영상 및 서버리스 아키텍처 관련 정보는 아래를 참고하시기 바랍니다.AWS 사용자모임 역시 관련 세미나를 여러번 개최하였습니다.

AWS Lambda 및 Amazon API Gateway의 서울 리전 출시에 맞추어 다양한 개발자 이벤트를 준비하였으니, 많은 참여 부탁드립니다.

awskrug-seminar
AWSKRUG 정기 세미나 | 서버리스 아키텍처 특집
아마존웹서비스 한국 사용자모임(AWS Korea User Group)이 주최하는 정기 세미나입니다. 이번 달에는 AWS Lambda 및 Amazon API Gateway를 기반한 서버리스(Serverless) 아키텍처 특집으로 열립니다. 실제 적용 중인 개발자들의 경험과 노하우를 공유합니다.

  • 일시: 2016년 9월 21일(수) 오후 7시 – 9시
  • 장소: AWS코리아 트레이닝룸

참가 신청

gaming-on-aws-hackathon-sep

Gaming on AWS | 서버리스 게임 해커톤
아마존 웹서비스(AWS)는 지속적으로 신규 서비스와 기능을 선보이며 게임 플랫폼의 혁신을 선도하고 있으며, 이를 사용해 서버 없는(Serverless) 게임 아키텍쳐와 Mobile SDK 등을 결합해 혁신적인 게임 플랫폼을 매우 손쉽게 만들 수 있습니다. AWS의 다양한 서비스들을 게임 개발에 접목해보고 싶은 개발자 여러분을 초대합니다.

  • 일시: 2016년 9월 24일(토) 오전 10시 – 오후 7시
  • 장소: AWS코리아 트레이닝룸

참가 신청 (9월 2일까지 신청 마감!)

zombie-workshop-oct

Zombie Apocalypse Workshop: 서울 워크샵
본 워크샵은 AWS Lambda, Amazon API Gateway, Amazon DynamoDB와 기타 AWS 서비스를 기반으로 서버 없는(Serverless) 애플리케이션을 구축해 보는 실습 행사입니다.본 실습 코스는 UI 및 백엔드가 구성되어 있는 기반 플랫폼을 활용하여, 채팅 서비스, Twilio 기반 SMS 연동, Elasticsearch 기반 채팅 메시지 검색, Slack 기반 연동, Intel Edison 좀비 모션 센서 등을 구성하는 실습을 진행합니다.

  • 일시: 2016년 10월 14일(금) 오전 10시 – 오후 7시
  • 장소: AWS코리아 트레이닝룸

참가 신청

AWS 기반 웹 및 애플리케이션 서버 부하 테스트: A to Z

사용자가 이용하고 있는 온라인 서비스로부터 예상치 못한 느려짐을 겪거나, 접속 불가로 인해 서비스 이용 조차 할 수 없다면, 서비스에 중요한 재방문율(Retention Rate)과 유료 전환율(Conversation Rate)을 하락 시켜 비지니스에 큰 손실을 야기 할 수 있습니다. 이런 성능 관련 문제를 예방하기 위해 성능 테스트, 특히 부하 테스트에 대한 중요성이 크게 증가하고 있으며, 더불어 관련  도구 및 서비스의 다양성 또한 증가하고 있습니다.

이번 글은 AWS 클라우드에서 어떻게 웹/애플리케이션 서버의 부하 테스트를 하는지 모범 사례를 알려드리기 위한 것으로, 부하테스트 목적과 고려 사항 그리고 단계 및 도구 등을 대해 다루고자 합니다.

부하 테스트의 목적
일반적으로 부하 테스트는 서비스 개발 이후, 운영을 하기 직전 수행하는 테스트 중 하나로서, 실제 요구되는 부하를 서비스가 수용할 수 있는지를 확인하기 위한 작업 입니다. 사용자 활동을 시뮬레이션 하고 인프라 및 서버의 동작을 모니터링 함으로써, 전부는 아닐지라도, 많은 부분의 병목 현상(Bottleneck)을 제거할 수 있습니다.

부하 테스트의 목적으로는 보통 다음 세가지가 있습니다.

  • 현재 서비스 구성의 제한(limit)을 찾기 위함
  • 원하는 부하를 수용할 수 있게끔 구성되었는지 확인하기 위함
  • 병목 지점을 찾고 병목 현상을 제거하기 위함

부하 테스트 전 고려되어야 할 점
실제 성능 테스트 시, 부하 테스트를 비중 있게 여기지 않는 경우가 많으며, ApacheBenchJMeter 와 같은 도구를 다운로드 한 뒤, 특정 시나리오를 기반으로 하여 도구를 실행하는 것만으로 충분하다고 생각하는 경우가 있습니다. 하지만, 실제 워크로드는 다양한 변수와 시나리오를 가지고 있기 때문에, 부하 테스트를 진행할 때 충분히 이점을 반영 하여 야지만 실제 서비스에서 예상 가능한 결과를 가져올 수 있다는 것은 분명한 사실 입니다.

그럼 실용적인 부하 테스트를 위해 어떤 부분들을 고려해야 할까요?

  • 충분한 테스트용 서버 자원 확보: 최대의 트래픽을 생성하여 테스트 하기 위해서는 충분한 서버 자원이 요구되며, 부족할 경우 적절한 테스트가 이루어지기 힘듭니다.
  • 테스트 시, 블랙박스 혹은 격리된 환경 제어: 부하 테스트는 많은 요청과 패킷을 생성하기 때문에 사내 인프라의 많은 부분을 포화 상태로 만들기 쉽습니다. 이를 방지하기 위해 제한된 자원만 할당된 블랙 박스 혹은 격리된 환경에서 테스트를 수행하는 경우가 많습니다.
  • 글로벌 기반의 부하 생성: 글로벌 서비스의 경우, 전 세계 각 지역에서 부하를 생성하여 테스트를 진행하여야만 실제 사용 패턴에 가까운 시나리오가 될 수 있습니다. 이를 통해 글로벌 커버리지를 확인할 수 있으며, 실제 워크로드에서 얻을 수 있는 유사한 각종 성능 관련 지표도 얻을 수 있습니다.
  • 높은 비용과 불규칙적인 사용성에 대한 주의: 격리된 환경과 더불어 여러 리전을 커버하기 위한 테스트 환경은 때로 높은 비용을 요구합니다. 구성된 환경은 짧은 기간 동안만 집중적으로 사용되기도 하며, 안정적인 서비스가 유지될 땐 드물게 사용되기도 하기 때문에, 사용하지 않을 때도 유지하여야 하는 등의 자원을 효율적으로 사용하지 못해 불필요한 비용이 발생 하기도 합니다.
  • 높은 아키텍처 복잡성에 대한 주의: 상기 언급된 부분들을 고려하여 부하 테스트 환경을 구성한다면 꽤나 높은 복잡성이 요구 됩니다. 나아가 반복적인 테스트를 위해, 가상의 가짜(Dummy) 데이터 등에 의해 지저분해진 환경을 초기화 시켜줄 수 있는 방안도 필요 합니다.

AWS 클라우드 기반 부하 테스트의 장점
AWS 클라우드는 부하 테스트를 진행하기 위해 고려할 사항에 대한 적절한 해답을 가지고 있습니다.  AWS 클라우드에서 부하 테스트 하게 된다면 어떤 특징을 가지고 있을까요?

  • 사용한 만큼 지불하는 비용 효율성: Amazon EC2 인스턴스는 사용한 만큼만 비용이 발생하기 때문에, 테스트 조건에 맞는 인스턴스 타입을 선택하여 비용 효율성을 높일 수 있습니다. 예를 들어, 정식 부하 테스트를 진행하기 전에 저렴한 마이크로 인스턴스 수십~수백대를 활용하여, 서버 워밍업을 저렴한 비용으로 할 수 있습니다. 또한, 인스턴스 사용이 끝나면 즉시 종료할 수 있어 불필요한 비용 발생을 줄일 수 있습니다.
  • 충분하고 유연한 컴퓨팅 자원 제공: AWS가 제공하는 컴퓨팅 자원을 활용한다면, 필요한 규모의 부하에 대해 자유롭게 테스트를 수행할 수 있습니다. 또한, 오토스케일링(Auto Scaling)을 통해 부하 테스트 시 자원을 자동으로 증설 혹은 감소 시킬 수 있습니다.
  • 글로벌 리전(Region)으로부터의 부하 생성: AWS가 제공하는 글로벌 인프라를 통해 전 세계 각 리전으로부터의 부하 생성을 손쉽게 할 수 있습니다.
  • 쉽고 단순한 아키텍처 구성 및 관리: AWS CloudFormation 을 비롯한 다양한 배포 자동화 서비스 및 기능을 통해 프로덕션과 테스트 용 환경을 동일한 방법으로 손 쉽게 구성할 수 있습니다. 뿐만 아니라 관리형 서비스를 활용하여 운영 측면에서의 부담도 줄일 수 있어, 테스트 환경 구축에 관한 복잡성을 줄일 수 있습니다.

부하 테스트의 단계
부하 테스트는 서비스 전체 스택을 대상으로 진행할 수도 있지만, 최근에는 마이크로서비스(Microservices) 나 서비스 지향 구조(Service-Oriented Architecture) 등의 형태로 서비스를 디자인하는 경우가 많아, 전체 스택을 구성하고 있는 작은 컴포넌트들부터 진행되는 경우가 많아지고 있습니다.

또, 빠른 병목 현상 발견과 수정을 위해, 애플리케이션 로직이 적용되기 전 순수한 인프라 수준에서 시작하여 작은 컴포넌트들, 솔루션, 그리고 애플리케이션 순으로 부하 테스트를 확대해 나갈 수도 있습니다.

아래는 일반적으로 수행할 수 있는 부하 테스트 단계 입니다.

  • 비결합(Loosely Coupled)된 개별 컴포넌트에 대한 부하 테스트: 이를 통해 각 컴포넌트 별 병목 현상을 보다 빠르게 발견하고 수정할 수 있습니다.
  • 내부 서비스에 대한 부하 테스트: 로그 기록 서비스와 같이 높은 처리량이 요구되는 서비스나, 결제 서비스와 같이 전체 서비스 품질에 있어 중요한 내부 서비스를 대상으로 테스트를 진행 합니다.
  • 외부 서비스에 대한 부하 테스트: Facebook, Twitter 등의 소셜 서비스나 Google 등의 플랫폼에 대한 서비스들, 또는 푸시 알림 서비스 등의 외부 서비스를 대상으로 테스트를 진행 합니다.
  • 전체 스택에 대해 부하 테스트: 개별 컴포넌트들에 대한 테스트를 완료한 뒤, 컴포넌트간의 상호작용을 알기 위해 처음부터 끝까지 전체 스택에 대해서 테스트 진행 합니다.

단계별 부하 테스트 수행 방법
앞서 언급한 것처럼, 부하 테스트는 전체 스택에 대해서도 수행 가능하지만, 작은 비결합된 컴포넌트나 기능 단위로도 수행 가능합니다. 그리고 작은 단위로 수행될 수록 더 분명하게 병목 지점을 파악하기에 수월 합니다. 그렇기에, 가능한 작은 단위부터 단계별로 진행하는게 원하는 결과를 얻어내는데 효율적입니다.

다음은 전형적인 3단계(3-tier) 웹 서비스에 대해 단계별로 부하 테스트를 진행하는 것을 설명하고 있습니다.

load-test-image001

  1. 최초 ‘WEB’ 을 출력하는 웹 페이지를 대상으로 동시 연결성에 대한 테스트 수행 → 결과 평가→최적화 진행 (Client →Web Server)
  2. 웹 서버를 통해 애플리케이션 서버에서 넘겨 받은 ‘APPLICATION’ 을 출력하는 웹 페이지를 대상으로 동시 연결성에 대한 테스트 수행→ 결과 평가 → 최적화 진행 (Client →Web Server → App Server – w/o Logic)
  3. 데이터베이스에서 최소한의 쿼리 결과를 전달 받아 출력하는 웹 페이지를 대상으로 동시 연결성에 대한 테스트 수행 →결과 평가 → 최적화 진행
    (Client →Web Server → App Server – w/o Logic → Database)
  4. 3-tier 스택 전체를 대상으로 애플리케이션 로직이 적용된 페이지에 동시 연결성에 대한 테스트 수행 → 결과 평가 → 최적화 진행
    (Client → Web Server → App Server – with Logic →Database)
  5. 4번을 기반으로 다양한 시나리오를 지정하여 테스트 수행 → (얻고자 하는 지표 기준에 대해서) 결과 평과 → 최적화 진행

부하 테스트 시, 각 레이어별 고려하여야 할 사항
부하 테스트를 수행한 뒤 각 레이어별로 발생할 수 있는 상황과 고려하여야 할 부분에 대해서 알아보도록 하겠습니다.

  1. 네트워크 용량 확인: 테스트 환경이 구성된 인프라와 관련하여 여러가지 지표를 확인할 수 있지만, 대표적으로 아웃바운드 연결이 예상되는 최대의 부하를 처리할 수 있는지 확인할 필요가 있습니다. Amazon EC2 의 경우 인스턴스 타입 마다 서로 다른 네트워킹 성능을 제공하고 있기에, 부하에 따른 적절한 인스턴스 타입 선택이 중요 합니다. 또 사내 인프라와 프라이핏하게 연결되어 있다면, VPN 관련 네트워킹 성능에 대해서도 확인을 하여야 합니다.
  2. 부하 생성 클라이언트: 앞서 설명하였듯이 부하 테스트의 요구사항 중 하나로, 필요한 만큼의 부하를 생성할 수 있는 충분한 인스턴스의 확보가 요구됩니다. 하지만, 설정 및 구현 방식에 의해 하나의 부하 생성 클라이언트가 처리할 수 있는 동시성에 큰 제한이 있다면, 필요 이상으로 복수개의 인스턴스가 요구되어 비용이 증가할 수 있습니다. 이럴 땐 Thread 기반의 툴 보다는 높은 동시성을 제공하는 Async IO 기반의 툴을 사용하여 테스트를 진행하는게 좋습니다.
  3. 로드 밸런싱: ELB(Elastic Load Balancing)는 서비스 전체 부하를 백엔드에 등록된 복수개의 인스턴스로 분산하는 기능을 제공합니다. 부하 테스트를 수행할 때 다양한 이유로 기대치 보다 낮은 결과나 5xx 에러가 발생하는 것을 볼 수 있습니다. 이 때, ELB 가 제공하는 다양한 모니터링 지표들을 확인하면, 어느 곳에서 병목 현상이나 에러가 발생되는지 확인하는데 도움이 됩니다. 가장 자주 발생하는 문제는, 503 Server Unavailable 이나 504 Gateway Timeout 에러 발생과 동시에, ELB 의 모니터링 지표에 SurgeQueueLength 가 1024 로 기록되고 SpilloverCount 가 0 보다 높을 경우 입니다. SurgeQueueLength 는 ELB 에 등록된 백엔드 인스턴스가 요청을 처리하지 못하여 쌓이게 되는 ELB 의 큐 이며, 앞서 언급한 것처럼 1024가 큐의 최대 크기 입니다. 이 최대 크기를 넘어서면 요청을 한 클라이언트에 5xx 에러를 보내게 되고, 동시에 SpilloverCount 가 기록 됩니다. 이 문제를 해결하기 위해서는 적시에 Auto Scaling 이 일어날 수 있도록 적절한 지표를 기준으로 알람을 발생 시킬 수 있도록 해야 합니다. 백엔드 인스턴스에서 동작하는 시스템이 어떤 자원을 더 많이 사용하는지 확인을 하고, 그 자원의 지표를 기준으로 Auto Scaling 을 설정하는 것이 좋습니다. SurgeQueueLength 를 기준으로 알람이 발생하게 하는 것도 한 가지 방법 입니다. ELB 가 제공하는 지표들은 여기에서 확인할 수 있습니다.
    추가로 ELB 도 발생하는 부하에 따라 Auto Scaling 을 통해 규모가 변화되도록 설계 되어 있습니다. 만약, 매우 급격한 트래픽 증가가 일어날 때 ELB 가 확장되는 속도가 증가하는 트래픽을 수용하지 못한다면 5xx 에러가 발생할 수 있습니다. 이를 방지 하기 위해, 미리 점차적으로 증가하는 부하 테스트를 통해 어느정도 ELB 를 확장 시켜 둘 수 있습니다. 또한, ELB 에 등록된 백엔드 인스턴스에서 Keep-Alive 기능을 활성화 시켜, ELB 와 백엔드 인스턴스간에 불필요한 연결 수립이 일어나는 것을 방지한다면 더 높은 성능을 기대할 수 있습니다.
  4. 서버 인스턴스: 서버 인스턴스의 설정 값에 따라 웹/애플리케이션 서버의 자원 사용 효율성이 달라 집니다. 대표적으로 Linux 서버의 open files 숫자를 늘려 두지 않으면, 동시 접속이 기본값인 1024 개로 제한되어 서버 인스턴스를 효과적으로 사용할 수 없습니다.
  5. 애플리케이션 서버: 애플리케이션 서버의 종류마다 다르지만, 일반적으로 Tomcat 등의 Thread 기반의 애플리케이션 서버일 경우, Thread Pool 의 크기가 너무 작다면 처리 되어야할 요청들이 기다리는(waiting) 상태가 길어져 전체 부하 테스트의 효율성을 떨어뜨릴 수 있습니다. 최근에는 Thread 기반의 애플리케이션 서버가 가지고 있는 제약으로 인해, Event 기반의 비동기 형태의 애플리케이션 서버가 자주 사용되어 집니다.
  6. 애플리케이션: 애플리케이션 코드와 프레임워크 둘로 나누어 생각해 볼 수 있습니다. 애플리케이션 코드 내에서 잘못된 방식으로 프레임워크나 API 를 사용할 수 있으며, blocking 코드가 포함되어 있다거나, 불필요한 연산을 진행, 또 테스트 코드를 삭제하지 않았다는 등의 문제가 있을 수 있습니다. 이 때에는 적절한 Unit Test 와 Lint 등을 통해 문제를 조기에 발견할 수 있어야 합니다.  사용하는 웹 프레임워크나 ORM(Object-relational mapping)과 같은 라이브러리가 가지고 있는 버그로 인하여 문제가 발생할 수도 있습니다. 애플리케이션 관련 다양한 문제를 해결하기 위해 APM(Application Performance Monitoring) 을 활용하여 성능을 모니터링 하는 것도 한가지 방법 입니다.
  7. 데이터베이스: CPU 사용률과 응답 시간(response time) 등을 확인할 필요가 있습니다. 특히 데이터베이스를 설정한 방법에 따라 더 요구되는 자원을 눈 여겨 볼 필요가 있습니다. 최근에는 성능을 향상 시키기 위해 메모리를 적극 활용하게끔 설정을 하는 경우가 많으며, 이때에는 메모리 사용률이 특정 수치 이상으로 넘어갈 경우, 알람을 발생 하도록 설정하여 병목 지점 확인이 가능 하겠습니다.

부하 테스트 관련 도구 및 서비스
부하 테스트를 위해 사용할 수 있는 다양한 툴과 서비스들이 존재 합니다. 간단한 소개와 함께 특징들을 살펴보겠습니다.

  • ApacheBench (http://httpd.apache.org/docs/2.2/en/programs/ab.html): 일반적으로 HTTP 웹 서버의 성능을 측정하기 위해서 자주 사용되는 툴입니다. 기본적인 HTTP 연결에 대해서 테스트를 할 때 자주 사용되는 툴이지만, HTTP/1.1 을 지원하지 않고, 한번에 하나의 대상 URL로 테스트가 가능한 것 등의 제한이 있습니다.
  • Siege (https://www.joedog.org/siege-home/): HTTP 부하 테스트와 벤치마킹 유틸리티 입니다. 한번에 복수개의 URL 로 테스트가 가능하고, Basic 인증을 지원하며 HTTP와 HTTPS 프로토콜로 테스트가 가능하는 등 ApacheBench 의 제한을 어느정도 해소 해 줍니다. 또 ApacheBench 와 비슷한 인터페이스를 가지고 있어 다른 툴과의 연계가 자유로운 편입니다. 하지만 Thread 기반으로 구현되어 있어 동시성에 제한이 있으며, 미미할 수 있지만 Context Switching 등으로 인하여 성능에도 영향이 있습니다.
  • JMeter (http://jmeter.apache.org/): 1998 년 부터 시작된 프로젝트로서 오랫동안 기능 강화를 지속해오고 있는 Java 기반의 부하 테스트 툴 입니다. HTTP 뿐만 아니라 다양한 프로토콜을 지원하며, 많은 기능을 가진 GUI 를 제공 합니다. 실제 워크로드를 시뮬레이션 하기 위해 다양한 방법으로 커스터마이징이 가능합니다. 하지만 앞서 언급한것처럼 Thread 기반으로 구현되어 있어 성능과 동시성에 대해서 제한이 있습니다. 이를 해결하기 위해, 복수개의 인스턴스에서 실행시켜 테스트를 수행할 수 있는 Remote Testing 기능을 지원 합니다. 복수개의 EC2를 활용하거나, BlazeMeterFlood.io 와 같은 JMeter 를 지원하는 부하 테스트 서비스를 사용할 수도 있습니다.
  • The Grinder (http://grinder.sourceforge.net/): Java 기반의 부하 테스트 프레임워크 입니다. Agent 가 지정한 값을 기반으로 부하를 생성하며, IDE 형태의 콘솔에서 Agent 들을 제어 및 결과 모니터링이 가능합니다. 마찬가지로 Thread 기반으로 구현되어 있어 성능과 동시성에 대해 제한이 있습니다.
  • Gatling (http://gatling.io/): Akka 와 Netty 기반의 Scala 로 개발된 부하 테스트 프레임워크 입니다. Thread 기반이 아닌 Event 와 Async IO 기반으로 구현되어, 높은 성능을 제공하며 HTML 보고서 생성 기능은 물론 시나리오를 DSL 로 작성하여 부하 테스트에 사용할 수 있는 기능을 제공하고 있습니다.
  • Tsung (http://tsung.erlang-projects.org/): Erlang 으로 개발된 부하 테스트 툴로서, HTTP는 물론 Websocket 이나 인증 시스템, 데이터베이스, MQTT 와 같은 TCP 기반의 다양한 프로토콜을 지원합니다. 동시성 지향 프로그래밍 언어 (concurrency-oriented programming language) 인 Erlang 이 가지고 있는 장점으로 인해, 성능과 확장성, 내결함성(Fault Tolerance)에서 큰 이점을 제공하고 있습니다. GUI 를 제공하지 않아 CLI 또는 Script 를 활용하여야 합니다.
  • Bees (https://github.com/newsapps/beeswithmachineguns): AWS 의 장점을 적극 활용한 오픈 소스 부하 테스트 툴로서, 부하를 분산 생성하기 위해 사용자의 AWS 계정에서 EC2 인스턴스를 지정한 개수만큼 생성하여 부하 테스트 대상에 테스트를 진행합니다. 비용을 줄이기 위해 스팟 인스턴스를 생성하여 활용할 수 있는 옵션도 제공하고 있습니다. 부하 테스트를 위해 ApacheBench 를 사용하기 때문에 ApacheBench 가 가지고 있는 제한을 그대로 가지고 있습니다.
  • Vegeta (https://github.com/tsenart/vegeta): Go 언어로 개발된 오픈소스 HTTP 부하 테스트 툴이며 CLI 로 사용하거나 라이브러리로 사용 가능합니다. 보통의 다른 툴과 다르게 초당 일정한 속도로 특정 수치의 요청을 지속하는데 초점을 맞추고 있어, 예상되는 최대 트래픽이 지속적으로 발생하였을 때 서비스와 인프라의 상태가 어떻게 변화하는지 확인하는데 적합한 툴 입니다.
  • RedLine13 (https://www.redline13.com/): AWS 의 Advanced Technology Partner 중 하나로서, AWS 기반의 부하 테스트를 수행하는 서비스 입니다. 사용자의 AWS 계정에서 IAM 을 생성하여 RedLine13 과 연동을 하면, 사용자의 AWS 계정에서 Agent 가 포함된 인스턴스가 실행되어 테스트가 진행 됩니다. 스팟 인스턴스를 활용할 수 있어 비용을 줄일 수 있습니다. 여기에서 RedLine13 과 Apache JMeter 를 활용하여 모바일 애플리케이션을 테스트 하는 데모를 보실 수 있습니다.
  • Loader.io (https://loader.io/): 클라우드 기반의 부하 테스트 서비스로서, 웹 페이지에서 대상 서버를 선택하고 원하는 동시성 등을 지정할 수 있으며, 그 결과를 보기 좋게 표시해 줍니다. 또한, 진행한 테스트를 추후에 리플레이 할 수도 있습니다.
  • Goad (https://goad.io/): AWS Lambda 를 활용하여 부하를 분산 생성하여 테스트를 수행하는 오픈 소스 툴로서 Go 언어로 개발 되었습니다. 실제 AWS 의 이점과 AWS Lambda 의 강력함을 잘 활용한 툴 입니다. 툴을 실행하면 AWS Lambda 함수를 생성 (혹은 갱신) 하여, 대상 URL 에 동시적으로 부하 테스트를 시작합니다. 그리고 각 결과는 AWS SQS 로 보내어지고, 최종적으로 최초 실행한 툴에서 결과를 취합하여 보여줍니다.
    load-test-image003

그밖에도 다양한 AWS Marketplace에서도 다양한 파트너들의 부하 테스트 솔루션을제공하고있습니다.

부하테스트 시 유용한 팁 모음
AWS 클라우드 기반으로 부하 테스트를 진행하는데 있어서 알아두면 도움이 되는 팁들을 간단하게 소개해 드리고자 합니다.

  • 로그 기록과 확인: 부하 테스트를 진행할 때, 로그 작성은 File IO 를 요구하는 작업이기에, 미미하게 테스트 수행 능력에 영향을 미칠 수 있습니다. 특히나 테스트 환경에서는 로그 수준을 낮추어(verbose 또는 debug) 더 많은 로그가 기록되도록 하는 경우가 많아, 실제 프로덕션에 비해 성능에 미치는 영향이 더 클 수 있습니다. 하지만 가능한 로그를 기록하는게 추후 발생하는 문제 파악에 도움을 줄 수 있기 때문에 기록을 하는게 권장 됩니다. 또는, 최초의 워밍업을 진행할 때 로그를 활성화하여 진행을 하고, 이후의 테스트에 대해서는 로그를 비활성화하여 진행할 수도 있겠습니다. 만약 그 결과가 기대에 미치지 않는다면, 다시 로그를 활성화 한 뒤 테스트를 진행하고, 생성되는 로그를 통해 문제를 파악할 수 있겠습니다.
  • 적절한 인스턴스의 선택: EC2 인스턴스는 요구되는 워크로드에 맞추어 선택할 수 있도록 다양한 종류가 준비되어 있습니다. 사용하는 웹/애플리케이션/데이터베이스에 따라 상대적으로 더 요구되는 자원은 다를 수 있으며, 그에 맞추어 인스턴스를 선택하는 것이 비용도 절약하며 더 적합한 성능을 발휘할 수 있겠습니다. 예를 들어, 특별한 연산이 수행되지 않고 다른 서비스와 통신이 주 목적이라면, 적은 CPU 자원과 적절한 Memory 자원, 그리고 높은 Bandwidth 와 Enhanced Networking 을 제공하는 인스턴스가 비용과 성능 관점에서 좋은 선택일 수 있습니다.
  • 비용 최소화: 유의미한 결과를 얻기 위해 부하 테스트 대상 환경을 가능한 실제 환경과 비슷하게 구성할 필요가 있습니다. 물론, 실제 프로덕션 환경에서 테스트를 수행할 수도 있지만, 이는 가상의 가짜(Dummy) 데이터를 생성하여 프로덕션 환경을 어지럽히고 라이브 서비스의 안정성을 헤치는 등의 위험성이 있기에 적극적으로 피해야 합니다. 실제 프로덕션 환경과 비슷한 환경을 구성하여 부하 테스트를 수행하는데 있어서 가장 먼저 고려하여야 할 사항은 비용 입니다. 일반적으로 최대 부하에 대한 테스트 진행을 위해, 수십에서 수백 대의 인스턴스가 필요할 수 있으며, 큰 규모의 부하를 생성하기 위해서도 많은 인스턴스가 요구되기 때문입니다. 이 때, 비용을 최소화 하기 위해 스팟 인스턴스를 활용할 수 있습니다. 스팟 인스턴스는 EC2 컴퓨팅 예비 용량에 입찰을 통해 온디맨드 요금과 비교하여 할인된 요금으로 사용할 수 있는 방법을 제공하며, 일반적으로 50~90% 저렴한 비용으로 사용할 수 있습니다. 자세한 내용은 여기를 참조 하시기 바랍니다.
  • 다양한 도구와 서비스의 복합적 활용: 앞서 부하 테스트를 위한 다양한 툴과 서비스에 대해서 알아 보았습니다. 부하 테스트를 진행할 때, 어떤 특정 툴 또는 서비스 하나만 선택해서 사용 할 필요는 없습니다. 각 툴과 서비스 별로, 목적성과 고유의 특징을 가지고 있기에, 용도에 맞게 복합하여 사용하는게 더 효율적일 수 있습니다. 예를 들어, GUI 의 완성도가 높고 다양한 시나리오를 설정할 수 있는 JMeter 는 웹 애플리케이션 내에서 사용자의 행동 흐름에 대해 부하 테스트를 하는데 적합할 수 있습니다. 그 이외의 툴과 서비스들도 특징들이 있으며 다음과 같이 활용할 수 있겠습니다.
    도구 명 활용 방법
    JMeter 웹 애플리케이션 내에서 사용자의 행동 흐름에 대해 부하 테스트를 하고 싶을 때
    Tsung API 가 수용할 수 있는 최대치의 부하를 알고 싶을 때
    Vegeta 어떤 API 에 대해 초당 특정 수치의 요청이 지속될 경우 발생하는 상황을 파악하고 싶을 때
    Goad 부하 생성 클라이언트 구성을 포함한 부하 테스트 관련 인프라 구성을 피하고 싶을 때
    RedLine13 JMeter 로 테스트 플랜을 작성하여 활용을 원하지만, 비용을 최소화 하고 싶고 사용한 만큼만 비용이 발생하길 원할 때
    Blazemeter 높은 동시성을 위해 JMeter 의 Remote Testing 기능을 활용하고 싶지만, 테스트 플랜 작성에 집중하고, 부하 테스트 관련 인프라 구성은 하고 싶지 않을 때
    Loader.io 부하 테스트 관련 인프라 구성을 하고 싶지 않고, Tsung 과 비슷한 목적으로 사용하고 싶을 때

부하 테스트에는 보통의 시나리오 기반의 가상의 워크로드에 대한 부하 테스트 뿐만 아니라, 실제 워크로드에 대한 부하 테스트를 위해 프로덕션에서 발생하는 트래픽을 활용하는 방법도 있습니다. 프로덕션 환경의 실제 트래픽을 활용하기 위해서는, 트래픽을 재사용 하기 위해 기록하거나 곧바로 테스트 환경으로 리플레이 해 주는 gor (https://goreplay.org/) 와 같은 툴을 사용할 수 있습니다. 프로덕션 환경의 실제 트래픽을 반복하여 활용할 수 있다는 이점 이외에도, 서비스 및 애플리케이션 업데이트 예정 버전에 실제 트래픽을 흘려 보내 사용성에 대한 테스트도 진행할 수 있는 장점도 있습니다.

추가로, 많은 경우 부하 테스트는 개발 주기 마지막에 진행되는 경우가 많습니다. 애자일 방법론과 지속적인 통합(CI/CD)을 활용하는 경우 조금 더 일찍, 자주 부하 테스트를 진행할 수 있으며, 이를 통해 추후 발생할 수 있는, 비용이 많이 드는 성능 문제를 미리 방지할 수 있습니다. 따라서, 가능한 개발 주기에 부하 테스트를 포함하여 자주 진행하는 것이 바람직하다고 볼 수 있습니다.

AWS 에서 제공하는 방대한 인프라와 이미 부하에 대해 고려되어 설계된 관리형 서비스, 그리고 다양한 규모 관련 기능들을 적극 활용하여 서비스를 구축한다면 가변적인 부하에도 유연한 서비스를 제공할 수 있을 것 입니다.

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

AWS Application Load Balancer 서비스 공개

지난 2009년 Elastic Load Balancing (ELB) 서비스를 시작하였습니다.(New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatch 참고). ELB는 AWS 기반 애플리케이션의 가장 중요한 아키텍처의 구성으로서 자동 스케일링과 함께 고가용성을 유지하면서 손쉽게 확장 및 감소를 할 수 있도록 도와 주고 있습니다.

상위 레이어 로드 밸런싱 기능 지원
잘 알려진 OSI 모델에 따르면, 로드밸런싱은 일반적으로 Layer 4 (네트워크) 또는 Layer 7 (애플리케이션)에서 처리합니다.

Layer 4 로드밸런싱은 네트워크 프로토콜 레벨에서 제공 되며, 실제 패킷을 살펴 보지는 못하기 때문에 HTTP나 HTTPS 같은 특정 프로토콜을 인지하지 않고 부하를 분산합니다.

대신 Layer 7 로드밸런싱은 좀 더 정교하고 강력한 기능을 제공합니다. 패킷을 조사하고, HTTP 및 HTTPS 헤더에 접근해서 좀 더 지능적인 부하 분산 작업이 가능합니다.

AWS Application Load Balancing 서비스 제공
오늘 ELB의 새로운 옵션인 애플리케이션 로드밸런서(Application Load Balancer)를 공개합니다. 이 서비스는 Layer 7 로드밸런싱을 통해 많은 고급 기능을 제공합니다. 기존의 로드 밸런싱 기능은 앞으로 Classic Load Balancer라고 부르게 되며, 여전히 Layer 4 및 Layer 7 기능을 제공합니다.

애플리케이션 로드밸런싱은 콘텐트 기반 라우팅 및 콘테이너 상 애플리케이션을 지원합니다. 표준 프로토콜인 WebSocket 및 HTTP/2를 지원하며, 인스턴스 및 콘테이너의 추가 가시성을 제공하게 됩니다. 콘테이너 및 EC2 인스턴스에서 실행하는 웹 사이트 및 모바일 앱에 대해 부하 분산에 대한 효과가 매우 높을 것입니다.

이제 좀 더 자세하게 애플리케이션 로드밸런싱 기능을 살펴 보겠습니다.

콘텐츠 기반 라우팅
애플리케이션 로드밸런서는 HTTP 헤더에 접근해서 다른 백엔드 서비스에 따라 다른 요청을 처리할 수 있습니다. 예를 들어, URL에 /api라는 경로를 포함하고 있는 경우, 다른 서버 그룹(일명 target group)으로 요청을 보낼 수 있으며 /mobile은 또 다른 서버 그룹으로 보낼 수 있습니다. 이를 통해 여러 개의 마이크로서비스를 독립적으로 실행하고 확장할 수 있도록 할 수 있습니다.

각 애플리케이션 로드밸린서는 10개의 URL 규칙을 만들 수 있으며, 앞으로 더 많은 라우팅 방법을 제공할 계획입니다.

콘테이너 기반 애플리케이션 지원
많은 AWS 고객들이 자사의 마이크로서비스를 콘테이너 형식으로 만들어서 Amazon EC2 Container Service를 통해 배포하고 있습니다. Amazon ECS는 하나의 EC2 인스턴스에 한 개 이상의 서비스를 배포 및 운영할 수 있습니다. 그러나, 포트 맵핑 및 헬스 체크 등에 대해 전통적인 로드밸린서로는 어려운 문제가 있습니다.

애플리케이션 로드밸린서를 통해 콘테이너 기반의 애플리케이션 역시 같은 타겟 그룹 내에 다수의 포트를 사용할 수 있으며, 세부적인 포트 수준의 헬스 체크를 지원할 수 있게 되었습니다.

더 자세한 통계 수치 제공
애플리케이션 로드밸린서는 포트 기반의 헬스 체크에 대한 리포트를 실행할 수 있어, HTTP 응답에 대한 범위를 정의할 수 있고 자세한 오류 코드에 대한 부분도 확인할 수 있습니다.

콘텐츠 기반의 라우팅을 제공함으로서 각 마이크로서비스의 다양한 통계 수치도 얻어낼 수 있습니다. 이는 마이크로서비스 기반에서 운영하는 타겟 그룹 또는 특정 EC2 인스턴스 그룹에 대한 유효한 부수 효과입니다. 개별 서비스에 대한 부하에 대해 좀 더 자세히 살펴 볼 수 있음으로서 확장성에 대한 도움을 얻을 수 있습니다.

애플리케이션 로드밸린서는 CloudWatch에서 전체 트래픽 (overall traffic in GB), 액티브 연결 갯수, 시간당 연결 비율 등의 새로운 통계 수치를 제공합니다.

추가 프로토콜 지원
애플리케이션 로드밸린서는 WebSocketHTTP/2를 지원합니다.

WebSocket은 클라이언트와 서버간 긴 TCP 연결을 제공하는 프로토콜로서, 긴 연결이 필요할 경우 기존의 HTTP 연결을 통해 하던 고전적인 풀링 방식을 개선할 수 있습니다. 모바일 앱의 경우, 주식 가격이나 스포츠 경기 점수 등 다양한 동적 데이터를 서로 주고 받을 때 유용하며 ALB는 ws://wss:// 프로토콜을 지원합니다.

HTTP/2 역시 기존 HTTP 1.1에 비해 중요한 기능 향상을 가진 프로토콜로서 단일 연결에 멀티플렉스 요청을 처리할 수 있고, 바이너리 속성을 통한 네트웍 트래픽을 줄여줍니다.

애플리케이션 로드밸린서는 실시간 스트리밍 뿐만 아니라 WebSocket 로드를 최적으로 처리 가능합니다. 요청 및 응답에 대한 버퍼링 대신 스트리밍 방식으로 처리함으로서 지연 속도를 줄이고 애플리케이션의 성능을 눈에 띄게 높일 수 있습니다.

ALB 생성하기
이제 애플리케이션 로드밸린서를 만들어서 트래픽을 처리해 보겠습니다.

The Elastic Load Balancing Console에 두 가지 중 하나의 로드밸린서를 선택할 수 있습니다.

Application load balancer을 선택하고 이름(MyALB)을 넣고 internet-facing를 선택 후, HTTPS listener를 추가합니다.

같은 화면에서 VPC를 선택하고 (VPC만 지원함), 원하는 가용 영역과 서브넷을 선택합니다. 애플리케이션 로드밸린서를 태그하고 Configure Security Settings 설정으로 갑니다.

HTTPS listener를 선택했기 때문에 ALB는 인증서가 필요합니다. IAM에 있는 기존 인증서를 선택하거나, AWS Certificate Manager (ACM)에서 발급 받거나 또는 로컬 인증서를 업로드할 수 있습니다.

오른쪽에서 보안 그룹을 설정합니다. 새로운 보안 그룹을 만들었으나 기존 VPC나 EC2 보안 그룹을 사용하실 수도 있습니다.

다음 단계로 타겟 그룹(main)을 만들고, 헬스 체크를 기본으로 체크합니다.

이제 타겟그룹의 EC2 인스턴스 세트를 선택하여 애플리케이션 로드밸린서를 통해 분산할 80포트를 선택합니다.

마지막 단계로 모든 설정을 확인 한후 Create를 누르면 됩니다.

Create 누르고 나면, 애플리케이션 로드밸린서가 수 분 안에 만들어집니다.

추가 타겟 그룹을 만들 수도 있습니다.

각 타겟 그룹에 원하는 경로, 즉 /api 호출을 보낼 수 있습니다.

애플리케이션 로드밸린서는 Auto Scaling, Amazon ECS, AWS CloudFormation, AWS CodeDeployAWS Certificate Manager (ACM) 서비스와 연동해서 사용할 수 있습니다.

신규 로드밸런서로 이전하기
현재 기존 로드밸런서를 사용하고 있으시고, 애플리케이션 로드밸린서로 옮기고 싶으시다면, Load Balancer Copy Utility를 활욜하시기 바랍니다. 기존 설정을 그대로 애플리케이션 로드밸린서에 맞게 옮겨주는 Python 기반의 도그로서 기존 EC2 인스턴스를 신규 로드밸런서로 등록하는 기능도 있습니다.

가용성 및 가격
애플리케이션 로드밸린서는 모든 AWS 리전에서 오늘 부터 사용가능합니다. ALB의 시간당 사용 비용은 기존 로드밸런서 보다 10% 낮습니다.

ALB를 사용하시면 로드밸런서 용량 단위(LCU)를 기반으로 시간당 과금하게 되며, LCU는 초당 연결 갯수, 활성 연결수, 및 데이터 전송량 등을 측정하게 됩니다. 이 세 가지 측면의 데이터를 기반으로 비용이 결정됩니다. 하나의 LCU는 다음 중 하나를 선택합니다.

  • 25 초당 연결 수 (2 KB 인증서, 3,000 활성 연결 수, 2.22 Mbps 데이터 전송량) 혹은
  • 5 초당 연결 수 (4 KB 인증서, 3,000 활성 연결 수, 2.22 Mbps 데이터 전송량

시간당 1 LCU에 대해 0.008 달러가 과금되며, 저희의 계산에 따르면 모든 고객들이 기존 로드밸런서에서 ALB로 이전할 경우 기본적으로 총 비용이 감소할 것으로 생각합니다. 지금 부터 한번 활용해 보시기 바랍니다.

Jeff;

본 글은 New – AWS Application Load Balancer의 한국어 번역본으로 AWS Summit 뉴욕 행사의 신규 발표 소식입니다.

AWS 서버리스 챗봇 경진대회에 참여하세요!


유명 인기 협업 메신저인 Slack과 함께 AWS Serverless Chatbot Competition 행사를 개최합니다.

여러분이 AWS LambdaAmazon API Gateway 서비스를 활용하여, Slack용  챗봇 개발에 관심이 있으시다면 많이 참여해 주시기 바랍니다.  Slack Events API  및 다른 AWS  서비스와 데이터 소스를 활용하여 슬랙 사용자에게 도움이 될만한 창의적이고 독특한 서비스를 제출 하시면 됩니다.

AWS 무료 티어를 활용하시면, AWS Lambda, API Gateway 및 다른 AWS 서비스를 무료로 개발 시 활용하실 수 있습니다. 신규 및 기존 사용자는 AWS Lambda에 대해 월 백만 회 및  400,000 GB-초당 컴퓨팅이 무료입니다. 신규 사용자에 대해서 월 1백만 API 호출이 12개월 동안 무료이기도 하구요.

챗봇 제작 및 알리기
여러분이 만든 챗봇을 다른 사람들이 이해하기 쉽게 좀 더 잘 설명하고, 알릴 수 있도록 아래와 같은 과정을 거치기를 권장 드립니다.

  • 챗봇이 동작하는 데모 동영상 만들기
  • 무엇이 독창적인지 간단한 설명 문서 만들기
  • 챗봇을 동작시키기 위한 코드와 설치 방법을 GitHub에 올리기
  • 챗봇을 테스트할 수 있는 간단한 웹 사이트와 방법 알리기

여러분이 만든 챗봇은 신규 혹은 기존 애플리케이션이라도 무방하나, AWS Lambda와 API Gateway  서비스를 활용해야 하며, 동영상 및 내용은 영문으로 만들어 주셔야 합니다.

수상작 선정 및 시상
개인별, 팀별, 그리고 50인 이하의 소규모 단체 참가자는 Serverless Chatbot Hero Award를 받으실 수 있습니다. 본 수상작에 선정되시면 AWS re:Invent 무료 등록 티켓 및 호텔 할인 비용을 제공 받을 수 있습니다. 또한, Serverless State of the Union에 선정되고, 다양한 선물 및 AWS $100 크레딧을 드립니다. 큰 규모 기업 참가자는 현물 지원 없는 혜택이 지원됩니다.

좀 더 자세한 부분은 FAQ 를 참고하시기 바랍니다.

진행 일정
아래는 주요 일정입니다.:

  • 8월 10일 – 9월 29일 – 제출 기간
  • 10월 3-7일 – AWS 심사 기간
  • 10월 15일 – 수상작 발표

시작 하기
여기에 시작하기 위한 가이드라인이 있습니다

  1. 행사 관련 규칙 및 가이드라인 읽어 보기
  2. AWS Serverless Chatbot Competition 등록하기
  3. AWSSlack 개발자 계정 만들기
  4. 각 API 및 서비스를 활용한 챗봇 개발 문서 살펴 보기
  5. 챗봇 샘플 코드 (aws-serverless-chatbot-sample) 활용하기
  6. 접수를 위한 데모 동영상 및 문서를 만들기
  7. 9월29일 오후 5시(태평양 시간)까지 접수하기

여러분의 독창적이고 재미있는 아이디어를 기다립니다!

관련 온라인 세미나 정보
아래에 여러분에게 도움이 될 만한 온라인 세미나 행사가 있습니다.:

기존의 녹화 영상도 참고하세요.