Amazon Web Services 한국 블로그

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 솔루션즈 아키텍트가 번역해 주셨습니다.

Amazon EC2 인스턴스 및 EBS 볼륨 초당 과금 제도 시행

2006년 Amazon EC2 출시 이전에는 컴퓨팅을 위해 필요한 물리 서버를 직접 구매하거나 임대했으나, EC2를 출시한 이후 시간 단위로 가상서버(인스턴스)를 사용하고 그 시간에만 비용을 지불하는 혁신을 가져왔습니다. 사용한 만큼 지불(Pay-as-you-go)하는 모델을 통해 AWS 고객이 다양한 애플리케이션을 개발, 테스트 및 배포하는 새로운 방법에 대해 생각할 수 있게 되었습니다.

최근 AWS Lambda와 같은 서비스는 애플리케이션을 실행한 시간 만큼만 과금하는 혁신을 가져왔고, 최근 콘테이너 기술을 비롯해서 짧은 시간 (불과 몇 분 정도의 실행)이 필요한 경우 효율적으로 활용하는 애플리케이션 개발도 증가하고 있습니다.

EC2 및 EBS에 대한 초 단위 청구
오는 10월 2일부터 온디멘드, 예약 및 스팟 형식의 구매 옵션에 대해 리눅스 인스턴스 사용은 1 초 단위로 과금합니다. 마찬가지로 EBS 볼륨에 대한 프로비저닝 된 스토리지는 1초 단위로 청구됩니다.

1초당 과금 방식은 Amazon EMR 및 AWS Batch에도 적용됩니다.

  • Amazon EMR – EMR 클러스터에 용량을 추가하여 보다 신속하게 데이터 분석 결과를 얻을 수 있는데, 이때 클러스터에 추가되는 EC2 인스턴스에 대한 초당 과금으로 노드를 추가하는 것이 이전보다 훨씬 비용 효율적입니다.
  • AWS Batch – 고객이 실행하는 일괄 처리 작업 중 상당수가 1시간 이내에 완료됩니다. AWS Batch는 스팟 인스턴스를 활용할 수 있으며, 앞으로 초당 과금을 통한 배치 처리로 훨씬 비용이 절감될 것입니다.

AWS 고객 중 일부는 게임, 광고 기술 또는 3D 렌더링 서버 집합을 관리 할 때, 가장 유리한  인스턴스 형태를 전략적으로 선택함으로써 EC2의 가치를 극대화 할 수있는 시스템을 구축했습니다. 이들 고객에게 초당 과금을 통해 인스턴스 관리의 추가 레이어가 필요 없으며, 모든 업무에 비용 절감 효과를 가져옵니다.

이로 인해 많은 부분에서 가격이 인하되는 효과를 가져 올 것이지만, 이것 보다 더 중요한 측면이 있습니다. 이러한 과금 방식의 변화가 여러분의 문제를 새로운 방식으로 풀수 있을 것으로 기대합니다. 예를 들어, 애플리케이션의 지속적인 통합, 테스트 서버의 운용, 데이터 분석, 일괄 처리 및 3D 렌더링 같은 분야에서 더 많은 자원으로 더 짧고 비용 효율적인 방법을 개선할 수 있을 것입니다.

클라우드 컴퓨팅의 많은 장점 중 하나는 필요에 따라 자원을 즉시 제공하고 해제할 수 있는 탄력성입니다. 과금 방식을 초단위로 바꾸면, 여러분은 이러한 자원 탄력성을 높이고 비용을 절감 할 수 있으며 계속해서 발전하는 컴퓨팅의 이점을 누릴 수 있습니다.

알아 두어야 할 것들
초당 과금 변경은 모든 AWS 리전에서 유효하며, 신규 실행 혹은 이미 실행중인 모든 리눅스 인스턴스에 대해 10월 2일부터 적용됩니다. 다만, 별도의 시간별 요금이 부과되는 Microsoft Windows 또는 리눅스 배포판을 실행하는 인스턴스에는 초당 청구가 적용되지 않습니다. 인스턴스 당 최소 1분의 요금이 부과됩니다.

인스턴스당 요금 및 스팟 가격은 시간 단위로 표시되지만, 비용 계산서에는 초단위로 과금된 비용이 청구됩니다.  예약 인스턴스 사용량 역시 한 시간 내에 여러 인스턴스를 시작, 사용 및 종료하는 경우 혜택을 받을 수 있으며, 요금 청구서에는 다음과 같이 십진법으로 시간이 표시됩니다.

단, 리전당 전용 호스팅 서버 요금, EBS Snapshots 및 AWS Marketplace의 제품은 여전히 한 시간 단위로 청구됩니다.

— Jeff;

이 글은 New – Per-Second Billing for EC2 Instances and EBS Volumes의 한국어 번역입니다.

 

AWS 주간 소식 모음 – 2017년 9월 18일

안녕하세요! 여러분~ 매주 월요일 마다 지난 주에 업데이트된 국내 AWS관련 콘텐츠를 정리해 드리고 있습니다. AWS 클라우드에 대한 새로운 소식을 확인하시는데 많은 도움 되시길 바랍니다. 혹시 빠지거나 추가할 내용이 있으시면, 저에게 메일 주시면 추가 공유해 드리겠습니다.

aws-korea-weekly

AWS코리아 블로그

AWS 관련 뉴스 및 추천 콘텐츠

AWS 글로벌 신규 소식 (영문)

AWS 제품별 블로그(영문)

AWS 주요 행사 및 온라인 세미나

AWS 마케팅 행사

AWS 공인 교육 일정

AWSKRUG 소모임

AWS 주요 파트너사 블로그

AWS 관련 새 소식을 확인하고 싶으시다면, 매주 업데이트 되는 AWS 주간 소식 모음을 살펴 보시기 바랍니다! 좀 더 빠르게 새소식을 접하시고 싶다면, 공식 트위터나 공식 페이스북을 팔로우 하세요!

이번 한주도 즐겁게 보내시고, 다음주에 다시 만나요!.

– AWS코리아 마케팅팀;

AWS 활용한 Amazon Prime Day 2017 성공 사례

올해로 세번째 맞는 지난 7월 11일 프라임 데이(Prime Day) 매출은 블랙 프라이데이(Black Friday)와 사이버 먼데이(Cyber ​​Monday)를 앞지르는 또 다른 신기록을 세웠으며, 아마존 소매 역사상 기념비적인 행사가 되었습니다. 30시간 행사 기간 동안 Prime 회원 수천만명이 Echo Dots, Fire 태블릿, 압력 쿠커, 에스프레소 머신, 충전식 배터리 등 다양한 제품들을 구입했습니다. 당일 수십만개의 저렴한 상품을 구매를 이용하기 위해 가입한 새로운 Prime 멤버십 회원수에 대한 기록도 세웠습니다. 아마존 고객은 주문을 위해 웹 사이트 뿐만 아니라 모바일 앱을 많이 사용했으며, 지난 프라임 데이 2배 이상의 모바일 주문이 있었습니다.

Powered by AWS
작년에 AWS가 Amazon의 가장 큰 이벤트를 어떻게 운영했는지에 대해 소개하면서, AWS 팀이 서버 준비, 자동화, 모니터링 등에 배웠던 것을 공유했습니다. 작년에 공유한 내용 모두 올해에도 해당되지만, 이번에 새로운 우수 사례 몇 가지를 소개하겠습니다.

작년 프라임데이가 끝나고 며칠만에 모범 사례를 수집 공유할 뿐만 아니라, 개선을 위한 부분을 확인하고 미리 프로세스 감사 및 게임 데이를 통한 테스트를 준비하였습니다.

  • 프로세스 감사 – 프로세스 감사는 큰 이벤트에 앞서 준비 사항을 추적하고, 위험을 식별하고, 목표에 대한 진행 상황을 추적 할 수있는 공식적인 방법입니다. 각 서비스 팀은 준비 상태를 결정하는 데 도움이되는 일련의 상세한 기술 및 운영 질문에 응답해야 합니다. 기술 측면에서는 CNAME의 TTL(Time to Live)에 대한 중요한 검사를 포함하여 데이터베이스 장애가 발생한 후 복구 시간에 대한 질문도 있습니다. 운영 측면에서는 현장 담당 통화 직원, 비상 연락망 및 서비스 및 인스턴스 소유권에 대한 확인 등을 포함합니다.
  • 게임 데이 (GameDay) – 전 아마존 직원 제시 로빈스(Jesse Robbins)가 처음 시작한 이 모범 사례는 컴퓨팅 용량 계획 및 준비를 검증하고 필요한 모든 운영 방식이 예상대로 작동하는지 확인하기 위한 테스트 이벤트입니다. 시뮬레이션 중 이슈가 있는 경우, 팀이 문제를 빨리 식별하고 신속하게 해결하고 과정에서 문제 해결을 훈련시키는 데 도움이됩니다. 또한, 장애 조치 및 복구 기능을 테스트하고 숨어있는 잠재된 결함을 노출 할 수 있습니다. 게임 데이는 각 서비스팀이 확장 과정(페이지 뷰, 주문 등)를 이해하도록 돕고 테스트 할 수있는 기회를 제공합니다. 좀 더 자세한 사항은 Resilience Engineering: Learning to Embrace Failure 문서나 GameDay: Creating Resiliency Through Destruction 동영상을 참고하시기 바랍니다.

2017 프라임 데이 통계
올해의 운영 결과에 대해 아마존닷컴을 담당하는 AWS 팀이 대시 보드 및 로그 파일을 확인하고, 주목할 만한 통계치를 공유해 주었으며, 아래는 몇 가지 흥미로운 지표입니다 :

  • 블록 스토리지 – Amazon Elastic Block Store (EBS)의 사용량은 전년 대비 40 % 증가했으며 데이터 전송량은 52 페타 바이트 (50 % 증가)로 증가했으며 총 I/O 요청은 8 억 3500 만 개로 증가했습니다. (30 % 증가). 빠른 EBS의 탄력성 덕분에  프라임 데이 (Prime Day)가 끝나고 나서도 용량이 줄어들지 않았습니다.
  • NoSQL 데이터베이스 – Alexa, Amazon.com 사이트 및 Amazon Fulfillment 센터의 Amazon DynamoDB 요청은 총 3 조 3400 억회로서, 피크 타임 초당 1290 만 건에 이릅니다. 서비스 팀에 따르면 DynamoDB의 빠른 확장성, 일관된 성능 및 고 가용성으로 인해 어렵지 않게 프라임 데이의 요구 사항을 충족 할 수있었습니다.
  • 스택 생성 – AWS 리소스를 추가로 가져 오기 위해 Prime Day를 위해 약 31,000 개의 AWS CloudFormation 스택이 생성되었습니다.
  • API 사용 횟수 – AWS CloudTrail은 5 백억 개 이상의 이벤트를 처리하고 Prime Day를 지원하는 다양한 AWS API에 대한 4190 억 회 이상의 호출을 추적했습니다.
  • 구성 추적 – AWS Config는 AWS 리소스를위한 1 천 4 백만 개 이상의 구성 항목을 생성했습니다.

여러분도 할 수 있습니다!
프라임 데이 (Prime Day)만큼 크고 복잡한 중요한 이벤트를 진행하는 데는 많은 계획이 필요합니다. 이러한 유형의 이벤트를 염두에 두고 계시면, 대형 이벤트를 위한 인프라 준비하기에 대한 한국어 기술 백서를 살펴보십시오. 내부에서는 제품 출시 또는 계절적 트래픽 급증과 같은 계획된 확장성 높은 이벤트, 자동화, 탄력성, 비용 최적화, 이벤트 관리 등의 섹션을 원활하게 처리 할 수 ​​있도록 애플리케이션을 디자인하고 프로비저닝하는 방법을 배울수있습니다.

— Jeff;

이 글은 Prime Day 2017 – Powered by AWS의 한국어 번역입니다.

4TB 메모리 기반 x1e.32xlarge EC2 인스턴스 타입 출시

올해 초 최대 16TB의 메모리 기반 EC2 인스턴스를 출시 계획을 전해 드린바 있습니다. 그 일환으로 오늘 4 개의 AWS리전에서 4TB의 DDR4 메모리를 갖춘 새로운 x1e.32xlarge 인스턴스를 출시합니다. 이전 게시물에서 쓴 것처럼 본 인스턴스는 SAP HANA 및 대용량 메모리 집약적인 애플리케이션을 실행하도록 설계되었습니다. 많은 AWS 고객이 이미 기존 x1.32xlarge 인스턴스에서 SAP 애플리케이션을 정식 운영 환경에서 실행하고 있습니다. 이제 훨씬 더 큰 데이터 세트를 저장하고 처리 할 수 있게 되었습니다.

x1.32xlarge와 마찬가지로 x1e.32xlarge는 2.3GHz(128 vCPU)에서 실행되는 쿼드 소켓 Intel Xeon E7 8880 v3 Haswell 프로세서와 L3 캐시, 대량 메모리 대역폭 및 C상태 및 P상태 관리 기능을 지원합니다.

네트워크 측면에서 각 인스턴스는 최대 8개의 Elastic Network Interface (ENI)를 지원하는 Elastic Network Adapter (ENA)를 기반으로 EC2 배치 그룹 내에서 최대 25 Gbps의 네트워크 대역폭을 사용할 수 있습니다. 각 인스턴스는 기본적으로 EBS 최적화되어 있으며 EBS 볼륨에 14Gbps의 전용 대역폭을 추가로 제공하며, 인스턴스 당 최대 80,000 IOPS를 지원합니다. 각 인스턴스에는 1,920GB SSD 볼륨 페어를 포함합니다.

다음은 x1e.32xlarge와 관련하여 염두에 두어야 할 몇 가지 사항입니다.

  • SAP 인증 – x1e.32xlarge 인스턴스는 HANA (SoH)의 SAP Business Suite, HANA의 SAP Business Warehouse (BWoH) 및 차세대 SAP S 프로덕션 HANA 배포를 위해 SAP에서 인증을 지원하는 최대 규모의 클라우드 고유 인스턴스입니다. 4HANA ERP 및 SAP BW / 4HANA 데이터웨어 하우스 솔루션. 더 작은 X1 인스턴스에서 SAP HANA 작업 부하를 이미 실행하고 있다면 확장이 쉽고 빠릅니다. AWS 클라우드 퀵 스타트 레퍼런스에서 SAP HANA가 업데이트되었으며, 고성능 및 안정성을 위해 SAP 및 AWS 표준을 따르는 설정하는 데 도움이됩니다. SAP HANA Hardware Directory 및 SAP HANA Sizing Guidelines 역시 도움이 되는 자료입니다.
  • 예약 인스턴스 – 예약 인스턴스의 리전 내 사이즈 유연성은 x1 및 x1e에 적용되지 않습니다.

정식 출시
x1e.32xlarge 인스턴스는 미국 동부 (버지니아 북부), 미국 서부 (오레곤), EU (아일랜드) 및 아시아 태평양 지역 (도쿄) 리에서 온-디맨드 및 예약 인스턴스로 시작할 수 있습니다.  X1 인스턴스에 대한 몇 가지 다른 업그레이드에 대해 알려 드리고자합니다.

  • EBS – 현재 출시 된 X1 인스턴스는 EBS에 최대 14 Gbps의 전용 대역폭과 인스턴스 당 80,000 IOPS를 지원합니다.
  • 네트워크 – 이번 주 초 기존 x1.32xlarge 인스턴스에 대해 배치 그룹 내에서 최대 25Gbps의 네트워크 대역폭을 지원을 발표했습니다.

— Jeff;

이 글은 Now Available – EC2 Instances with 4 TB of Memory의 한국어 번역입니다.

AWS 9월 온라인 세미나 – AWS 클라우드 소개, DB 마이그레이션, Aurora 심층 분석 및 Lambda@Edge

AWS 클라우드를 아껴주시는 한국 고객 분들을 위해 지속적으로 AWS 월간 온라인 세미나 시리즈를 진행하고 있습니다.이번 9월 온라인 세미나 에서는 AWS 클라우드 소개, AWS  데이터베이스 마이그레이션, Amazon Aurora Deep Dive,  AWS Lambda@Edge 서비스 등 다양한  온라인 세미나를 준비하였습니다.

관심 있는 분들의 많은 참여를 바랍니다.

온라인 세미나 일정

비지니스 기초 | AWS와 함께하는 클라우드 컴퓨팅
연사: 한정수 AWS 어카운트 매니저
일시: 2017년 9월 26일 (화) 오전 10:00 – 오전 11:30

강연 요약: AWS 클라우드는 IT의 새로운 기준을 정립하며 클라우드 컴퓨팅 산업을 혁신하고 있습니다. 이 세미나에서는 클라우드 컴퓨팅의 개념과 AWS가 제공하는 서비스 및 솔루션의 특장점, 주요 사용사례에 대해 말씀드리고 질답 시간을 가질 예정입니다. 부디 참석하셔서 귀사의 사업과 서비스에 적용할 수 있는 정보를 얻어가시기 바랍니다.

지금 등록하기

기술 기초 | AWS 데이터베이스 마이그레이션 서비스 활용하기
연사:  김상필 AWS 솔루션즈 아키텍트
일시: 2017년 9월 26일 (화) 오후 02:00 – 오후 03:30

강연 요약:   AWS Database Migration Service는 데이터베이스를 AWS로 쉽고 안전하게 마이그레이션할 수 있도록 도와줍니다. 본 세션에서는 기존에 운영 중인 오라클 DB에 AWS Schema Conversion Tool 및 AWS Database Migration 서비스를 이용함으로써, 비즈니스 중단을 최소화하며 클라우드 환경의 Amazon Aurora로 마이그레이션할 수 있는지에 대한 방법론을 살펴봅니다.

지금 등록하기

기술 심화 | Amazon Aurora Deep Dive
연사: 김필중 AWS  솔루션즈 아키텍트
일시: 2017년 9월 27일(수) 오전 10:00 – 오전 11:30

강연 요약: Amazon Aurora는 MySQL과 완벽히 호환되는 관계형 데이터베이스로서 저렴한 비용은 물론 더 향상된 안정성과 성능을 제공합니다. 비용, 안정성, 성능, 운영 관점에서 Aurora가 제공하는 장점과 그 기술에 대해 알아봅니다. 더불어 기존 데이터베이스에서의 마이그레이션 전략과, 실제 고객 사례를 통해 그 활용성에 대해서도 알아볼 예정입니다.

지금 등록하기

기술 심화 | AWS Lambda@Edge를 통한 엣지 컴퓨팅 서비스
연사: 윤석찬 AWS 테크에반젤리스트
일시: 2017년 9월 27일(수) 오후 2:00 – 오후 3:30

강연 요약:  AWS Lambda@Edge 서비스를 이용하면, AWS의 콘텐트 배포 네트워크(CDN)의 엣지네트워크에서 별도의 자바스크립트 코드를 통해 원하는 애플리케이션 기능을 수행할 수 있습니다. 본 세션에서는 AWS의 콘텐츠 배포 네트워크 활용 방법과 아울러 활용 방법 및 간단한 데모를 통해 엣지 컴퓨팅 서비스를 만들 수 있는 방법을 소개합니다.

지금 등록하기

9월 AWS 온라인 세미나를 통해 AWS를 통해 비지니스를 성공하는 방법과 다양한 AWS 서비스를 통해 다양한 IT 워크로드를 구축하는 방법에 대해 알아보시기 바랍니다. 또한, AWS Online Tech Talk 역시 매월 진행하고 있습니다. 영어로 진행되지만 많은 도움 받으시기 바랍니다.

– AWS 코리아 마케팅팀;

AWS 주간 소식 모음 – 2017년 9월 11일

안녕하세요! 여러분~ 매주 월요일 마다 지난 주에 업데이트된 국내 AWS관련 콘텐츠를 정리해 드립니다. AWS 클라우드에 대한 새로운 소식을 확인하시는데 많은 도움 되시길 바랍니다. 혹시 빠지거나 추가할 내용이 있으시면, 저에게 메일 주시면 추가 공유해 드리겠습니다.

aws-korea-weekly

AWS코리아 블로그

AWS코리아 발표 자료

AWS 관련 뉴스 및 추천 콘텐츠

AWS 글로벌 신규 소식 (영문)

AWS 제품별 블로그(영문)

AWS 주요 행사 및 온라인 세미나

AWS 마케팅 행사

AWS 공인 교육 일정

AWSKRUG 소모임

AWS 주요 파트너사 블로그

AWS 관련 새 소식을 확인하고 싶으시다면, 매주 업데이트 되는 AWS 주간 소식 모음을 살펴 보시기 바랍니다! 좀 더 빠르게 새소식을 접하시고 싶다면, 공식 트위터나 공식 페이스북을 팔로우 하세요!

이번 한주도 즐겁게 보내시고, 다음주에 다시 만나요!.

– AWS코리아 마케팅팀;

신규 Network Load Balancer 출시 – 초당 수백만 요청을 처리 확장성 제공

ELB (Elastic Load Balancing)와 Auto Scaling 및 Amazon CloudWatch 등 3종 세트는 AWS 초기 부터 매우 중요한 부분입니다. 그 이후로 많은 기능이 추가하였고, Application Load Balancer는 컨테이너에서 실행되는  애플리케이션의 콘텐츠 기반 라우팅을 지원하도록 설계하여 마이크로서비스, 스트리밍 및 실시간 서비스 등에 최적화되어 있습니다.

오랫 동안 AWS 고객은 ELB를 사용하여 T2 인스턴스에서 실행하는 단순한 웹 사이트에서부터 다수의 고급 인스턴스에서 실행되는 복잡한 애플리케이션에 이르기까지 다양한 규모의 서비스에 활용하여 방대한 양의 트래픽을 처리 할 수 있었습니다. ELB는 배후에서 트래픽을 모니터링하고, 수요에 맞게 자동으로 확장합니다. 몇년 간 높은 반응 속도를 보이도록 개선 한 결과, ELB를 사용한 온라인 생중계, 깜짝 판매 이벤트 등의 이벤트성 서비스에도 잘 동작합니다. 그러나, 리전 간 순간적인 페일 오버 또는 극히 까다로운 워크 로드와 같은 일부 상황에서 트래픽 급상승을 예상하는 경우 ELB를 사전에 미리 설정해 두고(pre-warm)으로 제공하는 옵션을 제공했습니다.

신규 네트워크 로드 밸런서 출시
오늘 네트워크 로드 밸런서 (NLB)를 새롭게 소개합니다. 본 서비스는 낮은 대기 시간에 높은 처리량을 유지하면서 초당 수천만 건의 요청을 처리 할 수 있도록 설계되었습니다. NLB는 대상 그룹에 대해 API 호환성이 높은 ALB입니다. 아래는 주요 기능을 소개합니다.

  • 고정 IP 주소 – 각 NLB는 각 VPC 서브넷마다 하나의 IP 주소를 제공합니다. us-west-2a의 서브넷에 대상이 있고 us-west-2c의 서브넷에 있는 다른 대상이 있는 경우 NLB는 두 개의 IP 주소(서브넷 당 하나)를 만들고 관리합니다. 해당 IP 주소에 대한 연결은 서브넷의 인스턴스간에 트래픽을 분산시킵니다. 각 서브넷에 대해 기존의 Elastic IP를 지정할 수도 있습니다. IP 주소를 완전히 제어하면 IP 주소를 DNS 레코드, 고객 방화벽 규칙 등에 하드 코딩해야하는 상황에서 NLB를 사용할 수 있습니다.
  • Zonality – 서브넷 당 고정 IP 기능은 향상된 성능으로 지연 시간을 줄이고 격리 및 내결함성을 통해 가용성을 향상 시키며 NLB 클라이언트에서 바로 사용 가능합니다. 또한, NLB는 자동 장애 조치를 통해, 특정 소스의 일련의 요청을 단일 서브넷의 대상으로 라우팅합니다.
  • 소스 주소 보존 – NLB를 사용하면 들어오는 연결의 원래 소스 IP 주소 및  포트가 수정되지 않으므로 응용 프로그램 소프트웨어는 X-Forwarded-For, 프록시 프로토콜 또는 다른 해결 방법을 지원할 필요가 없습니다. 이는 VPC 보안 그룹을 포함한 일반 방화벽 규칙을 대상에서 사용할 수 있습니다.
  • 장기 연결 유지 및 실행 – NLB는 내결함성을 내장한 연결을 처리하고 몇 달 또는 몇 년 동안 커넥션을 처리 할 수 있으므로 IoT, 게임 및 메시징 응용 프로그램에 매우 적합합니다.
  • 장애 조치 – Route 53 상태 검사에 의해 작동되는 NLB는 리전 내 및 리전 간 IP 주소 간의 장애 조치를 지원합니다.

Network Load Balancer 만들기
EC2 콘솔에 가면, 새로운 Load Balancers항목에서 Create Load Balancer를 클릭합니다.

네트워크 로드 밸런서를 선택하고 만들기를 클릭 한 다음 세부 정보를 입력합니다. 대상 VPC의 각 서브넷에 대해 Elastic IP 주소를 선택할 수 있으며, 태그를 지정할 수 있습니다.

그런 다음 라우팅 구성을 클릭하고 새 대상 그룹(Target Group)을 만듭니다. 이름을 입력 한 다음 프로토콜과 포트를 선택합니다. 트래픽 포트와 상태 확인 방법을 설정할 수 있습니다.

Register Targets를 눌러 EC2 인스턴스를 설정 한 후, Add to registered:를 클릭합니다.

모든 것이 잘 설정 되었으면, Create를 선택합니다.

신규 로드 밸런서가 완료 되면 몇 분 후 provisioning에서 active로 바뀝니다.

테스트 목적으로 콘솔에서 Load Balancer의 DNS 이름을 가져옵니다 (실제로는 Amazon Route 53 와 좀 더 친숙한 이름을 사용합니다.)

이제 대량 트래픽을 한번 보내 볼 때입니다.

Bash
$ while true;
> do
>   wget http://nlb-1-6386cc6bf24701af.elb.us-west-2.amazonaws.com/phpinfo2.php &
> done

몇 가지 트래픽 흐름을 허용하기 위해, CloudWatch 지표를 확인하면 갑작 스러운 트래픽을 잘 처리 할 수 ​​있음을 확인했습니다.

또한, EC2 인스턴스를 보고 부하가 어떻게 작동하는지 확인했습니다.

AWS 개발팀에서 위의 것 보다 더 나은 테스트를 해 보았고, 수백 대의 EC2 인스턴스로 클러스터에서 초당 150 만 건의 요청을 시작으로 신속하게 초당 300만 건의 요청과 총 대역폭의 30Gbps를 달성했습니다.

Load Balancer 선택하기
로드 밸런서를 선택할 때, 여러분의 애플리케이션 요구 사항을 고려해야합니다. 다음은 몇 가지 지침입니다.

  • Network Load Balancer (NLB) – TCP 트래픽 로드 밸런싱에 이상적인 NLB는 초저 대기 시간을 유지하면서 초당 수백만 건의 요청을 처리 할 수 ​​있습니다. NLB는 가용성 영역 당 하나의 고정 IP 주소를 사용하면서 갑작스럽고 불안정한 트래픽 패턴을 처리하도록 최적화되어 있습니다.
  • Application Load Balancer (ALB) – HTTP 및 HTTPS 트래픽의 고급 로드 밸런싱에 이상적인 ALB는 마이크로서비스 및 컨테이너 기반 응용 프로그램을 포함한 최신 응용 프로그램 아키텍처를 지원하는 고급 요청 라우팅을 제공합니다.
  • Classic Load Balancer (CLB) – EC2-Classic 네트워크 내에 구축 된 애플리케이션에 이상적입니다.

좀 더 자세한 사항은 Elastic Load Balancer 세부 정보 테이블을 살펴 보시기 바랍니다.

현재 Classic Load Balancer를 사용 중이고 Network Load Balancer로 마이그레이션하려면 Load Balancer Copy Utility를 살펴보십시오. 이 Python 도구를 사용하면 기존의 Classic Load Balancer와 동일한 구성으로 NLB를 만들 수 있습니다. 기존로드 밸런서를 사용하여 기존 EC2 인스턴스를 등록 할 수도 있습니다.

가격 및 가용 방법
Application Load Balancer와 마찬가지로 가격 책정은 Load Balancer Capacity Unit 또는 LCU를 기본으로합니다. 청구액은 다음 측정 기준에서 가장 높은 값을 기준으로 한 LCU 당 0.006 달러입니다.

  • 대역폭 – LCU 당 1GB.
  • 신규 연결 – LCU 당 800.
  • 활성 연결 – LCU 당 100,000.

대부분의 애플리케이션은 대역폭에 따라 달라 지고, 기존의 ALB와 비교할 때 약 25%의 비용 절감 (로드 균형 조정)이 있습니다. 네트워크로드 밸런서는 현재 China (Beijing)를 제외한 AWS CloudFormation, Auto Scaling 및 Amazon ECS 등을 지원되는 모든 AWS 상용 리전에서 사용할 수 있습니다.

— Jeff;

이 글은 New Network Load Balancer – Effortless Scaling to Millions of Requests per Second의 한국어 번역입니다.

AWS 주간 소식 모음 – 2017년 9월 4일

안녕하세요! 여러분~ 매주 월요일 마다 지난 주에 업데이트된 국내 AWS관련 콘텐츠를 정리해 드립니다. AWS 클라우드에 대한 새로운 소식을 확인하시는데 많은 도움 되시길 바랍니다. 혹시 빠지거나 추가할 내용이 있으시면, 저에게 메일 주시면 추가 공유해 드리겠습니다.

aws-korea-weekly

AWS코리아 블로그

 
AWS코리아 발표 자료

AWS코리아 동영상

AWS 관련 뉴스 및 추천 콘텐츠

AWS 글로벌 신규 소식 (영문)

AWS 제품별 블로그(영문)

AWS 주요 행사 및 온라인 세미나

AWS 마케팅 행사

AWS 공인 교육 일정

AWSKRUG 소모임

AWS 주요 파트너사 블로그

AWS 관련 새 소식을 확인하고 싶으시다면, 매주 업데이트 되는 AWS 주간 소식 모음을 살펴 보시기 바랍니다! 좀 더 빠르게 새소식을 접하시고 싶다면, 공식 트위터나 공식 페이스북을 팔로우 하세요!

이번 한주도 즐겁게 보내시고, 다음주에 다시 만나요!.

– AWS코리아 마케팅팀;

Application Load Balancing을 통한 온-프레미스 서버 연결 기능 출시

작년에 새로운 Application Load Balancer 출시와 함께 네트워크 레이어 7의 애플리케이션 라우팅을 통해 EC2 인스턴스 및 콘테이너에서 실행하는 마이크로 서비스 구현 방법을 설명했습니다.

어떤 고객은 AWS로 장기간 이전 중인 하이브리드 애플리케이션을 구축하고 있습니다. 이들 고객은 단일 Application Load Balancer를 사용하여 기존 사내의 리소스와 AWS 클라우드에서 실행 중인 신규 리소스를 결합하여 트래픽을 분산할 필요가 있습니다. 또 다른 고객은 둘 이상의 가상 사설망(VPC)에 분산되어 있는 웹 서버 또는 데이터베이스 서버에 트래픽을 분산시키고, 동일한 인스턴스에서 중복되지 않는 고유 IP 주소를 사용하지만 공통 포트 번호를 사용하여 SNI (Server Name Indication)를 지원하지 않는 클라이언트 용 가상 기반 가상 호스팅을 통해 여러 서비스를 하기도 합니다. 또한, 여러 인터페이스와 보안 그룹을 사용하여 세분화 된 접근 제어를 구현하는 동시에 동일한 인스턴스(예: 컨테이너)에 여러 서비스 인스턴스를 호스팅하기도 합니다.이러한 상황은 엔터프라이즈 기업의 하이브리드, 마이그레이션, 재해 복구 및 사내 구축 환경의 사용 사례 및 시나리오에서 발생합니다.

이러한 상황은 엔터프라이즈 기업의 하이브리드, 마이그레이션, 재해 복구 및 사내 구축 환경의 사용 사례 및 시나리오에서 발생합니다.

IP 주소로 라우팅 하기
이러한 사용 사례를 해결하기 위해 Application Load Balancer는 이제 트래픽을 IP 주소로 직접 라우팅 할 수 있습니다. 이 주소는 ALB와 동일한 VPC, 동일한 리전의 피어 VPC, ClassicLink를 통해 VPC에 연결된 EC2 인스턴스 또는 VPN 연결 또는 AWS Direct Connect 연결 지점 내 사내 자원에있을 수 있습니다.

ALB는 이미 대상을 대상 그룹을 지정하고 있고, 오늘 부터 각 대상 그룹에는 오른쪽 그림 같이 Target Type 속성이 있습니다.

  • instance – 대상은 이전과 마찬가지로 EC2 인스턴스 ID를 통해 등록됩니다.
  • ip – 대상은 IP 주소로 등록됩니다. 로드 밸런서의 VPC 내의 대상에 대한로드 밸런서의 VPC CIDR과 RFC 1918 범위 (10.0.0.0/8, 172.16.0.0/12 및 192.168.0.0/16)의 IPv4 주소 또는 RFC 부하 분산 장치의 VPC 외부에있는 대상 (여기에는 Peered VPC, EC2-Classic 및 직접 연결 또는 VPN을 통해 도달 할 수있는 온 프레미스 대상 포함)에 대한 RFC 6598 범위 (100.64.0.0/10)가 있습니다.

각 대상 그룹에는 로드 밸런서 및 상태 확인 구성이 있으며, 항상 그렇듯이 CloudWatch에 지표를 게시합니다.

AWS 클라우드 마이그레이션의 전환 단계에 있거나 EC2 인스턴스로 AWS를 사용하여 사내 리소스를 확장하려는 경우, 애플리케이션 트래픽을 AWS 및 사내 구축 형 리소스 모두에 배포해야한다고 가정해 보겠습니다. 모든 리소스(AWS 및 사내 구축 형)를 동일한 대상 그룹에 등록하고 대상 그룹을로드 밸런서와 연관 시키면 이러한 기능을 수행 할 수 있습니다.

또한, 두 개의 로드 밸런서, 즉 AWS용 로드 밸런서 하나와 사내 구축 리소스용 로드 밸런서 하나를 사용하여 AWS 및 사내 구축 리소스에서 DNS 기반 부하 로드 밸런싱을 사용할 수 있습니다. 애플리케이션-A는 백 엔드가 VPC에 있고, 애플리케이션-B 백엔드가 온-프레미스 위치에 있는 시나리오에서 각 애플리케이션에 대한 백엔드를 다른 대상 그룹에 넣고 콘텐츠 기반 라우팅을 사용하여 트래픽을 각각 라우팅 할 수 있습니다.

Target Group 생성하기
다음은 Application Load Balancer를 생성하는 과정의 일부로 일부 IP 주소로 트래픽을 보내는 대상 그룹을 만드는 방법입니다. 여기서 이름 (ip-target-1)을 입력하고 대상 유형으로 ip를 선택합니다.

그런 다음 IP 주소 대상을 입력합니다. 로드 밸런서를 호스팅하는 VPC에서 가져올 수 있습니다.

또는 로드 밸런서를 호스팅하는 VPC 외부 대상에 대해 위에 나열된 개별 범위 중 하나로다른 개인 IP 주소일 가능성도 있습니다.

설정을 검토하고 로드 밸런서를 만든 후, 상태 확인을 통과하자마자 지정된 IP 주소로 트래픽이 전송됩니다. 각로드 밸런서는 최대 1000 개의 대상을 수용 할 수 있습니다.

타겟 그룹을 검토하고 언제든지 타겟 세트를 편집 할 수 있습니다.

위에서 처럼 스크린 샷을 찍었을 때, 타겟 중 하나가 문제 가 생긴 경우, (이것은 의도적으로 설계임) 각 대상 그룹에 대한 통계가 CloudWatch에 게시됩니다. 콘솔에서 볼 수 있으며 CloudWatch Alarms를 만들 수 있습니다.

정식 출시
이 기능은 현재 사용 가능하며 모든 AWS 리전에서 즉시 사용할 수 있습니다.

— Jeff;