Amazon API Gateway | Amazon Web Services 한국 블로그

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

on 17 FEB 2017 | in Amazon API Gateway, AWS Lambda, AWS Step Functions, Serverless | Permalink

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

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

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

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

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

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

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

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

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

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

단계 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 관리 정책을 추가하십시오.

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

이제 각 메소드를 구성해야합니다. /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 값 입력

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

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 메시지가 표시되어야 합니다.

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

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

이제 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를 생성합니다.

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에 이메일을 보내도록 여분의 시간을 제공합니다. 다른 모든 설정의 경우 람다 콘솔 기본값을 사용하십시오.

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

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

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

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

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

JavaScript

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

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

이 글에서는 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의 한국어 번역입니다.

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

on 05 OCT 2016 | in Amazon API Gateway, AWS Lambda, Serverless | Permalink

Express는 Node.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 앱 개발을 위한 두 가지 기술 정보를 참고하실 수 있습니다.

Running Express Apps in AWS Lambda(영문): Claudia.js와 aws-serverless-express 모듈을 통해 애플리케이션을 개발 및 배포하는 방법입니다. 기존 TCP 리스너를 제거한 후, Lambda 프록시를 추가한 후 배포하는 방법입니다.
Going Serverless: Migrating an Express Application to Amazon API Gateway and AWS Lambda(영문): 위의 글보다는 좀 더 깊이 있는 기술 문서로서, 환경 변수 설정 방법, 데이터베이스 연결 방법, 정적 자원에 대한 효율적인 호스팅 방법 등을 알려주고 있습니다. 추가적인 Lambda 및 API Gateway 기능을 통해 전체 배포 주기 및 과정에 대한 부분도 자세히 담고 있습니다.

— Jeff;

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

API Gateway 업데이트 – 간편한 API 개발을 위한 신규 통합 기능

on 23 SEP 2016 | in Amazon API Gateway | Permalink

Amazon API Gateway는 손쉽게 확장성 높은 애플리케이션 백엔드를 만들고 실행할 수 있을 뿐만 아니라 사용량 제어 등의 기능을 통해 API 서비스를 서드파티 개발자에게 제공함으로서 생태계를 만들 수 있습니다. 본 서비스에 이용되는 몇 가지 용어에 대해 한번 살펴 보겠습니다.

엔드포인트(Endpoint) – API Gateway에서 접근하기 위한 URL 주소로서, GET, PUT 및 POST 같은 HTTP 호출을 할 수 있습니다.
리소스(Resource) – 엔드포인트 내에서 상징적으로 존재하는 각 이름 항목으로 계층 구조로 표시됩니다.
동작(Behavior) – 애플리케이션 코드가 HTTP 응답을 받기 위해 엔드포인트와 리소스로 보내는 HTTP 메소드 같은 행동
통합(Integration) – API Gateway에 엔드포인트, 리소스, 및 HTTP 메소드를 연결

오늘 이러한 통합 모델(Intergration Model)에 새로운 기능 몇 가지를 추가하여, 기존 애플리케이션을 새로운 API 엔트포인트로 이전할 때 도움을 줄 수 있게 되었습니다.

경로 변수 처리(Catch-all Path Variables) – 일반 경로 내에 들어 있는 모든 경로와 동작을 각각 제어 하는 대신, 전체 요청을 가로채서 하나의 함수에서 처리할 수 있습니다. 예를 들어, 단일 경로 정의 (/store/{proxy+})를 통해 /store/list-products, /store/add-product 및 /store/delete-product 경로 모두를 하나의 함수에서 제어 가능합니다.
통합 메소드 처리(ANY Method) – 개별 HTTP 메소드(GET, POST, PUT 등)를 개별 동작으로 처리하는 대신, ANY 메소드를 설정하면, 모든 요청 내 동작을 처리할 수 있습니다.
람다 함수 통합(Lambda Function Integration) – 신규 기본 맵핑 템플릿을 통해서 전체 요청을 람다함수로 보내고 HTTP 응답으로 보낼 수 있습니다.
HTTP 엔드포인트 통합(HTTP Endpoint Integration) – 신규 기본 템플릿을 통해서 모든 요청을 HTTP 엔드포인트로 보내고 변경 없이 응답을 반환할 수 있습니다. 이를 통해 아주 간단하게 HTTP 프록시로서 사용 가능합니다.

하나 하나 자세하게 알아보도록 하겠습니다.

경로 변수 처리
전자 상거래 API를 만든다고 가정할 경우, 아래와 같이 만들 수 있을 것입니다.

이제 /store 리소스를 만듭니다.

이제 경로 변수 처리 기능을 활용하여 /store로 들어오는 모든 요청을 처리할 수 있습니다. ( Configure as proxy resource를 체크합니다.)

{proxy+}는 모든 서브 리소스에 대해 실제 리소스로만 보내기 때문에, 리소스 경로의 마지막 요소로만 사용해야 합니다. 또한, /store/us/clothing, /store/us/clothing/children 등그 이하의 모든 경로에 대해서 처리하게 됩니다. 이를 통해 프록시 기능 처럼 람다함수나 HTTP 엔드포인트로 연결할 수 있습니다.

통합 메소드 처리
리소스에서 메소드를 선택할 때, 각 HTTP 메소드를 개별 동작으로 지정하지 않아도 됩니다.

대신 ANY 항목을 선택하면, 리소스 내 모든 메소드에 대해 똑같은 통합 동작을 제공할 수 있습니다.

더 깔끔하고 간편하고 쉽게 설정할 수 있을 뿐 아니라 전체를 처리하는 코드에서 각각 메소드 네임을 검사해서 적당한 응답을 줄 수 있습니다. 위와 같이 경로 변수를 만들 때 ANY 메소드가 자동으로 만들어 집니다. 개별 리소스에도 적용할 수 있을 뿐 아니라 (DELETE를 다르게 처리하고자 할 때) 설정에서 쉽게 재정의도 가능합니다.

람다 함수 통합
람다 함수를 사용하는 부분에서도 개선이 이루어졌습니다. 새로운 람다 함수 통합 템플릿을 통해 자동으로 HTTP 요청 내용- 헤더, 쿼리 파라미터, 요청 내용(payload) 등을 함수에서 사용할 수 있도록 할 수 있습니다. 템플릿에서 람다 함수의 반환 값으로 제공되어 상태 코드, 헤드 및 요청 내용을 객체로 변환해서 HTTP 응답을 구조적으로 제공 가능합니다.

아래에 기술 문서(Lambda Function for Proxy Integration)에서 가져온 간단한 샘플 함수 코드가 있습니다.

이와 같이 /store를 연결하였습니다.

이제 코드를 배포하고 간단하게 테스트를 해 봅니다.

함수가 실행되었고, 콘솔에서 응답 내용, 헤더 및 로그가 표시되었습니다. 이 부분이 첫번째 부분입니다.

이제 람다 콘솔에서 함수 실행 결과를 CloudWatch 로그를 통해 살펴 보겠습니다.

열 번째 행에서 노란색으로 표시한 함수 실행 메시지가 만들어 진 것을 볼 수 있습니다.

요약하면, 여러분의 API 리소스에서 별도의 설정 및 맵핑 시간을 들일 필요 없이 HTTP 요청에 대해 응답하는 람다 함수를 만들어 처리할 수 있게 됩니다. 즉, 람다 콘솔에서 이를 추가하는 것도 쉽고 새로운 람다 함수를 만들 때 API 게이트웨이 엔드포인트를 설정할 수도 있습니다.

HTTP 함수 통합
기존 데이터 센터나 Amazon EC2 인스턴스 내에 실행되는 HTTP 엔드포인트로도 API 요청을 보낼 수 있습니다. 특히, 별도 설정 없이도 integration type에 HTTP를 선택하고, Use HTTP Proxy integration를 선택하여 엔드포인트 이름을 넣으면 됩니다.

HTTP 메소드에 ANY를 선택하면 모든 요청에 대해 바로 지정한 곳으로 호출을 재전송 할 수 있습니다.

정식 출시
본 기능은 추가 비용 없이 API Gateway를 제공하는 모든 리전에서 바로 사용 가능합니다.

— Jeff;

이 글은 API Gateway Update – New Features Simplify API Development의 한국어 번역입니다.

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

on 30 AUG 2016 | in Amazon API Gateway, AWS Lambda, Serverless, 서울 리전 소식 | Permalink

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를 기반한 서버리스 아키텍처에 대해서는 아래의 온라인 세미나 강의 및 발표 자료를 참고하시면 좀 더 쉽게 이해하실 수 있습니다.

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

참가 신청

Amazon API Gateway, API 사용량 설정 기능 추가

on 12 AUG 2016 | in Amazon API Gateway | Permalink

작년에 Amazon API Gateway를 정식 공개하고, 개발자들이 웹 서비스, 모바일 백엔드 및 IoT 애플리케이션을 구축할 때 활용할 수 있게 되었습니다. 다양한 AWS 고객들이 AWS Lambda, Amazon Elastic Compute Cloud (EC2), 및 AWS 외부의 서버를 통해 직접 API를 만들고 서비스 하고 있습니다.

대부분의 경우, 고객들이 외부의 제 3자 개발자나 파트너사에 API를 제공해 주고자 합니다. API 게이트웨이에서는 이를 위해 각 사용자별 API 키를 생성할 수 있는 기능이 있습니다.

API키를 통해 사용자를 인식하고, 그 사용자가 어떤 배포 단계의 어떤 API를 사용 가능한지 접근 권한을 설정할 수 있으며, 이를 통해 제 3자 개발자 및 파트너사가 제공 API를 활용하여 자체적인 비지니스 모델을 구축할 수 있도록 사용량 설정 기능이 제공될 필요가 있습니다.

신규 사용량 설정(Usages Plan) 기능
이를 위해 신규로 사용량 설정(Usage Plans) 기능을 공개합니다. 이를 통해 API 게이트웨이를 통해 제공되는 API에 대해 사용량을 지정함으로서 수익을 창출 할 수도 있고, 다양한 생태계를 구축할 수 있습니다. 각 API 사용자 별로 다른 등급의 사용량을 설정할 수 있습니다. (예를 들어, 초급, 중급 고급 혹은 학생, 개인, 스타트업, 기업 같은 사용자 분류 등). 각 사용량 설정 시, 아래 API 측면을 통해 정의할 수 있습니다.

비율(Throttling) –초당 평균 호출량 같은 호출 비율 및 용량에 따른 설정
할당량(Quota) – 하루 혹은, 주당, 월간 호출 사용량에 따른 설정
API / 단계 – 접근할 수 있는 API 단계 (오픈 API 혹은 제휴용 API)

사용량 설정을 하려면, 각 API를 사용량 설정과 연계시켜야 합니다. 우선 기본 사용량 설정이 각 API에 자동으로 연계되며, 아래 창이 나타날 경우, Enable Usage Plan을 클릭하면 됩니다.

기본 사용량 설정은 사용량이나 비율에 대한 제한이 없으며, 현재 API 서비스에 영향을 주지 않습니다.

사용량 설정 만들기
이제 직접 사용량에 대한 설정을 해보도록 하겠습니다. API Gateway 콘솔을 열고, Usage Plans을 선택하고 Create를 누릅니다. 이름과 간단한 설명을 입력 한후, 제한할 비율 및 용량 설정을 합니다.

비율 제한은 Token Bucket 모델을 따릅니다. 버킷은 버스팅 값에 정해진 토큰 숫자만큼 가질 만큼 충분한 용량을 가지고 있습니다. 이제 Next를 눌러 사용량 설정과 연계할 API와 API 서비스 스테이지를 선택합니다.

이제 Next를 눌러 설정 생성을 한 후, 기존 API 키를 연계하거나 새로 만들 수 있습니다.

기존 API 키에 사용량 설정을 연계하면, 하나의 키에 여러 개 설정을 중북으로 지정할 수 없기 때문에 기존 기본 설정은 지워집니다.

API 키를 각 설정에 연계 한 후, Done를 선택합니다.

이제 API 키 사용자가 API 호출을 시작하면, 여러분이 정한 사용량 설정에 따라 제한량에 따라 사용할 수 있습니다. 각 API 키의 사용량은 Usage에서 확인할 수 있습니다.

사용량 제한은 실시간으로 반영되고, 데이터 표시는 30분 이후에 이루어 집니다. Export Usage Data를 클릭해서 사용량 데이터를 다운받을 수 있습니다.

이제 API 키 사용자에게 원하는 용량을 제공할 수 있고, 필요에 따라 호출 기반 과금 모델을 만들 수도 있게 되었습니다.

사용자가 여러분의 API을 매우 잘 활용하고 있고, 사용량 제한에 근접하는 경우, 계속 사용하도록 허용하고 싶으시다면 Extension을 눌러서 남아 있는 기간 동안 사용량 값 제한을 손쉽게 늘려 줄 수 있습니다.

사용량 설정을 통한 서비스 모델 구축
이전에 말씀 드린 대로 사용량 설정을 통해 API 키 사용자에 대해 다양한 서비스 모델을 구축할 수 있습니다. 개발용, 제휴용, 오픈용 등을 나눠서 과금 혹은 무료 API 서비스를 설계할 수 있습니다.

마지막으로 꼭 말씀 드리고 싶은 것은 API키는 신원 확인용이지 보안 인증용이 아닙니다. API 키를 가지고 로그인을 한다거나 보안용 수단으로 사용하지 않기를 권장합니다. (이를 위해서는 Cognito 사용자 풀 기능을 활용하셔야 합니다.)

정식 공개
본 기능은 오늘 부터 API Gateway를 지원하는 모든 리전에서 사용 가능합니다.

— Jeff;

이 글은 New – Usage Plans for Amazon API Gateway의 한국어 번역으로서, AWS Summit 뉴욕 행사에서 신규로 공개한 소식입니다.

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

on 11 AUG 2016 | in Amazon API Gateway, AWS Lambda, Serverless, 개발자 | Permalink

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8월 17일 – 서버가 필요 없는 아키텍처 만들기 (김필중, AWS 솔루션 아키텍트) 지금 등록하세요!!!
8월 30일 – Building Serverless Chatbots

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

Chalice, Python 기반 서버리스 마이크로프레임웍 공개

on 14 JUL 2016 | in Amazon API Gateway, AWS Lambda, Serverless, 개발자 | Permalink

서버리스 컴퓨팅(Serverless computing)은 AWS 고객 사이에 가장 인기있는 주제입니다. AWS가 제공하는 AWS Lambda 및 Amazon API Gateway를 통해 개발자들이 확장성에 대한 걱정 없이 손쉽게 API 애플리케이션을 만들어 낼 수 있습니다. AWS 개발자 도구팀에서 개발한 Python 기반의 Serverless Microframework을 소개하고자합니다.

아래 3분 정도의 동영상을 보면 어떻게 chalice 커맨드 라인 모드를 통해 손쉽게 API 서비스를 만들 수 있는 지 볼 수 있습니다. 45초 정도에서 Hello World 프로젝트를 만들고 app.py를 수정한 후, curl을 통해 HTTP GET 요청을 체크할 수 있습니다.

그 이후에는 새로운 기능을 추가해서 새롭게 배포하는 방법을 알려드리게 됩니다. 아마 이러한 개발 방법에 익숙하시다면, 아마 여러분이 Flask를 써보셨을 거라고 생각합니다. Flask는 커뮤니티에서 매우 인기있는 Python 기반 마이크로프레임웍 중에 하나이고, 이러한 개발 스타일을 차용함으로서 Python 개발자들이 좀 더 쉽게 서버리스 컴퓨팅에 친숙하게 해드릴 수 있을 것 입니다.

동영상의 마지막 파트에는 Amazon CloudWatch 로그를 통해 AWS Lambda의 빌트인 로깅 기능을 만드는 것입니다. chalice logs 및 chalice deploy 명령어를 함께 써서, 테스트, 수정, 배포 등을 계속 하실 수 있습니다.

Python Serverless Microframework for AWS는 PyPI (pip install chalice) 및 GitHub (https://github.com/awslabs/chalice) 통해 사용해 볼 수 있으며, 아직 미리 보기로 제공하기 때문에 정식 서비스 보다는 테스트로 활용해 보시길 권해 드립니다.

또한, 다양한 제안 및 기능에 대한 답글을 남겨 주시면 감사하겠습니다.

– Peter Moon

이 글은 AWS Developer 블로그의 Preview the Python Serverless Microframework for AWS의 한국어 번역입니다.

개발자들이 말하는 AWS 기반 ‘서버 없는 아키텍처’

on 18 APR 2016 | in Amazon API Gateway, AWS Lambda, Serverless, 한국 기술 문서 | Permalink

2014년 AWS re:Invent에서 처음 발표된 AWS Lambda는 클라우드에서 확장성에 대한 고민 없이도 경량의 애플리케이션을 실행하는 새로운 클라우드 함수입니다. 이를 통해 고객들로 부터 로그 분석, 이미지 처리 등 다양한 응용 사례들이 나오고 있지만, 그 중에서도 서버 없는(Serveless) 아키텍처를 실험하고 응용하고 있다는 점은 매우 고무적인 현상입니다.

특히, 2015년 6월 출시된 아마존 API 게이트웨이(Amazon API Gateway)와도 연계가 가능합니다. 이를 통해 외부에서 들어오는다양한 API 호출 대한 실행도 가능하여, API Gateway와 함께 AWS 자원을 제어하는 모든 종류의 기능을 수행할 수 있습니다.

모바일, 웹, 기업용 또는 IoT 애플리케이션에서 REST 기반 호출 서비스를 위한 API를 개발자가 손쉽게 생성, 게시, 유지관리, 모니터링할 수 있습니다. 기존에 API를 운영하고 있는 경우, 외부 혹은 사내팀에게 API를 제공할 때 필요한 많은 부담을 덜어주는 역할을 합니다.

오늘은 한국 개발자들이 이러한 AWS의 서버 없는 아키텍처를 어떻게 활용하고 있는지 다양한 경험들을 녹은 블로그 글들을 엄선해서 소개하고자 합니다.

AWS Lambda를 이용해서 HTTP API 만들기 #1, #2 by Outsider’s Dev Story

아주 간단한 API 두 개를 만드는데 아주 긴 설명을 했지만, 서버를 하나도 띄우지 않고 HTTP API를 만들었다. 설명은 아주 길게 했지만 실제로 하면 간단한 설정일 뿐이다.(초기에는 삽질이 좀 필요하겠지만 ) 예제는 아주 간단한 API였지만 실제로는 꽤 수준 높은 부분까지도 서버 구성을 하나도 하지 않고 이 조합으로 만들 수 있을 거라고 생각한다. 그래서 요즘 이 serverless 아키텍처에 관심이 있다.

일본어 RSS 번역해서 보기 – AWS Lambda 이용 by Seapy

이번 개발을 하면서 느낀 건 2가지였습니다. 첫째는 Node.js 도 재미있다는 거였습니다. 이번 개발을 하기 전까지는 필요성을 못 느꼈는데 서버 운영하기 싫은 간단한 것들 만들 때 Lambda에 올릴 것들은 Node.js 배워서 해보면 재미있겠다는 생각이 들었습니다. 두 번째는 Serverless 트렌드가 일회성으로 끝나지 않고 앞으로 많은 비중을 차지하게 될 것이라고 느꼈습니다. 직접 해보니 특정 영역에서 확실한 장점이 보였습니다.

AWS 람다(Lambda) 그리고 GitHub 자동배포 연동 by 개발자 PIGNOSE의 연구실

AWS Lambda를 이용하여 코드배포 자동화 서비스를 구성해볼려고 했습니다. 참고로 회사에서 기존에 이용하던 배포 프로세스는 Visual Studio를 이용해 개발을 완료, Github에 푸시하고 플러그인을 통해 AWS Beanstalk에 republish를 하였습니다. 이러한 기능을 이용하다 문득 이렇게 생각했습니다. “GitHub에 커밋으로 맨 앞에 Deploy라는 문자를 적으면 자동으로 배포할 수 는 없을까?” 이런 생각을 시작으로 Lambda를 NodeJS로 설정하고 작업을 시작했습니다.

Serverless 실시간 대전게임 by hyunjong-lee

지인의 소개로 Gaming on AWS 해커톤 행사를 알게 되었는데 서버 없는 (Serverless) 구조를 통한 게임 플랫폼 개발을 하는 것이 주제였습니다. Amazon Web Services (AWS)를 그전까지 한번도 써본적 없던 필자는 처음엔 무슨 의미인지 이해하지 못하였는데 같이 참가한 친구들의 도움으로 어떤 의미인지 뒤늦게 깨달았습니다. -_-a

Serverless 아키텍처의 세상이 온다 by 골빈해커의 생각의 파편들

AWS Lambda와 API Gateway가 런칭할 때부터 관심은 가지고 있었지만…최근에 몇 가지 개인 프로젝트를 하면서 사용해보게 되었는데, 정말 인상적이었다. “와, Serverless의 세상이 진짜 오는구나.” 얼마전에 슬랙 명령어와 개인적으로 사용하는 범용 함수를 간단한 API로 만들어서 사용하려고 했는데, 겨우 이것때문에 EC2등의 서버를 추가하는 것이 좀 부담스러웠다. 그래서 문득 생각난 것이 AWS Lambda 여서 사용해보게 되었다. “와, 정말 편하다.”…관리적인 측면에서 이처럼 편할 수가 없다. 단순히 서버 관리뿐 아니라, 배포나 확장 문제, 또한 보안 측면에서도 거의 신경 쓸 부분이 없다. “이것이 바로 레알 클라우드 서버야” 라는 느낌이랄까?”

그 밖에 몇 가지 도움 될 만한 블로그 글 몇 가지를 더 소개해 드립니다.

AWS Lambda with Apex by Tamm
AWS Lambda를 이용하여 S3 업로드된 파일 meta-data 변경 by 이두잉의 AWS 세상
AWS Lambda와 API Gateway로 Slack Bot 만들기 by 유스풀패러다임
API Gateway + Lambda: 텔레그램에서 슬랙 전달 봇 만들기 by 김승연

많은 한국 개발자들이 이미 AWS의 다양한 서비스 빌딩 블록을 이용하여 서버 없는 아키텍처를 실험하고, 현장에서 적용해 가고 있다는 점에서 매우 감사하면서 놀랍습니다. 혹시 더 좋은 글이 있으시면 언제든지 aws-korea-blog@amazon.com으로 알려주시면 소개해 드리겠습니다.

더 자세한 정보는 AWS Lambda 한국 블로그 글 및 AWS Compute 블로그 (영문)을 참고하시면 도움이 되실 것입니다.

또한, AWS 기술 백서 중 AWS Serverless Multi-Tier Architectures (영문)를 통해 보시면 세 가지 멀티 티어에 대한 설계 방법도 보실 수 있습니다.

Amazon S3 웹 사이트를 위한 서버 없는 백엔드 아키텍처 예제

모바일 앱을 위한 서버 없는 아키텍처 예제

마이크로서비스를 위한 서버 없는 백엔드 아키텍처 예제

– Channy(윤석찬);

Amazon API Gateway 출시 – 높은 확장성 앱을 위한 백엔드

on 10 JUL 2015 | in Amazon API Gateway | Permalink

인프라스트럭쳐는 누구나 필요로 하면서도 다루기를 힘들어 하는 부분이라고 생각합니다.일반적으로 인프라는 변화가 없고 복잡하고, 지루한 작업이면서 다루기도 어렵고 그러면서도 인프라에 영향에 따라 성공이 좌우되는 무엇이든 당연히 있어야 되는 것입니다(기대한 것 처럼 동작하다면 말이지요.)

우리의 고객중 많은 분들이 AWS상에서 모바일, 웹 , 기업용 또는 사물 인터넷(IoT, Internet of Things) 애플리케이션을 운영하고 있습니다. 이런 서비스들은 사용자 인터페이스를 갖고 있지 않습니다. 대신에 보통 REST 방식의 인터페이스로 그 서비스들에 프로그래밍적으로 접근합니다. 백엔드 애플리케이션을 성공적으로 운영하기 위해서 여러분은 인프라 구조에 대한 다음 항목에 대해 생각할 필요가 있습니다: 권한, 접근 제어, 트래픽 관리, 모니터링, 분석, 그리고 버전 관리. 이 작업들 중 어느 하나도 쉽지 않으며 모두 인프라 이슈로 귀결됩니다. 여러분은 여러 경우에 하나 이상의 프로그래밍 언어를 지원하는 소프트웨어 개발 도구(SDK, Software Development Kits)를 구축, 유지 보수, 배포할 필요가 있습니다. 그 모든 것을 한꺼번에 넣는다면, 웹 서비스의 기반 구조를 위해 할당된 막대한 양의 코드와 리소스가 서비스의 구현을 방해할 수 있습니다. 많은 고객들이 웹 서비스에 투자를 하고 싶지만,그 서비스를 개발하는데 필요한 기반 구조를 구축하거나 유지 보수하는데 있어서는 그에 따르는 비용과 복잡함 때문에 관심을 덜 간다고 얘기를 합니다.

새로운 API 게이트웨이

오늘 새로운 Amazon API Gateway를 소개하려고 합니다. 새로운 종량제(pay-as-you-go) 서비스로서 여러분이 빠르고 쉽게 견고하면서 확장성 있는 백엔드 애플리케이션을 구축하고 운영하게 해줍니다.

API 게이트웨이는 여러분이 모든 종류의 애플리케이션을 쉽게 AWS Lambda, Amazon Elastic Compute Cloud (EC2), 또는 AWS 외부에 있으며 공개적으로 접근할 수 있는 서비스에서 동작하는 API에 연결하게 해줍니다. 여러분이 만약 Lambda를 사용한다면(제가 어떻게 하는지 바로 보여드리겠습니다), 서버가 없으면서 높은 확장성을 제공하는 API를 구현할 수 있습니다.

또한 여러분은 기존 시스템을 포함하면서도 보완하여 효과적으로 제공 가능한 현대적 API를 구현할 수 있습니다. 여러 개의 구형 RPC 형태의 웹 서비스 호출을 통합된 하나의 응답으로 모을 수 있고, 그 결과를 걸러내고 처리할 수도 있으며 심지어 내장된 트래픽 제어 기능을 이용해서 과다 서비스 요청으로부터 백엔드 서비스를 보호할 수 있습니다.

API 게이트웨이는 다음의 항목을 보장하기 위해 설계됐습니다:

확장성 및 효율성 – 시스템 리소스를 잘 사용하면서 많은 초당 요청 수(RPS, requests per second)를 처리
셀프 서비스 및 높은 사용성 – 전문적인 지식이나 기술없이도 몇 번의 클릭이나 간편한 SDK를 이용해서 API를 정의,조정하며 배포하고 모니터링
신뢰성 – 커스터마이징된 예외 응답을 포함하여 예외 처리에 대한 완전한 제어를 제공해주며 뛰어난 신뢰성을 제공
안전성 – 최신 AWS 권한 매커니즘과 여러분의 API와 AWS 리소스를 관리할 수 있는 IAM 정책을 제공
고성능 – AWS 네트워크를 이용한 백엔드 데이터 전송으로 낮은 지연을 제공하기 위한 글로벌하게 낮은 지연을 제공하는(CloudFront를 경유하여) 서비스를 구축
비용 효율 – 고정 비용이 없는 종량제 과금으로 경제적으로 서비스를 구축

이 서비스를 설계하는데 있어 많은 시간을 개발자들에게 무엇이 필요한가에 집중했습니다. 예를 들면, 많은 고객들께서 API를 설명하는데 Swagger를 사용했다고 하셨습니다. 우리가 제공하는 도구를 이용하면 몇 분 만에 이미 존재하는 API 정의를 API 게이트웨어로 집어 넣고, 새로운 또는 기존의 API에 빠르게 연결할 수 있습니다.

또한, API 우선 개발 방식(API-first development model)을 지원하여 API 구현이 진행 중인 상황에서도 API 정의를 생성할 수 있습니다. API가 정의되면, API 게이트웨이는 자바스크립트, iOS 및 안드로이드 SDK를 몇 번의 클릭으로 생성할 수 있습니다(향후에 더 많은 언어를 추가할 것 입니다).

또한 간편한 테스팅과 배포를 위해 설계된 많은 기능들이 있습니다. AWS Management Console에서 HTTP 상태 코드, 응답(본문과 헤더) 및 요청 로그를 완벽히 제어하며 여러분의 API를 테스트할 수 있습니다.

몇 번의 클릭으로 주어진 API에 대한 여러 환경(stage라고 부름)을 생성하고 여러분이 정의한 태그(개발, 베타, 운영 등)의 범위 안에서 그 API를 배포할 수 있습니다. 각 버전의 개별 오퍼레이션은 구별되는 구현을 갖습니다(반드시 그럴 필요는 없습니다). 어떤 API에 대한 신규 버전이 생성되는 시점이 됐을때, 존재하는 API를 복제하고 구별되는 stage로 그 API를 배포하면, 오래된 API의 제거라는 최종 목적으로 가지고 두 버전의 API를 모두 사용할 수 있습니다. 그리고 각 서비스의 URL에 대한 더 많은 시험을 하기 위해 커스텀 도메인명을 사용할 수도 있습니다.

이제 API 게이트웨이는 수많은 운영상의 지원을 제공합니다!

여러분이 API를 배포한 후, 게이트웨이는 신속하게 요청을 수신하여 처리하며 응답하게 됩니다. 캐시된 응답의 수명 주기, 캐시키와 요청 파라메터의 매핑에 대한 완전한 제어를 가지고 stage 별로 캐시를 구성할 수 있습니다. 여러분의 API 요청은Amazon CloudWatch에 기록되며 상세한 측정 기준은 stage별, method별 기준으로 Amazon CloudWatch로 보고됩니다. API를 생성하고 구성하는 등의 관리적인 행동은 감사를 위해 CloudTrail에 기록됩니다. 요청이 임계치를 초과할 경우 요청을 조절할 수 있으며, 개별적인 방식에 대한 접근 권한의 확인을 위해 AWS Identity and Access Management (IAM), Amazon Cognito 및 OAuth 인증키를 사용할 수 있습니다.

API Gateway 시작하기
몇 가지 Lambda 함수를 다루기 전에 API를 만드는 과정을 함께 따라가 봅시다. 지면의 제약 때문에 게이트웨이의 몇개 기능만 보여드리겠고, IAM 정책과 관련된 과정은 넘어가도록 하겠습니다. 이 서비스가 무엇을 할 수 있는지에 대해 더 많은 내용을 배우고 필요한 정책을 생성하는 법을 얻기 위해 Amazon API Gateway Developer Guide을 읽을 것을 권장드립니다.

자 이제 API 게이트웨이 콘솔을 열고 API를 생성해보겠습니다:

콘솔은 제가 만든 API를 트리 구조로 보여줍니다:

그리고나서 Create Resource 버튼을 클릭하여 루트(root) 리소스 안에 자식(child) 리소스로 생성했습니다:

새 리소스가 생성됐고 트리 형태로 나타납니다:

자 이제 실제 코드가 필요합니다. Lambda 콘솔로 전환하고 /data 리소스 위에 있는 메소드의 구현으로 제공할 몇 가지 함수를 만들어보겠습니다. 첫번째는 GetHelloWorld라는 함수입니다. 이 함수는 입력값은 없고 간단하게 상수값을 갖는 JSON 객체를 반환합니다. 코드는 다음과 같습니다:

The second function is called GetHelloWithName. This one is slightly more sophisticated. If it is supplied with a parameter called name, it will return that name in the JSON object. If the parameter is not present it will use the string “No-Name” instead. Here’s the code:

두번째 함수는 GetHelloWithName입니다. 이 함수는 좀 더 복잡합니다. name이라는 파라메터가 제공되면, 그 name의 값을 갖는 JSON 객체를 반환합니다. 파라메터가 없으면 name값 대신에 “No-Name”이라는 문자열을 사용합니다. 코드는 다음과 같습니다:

두 함수가 준비됐으므로, 이미 만들어놓은 리소스에 함수를 생성하고 그 함수에 위에 있는 코드를 붙일 수 있습니다. 다시 API 게이트웨이 콘솔로 돌아와서 Create Method를 클릭하고 HTTP 메소드를 선택합니다.

제가 만든 리소스위에 여러 메소드(HTTP verb에 한 메소드)를 생성할 수 있습니다. 저는 GET을 선택하고 Integration Type으로 Lambda 함수를 지정하겠습니다(다른 형태에 대해서는 나중에 다루겠습니다):

자 이제 API에 호출의 각 단계를 커스터마이징할 옵션이 있습니다(method request와 method respone, integration request & response):

기본 설정으로도 잘 동작하겠네요! 이제 제가 만든 메소드가 실행되는 것을 볼 시간이므로, TEST 아이콘(번개 모양)을 클릭하여 Test 버튼을 누릅니다. API 게이트웨이는 제 메소드를 호출하여 저에게 응답으로 본문과 헤더 그리고 실행 로그(Lambda 함수를 호출하기 위한 준비, 발행, 처리에서 일어난 일)를 제공합니다:

다시 Lambda 콘솔로 넘어가면 거기서 제 함수에 대한 측정치를 볼 수 있습니다:

이제 본 API로 만족한다면, 저는 그 API를 다른 사람들도 사용할 수 있게 배포할 수 있습니다. 그렇게 하려면 Deploy API 버튼만 누르고, stage를 선택하면 됩니다. stage가 API에 대한 URL의 한 부분이 됩니다; stage는 서로 격리되있으며 독립적이고, 다수의 병렬적인 배포 환경(대기, 베타, 운영 등)을 갖게해줍니다. prod(운영 목적인)라는 stage를 생성하는 방법입니다:

그리고나면, stage에 대한 몇가지 옵션을 설정할 수 있습니다. CloudWatch Logs에 API 호출을 기록하고 측정치를 CloudWatch로 전송하게 옵션을 설정할 수 있습니다. 또한 API의 모든 호출에 대해서 그 호출을 허용하기 위해 API를 포함해야한다는 것을 지정할 수 있습니다:

보시는 것 처럼, API를 호출할 수 있는 URL이 콘솔에 나타납니다. 또한 콘솔에서 SDK를 이용해서 URL을 호출할 수 있는 옵션도 제공합니다:

제 경우에는 커스텀 도메인명을 생성해서 제 서비스를 위한 선호하는 호출 URL을 결정된 URL로 노출할 수 있습니다(이 모든것은 콘솔에서 처리될 수 있으며, CloudFront를 통해 구현됩니다).

이 시점에 저는 기반 구조에 대해서 생각할 필요없이 완전하게 확장 가능한 API를 생성하고 배포했습니다. 제가 만든 Hello World 함수가 엄청나게 인기를 얻게되더라도, 저는 제 AWS 계정에서 Lambda 함수가 동시에 처리할 수 있는 요청수를 적절하게 조정하는 것말고는 할 일이 없습니다.

기존 서비스를 강화하기
여러분(또는 여러분의 조직)은 아마도 더 예전 방식의 프로토콜인 XML-RPC나 SOAP으로 응답하는 기존 웹 서비스들을 갖고 있을겁니다. 각자 필요에 적합한 것으로 선택하고, 다음과 같은 기능들을 이용하여 이런 서비스들을 현대화하기 위해 게이트웨이 서비스를 사용할 수 있습니다:

트래픽 관리 – 미리 정의된 범위를 초과한다면 요청을 조절하기 위해 API Gateway를 구성할 수 있습니다. 이 기능은 존재하는 백엔드 시스템에 과부하가 가지 않도록 해줍니다(아마도 확장가능하지 않은 서비스).
권한 부여 – 여러분이 생성한 API에 대해 AWS 인증위에서 더 많은 정보를 적용하려면 가장 최신의 AWS 인증 방식(AWS Signature v4)를 활성화할 수 있습니다(Signing API Requests 참고). API Gateway를 통해 생성한 SDK가 필요한 서명, 암호화 및 복호화를 관리해줍니다.
데이터 변환 – 초기 고객들 중 한 분은 서비스 구현을 JSON 데이터를 변화하는 함수를 가지고 Lambda 기반의 모델로 옮기는 과정에 있습니다. 그 변환 과정 동안에 기본 서비스의 결과를 JSON으로 변환하기 위해 API Gateway를 사용하고 있으며, 매끄럽고 문제없이 진행되고 있습니다. 그 변환 과정에서 다음과 같은 JSON 스키마를 지정했습니다:
REST에서 RPC 그리고 역변환 – GET 요청에 대해 응답하는 신규 API 엔드포인트를 생성하고, POST를 사용하는 기존의 엔드포인트와 매핑할 수 있습니다. 그 과정에서 GET 파라메터를 POST에 대한 요청 본문으로 변환하는데 [gateway_u]를 사용할 수 있습니다.

추가 사항!
정리하기전에 API 게이트웨이에 대해 몇가지만 더 살펴보시죠.

제가 만든 리소스 정의(리소스명과 그에 대한 HTTP 메소드)와 그에 대한 코드간의 관계를 Integration Request라고 합니다.
이미 보신것 처럼, 그 요청은 몇번의 클릭만으로 Lambda 함수로 흘러갈 수 있습니다. 또한 임의의 HTTP 엔드포인트를 향할 수도 있습니다(EC2에서 동작하거나 어떤 공개적으로 접근 가능한 지점). 그 과정에서, 요청을 다른 HTTP 메소드와 매핑될 수 있고(가령, GET을 POST로 변경) API 게이트웨이 모델이 요청 입력값을 엔드포인트에서 실행중인 서비스가 요구하는 형태로 변경할 수도 있습니다. 그 모델들은 JSON-Schema로 지정하며 게이트웨이 콘솔에서 설정할 수 있습니다.

엔드포인트로 AWS 서비스가 제공하는 API를 사용할 수 있습니다. 이 옵션은 API 게이트웨이안에 포함된 AWS Service Proxy를 사용합니다. 다음은 제가 그 옵션을 설정한 방법입니다:

앞서 API 키에 대해 언급했습니다. 여러분이 만일 어떤 관리된 기준위에서 서드파티(고객, 개발자 또는 연계 파트너)에게 API의 접근을 허용한다면, 여러분은 API 키를 생성하고 서드파티가 그 키를 사용해서 API를 호출하도록 강제할 수 있습니다.

지금 사용하기
Amazon API 게이트웨이는 현재 미국 동부(US East, Northern Virginia), 미국 서부(US West, Oregon), 그리고 유럽(Europe, Ireland)에서 가용하며 여러분은 오늘 바로 사용할 수 있습니다.

과금 모델은 간단합니다. 여러분은 API 호출과 외부로 나가는 데이터 전송(API 호출이 반환하는 정보)에 대해 지불하면 됩니다. 캐싱은 별도로 과금되며 그 가격은 여러분이 구성한 캐시의 크기에 따라 달라집니다.

— Jeff;

이 글은 Amazon API Gateway – Build and Run Scalable Application Backends의 한국어 번역으로 AWS 코리아 테크니컬 트레이너로 근무중인 홍성민님이 수고하셨습니다.

Category: Amazon API Gateway