Amazon Web Services 한국 블로그

Category: AWS Elastic Beanstalk

AWS Application Load Balancer 서비스 공개

on 12 AUG 2016 | in Amazon EC2, AWS Elastic Beanstalk, EC2 Container Service, Elastic Load Balancing, 서울 리전 소식 | Permalink

지난 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), 액티브 연결 갯수, 시간당 연결 비율 등의 새로운 통계 수치를 제공합니다.

추가 프로토콜 지원
애플리케이션 로드밸린서는 WebSocket 및 HTTP/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 CodeDeploy 및 AWS 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 Elastic Beanstalk – 신규 관리형 플랫폼 업데이트 기능

on 20 APR 2016 | in AWS Elastic Beanstalk | Permalink

AWS Elastic Beanstalk은 웹 서비스 운영 및 웹 애플리케이션 배포를 간단하게 해주는 서비스입니다. 여러분이 개발한 코드를 업로드만 하면, Elastic Beanstalk에서 나머지 해야 할 일인 용량 미리 산정, 로드 밸런싱 설정, 오토 스케일링 및 헬스 체크 및 모니터링 등을 알아서 해 줍니다. 여러분은 Java, PHP, Ruby, Node.ps, Python, .NET, Go, Docker 등 다양한 개발 플랫폼을 사용할 수도 있습니다.

Elastic Beanstalk은 주기적으로 새로운 플랫폼과 운영체제, 웹 서버, 언어별 프레임워크 등을 업데이트합니다. 지금까지는 이것을 수동으로 콘솔, CLI 혹은 API로 직접 업데이트 해야 했습니다. 많은 기능을 관리형으로 제공했지만, 여전히 관리해야할 항목이 하나 남아 있었습니다.

자동 플랫폼 업데이트 기능
오늘 Elastic Beanstalk에 자동 플랫폼 업데이트 기능을 추가하여, 더욱 강력한 서비스로 거듭나게 되었습니다. 주간 유지 보수 방식을 선택하면 Elastic Beanstalk이 알아서 여러분의 최신 서비스 환경을 자동으로 업데이트 합니다.

업데이트는 변경이 불가능한(immutable) 배포 모델을 사용하여 설치됩니다. 즉, 업데이트된 인스턴스가 사용 가능하게 되어 헬스체크로도 애플리케이션을 확인할 수 있을 때 까지는 기존 환경에서 변화가 없다가, 완료되면 바뀌는 방식입니다. 만약 이슈가 업데이트 도중 발생되면, 사용자 트래픽은 기존의 인스턴스로 가게 됩니다. 따라서 이러한 배포 모델을 통해 업데이트 도중에서 여러분의 애플리케이션이 기존 사용자에게 별 문제 없이 제공된다는 것을 의미합니다.

마이너 업데이트 및 패치를 자동으로 업데이트 하도록 추가할 수 있을 뿐만 아니라 관리 화면 밖에서도 업데이트를 할 수 있습니다. 다만, 중요한 업데이트의 경우, 배포 전에 애플리케이션 테스트를 해 보아야 하기 때문에 이는 자동으로 되지 않고 수동으로 작업을 하게 됩니다.

Elastic Beanstalk 콘솔에서 Configuration 탭에서 선택할 수 있습니다:

Managed Updates 탭에서 설정을 할 수 있습니다.

정식 출시
본 기능은 오늘 부터 모든 리전에서 사용이 가능하며, 추가 비용은 없습니다. 다만, 배포 모델에 따라 업데이트 시 추가로 뜨는 EC2 인스턴스에 대한 비용을 청구될 수 있습니다.

— Jeff;

이 글은 New – Managed Platform Updates for AWS Elastic Beanstalk의 한국어 번역입니다.

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

on 27 JAN 2016 | in Amazon CloudWatch, AWS Elastic Beanstalk, AWS Lambda, 한국 기술 문서 | Permalink

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.thinkwithwp.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 을 사용하여 메시지를 전달할 수 있도록 정보를 확인합니다.

https://<your-team-domain>.slack.com/services/new로 이동합니다.
“Incoming WebHooks”을 검색하여 채팅 그룹와 채널을 선택하고, 추가합니다.
“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 활용 기술 팁을 보내드리는 코너로서, 이번 글은 김일호 솔루션즈 아키텍트께서 작성해주셨습니다.

Elastic Beanstalk – Java 및 Go 언어 지원

on 28 SEP 2015 | in AWS Elastic Beanstalk | Permalink

Abhishek Singh는 AWS Elastic Beanstalk의 신규 기능 업데이트 소식인 Java JAR 파일 및 Go 프로그래밍 언어 지원을 아래 글을 통해 알려드립니다.

— Jeff;

AWS Elastic Beanstalk을 통해 Java, .NET, PHP, Ruby, Node.js 및 Docker 등 웹 응용 프로그램 및 서비스를 손쉽게 확장성 높은 AWS 클라우드로 배포 및 서비스가 가능합니다. 프로그램 코드를 업로드만 하면 Elastic Beanstalk이 자동으로 용량 프로비저닝, 로드 밸런싱, 오토 스케일링, 응용 프로그램의 상태 모니터링을 포함하여 배포 작업을 수행합니다. 또한, 응용 프로그램을 계속 서비스하기 위한 AWS 리소스 제어 또한 가능합니다.

이번에 Java와 Go 응용 프로그램에 대한 지원을 추가함으로써 Elastic Beanstalk를 더욱 유용하게 활용할 수 있게 되었습니다. 또한, 새로운 플랫폼에서는 Nginx 리버스 프록시를 구성하는 프로세스를 쉽게 가능합니다. Nginx 구성을 제어하려면 .ebextensions/nginx 폴더에 nginx.conf를 추가 할 수 있습니다. 또한 플랫폼에서 제공하는 Nginx 구성을 포함하려면, .ebextensions/nginx/conf.d 폴더에 설정 파일을 추가 할 수 있습니다. 자세한 내용은 역방향 프록시 구성 방법을 참조하십시오.

.ebextensions/nginx/nginx.conf – Nginx 설정 재정의(Override)
.ebextensions/nginx/conf.d – Nginx 설정 파일

자바 신규 지원

Jetty 및 Play와 같은 개발 프레임웍을 사용하여 자바 앱을 배포하는 것이 가능합니다. Tomcat외에도 다양한 옵션이 제공됩니다.

Java 응용 프로그램을 Elastic Beanstalk에 배포하는 방법은 다음과 같습니다.

응용 프로그램 JAR 파일을 업로드
응용 프로그램 JAR 파일을 포함한 아카이브를 업로드합니다. 여기에 응용 프로그램을 동작 시키는 데 필요한 커맨드 모드 파리메터를 정의하는 Procfile도 포함되어 있습니다. 자세한 내용은 Application Process Configuration (Procfile)를 참조하십시오.
다수의 JAR 파일을 포함한 아카이브를 업로드합니다. 각각의 JAR 파일의 동작 설정인 Procfile도 포함되어 있습니다. 자세한 내용은 Application Process Configuration (Procfile)를 참조하십시오.
응용 프로그램 소스 Buildfile 및 Procfile를 포함 아카이브를 업로드합니다. 자세한 내용은 Building Applications On-Server (Buildfile)를 참조하십시오.

바로 시작해 보시려면, Elastic Beanstalk 시작 화면에서 샘플로 정의된 카테고리에 있는 Java 플랫폼을 선택하십시오. Java 7 및 Java 8 모두 지원됩니다.

Go 언어 신규 지원
AWS Elastic Beanstalk에서 Go language 응용 프로그램을 실행시킬 수 있습니다. 다음과 같은 방법으로 Elastic Beanstalk에 Go 응용 프로그램을 배포 할 수 있습니다.

응용 프로그램의 소스를 포함 아카이브를 업로드합니다. AWS Elastic Beanstalk은 자동으로 응용 프로그램을 빌드하고 실행시킵니다. (AWS Elastic Beanstalk은 application.go라는 파일에 main function이 있다고 가정합니다.)
응용 프로그램의 바이너리를 포함한 아카이브를 업로드합니다. 여기에 응용 프로그램을 동작 시키기 위해 필요한 추가 매개 변수를 정의하는 Procfile도 포함되어 있습니다. 자세한 내용은 Application Process Configuration (Procfile)를 참조하십시오.
응용 프로그램 소스 Buildfile 및 Procfile를 포함한 아카이브를 업로드합니다. 자세한 내용은 Building Applications On-Server (Buildfile)를 참조하십시오.Java 플랫폼처럼 Go 플랫폼은 Profile에 여러 프로세스를 정의하는 Procfile을 지원합니다.

새로운 플랫폼을 사용하려면, AWS Elastic Beanstalk Management Console 로그인 및 EB CLI를 이용하여 최적의 클라우드 서비스 플랫폼을 만들어 보시기 바랍니다.

— Abhishek Singh, Senior Product Manager, AWS Elastic Beanstalk

이 글은 Elastic Beanstalk Update – Support for Java and Go의 한국어 번역입니다.