Category: Serverless*


출시 예고 – Amazon Aurora 멀티 마스터 및 서버리스 서비스

Amazon Aurora에 대해 이미 들어보셨을 수도 있습니다. MySQL 호환 또는 PostgreSQL 호환 버전으로 제공되는 Aurora는 완전 관리형 솔루션으로, 최대 64TB 크기의 데이터베이스 스토리지까지 자동으로 확장됩니다. Aurora 데이터베이스 인스턴스를 생성할 때 원하는 인스턴스 크기를 선택할 수 있으며, 읽기 복제본을 사용하여 읽기 처리량을 늘리는 옵션도 있습니다. 처리 요건이나 쿼리 속도가 변경되면 인스턴스 크기를 수정하거나 필요에 따라 읽기 복제본 수를 변경할 수 있습니다. 이 모델은 워크로드를 예측할 수 있는 환경에서 요청 속도 및 처리 요구 사항에 맞게 매우 효과적으로 작동합니다.

오늘 관계형 데이터베이스의 병목을 획기적으로 개선할 수 있는 Aurora 멀티 마스터 및 서버리스 두 가지 기능을 미리 보기로 출시합니다.

Amazon Aurora 멀티 마스터 기능

Amazon Aurora 멀티 마스터로 복수의 가용 영역에서 작동하는 복수의 읽기/쓰기 마스터 인스턴스를 생성할 수 있습니다. 애플리케이션은 이를 통해 마치 읽기 전용 복제본을 읽는 것처럼 클러스터에 있는 여러 데이터베이스 인스턴스에 데이터를 쓰거나 읽을 수 있게 됩니다.

멀티 마스터 클러스터는 Aurora의 우수한 고가용성을 한층 더 강화합니다. 마스터 인스턴스 중 하나에 장애가 발생하면 클러스터에 있는 다른 인스턴스가 즉시 이어받기 때문에 인스턴스 장애는 물론 AZ 전체에 장애가 발생하더라도 애플리케이션이 중단되지 않고 계속 읽거나 쓸 수 있습니다.

현재 마스터 하나로 운영되는 Aurora는 데이터베이스 클러스터 하나에서 쓰기 인스턴스 하나와 최대 15개의 읽기 전용 복제본(승격 가능)을 지원합니다. 기본 쓰기 인스턴스는 r4.16xlarge에서 1초당 최대 200,000개의 쓰기 작업을 실행할 수 있습니다. 쓰기 처리량이 그보다 많아야 하는 워크로드라면 마스터 인스턴스를 추가하고 쓰기 작업을 수평 확장함으로써 이익을 얻을 수 있습니다. 이 미리 보기는 Aurora MySQL 호환 버전에 사용 가능합니다. 참가하려면 등록 양식을 작성해 주십시오.

Amazon Aurora 서버리스 기능

데이터 베이스를 사용하다 보면, 경우에 따라 하루 또는 한 주에 몇 분 또는 몇 시간 동안 요청이 폭증하는 등, 워크로드가 간헐적이거나 예측 불가능할 수도 있습니다. 반짝 세일, 드물거나 일회성으로 진행하는 이벤트, 온라인 게임, 보고 워크로드(시간당 또는 일일), 개발/테스트 및 새로운 애플리케이션 출시가 대표적인 경우입니다. 정확히 알맞은 양의 용량만 확보하기 위해서는 많은 조사 작업이 필요할 수 있고, 정기 결제는 합리적이지 않을 수 있습니다.

바로 오늘 Amazon Aurora 서버리스의 프리뷰 버전이 출시됩니다(미리 보기 신청). 가변성이 높고 급격한 변화가 발생할 수 있는 워크로드에 적합하도록 설계된 이 새 구성에서는 데이터베이스 리소스 비용을 사용한 만큼 초 단위로 지불할 수 있습니다.

이 서버리스 모델은 Aurora 아키텍처의 일부로 내장된, 완벽하게 분리된 처리와 스토리지를 기반으로 구축됩니다(자세한 내용은 Design Considerations for High-Throughput Cloud-Native Relational Databases 참조). 처음에 데이터베이스 인스턴스 크기를 선택하는 대신 엔드포인트를 만들고, 필요에 따라 원하는 최소 및 최대 용량을 설정한 후 엔드포인트에 대해 쿼리를 발행합니다. 엔드포인트는 쿼리를 신속하게 확장된 데이터베이스 리소스 집합으로 라우팅하는 간단한 프록시입니다. 그러면 백그라운드에서 조정 작업이 이루어지는 동안에도 연결 상태를 그대로 유지할 수 있습니다. 새로운 리소스가 5초 이내에 온라인으로 제공되는 등, 조정이 빠르게 이루어집니다. 함께 정상적으로 작동되는 방식은 다음과 같습니다.

스토리지와 처리가 분리되므로 이론상 0까지 축소할 수 있고 스토리지에 대한 비용만 지불하면 됩니다. 정말 멋진 모델이라고 생각합니다. 덕분에 새로운 종류의 인스턴트 온 임시 애플리케이션이 개발될 것으로 기대합니다. 조정은 요청을 즉시 처리할 준비가 된 “웜” 리소스 풀을 기반으로 단 몇 초 만에 이루어집니다. 새로 추가된 리소스가 최고 속도로 작동하도록 캐싱 및 버퍼링된 기존 콘텐츠가 신중하게 구축됩니다. 거의 아무런 조치 없이 기존의 Aurora 데이터베이스를 서버리스로 만들 수 있습니다.

요금 청구는 Aurora 용량 단위를 기반으로 하며, 각 단위는 컴퓨팅 성능과 메모리의 조합을 의미합니다. 새로 추가되는 리소스당 1분을 최소값으로 하여 1분 단위로 측정됩니다.

지속적 업데이트
2018년 초, Amazon Aurora 서버리스에 대한 추가 정보를 제공할 예정입니다. 현재 계획은 상반기에 MySQL 호환성을 갖춘 프로덕션 형태로 출시하고, 하반기에는 PostgreSQL 호환 버전을 출시하는 것입니다. 바로 지금 프리뷰 서비스에 가입할 수 있습니다.

Jeff;

이 글은 AWS re:Invent 2017 신규 서비스 출시 소식으로 Sign Up for the Preview of Amazon Aurora Multi-Master 및  In The Works – Amazon Aurora Serverless의 한국어 번역 편집본입니다.

AWS Step Functions를 통해 서비스 플로우 개선 – 코카콜라 지불 서비스 사례

Amazon의 혁신 문화에 대한 프레젠테이션을 할 때가 많은데 이때마다 Amazon 창업자인 Jeff Bezos의 말을 인용한 슬라이드로 시작합니다.

고객과 함께 머리를 맞대고 앉아 우리가 어떻게 그들의 창의성을 강화시켰는지 알아보고, 함께 새로운 꿈을 추구하는 것을 좋아합니다. 올해 초에 AWS Step Functions 및 기타 AWS 서비스를 사용하여 Coke.com Vending Pass 프로그램을 지원한 방법을 알아보기 위해 Coca-Cola Company의 Patrick과 대화를 나눈 적이 있습니다.

이 프로그램에는 Coca-Cola Vending Pass를 사용하여 모바일 결제를 지원할 수 있는 기능을 갖춘 자동 판매기에서 제품을 구매하여 얻은 음료 보상이 포함됩니다. 참가자는 자신의 NFC 지원 휴대폰을 갖다 대서 Apple Pay 또는 Android Pay 구매를 완료함으로써 자동 판매기에서 자신을 식별하고 향후 무료 자동 판매기 구매를 위한 크레딧을 획득할 수 있습니다.

AWS SNS 토픽과 AWS Lambda 기능의 조합을 통해 기존 백엔드 코드 중 일부에 대한 한 쌍의 호출을 시작하여 자동 판매기 포인트를 계산하고 참가자의 레코드를 업데이트했습니다. 그러나 백엔드 코드는 반응이 느리고 시간 종속성이 있어 Vending Pass 참가자에게 혼동을 줄 가능성이 있는 업데이트 누락이 발생할 수 있었습니다. 이 문제에 대한 초기 해결책은 매우 간단했습니다. 즉, 두 호출 사이에 90초 지연을 포함하도록 Lambda 코드를 수정하는 것이었습니다. 이것으로 문제는 해결되었지만 아무 이유도 없이 프로세스 시간을 소비했습니다(Lambda 함수 사용에 대한 요금 청구는 100ms 간격으로 요청 기간을 기반으로 함).

솔루션을 보다 비용 효율적으로 만들기 위해 팀은 AWS Step Functions를 사용하여 매우 간단한 상태 시스템을 구축했습니다. 이전 블로그 게시물에 썼듯이 Step Functions는 구축하기 쉬운 시각적 워크플로를 사용하여 분산 애플리케이션 및 마이크로서비스의 구성 요소를 규모에 따라 조정합니다.

Coke는 매우 간단한 상태 시스템을 구축하여 비즈니스 로직을 간소화하고 비용을 절감했습니다. 사용자는 동등하게 간단하거나 순차 및 병렬 실행 등의 기타 Step Function 기능과 의사를 결정하고 대체 상태를 선택할 수 있는 기능을 사용할 수 있습니다. Coke 상태 시스템은 다음과 같습니다.

FirstStateSecondState 상태(작업 상태)는 Step Functions가 90초 지연(대기 상태)을 구현하는 동안 적절한 Lambda 함수를 호출합니다. 이 수정 사항을 통해 로직을 간소화하고 비용을 절감했습니다. 함께 정상적으로 작동되는 방식은 다음과 같습니다.

다음 단계
이 초기 성공으로 인해 서버리스 컴퓨팅에 대해 자세히 알아보고 다른 프로젝트에 이 서버리스 컴퓨팅의 사용을 고려하게 되었습니다. Patrick은 생산성의 향상과 개발자의 행복을 이미 실현했다고 말했습니다. 개발자는 더 이상 서버를 프로비저닝할 때까지 기다릴 필요가 없으며 이제 (Jeff의 말처럼) 자신의 창의성을 발휘하고 자신의 꿈을 추구할 수 있습니다. 그들은 Step Functions를 사용하여 애플리케이션의 확장성, 기능성 및 안정성을 향상시킴으로써 Coca-Cola Vending Pass의 초기 사용을 훨씬 능가할 것으로 예상합니다. 예를 들어 Coke는 Lambda, Step Functions, API Gateway를 사용하여 영양 정보를 식품 서비스 파트너에게 게시할 수 있는 서버리스 솔루션을 구축했습니다.

Patrick과 그의 팀은 이제 기계 학습 및 인공 지능을 실험하고 있습니다. 그들은 프로토타입 애플리케이션을 구축하여 Instagram의 사진 스트림을 분석하고 맛과 향미의 추세를 추출했습니다. 애플리케이션(빠른 1일 프로토타입으로 구축)은 Lambda, Amazon DynamoDB, Amazon API Gateway, Amazon Rekognition을 사용했으며 Patrick의 말에 따르면 “큰 승리이자 조력자”였습니다.

서버리스 애플리케이션을 보다 신속하게 구축하기 위해 개발 팀은 서버리스 애플리케이션 프레임워크를 기반으로 하는 내부 CI/CD 참조 아키텍처를 생성했습니다. 이 아키텍처에는 내부 서비스 및 자산에 액세스할 수 있는 몇 가지 보일러플레이트 코드와 서버리스의 가이드 투어가 포함되어 있습니다. Patrick은 이 모델을 통해 유망한 프로젝트를 “컴퓨터를 가진 사람”에서 전체 개발 팀으로 쉽게 확장할 수 있다고 말했습니다.

AWS re:Invent에서 제 동료인 Tim Bray 다음으로 Patrick이 무대에 오를 예정입니다. 직접 만나기 위해서는 SRV306 – 현장에서의 상태 시스템! 고객이 AWS Step Functions를 사용하는 방법에 참석하시기 바랍니다.

참고) 2016년 AWS re:Invent에서 Cocacola가 직접 발표한 세션 동영상도 참고하시기 바랍니다.

Jeff

이 글은 Things Go Better With Step Functions의 한국어 번역입니다.

Startup Kit Serverless Workload 예제 프로그램 소개

“AWS를 시작하는 가장 쉬운 방법은 무엇입니까?”라는 질문을 흔히 받습니다. AWS Elastic Beanstalk 등을 이용해 시작하는 좋은 방법이 여러 가지 있지만, 서버리스 컴퓨팅 역시 좋은 대안으로 급부상하고 있습니다.

서버리스 컴퓨팅은 서버에 대해 신경 쓰지 않고도 어플리케이션 및 서비스를 구축하고 실행할 수 있도록 해줍니다. AWS Lambda 서비스는 AWS에서의 서버리스 컴퓨팅을 구성하는 가장 핵심 빌딩 블록입니다. 이 외에도 AWS는 서버리스 아키텍처를 지원하는 여러 가지 서비스를 제공합니다. 여기에는 Lambda와 함께 RESTful API를 생성 할 수 있는 Amazon API Gateway와 데이터베이스 클러스터 설정으로부터 자유로운 NoSQL 클라우드 데이터베이스 서비스인 Amazon DynamoDB가 포함됩니다.

다음 도표는 하나의 완전한 서버리스 아키텍처를 나타냅니다:

serverless-arch

다이어그램의 아래쪽 서비스 그룹은 RESTful API 서비스를 구현합니다. API Gateway는 API 요청 및 응답을 처리하여 비즈니스 논리를 구현하는 Lambda 함수에 매핑합니다. DynamoDB는 지속적인 계층입니다. 다이어그램의 맨 위에 있는 서비스 그룹은 프론트 엔드를 형성합니다. Amazon S3는 AngularJS 또는 React 앱과 같은 정적 웹 자산을 호스팅하며 프론트 엔드 서버를 실행할 필요가 없는 완전 관리형 서비스입니다. S3 앞단에는 전 세계 사용자들과 가까운 엣지 로케이션(edge location)에서 웹 콘텐츠를 효율적으로 전달하기 위한 콘텐츠 전달 네트워크(CDN)인 Amazon CloudFront가 있습니다.

최근까지 서버리스 어플리케이션을 구현할 때 고려해야 할 사항 중 하나는 효율적으로 배포하는 방법이었습니다. 이제는AWS의 고유 솔루션인 AWS SAM(Serverless Application Model)이 이 문제를 해결해 줍니다. AWS SAM을 사용하면 간단한 YAML 기반 설명 언어와 단 2 개의 AWS CLI 명령을 사용하여 서버리스 배포를 쉽게 관리할 수 있습니다. AWS를 시작하는데 있어 서버리스 아키텍처를 구축하는 것이 가장 쉬운 방법일 수 있습니다. 특히 인프라 관리에 익숙하지 않은 사용자에게는 더욱 그렇습니다.

이 글에서는 AWS Startup Kit을 소개합니다. Startup Kit은 AWS를 시작하는 방법에 대한 지침을 제공하며 스타트업에서 흔히 사용하는 기술을 도입한 워크로드의 예제를 포함합니다. “워크로드”는 고객에게 노출된 RESTful API, 분석을 위한 일괄 처리 작업 등과 같이 비즈니스 또는 운영 가치를 제공하는 AWS에서 실행되는 하나 이상의 관련 어플리케이션을 말합니다.

Startup Kit 구성 요소는 Startup Kit Serverless Workload입니다. Lambda Node.js 4.3 런타임을 사용하여 빌드되고 SAM과 함께 배포되는 TODO 어플리케이션의 샘플 RESTful API입니다. Github의 startup-kit-serverless-workload저장소에서 코드를 확인할 수 있습니다. AWS 계정을 아직 설정하지 않았다면 AWS 계정을 설정하고 AWS CLI를 설치해야 합니다(자세한 내용은 여기에서 확인하실 수 있습니다).

서버리스 아키텍처의 이점
서버리스 아키텍처를 사용하면AWS Well-Architected framework의 많은 이점을 얻을 수 있습니다. Well-Architected Framework에 대한 자세한 내용은 본 포스팅의 범위를 벗어나지만, 간략하게 프레임워크에 해당하는 5개의 요소가 아키텍처에 어떻게 적용되는지 살펴 보겠습니다. 다음 요약 차트에서 “HA”는 고가용성(High Availability)을 의미하며 “OS”는 운영 체제 (Operating System)이며 “IAM”은 AWS 서비스 및 자원에 대한 액세스를 안전하게 제어 할 수 있는 AWS Identity and Access Management service를 의미합니다.

API Gateway Lambda DynamoDB
보안 기본 설정값: HTTPS
호출의 대역폭 조절 가능
IAM 또는 무기명 토큰 인증을 사용하여 API 콜 보안
AWS 관리형 OS
Lambda 함수의 다른 AWS 리소스에 대한 액세스는 이에 할당된 IAM 역할로 제한
IAM은 DynamoDB 리소스에 대한 세분화된 액세스 제어 제공 DynamoDB호출은 AWS CloudTrail을 사용하여 추적 가능
신뢰성 AWS 관리형 HA와 확장성
별도로 지정하지 않는 한 API 콜은 제한 안됨
AWS 관리형 HA와 확장성
실패한 비동기 호출이 재시도 되고 데드 레터 큐(DLQ)에 저장
AWS 관리형 HA와 확장성
데이터는 AWS 리전에 세 번 복제
성능 효율 결과 캐시 활성화 가능
서버리스 리소스는 필요할 때만 소비.
서버리스 리소스는 필요할 때만 소비 서버리스 리소스는 필요할 때만 소비.
비용 최적화 API 호출을 라우팅하기 위해 역방향 프록시 플릿 실행 필요 없음 함수 수행 중에만 비용 발생; 미 작동시에 비용 없음 Cluster 관리 없음
하드웨어 용량 예측 필요 없음
운영 효율성 SAM과 자동화
API 버저닝과 배포의 쉬운 관리
기본 매트릭스 제공; 로깅 활성화
SAM과 자동화
람다 콘솔에 기본 매트릭스 제공
Lambda 콘솔에서 링크로 로그 액세스 혹은 Amazon CloudWatch 콘솔 직접 이동
SAM과 자동화
DynamoDB 콘솔에 기본 매트릭스 제공
DynamoDB 스트림으로 테이블  변화에 대한 트래킹 가능

위 표는 Well-Architected framework의 가장 기초 사항에만 해당됩니다. AWS에서 서버리스 아키텍처를 구축해 나가면서 아키텍처를 개선할 추가 고려 사항 및 방법에 대해서는 Well-Architected Framework 백서를 참조하십시오.

워크로드 도입을 위해 SAM사용하기
SAM은 서버리스 어플리케이션을 정의하기 위한 모델입니다. SAM을 사용하려면 템플릿 파일에서 YAML (또는 JSON)로 서버리스 자원을 설명하고 두 개의 AWS CLI 명령을 사용하여 코드를 패키징 및 배포하십시오. SAM 자체는 오픈 소스 프로젝트이며 GitHub에서 사용할 수 있습니다. SAM은 “함수”(Lambda사용), “API”(API Gateway 사용) 및 “SimpleTable”(DynamoDB 사용)의 세 가지 기본 서버리스 자원을 지원합니다.

또한, SAM은 함수(예 : API)의 이벤트 소스 및 함수의 환경 변수와 같은 속성을 지정할 수 있습니다. SAM 템플릿을 더 단순화하려면 API를 함수의 이벤트 소스로 지정하세요. 그렇게 하면 SAM에서 명시적으로 API 리소스를 선언할 필요가 없습니다. 아래의 SAM 템플릿은 함수 리소스를 지정하는 것이 얼마나 간단한지 보여줍니다. 첫 번째 함수 인 CreateFunction은 TODO 응용 프로그램의 DynamoDB 테이블에서 새 TODO 항목을 만들기 위해 API 호출을 구현합니다.

서버리스 어플리케이션의 나머지 부분에 대한 CreateFunction의 관계는 SAM 템플릿에 완전히 지정됩니다. 예를 들어, CreateFunction이 DynamoDB 테이블과 상호 작용하는 방법을 지정하기 위해 템플릿은 DynamoDB 쓰기 권한을 포함하는 IAM 정책 인 CreateFunction과 연관되며 DynamoDB 테이블을 참조하는 환경 변수도 지정합니다. API 이벤트는 CreateFunction을 호출하기 위해 지정됩니다. 이 이벤트는 경로 및 HTTP 메소드(이 경우 POST)로 설명됩니다. SAM 템플리트의 다른 기능은 모두 동일한 기본 패턴을 따릅니다

YAML
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: RESTful API for a TODO app, backed by a SimpleTable (DynamoDB) resource.

Resources:
  
  CreateFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.create
      Runtime: nodejs4.3
      Policies: AmazonDynamoDBFullAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref Table
      Events:
        PostResource:
          Type: Api
          Properties:
            Path: /todo/new
            Method: post

  GetAllFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.getAll
      Runtime: nodejs4.3
      Policies: AmazonDynamoDBReadOnlyAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref Table
      Events:
        GetResource:
          Type: Api
          Properties:
            Path: /todo/all
            Method: get

  # API functions related to active TODO items
  
  GetActiveFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.getActive
      Runtime: nodejs4.3
      Policies: AmazonDynamoDBReadOnlyAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref Table
      Events:
        GetResource:
          Type: Api
          Properties:
            Path: /todo/active
            Method: get

  UpdateActiveFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.updateActive
      Runtime: nodejs4.3
      Policies: AmazonDynamoDBFullAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref Table
      Events:
        PutResource:
          Type: Api
          Properties:
            Path: /todo/active
            Method: put

  # API functions related to completed TODO items
  
  GetCompleteFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.getComplete
      Runtime: nodejs4.3
      Policies: AmazonDynamoDBReadOnlyAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref Table
      Events:
        GetResource:
          Type: Api
          Properties:
            Path: /todo/complete
            Method: get

  MarkCompleteFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.markComplete
      Runtime: nodejs4.3
      Policies: AmazonDynamoDBFullAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref Table
      Events:
        PutResource:
          Type: Api
          Properties:
            Path: /todo/complete
            Method: put

  DeleteCompleteFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.deleteComplete
      Runtime: nodejs4.3
      Policies: AmazonDynamoDBFullAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref Table
      Events:
        DeleteResource:
          Type: Api
          Properties:
            Path: /todo/complete
            Method: delete

  Table:
    Type: AWS::Serverless::SimpleTable
    Properties:
      PrimaryKey:
         Name: todo_id
         Type: String
      ProvisionedThroughput:
         ReadCapacityUnits: 5
         WriteCapacityUnits: 5

시작하기 전에, AWS CLI를 설치하거나 이전에 설치한 버전을 업데이트하세요. 본 포스팅에 사용된 일부 명령은 이전 버전의 AWS CLI에 없을 수 있습니다. AWS CLI와 연결하는 IAM 사용자는 IAM 역할을 생성하는 기능을 포함하는 관리자 권한이 있어야 합니다. Startup Kit Serverless Workload 배포를 시작하려면 GitHub에서 코드의 zip 파일을 다운로드하거나 다음 명령을 사용하여 GitHub 리포지토리를 복제하세요.

git clone https://github.com/awslabs/startup-kit-serverless-workload.git

배포를 계획중인 AWS 리전에서 SAM이 배포 아티팩트(Artifacts)를 넣을 수 있는 기존 Amazon S3 버킷을 가지고 있는지 확인하거나 다음 AWS CLI 명령을 사용하여 새로운 버킷을 만듭니다:

aws s3 mb s3://<your-bucket-name>

다음으로, 간단히 두 개의 AWS CLI 명령을 실행하면 됩니다. 첫 번째 명령인 package의 경우 s3-bucket 인수를 S3 버킷의 이름으로 바꿉니다. 두 번째 명령인 deploy의 경우 template-file 인수를 출력 템플릿 파일의 전체 경로로 바꿉니다.

aws cloudformation package \
--template-file serverless.cfn.yml \
--output-template-file serverless-xfm.cfn.yml \
--s3-bucket <your-bucket-name>
aws cloudformation deploy 
--template-file <path-to-file/serverless-xfm.cfn.yml> \
--stack-name StartupKitServerless \
--capabilities CAPABILITY_IAM

Deploy 명령이 완료되었다고 표시되면, 작업 워크로드가 실행 중인 겁니다! 이 두 명령은 SAM으로 작업할 때 배포 워크 플로(work flow)의 핵심입니다. 예를 들어, 코드를 수정하고 변경 사항을 배포하려는 경우, 패키지를 실행하고 명령을 다시 배포하기 만하면 됩니다. 그런 다음, 워크로드를 테스트하려면 API의 호출 URL을 가져옵니다.다음 bash 코드를 복사하여 터미널에 붙여 넣어 다른 지역 (예 : us-east-1)의 AWS 지역 코드 “us-west-2″를 현재 지역으로 바꾼 다음, 반환하시면 됩니다:

x=`aws cloudformation list-stack-resources --stack-name StartupKitServerless | grep -A2 'AWS::ApiGateway::RestApi' | grep 'PhysicalResourceId' | awk '{print $2}' | tr -d '"' | tr -d ","`; echo "https://$x.execute-api.us-west-2.amazonaws.com/Stage/"

(호출 URL를 가져오는 다른 방법으로는 API Gateway console에서 StartupKitServerless를 선택하고, 왼쪽 탐색 창에서 스테이지를 선택한 다음, 스테이지 목록에서 스테이지를 선택하면, API의 호출 URL이 이제 오른쪽 상단에 나타납니다. 마지막 URL에 ‘/ Stage’를 포함하여 전체 URL을 복사하면 됩니다.) ‘Create API’를 사용하여 일부 TODO 항목을 추가하여 테스트를 시작하세요. 그러면 다음 명령을 사용하여 수행할 수 있습니다:

curl -X POST -H 'Content-Type: application/json' -d '{"todo_id": "1001", "active": true, "description": "What TODO next?"}' https://<invoke-URL-for-your-API>/todo/new

작성한 활성 TODO 항목을 가져 오려면 다음 명령을 실행하세요:

curl https://<invoke-URL-for-your-API>/todo/active

유사한 명령을 사용하여 다른 모든 API 호출을 테스트할 수 있습니다.

AWS SAM 및 서버리스 아키텍처를 사용하는 것은 AWS를 시작하는 가장 쉬운 방법 중 하나입니다. Startup Kit Serverless Workload에 관한 제안, 의견 또는 수정 사항이 있으면 GitHub에 요청해주세요. 앞으로 더 많은 Startup Kit으로 찾아 뵙겠습니다!

이 글은 Introducing the ‘Startup Kit Serverless Workload’의 한국어 번역으로 이창수 AWS 솔루션즈 아키텍트가 번역해 주셨습니다.

AWS SAM Local (베타) – 로컬 기반 서버리스 앱 테스트 및 개발 도구

오늘 신규 서버리스(Serverless) 개발 도구 인 SAM Local 베타 버전을 발표했습니다.이 도구를  통해 로컬에서 쉽게 작성하고 테스트 할 수 있습니다. 이 글에서는 SAM local을 사용하여, 개발자들이 코드 개발 시, 탭 혹은 스페이스 선호도 투표 할 수 있는 빠른  애플리케이션을 빌드, 디버그 및 배포하는 예제를 소개해 드리고자 합니다. AWS는 작년에 Serverless Application Model (SAM)을 소개하고, 이를 통해 서버리스 애플리케이션을 쉽게 배포 할 수 있습니다.  SAM은 AWS CloudFormation을 기반으로 하는 강력한 오픈 소스 기반 인프라 코드 구현 모델 입니다. 로 유지하기가 쉽고 가장 멋진 마스코트를 갖추고 있습니다.

SAM Local은 SAM의 아래와 같은 장점을 로컬 시스템으로 가져와서 사용 가능합니다.

SAM Local을 설치하는 데에는 몇 가지 방법이 있지만 가장 쉬운 방법은 NPM을 사용하는 것입니다. npm install -g aws-sam-local 명령을 사용하거나, 최신 버전을 원하면 github.com/awslabs/aws-sam-local (aws-sam-local  바이너리)에서 설치 가능합니다..

개발자들이 코드 개발 시, 탭 혹은 스페이스 선호도 투표 할 수 있는 빠른  애플리케이션을 API Gateway 및 AWS Lambda를 통해 만든 후, 이를 DynomoDB에 저장합니다. https://SOMEURL/ -d '{"vote": "spaces"}' 같은 간단한 엔드포인트가 될 것이고, 아래와 같은 간단한 SAM 템플릿 파일로 정의할 수 있습니다.

YAML
AWSTemplateFormatVersion : '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
  VotesTable:
    Type: "AWS::Serverless::SimpleTable"
  VoteSpacesTabs:
    Type: "AWS::Serverless::Function"
    Properties:
      Runtime: python3.6
      Handler: lambda_function.lambda_handler
      Policies: AmazonDynamoDBFullAccess
      Environment:
        Variables:
          TABLE_NAME: !Ref VotesTable
      Events:
        Vote:
          Type: Api
          Properties:
            Path: /
            Method: post

그래서  TABLE_NAME이라는 환경 변수를 통해 Lambda 함수에 드러내는 [dynamo_i] 테이블을 생성합니다. 이 템플릿이 유효한지 테스트하기 위해 sam validate를 호출하여, Valid를 반환 받으면 됩니다.

아래는 우리가 사용할 Lambda 함수 코드입니다.

Python
import os
import os
import json
import boto3
votes_table = boto3.resource('dynamodb').Table(os.getenv('TABLE_NAME'))

def lambda_handler(event, context):
    print(event)
    if event['httpMethod'] == 'GET':
        resp = votes_table.scan()
        return {'body': json.dumps({item['id']: int(item['votes']) for item in resp['Items']})}
    elif event['httpMethod'] == 'POST':
        try:
            body = json.loads(event['body'])
        except:
            return {'statusCode': 400, 'body': 'malformed json input'}
        if 'vote' not in body:
            return {'statusCode': 400, 'body': 'missing vote in request body'}
        if body['vote'] not in ['spaces', 'tabs']:
            return {'statusCode': 400, 'body': 'vote value must be "spaces" or "tabs"'}

        resp = votes_table.update_item(
            Key={'id': body['vote']},
            UpdateExpression='ADD votes :incr',
            ExpressionAttributeValues={':incr': 1},
            ReturnValues='ALL_NEW'
        )
        return {'body': "{} now has {} votes".format(body['vote'], resp['Attributes']['votes'])}

이제 로컬에서 테스트 해 봅시다. 실제 DynamoDB 데이터베이스를 만들어야 하고 환경 변수 TABLE_NAME을 통해 해당 데이터베이스의 이름을 제공해야 합니다. env.json 파일을 사용하여 본 작업을 수행 할 수 있습니다. 또는, 명령 줄에서 호출해서 만들 수 있습니다.

$ echo '{"httpMethod": "POST", "body": "{\"vote\": \"spaces\"}"}' |\
TABLE_NAME="vote-spaces-tabs" sam local invoke "VoteSpacesTabs"

Lambda 함수를 테스트하기 위해, sam local generate-event api  API를 사용하여 샘플 이벤트를 생성하고 이를 로컬 호출에 전달할 수 있습니다.  sam local start-api 을 통해 로컬 엔드 포인트를 말아서 모든 것을 테스트 할 수 있습니다.

$ curl -d '{ "vote": "tabs"}'http://127.0.0.1:3000/

그러면 다음과 같이 “tabs now has 12 votes”을 반환합니다.  만약 DynamoDB에 대한 로컬 테스트를 원하시면, DynamoDB Local 을 다운로드하고, 아래와 같이 로컬에서 시작할 수 있습니다.

 java -Djava.library.path =. / DynamoDBLocal_lib -jar DynamoDBLocal.jar -sharedDb

이제 Lambda 함수가 AWS_SAM_LOCAL 환경 변수를 사용하여 어떻게 행동할지 결정할 수 있습니다. 우리 함수를 약간 수정 해 봅시다.

Python
import os
import json
import boto3
if os.getenv("AWS_SAM_LOCAL"):
    votes_table = boto3.resource(
        'dynamodb',
        endpoint_url="http://docker.for.mac.localhost:8000/"
    ).Table("spaces-tabs-votes")
else:
    votes_table = boto3.resource('dynamodb').Table(os.getenv('TABLE_NAME'))

이제는 로컬 엔드 포인트를 사용하여 로컬 데이터베이스에 연결하므로 무선 랜 없이도 쉽게 작업 할 수 있습니다.

SAM local은 대화형 디버깅을 지원합니다. Java 및 Node.js에서 -d 플래그와 포트를 전달하여 디버거를 즉시 사용할 수 있습니다. 파이썬의 경우 import epdb; 와 같은 라이브러리를 사용할 수 있습니다. epdb.serve() 를 호출하고, sam local invoke -d 8080 "VoteSpacesTabs" 를 통해 디버거를 단계별로 실행하게 됩니다.

이제 먼저 aws cloudformation package의 별칭인 sam package 명령을 호출 한 다음이 명령의 결과를 sam deploy에 사용합니다.

$ sam package --template-file template.yaml --s3-bucket MYAWESOMEBUCKET --output-template-file package.yaml
Uploading to 144e47a4a08f8338faae894afe7563c3  90570 / 90570.0  (100.00%)
Successfully packaged artifacts and wrote output template to file package.yaml.
Execute the following command to deploy the packaged template
aws cloudformation deploy --template-file package.yaml --stack-name 
$ sam deploy --template-file package.yaml --stack-name VoteForSpaces --capabilities CAPABILITY_IAM
Waiting for changeset to be created..
Waiting for stack create/update to complete
Successfully created/updated stack - VoteForSpaces

이를 통해 API Gateway가 만들어집니다.

아래는 서비스가 라이브가 된 모습입니다. http://spaces-or-tabs.s3-website-us-east-1.amazonaws.com/

SAM Local 을 사용하면 서버리스 애플리케이션을 쉽게 테스트, 디버그 및 배포 할 수 있습니다. 본 소스 코드에 공헌하시려면, CONTRIBUTING.md 가이드 문서를 참고해 주시고, 좀 더 자세한 것은 기술 문서를 참고해 주시기 바랍니다.

Randall

이 글은 New – AWS SAM Local (Beta) – Build and Test Serverless Applications Locally의 한국어 번역 편집입니다.

Amazon GameLift를 통한 맞춤형 서버리스 매치메이킹 서비스 만들기

세션 기반의 멀티플레이어 게임에서 가장 중요한 요소의 하나는 사용자의 숙련도, 접속 속도, 위치 등의 제약에서 벗어나면서 효율적이고 지능적으로 사용자들에게 재미있고 도전할만한 게임 매치를 제공할 수 있는지 여부일 것입니다. 시스템은 이전의 모든 경기 이력을 바탕으로 안정적이고 유연하게 성공적인 멀티플레이어 경험을 제공하는 것이 목표입니다.

2017년 GDC(Game Developers Conference)에서 Chris Byskal과 Geoff Pare는 Amazon GameLift를 통하여 내구성 있는 온라인 게임을 만드는 것에 대한 세션을 진행 했었습니다. 여기에서 Chris와 Geoff는 GameLift롤 통하여 클라우드 환경에서 다양한 형태의 게임을 구성하는 과정을 단순화 할 수 있는지를 이야기했습니다. GameLift를 통하여 어떤 방법으로 수천 시간의 개발 시간을 줄이고, 유휴 서버를 줄이고, DDoS공격에서 보호하고, 그리고 매치메이킹과 자동화된 스케일링을 지원할 수 있는지를 설명했습니다.

이 블로그 글은 Chris와 Geoff의 발표에서 거론되었던 플레이어 매치 메이킹의 패턴에 대하여 좀 더 자세히 살펴보고, 그리고 게임에 따라 독자적으로 사용할 수 있는 사용자 사이의 매치메이킹 알고리즘, 그리고 사용자들을 서버에 연결할 수 있는 아키텍쳐를 살펴볼 것입니다.  덤으로, 실제 여러분의 게임에서 사용할 수 있는 사용자 정의 맞춤형 매치메이킹 코드 예제를 살펴보도록 하겠습니다.

이러한 형태의 서버리스 접근 방법은 많은 장점을 가지고 있습니다. 전통적인 환경에서 접할 수 있는 (다른 회사와 비교해서 차별화되지 않는) 통상업무 부담을 줄여줄 수 있습니다. 그리고 복잡한 백앤드의 구축을 단순화하여 게임 로직 자체에 집중 할 시간을 늘려 준다는 점이 가장 중요하다고 할 수 있습니다.

플레이어 매칭 패턴에 대하여
최근의 멀티 플레이어 게임은 크게 두가지 경향을 보이고 있습니다. 첫번째는 사용자가 직접 접속할 서버를 찾아서 선택하는 방법, 두번째는 매치 메이킹 서버를 통하여 자동으로 여러 사용자들을 연결해주는 형태입니다.

사용자가 직접 서버를 선택하는 방법은 구현하기가 상대적으로 간단합니다. 사용자에게 게임을 할 수 있는 서버의 목록을 전달하는 것이 전부입니다.

Game Server Browser Example

그림-1 : 서버 목록 찾기의 예제

만일 개발자가 이러한 형태로 구현할 경우, GameLift는 다음의 3가지 API콜을 이용하여 클라이언트에서 이러한 방법을 쉽게 구현 할 수 있는 몇 가지 방법을 제공하고 있습니다.

  • 게임 서버의 목록 취득 – GameLift는 사용자가 지정하는 검색 항목을 사용한 검색을 지원합니다. 서버 브라우징을 사용 하는 경우, 모든 게임 세션을 검색 결과로 보여주거나 현재 사용 가능한 세션만 결과로 보여줄 수가 있습니다. 더욱 자세한 사항은 해당 API문서를 참고하시면 됩니다. (Amazon GameLift SearchGameSessions() API documentation)
  • 지정한 게임에 참가 – 사용자는 자신이 속한 그룹이나 길드와 함께 특정한 게임에 참가하는 것이 가능합니다. 일단 사용자가 게임 세션을 지정하면 시스템은 그 사용자를 해당 게임에 참가 시킵니다. 만일 게임 세션에 추가로 참가 할 수 있는 여유가 있으면 GameLift가 해당 슬롯들을 선점하여 해당 정보를 전달하게 됩니다. 이러한 방법으로 사용자가 게임 세션을 선택하면, 참가 신청을 하는 순간 모든 세션이 가득 찰 수도 있게 됩니다. 좀 더 자세한 사항은 관련 문서를 참고하시기 바랍니다. (Amazon GameLift CreatePlayerSession() API Reference.)
  • 새로운 게임 시작 – GameLift는 사용자 요청에 의하여 새로운 게임 세션을 만들 수도 있습니다. 생성이 되면 해당 게임 세션은 서버 목록에서 공개적으로 검색이 될 수 있습니다. 사용자는 또한 공개되지 않는 비공개 게임 세션을 만들 수도 있습니다. 자세한 사항은 관련 문서를 참고 하시기 바랍니다. (Amazon GameLift CreateGameSession() API Reference)

서버 검색 방식은 간단하고 사용자들이 직접 목록에서 원하는 게임을 선택할 수 있는 기회를 제공합니다. 또한 개발자들에게도 구현이 간단하다는 장점이 있습니다. 하지만 이러한 간단하고 직관적인 형태로는 사용자들에게 최적의 게임 경험을 제공 할 수 없을 수도 있습니다. 사용자의 팀/ 숙련도, 또는 기타 게임의 중요한 요소들을 고려하지 않는 매치들은 균형 잡히지 않은 일방적인 게임진행으로 참가한 모든 이들에게 즐겁지 않은 경험만 남길 수도 있습니다.

서버 검색 방식은 또한 여러분의 게임 인프라를 전체적으로 균형 잡힌 활용을 어렵게 할 수 있습니다. 왜냐하면 사용자들은 인프라의 상태를 고려할 수 없고 이로 인하여 특정 지역의 서버에 몰리는 현상을 가져올 수 있기 때문입니다. 이는 결과적으로 인프라 전반적으로 사용자 분배를 어렵게 하고, 또한 불필요하게 높은 비용을 가져다 줄 수 있습니다.

매치메이킹은 다른 접근법을 활용합니다. 사용자가 게임에 참가 요청을 하면 매치메이킹 알고리즘을 통하여 다양한 변수 – 사용자의 숙련도, 서버 레이턴시, 친구목록, 팀/ 그룹등 – 를 고려하여 매치를 선택해줍니다. 사용자들은 따라서 조금 더 자신과 비슷한 실력의 상대와 게임을 즐길 수 있습니다.

또한 이 방법은 사용자들을 게임 서버 사이에 더더욱 효율적으로 분배 할 수 있고 효율적인 세션 활용을 통하여 운영비용을 줄일 수가 있습니다. 매치메이킹의 단점은 구현이 더욱 복잡하다는 점입니다.

서버리스로 매치메이킹 시스템 만들기
매치매이킹을 사용하기로 결정하면 가장 먼저, 매치메이킹 시스템을 만들어야 합니다. 여기에서는 간단하게 서버리스로 맞춤형 메치메이킹을 어떻게 구현할 수 있는지를 살펴보도록 하겠습니다. 아래의 그림 2의 간단한 아키텍쳐를 그리고 있습니다. 이 아키텍쳐 안에는

  • 사용자 정의 변수, 또는 알고리즘을 사용한 매치메이킹 시스템
  • 게임서버 관리
  • 게임세션 관리
  • 서버 인스턴스의 오토스케일링
  • 게임 연결 흐름도

들을 보여주고 있습니다.

이 서버레스 매치메이킹 시스템은 크게 3단계로 구현되고 있습니다.

Serverless Custom Matchmaking Example Architecture

그림 2 – 서버레스로 구현한 맞춤형 매치메이킹 아키텍쳐

 

  1. 게임 참가 요청
    첫번째 단계에서 사용자는 게임 클라이언트를 통하여 게임 참가 요청을 합니다. 게임 클라이언트는 Amazon API Gateway의 엔드포인트를 호출합니다. 이 엔드포인트는 우리의 매치메이킹 로직을 실행하는 람다함수를 호출하고, 이 람다 함수는 게임리프트와 연동하여 적합한 게임 세션을 찾아줍니다. API게이트웨이는 개발자들이 API를 만들고 안전하게 관리할 수 있도록 도와주는 관리형 서비스입니다. API게이트웨이를 사용하는 것은 게임 클라이언트와 람다함수/ 게임리프트사이를 추상화 할 수 있기 때문입니다. 이는 아래와 같은 상황에 대한 유연성을 가져다 줍니다.

    • 버전관리 – 게임 클라이언트는 백앤드의 변화에 대하여 종속될 필요가 없습니다. 이는 몇가지 장점을 가지는데, 새로운 기술을 적용하기 쉬워집니다. 또한 새로운 게임리프트의 적용을 부드럽게 진행할 수 있습니다, 그리고 A-B테스팅을 쉽게 적용할 수 있습니다.
    • 운영 메트릭 확보 – API 게이트웨이와 Amazon CloudWatch를 함께 활용하여 제작하는 API의 퍼포먼스의 확인으로 매치메이킹 서비스에서 발생할 수 있는 다양한 문제들을 빨리 파악할 수 있도록 도와줍니다.
    • 보안 – API 게이트웨이와 함께 Amazon Cognito와 같은 AWS의 다양한 보안 도구를 활용하여 API의 활용을 인증을 거친 활용의 제어를 손쉽게 활용할 수 있습니다. 이를 통하여 손쉽게 구현하고 관리 할 수 있는 인증 시스템을 제공 할 수 있습니다.
  2. 게임 찾기
    두번째 단계에서 우리는 AWS람다(AWS Lambda) 함수를 활용하여 매치메이킹을 구현할 것입니다. 람다를 통하여 서버를 할당하거나 관리할 필요없이 여러분의 코드를 클라우드상에서 실행할 수 있습니다. 람다에 코드를 배포하는 것은 여러분의 코드를 단순히 업로드 하는 것으로 구현됩니다. 람다는 이후, 코드의 실행과 스케일링에 필요로 하는 여러사항들을 자동으로 관리하게 됩니다. 여러분의 코드는 또한 다양한 AWS서비스에서 호출되거나 다른 웹서비스, 앱에서 호출될 수 있습니다. 매치메이킹은 실행시간이 짧고 비교적 자주 호출 되기 때문에 이러한 환경에서 상당히 효율적인 방법일 수가 있습니다. 서버 관리는 최소한으로 유지하면서 반대로 가용성은 최대로 유지됩니다. 람다의 사용료는 호출횟 수, 그리고 각 호출에서 실행 시간 100ms당 책정됩니다. 여러분은 또한 여러 버전의 프로세스를 함께 실행할 수도 있습니다. 이를 통하여 폭 넓은 게임클라이언트와 많은 사용자들을 지원할 수도 있습니다. 이러한 점을 염두에 두고 3가지 람다 함수를 만들어보겠습니다.

    • 매치 메이킹에 들어가기 – 이 함수는 게임 클라이언트로부터의 게임 참가 요청을 처리합니다. 이 함수는 요청을 받고, 동시에 클라이언트로부터 전달되는 필요 정보를 파악합니다. 그리고 이 정보들을 아마존DynamoDB(Amazon DynamoDB)의 게임 참가 대기자 테이블에 추가합니다. 이 함수는 그리고 클라이언트에게 매치메이킹이 진행중이라고 알려줍니다. (그리고 클라이언트는 사용자에게 그 사실을 전달하게 됩니다.)
    • 메치메이커 – 이 함수는 주기적으로 실행되어 매칭할 수 있는 플레이어 그룹을 생성하고 그 그룹들이 새로운 게임 세션에 참가할 수 있도록 해줍니다. 여기에서 게임의 매치메이킹로직이 적용됩니다. 이 함수가 호출될 때마다 아까 만들었던 테이블의 대기자 사이에서 로직을 적용하여 가까운 그룹으로 분류합니다. 온전한 그룹이 만들어지면 해당 그룹은 게임 세션에 참가 가능하다고 분류됩니다. 함수는 이 정보를 아까의 DynamoDB테이블에 기록하고 종료됩니다. 아래의 그림 3에 이러한 로직에 대한 예제 코드가 있습니다.
    • 서버 접속기 – 이 함수는 정기적으로 게임 서버에 할당할 수 있는 그룹을 확인하고, 게임 세션 생성 요청을 합니다. 이는 게임리프트의 CreateGameSession API를활용합니다.
Python
def get_unmatched_players():
        table = dynamodb.Table(table_name)
        response = table.scan(
            FilterExpression=Attr('MatchStatus').eq('Open')
        )
        players = response['Items']
        
        print("Number of players watching for matches: " + str(len(players)))
        
        return players
        
def create_groups(players):
    print('Creating Groups')
    groups = list()
    
    # Sort players by skill
    players = sorted(players, key=lambda player: player['Skill'])
    
    # Group players into match sized groups
    while (len(players) >= match_size):
        new_group = {'Players': list()}
        for i in range(0, match_size):
            new_group['Players'].append(players.pop(0))
            
        groups.append(new_group)

    print("Number of groups created: " + str(len(groups)))
    
    return groups

그림 3 – 매치메이킹 로직의 파이썬 예제

게임 서버 할당을 통하여, Amazon GameLift는 알고 있는 리전의 여러 서버 Fleet들 중에서 가장 적당한 호스팅 리소스를 할당합니다. 또한 새로운 게임 세션을 생성하여 앞의 그룹을 할당할 수 있습니다.

게임리프트에서 새로운 세션 할당 요청은 (game session queue)에 할당됩니다. 따라서 우리는 하나, 또는 그 이상의 서버 Fleet를(어떤 지역에 있어도 상관없습니다) 가지고 있는 큐를 만들고, 더불어 요청에 대하여 어느정도의 시간을 쓸지를 결정하는 타임아웃 수치를 지정합니다.

할당 요청을 처리할 때, 게임리프트는 큐에 할당 되어있는 모든 Fleet 대상으로 요청에 적합한지 살펴보고 응답하게 됩니다. 만일 적합한 Fleet이 없어서 판단하지 못할 경우 타임아웃이 발생하게 됩니다. 기본적으로 게임 리프트는 큐 구성에 나열 되어있는 순서대로 Fleet들을 살펴봅니다. 이를 통하여 새로운 게임 서버 구성 요청에 대하여 각 Fleet에 대한 우선도를 지정할 수도 있습니다.

아주 낮은 지연속도가 필요로 하는 게임의 경우, 게임리프트는 지연속도 정보를 바탕으로 그룹의 모든 사용자에 대하여 가장 낮은 평균 지연을 경험할 수 있는 지역으로 할당 할 수도 있습니다.

이러한 기능을 활용하기 위해서는 우리는 클라이언트로부터 모든 지역에 대한 지연 속도 정보를 모아야 합니다. 여러 사용자로부터 지연 속도 정보를 받으면, 게임 리프트는 큐의 서버 Fleet정보를 평균 Lag이 낮은 순서로 우선 순위를 변경하게 됩니다.

이 부분에 대한 자세한 내용은 이전의 블로그 글을 참고하세요

그림 4의 코드는 게임 세션 할당 요청에 대한 예제 코드입니다. 코드의 StartGameSessionPlacement() 함수는 큐 이름을 전달 받습니다. (이 큐 이름은 큐 구성에서 지정한 것입니다.)

게임리프트는 또한 고유한 할당 ID를 필요로 합니다. 우리는 이 ID를 활용하여 요청의 상태를 추적하게 됩니다. 개발자가 할당 ID를 정의하면 되고, 단지 상호간의 고유성만 보장되면 됩니다. 아래의 예제에서는 UUID를 사용하며, 호출자에게 전달되어 이후 처리됩니다.

부가적으로, 우리의 할당 요청은 세션의 게임과 플레이어 ID를 요청할 수도 있습니다. 만일 해당 정보가 전달되면, AWS콘솔을 통하여 게임 세션들을 사용자가 보는 것처럼 확인할 수 있습니다. 이를 통하여 언제 얼마나 사용자들의 활동이 있는 지를 확인할 수가 있습니다.

새로운 게임 세션 할당은 PENDING 상태로 만들어집니다. 아래의 예제 코드는 할당 요청에 대한 응답을 표시하게 되어있습니다. 할당 요청의 결과 상태에 따라서 추후 작업도 진행할 수 있습니다. 예를 들어 만일 PENDING 응답이 전달되면, 우리는 게임 클라이언트에게 곧 세션이 시작됨을 알리고 이후의 상태 확인 상태로 들어갈 수 있습니다. 만일 할당 요청이 타임 아웃이 발생하면 다른 큐를 통하여 할당 요청을 다시 보낼 수가 있을 것입니다.

Python
def start_game_placement(queue_name, group):
    print("Starting Game Session Placement")
    
    placement_id = str(uuid.uuid4())

    desiredPlayerSessions = list()

    for player in group['Players']:
        desiredPlayerSessions.append({ 
                'PlayerId':  player['PlayerId'],
                'PlayerData':  player['Skill']
        })

    response = gamelift.start_game_session_placement(
	    PlacementId=placement_id,
	    GameSessionQueueName=queue_name,
	    GameProperties=[
	        {
	            'Key': 'Skill_Level',
	            'Value': 'Highest'
	        },
	    ],
	    MaximumPlayerSessionCount=match_size,
	    GameSessionName='My Matched MP Game',
        DesiredPlayerSessions= desiredPlayerSessions
	)

    print("Game Session Status: " + response['GameSessionPlacement']['Status'])
    
    return placement_id
    
def update_players_in_group_for_match(group):
    for player in group['Players']:
        update_player(player, group['PlacementId'], 'Matched')
    
def update_player(player, placement_id, status):
    print('Updating Player with Placement Id and setting status to Matched')
    
    table = dynamodb.Table(table_name)
    
    response = table.update_item(
        Key={
            'PlayerId': player['PlayerId'],
            'StartDate': player['StartDate']
        },
        UpdateExpression="set PlacementId = :g, MatchStatus= :t",
        ExpressionAttributeValues={
            ':g': placement_id,
            ':t': status
        },
        ReturnValues="UPDATED_NEW"
    )

 

그림 4 –게임리프트의 세션 할당의 예제 파이썬 코드

  1. 게임에 접속하기
    세번째 단계에서 게임 클라이언트는 람다 함수와 게임리프트를 통하여 게임 세션에 관련한 상세한 정보를 수령합니다. 게임 클라이언트들은 이제 게임 서버에 직접 접속하여 게임을 시작할 수가 있습니다. 게임 클라이언트가 게임 서버에 직접 연결한다는 점은, 게임리프트가 게임 진행 자체에 어떠한 레이턴시도 더하지 않는다는 것을 의미합니다.

결론
멀티플레이어 게임은 계속해서 인기를 누리고 있습니다. 이러한 환경에서 성공하기 위해서는 빠르고, 부드러운 확장성과 함께 수백만 사용자들이 선호할 수 있는 높은 수준의 안정성을 지원 해야할 것입니다.

많은 멀티플레이어 게임은 개성적인 매치메이킹을 통하여 비슷한 수준의 사용자들과 함께 게임을 진행하는 최적의 경험을 제공할 수 있습니다. 많은 장르의 게임 사용자들은 자신과 유사한 수준의 상대와 수준 높은 매체메이킹을 기대하게 됩니다. 따라서 여러분의 게임의 성공을 위해서 매치메이킹은 아주 중요한 요소일 것입니다. 여기에서 거론된 서버리스 매치메이커 패턴은 여러분이 원하는 알고리즘을 활용하면서, 동시에 아마존의 게임리프트를 활용하여 여러분의 서버 리소소를 적극적으로 활용할 수 있는 가능성을 제시하고 있습니다.

게임리프트 세션 할당 기능은 위 예제에서 보여준 매치메이킹 방식을 지원하는 적합한 방법이며, 사용자에게 최고의 경험을 전달할 수 있습니다. 그리고 더불어 관리형 서비스의 하나로 게임리프트는 서버 Fleet의 유지관리를 전담하게 됩니다.

사용자의 수요에 따라서 자동적으로 용량을 조절하고 사용한 만큼 비용을 청구하게 됩니다. 이를 통하여 사용자에게 직접 영향을 주지 않으면서 비용 관리를 할 수 있도록 도와줍니다. 게임리프트는 또한 동시에 여러 버전의 Fleet들 을 동시에 구동하고 이들 사이를 Alias를 통하여 전환할 수 있도록 해줍니다. 이를 활용하기 위해서 필요한 SDK는 게임리프트 SDK(Amazon GameLift Server SDK)입니다. 관리는 관리 콘솔(AWS Management ConsoleAWS CLI), 또는 게임리프트 API(Amazon GameLift APIs)를 통하여 진행할 수 있습니다. (C++, C#, 그리고 몇가지 다른 언어로 제공됩니다.)

게임리프트는 미지의 수요에 대하여 걱정 없이 대응할 수 있는 기반을 제공하고 있으며, 이는 여러 개발자들이 독특하고 차별화된 게임 경험 그 자체에 집중할 수 있는 환경을 제공합니다. 이 서버리스 매치케이킹 패턴은 많은 사용자가 몰리더라도 유연하고 확장 가능한 백-엔드를 제공하며 인프라에 대한 많은 관리 부담을 줄여줄 수 있습니다. 결과적으로 게임 개발자, 운영자의 부담을 줄여주고 여러분의 게임을 즐기는 고객들에게 좋은 게임 경험을 제공할 수 있습니다.

피터 챕맨(Peter Chapman)은 Amazon Gamelift, Lumberyard 팀의 솔루션스 아키텍트입니다. 그는 12년 이상의 소프트웨어 개발 및 아키텍쳐경험을 가지고 있습니다. 게이밍 뿐만 아니라 건강/ 소매 다양한 분야에서 솔루션을 디자인한 경험을 가지고 있습니다. 이 글은 아마존웹서비스 코리아의 솔루션즈 아키텍트가 국내 고객을 위해 전해 드리는 AWS 활용 기술 팁을 보내드리는 코너로서, 김성수 솔루션즈 아키텍트께서 작성해주셨습니다.

AWS Step Functions 및 Amazon API Gateway 연동을 통한 서버리스 기반 승인 기능 구현하기

AWS Step Functions을 사용하는 가장 일반적인 사례는 프로그램 중에 사람이 개입해서 뭔가 승인해야 할 때입니다 (예: 회원 가입 시 이메일 승인 프로세스). Step Functions을 사용하면 상태 머신 이라고 하는 시각적 워크플로에서 일련의 단계별 분산 응용 프로그램 구성 요소를 쉽게 조정할 수 있습니다. 상태 머신을 신속하게 빌드 및 실행하여 응용 프로그램 단계를 안정적이고 확장성 높은 방식으로 실행할 수 있습니다.

이 글에서는 수동 승인 단계를 구현하기 위한 서버리스 디자인 패턴을 설명합니다. Step Functions 활동 작업(Activity Task)를 사용하여 나중에 결정을 내린 사람이 승인 또는 거부를 알려주는 고유한 토큰을 생성 및 반환할 수 있습니다.

기능 구현 단계 소개
Step Functions 상태 머신이 활동 작업 상태로 실행 되면, Step Functions은 활동(Activity)을 스케줄하고 활동 작업자(Activity Woker)를 기다립니다. 활동 작업자는 GetActivityTask를 호출하여 활동 작업을 가져오는 응용 프로그램 입니다. 작업자가 API 작업을 성공적으로 호출하면, 해당 작업자는 콜백 토큰을 포함하는 JSON blob로 작업을 보냅니다.

이 시점에서 상태를 포함한 실행 작업 상태 및 실행 분기가 일시 중지됩니다. 상태 머신에 타임아웃이 지정되어 있지 않으면,  활동 작업 상태는 활동 작업자가 vended 토큰을 사용하여 SendTaskSuccess 또는 SendTaskFailure를 호출 할 때까지 대기합니다. 이러한 일시 중지 기능이 수동 승인 단계를 구현하는 첫 번째 열쇠입니다.

두 번째 열쇠는 서버리스 환경에서 작업을 가져 오는 코드를 분리하고, 토큰을 공유 할 수 있는 한 완료 상태로 응답하고 토큰을 되돌려 보내는 코드에서 토큰을 가져 오는 기능입니다. 여기서 작업자는 단일 활동 작업 상태에 의해 관리되는 서버리스 응용 프로그램입니다.

이를 통해 일정에 따라 호출된 AWS Lambda 함수를 사용하여 활동 작업자를 구현합니다. 이 작업자는 승인 단계와 관련된 토큰을 획득하고, Amazon SES를 사용하여 승인자에게 이메일을 보냅니다.

직접 토큰을 리턴하는 응용 프로그램에서 Step FunctionsSendTaskSuccessSendTaskFailure API를 직접 호출 할 수 있기 때문에 매우 편리합니다. 이메일 클라이언트 또는 웹 브라우저가 토큰을 단계 기능으로 반환 할 수 있도록 Amazon API Gateway를 통해 이러한 두 가지 작업을 제공 하면, 보다 쉽게 작업을 수행 할 수 있습니다. 토큰을 가져 오는 람다 함수와 API 게이트웨이를 통해 토큰을 반환하는 응용 프로그램을 결합하여 서버리스 수동 승인 단계를 구현할 수 있습니다 (아래 그림 참조).

수동 승인이 필요한 상태가 되면, Lambda 함수는 승인 및 거부를 위해 두 개의 하이퍼링크가 포함 된 전자 메일을 준비하여 사용자에게 보냅니다.

권한이 부여 된 사용자가 승인(approval) 하이퍼 링크를 클릭하면 상태가 성공합니다. 사용자가 거절(reject) 링크를 클릭하면 상태가 실패합니다. 또한, 승인에 대한 시간 제한을 설정하도록 선택할 수 있으며, 제한 시간이 지나면 활동 작업 상태에서 재시도/처리 조건을 사용하여 이메일 요청을 재전송 하는 등의 조치를 취할 수 있습니다.

사례: 직원 승진 프로세스 승인
본 서버리스 애플리케이션 패턴의 하나로 이메일을 통해 관리자의 승인을 받는 것과 같은 기능을 포함하는  직원 승진 프로세스를 설계할 수 있습니다. 직원이 승진 후보로 정해되면, 새로운 Step Functions 실행이 시작됩니다. 직원의 이름과 직원 매니저 이메일 주소를 최초 제공합니다.

본 디자인 패턴을 사용하여 수동 승인 단계를 구현하고, SES를 사용하여 이메일을 관리자에게 보냅니다. 태스크 토큰을 획득 한 후, Lambda 함수는 API 게이트웨이가 제공하는 URI에 대한 하이퍼 링크가 포함 된 전자 메일을 생성하여 관리자에게 전송합니다.

본 사례에서는 IAM 역할을 만들 수 있도록 계정 관리 권한이 필요합니다.  또한, SES에 이메일 주소를 이미 등록 했으므로 주소가 보낸 사람/받는 사람으로 이메일을 보낼 수 있습니다. 자세한  정보는 Amazon SES로 전자 메일 보내기를 참조하십시오.

아래와 같은 단계로 서버리스 애플리케이션을 구현해 보겠습니다.

  1. 활동(Activity) 만들기
  2. 상태 머신(State Machine) 만들기
  3. API 생성 및 배포
  4. 활동 작업자 람다 함수 만들기
  5. 프로세스 테스트

단계 1: 활동 만들기
Step Functions 콘솔에서 Task를 선택하고, ManualStep이라는 활동을 작성하십시오.

stepfunctionsfirst_1.png

본 활동의 ARN을 저장해 두시기 바랍니다. (나중에 사용 예정)

stepfunctionsfirst_2.png

단계 2. 상태 머신 만들기
Step Functions 콘솔에서 승진 프로세스를 모델링하는 상태 머신을 만듭니다. 콘솔에서 기본 생성된 IAM 역할 인 StatesExecutionRole-us-east-1을 사용합니다. 상태 머신의 이름에 PromotionApproval를 지정하고 다음 코드를 사용합니다. Resource의 값을 위의 활동 ARN으로 바꾸십시오.

JavaScript
{
  "Comment": "Employee promotion process!",
  "StartAt": "ManualApproval",
  "States": {
    "ManualApproval": {
      "Type": "Task",
      "Resource": "arn:aws:states:us-east-1:ACCOUNT_ID:activity:ManualStep",
      "TimeoutSeconds": 3600,
      "End": true
    }
  }
}

단계 3. API 생성 및 배포
API 게이트웨이를 사용하여 SendTaskSuccess 또는 SendTaskFailure API 작업을 호출하기 위한 공용 URI를 만들고 배포합니다.

먼저, IAM 콘솔로 이동하여 API 게이트웨이가 Step Functions을 호출하는 데 사용할 수 있는 IAM 역할을 만듭니다. 역할 이름을 APIGatewayToStepFunctions로 지정하고 역할 유형으로 Amazon API 게이트웨이 를 선택한 다음 역할을 만듭니다.

IAM 역할을 만든 후, AWSStepFunctionsFullAccess 관리 정책을 추가하십시오.

stepfunctionsfirst_3.png

API 게이트웨이 콘솔에서 StepFunctionsAPI라는 새 API를 만듭니다. 성공(success) 및 실패(fail)이라는 루트 (/) 아래에 두 개의 새 리소스를 만들고 각 리소스에 대해 GET 메서드를 만듭니다.

stepfunctionsfirst_4.png

이제 각 메소드를 구성해야합니다. /fail GET 메소드를 선택하고, 다음 빙식으로 구성하십시오.

  • Integration type: AWS Service 선택
  • AWS Service: Step Functions 선택
  • HTTP method: POST 선택
  • Region: 여러분이 원하는 리전을 선택합니다. (참고. 아직 Step Functions이 지원되는 리전은 AWS Region Table에서 참고하세요.)
  • Action Type: SendTaskFailure 추가
  • Execution: APIGatewayToStepFunctions 역할의 ARN 값 입력

stepfunctionsfirst_5.png

URI를 통해 taskToken을 전달하려면 Method Request 섹션으로 이동하고 taskToken 이라는 URL Query String 매개 변수를 추가하십시오.

stepfunctionsfirst_6.png

Integration Request 섹션으로 이동하여 application/json 유형의 Body Mapping Template을 추가하여 쿼리 문자열 매개 변수를 요청 본문에 삽입합니다. 보안 경고에서 제안한 변경 사항을 허용합니다. When there are no templates defined (Recommended) 본문 패스 동작을 설정합니다. 아래 코드는 이러한 매핑을 수행합니다.

JavaScript
{
   "cause": "Reject link was clicked.",
   "error": "Rejected",
   "taskToken": "$input.params('taskToken')"
}

그런 다음, Save을 눌러 저장합니다.

다음에는 /success GET 메서드를 구성합니다. 구성은 /fail GET 메소드와 매우 유사합니다. 유일한 차이점은 Action입니다. SendTaskSuccess를 선택하고 다음과 같이 매핑을 설정하십시오.

JavaScript
{
   "output": "\"Approve link was clicked.\"",
   "taskToken": "$input.params('taskToken')"
}

API 작업을 구성한 후 API 게이트웨이 콘솔의 마지막 단계는 respond 이라고하는 새로운 단계에 API 작업을 배포하는 것입니다. GET 메소드 중 하나에서 Invoke URL 링크를 선택하여 API를 테스트 할 수 있습니다. 토큰이 URI에 제공되지 않으므로 ValidationException 메시지가 표시되어야 합니다.

stepfunctionsfirst_7.png

단계 4: 활동 작업자를 위한 Lambda 함수 만들기
Lambda 콘솔에서 Node.js 4.3 런타임에 대한 신규 템플릿을 활용하여 CloudWatch Events Schedule 트리거로 람다 함수를 만듭니다. Schedule expression에 입력하는 값은 활동 비율입니다. 이것은 활동 진행 시간이 계획되는 비율보다 커야합니다.

안전 마진(safety margin)은 활동이 계획되지 않은 동안 발생하는 토큰 손실, 재시도 활동 등을 설명합니다. 예를 들어, 승진 액션이 3 번이 발생할 것으로 예상되는 경우, 특정 한 주 동안 하루에 네 번 람다 함수를 실행하도록 예약 할 수 있습니다. 또는, 단일 람다 함수가 여러 활동을 병렬 또는 직렬로 실행될 수 있습니다. 이 때는 분당 1 회의 속도를 사용하지만 트리거는 아직 사용하지 않도록 설정합니다.

stepfunctionsfirst_8.png

이제 Node.js 4.3 코드를 사용하여 Lambda 함수 ManualStepActivityWorker를 만듭니다. 이 함수는 StepTunction에서 taskToken, employee 이름 및 manager 이메일 정보를 수신합니다. 이들 정보를 이메일에 포함시키고 이메일을 관리자에게 보냅니다.

JavaScript

'use strict';
console.log('Loading function');
const aws = require('aws-sdk');
const stepfunctions = new aws.StepFunctions();
const ses = new aws.SES();
exports.handler = (event, context, callback) => {
    
    var taskParams = {
        activityArn: 'arn:aws:states:us-east-1:ACCOUNT_ID:activity:ManualStep'
    };
    
    stepfunctions.getActivityTask(taskParams, function(err, data) {
        if (err) {
            console.log(err, err.stack);
            context.fail('An error occured while calling getActivityTask.');
        } else {
            if (data === null) {
                // No activities scheduled
                context.succeed('No activities received after 60 seconds.');
            } else {
                var input = JSON.parse(data.input);
                var emailParams = {
                    Destination: {
                        ToAddresses: [
                            input.managerEmailAddress
                            ]
                    },
                    Message: {
                        Subject: {
                            Data: 'Your Approval Needed for Promotion!',
                            Charset: 'UTF-8'
                        },
                        Body: {
                            Html: {
                                Data: 'Hi!<br />' +
                                    input.employeeName + ' has been nominated for promotion!<br />' +
                                    'Can you please approve:<br />' +
                                    'https://API_DEPLOYMENT_ID.execute-api.us-east-1.amazonaws.com/respond/succeed?taskToken=' + encodeURIComponent(data.taskToken) + '<br />' +
                                    'Or reject:<br />' +
                                    'https://API_DEPLOYMENT_ID.execute-api.us-east-1.amazonaws.com/respond/fail?taskToken=' + encodeURIComponent(data.taskToken),
                                Charset: 'UTF-8'
                            }
                        }
                    },
                    Source: input.managerEmailAddress,
                    ReplyToAddresses: [
                            input.managerEmailAddress
                        ]
                };
                    
                ses.sendEmail(emailParams, function (err, data) {
                    if (err) {
                        console.log(err, err.stack);
                        context.fail('Internal Error: The email could not be sent.');
                    } else {
                        console.log(data);
                        context.succeed('The email was successfully sent.');
                    }
                });
            }
        }
    });
};

이제 Lambda function handler and role 항목에서 Role에 대해서는 Create a new role을 선택하고 LambdaManualStepActivityWorkerRole를 생성합니다.

stepfunctionsfirst_9.png

IAM 역할에 두 개의 정책을 추가합니다. 하나는 Lambda 함수가 Step Functions를 호출하여 GetActivityTask API 조치를 호출하고 SES를 호출하여 이메일을 보내도록 허용하는 것입니다. 결과는 다음과 같습니다.

JavaScript
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": "states:GetActivityTask",
      "Resource": "arn:aws:states:*:*:activity:ManualStep"
    },
    {
      "Effect": "Allow",
      "Action": "ses:SendEmail",
      "Resource": "*"
    }
  ]
}

또한, GetActivityTask API 동작이 60 초 제한 시간으로 롱 폴링(long-polling)을 수행하므로 람다 기능의 제한 시간을 1 분 15 초로 늘립니다. 이를 통해 함수가 활동이 사용 가능하게 될 때까지 기다릴 수 있으며, SES에 이메일을 보내도록 여분의 시간을 제공합니다. 다른 모든 설정의 경우 람다 콘솔 기본값을 사용하십시오.

stepfunctionsfirst_10.png

그런 다음, 액티비티 작업자 람다 함수를 생성 할 수 있습니다.

단계5: 프로세스 테스트 하기

이제 직원 승직 프로세스를 테스트 할 준비가되었습니다.

람다 콘솔에서 ManualStepActivityWorker 람다 함수에서 ManualStepPollSchedule 트리거를 활성화하십시오.

Step Functions 콘솔에서 아래 입력 값을 사용하여 상태 시스템을 새로 시작하십시오.

JavaScript
{ "managerEmailAddress": "name@your-email-address.com", "employeeName" : "Jim" } 

잠시 후 Jim의 프로모션을 승인하거나 거부하는 링크가 포함 된 이메일을 받아야 합니다. 링크 중 하나를 선택하면 실행이 성공하거나 실패합니다.

stepfunctionsfirst_11.png

이 글에서는 AWS Step Functions의 활동 작업, API 게이트웨이가 있는 API 및 승인/실패 프로세스를 전달하는 AWS Lambda 함수가 포함 된 상태 머신을 만들었습니다. 본 디자인 패턴을 사용하여 수동 승인 단계를 구현할 수 있습니다.

질문이나 제안이 있으시면 아래에 의견을 남겨주십시오.


Ali Baghani, Software Development Engineer

이 글은 Implementing Serverless Manual Approval Steps in AWS Step Functions and Amazon API Gateway의 한국어 번역입니다.

AWS Lambda 신규 기능– 환경 변수 및 서버리스 앱 모델(SAM)

최근 AWS Lambda 및 서버리스(Severless) 애플리케이션 개발 모델이 확대되고 있는 고무적인 현상을 볼 수 있습니다. 특히, AWS Week in Review 에는 최근 이와 관련된 오픈 소스 프로젝트도 많이 늘어났습니다.

이러한 기술 변화에 도움을 줄 AWS Lambda에 두 가지 중요한 기능 추가를 발표하게 되었습니다. 환경 변수 지원 및 새로운 서버리스 애플리케이션 모델입니다.

환경 변수 지정 기능
대부분 개발자들이 하나의 환경 이상에서 코드를 작성하고, 이를 위해서는 재사용 가능한 변수 설정을 통해 시간에 코드의 영속성을 보장해야 합니다. 설정 값은 환경에 따라 테이블명, 파일 경로 등 달라질 수 있는 변수들로서 개발 환경, 테스트 환경, 정식 서비스 환경에 따라 변하게 됩니다.

이제 Lambda 함수에도 이러한 환경 변수를 설정할 수 있게 되었습니다. 변수를 필요에 따라 지정함으로서 코드를 수정 및 재배포하지 않고도, 효율적으로 서버리스 애플리케이션 개발을 할 수 있습니다. 각 환경 변수는 키/밸류 페어로 저장되며 이 값들은  AWS Key Management Service (KMS) 로 암호화 되고, 필요에 따라 복호화 됩니다. 환경 변수의 개수 제한은 없으나 전체 크기가 4kb 미만이어야 합니다.

Lambda 함수의 새 버전을 만들 때, 환경 변수를 설정할 수 있습니다. 여기서 환경 변수를 설정하는 예제를 간단한 Python 코드를 통해 보여 드리도록 하겠습니다.

Lambda가 제공하는 기본 서비스 키를 사용하면 추가 비용이 들지 않습니다. (만약 기존에 사용 중인 KMS키에 대해 과금이 될 수 있습니다.)

본 기능에 대해 좀 더 자세한 정보는 Simplify Serverless Applications With Lambda Environment Variables 블로그 글을 참고하시기 바랍니다.

AWS 서버리스 애플리케이션 모델
Lambda 함수, Amazon API Gateway 자원, Amazon DynamoDB 테이블 등을 사용하여 서버리스 애플리케이션을 만들 수 있습니다. 신규 AWS Serverless Application Model (AWS SAM)은 AWS CloudFormation을 활용하여, 손쉽게 자원을 표시할 수 있는 방법입니다. 새로운 문법을 사용하기 위해서는 CloudFormation 템플릿이 Transform 부분을 포함해야 합니다.

YAML
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

템플릿을 통해 Lambda 함수, API Gateway 엔드 포인트 및 API 리소스, DynamoDB 테이블을 표시하고, 각 함수의 핸들러, 런타임, 코드 배포를 위해 업로드할 Zip 파일 URI 등을 포함 할 수 있습니다.

API는 이벤트 뿐만 아니라 Swagger 를 통해서도 정의 가능합니다.

DynamoDB 테이블을 간단한 문법으로 정의하여, 테이블명, 기본 키 및 형식, 처리량 등을 설정할 수 있습니다.

AWS SAM 파일을 만들어 Lambda 함수의 배포 패키지로 만들 수 있습니다. 간단하게 Actions 메뉴에서 Export function을 선택하면 됩니다.

그리고 Download AWS SAM 파일 또는 Download deployment package를 선택합니다.

아래에 간단한 샘플 코드가 있습니다.

YAML
AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Description: A starter AWS Lambda function.
Resources:
  ShowEnv:
    Type: 'AWS::Serverless::Function'
    Properties:
      Handler: lambda_function.lambda_handler
      Runtime: python2.7
      CodeUri: .
      Description: A starter AWS Lambda function.
      MemorySize: 128
      Timeout: 3
      Role: 'arn:aws:iam::99999999999:role/LambdaGeneralRole'

코드 배포를 위한 ZIP 파일은 S3에 올려서, SAM 파일 내 CodeUri 를 수정하면 됩니다. 간단한 CLI 명령어 (aws cloudformation package and aws cloudformation deploy)를 통해 자동으로 배포할 수 있습니다. 좀 더 자세한 정보는 Introducing Simplified Serverless Application Management and Deployment 블로그 글의 Deploying a Serverless app 부분을 참고하시기 바랍니다.

샘플 예제로 되어 있는 Lambda 함수도 각 박스 오른쪽 아래의 다운로드 버튼을 눌러 받을 수 있습니다.

이제 Download blueprint를 누릅니다.

AWS SAM 파일과 코드가 포함된 ZIP 파일을 받을 수 있습니다.

더 자세한 사항은 Introducing Simplified Serverless Application Management and Deployment 블로그 글을 참고하세요.

Jeff;

이 글은 New for AWS Lambda – Environment Variables and Serverless Application Model (SAM)의 한국어 번역입니다.

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

AWS IoT 서비스, 서울 리전 출시

AWS IoT는 인터넷에 연결된 디바이스를 쉽고 안전하게 클라우드 애플리케이션 및 다른 디바이스와 상호 작용할 수 있게 해주는 관리형 클라우드 플랫폼입니다. 오늘 부터 서울 리전에서 AWS IoT 서비스를 이용할 수 있게 되었습니다.

aws-iot-in-seoul-region

AWS IoT는 수십억 개의 디바이스와 수조 건의 메시지를 안전하고 안정적으로 처리할 수 있는 확장성을 제공하며, 디바이스가 오프라인으로 연결되어 있지 않더라도 애플리케이션에서 모든 디바이스를 추적하고 디바이스와 통신할 수 있는 기능도 제공합니다.

AWS IoT를 사용하면 인프라를 관리할 필요 없이 기존 AWS 서비스와 연결 즉, AWS Lambda, Amazon API Gateway로서 서버리스 RESTful API 서비스를 가능하게 하고, Amazon DynamoDB, Amazon Kinesis, Amazon Simple Storage Service (S3)Amazon Redshift, Amazon Machine Learning 같은 서비스를 통해 대량 실시간 데이터 저장 및 분석 등 IoT 응용 프로그램에 필요한 확장성 높은 인프라를 함께 제공하고 있습니다.

AWS IoT 서비스에 대해서는 아래의 온라인 세미나 강의 및 발표 자료를 참고하시면 좀 더 쉽게 이해하실 수 있습니다.

AWS IoT 서비스 시작하기
AWS IoT 버튼은 Amazon Dash Button 하드웨어를 기반으로 한 프로그램 가능한 버튼입니다. 이 단순한 Wi-Fi 디바이스는 손쉽게 구성할 수 있으며, 개발자가 디바이스별 코드를 따로 작성하지 않고도 AWS IoT, AWS Lambda, Amazon DynamoDB, Amazon SNS 및 이외에도 다양한 AWS 서비스를 이용하여 시작할 수 있도록 고안되었습니다.

AWS IoT 버튼 구매 및 사용 방법을 확인하셔서  IoT 서비스를 직접 구성해 보실 수 있습니다.

그 외에도 Intel Edison, Raspberry Pi를 포함하여 다양한 IoT 서비스 데모를 만나보실 수 있습니다.

AWS IoT 서비스 실습 행사

zombie-workshop-oct

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

  • 일시: 2016년 10월 14일(금) 오전 10시 – 오후 7시
  • 장소: 역삼역 GS타워 25층

참가 신청

지금 시작하세요!
AWS IoT 서비스에 대해 더 알고 싶으시면, AWS IoT 시작하기 문서와 AWS IoT FAQAWS IoT 기술 문서를 참고하세요.

– AWS코리아 마케팅팀

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코리아 트레이닝룸

참가 신청