Amazon Web Services 한국 블로그

Category: re:Invent

AWS Mobile Hub – 모바일 앱 빌드, 테스트 및 모니터링

AWS Mobile Hub(베타) 신규 서비스는 AWS 서비스를 사용하여 모바일 앱을 빌드, 테스트 및 모니터링을 단순화한 새로운 서비스입니다. 여러분 앱에 간단한 설정을 추가함으로서 기존의 AWS 서비스 설정 및 통합 작업의 부담을 덜어드림과 동시에 인증, 데이터 저장소, 백엔드 로직, 푸시, 콘텐츠 배포 및 분석 등 모든 것을 통합된 하나의 콘솔에서 운영할 수 있습니다.

관리 콘솔에서는 설정, 빌드, 테스트 및 사용량 모니터링 등 개발 및 서비스 단계 별로 기능 위주로 서비스를 선택할 수 있으며 이들 기능을 하나 통합 및 조합해서 사용할 수 있습니다. 일단 10분 정도만 사용해 보시면 어떻게 동작하는지 바로 확인이 가능합니다.

모바일 허브 콘솔 자세히 보기
이제 콘솔 기능을 한번 살펴 보도록 하겠습니다.

모바일허브는 모바일 앱 개발 단계별로 필요한 업무를 대략적으로 알 수 있게 되어 있습니다.

샘플 프로젝트 명은 SuperMegaMobileApp으로 하겠습니다.

각 기능은 하나 이상의 AWS 서비스를 활용할 수 있는데, 예를 들어 로그인의 경우 Amazon Cognito 및 Amazon SNS를 통한 푸시를 조합할 수 있습니다. 클릭해서 선택 후 설정만 하면 됩니다.

Push Notification을 선택 후, Enable push를 누르고 원하는 플랫폼을 선택합니다.

안드로이드 기기에 푸시를 보내고 싶다면 API Key와 Sender ID를 넣으면 됩니다.

백엔드 로직을 위해 AWS Lambda 함수를 연결할 수도 있습니다.

기능 설정을 마쳤다면, Build를 누르면 다음으로 넘어갑니다.

모바일 허브는 바로 시작할 수 있는 소스 패키지를 제공합니다. 다운로드하여 사용하기 전에 여기에 대한 자세한 설명 및 가이드는 보실 수 있습니다.

전체 패키지를 다운로드 한 후, 여러분이 선호하는 개발 환경(IDE)에 통합할 수 있습니다.

이 코드를 기반으로 샘플 앱을 시작하거나 편집할 수 있으며, 코드 일부를 기존 앱에 붙여넣기 할 수도 있습니다.

여러분이 앱 테스트를 원한다면 AWS Device Farm을 그리고 분석 데이터 수집을 원한다면 Amazon Mobile Analytics를 선택하시면 됩니다.

모바일 허브 사용하기
새로운 앱을 만들거나 기존 앱에 기능 추가를 위해, 모바일 허브는 아주 적은 비용과 시간을 들여 확장성 및 신뢰성을 높일 수 있습니다. 여러분이 보셨듯이 AWS Mobile Hub를 통해 기능 선택 및 설정을 바로 할 수 있으며 자동으로 AWS 서비스를 동작할 수 있도록 하여 더 빠르게 iOS 및 안드로이드 앱에 기능을 더할 수 있습니다.

이제 모바일 앱 개발에만 더욱 시간을 쏟아서 여러분의 중요한 서비스에만 집중하십시오. 더 자세한 사항은 AWS Mobile Hub 페이지에서 확인하시기 바랍니다.

— Jeff;

이 글은 AWS Mobile Hub – Build, Test, and Monitor Mobile Applications의 한국어 번역이며, re:Invent 2015의 신규 서비스 소식입니다.

AWS IoT – 사물 인터넷을 위한 클라우드 서비스

최근 사물인터넷(Internet of Things)이 많이 회자되고 있습니다. 때로 비판이 있지만, 장기적 관점의 기술 경향이면서 매우 흥미로운 변화를 주도하는 가치있는 기술입니다.

가장 큰 변화는 대량 생산을 통한 컴퓨팅 파워의 비용의 감소와 인터넷에 연결할 수 있는 디바이스가 폭넓게 이용된다는 점, 이를 통해 생산되는 정보의 양과 지능에 대한 빅데이터 분석 도구와 기법의 필요성입니다.

  • 대량 생산 컴퓨팅 파워: 매우 작은 크기의 저비용의 컴퓨팅 프로세서가 등장하여 어떤 크기와 형태의 디바이스라도 자연스럽게 탑재됨을 의미합니다.
  • 광범위한 인터넷 (유무선) 연결 기기: 이러한 프로세서들이 서로 클라우드를 통해 연결하여 통신할 수 있게 됨을 의미합니다.
  • 빅 데이터: 이들 기기에서 실행 되는 프로세서에서 수집 및 측정되는 정보를 모아 분석하는 것을 의미합니다.

또한, 최신 배터리 및 센서 기술을 통해 IoT 기술을 실현할 수 있습니다. 금방 공장, 자동차, 헬스 케어 시스템 및 주택 보안 기기 등에서 많은 인터넷 연결 “기기(Things)”들이 활성화 될 것입니다. 이러한 변화를 설명하는 두 개의 기사를 소개해 드립니다. 20 Real World Problems Solved by IoT 및 Smart IoT: IoT as a Human Agent, Human Extension and Human Complement. 최근에 Sudha Jamthe는 IoT Distruptions에서 IoT 세상이 도래할 경우, 향후 새로운 직업 및 업무에 대해 자세히 다루었습니다.

이러한 트렌드가 말해주듯이 AWS도 여러 형태의 IoT 기기 및 애플리케이션을 지원할 준비를 하고 있으며 이를 위해 많은 노력을 기울여 왔습니다. 여기서는 인터넷 연결 디바이스로서의 사물(things)를 다루었지만, 많은 모바일 기기 위의 앱도 마찬가지입니다.

AWS IoT 신규 서비스 발표

오늘 AWS IoT 베타 서비스를 발표합니다.

IoT를 위한 새로운 매니지드 클라우드 서비스는 자동차, 공장, 비행기 엔진 등 다양한 센서가 들어가는 기기(AWS IoT에서는 Things) 사이에 더 쉽고 안전하게 상호 작용하고 글로벌 클라우드 서비스를 연결할 수 있습니다. 클라우드로 연결은 고속의 경량 프로토콜(MQTT 또는 REST)를 활용할 수 있고 제한된 메모리 및 프로세스 파워와 배터리 성능의 기기에도 최적화되어 있습니다.

AWS IoT 서비스의 몇 가지 주요 구성 서비스를 살펴 보겠습니다.

  • Things 물리적은 개체, 인터넷 기기, 애플리케이션 등을 포함한 어떤 형태의 디바이스로서 로컬 환경에서 우리가 관심 있는 것을 측정 및 제어합니다. AWS IoT 모델은 상태와 상태 변화를 확인하고, 연결이 일시적으로 멈추더라도 애플리케이션이 클라우드 기반의 Thing Shadows 기능을 활용하여 상호 작용할 수 있습니다. 각 Things는 이름(names), 속성(attributes) 및 섀도(shadows)를 가지게 됩니다.
  • Thing Shadows Things에 대한 가상 클라우드 기반 표현(represenation)입니다. 각 연결 기기의 상태를 추적하며, 일정 기간 연결이 끊기더라도 가능하도록 되어 있습니다.
  • Rule Engine 실시간으로 여러분이 정의한 표현으로 메시지를 변환해서 다양한 AWS 엔드포인트(Amazon DynamoDB, Amazon Simple Storage Service (S3),  AWS Lambda, Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS), Amazon Kinesis 및 Amazon Kinesis Firehose) 등으로 SQL 문법 표현으로 전송하게 됩니다. 예를 들어, 온도 센서로 부터 기온 변화 정보를 받아 DynamoDB에 업데이트하거나 thing shadow에 저장된 값을 넘어서는 이상치를 얻을 때 AWS Lambda 함수를 실행(triggering)할 수 있습니다.
  • Message Broker MQTT (및 HTTP 1.1)를 통해 클라우드 백엔드가 응답을 하지 않더라도 대체 프로토콜을 사용할 수 있습니다. Message Broker는 각 사물 및 클라우드 애플리케이션 사이의 수십 억 건의 긴 연결(long-lived connection)을 처리할 수 있도록 확장이 가능합니다. 각 사물은 토픽 기반의 pub/sub 모델로 브로커와 통신할 수 있고 이는 HTTP 요청/응답 방식으로도 가능합니다. 상태를 표시할 수도 수신 메시지를 받을 수도 있습니다. Pub/sub 모델을 통하면 각 하나의 기기의 메시지를 다양한 (수천 혹은 수백 만 개의) 기기와도 쉽고 효율적으로 상태를 공유할 수 있습니다.
  • Device SDK 개별 기기의 형태에 따라 다양한 클라이언트 라이브러리가 제공됩니다. SDK 기기를 통해 AWS IoT Message Broker와 암호화된 연결 방식으로 통신할 수 있습니다. 각 기기들은 Amazon Cognito의 인증 방식이나 X.509 인증서를 통해 서로 인증이 가능합니다.
  • Thing Registry 개별 기기의 고유 식별을 부여하고, 기기의 속성 및 기능에 대한 메타 데이터를 관리합니다.

위의 구성 요소들은 AWS 관리 콘솔, AWS 커맨드라인 인터페이스 및 IoT API를 통해 생성, 설정 변경 및 확인이 가능합니다.

AWS IoT 서비스를 통해 수 십억 개의 사물이 클라우드와 반응성 높은 연결을 만들고 클라우드 애플리케이션이 사물들과 (device shadows, rule engine 및 실시간 기능 등의) 상호 작용을 할 수 있게 됩니다. 사물로부터 메시지를 받아 필터링 및 기록 및 변환하고 이를 다른 AWS 서비스로 연결하거나 직접 코드로 제어할 수 있습니다.

AWS IoT 시작하기

아래 목록과 같이 AWS-powered 스타터킷을 만들기 위해 그동안 많은 IoT 파트너와 협력해왔으며, 향후에 계속해서 추가될 예정입니다.

일단 여러분의 위의 스타터킷 중에 하나를 받아 관심 있는 것을 만드신다면, AWS IoT를 이용한 첫 번째 IoT 앱을 만드실 수 있습니다. 이를 위해 몇 가지 SDK를 활용하실 수 있습니다.

AWS IoT 애플리케이션은 AWS 서비스 뿐만 아니라 Alexs Skills Kit을 통해 Amazon Echo와도 통신이 가능합니다. AWS IoT는 Lambda 함수를 통해 Alexa Skill의 기능을 수행할 수 있고, Alexa Skill은 Shadow와 상호 작용이 가능합니다. 따라서, Alaex Skill을 통해 AWS IoT와 양방향 메시지 처리를 할 수 있는 이점을 얻음으로서, 클라우드를 통해 (NAT 및 홈네트워크 내 방화벽을 넘어) 기기를 깨우거나 명령어를 전달할 수 있게 됩니다. 제조사 역시 특정 음성에 반응할 수 있는데 thing shadows를 활용할 수 있게 됩니다.

AWS IoT 콘솔 활용법

콘솔에는 다양한 AWS IoT 사용 설명서 및 샘플 코드도 포함하고 있습니다.

API엔드 포인트, MQTT 토픽, shadow의 콘텐츠 등 각 기기에 대한 상세한 정보도 확인해 볼 수 있습니다.

AWS IoT 토픽, 메시지 및 규칙

지금까지 설명한 모든 인프라는 AWS IoT의 핵심이 되는 메시지 및 규칙에 대한 지원 시스템입니다. 각 기기는 토픽 이름으로 메시지를 게시(publish)함으로서, 상태를 공개합니다. 토픽으로 메시지를 게시할 때 토픽이 만들어지며, 미리 만들 필요는 없습니다. 토픽 네임스페이스는 계층적 구조(myfactories/seattle/sensors/door)로 되어 있습니다.

규칙(Rules)은 SQL 기반의 SELECT 구문을 활용하여 메시지를 필터링합니다. IoT Rule Engine에서는 FROM절을 통해 MQTT 토픽을 참조하며, WHERE절을 통해 메시지에서 JSON 속성을 참조할 수 있습니다. 규칙에 맞는 메시지가 있으면, 하나 이상의 다른 동작을 수행할 수 있습니다. 예를 들면…

  • DynamoDB 테이블에 조회, 추가 및 변경
  • Lambda 함수 실행
  • S3 버킷에 쓰기
  • SNS 토픽 및 엔드포인트에 게시
  • SQS 큐에 게시
  • Amazon Kinesis Stream에 게시
  • Amazon Kinesis Firehose에 게시
  • 다른 토픽에 재게시

SELECT 구문에서 전체(*)를 선택하거나 특정 메시지 필드를 선택할 수 있습니다.

위에 언급한 엔드포인트를 통해 다른 AWS 서비스로 연결할 수 있는데, 예를 들면 Kinesis를 통해 Amazon Redshift로 DW용 데이터로 저장할 수도 있습니다. 뿐만 아니라 Lambda, SNS 또는 Kinesis 를 통해 외부 서버 엔드포인트로 전송도 가능합니다.

Thing Shadows 역시 메시징 시스템에 참여할 수 있고, JSON 형식의 HTTP GET 요청에 응답합니다(HTTP를 쓸 수 없는 환경에서는 MQTT 활용 가능). 각 JSON 문서에는 사물의 상태, 메타데이터 및 상태 버전 등이 담겨 있습니다. 각 상태 정보는 (기기의 최종 상태) “reported” 및 (애플리케이션이 원하는) “desired” 사항이 저장되어 있습니다. 각 Shadow가 원하는 상태(HTTP) POST에 대한 변화를 받아 “delta”와 “accepted” 메시지를 thing shadows와 연결된 토픽으로 게시합니다. 기기가 이들 토픽을 수신 대기하다가 상태 변경을 진행합니다.

IoT re:Invent 세션 소개
만약 여러분이 re:Invent에 계시다면 아래의 모바일 개발 및 IoT 트랙의 강연을 참고하시고 참여하시기 바랍니다.

  • MBL203 – From Drones to Cars: Connecting the Devices in Motion to the Cloud.
  • MBL204 -Connecting the Unconnected – State of the Union – Internet of Things Powered by AWS.
  • MBL303 -Build Mobile Apps for IoT Devices and IoT Apps for Mobile Devices.
  • MBL305 – You Have Date from the Devices, Now What? Getting Value of the IoT.
  • WRK202 – Build a Scalable Mobile App on Serverless, Event-Triggered, Back-End Logic.

향후 계획
이 소개 글에서 언급하지 못한 많은 내용들이 있습니다. AWS re:Invent가 끝나면, 여러분이 집에서 직접 하실 수 있도록 제가 코드를 직접 만들어서 여러분에게 공유해 드리겠습니다.

– Jeff;

AWS IoT Mega Contest에도 꼭 참여하세요!

이 글은 AWS IoT – Cloud Services for Connected Devices에 대한 한국어 번역이며, re:Invent 2015의 신규 서비스 소식입니다.

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

AWS Lambda 신규 기능 – Python 지원, VPC 지원, 함수 실행 시간 연장 및 스케줄링

작년 re:Invent 2014에서 AWS Lambda를 공개한 이후, 놀라운 변화가 있었습니다. 먼저 많은 개발자 및 시스템 아키텍트들이 서버 없는(Serverless) 시스템에 대한 신 개념을 빠르게 파악하는 것을 보았습니다. 이를 통해 대용량 요청을 처리하기 위한 확장 및 관리가 전혀 없는 형태의 놀라울 만한 방법으로 이를 클라우드 아키텍쳐에 도입하였습니다.

이제 그동안 추가되어 온 Lambda 함수가 처리할 수 있는 각종 이벤트를 한번 다시 한번 살펴보겠습니다.

지난 1년간 Lambda에 많은 기능을 추가해 왔는데, 우선 세 개의 AWS 리전(US West, US East, Europe)에 더하여 올해 초 동경 리전을 추가하였습니다. 시작할 때 Node.js에 더불어 자바 함수 지원도 시작했습니다. 위의 목록에서 보듯이 많은 AWS 자원의 이벤트를 지원하고 있고, AWS Compute Blog에서 이를 사용하는 다양한 예제를 보실 수 있으며 그 중에서도 가장 멋진 글은 바로 (개인적인 취향이지만) Microservices Without the Servers입니다.

AWS Lambda 신규 기능
오늘 re:Invent 2015에서는 AWS Lambda의 새로운 추가 기능들을 발표하게 되었습니다.

  • VPC 지원
  • Python 함수 지원
  • 함수 실행 시간 증가
  • 함수 버전 지원
  • 함수 스케쥴링 지원

보시면 아시겠지만, 모두 함수에 대한 새로운 기능들로 좀 더 자세히 하나씩 살펴보도록 하겠습니다.

1. 람다 함수에서 VPC내 자원 접근
많은 고객들이 Amazon VPC내에서 마이크로서비스를 운영하고 있고, 람다 함수에서 이를 접근할 수 있기를 바라고 있습니다. 만약 MongoDB 클러스터를 운영하면서, 데이터를 조회하거나 Amazon ElastiCache를 상태 저장소로 사용하거나 할때 람다 함수가 필요할 수 있는데, 이들은 인터넷 상에 노출되는 자원이 아닙니다.

이제 여러분이 정한 VPC 안의 보안 그룹을 설정함으로서 이러한 리소스를 접근할 수 있게 됩니다. 람다를 통한 인바인드 트래픽 접근을 허용하고 타겟 VPC 서브넷에 첨부 하면 됩니다. 여러분이 람다 함수를 만들거나 기존 함수를 사용할 때, 특정 VPC, 서브넷 그리고 보안 그룹을 지정해야 합니다. 또한, IAM 역할을 통해 함수 권한을 실행해서, 유연한 네트워킹 설정을 위한 몇가지 EC2 함수 접근을 주면 됩니다.

본 기능은 올해 말 지원을 할 예정이고, 더 자세한 것은 본 블로그를 통해 계속 알려드리겠습니다.

2. Python 기반 람다 함수 지원
여러분은 Node.js 및 Java로 람다 함수 작성이 가능하며, 이에 추가적으로 오늘부터 Python 2.7 프로그래밍 지원을 시작합니다. AWS SDK for Python에도 함께 포함되었습니다. Python 언어는 쉽게 배우고 사용할 수 있는 인기 있는 언어로서 이에 대한 많은 지원 요청을 받았습니다. 그래서 오늘 여러분께 선보이기 되어서 매우 기쁩니다.

아래는 Python을 통한 함수 지원 스크린샷입니다.

3. 람다 함수 실행 시간 증가
람다는 추출-변환-읽기(Extract-Transform-Load, ETL)과 같은 작업에 딱 맞습니다. 영구적인 인프라가 필요 없이 쉽게 대용량 데이터를 수집 및 처리하는데 쉽게 확장이 가능합니다. 이를 지원하기 위해 람다 함수는 5분까지 실행할 수 있게 되었습니다. 이러한 경우에 대해 함수를 만들 때 타임아웃을 지정하기만 하면 됩니다. 여러분의 함수가 얼마나 오래 실행되는지 확인을 하셔도 됩니다.

아래는 Python을 활용하여 잔여 시간을 확인할 수 있는 로그를 남기는 방법입니다.

print(" Remaining time (ms): " + str(context.get_remaining_time_in_millis()) + "\n")

대부분 경우처럼, 정해진 함수 실행 시간을 모도 소모하면 종료됩니다.

4. 람다 함수 버전 및 별칭 지원
람다 함수를 통해 복잡한 시스템을 만들 때, 함수 기능을 계속 추가하면서 이를 제어할 필요가 있습니다. 개발 및 테스트 측면에서도 중요한 이런 부분을 단순화 하기 위해 신규 버전 기능을 공개합니다.

특정 함수의 새로운 코드를 매번 올릴 때 마다 람다가 새로운 버전 숫자를 지정하게 됩니다.(예, 1,2,3 등) 함수에 대한 ARN(Amazon Resource Name)에 옵션으로 버전 지시자가 추가 됩니다. (즉, “:”뒤에 버전 번호) ARN에 지시자가 없으면 최신 버전임을 의미하며 하위 호환성을 쉽게 활용할 수 있습니다. 버전 2의 ARN 지시자는 “arn:aws:lambda:us-west-2:123456789012:function:PyFunc1:2” 형식입니다.

버전 기능에 대해 알아 두셔야 할 몇 가지 점을 함께 알려드립니다.

  • 각 함수 버전은 자체 설정 정보를 포함합니다. (언어, 런타임, 메모리 크기 및 타임아웃, IAM 역할 등)
  • 각 버전은 자체적인 CloudWatch 측정값를 생성합니다.
  • CloudWatch 로그는 스트림 이름에 함수 버전을 포함합니다.
  • Lambda에서는 각 함수마다 다중 버전을 저장하고, 각 람다 계정은 1.5기가바이트까지 코드를 저장한 뒤, 이전 버전은 삭제합니다.

또한, 각 함수 및 버전 이름에 대한 별칭(aliasing)을 지정할 수도 있습니다. (예를 들어, version 3에 “prod”, version 5에 “test” 그리고 version 7에 “dev”같은 방식) 또한 ARN에서 별칭을 확인 할 수도 있습니다.

  • Production – “arn:aws:lambda:us-west-2:123456789012:function:PyFunc1:prod”
  • Testing – “arn:aws:lambda:us-west-2:123456789012:function:PyFunc1:test”
  • Development – “arn:aws:lambda:us-west-2:123456789012:function:PyFunc1:dev”

ARN에 있는 버전 및 별칭을 이용하여 어디서나 기존 ARN에 사용할 수 있으며, 모범 활용 방법으로 추천드립니다.

이 기능을 통해 문제 발생 시 쉽게 코드를 개발 단계에서 이전 버전으로 롤백을 할 수 있습니다. 예를 들어, 클라이언트 애플리케이션의 변경이나 이벤트 소스에 대한 함수 재실행 없이도 서비스 환경에서 버전 3을 변경해서 기능 변화를 줄 수 있습니다.

5. 람다 함수 스케쥴링(Cron)
새롭게 주기적으로 람다 함수를 실행할 수 있는 기능을 추가합니다. 실행 날짜, 시간 및 분 단위로 주기를 정할 수 있고 이는 기존 Cron 작업과 비슷합니다.

이러한 기능들은 오늘 부터 바로 AWS 관리 콘솔에서 사용할 수 있으며 바로 활용할 수 있습니다.

— Jeff;

이 글은 AWS Lambda Update – Python, VPC, Increased Function Duration, Scheduling, and More의 한국어 번역이며, re:Invent 2015의 신규 서비스 소식입니다.

EC2 Container Service 신규 기능 – 콘테이너 레지스트리, ECS CLI, AZ-인식 스케줄링 등

최근 도커(Docker)를 기반한 콘테이너 기반 배포 모델이 빠르게 자리잡아 가면서 더 빠른 앱 빌드, 실행 및 업데이트 및 확장을 선호해 가고 있다는 점은 고무적입니다. 작년에 Amazon EC2 Container Service(ECS)를 공개한 이후 많은 고객들이 이를 실제로 적용하여 마이크로서비스(Microservices) 기반 웹 애플리케이션 개발과 일괄 처리 업무 등에 활용 중입니다.

많은 개발자들은 콘테이너를 통해 개발, 테스트 및 배포에 드는 작업 속도를 높힐 수 있다고 이야기합니다. 특히 개별 콘테이터들이 “표준” 개발 환경을 가지고 있기에 다양한 프로그래밍 언어, 프레임웍 및 미들웨어의 조합을 만들 수 있으며, 이러한 자유도 높은 격리 방식을 통해 전체 시스템을 하나로 만들어 큰 변경에 따른 위험 부담을 줄여 더욱 혁신을 이룰 수 있게 되기 때문입니다.

그동안 Amazon ECS와 도커 사용자로 부터 받은 다양한 피드백을 바탕으로 오늘 새로운 기능 몇 가지를 공개합니다. 바로 Amazon EC2 Container Registry(콘테이너 레지스트리), Amazon EC2 Container Service CLI(ECS CLI)입니다. 또한 Amazon ECS 스케줄러를 통해 가용 영역(Availablity Zones) 인식 및 신규 콘테이너 옵션 몇 가지를 추가 합니다.

한번 같이 살펴 보도록 하겠습니다.

Amazon EC2 Container Registry(콘테이너 레지스트리)
도커 또는 ECS 역시 가상 이미지라는 개념에서 시작합니다. 콘테이너를 실행할 때, 이러한 가상 이미지를 참고하고 이를 Docker Registry라는 저장소에서 가져옵니다. 레지스트리는 배포 과정에서 매우 중요한 부분입니다. 고객들과의 대화를 통해 우리는 레지스트리 자체가 매우 높은 가용성과 확장성 및 여러 리전을 지원하는 글로벌 접근 가능한 시스템으로 만들어져야할 필요가 있다고 배웠습니다. 또한, AWS Indentity and Access Management(IAM) 서비스와 연동하여 보다 세부적인 제어를 위한 인증도 필요합니다.

고객들의 이러한 요구사항에 맞추어 직접 레지스트리를 운영하다 보니 피해도 되는 관리 부담이 들게 되었습니다.

이에 저희는 Amazon EC2 Container Registry(Amazon ECR)를 공개합니다. 이전의 콘테이너 이미지의 저장 및 관리 배포 등의 운영 부담을 줄일 수 있는 관리형 서비스입니다.

Amazon ECR은 ECS를 통해 여러분의 프로덕션 워크플로와 쉽게 통합할 수 있습니다. 여러분의 개발 PC에서 도커 CLI를 통해 Amazon ECR로 콘테이너 이미지를 등록할 수 있고, Amazon ECS에서 배포 과정에서 가져올 수도 있습니다.

콘테이너 이미지를 S3에 저장하고, IAM 사용자의 역할을 기반으로 접근 제어와 함께 전환 과정에서 암호화도 지원 합니다. 여러분은 인터넷을 통해 전송되는 데이터와 저장하는 데이터에만 신경 쓰시면 됩니다.

아래는 관리 콘솔에서의 몇 가지 스크린샷입니다.

등록 페이지에서 방문하여 초기 접근을 위해 등록을 하실 수 있습니다. 이 프로그램에 관심이 있으시면 오늘 바로 하실 수 있습니다.

이를 함께 작업한 여러 파트너도 있습니다. Shippable, CloudBees, CodeShip 및 Wercker 등의 협력사와 Amazon ECS와 ECR의 통합 및 자동 빌드, 도커 이미지 배포 등을 제공합니다. 더 자세한 사항은 콘테이너 파트너 페이지를 참고하세요.

Amazon ECS CLI
ECS 커맨드라인 인터페이스(CLI)는 Amazon ECS를 위해 만들어진 것으로 로컬 개발 환경에서 클러스터, 태스크를 생성하거나 업데이트 및 모니터링 할 수 있도록 하는 간편한 명령어입니다.

Amazon ECS CLI는 Docker Compose를 지원하는데, 이 프로그램은 멀티 콘테이너 애플리케이션을 정의하고 실행하는 인기 높은 오픈 소스 도구입니다. 매일 일어나는 개발 및 테스트 주기에서 AWS 관리 콘솔이 아닌 새로운 간편한 방식입니다.

ECS CLI를 몇 분안에 사용해 보실 수 있습니다. 사용 가이드를 기반으로 다운로드 해서 설치만 하면 되며, 클러스터 설정의 경우 아래와 같이 간단한 샘플 명령어를 사용할 수 있습니다.

$ ecs-cli configure --region us-east-1 --cluster my-cluster

클러스터 실행을 다음과 같습니다.

$ ecs-cli up --keypair my-keys --capability-iam --size 2

Docker Compose는 설정 파일이 필요합니다. 아래는 간단한 docker-compose.yml 파일입니다.

web:
  image: amazon/amazon-ecs-sample
  ports:
  - "80:80"

이제 클러스터를 실행해 봅니다.

$ ecs-cli compose up
INFO[0000] Found task definition TaskDefinition=arn:aws:ecs:us-east-1:980116778723:task-definition/ecscompose-bin:1
INFO[0000] Started task with id:arn:aws:ecs:us-east-1:9801167:task/fd8d5a69-87c5-46a4-80b6-51918092e600

실행 중인 태스크가 있는지도 한번 살펴봅니다.

$ ecs-cli compose ps
Name                                      State    Ports
fd8d5a69-87c5-46a4-80b6-51918092e600/web  RUNNING  54.209.244.64:80->80/tcp

위에 지정된 주소에서 여러분의 샘플 앱이 돌아가고 있는지 확인해 보시면 됩니다.

ECS CLI는 여러 옵션을 지원합니다. (전체를 보시려면 -help를 해보세요.) 예를 들어, 장기 실행 서비스도 만들어 관리 가능합니다. 아래는 옵션 목록입니다.

ECS CLI는 Apache 2.0 라이선스 기반의 오픈 소스로 https://github.com/aws/amazon-ecs-cli에서 받을 수 있으며, 여러분의 풀 리퀘스트(Pull Request)도 기다립니다.

도커 콘테이너 신규 설정 옵션
태스크 정의(task definition)은 애플리케이션 정보입니다. 이를 통해 콘테이너를 정의하고 언제 어떤 EC2 인스턴스에 배포할 것인가를 정의할 수 있습니다. 몇 가지 파리미터를 통해 이러한 태스크 정의를 할 수 있는데, 사용할 도커 이미지, 각 콘테이너가 사용할 CPU 및 메모리 용량 및 호스트 콘테이너와 매핑할 포트 등입니다.

뿐만 아니라 도커 라벨, 작업 디렉토리, 네트워크 사용 여부, 실행 권한, 읽기 전용 루트 파일 시스템, DNS 서버 및 DNS 검색 도메인, 로그 설정 및 (/etc/hosts에 넣을) 추가 호스트, SELinux 등에서 지원하는 멀티 레벨 보안(Multi-Level Security) 등 보안 옵션도 있습니다.

ECS 콘솔 내부에 이러한 태스크 정의 편집기를를 통해 업데이트하거나 새로운 설정을 입력할 수 있습니다.

더 자세한 사항은 태스크 정의 파라미터 문서를 참고하시기 바랍니다.

가용 영역 인식 스케줄링 지원
장기 실행 서비스 및 애플리케이션을 위한 콘테이너의 스케줄링을 위해 올해 초 Amazon ECS Service Scheduler를 소개하였습니다. 서비스 스케줄러는 Elastic Load Balacing과 선택저그로 통합할 수 있습니다. 이를 통해 특정 숫자의 태스크를 항상 실행할 수 있고, 이게 실패하면 태스크를 재시작합니다. 고객들이 ECS를 프로덕션 환경에서 서비스를 할 수 있는 주요한 기능이고, 계속적으로 좀 더 쉽게 지원을 계속하려고 합니다.

오늘 부터 서비스 스케줄러는 가용영역을 인식합니다. 즉, 새 태스크를 실행하면 서비스 스케줄러가 태스크를 AWS의 다중 가용영역 기반으로 서비스 부하 분산을 하게 됩니다.

re:Invent Amazon ECS 배우기
여러분이 re:Invent 현장에 계시다면 여러분의 (경쟁자가 아닌) 동료들이 어떻게 콘테이너 기반 컴퓨팅 서비스를 만들고 운영하는지 그 노하우를 배우실 수 있습니다. 아래 세션들을 참고해 보시기 바랍니다.

  • CMP302 – Amazon EC2 Container Service: Distributed Applications at Scale (생중계 예정)
  • CMP406 – Amazon ECS at Coursera.
  • DVO305 – Turbocharge Your Continuous Deployment Pipeline with Containers.
  • DVO308 – Docker & ECS in Production: How We Migrated Our Infrastructure from Heroku to AWS.
  • DVO313 – Building Next-Generation Applications with Amazon ECS.
  • DVO317 – From Local Docker Development to Production Deployments.

— Jeff;

이 글은 EC2 Container Service Update – Container Registry, ECS CLI, AZ-Aware Scheduling, and More의 한국어 번역이며, re:Invent 2015의 신규 서비스 소식입니다.

EC2 인스턴스 추가 – X1 (SAP HANA) 및 T2.Nano

AWS 고객의 계획과 인프라 요구 사항에 저희에게 항상 공유해 주고, 저희는 이러한 필요를 맞추기 위해 노력해 왔습니다. EC2 인스턴스 역사를 보면 그러한 변화를 잘 파악할 수 있으며 다양한 인스턴스 타입을 추가해 왔습니다.

최근에 아래의 두가지 요구사항을 많이 받아 왔으며 매우 중요한 산업 트렌드라고 생각하고 있습니다.

  • 엔터프라이즈 고객은 많은 메모리 용량을 가진 고성능의 인스턴스를 요구합니다. 인메모리 기반의 SAP HANA나 Neo4j 및 Titan 같은 실시간 분석 그리고 대용량 캐시 같은 사례가 있습니다.
  • 소형 웹 사이트를 운영하는 고객은 그렇게 많은 컴퓨팅 용량을 차지 하지 않거나 모니터링이나 마이크로서비스용 서비스를 운영하기도 합니다.

이러한 요구 사항을 맞추기 위해 오늘 저희는 두 가지의 새로운 인스턴스 타입을 소개합니다. 바로 대용량 메모리를 가진 X1 인스턴스와 매우 적은 컴퓨팅 용량을 가지지만 필요 시 버스팅 기능을 가진 t2.nano입니다.

X1 – 대용량 메모리 기반
X1 인스턴스는 2TB의 메모리를 가지며 대용량 메모리 작업이 필요한 SAP HANA, Microsoft SQL Server, Apache Spark 및 Presto 같은 애플리케이션에 적합합니다.

X1인스턴스는 네 개의 Intel® Xeon® E7 프로세서를 기반으로 하고 각 프로세서는 L3 캐시의 메모리 대역폭을 가지며 고성능 대용량 메모리 앱을 지원합니다. 100개가 넘는 vCPU를 통해 이들 인스턴스가 동시 작업을 수행할 수 있습니다.

X1 인스턴스는 2016년 상반기 중에 공개할 예정이며, 더 자세한 것은 이 블로그를 통해 알려드리겠습니다.

t2.nano – 소형 서비스용(버스팅 기능 포함)
T2 인스턴스는 최저 사양의 프로세서 기준을 가지고 이를 넘어가는 경우 기존에 모아둔 CPU 크레딧이라는 사용하는 방식으로 효율적으로 인스턴스를 운영할 수 있는 모델입니다. 저희는 t2.micro, t2.small 그리고 t2.medium 등의 서비스를 제공했습니다. 버스팅 모델은 많은 고객들에게 인기가 높아지고 있으며 얼마 전 t2.large라는 인스턴스도 제공하기 시작했습니다.

다음 단계로 오늘 t2.nano라는 인스턴스 타입을 공개합니다. 1 vCPU에 512MB의 메모리를 가지며 한 시간 정도 전체 CPU를 사용할 수 있는 크레딧을 제공합니다.

트래픽이 거의 없거나 간단한 작업을 하는 서비스에 적합니다. 본 인스턴스 타입 또한 더 자세한 것은 이 블로그를 통해 알려드리겠습니다.

— Jeff;

이 글은 EC2 Instance Update – X1 (SAP HANA) & T2.Nano (Websites)의 한국어 번역이며, re:Invent 2015의 신규 서비스 소식입니다.

re:Invent 2015 이모저모(2)

드디어 re:Invent 주요 행사가 시작되는 날입니다. 첫번째 이모저모 다음으로 두번째 소식을 전합니다. 오늘은 아침 8시 30분 부터 시작되는 앤디 제시 부시장의 키노트를 듣기 위해 아침을 먹고 길게 100m 넘게 줄을 설 만큼 엄청난 인파입니다.

올해 1만 9천명이 넘는 분들이 등록을 했고, 35천명이 라이브 스트림 등록 그리고 278개의 세션이 진행됩니다.

첫날 키노트 신규 출시 서비스
고객의 기대에 부응하듯이 앤디 제시는 클라우드가 가져다 준 7가지 자유(Freedom)를 기반으로 키노트를 진행하였습니다.

1. Freedom to build, unfettered
AWS 클라우드의 폭넓고 깊은 서비스 기능으로 인해 엔터프라이즈에서도 최소한의 제약만이 있으며, 클라우드 전략을 가져가는데 자유를 얻을 수 있다.

2. Freedom to get the real value from your data
AWS 클라우드에서는 대용량 데이터를 손쉽게 처리할 수 있는 다양한 서비스를 제공하고 있으며, 데이터에서 가치를 찾는 곳에 서비스를 집중하고 있으며 이번에 Amazon QuickSight를 통해 기존보다 훨씬 저렴한 가격에 비지니스 인텔리전스(BI) 솔루션을 얻을 수 있다.

3. Freedom to get your data into (or out of) the cloud easily
AWS 클라우드에서 대용량 데이터 혹은 스트림 데이터도 손쉽게 클라우드와 기존 데이터 센터를 오갈 수 있는 자유가 있으며, 이를 위해 Amazon Kinesis Firehose를 통한 대용량 스트림 처리 그리고 Amazon Import/Export Snowball을 통한 기존 데이터를 한번에 50TB씩 손쉽게 옮길 수 있는 클라우드 이전 전용 저장 장치 등을 새로 선보인다.

4. Freedom from bad (database) relationships
Amazon RDS에서 오픈 소스 엔진으로도 상용 데이터베이스 만큼의 성능을 보장 받을 수 있는 비용 효율적인 Amazon Aurora와 더불어 새롭게 여섯번째 RDS인 MariaDB의 지원 그리고 엔진간 스키마 변환기를 제공한다.

5. Freedom to migrate
엔터프라이즈 클라우드 전환 전략에서 중요한 것은 온-프레미스의 데이터 센터에서 어떻게 데이터를 이전하는가 하는 것이다. 이를 위해 AWS 및 DB 데이터 마이그레이션 서비스를 미리 보기로 제공한다.

6. Freedom to secure your cake and eat it too
클라우드 전환에서 보안과 규정 준수는 매우 중요한 이슈이다. AWS Config Rule은 기존 규정을 준수할 수 있는 도움을 주는 것이다. 또한, 자동으로 규정 준수 여부를 확인할 수 있는 Amazon Inspector를 출시한다.

7. Freedom to say “yes”
IT리더들이 자신의 의지대로 민첩하게 플랫폼을 사용해서 클라우드로 전환하는 기회를 제공한다. 직접 경험하고 의지를 가지고 클라우드를 활용할 수 있는 자유가 필요하다.

많은 분들이 관심이 많을 키노트 중에 나온 신규 서비스에 대해 소개해드립니다.

한국 고객 최초 세션 발표
이번 행사에서는 한국 고객 중 최초로 re:Invent 세션을 발표하는 두 회사가 있습니다. 바로 IGAWorks 및 데브시스터즈입니다. IGAworks의 백정상 이사님은 DAT202 – Managed Database Options on AWS 발표를 통해 모바일 광고 플랫폼에서 데이터베이스 활용 모범 사례를 발표합니다.

또한, 데브시스터즈의 안재만 님은 GAM201 – Cloud Gaming Architectures from Mobile to Social to MMO를 통해 다양한 게임 아키텍쳐를 소개하였습니다.

올해를 시작으로 내년에도 더 많은 한국 고객들이 클라우드 활용 노하우를 전 세계에 공유하는 자리가 더 많아졌으면 좋겠습니다.

최초 한중일 동시 통역 세션 제공
양일 키노트 및 APAC 트랙에서는 일본어와 중국어를 포함 한국어 동시 통역이 진행되었습니다. 저도 해외 콘퍼런스를 많이 다녔는데, 이렇게 동시 통역을 제공해 주는 경우를 거의 보지 못했습니다. (일본의 경우, 작년 부터 시작했는데 호응이 좋아 2개 언어를 추가하였습니다.)

현지에서 통역사들과 오랜 기간 준비하고 직접 데려와 진행하니 매우 높은 품질의 통역을 들을 수 있었습니다. 저도 통역으로 들었는데, 쏙쏙 이해가 되었습니다.

동북아시아 지역의 언어 장벽을 가진 고객들에게는 매우 소중한 경험이 될 것 같습니다. 앞으로도 리인벤트에서 고객의 만족도를 높히는데 더욱 좋은 아이디어를 내어 보겠습니다.

300개가 넘는 전시 부스 활동
또 하나 빼 놓을 수 없는 곳이 바로 re:Invent Central이라는 전시장입니다. 클라우드 대표 행사인 만큼 전 세계 내노라하는 대부분의 클라우드 업체들이 모두 참석해서 참석자들에게 자사의 서비스와 AWS와 연계된 제품을 선보였습니다.

아마 최근 들어 이렇게 활기를 띠는 전시장을 보기가 힘듭니다. 한번 와 보시면 정말 얼마나 큰 생태계가 이루어 지고 있는지 아실 수 있습니다.

오늘은 여기까지 전하고 내일 또 즐거운 소식으로 찾아 뵙겠습니다. 더 자세한 것은 re:Invent 트위터 계정 및 #reinvent 해시태그를 통해 현장의 느낌을 보실 수 있습니다.

Amazon Inspector – 신규 자동 보안 평가 서비스

시스템과 설정 및 애플리케이션이 점점 더 복잡해짐에 따라 보안 및 규정 준수 문제도 많아지고 있습니다. 민첩한 개발 방법론 덕분에 “코드 개발 완료”와 “테스트 및 배포 완료” 사이의 시간은 점점 줄고 있지만, 테스트 도중에 파악하지 못했던 실수로 인한 취약점도 가끔 발견됩니다. 또한 많은 기업들이 시간이 많이 드는 매뉴얼 확인이나 서버 및 자원을 관리할 충분한 보안 인력을 갖추고 있지도 못한 상황입니다.

Amazon Inspector 신규 서비스
오늘 Amazon Inspector 미리 보기(Preview) 서비스를 공개합니다. 이름에서 내포하듯이 여러분이 AWS에서 구동하는 애플리케이션의 동작들을 분석하여 보안상 문제의 가능성을 미리 인지하는데 도움을 줄 것입니다.

Inspector는 애플리케이션 기반의 애플리케이션으로 동작하는데, 즉 여러분이 만드는 앱을 구성하는 AWS 자원의 모음을 정의하는데서 부터 시작합니다.

이 때 애플리케이션의 보안 평가 항목들을 만들어서 실행할 수 있습니다.

여러분의 애플리케이션을 운영하는 EC2 인스턴스나 다른 AWS 자원들을 태그로 분류하고, 평가 기준을 만들 때 기간(1/8/12/24시간 또는 2/3/7일 등)을 설정합니다.

평가 기간 동안 각 EC2 인스턴스의 Inspector 에이전트가 실행되면서 네트워크, 파일시스템, 및 프로세스 등의 활동을 살펴봅니다. 다른 AWS 자원과의 세부 통신 사항, 보안 채널의 사용 여부, 인스턴스와의 네트워크 트래픽 등도 수집합니다. 이들 정보를 통해 Inspector는 애플리케이션의 보안 가능성 이슈 및 규정 준수 여부을 파악하게 됩니다.

데이터를 수집한 이후에는 기존에 만들어진 보안 규칙과 비교, 분석하게 됩니다. 이러한 규칙은 모범 사례, 표준 규정 및 AWS 보안팀의 지식을 기준으로 모여준 취약점을 확인해서 만듭니다. 보안팀의 구성원들은 항상 신규 보안 취약점 및 모범 사례를 찾아내고 연구하는 우수한 인력들로서 Inspector에 새로운 규칙들을 추가하고 있습니다.

이번에 새로 시작되는 Inspector에는 아래의 규칙 모음을 포함합니다.

  • 일반 취약점 노출 사례
  • 네트워크 보안 모범사례
  • 인증 체계 모범 사례
  • 운영 체제 모범 사례
  • 애플리케이션 보안 모범 사례
  • PCI DSS 3.0 규정

Inspector를 통해 인지된 문제점들은 (우리는 “finding”이라 부릅니다) 모아서 중요도에 따라 보고서 형식으로 살펴 볼 수 있습니다.

Inspector 서비스는 AWS 관리 콘솔 및 AWS 커맨드 라인 인터페이스 및 API로 이용 가능합니다.

향후 계획
이번 re:Invent가 끝나고 나면 Amazon Inspector에 대한 자세한 사항을 곧 블로그를 통해 공유해 드리겠습니다.

— Jeff;

이 글은 Amazon Inspector – Automated Security Assessment Service의 한국어 번역이며, re:Invent 2015의 신규 서비스 소식입니다.

Amazon RDS – MariaDB 신규 서비스 공개

우리는 6년전인 2009년에 관계형 데이터베이스의 매니지드 서비스인 Amazon RDS를 처음 시작하였습니다. 먼저 MySQL을 맨 먼저 서비스하기 시작하여, MS SQL서버, 오라클 및 PostgreSQL 그리고 최근에는 Amazon Aurora 서비스를 시작했습니다. 모든 AWS 리전과 다양한 인스턴스 타입으로 서비스를 제공하고 있으며, 여러분의 각 지리적 기반 사용자에게 다양한 하드웨어 선택 사양에 따라 애플리케이션의 요구 사항을 맞출 수 있게 되었습니다.

Maria DB 서비스 개시
오늘부터 새롭게 MariaDB 데이터베이스 10.0.17 버전을 RDS로 제공합니다. 2009년 MySQL로 부터 분리되어 XtraDB 및 Aria의 두가지 스토리지 엔진을 지원하면서 빠르게 개발되어 온 인기 있는 오픈소스 DB엔진입니다. 이를 활용하고자 하는 고객들의 요구를 받아 병렬 리플리케이션(Pararell replication) 및 쓰레드 풀(Thread pool) 등의 멋진 기능도 포함합니다.

RDS의 다른 데이터베이스와 마찬가지로 관리 콘솔 및 리눅스 커맨드라인과 윈도우 파워셀 그리고 RDS API 및 CloudFormation 템플릿을 사용할 수 있습니다.

다음과 같은 커맨드라인 명령어로 바로 DB 서버를 띄울 수 있습니다.

$ rds-create-db-instance jeff-mariadb-1 \
  --engine mariadb \
  --db-instance-class db.r3.xlarge \
  --db-subnet-group-name dbsub \
  --allocated-storage 100 \
  --publicly-accessible false \
  --master-username root --master-user-password PASSWORD

하나씩 살펴 보면 다음과 같습니다.

  • 첫 번째 라인에서 rds-create-db-instance를 통해 이름(jeff-mariadb-1)을 설정합니다.
  • 두 번째 라인에서 MariaDB 엔진을 선택하고, 세 번째 라인에서 인스턴스 타입인 db.r3.xlarge를 선택합니다.
  • 네 번째 라인에서는 DB 인스턴스의 서브넷 그룹을 선택하는데, 이는 여러분의 VPC(Virtual Private Cloud)의 목록 중 맞는 것을 입력합니다.
  • 다섯 번째 라인에서는 100GB의 스토리지를 설정하고, 6번째 라인에서는 공개 IP 주소 접근 허용을 하지 않도록 설정합니다.
  • 마지막 라인에서는 DB의 마스터 유저의 아이디 및 암호를 입력합니다.

실행이 완료되면 아래와 같은 결과를 보실 수 있습니다.

DBINSTANCE  jeff-mariadb-1  db.r3.xlarge  mariadb  100  root  creating  1  ****  db-QAYNWOIDPPH6EYEN6RD7GTLJW4  n  10.0.17  general-public-license  n  standard  n
      VPCSECGROUP  sg-ca2071af  active
SUBNETGROUP  dbsub  DB Subnet for Testing  Complete  vpc-7fd2791a
      SUBNET  subnet-b8243890  us-east-1e  Active
      SUBNET  subnet-90af64e7  us-east-1b  Active
      SUBNET  subnet-b3af64c4  us-east-1b  Active
      PARAMGRP  default.mariadb10.0  in-sync
      OPTIONGROUP  default:mariadb-10-0  in-sync

RDS 커맨드 라인은 매우 훌륭한 도구로서 기술 문서를 통해 더 자세한 것을 확인할 수 있습니다. 예를 들어, rds-create-db-instance-read-replicas로 읽기 복제본을 만들 수 있고 rds-create-db-snapshot를 통해 몇 분 안에 백업본을 만들 수 있습니다.

물론 AWS 관리 콘솔 화면에서도 쉽게 인스턴스를 만들 수 있습니다.

지금 시작하기
MariaDB 실행 RDS 인스턴스는 오늘 부터 모든 리전에서 사용 가능하며 M3(표준), R3(메모리 최적화), T2(표준) 인스턴스를 지원합니다.

— Jeff;

이 글은 Amazon RDS Update – MariaDB is Now Available의 한국어 번역이며, re:Invent 2015의 신규 서비스 소식입니다.

AWS Import/Export Snowball – 전용 스토리지로 1주일에 1페타바이트 전송하기

초고속 인터넷 라인이 제공되더라도 테라 혹은 페타바이트 데이터를 클라우드로 이전을 위해 전송하는 것은 쉬운 일이 아닙니다. 많은 고객들이 클라우드 이전을 결정하고도, 데이터 이전에서 어려움을 겪는 경우가 많습니다.

그래서, 2009년에 처음으로 AWS Import/Export 서비스를 시작했습니다. 그 때 “하드 디스크가 인터넷보다 더 빠르게 많이 담을 수 있다”라고 생각했고, 현재도 비슷합니다. 최근 빅데이터 응용 프로그램이 늘어나고 및 센서 기반 네트웍의 출현 등으로 “일단 저장하고, 나중에 가치를 찾자”라는 인식이 확산 되고 있을 정도로 데이터 양이 폭증하고 있습니다.

사실 초기 AWS Import/Export 모델은 여러분이 직접 디바이스를 골라서 구매 및 포맷, 데이터 저장 및 배송까지 알아서 해야 하는 시스템으로 만들어졌습니다. 많은 고객들이 이를 사용해 보고, 몇 가지 어려움을 느꼈습니다. 예를 들어, AWS에 한번 이전을 하려고 비싸기 여러 저장 장치를 구매를 해야 한다는 점과 장치의 내구성 및 암호화 이슈, 각 장치에 manifest 파일을 만들고 저장 및 운송에 대한 오버헤드와 조작 실수 등등입니다.

Amazon이 직접 제공하는 장치를 통한 데이터 이전 모델
이러한 원래 서비스 모델에 대한 경험을 토대로 AWS Import/Export Snowball이라는 신규 서비스를 오늘 공개합니다. 아마존이 직접 소유 및 유지하는 장치를 통해 빠르고 간단하면서도 효율적인 데다 보안까지 우수합니다. 더 이상 스토리지를 사거나 회선을 늘릴 필요가 없습니다.

Snowball은 한번에 10테라바이트 혹은 그 이상의 데이터를 이전해야 할 필요가 있을 때 유용합니다. AWS 관리 콘솔에서 간단하게 신청만 하면, 며칠 안에 여러분의 주소로 기기를 보내드립니다. 더 많은 데이터를 이전하시려면 여러 개의 Snowball 장치를 요청하시고, 병렬 적으로 작업하시면 됩니다.

새로 만들어진 기기는 데이터 저장 및 전송에 효율적으로 만들어졌습니다. 6G 정도의 충격에도 견디며, 한 사람이 운반할 만큼 가벼운(23kg) 크기입니다. 뒤에는 110 볼트 파워에 10GB 네트웍 연결이 가능하고, 앞에는 표시등이 있습니다. 굳은 날씨 조건에도 잘 견디고 이미 포장이 된 상태입니다. 택배로 부터 받아서 데이터 센터로 가져갈 수 있으며, 보낼 때 다시 포장할 필요도 없습니다. 물리적으로도 튼튼하고 변형 억제 기능을 가지고 있습니다. 모양은 아래와 같습니다.

일단 Snowball 기기를 받으시면 플러그를 꼽고 네트웍에 연결하신 후 IP 설정(DHCP로 자동 인식하거나 설정 가능) 후 SnowBall 클라이언트를 설정합니다. 그 다운 콘솔에서 신청 시 받은 작업용 manifest 및 25자리 언락(unlock) 코드를 입력하면 기기 사용을 시작할 수 있습니다.

아래 명령어를 통하면 바로 시작 가능합니다.

$ snowball start -i DEVICE_IP -m PATH_TO_MANIFEST -p UNLOCK_CODE

이제 데이터를 Snowball에 복사하면 됩니다. 데이터는 256비트 암호화되어 기기에 저장되며, 제한된 네트웍 접근을 가진 사설 서브넷으로 구성됩니다.

50테라바이트까지 데이터를 복사할 수 있고, 연결을 해제하면 e-ink 디스플레이가 자동으로 표시가 됩니다. 이제 장치를 저희에게 보내주시면 됩니다. 저희가 받은 후 데이터를 복호화 및 여러분이 처음 지정한 S3 버킷으로 복사해 드립니다. 절차가 완료되면 National Institute of Standards and Technology Special Publication 800-88 (미디어 장치 영구 삭제 가이드)에 따라 데이터는 완벽하게 삭제됩니다.

이러한 모든 절차는 Amazon Simple Notification Service (SNS) 토픽을 통해 여러분의 이메일 주소로 전달됩니다. SNS 알림을 통해 데이터 가져오는 과정을 자체 이전 워크플로 시스템과 통합할 수도 있습니다.

데이터 이전 작업 생성하기
이제 AWS Snowball 이전 작업을 관리 콘솔에서 하는 방법을 잠깐 살펴보겠습니다. (물론 AWS 커맨드라인 인터페이스에서도 가능합니다.) 아래와 같이 이름과 (이전에 가지고 있거나 새로운) 주소를 입력함으로서 시작할 수 있습니다.

저의 데이터 작업명 (import-photos)을 기입하고, 저장할 곳(AWS 리전 및 S3 버킷)을 설정합니다.

다음에는 (IAM 역할 및 암호화를 위한 KMS키) 보안 설정을 진행합니다.

이제 알림 설정을 하면 거의 끝났습니다. 새로운 SNS 토픽을 원하는 이메일로 받을 수 있고 알림을 원하는 상태 등을 선택 가능합니다.

신청 사항에 대해 최종 확인을 끝나면 작업이 활성화 됩니다.

이제 장치를 기다리시면 되고, 받으신 후 클라이언트 설치와 데이터 복사 후 보내 주시면 됩니다.

향후 계획
AWS Import/Export Snowball은 클라우드에서 데이터 이전을 쉽게 하기 위해 만든 것입니다. 데이터 이전에 대해 여러 가지 방법의 흥미 있는 사용 사례들이 있을 것으로 생각하며, 미래에는 더 많은 용량의 데이터 이전 및 제공이 이루어질 수 있을 것입니다.

앞으로 GPS기능이 장착된 기기 추적 기능을 포함한 더 많은 기능 개선을 준비하고 있습니다.

가격 및 이용 방법
한번 작업 비용은 200 달러이며, 추가로 여러분의 위치 및 배송 방식에 따른 비용이면 됩니다. 경우에 따라, 모든 작업을 마치는 데 10일 정도 걸릴 것으로 예상되며, 추가 하루 당 15불 정도가 책정됩니다. 현재 US West(오레곤) 리전의 S3 스탠다드 저장소에 제공이 되며, 향후에 추가로 확대할 예정입니다.

— Jeff;

이 글은 AWS Import/Export Snowball – Transfer 1 Petabyte Per Week Using Amazon-Owned Storage Appliances의 한국어 번역이며, re:Invent 2015의 신규 서비스 소식입니다.