Amazon Web Services 한국 블로그

Category: re:Invent

AWS OpsWorks for Chef Automate 신규 서비스 출시

AWS OpsWorks는 Chef를 사용하여 응용 프로그램 설정 및 실행을 돕는 서비스입니다. 도메인 특정 언어 (DSL)를 사용하여 응용 프로그램 아키텍처와 각 구성 요소 설정을 정의하는 cookbooks을 사용할 수 있습니다. 이는 Chef 서버 설정 과정에서 필수적인 요소입니다. Chef 서버는 모든 cookbook을 저장하고 각 인스턴스 (Chef 용어로 노드)의 상태 정보를 추적합니다.

Chef 서버는 새로 인스턴스가 설정 될 때 중요한 경로에 있기 때문에 안정성이 높아야 합니다. 대다수 AWS OpsWorks 및 Chef 사용자는 이러한 Chef 서버를 직접 설치하고 유지하고 있습니다. 정식 서비스 환경에서 이를 통해 운영 환경 백업, 복원, 버전 업그레이드 등을 사용자가 직접 처리해야 합니다.

신규 AWS OpsWorks for Chef Automate 서비스
지난 AWS re:Invent 2016에서 소개된 AWS OpsWorks for Chef Automate를 정식 출시합니다. Chef Automate 서버는 단 3 번의 클릭으로 시작하여, 몇 분 이내에 사용할 수 있습니다. Chef Supermarket을 비롯해 Test Kitchen 및 Knife 등 커뮤니티 도구에서 커뮤니티 사용법을 활용할 수 있습니다. Chef Automate을 사용하면 애플리케이션 인프라의 수명 주기에 맞추어 인프라를 관리 할 수 ​​있습니다. 예를 들어, 새로 시작된 EC2 인스턴스는 자동으로 Chef 서버에 연결하고 자동 연결 스크립트를 사용하여 지정된 레시피를 실행할 수 있습니다 (자세한 내용은  Adding Nodes Automatically in AWS OpsWorks for Chef Automate 참조). 등록 스크립트를 사용하여 Auto Scaling 그룹을 통해 동적으로 생성 된 EC2 인스턴스를 등록하고 온 – 프레미스 서버를 등록 할 수 있습니다.

서비스 살펴 보기
OpsWorks 콘솔에서 Chef Automate 서버를 시작해보겠습니다. 시작하려면 Go to OpsWorks for Chef Automate을 클릭합니다.

Create Chef Automate server를 클릭하고 서버 이름을 지정합니다. 사용할 리전을 선택하고 적절한 EC2 인스턴스 유형을 선택합니다.

SSH 키 쌍 중 하나를 선택하거나 SSH를 사용하지 않습니다.

마지막으로, 네트워크 (VPC), IAM, 유지 관리 및 백업 설정을 지정합니다.

Next를 클릭하여, 설정을 확인하고 Launch를 선택합니다. 부팅 과정에 걸리는 시간은 20분 미만입니다. 그 시간 동안 스타터 키트와 함께 Chef Automate 대시 보드의 로그인 인증 정보를 다운로드 할 수 있습니다.

이제 모든 Chef Automate 서버를 한눈에 볼 수 있습니다.

서버 이름(여기에서는 BorkBorkBork)을 클릭하고 Open Chef Automate dashboard를 클릭합니다. 다음 인증 정보를 입력하여 로그인합니다.

아래는 대시 보드를 보여줍니다.

노드를 표시하고 관리 할 수 ​​있습니다.

워크 플로우 관리도 가능합니다.

그 밖에도 다양한 기능이 있습니다. 백그라운드 실행 과정을 통해 AWS CloudFormation 템플릿을 호출합니다. 이 템플릿은 EC2 인스턴스, Elastic IP 주소 및 보안 그룹을 생성합니다.

정식 출시
AWS OpsWorks for Chef Automate는 US East (Northern Virginia), US West (Oregon) 및 Europe (Ireland) 지역에서 이용하실 수 있습니다. 가격은 서버에 연결된 노드의 수와 시간에 따라 다릅니다. 자세한 내용은 Chef Automate 요금 페이지를 참조하십시오. AWS Free Tier의 일환으로 12 개월 당 최대 10 노드까지 무료로 사용할 수 있습니다.

— Jeff;

이 글은 New – AWS OpsWorks for Chef Automate의 한국어 버전입니다.

EC2 Systems Manager – EC2 및 온-프레미스 서버 함께 관리하기

지난 해 EC2 Run Command 를 소개하고 EC2 인스턴스와 하이브리드 및 교차 클라우드 환경에서 원격 인스턴스 관리를 대규모로 수행하는 방법을 보여드렸습니다. 이 과정에서 리눅스 인스턴스에 대한 지원을 추가해 EC2 Run Command를 광범위하게 적용할 수 있고 매우 유용한 관리 도구로 만들었습니다.

가족이 되신 것을 환영합니다
Werner가 AWS re:Invent에서 EC2 System Manager를 발표했고 드디어 이것에 대해 말할 수 있게 되었습니다!

EC2 Run Command의 향상된 버전과, 여덟 개의 유용한 기능이 포함된 새로운 관리 서비스입니다. EC2 Run Command 처럼 윈도우, 리눅스를 실행하는 서비스와 인스턴스로 이루어진 교차 클라우드 환경 및 하이브리드 환경을 지원합니다. AWS Management Console을 열고 관리할 인스턴스를 선택한 다음 수행 하고싶은 작업을 정의하기만 하면 됩니다(API와 CLI에서도 접근할 수 있습니다).

다음은 개선된 기능과 새로운 기능에 대한 개요입니다:

  • Run Command – 이제 명령 실행 속도를 제어하고 에러 비율이 높아졌을 때 명령 실행을 중지할 수 있습니다.
  • State Manager – 규칙적인 간격으로 적용되는 정책을 통해 정의된 시스템 설정을 유지합니다.
  • Parameter Store – 라이센스 키, 비밀번호, 사용자 목록 및 다른 값들을 위한 (암호화 가능한)중앙 집중 저장소를 제공합니다.
  • Maintenance Window – 업데이트 설치와 기타 시스템 유지 관리를 위한 기간을 지정하세요.
  • Software Inventory – 각 인스턴스에서 자세한 소프트웨어 사항들과 사용자가 정의한 추가사항까지 포함한 설정 목록을 수집합니다.
  • AWS Config Integration – 새로운 Software Inventory 기능과 함께 AWS Config는 software inventory의 변화를 인스턴스에 기록할 수 있습니다.
  • Patch Management – 인스턴스의 패치 과정을 단순화하고 자동화합니다.
  • Automation – AMI 구축과 기타 반복적인 AMI 관련 작업을 단순화합니다.

각각을 살펴봅시다..

Run Command 개선 사항

이제 동시에 실행되는 명령의 숫자를 제어할 수 있습니다. 명령이 내부 업데이트나 서버 패치와 같이 제한적인 공유 리소스들을 참조하고, 너무 많은 리퀘스트로 인한 오버로딩을 피하고 싶은 상황에서 유용합니다.

이 기능은 현재 CLI와 API로 접근할 수 있습니다. 다음은 CLI에서 동시실행을 2로 제한하는 예제입니다:

Bash 
$ aws ssm send-command \
  --instance-ids "i-023c301591e6651ea" "i-03cf0fc05ec82a30b" "i-09e4ed09e540caca0" "i-0f6d1fe27dc064099" \
  --document-name "AWS-RunShellScript" \
  --comment "Run a shell script or specify the commands to run." \
  --parameters commands="date" \
  --timeout-seconds 600 --output-s3-bucket-name "jbarr-data" \
  --region us-east-1 --max-concurrency 2

다음은 –instance-ids 대신 –targets를 지정하여 태그와 태그 값에 의해 작동하는 흥미로운 변형 예제입니다.

Bash 
$ aws ssm send-command \
  --targets "Key=tag:Mode,Values=Production" ...

최대 에러 수 또는 에러 비율을 지정하는 옵션으로 에러를 반환하면 명령 실행을 멈출 수 있습니다:

Bash 
$ aws ssm send-command --max-errors 5 ... 
$ aws ssm send-command --max-errors 5% ...

State Manager

State Manager는 문서를 따라 인스턴스를 정의된 상태로 유지하도록 도와줍니다. 문서를 만들어 타겟 인스턴스 집합과 연결한 다음, 문서를 실행해야 하는 시간과 빈도를 지정하기 위한 연관성을 생성합니다. 다음은 요일 파일의 메세지를 업데이트하는 문서입니다.

그리고 연관성은 이와 같습니다(태그를 사용하기 때문에 현재 인스턴스 및 같은 방식으로 태그된 나중에 만들어질 다른 인스턴스에도 적용됩니다):

태그를 사용해서 타겟을 지정하면 미래에도 사용할 수 있으며 동적 오토 스케일 환경에서도 기대했던 대로 작동하게 합니다. 모든 연관성을 볼 수 있으며 새로운 연관성을 선택하고 Apply Association Now를 클릭해 실행할 수 있습니다.

Parameter Store

이 기능은 라이센스 키, 비밀번호 및 인스턴스에 배포하려는 기타 데이터의 저장 및 관리를 단순화합니다. 각 매개변수는 형(문자열, 문자열 리스트, 보안 문자열)이 지정되어 있고 암호화된 형태로 저장할 수 있습니다. 다음은 매개변수를 생성하는 방법입니다:

다음은 커맨드에서 매개변수를 참조하는 방법입니다:

Maintenance Window

이 기능은 업데이트 설치와 기타 시스템 유지관리를 위한 시간을 지정할 수 있게 합니다. 다음은 매 주 토요일에 4시간동안 열리는 유지 관리 기간을 생성하는 방법입니다:

창을 생성한 후에는 인스턴스 Id 또는 태그로 창에 인스턴스 집합을 할당해야 합니다:

그리고 나서 유지 관리 기간 동안 수행할 작업을 등록해야 합니다. 예를 들어 리눅스 쉘 스크립트를 실행할 수 있습니다:

Software Inventory

이 기능은 소프트웨어와 인스턴스 집합의 설정에 대한 정보를 수집합니다. 이 정보에 접근하기 위해 Managed Instance와 Setup Inventory를 클릭합니다:

인벤토리를 설정하면 AWS 소유 문서와 인스턴스 집합 간에 연관성이 생깁니다. 타겟을 선택하고 일정을 설정하고 목록화 할 항목의 유형을 확인한 다음 Setup Inventory를 클릭하기만 하세요:

인벤토리가 실행된 후에는 인스턴스를 선택하고 인벤토리를 클릭해서 결과를 관찰할 수 있습니다:

더 분석하기 위해서 결과를 필터링할 수 있습니다. 예를 들어 개발 도구와 라이브러리만 보기 위해 AWS 요소 목록을 필터링 할 수 있습니다:

모든 관리 인스턴스에서 인벤토리 기반 쿼리를 실행할 수 있습니다. 다음은 4.6 이전 버전의 .NET을 실행하고 있는 Windows Server 2012 R2 인스턴스를 찾는 방법입니다:

AWS Config Integration

인벤토리의 결과는 AWS Config까지 연결되어 어플리케이션, AWS 요소, 인스턴스 정보, 네트워크 설정, Windows 업데이트의 변화를 지속적으로 추적합니다. 인스턴스 Config 타임라인 위에 있는 Managed instance information을 클릭해 이 정보에 접근할 수 있습니다:

하단의 세줄은 인벤토리 정보로 이어집니다. 다음은 네트워크 설정입니다:

Patch Management

이 기능은 Windows 인스턴스에 있는 운영체제를 최신으로 유지하게 도와줍니다. 지정한 유지관리 기간 동안 패치를 적용하고 기준을 준수하여 수행됩니다. 기준은 분류와 심각도에 따라 패치를 자동으로 승인하는 규칙과 승인 또는 거부할 명시적인 패치 목록을 지정합니다.

다음은 저의 기준입니다:

각 기준은 하나 또는 다수의 패치 그룹에 적용될 수 있습니다. 패치그룹에 들어있는 인스턴스는 Patch Group 태그가 있습니다. 저는 그룹에 Win2016라는 이름을 붙였습니다:

그리고 값을 기준과 연결했습니다:

다음 단계에서는 AWS-ApplyPatchBaseline 문서를 사용해 유지 관리 기간동안 패치의 적용을 조정합니다:

Managed Instances 목록으로 돌아가서 한 쌍의 필터를 사용해 패치가 필요한 인스턴스를 찾을 수 있습니다:

Automation

마지막이지만 앞의 기능 못지않게 중요한 Automation 기능은 일반적인 AMI 구축과 업데이트 작업을 간소화합니다. 예를 들어 AWS-UpdateLinuxAmi 문서를 사용해 매 달마다 새 Amazon Linux AMI를 만들 수 있습니다:

다음은 이 자동화가 실행되었을 때 일어나는 일을 보여줍니다:

정식 출시
위에서 설명한 EC2 Systems Manager의 모든 기능을 지금 무료로 사용할 수 있습니다. 당신이 관리하는 리소스에 대해서만 비용을 지불합니다.

– Jeff;

이 글은 EC2 Systems Manager – Configure & Manage EC2 and On-Premises Systems의 한국어 번역으로 AWSKRUG 블로그 번역모임의 이상록님께서 작성해 주셨습니다. 만약 AWS 영문 공식 블로그를 한국어로 소개하시고 싶으신 분은 언제든지 번역 공헌을 해 주실 수 있습니다.

AWS re:Invent 2016 총정리

안녕하세요. 이제 AWS re:Invent 2016 행사가 거의 막바지에 다다르고 있습니다.

3만 여명의 참가자들과 함께 정보를 나누고 배우며 즐기는 콘퍼런스로서 무엇 보다 “클라우드에 대한 교육과 학습“에 집중하고 있습니다. 아울러 클라우드의 미래를 보여 줄 수 있는 다양한 신규 서비스 발표와 공유도 이루어졌습니다.

혹시 많은 것을 놓치셨다고 생각되시나요? 걱정 하지 마세요. 여기에 있는 총정리 편만 확인 하셔도 거의 다 따라잡으신 것입니다. IT 서비스에 종사하면서 흥미로운 점은 늘 공부할 것이 끊임없이 나온다는 것인데요. 함께 공부해서 여러분의 비지니스가 성공하시고, 이를 또 AWS와 다른 분에게 공유해 주세요.

bW_iLGsP

1. AWS re:Invent 동영상 및 발표 자료

기조 연설 동영상

강의 세션 동영상 및 발표 자료

  • 전체 강의 세션 동영상 (분야별 목록 제공)
  • 전체 강의 세션 발표 자료
  • 검색 활용 팁
    • 발표 자료 및 영상은 최소 1주일 이내로 유튜브와 슬라이드쉐어에 공유됩니다.
    • 구글에서 “re:Invent 2016 ARC201 slideshare” 형식으로 검색어를 넣으시면 빠르게 찾을 수 있습니다.

행사 현장 이모저모 살펴 보기

2. AWS re:Invent 신규 서비스 출시 정보

컴퓨팅

데이터베이스 및 분석

인공 지능

개발자 도구 및 지원 서비스

하이브리드, 마이그레이션, 관리 및 보안 등

보도 자료 및 뉴스 기사

3. AWS re:Invent 후속 행사

행사 전 AWS re:Invnet 2016 시즌이 돌아왔습니다!라는 글을 통해 re:Invent를 준비했다면, 이 글로 마무리를 지어야 할 것 같습니다. 리인벤트 기간 중에 함께 참여 해 주신 고객사와 파트너사 그리고 한국에서 생중계 및 각종 소식을 공유해 주신 많은 분들께 감사드립니다.

12월과 내년 1월에 이어지는 후속 행사에도 꼭 관심을 가져 주시고, AWS는 고객 여러분의 성공을 위해 내일도 최선을 다하겠습니다. 여러분의 지속적인 피드백과 연락 부탁드립니다.

– AWS 코리아 마케팅팀;

 

Amazon EC2 인스턴스 및 VPC IPv6 지원 시작

모바일 앱, 커넥티드 디바이스 및 IoT 분야에서 인터넷의 지속적인 성장으로 업계 전반에 IPv6 전환이 촉발되었습니다. 2010 년에서 부터 미국 정부 기관은 공개 서버 및 서비스를 가능한 빨리 IPv6로 옮기고 있습니다. 128 비트의 주소 공간을 갖춘 IPv6는 성장 여지가 충분하며 새로운 애플리케이션 및 연결 확장성에 큰 도움이 됩니다.

Amazon EC2 및 VPC IPv6 지원
올해 초 Amazon S3, IPv6 주소 지원 시작을 시작으로 Amazon CloudFront, Route53, WAF 및 S3 Transfer Acceleration의 IPv6 지원을 진행하였습니다. 오늘 그 다음 단계로 Virtual Private Cloud (VPC)와 VPC내 EC2 인스턴스에 대한 IPv6 지원을 시자하며, 우선 US East (Ohio) 리전부터 시작합니다.

IPv6 지원은 신규 혹은 기존 VPC에서도 가능하며 VPC-VPC간에도 콘솔 (혹은 API 및 CLI)를 통해 선택할 수 있습니다.

각 VPC은 개별적 /56 주소 영역을 Amazon GUA (Global Unicast Address)에서 얻으며, 각 VPC내 서브넷에는 /64를 할당할 수 있습니다.

Amazon S3에서 처럼 각 인스턴스에 해당 DNS 항목과 함께 IPv4 주소와 IPv6 주소를 할당하는 이중 스택 모델을 사용합니다. 두 버전의 프로토콜을 모두 지원하므로 리소스 및 응용 프로그램에 접근에 대한 호환성과 유연성이 보장됩니다.

VPC 내의 보안 그룹, 라우팅 테이블, 네트워크 ACL, VPC 피어링, 인터넷 게이트웨이, Direct Connect, VPC 흐름 로그(Flow Logs) 및 DNS 질의 등은 모두 현재와 같은 방식으로 작동합니다. 애플리케이션 로드밸런서(ALB)의 이중 스택 모델에 은 예정되어 있으며, 장기적인 로드맵을 가능한 한 빨리 알려 드리겠습니다.

AWS Direct Connect IPv6 지원
AWS Direct Connect Console내 가상 인터페이스(VIFs)에서 IPv4 및 IPv6 주소를 선택할 수 있습니다.

각 VIF는 BGP 피어링 세션을 각각 IPv4와 IPv6을 지원 합니다.

신규 Egress-Only 인터넷 게이트웨이 IPv6 지원

IPv6에 주요 특징 중 하나는 모든 주소가 인터넷 라우팅이 가능하여, 인터넷에 연결할 수 있다는 것입니다. IPv4 전용 VPC에서 공용 IP 주소를 EC2 인스턴스에 할당하면 1:1 NAT(Network Address Translation)가 인스턴스와 사설 주소로 설정됩니다. IPv6을 사용하는 VPC에서 각 인스턴스의 주소는 공개되어 있습니다. 직접 연결을 통해 많은 네트워킹 문제를 해결하지만, 사설 서브넷을 만드는 또 다른 메커니즘이 필요합니다.

오늘 IPv6 지원을 통해 VPC용 비공개 서브넷을 구현하는 데 사용할 수 있는 새로운 Egress-Only Internet Gateway (EGW)를 소개합니다. EGW는 NAT 인스턴스의 집합보다 설치 및 사용하기가 쉽고 무료로 사용할 수 있습니다. 수신 트래픽을 차단하면서 아웃 바운드 트래픽을 허용 할 수 있습니다 (인터넷 게이트웨이가 보안 그룹과 연결). 일반적인 방식으로 EGW를 생성하고, 이를 사용하여 인바운드 IPv6 트래픽을 제한할 수 있습니다. IPv4 트래픽에 NAT 인스턴스 또는 NAT 게이트웨이를 계속 사용할 수 있습니다.

정식 출시
EC2 IPv6 지원은 US East (Ohio) 리전에서 오늘 부터 추가 비용 없이 사용 가능합니다. M3, G2를 제외한 모든 현 세대 EC2 인스턴스 타입에서 사용 가능합니다.

다른 리전의 IPv6 지원 확대는 계획 중에 있으며, 준비되는 대로 계속 알려드리겠습니다.

— Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 New – IPv6 Support for EC2 Instances in Virtual Private Clouds의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

AWS Step Functions– 시각적 워크플로 기반 분산 애플리케이션 개발용 신규 서비스

오늘 날 다양한 웹 기반 마이크로 서비스를 연결하여 복잡한 분산 응용 프로그램을 보다 쉽게 만들 수 있어야 합니다. 대부분 개발자는 복잡한 비즈니스 프로세스를 구현하든 간단한 사진 업로드를 위한 처리를 하던지 가급적 관리 작업 보다는 코드 개발에 집중하고, 익숙한 개발 도구와 라이브러리를 사용하면서 견고하고 확장성 높은 비용 효율적인 안정적 응용 프로그램을 구축하기를 바라고 있습니다.

AWS Step Functions 소개
위의 요구 사항에 부합하는 AWS Step Functions을 오늘 출시합니다. 여러분이 만든 애플리케이션의 구성을 시각적 워크플로를 통해 설정하고, Step Functions 콘솔에서 각 머신(machine)에서 높은 확장성으로 진행하는 과정을 정의해 줄 수 있습니다.

각 머신은 상태 세트를 정의하고 이들 사이의 그 상태 값을 이전합니다. 각 단계별 상태는 병렬 혹은 순서대로 활성화 될 수 있습니다. Step Functions에서는 다음 단계로 가기 전에 모든 병렬적인 상태가 완료되도록 합니다. 이들 상태를 기반으로 작업 및 의사 결정 및 컴퓨터를 통한 과정 제어 등을 수행합니다.

아래에는 상태 머신(state machine)에 대한 일부분을 표시한 것입니다.

각 상태 머신의 여러 복제본은 동시에 독립적으로 실행할 수 있습니다. 각 복제본은 실행물(execution)이라고 부릅니다. Step Functions는 수 천개의 실행물을 동시에 실행할 수 있도록 하여 원하는 수준의 확장성을 제공합니다.

어떤 상태가 실행될 때 수행할 작업을 지정하는 데는 두 가지 다른 방법이 있습니다. 먼저, 상태가 실행될 때 동기적으로 호출 될 Lambda 함수를 제공 할 수 있습니다. 둘째, 액티비티(Activity) 이름을 제공할 수 있습니다. 이것은 수행할 작업에 대해(API를 통해) 가져올 장기적인 실행 작업 함수에 대한 참조값입니다. 어느 쪽이든, 코드는 JSON 입력을 통해 JSON 출력을 반환 받습니다.

상태 시스템의 일부로서 오류 처리 동작을 지정하고 로직를 다시 시도 할 수 있습니다. 따라서, 코드 한 부분에서 일시적인 문제로 인해 일시적인 오류가 발생하더라도 원활하게 실행되는 강력한 다중 단계 앱을 만들 수 있습니다.

Step Function 살펴 보기
AWS 관리 콘솔에 들어가 상태 시스템을 설정해 보겠습니다. 정식 애플리케이션은 AWS 단계 함수 API (아래에서 설명)를 사용하여 상태 시스템을 생성하고 실행합니다.

우선 간단한 AWS Lambda 함수를 작성해 보겠습니다.

함수의 ARN 값을 복사합니다.

이제 AWS Step Functions 콘솔로 가서  Create a State Machine을 누르고,  이름(MyStateMachine)과 함께 실행할 기본 샘플 워크 플로를 선택합니다.

Hello World를 클릭하고, 상태 머신에 대한 JSON 모델을 만들기 위해 Parallel 요소를 선택합니다.

{
  "Comment": "A simple example of the Steps language using an AWS Lambda Function",
  "StartAt": "Hello",

  "States": {
    "Hello": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:eu-west-1:99999999999:function:HelloWord_Step",
      "Next": "Parallel"
    },

    "Parallel": {
      "Type": "Parallel",
      "Next": "Goodbye",
      "Branches": [
        {
          "StartAt": "p1",
          "States": {
            "p1": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:eu-west-1:9999999999:function:HelloWord_Step",
              "End": true
            }
          }
        },

        {
          "StartAt": "p2",
          "States": {
            "p2": {
                  "Type": "Task",
                  "Resource": "arn:aws:lambda:eu-west-1:99999999999:function:HelloWord_Step",
              "End": true
            }
          }
        }
      ]
    },

    "Goodbye": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:eu-west-1:99999999999:function:HelloWord_Step",
      "End": true
    }
  }
}

Preview 를 누르면 아래와 같이 시각적으로 보입니다.

Step Functions을 실행할 IAM 역할을 지정합니다.

이제 모든 설정을 마치고, 상태 머신을 실행할 수 있습니다. 첫번째 함수를 통과하는 JSON 블럭을 가지고 시작해 볼 수 있습니다.

Start Execution을 누르자 마자 상태 머신이 실행되고, 실행 순서에 따라 아래와 같이 상태와 상태 사이의 전이가 일어납니다.

Lambda 콘솔에 가면, 아래와 같이 4번의 함수 실행을 볼 수 있습니다. (시간이 촉박하면, 네 개의 기능을 따로 만들지 않아도 됩니다.)

Step Functions는 각 단계별로 정보를 모두 기록하고 이를 콘솔에서 볼 수 있습니다.

AWS Step Functions API
앞에서 말씀 드린 대로, AWS Step Funcitons는 API로 실행 가능하며, 아래에 주요 기능에 대한 API 함수 입니다.

  • CreateStateMachine –  JSON을 통해 신규 상태 머신 생성
  • ListStateMachines – 상태 머신 목록 가져오기
  • StartExecution – 상태 머신 (비동기적으로) 실행하기
  • DescribeExecution – 실행물 정보 가져오기
  • GetActivityTask – 실행할 신규 작업 가져오기

새 객체가 S3 버킷에 업로드 될 때마다 Lambda 함수를 실행할 수 있습니다. 이 함수는 StartExecution을 호출하여 상태 머신 실행을 시작할 수 있습니다. 상태 머신은 (예를 들어) 이미지 유효성 검사, 다양한 크기 및 형식 병렬 생성, 특정 유형의 콘텐트 확인 및 데이터베이스 항목 업데이트를 수행 할 수 있습니다.

동일한 기능을 AWS CLI에서도 사용할 수 있습니다.

개발 도구
신규 statelint gem 파일을 사용하여 연결할 수 없는 상태, 터미널 상태 누락과 같은 일반적인 오류에 대해 수기 혹은 컴퓨터에서 생성된 JSON 로그를 확인할 수 있습니다.

AWS GitHub 레포지터리에서 다운로드하십시오 (RubyGems) 다음과 같이 설치하십시오.

$ sudo gem install j2119-0.1.0.gem statelint-0.1.0.gem

Here’s what happens if you have a problem:

$ statelint my_state.json
2 errors:
 State Machine.States.Goodbye does not have required field "Next"
 No terminal state found in machine at State Machine.States

잘 진행이 된다면,

$ statelint my_state.json

정식 출시
AWS Step Functions는 오늘 부터 US East (Northern Virginia), US East (Ohio), US West (Oregon), EU (Ireland), Asia Pacific (Tokyo) 리전에서 사용 가능합니다.

AWS 프리티어를 통해  매월 4,000 번의 상태 전이를 수행할 수 있습니다. 그 이후로는 1,000회당  $0.025의 요금을 부가합니다.

— Jeff;

AWS Lambda@Edge – 미리 보기 출시

지난 주에 한 AWS 고객으로 부터 Hacker News에 올린 댓글을 통해 한 통의 메일을 받았습니다.

그는 싱글 페이지 애플리케이션(SPA)을 빠른 속도의 웹 페이지 배포가 가능한 Amazon CloudFront를 통해 Amazon S3에 정적 웹 호스팅으로 서비스를 하고 있는데, 그 페이지에서 AWS Elastic Beanstalk에서 운용중인 자체 API를 통해 개별 사용자를 위한 동적인 작업을 진행하고 있다고 합니다. 그 분이 설명한 문제는 다음과 같습니다.

최근의 웹 환경에서는 검색 엔진을 위해 별도 색인을 생성하고 Facebook 및 Twitter 내에서 콘텐츠 미리보기가 올바르게 표시 되려면 각 페이지의 미리 렌더링 된 버전을 제공해야 합니다. 이를 위해서는 사용자가 Google 사이트를 방문 할 때마다 Cloudfront의 프론트엔드에 서비스를 제공해야 합니다. 그러나 사용자 에이전트가 Google/Facebook/Twitter 인 경우 미리 렌더링된 사이트 버전으로 리디렉션을 해야합니다.

한 명의 고객이 보내준 사용 사례를 넘기지 않고, 우리가 앞으로 이러한 문제를 개선하겠다는 사실을 알려주었습니다. 여러 고객들이 이미 엣지에서 신속하게 의사 결정을 내림으로써 맞춤형 최종 사용자 경험을 제공하고자 하는 의견을 주었습니다.

(레이턴시 기준) 고객에게 가까이 있는 위치에서 HTTP 요청을 “지능적으로” 처리하는 데는 많은 주목할만한 사용 사례가 있습니다. 예를 들어, HTTP 헤더 검사, 접근 제어 (특정 쿠키가 필요함), 모바일 디바이스 탐지, A/B 테스트, 크롤러 또는 봇에 대한 신속한 처리 또는 특수한 별도 처리, 레거시 시스템을 수용 할 수 있는 사용자 친화적인 URL 리다이렉트 등입니다. 이런 요구 사항 대부분은 단순한 패턴 일치 및 규칙으로 표현할 수 있는 것보다 좀 더 복잡한 처리 및 의사 결정을 필요로합니다.

AWS Lambda@Edge 서비스 소개
이러한 요구 사항을 지원하기 위해 AWS Lambda@Edge 미리 보기를 시작합니다. 이 새로운 람다 기반 처리 모델을 사용하면, 전 세계에 산재하는 AWS 엣지 로케이션에서 JavaScript 코드를 작성하여 실행할 수 있습니다.

이제는 가벼운 요청 처리 로직을 작성하고 CloudFront 배포판을 통과하는 요청(request) 및 응답(response)을 처리 할 수 있습니다. 아래와 같이 네 가지 별개의 이벤트에 대한 응답으로 코드를 실행할 수 있습니다.

Viewer Request – 콘텐츠 캐시 여부에 관계없이 모든 요청에 대해 코드가 실행됩니다. 다음은 간단한 헤더 처리 코드입니다.

JavaScript 
exports.viewer_request_handler = function(event, context) {
  var headers = event.Records[0].cf.request.headers;
  for (var header in headers) {
    headers["X-".concat(header)] = headers[header];
  }
  context.succeed(event.Records[0].cf.request);
}

Origin Request – Your code will run when the requested content is not cached at the edge, before the request is passed along to the origin. You can add more headers, modify existing ones, or modify the URL.

Viewer Response – 캐시 여부와 관계없이 모든 응답에서 실행됩니다. 이것을 사용하여 브라우저로 다시 전달할 필요가 없는 일부 헤더를 정리할 수 있습니다.

Origin Response – 캐시 실패로 인해 원본(Origin)에서 다시 가져와서 엣지(Edge)에 반응한 후 코드를 실행합니다.

개별 코드는 URL, 메소드, HTTP 버전, 클라이언트 IP 주소 및 헤더 등 HTTP 요청 및 응답에서 나오는 여러 데이터를 접근할 수 있습니다. 간단하게 헤더를 추가, 수정 및 삭제할 수도 있고, HTTP 바디(Body)를 포함한 모든 값을 변경할 수 있습니다. 처음에는 헤더를 추가, 삭제 및 수정할 수 있습니다. 곧 바디를 포함한 모든 값에 대한 읽기 / 쓰기 접근 권한을 갖게됩니다.

자바 스크립트 코드는 HTTP 호출/응답의 한 부분이 되기 때문에 재빠르고 의미 있는 스스로 완결적인 코드여야 합니다. 다른 웹 서비스를 호출 할 수 없으며, 다른 AWS 리소스에 접근할 수 없습니다. 128MB의 메모리 내에서 실행되어야 하며 50ms 이내에 실행이 끝나야 합니다.

처음 시작을 해보려면, 새로운 람다 함수를 생성하고, CloudFront 배포를 트리거로 설정한 후 새 Edge 런타임을 선택하면됩니다.

CynNG_pVQAADVbR

그런 다음, 코드를 만들면 됩니다. Lambda 함수는 엣지 로케이션의 여러 가지 측면을 개선하는데 도움을 줄 것입니다.

미리 보기 신청하기
이 기능이 새로운 애플리케이션 및 개발 도구로서 창의적인 적용을 해 볼 수 있을 것으로 생각하고, 여러분이 직접 해 보시기를 권해 드립니다.

오늘 AWS Lambda@Edge 미리 보기를 시작하였고, 직접 해보시려면 미리 보기 신청 페이지에서 등록해 주시기 바랍니다.

— Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 AWS Lambda@Edge – Preview의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

Blox – Amazon EC2 Container Service를 위한 오픈 소스 스케줄러

2014년에 처음 출시한 Amazon ECS은 Docker 기반 애플리케이션 빌드와 실행 및 확장을 하는데 도움을 주는 서비스로서, 당시 세 가지 콘테이너 스케줄링 선택 사항 (자동, 수동, 사용자 정의) 방식을 소개하고, 어떻게 스케줄러가 각 태스크를 인스턴스에 처리하는지 설명하였습니다

사용자 정의 스케줄링은 클러스터의 현재 상태를 확인하기 위해서 ListContainerInstances 및 DescribeContainerInstances 함수를 계속 호출해야 합니다. 올해 초에 이러한 과정을 좀 더 간단하게 만들고, 각 클러스터의 상태를 추적하기 위해 Amazon CloudWatch Events를 추가 하였습니다. (자세한 사항은 Monitor Cluster State with Amazon ECS Event Stream 문서를 참고하세요.)

신규 이벤트 스트림 방식으로 맞춤형 스케줄러를 직접 만들 수 있습니다.

오늘 BloxOSS라는 신규 오픈 소스 소프트웨어를 공개합니다. 이 프로그램은 이벤트 스트림을 가져와서 클러스터의 상태를 추적하고, REST API로 상태를 확인할 수 있도록 해줍니다. 본 패키지에는 클러스터 내 각 콘테이너 인스턴스의 태스크를 실행할 수 있는 스케줄러 데몬을 포함하고 있습니다. 콘테이너 당 하나의 모델을 통해 로그를 처리하고 통계치를 수집하는 작업을 지원합니다.

여기에 간단한 모식도를 공유해 드립니다.

이는 오픈 소스로 제공이 되며, 외부에 계신 분들의 많은 피드백 및 코드 공헌을 기대합니다. 더 자세한 사항은 Introducing Blox From Amazon EC2 Container Service 글을 참고하시기 바랍니다.

— Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 Blox OSS – New Open Source Scheduler for Amazon EC2 Container Service의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

AWS 개인 상태 대시 보드 – 신규 기능 제공

2008년 AWS는 서비스 상태 대시 보드를 시작했습니다. 그 당시에는 AWS 클라우드는 비교적 새로운 서비스였기 때문에 이 서비스는 고객이 각 서비스의 상태를 확인할 수있는 제일 좋은 방법이었습니다 (해당 블로그 게시물의 간단한 스크린 샷을 현재 대시 보드와 비교해서 보시면, 8년 만에 얼마나 기능이 개선되었는지 모실 수 있습니다.)

사실 현재 대시 보드는 각 AWS 서비스의 전체 상태를 표시하는 데는 적합하지만, 개인화된 정보를 제공하지는 않습니다. AWS 서비스의 전반적인 상태보다 내가 사용중인 AWS 서비스 및 리소스의 상태가 더 중요 할 수 있습니다.

개인 상태 대시 보드 출시
여러분에게 가장 중요한 정보를 제공하기 위해 오늘 부터 AWS 개인 상태 대시 보드를 제공합니다.

이름에서 알 수 있듯, 본 대시 보드는 여러분이 사용중인 AWS 서비스의 성능 및 가용성에 대한 개인화 보기와 함께 서비스 상태 변화에 의해 자동으로 알림을 제공합니다. 여러분의 클라우드 자원와 관련한 정보를 한곳에 모아 두도록 만들어졌으며, 영향을 줄 수있는 모든 문제를 보다 잘 파악할 수 있습니다.

대시 보드에 관심있는 항목이 포함되어 있으면, 콘솔 메뉴에 알림 아이콘이 표시됩니다. 요약 내용을 보려면 클릭하십시오.

미해결 문제를 클릭하면, AWS 인프라에 영향을 줄 수있는 문제가 표시됩니다. (테스트 데이터입니다.)

항목을 클릭하면 문제를 해결하는 방법에 대한 지침을 비롯하여 자세한 정보가 제공됩니다.

본 대시 보드는 예정된 활동에 앞서 미리 알려줍니다.

관심 있게 봐야 할 모든 정보를 제공하고 있습니다.

고급 사용자를 위한 추가 API 기능
CloudWatch 이벤트를 사용하여, 알림에 대한 응답 및 예약 활동에 대한 알림을 자동화 할 수도 있습니다. 예를 들어, 여러분의 EC2 인스턴스가 임박한 유지 관리 알림을 받았을 때, 신규 인스턴스로 적극적으로 이동하는 응답을 할 수 있습니다.

여러분의 회사가 AWS Business Support 또는 AWS Enterprise Support에 가입하면 새로운 AWS Health API에 접근할 수 있습니다. 본 API를 사용하여 기존 사내 혹는 서드파티 IT 관리 도구를 개별 대시 보드 정보와 통합 할 수 있습니다.

— Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 New – AWS Personal Health Dashboard – Status You Can Relate To의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

AWS Batch – 배치(Batch) 컴퓨팅 관리 서비스 출시

제가 대학에 들어갔던 1978년에 Montgomery College 전산학과에는 IBM 370/168라는 메임 프레임이 있었고, 저는 카드 천공기를 통해 Job Control Language (JCL) 문법을 작성하는 것을 배웠습니다. (그 뒤로 FORTRAN, COBOL, PL/I 컴파일러가 나왔죠.) 작업한 카드 덱을 제출하기 위해 각 작업 식별자와 교환하여, IT 부서 운영자에게 건네 주면 인쇄된 결과와 카드 덱을 받으러 몇 시간 후에 다시 와야 했습니다. 결과물을 공부하고, 앞의 작업을 다시 하고 몇 시간 후에 오던 것을 반복하곤 했는데, 나중에 우리 작업의 실행 시간은 불과 몇 초 밖에 걸리지 않았다는 것을 알고 충격을 받았습니다. 학교 IT 부서에서 수행할 작업이 네 번째 우선 순위에 배정되었다면, 학생들이 준 것은 여덟번째로 매우 낮은 것이었습니다. 과거 우선 순위 선정 매커니즘의 목표는 중요한 업무에 우선해서 값비싼 하드웨어를 전부 사용하는 것이었습니다. 학교에서 학생들의 생산성은 자원을 효율적으로 사용하는 데 있어 후순위였던 것이죠.

현대적인 배치(Batch) 컴퓨팅
오늘날 배치(Batch) 컴퓨팅은 매우 중요합니다! 영화 스튜디오, 과학자, 연구원, 수치 분석가 및 기타 사람들이 쉽게 대용량 ​​컴퓨팅 성능에 접근할 수 있게 되어, 컴퓨팅 사이클에 대해 활용하고자 하는 열의를 갖게 되었습니다. 많은 기업 조직에서는 오픈 소스 또는 상용 작업 스케줄러로 사내 컴퓨팅 클러스터를 직접 구축하여, 이러한 요구 사항을 충족시키기 위해 노력해 왔습니다. 그런데, 여전히 과거와 같이 우선 순위를 적용할 수 밖에 없는 충분한 양의 컴퓨팅 용량은 아닌 것 같습니다. 이들 기존 사내 클러스터는 구축 및 유지 보수에 비용이 많이 들고, 동일한 서버에 동일한 사양의 대형 프로세서로 구성되는 경우가 많습니다.

우리는 클라우드 컴퓨팅을 통해 다양한 타입의 EC2 인스턴스를 신속히 제공할 수 있고, 변화하는 요구 사항에 따라 확장 및 축소 할 수 있는 확장성과 사용한 만큼 지불하거나 경매를 통한 가격 책정 모델을 통해 배치 컴퓨팅 모델을 보다 효과적으로 변경할 수 있다고 생각했습니다. 과거에는 AWS 고객 역시 EC2 인스턴스, 콘테이너, 알림, CloudWatch 모니터링 등을 사용하여 자체 배치 처리 시스템을 구축했습니다. 이런 것들이 매우 일반적인 AWS 사용 사례 였기 때문에 이를 위한 관리형 서비스가 필요하다는 결론을 얻었습니다.

AWS Batch 서비스 출시
배치 컴퓨팅에 대한 전체 관리형 서비스인 AWS Batch를 오늘 출시합니다. 이를 통해 배치 관리자, 개발자 및 사용자들은 배치용 클러스터를 따로 구축, 관리 및 모니터링 할 필요 없이 대용량 클라우드 컴퓨팅 자원을 활용할 수 있게 되었습니다. 소프트웨어 구매나 설치도 필요도 업습니다.

AWS Batch에서는 관리 상 불필요한 부담을 덜면서 동적으로 확장되는 EC2 인스턴스 세트에 여러분의 콘테이너 이미지와 애플리케이션을 통해 배치 작업을 할 수 있습니다. 클라우드를 통한 효율적이고 사용하기 쉬운 서비스로서 Amazon EC2 및 EC2 스팟 인스턴스가 제공하는 탄력성을 통한 대용량 병렬 작업을 할 수 있게 되었고, Amazon S3, DynamoDB 및 SNS 같은 기존 서비스와도 안전하고 쉽게 연동할 수 있습니다.

우선 AWS Batch에서 사용되는 몇 가지 중요한 용어와 개념을 살펴 보겠습니다. (배치 작업을 많이 하시는 경우 이미 익숙하실 수 있습니다.)

  • 작업(Job) – AWS Batch에 제공되는 하나의 작업 단위 (쉘 스크립트, 리눅스 실행 파일 또는 콘테이너 이미지)입니다. 작업 정의(Job Definition)에 의해 정의한 파라미터 값을 통해 EC2에서 콘테이너화 되어 실행 합니다. Job에서 다른 작업을 ID로 참조할 수 있습니다. AWS Batch에서는 각 작업을 독립적으로 실행하고, (파라메트릭 스윕 및 몬테카를로 시뮬레이션에 적합한) 어레이 작업(Array Jobs) 역시 지원합니다. 어레이 작업은 병렬적으로 작업이 되고, 동시에 가용 컴퓨팅 자원을 관리하면서 실행합니다.
  • 작업 정의(Job Definition) – 작업을 어떻게 실행할지 정합니다. AWS Identity and Access Management (IAM) 역할을 포함한 AWS 자원 접근 제어, CPU와 메모리와 요구 사항 등의 값을 설정합니다. 이러한 정보를 통해 개별 콘테이너 설정 값, 환경 변수, 마운트 지점 등을 정하게 됩니다. 개별 작업을 시작 될 때, 이들 값들이 재정의 됩니다.
  • 작업 큐(Job Queue) – 컴퓨팅 환경이 예약 될 때까지 작업이 있는 곳으로, 우선 순위 값은 각 대기열와 연결됩니다.
  • 스케줄러(Scheduler) –작업 큐와 함께 작업을 언제 어디서 어떻게 실행할지 결정합니다. AWS Batch 스케줄러는 FIFO(First-in, first-out) 기반이며 작업 사이의 의존성을 인지합니다. 우선 순위를 지정하고, 같은 컴퓨팅 환경 내에서 높은 우선 순위의 큐에 있는 작업부터 낮은 순서로 실행하게 됩니다. 스케줄러는 작업을 위한 적정한 크기의 컴퓨팅 환경을 설정하기도 합니다.
  • 컴퓨팅 환경(Compute Environment) – 작업을 실행하기 위한 관리 혹은 비관리 컴퓨팅 자원으로서, 관리 환경에서는 세부적인 수준에서 인스턴스 타입을 정의할 수 있습니다. c4.2xlarge나m4.10xlarge 같은 특정한 인스턴스 타입을 지정하거나, 여러분이 원하는 신규 인스턴스 타입을 간단히 지정해도 됩니다. 또한, Spot Market의 경매에 따른 백분율 값에 따라 최소, 희망 혹은 최대 vCPU 숫자를 지정하거나, VPC 서브넷을 지정할 수 있습니다. 이러한 지정 파라미터와 제약 사항을 기반으로 AWS Batch가 원하는 EC2 인스턴스를 효과적으로 켜고 관리하고 종료하게 됩니다. 또한, 직접 컴퓨팅 환경을 구성할 수도 있는데, 이 때 AWS Batch가 사용할 Amazon ECS 클러스터를 직접 설정하고 확장성을 관리하셔야 합니다.

AWS Batch 살펴 보기
AWS 관리 콘솔에서 AWS Batch를 사용할 수 있으며, , AWS Command Line Interface (CLI)나 AWS Batch API를 사용할 수 있습니다.

잠깐 살펴보면 상태 대시보드에 작업, 작업 큐 및 컴퓨팅 환경을 보실 수 있습니다.

Compute environments을 선택하고 Create environment를 통해 작업을 시작할 수 있습니다. 우선 관리형 환경(Managed environment)으로 작업 이름과 IAM 역할(자동으로 생성)을 선택합니다.

그리고 프로비저닝 모델(온디멘드 혹은 스팟)을 설정하고, 원하는 인스턴스 타입(또는 특정 타입) 및 컴퓨팅 환경(vCPU로 측정되는) 크기를 설정합니다.

컴퓨팅 자원과 보안 그룹 등에 필요한 VPC 서브넷를 선택함으로서 설정을 완료합니다.

이제 Create를 누르면, 배치 작업을 위한 컴퓨팅 환경이 (MainCompute) 몇 초내에 생성됩니다.

다음으로, 컴퓨팅 환경에 보낼 작업 큐가 필요합니다. Queues를 선택한 후 Create Queue를 클릭해서 설정을 진행합니다. 모든 값을 기본값으로 선택 한 뒤, 작업 큐를 내 컴퓨팅 환경에 연결하고 Create queue를 누릅니다.

이 역시 몇 초안에 진행 됩니다.

이제 작업 정의를 할 차례입니다. Job definitions를 선택하고, Create를 눌러 작업에 대해 정의합니다. (아래는 아주 간단한 작업으로 아마 여러분은 더 잘하실 수 있을 겁니다.) 제가 만든 작업은 sleep 명령어로 128MB 메모리와 1 vCPU에서 진행됩니다.

환경 변수를 전달하고 접근 권한을 비활성화한 뒤, 프로세스 사용자 이름을 지정하고 콘테이너 내에서 파일 시스템을 사용할 수 있도록 할 수 있습니다.

Save를 눌러 작업 정의를 완료합니다.

이제 작업을 돌려볼 차례입니다. Jobs을 선택한 후 Submit job를 누릅니다.

다양한 측면의 작업의 재정의, 부가적인 태그 추가 등의 기능을 활용할 수 있으며, 이제 Submit을 누릅니다.

그 뒤에 결과가 나옵니다.

Ruby, Python, Node, 또는 Bash 스크립트를 통해서도 작업을 정의할 수 있습니다. 예를 들어, 아래는 루비 코드로 만든 작업입니다.

콘솔에서 작업한 것과 같이 커맨드 라인에서도 create-compute-environment, describe-compute-environments, create-job-queue, describe-job-queues, register-job-definition, submit-job, list-jobs, describe-jobs 명령어로 같은 작업을 수행할 수 있습니다.

AWS Batch API를 사용하여 좀 더 흥미로운 방식으로 배치 작업을 할 수 있습니다. 예를 들어, 새로운 개체(예를 들어, 엑스레이 사진, 지진파 데이터 영상, 3D 이미지 정보)가 Amazon S3 버킷에 업로드 되었을 때 AWS Lambda 함수를 통해 개체를 조사하고, 이를 분석하여 메타 데이터를 뽑아 내거나 하는 작업을 수행할 수 있을 것입니다. SubmitJob 함수는 그렇게 얻어진 데이터를 Amazon DynamoDB에 저장하고 Amazon Simple Notification Service (SNS)로 알림을 보낼 수도 있을 것입니다.

정식 출시 및 가격
AWS Batch는 오늘 부터 US East (Northern Virginia) 리전에서 사용 가능하며, 곧 지원 리전을 계속 확대할 예정입니다. 추가적인 리전 확대와 아울러 AWS Lambda 함수 기반 작업 등 다양한 추가 기능도 선보일 예정입니다.

AWS Batch에는 추가 비용은 없으며, 여러분이 사용하는 AWS 컴퓨팅 리소스 비용만 지불하시면 됩니다.

— Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 AWS Batch – Run Batch Computing Jobs on AWS의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.

AWS Shield – DDoS 공격 대비 애플리케이션 보안 서비스

온라인 세계는 우호적인 장소는 아닐 수 있습니다. 웹 사이트를 온라인으로 올리자마자 다운되거나 침입 당할 수 있는 여러 가지 유형의 공격 대상이 될 수 있습니다. DDoS (Distributed Denial of Service) 공격은 흔히 발생하는 문제 중 하나입니다. 인터넷 전체에서 취약한 자원을 모아서 특정 대상을 공격할 수 있게 됩니다.

아래에 세 가지 일반적인 유형의 DDoS 공격 타입이 있습니다.

응용 프로그램 계층 공격: 응용 프로그램 리소스를 사용하도록 설계되어 있지만, 실제로는 악의적인 요청 (HTTP GET 및 DNS 쿼리가 많이 사용됨)으로 구성됩니다. 예를 들어, 여러 개의 HTTP 연결을 열어 몇 초 또는 몇 분 동안 요청을 해서 과도한 메모리가 소모되도록 합니다.

고갈 상태 공격: 상태 별 프로토콜을 어뷰징하고, 각 통신 연결 당 많은 리소스를 소비함으로써 방화벽 및 로드 밸런서에 강한 스트레스를 유발합니다.

볼륨 공격: 실제 처리 할 수 있는 것보다 많은 트래픽을 네트워크에 보내거나, 가짜 쿼리를 발행하여 네트워크를 혼란시킵니다.

AWS Shield 신규 서비스
AWS Shield는 DDoS (Distributed Denial of Service) 공격으로부터 웹 애플리케이션을 보호하는 새로운 관리 서비스입니다. Elastic Load Balancing, Amazon CloudFront, Amazon Route 53와 함께 작동하며 다양한 유형, 모양 및 크기의 DDoS 공격으로부터 사용자를 보호합니다. 두 가지 계층의 서비스가 있습니다. 여기에 두 가지 계층의 서비스가 있습니다.

AWS Shield Standard: 비용 없이 모든 AWS 고객이 사용할 수 있습니다. SYN/ACK Floods, 반사 공격 및 HTTP 저속 읽기와 같은 가장 일반적인 공격의 96 %를 방지합니다. 이 보호 방식은 Elastic Load Balancer, CloudFront 배포 및 Route 53 리소스에 자동으로 적용됩니다.

AWS Shield Advanced: 볼륨 공격, 지능형 공격 탐지 및 애플리케이션 및 네트워크 계층에서의 공격 완화를 위한 DDoS 완화 기능을 제공합니다. DDoS 공격의 여파로 인한 비용 청가 증가를 방지하기 위해 고급 실시간 통계  보고서 및 DDoS 비용 보호와 사용자 지정 완화를 위해 DDoS 대응 팀 (DRT)에 24 시간 연중 항상 지원 받을 수 있습니다.

더 자세한 사항은 AWS Shield 나 Get Started with AWS Shield Advanced를 참고하시기 바랍니다.

— Jeff;

이 글은 AWS re:Invent 2016 신규 출시 소식으로 AWS Shield – Protect your Applications from DDoS Attacks의 한국어 번역입니다. re:Invent 출시 소식에 대한 자세한 정보는 12월 온라인 세미나를 참고하시기 바랍니다.