Category: Compute


딥러닝용 P2 인스턴스 타입, 서울 리전 출시

최근 인공 지능에 대한 관심이 높아짐에 따라 활용 요구가 높은 기계 학습 및 딥러닝(Deep Learning), 유체 역학 컴퓨팅 연산, 지진파 분석, 분자 모델링, 유전학 및 금융 분석 등 대량 컴퓨팅 연산에 도움이 될 P2 인스턴스 타입을 서울 리전에 오늘 출시하였습니다.
P2 인스턴스 타입은 8 NVIDIA Tesla K80 Accelerators (각각 2개의 NVIDIA GK210 GPU)을 지원합니다. 각 GPU는 12GB 메모리를 가지고 있으며 (초당 240GB 메모리 대역폭 제공) 2,496개의 병렬 코어를 지원합니다. 또한, 더블 비트 오류를 검출해서 싱글 비트 오류를 고치는 ECC 메모리 보호 기능을 지원합니다. ECC 메모리 보호 가능 및 이중 플로팅 포인트 기능을 통해 위의 다양한 요구 사항을 수용할 수 있습니다.

아래는 P2 인스턴스 타입 스펙입니다.

Instance Name GPU Count vCPU Count Memory Parallel Processing Cores
GPU Memory
Network Performance
p2.xlarge 1 4 61 GiB 2,496 12 GB High
p2.8xlarge 8 32 488 GiB 19,968 96 GB 10 Gigabit
p2.16xlarge 16 64 732 GiB 39,936 192 GB 20 Gigabit

더 자세히 알아보기

Channy;

신규 EC2 예약 인스턴스 크기 유연성 기능 출시

AWS 고객은 예약 인스턴스(Reserved Instances, RI)를 통해 특정 가용 영역 (AZ)에서 사용할 수 있는 컴퓨팅 용량을 미리 구비함으로서 온디멘드에 대비 최대 75%의 가격 할인을 받을 수 있습니다. 작년에 가용 영역을 넘어 리전(Region) 기반 RI 및 컴퓨팅 용량을 변경할 수 있는 전환 가능 RI을 출시하였습니다. 두 가지 유형의 RI를 통해 인스턴스 관리에 대한 부담을 줄이고, 다양한 워크로드에 따라 유연하게 대응할 수 있습니다.

인스턴스 크기 유연성 제공
3 월 1 일부터 기존 리전 기반 RI가 더욱 유연 해집니다! 모든 리전의 공유된 Linux / UNIX RI는 이제 통합 청구를 통해 여러 계정에서 사용하더라도 인스턴스 제품군 및 AWS 리전 내 모든 인스턴스에 적용됩니다. 이를 통해 RI 관리에 소요되는 시간을 더욱 단축하고, 컴퓨팅 리소스를 더욱 창의적이고 혁신적으로 사용할 수 있습니다.

모든 신규 및 기존 RI는 인스턴스 크기에 기초한 정규화 수치에 따라 크기가 정해집니다.

인스턴스 크기
정규화 수치
nano 0.25
micro 0.5
small 1
medium 2
large 4
xlarge 8
2xlarge 16
4xlarge 32
8xlarge 64
10xlarge 80
32xlarge 256

기존에 c4.8xlarge에 대한 RI를 이미 소유하고 있다고 가정 해 보겠습니다. 이 RI는 리전 내 공유하는 Linux/UNIX C4 인스턴스를 모두 사용할 수 있습니다. 즉, 다음은 모두 같은 사용 방법입니다.

  • 한 개의 c4.8xlarge 인스턴스
  • 두 개의 c4.4xlarge 인스턴스
  • 네 개의 c4.2xlarge 인스턴스
  • 16개의 c4.large i인스턴스

또한, 하나의 c4.4xlarge 인스턴스와 8개의 c4.large 인스턴스 같은 조합도 가능합니다.

실행 중인 인스턴스보다 작은 RI를 소유하고 있는 경우, 초과 분에 대해 비례해서 온디맨드 가격이 부과됩니다. 즉, 여러분은 c4.4xlarge에 대한 RI를 구입해서 사용하지만, 원한다면 c4.8xlarge  인스턴스로 확장할 수 있습니다.  더 큰 인스턴스 크기의 시간당 가격인 온디맨드 비용의 절반 만 지불하면 됩니다. AWS의 목표는 가장 낮은 비용으로 컴퓨팅 자원을 제공하는 것입니다. 큰 인스턴스 크기의 RI를 소유하고, 작은 인스턴스를 실행하는 경우 RI 가격이 작은 인스턴스에 적용됩니다. 그러나, 예약하고 사용하지 않은 부분은 누적되지 않습니다.

정식 출시
신규 예약 인스턴스의 유연한 활용은 지금 바로 사용할 수 있으며, 별도의 설정 없이 모든 리전의 Linux / UNIX RI에 자동으로 적용됩니다.

Jeff;

이 글은 New – Instance Size Flexibility for EC2 Reserved Instances의 한국어 버전입니다.

차세대 I3 인스턴스 타입 출시 – 고성능 I/O를 위한 애플리케이션 지원

지난 AWS re:Invent에서 EC2 Instance 업데이트 소식을 알려드리면서, 향후 새로운 소식을 추가로 알려드리겠다는 말씀을 드렸습니다.

오늘 AWS 서울 리전을 포함하여 총 15 개의 리전에서 아래와 같이 6 가지 종류의 새로운 I3 인스턴스를 출시하게 되었습니다.  I/O 최적 워크로드 용으로 설계된 I3 인스턴스 패밀리는  높은 효율의 NVMe SSD 스토리지를 갖추고 있으며, 4KB 블록에서 최대 330만 IOPS를 제공하고 순차 디스크 처리량에서 최대 16GB/초를 제공 할 수 있습니다. 따라서, 이를 통해 관계형 데이터베이스, NoSQL 데이터베이스, 검색 엔진, 데이터웨어 하우스, 실시간 분석 및 디스크 기반 캐시를 포함하여 높은 I/O 처리량과 낮은 지연 시간을 요구하는 모든 업무에 적합합니다. I2 인스턴스와 비교할 때, I3 인스턴스는 훨씬 저렴하면서 밀도가 높은 스토리지를 제공하며 CPU 코어 당 IOPS 및 네트워크 대역폭이 훨씬 더 많습니다.

I3 스펙 자세히 보기
자세한 스펙은 아래의 표를 참고하시기 바랍니다.

인스턴스타입 vCPU 숫자 메모리
스토리지 (NVMe SSD) 시간당 비용
i3.large 2 15.25 GiB 0.475 TB $0.15
i3.xlarge 4 30.5 GiB 0.950 TB $0.31
i3.2xlarge 8 61 GiB 1.9 TB $0.62
i3.4xlarge 16 122 GiB 3.8 TB (2 volumes) $1.25
i3.8xlarge 32 244 GiB 7.6 TB (4 volumes) $2.50
i3.16xlarge 64 488 GiB 15.2 TB (8 volumes) $4.99

위의 가격은 아시아 태평양 (서울) 리전의 가격표로서, 다른 리전의 자세한 가격은 EC2 요금표를 참고하시기 바랍니다.

I3 인스턴스는 온디멘드, 예약, 스팟 인스턴스로 제공되며 US East (Northern Virginia), US West (Oregon), US West (Northern California), US East (Ohio), Canada (Central), South America (São Paulo), EU (Ireland), EU (London), EU (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Mumbai), Asia Pacific (Sydney) AWS GovCloud (US) 리전에서 제공되며, Dedicated Hosts  및 Dedicated Instances로도 사용 가능합니다.

본 인스턴스는 하드웨어 가상화 (HVM) AMI 만 지원하며 가상 사설 클라우드(VPC) 내에서 실행해야합니다. NVMe 스토리지로 가능한 성능을 얻으려면 다음 운영 체제 중 하나를 실행해야합니다.

  • Amazon Linux AMI
  • RHEL – 6.5 이상
  • CentOS – 7.0 이상
  • Ubuntu – 16.04 또는 16.10
  • SUSE 12
  • SUSE 11 with SP3
  • Windows Server 2008 R2, 2012 R2, 2016

I3 인스턴스는 최대 8개의 NVMe SSD를 제공합니다. 최고 처리량과 가능한 많은 IOPS를 얻으려면 여러 볼륨을 함께 연결하거나 I/O 워크로드를 다른 방법으로 분산시킬 수 있습니다.

각 vCPU (가상 CPU)는 2.3 GHz를 지원하는 Intel E5-2686 v4 (Broadwell)를 탑재하고 있으며, 이들 프로세스는 Turbo Boost 및 NUMA와 함께 AVX2를 지원합니다.

정식 출시
I3 인스턴스는 오늘 부터 사용 가능하며, 서울 리전에서도 바로 사용할 수 있습니다.

Jeff;

이 글은 Now Available – I3 Instances for Demanding, I/O Intensive Applications의 한국어 버전입니다.

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

Amazon EBS 업데이트 – 언제나 자유롭게 볼륨 유형 및 크기 변경 가능

AWS 고객은 서비스를 시작한 후, 사용자 트래픽 및 데이터 사이즈가 증가함에 따라 기존 볼륨을 수정하여 용량을 추가하거나 I/O 성능 특성을 변경해야 할 경우가 생깁니다. 이를 변경하기 위해, 24시간 운영하는 서비스를 중단하는 않고도 바로 변경하고 싶다는 요구 사항을 많이 받았습니다.

특히, AWS는 몇 해에 걸쳐 다양한 케이스를 지원하는 신규 EBS 볼륨 타입을 제공했습니다. 이를 통해 운영 체제에 영향을 주지 않고, 볼륨 유형을 스토리지 계층으로 사용하고 유형을 수정하여 비용을 절감하거나 성능 특성을 변경하여 EBS 볼륨도 탄력적으로 유지하기 바라고 있습니다.

신규 탄력적 볼륨(Elastic Volume) 출시
오늘 탄력적 볼륨이라고 신규 EBS 기능을 출시합니다. 현 EC2 인스턴스에 연결된 모든 EBS 볼륨에서 사용할 수 있습니다. 볼륨을 사용하는 동안, 볼륨 크기를 늘리거나 성능을 조정하거나 볼륨 유형을 변경할 수 있습니다. 변경 사항이 적용하는 동안 응용 프로그램을 계속 사용할 수 있습니다.

이 새로운 기능은 많은 작업을 단순화 해주며, 간단한 API 호출을 사용하여 인스턴스 내 스토리지 인프라를 즉시 변경할 수 있습니다. Elastic Volumes을 사용하여 다음과 같은 시나리오를 해결할 수 있습니다.

  • 신속한 볼륨 유형 변경 – 처음에 인프라를 서둘러 설정하고 블록 스토리지에 General Purpose SSD 볼륨을 사용했습니다. 몇 가지 경험을 쌓은 후에는 처리량 최적화 볼륨이 더 적합하다는 것을 알게 되었을 때, 간단히 볼륨 유형을 변경할 수 있습니다.
  • 급작스런 트래픽 대비 – 월말에 배치 처리로 인해 매월 마지막 3일 동안 트래픽이 10배 급증하면, 해당 월에 적절한 양의 트래픽을 처리하도록 설정된 프로비저닝 IOPS 볼륨에서 관계형 데이터베이스를 실행할 수 있습니다. 탄력적인 볼륨을 사용하여, 유형 변경 후 다시 되돌릴 수 있습니다.
  • 자동 스토리지 증가 – 100 GiB에 대해 볼륨을 설정 한 후, 90% 이상이 저장된 경우 볼륨 크기를 늘리고 중단 없이 파일 시스템을 확장하는 자동화 운영이 가느합니다.

탄력적 볼륨 사용하기
AWS 관리 콘솔, API 호출 또는 AWS 명령 줄(CLI)에서 모든 것을 관리 할 수 ​​있습니다.

콘솔에서 변경하려면 볼륨을 선택하고 Action 메뉴에서 Modify Volume을 선택하십시오.

그런 다음 볼륨 유형, 크기 및 프로비저닝 된 IOPS (필요한 경우)를 원하는 대로 변경하십시오. 여기에서 75 GiB 범용 (gp2) 볼륨을 20,000 IOPS의 400 GiB 프로비저닝 IOPS 볼륨으로 변경합니다.

Modify을 클릭하고, 확인 후 Yes를 클릭하십시오 :

볼륨의 상태는 작업 진행 상황을 반영합니다 (modifying, optimizing, complete):

다음 단계는 추가 저장 영역 공간을 이용할 수 있도록 파일 시스템을 확장하는 것입니다. 이를 수행하는 방법은 Linux에서 EBS 볼륨의 저장소 공간 확장 또는 Windows에서 EBS 볼륨의 저장소 공간 확장 문서를 참조하십시오. 상태가 optimizing로 전환되는 대로 파일 시스템을 확장 할 수 있습니다. (일반적으로 작업을 시작한 후 몇 초 후). 최적화가 최대 24 시간 동안 계속 될 수 있지만 새로운 구성이이 시점에서 적용됩니다. 상태가 optimizing로 바뀌자마자 새 구성에 대한 요금 청구가 시작됩니다 (수정 자체는 무료입니다)

자동 탄력적 볼륨 작업 방법
콘솔에서 수동으로 변경하는 것보다, 다음과 같은 경우에 자동화를 통한 운영 부담을 감소하는 것도 좋습니다.

  • 최적의 볼륨 크기 조정 – CloudWatch 알람을 사용하여 IOPS 한도에서 실행 중인 볼륨을 감시할 수 있습다. 추가 IOPS를 제공하거나 볼륨 유형을 변경할 수 있는 작업 방법을 만들거나 CloudWatch에 “여유 공간” 측정 항목을 추가하고, 볼륨 및 파일 시스템의 크기를 조정하는 할 수 있습니다.
  • 비용 절감 – 통계치를 활용하여 불필요한 IOPS를 줄이거나 더 저렴한 볼륨 유형으로 자주 바꿀 수 있습니다. 이를 통해 스토리지 운영에 드는 비용을 절감하면서도, 최적화된 볼륨 운영 할 수 있습니다.

이러한 프로세스를 자동화하는 방법을 보여주기 위해 CloudWatch Events, AWS Lambda, EC2 Systems Manager 및 PowerShell 스크립팅을 사용하는 샘플을 작성했습니다. 본 규칙은 EBS에서 생성한 modifyVolume이벤트를 기반으로 logEvents Lambda 함수를 호출합니다.

본 람다 함수는 볼륨을 찾아 EC2 Systems Manager가 관리하는 인스턴스에 연결되어 있는지 확인한 다음, 인스턴스에 “maintenance tag”를 추가합니다.

from __future__ import print_function
import boto3
ec2 = boto3.client('ec2')
ssm = boto3.client('ssm')
tags = ['maintenance']

def lambda_handler(event, context):
    volume = [event['resources'][0].split('/')[1]]
    attach = ec2.describe_volumes(VolumeIds=volume)['Volumes'][0]['Attachments']
    if attach:
        instance = attach[0]['InstanceId']
        filters = [{'key': 'InstanceIds', 'valueSet': [instance]}]
        info = ssm.describe_instance_information(
            InstanceInformationFilterList=filters)['InstanceInformationList']
        if info:
            ec2.create_tags(Resources=[instance], Tags=tags)
            print('{} Instance {} has been tagged for maintenance'.format(info[0]['PlatformName'], instance))

나중에 (수동 또는 일정에 따라) EC2 System Manager는 유지 관리를 위해 태그가 지정된 모든 인스턴스에서 PowerShell 스크립트를 실행하는 데 사용됩니다. 스크립트는 인스턴스의 디스크와 파티션을 보고 모든 드라이브 (파일 시스템)의 크기를 최대 허용 크기로 조정합니다.

foreach ($DriveLetter in $DriveLetters) {
	$Error.Clear()
        $SizeMax = (Get-PartitionSupportedSize -DriveLetter $DriveLetter).SizeMax
}

정식 출시
탄력적 볼륨 기능은 오늘 부터 모든 상용 리전에서 사용 가능합니다. 몇 가지 주요 사례와 인스턴스 타입 제한 사항은 Considerations When Modifying EBS Volumes 글을 참고하시기 바랍니다.

Jeff;

이 글은 Amazon EBS Update – New Elastic Volumes Change Everything의 한국어 번역입니다.

운영 중인 EC2 인스턴스에 IAM 역할 연결하기

AWS Identity and Access Management (IAM)의 역할을 통해 Amazon EC2 에서 실행되는 응용 프로그램이 자동 생성, 배포되는 임시 보안 자격 증명을 사용할 수 있습니다 . 임시 자격 증명을 사용하는 것은 IAM 모범 사례로서 인스턴스에서 직접 키 관리를 하지 않아도 됩니다.

2017-02-aws-iam-ec2-instance

즉, EC2 IAM 역할 적용 기능을 사용하여 장기적인 AWS 액세스 키(Access Key)를 수동 혹은 프로그램에서 직접 관리 할 필요가 없습니다. 얼마 전, IAM 역할을 통해 기존 EC2 인스턴스 응용 프로그램에서 AWS에서 제공하는 임시 보안 자격 증명을 사용할 수 있게 되었습니다. 또한 기존 EC2 인스턴스에 첨부 되어있는 IAM 역할을 변경할 수 있습니다.

이 글에서는 AWS CLI를 사용하여 기존 EC2 인스턴스에 IAM 역할을 손쉽게 변경하는 방법을 소개합니다. 아래는 이 글의 주요 순서입니다.

  1. IAM 역할 생성 하기
  2. EC2 인스턴스에 신규 IAM 역할 추가하기
  3. EC2 인스턴스에서 기존 IAM 역할 변경하기

이 글에서는 새로 만든 IAM 역할을 “YourNewRole”라고합니다. 이 역할과 연관된 인스턴스 프로파일을 “YourNewRole-Instance-Profile” 기존 인스턴스를 “YourInstanceId”라고 하겠습니다. 여기에서는 AWS 명령 줄 인터페이스 (CLI) 설정을 완료하고, IAM 역할을 만들 권한 및 EC2 API를 호출 권한을 가지고 있음을 전제로 하고 있습니다.

1. IAM 역할 생성 하기

참고 : 기존 IAM 역할을 연결할 경우, 이 글 아래의 “EC2 인스턴스에 신규 IAM 역할 추가하기”를 보시기 바랍니다. 또한, AWS 관리 콘솔을 사용하여 IAM 역할을 생성하고 진행하면 됩니다.

AWS CLI에서 IAM 역할을 생성하기 전에 신뢰 정책(Trust policy)을 작성해야합니다. 신뢰 정책은 EC2 등의 AWS 서비스가 응용 프로그램 대신 IAM 역할을 맡도록 허용합니다. 신뢰 정책을 만들려면, 아래 정책을 복사하여 YourNewRole-Trust-Policy.json로 저장 한 텍스트 파일에 붙여 넣습니다.

Json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

신뢰 정책을 만들면 기존 EC2 인스턴스에 연결할 수 있는 IAM 역할을 만들 준비가 되었습니다.

AWS CLI에서 IAM 역할을 만들기:

  1. AWS CLI에서 create-role 명령을 호출하여,  YourNewRole-Trust-Policy.json을 기반으로 YourNewRole이라는 IAM 역할을 생성합니다.
    $aws iam create-role --role-name YourNewRole --assume-role-policy-document file://YourNewRole-Trust-Policy.json
    
  2. 만들어진 IAM 역할에 계정 자원에 대한 접근 권한을 부여하려면, attach-role-policy 명령을 호출합니다. 아래 는 애플리케이션이 Amazon S3 버킷의객체에 대한 읽기 권한이 필요한 경우입니다. 따라서, AWS 관리 정책 중 하나인 AmazonS3ReadOnlyAccess을 사용합니다. AWS 관리 정책에 대한 자세한 내용은 “관리 정책 기술 문서“를 참조하십시오.
    $aws iam attach-role-policy --role-name YourNewRole --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
  3. create-instance-profile 명령 및 add-role-to-instance-profile 명령을 실행하여, IAM 인스턴스 프로파일 “YourNewRole-Instance-Profile“을 만듭니다. 인스턴스 프로파일을 통해 EC2는 IAM 역할 “YourNewRole“을 EC2 인스턴스에 추가할 수 있습니다. 자세한 내용은 “인스턴스 프로파일 사용“을 참조하십시오.
    $aws iam create-instance-profile --instance-profile-name YourNewRole-Instance-Profile
    $aws iam add-role-to-instance-profile --role-name YourNewRole --instance-profile-name YourNewRole-Instance-Profile

“YourNewRole”라는 IAM 역할을 성공적으로 만들었습니다.

2. EC2 인스턴스에 신규 IAM 역할 추가하기

이제 YourNewRole이라는 IAM 역할을 EC2 인스턴스 YourInstanceId에 연결할 준비가 되었습니다. 이제 추가해 보겠습니다.

  1. associate-iam-instance-profile 명령을 호출하여, 새로 생성 된 IAM 역할 “YourNewRole-Instance-Profile”, “YourNewRole” 인스턴스 프로파일을 EC2 인스턴스 “YourInstanceId”에 연결합니다.
    $aws ec2 associate-iam-instance-profile --instance-id YourInstanceId --iam-instance-profile Name=YourNewRole-Instance-Profile
  2. describe-iam-instance-profile-association 명령을 호출하여 IAM 역할이 제대로 인스턴스에 연결되어 있는지 확인합니다.
    $aws ec2 describe-iam-instance-profile-associations
  3. 이제 IAM 역할을 사용하여 AWS 자원에 접근할 수 있도록 애플리케이션을 업데이트하고, 인스턴스에서 보안 키를 삭제할 수 있습니다.

3. EC2 인스턴스에서 기존 IAM 역할 변경하기

기존 IAM 역할의 요구 사항이 변경되어, 기존 EC2 인스턴스에 부여 된 권한을 변경할 필요가 있는 경우 IAM 역할과 관련된 정책을 바꿀 수 있습니다. 새로 변경된 IAM 역할을 사용하는 다른 EC2 인스턴스의 권한도 변경됩니다.대신 replace-iam-instance-profile-association 명령을 호출하여 현재 연결되어있는 IAM 역할 “YourNewRole”다른 IAM 역할을 대체 할 수 있습니다. 아래 예제에서는 “YourCurrentAssociation-id”를 사용하여, 현재 iam-instance-profile-association 인스턴스를 나타내고, “YourReplacementRole-Instance-Profile”을 사용하여 인스턴스에 연결할 대체 인스턴스 프로파일을 나타냅니다. 이 자리 표시자를 적절한 association-id와 계정의 IAM 인스턴스 프로필 이름을 변경하십시오.

$aws ec2 replace-iam-instance-profile-association --association-id YourCurrentAssociation-id --iam-instance-profile Name=YourReplacementRole-Instance-Profile 

참고 : YourCurrentAssociation-id는 describe-iam-instance-profile-associations를 호출하여 얻을 수 있습니다.

이 글에서는 EC2 인스턴스를 다시 시작하지 않고, 기존 EC2 인스턴스에 IAM 역할을 추가 혹은 변경하여 애플리케이션이 AWS에서 제공하는 임시 보안 자격 증명을 사용할 수 있습니다. 중요한 애플리케이션 중단 없이 EC2 인스턴스에 연결된 IAM 역할을 대체 할 수 있습니다.

이 게시물에 대한 의견이나 질문이나 제안이 있으시면, IAM 포럼에서 의견 주시기 바랍니다.

– Apurv;

이 글은 New! Attach an AWS IAM Role to an Existing Amazon EC2 Instance by Using the AWS CLI의 한국어 번역입니다.

Elastic Network Adapter를 활용한 고성능 네트워크 구성하기

많은 고객 분들은 네트워크 성능을 최대한 활용하기를 원합니다. Amazon EC2는 다양하고 새로운 인스턴스 타입을 지속적으로 추가하고 있습니다. AWS는 CC1 instance를 시작으로 10Gbps 네트워크를 채택하고 Enhanced Networking 기능을 소개했습니다. Enhanced Networking은 Intel 82599 VF Interface와 SR-IOV 기술을 활용합니다. I/O 성능은 높이고, CPU자원 소모는 줄일 수 있습니다. 더 넓은 네트워크 대역폭을 지원하며, PPS(Packet per second) 성능이 뛰어나고 인스턴스간의 통신 시 Latency도 낮습니다.

최근 고객 분들의 여러 의견을 듣고 새로운 기술을 활용해 Elastic Network Adapter(ENA)를 채택한 새로운 인스턴스 타입들을 추가했습니다. vCPU가 점점 많아지면서 vCPU의 리소스를 보다 효과적으로 분산하여 사용하여 성능을 높일 수 있는 기술입니다. ENA를 활용하기 위해서는 몇가지 설정이 필요합니다. 쉽게 설정 하실 수 있도록 구성하는 방법을 소개해 드립니다.

Elastic Network Adapter(ENA)를 지원하는 EC2 인스턴스
2016년 12월 현재 ENA는 최대 20Gbps 네트워크 성능을 지원하며, P2, R4, X1, 그리고 m4.16xlarge에서 ENA를 지원하고 있습니다. 또한 최신 Amazon Linux HVM AMI(Amazon Machine Image)는 기본적으로 ENA를 사용할 수 있도록 구성되어 있습니다.

Elastic Network Adapter(ENA) 활성화 하기
Amazon Linux의 이전 버젼 또는 다른 Linux 배포판의 경우 ENA를 사용하기 위해서는 아래와 같이 설정이 필요합니다. 이 블로그에서는 RedHat Enterprise Linux Server 7.3 AMI를 를 사용해 x1.16xlarge 인스턴스를 구동했습니다. Public IP와 Key file을 이용하여 인스턴스에 SSH 접속합니다.

$ ssh -i {$key_file} ec2-user@54.161.110.6
[ec2-user@ip-10-10-10-10 ~]$
[ec2-user@ip-10-10-10-10 ~]$ uname -na
Linux ip-10-10-10-10.localdomain 3.10.0-514.el7.x86_64 #1 SMP Wed Oct 19 11:24:13 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux
[ec2-user@ip-10-10-10-10 ~]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.3 (Maipo)
launching_x1_instance

X1 인스턴스 구동

1. ENA 드라이버 확인하기
아래 명령으로 현재 ENA 드라이버가 설정되어 있는지 확인합니다. Vif라고 이름이 나온다면 현재는 기본 Driver로 ENA를 사용할 수 없는 상태입니다.

[ec2-user@ip-10-10-10-10 ~]$ ethtool -i eth0
driver: vif
version:
firmware-version:
expansion-rom-version:
bus-info: vif-0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

2. Linux 최신 업데이트 하기
아래 명령으로 Linux의 설치된 패키지들을 최신으로 업데이트합니다. 업데이트 완료 후 intstance를 reboot 합니다.

[ec2-user@ip-10-10-10-10 ~]$ sudo yum update -y
Loaded plugins: amazon-id, rhui-lb, search-disabled-repos
Resolving Dependencies
--> Running transaction check
---> Package NetworkManager.x86_64 1:1.4.0-12.el7 will be updated
---> Package NetworkManager.x86_64 1:1.4.0-13.el7_3 will be an update
---> Package NetworkManager-config-server.x86_64 1:1.4.0-12.el7 will be updated
---> Package NetworkManager-config-server.x86_64 1:1.4.0-13.el7_3 will be an update
---> Package NetworkManager-libnm.x86_64 1:1.4.0-12.el7 will be updated
---> Package NetworkManager-libnm.x86_64 1:1.4.0-13.el7_3 will be an update
---> Package NetworkManager-team.x86_64 1:1.4.0-12.el7 will be updated
---> Package NetworkManager-team.x86_64 1:1.4.0-13.el7_3 will be an update
---> Package NetworkManager-tui.x86_64 1:1.4.0-12.el7 will be updated
---> Package NetworkManager-tui.x86_64 1:1.4.0-13.el7_3 will be an update
………

3. 드라이버 다운로드
Github 에 공개되어 있는 ENA Linux driver 를 git 툴을 통해 가져옵니다. 그리고 컴파일을 위해서 gcc와 kernel-devel 패키지를 설치합니다.

[ec2-user@ip-10-10-10-10 ~]$ git clone https://github.com/amzn/amzn-drivers
Cloning into 'amzn-drivers'...
remote: Counting objects: 57, done.
remote: Total 57 (delta 0), reused 0 (delta 0), pack-reused 57
Unpacking objects: 100% (57/57), done.

드라이버를 컴파일 하기 위해 gcc 컴파일러와 Kernel-devel 패키지를 먼저 설치합니다.

[ec2-user@ip-10-10-10-10 ena]$ sudo yum install gcc -y
Loaded plugins: amazon-id, rhui-lb, search-disabled-repos
Resolving Dependencies
--> Running transaction check
---> Package gcc.x86_64 0:4.8.5-11.el7 will be installed
--> Processing Dependency: cpp = 4.8.5-11.el7 for package: gcc-4.8.5-11.el7.x86_64
--> Processing Dependency: glibc-devel >= 2.2.90-12 for package: gcc-4.8.5-11.el7.x86_64
--> Processing Dependency: libmpc.so.3()(64bit) for package: gcc-4.8.5-11.el7.x86_64
--> Processing Dependency: libmpfr.so.4()(64bit) for package: gcc-4.8.5-11.el7.x86_64
….
[ec2-user@ip-10-10-10-10 ena]$ sudo yum install kernel-devel -y
Loaded plugins: amazon-id, rhui-lb, search-disabled-repos
Resolving Dependencies
--> Running transaction check
---> Package kernel-devel.x86_64 0:3.10.0-514.2.2.el7 will be installed
--> Finished Dependency Resolution

4. 드라이버 컴파일
드라이버 소스 코드가 있는 디렉토리로 이동합니다. 그리고 make명령을 통해서 driver를 compile합니다.

[ec2-user@ip-10-10-10-10 ena]$ make
make -C /lib/modules/3.10.0-514.2.2.el7.x86_64/build M=/home/ec2-user/amzn-drivers/kernel/linux/ena modules
make[1]: Entering directory `/usr/src/kernels/3.10.0-514.2.2.el7.x86_64'
CC [M]  /home/ec2-user/amzn-drivers/kernel/linux/ena/ena_netdev.o
CC [M]  /home/ec2-user/amzn-drivers/kernel/linux/ena/ena_ethtool.o
CC [M]  /home/ec2-user/amzn-drivers/kernel/linux/ena/../common/ena_com//ena_com.o
CC [M]  /home/ec2-user/amzn-drivers/kernel/linux/ena/../common/ena_com//ena_eth_com.o
CC [M]  /home/ec2-user/amzn-drivers/kernel/linux/ena/ena_sysfs.o
LD [M]  /home/ec2-user/amzn-drivers/kernel/linux/ena/ena.o
Building modules, stage 2.
MODPOST 1 modules
CC      /home/ec2-user/amzn-drivers/kernel/linux/ena/ena.mod.o
LD [M]  /home/ec2-user/amzn-drivers/kernel/linux/ena/ena.ko
make[1]: Leaving directory `/usr/src/kernels/3.10.0-514.2.2.el7.x86_64'

컴파일이 완료되면 ena.ko 드라이버 파일이 생성됩니다. Modinfo 명령으로 드라이버를 확인합니다.

[ec2-user@ip-10-10-10-10 ena]$ modinfo ena.ko
filename:       /home/ec2-user/amzn-drivers/kernel/linux/ena/ena.ko
version:        1.1.2
license:        GPL
description:    Elastic Network Adapter (ENA)
author:         Amazon.com, Inc. or its affiliates
rhelversion:    7.3
srcversion:     25093B15753CC7D0357E01C
alias:          pci:v00001D0Fd0000EC21sv*sd*bc*sc*i*
alias:          pci:v00001D0Fd0000EC20sv*sd*bc*sc*i*
alias:          pci:v00001D0Fd00001EC2sv*sd*bc*sc*i*
alias:          pci:v00001D0Fd00000EC2sv*sd*bc*sc*i*
depends:
vermagic:       3.10.0-514.2.2.el7.x86_64 SMP mod_unload modversions
parm:           debug:Debug level (0=none,...,16=all) (int)

5. 드라이버 설치 및 로드 설정
현재 makefile에서는 make install은 구성되어 있지 않습니다. README파일을 참조하여 아래와 같이 부팅 시 드라이버가 로드될 수 있도록 설정하고 드라이버를 리눅스의 드라이버 모듈 디렉토리 밑으로 복사합니다.

      1. sudo vi /etc/modules-load.d/ena.conf 로 ena.conf생성
      2. ena.conf 파일에 ena 입력 후 저장
      3. sudo cp ena.ko /lib/modules/`uname -r`/ 로 드라이버 복사
      4. sudo depmod 드라이버 디펜던시 체크
      5. reboot OS

6. 인스턴스 enaSupport 설정 활성화
인스턴스의 enaSupport 설정값을 변경하기 위해서는 먼저 인스턴스를 Stop합니다. Stop이 완료 된 후에, 아래와 같은 명령으로 enaSupport를 활성화합니다.

$ aws ec2 modify-instance-attribute --instance-id instance_id --ena-support

7. 인스턴스 Start
이제 인스턴스를 다시 시작하면 ENA가 활성화되어 사용할 수 있습니다. 아래 명령으로 직접 확인할 수 있습니다.

[ec2-user@ip-10-10-10-10 ~]$ ethtool -i eth0 
driver: ena 
version: 1.1.2 
firmware-version: 
expansion-rom-version: 
bus-info: 0000:00:03.0 
supports-statistics: yes 
supports-test: no 
supports-eeprom-access: no 
supports-register-dump: no 
supports-priv-flags: no

본 글은 아마존웹서비스 코리아의 솔루션즈 아키텍트가 국내 고객을 위해 전해 드리는 AWS 활용 기술 팁을 보내드리는 코너로서, 이번 글은 김일호 솔루션즈 아키텍트께서 작성해주셨습니다.
andy_kim_photo

AWS IPv6 업데이트 – 서울 리전 포함 글로벌 및 지원 서비스 확대

AWS는 이미 Elastic Load Balancing, AWS IoT, AWS Direct Connect, Amazon Route 53, Amazon CloudFront, AWS WAF, S3 Transfer Acceleration 기능을 시작으로 지난 몇 년 동안 여러 가지 AWS 여러 부분에 IPv6 지원을 추가하기 위해 노력해 왔습니다. 지난 달 (오하이오 리전을 시작으로) VPC 기반 EC2 인스턴스의 IPv6 지원을 시작하였습니다.

오늘 부터 VPC에서 EC2 인스턴스에 대한 IPv6 지원은 총 15 개 리전에서 사용 가능하며, 9 개 리전에서 IPv6에 대한 Application Load Balancer 지원이 제공됩니다.

이제 IPv6 주소를 사용하여 서버, 개체 저장소, 부하 분산 및 콘텐츠 배포 서비스와 통신 할 수 있는 응용 프로그램을 손쉽게 구축하고 배포 할 수 있습니다. Apple 및 다른 모바일 기기 공급 업체의 IPv6 지원에 대한 최신 지침에 따라 모바일 응용 프로그램은 AWS와 통신 할 때 IPv6 주소를 사용할 수 있습니다.

총 15개 리전에서 IPv6 지원 시작
기존 및 신규 VPC에서 EC2 인스턴스에 대한 IPv6 지원은 현재 미국 동부 (버지니아 북부), 미국 동부 (오하이오), 미국 서부 (캘리포니아 북부), 미국 서부 (오레곤), 남아메리카 (상파울루), 캐나다 아시아 태평양 (서울), 아시아 태평양 (시드니), 아시아 태평양 (뭄바이), AWS (아시아 태평양 지역), 아시아 태평양 지역 GovCloud (미국) 리전에서 사용 가능합니다.

새 VPC를 만들 때 AWS 관리 콘솔에서 IPv6을 활성화 할 수 있습니다.

Application Load Balancer 지원
미국 북동부 (버지니아 북부), 미국 서부 (캘리포니아 북부), 미국 서부 (오레곤), 남아메리카 (상파울루), EU (아일랜드), 아시아 태평양 (도쿄), 아시아 태평양 (싱가포르), 아시아 태평양 (Sydney) 및 AWS GovCloud (US) 리전은 IPv6를 듀얼 스택 모드로 지원하므로 IPv4 또는 IPv6을 통해 접근 할 수 있습니다 (몇 주 이내에 나머지 리전에 대한 지원이 추가 될 예정입니다).

ALB를 구성 할 때 dualstack 옵션을 활성화 한 다음 보안 그룹이 요구 사항에 따라 IPv6 트래픽을 허용하거나 거부하는지 확인하십시오. 듀얼 스택 옵션을 선택하는 방법은 다음과 같습니다.

set-ip-address-type 명령을 실행하거나 SetIpAddressType 함수를 호출하여 옵션을 활성화 할 수도 있습니다. 이 새로운 기능에 대한 자세한 내용은 Load Balancer Address Type 설명서를 참조하십시오.

AWS IPv6 지원 현황 요약
VPC에서 EC2 인스턴스에 대한 IPv6 지원 시작에 앞서 이미 다양한 IPv6 지원을 제공하고 있으며, 상세 내용은 다음과 같습니다.

  • Amazon CloudFront, WAF 및 S3 Transfer Acceleration -개별 CloudFront 배포 지점에 IPv6 지원을 사용할 수 있습니다. 새로 생성 된 배포 지점은 기본적으로 IPv6을 지원하며, 기존 배포판은 업그레이드 할 수 있습니다 (Route 53 별칭 레코드를 사용하는 경우 도메인에 AAAA 레코드도 추가해야 합니다). IPv6 지원을 사용하면 새 주소가 CloudFront Access Logs에 표시됩니다.  AWS WAF를 사용하여 IPv4 또는 IPv6 주소를 통해 오는 요청을 검사하고, S3 Transfer Acceleration을 위한 새로운 이중 스택 엔드 포인트를 사용할 수도 있습니다.
  • Amazon Route 53 -IPv6을 통한 DNS 쿼리에 대한 지원을 추가했습니다. (필수 AAAA 레코드에 대한 지원이 이미 마련 있습니다). IPv6 엔드 포인트 상태 검사를 지원하므로 엔드 포인트의 상태를 모니터링하고 DNS 장애 조치를 조정할 수 있습니다.
  • AWS IoT -인터넷 연결 장치와 AWS IoT 간의 메시지 교환을 위한 IPv6 지원을 제공합니다.
  • Amazon S3 –  듀얼 스택 엔드 포인트를 통한 S3 버킷 접근 지원이 가능합니다.
  • Elastic Load Balancing – Elastic Load Balancer를 위해 공개라우팅 가능한 IPv6 주소를 지원합니다.
  • AWS Direct Connect – 공개 및 비공개 VIF (가상 인터페이스)에서 단일 및 이중 스택 구성을 지원합니다.

Jeff;

이 글은 AWS IPv6 Update – Global Support Spanning 15 Regions & Multiple AWS Services의 한국어 번역입니다.

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

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

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

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

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

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

각각을 살펴봅시다..

Run Command 개선 사항

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

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

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

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

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

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

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

State Manager

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

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

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

Parameter Store

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

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

Maintenance Window

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

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

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

Software Inventory

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

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

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

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

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

AWS Config Integration

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

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

Patch Management

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

다음은 저의 기준입니다:

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

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

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

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

Automation

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

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

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

– Jeff;

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

AWS 2016년 12월 31일 윤초 대응 방법

2016년말 새해를 맞이하기 전 1초를 추가하는 윤초가 시행됨을 잊지 마시기 바랍니다.

이번 윤초 (통산 27 번째)는 UTC(세계 표준시) 2016년 12월 31일 23:59:60으로 삽입됩니다 (한국 표준시로 2017년 1월 1일 8:59:60). 이는 지구 시간(협정 세계시)과 태양시(천문시)과의 차이를 줄이기 위해 진행되며, UTC 기준 올해 마지막 1분은 61가 됩니다.

이전에 윤초를 진행할 때 드린 정보(AWS에서 윤초 대응)은 계속 유효하며, 이번에도 마찬가지로 처리되지만 약간의 차이가 있습니다 :

AWS 조정 시간 (AWS Adjusted Time) – 윤초 삽입 전후의 24시간 동안 윤초의 1초를 조금씩 분산합니다(UTC에서 12월 31일 11:59:59부터 2017년 1월 1일 12:00:00까지). AWS 조정 시간과 세계 시간은 이 기간이 끝난 후 동기화합니다.

Microsoft Windows – Amazon에서 제공 된 Microsoft Windows AMI를 이용하고 있는 인스턴스는 AWS 조정 시간에 따릅니다.

Amazon RDS – 대부분 Amazon RDS 인스턴스(UTC로 설정되어있는 경우) “23:59:59″을 두 번 기록합니다. 그러나 Oracle 11.2.0.2, 11.2.0.3, 12.1.0.1는 AWS 조정 시간에 따릅니다. Oracle 11.2.0.4 및 12.1.0.2에 대한 자세한 정보가 필요한 경우 AWS 지원에 문의하십시오.

자세한 정보
윤초 삽입에 대한 질문이있는 경우AWS SupportEC2 Forum에 문의해 주시기 바랍니다.

Jeff;

이 글은 Look Before You Leap – December 31, 2016 Leap Second on AWS의 한국어 번역입니다.