Category: Compute


AWS Lambda기반 VPC 지원 활용하기

지난 2월 블로그 글을 통해 AWS Lambda의 VPC 지원 기능을 소개해 드렸습니다. Lambda 함수를 통해 Amazon Redshift 데이터웨어 하우스, Amazon ElastiCache 클러스터, Amazon Relational Database Service (RDS) 인스턴스 및 특정 VPC 내에서만 접근할 수 있는 서비스 엔드 포인트에 접근할 수 있습니다. 이를 위해 자신의 VPC를 하나 선택하고 적절한 서브넷과 보안 그룹을 지정하면 됩니다. Lambda 함수가 VPC 내의 리소스에 접근할 수 있도록 하기 위해 Lambda는 이러한 정보를 바탕으로 Elastic Network Interfaces (ENI)와 사설 IP 주소를 지정합니다.

먼저 AWS Lambda 함수 설정시, 아래 그림과 같이 VPC 사용 여부를 정할 수 있습니다.

VPC 지원을 선택하면, VPC내 서브넷(Subnet)에 생성한 서비스, 예를 들어 RDS, Elasticache에 대해 접근이 가능하게 해주는 기능입니다. VPC 지원을 선택하면, 어떤 VPC를 선택할지 그 내부에 어떤 서브넷을 지원할 지를 선택할 수 있도록 해줄 수 있습니다. 이렇게 되면 선택된 서브넷에서는 람다를 위한 ENI가 생성되고 이를 통해 람다는 각 서브넷과 통신을 하게 됩니다.

본 기능이 만들어진 배경은 프라이빗 서브넷 안에 존재하는 리소스에 접근하기 위함입니다. 예를 들어, RDS나 Redshift 같은 서비스를 프라이빗 서브넷 안에 만들고 특정 작업을 하기 위해 람다를 이용해서 접근을 해야 한다고 생각해봅시다. 과거에는 불가능했기 때문에 RDS나 Redshift를 퍼블릭 서브넷에 두어야 했다. 이 경우 보안상의 문제로 인해서 문제가 될 수 있습니다.

그런데, 이렇게 VPC 를 지원하게 되면 람다는 VPC의 선택된 서브넷만 접근을 할 수 있게 됩니다. 사용자 입장에서는 하나의 람다 함수 안에서 RDS 나 Elasticache의 정보를 조회한 이후에 SNS에 메시지를 보낸다던가 S3에 특정 작업을 하고 싶을 수 있습니다. 이런 경우 프라이빗 서브넷에서 퍼블릭 망으로 접근 할 수 있는 기능이 존재해야 한합니다. 이를 위해 프라이빗 서브넷 안에 NAT 역할을 하는 인스턴스 혹은 NAT Gateway가 설정되어 있어야 합니다.

이번 글에서는 VPC 지원 활성과 퍼블릭 네트워크로 접근을 하는 기능 구현에 대해 알아보고자 아래 샘플 코드를 참고하겠습니다.

const AWS = require('aws-sdk');

exports.handler = (event, context, callback) => {
 console.log("\n\nLoading handler\n\n");
    var sns = new AWS.SNS();
    
    // req1();

    sns.publish({
        Message: 'Test publish to SNS from Lambda',
        TopicArn: 'arn:aws:sns:us-east-1:550622896891:crr-virginia-topic'
    }, function(err, data) {
        if (err) {
            console.log(err.stack);
            return;
        }
        console.log('push sent');
        console.log(data);
        context.done(null, 'Function Finished!');  
    });
};

var http = require('http');

function req1()
{
    var options = {
      host: 'amazon.com',
      path: '/',
      port: '80',
      //This is the only line that is neindew. `headers` is an object with the headers to request
      headers: {'custom': 'Custom Header Demo works'}
    };
    
    var req = http.request(options, function(response) {
      var str = ''
      response.on('data', function (chunk) {
        str += chunk;
      });
    
      response.on('end', function () {
        console.log(str);
      });
    });
    req.end();
};

우선 VPC 설정을 합니다. 아래 그림은 VPC와 서브넷의 설정 화면이다. 여러분이 원하는 대상을 지정하면 됩니다.

이제 다음으로 중요한 것은 프라이빗 서브넷에 NAT를 설정하는 것입니다. 손쉽게 설정하는 방법은 AWS의 NAT Gateway를 이용합니다. NAT Gateway는 VPC 메뉴 중에 존재하며, 아래 그림은 새롭게 NAT Gateway를 생성하는 화면입니다. 여기서 원하는 프라이빗 서브넷을 선택해서 생성합니다.

생성한 NAT Gateway를 활용하기 위해서 Route Tables에서 라우팅 정보를 추가하면 모든 설정은 끝납니다. 아래 그림은 라우팅 정보를 세팅한 모습입니다.

이제 테스트를 진행할 차례입니다. 람다 함수에도 테스트 기능이 존재하며, Req1() 함수만을 활성화 한 후에 테스트를 해봅시다. 람다 함수의 테스트 버튼을 눌러 하단의 Log output 화면에서 아래와 같은 결과가 나오면 성공한 것이다.

AWS Lambda의 VPC 지원 기능은 사용자에게 보안과 유연성이라는 두 장점을 같이 제공합니다. 더 자세한 사항은 Configuring a Lambda Function to Access Resources in an Amazon VPCVPC NAT Gateway 설명서를 참고하세요.

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

EC2 Run Command 서울 리전 기능 출시

작년 EC2 Run Command – 대규모 원격 인스턴스 관리 기능을 출시하였습니다. 이 기능은 개발자 및 시스템 관리자들이 좀 더 편리하게 여러 EC2 인스턴스를 관리하는데 도움을 주기 위한 것입니다. 오늘 부터, 서울 리전에 EC2 Run Command 기능을 시작할 수 있게 되었습니다.

더 자세한 것은 아래 블로그 글을 참고하시기 바랍니다.

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

서버리스 컴퓨팅(Serverless computing)은 AWS 고객 사이에 가장 인기있는 주제입니다. AWS가 제공하는 AWS LambdaAmazon 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 logschalice 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의 한국어 번역입니다.

EC2 Run Command 신규 기능 – 하이브리드 환경을 위한 외부 서버 관리 제공

작년 EC2 Run Command – 대규모 원격 인스턴스 관리 기능을 출시하였습니다. 이 기능은 개발자 및 시스템 관리자들이 좀 더 편리하게 여러 EC2 인스턴스를 관리하는데 도움을 주기 위한 것입니다. 이전 글에서 말씀드린대로, 원하는 명령을 선택한 인스턴스에 함께 제공할 수 있습니다. EC2 Run Command는 실행 결과를 통해 각 인스턴스에서 잘 실행이 될 수 있는지를 확인할 수 있고, 지난 달에는 명령어 목록을 생성, 관리 및 공유 하는 기능 역시 공개하였습니다.

많은 고객들이 이 기능을 유용하게 사용하고 있으며, 아래는 그 목록 중 하나입니다.

  • 인스턴스 내 로컬 사용자 및 그룹 생성
  • 설치되지 않은 윈도 업데이트가 있는지 확인하기
  • 모든 필수 윈도 업데이트를 바로 업데이트하기
  • 특정 데몬 및 서비스 시작, 중지 및 재시작 하기
  • 패키지 및 애플리케이션 설치하기
  • Access 로그 파일 확인하기

하이브리드 및 클라우드 교차 관리 기능
많은 고객분들이 클라우드 뿐만 아니라 온-프레미스 환경의 서버에도 같은 기능을 사용할 수 있기를 요청하셨습니다. 이는 기존 데이터 센터 환경에서 물리 서버를 운용하는 경우, 클라우드 인스턴스와의 통합 관리를 좀 더 편리하게 할 수 있을 것입니다. 고객의 피드백에 따라 Run Command 기능을 EC2 밖에 있는 서버에도 제공할 수 있게 되었습니다.

여러분은 외부의 관리 서버를 Managed Instances라고 지정하고, AWS SSM Agent을 설치 한 후, 각 서버에서 실행만 하면 됩니다. 그러면, 기존에 만들어 둔 명령 목록을 통해 AWS 클라우드 안과 밖의 서버에 모두 Run Command를 실행할 수 있습니다.

에이전트 프로그램이 지원하는 운영체제는 아래와 같습니다.

  • Windows Server (32 and 64 bit) – 2003-2012, including R2 versions (자세히 보기).
  • Linux (64 bit) – Red Hat Enterprise Linux 7.1+, CentOS 7.1+ (자세히 보기).

만약 여러분이 가상 환경 즉, VMware ESXi, Microsoft Hyper-V, KVM 및 다른 하이퍼바이저를 사용한다면, 게스트 운영체제에 에이전트를 설치한 이미지를 사용하실 수 있습니다.

간단한 동작을 위해 에이전트는 원하는 리전에서 SSM 엔드포인트에서 대한 HTTPS 연결만 있으면 됩니다 연결 요청은 바로 접속하거나, 네트워크 설정에 따라 프록시나 게이트웨이를 통할 수도 있습니다. 에이전트가 AWS에 요청을 보내면, SSM API를 접근할 수 있는 IAM 역할을 통해 검증 하기 때문에 첫 외부 서버 설정 및 활성화 할때 IAM 역할을 설정합니다.

에이전트는 AWS에 신원 확인 정보를 보내고, 여기에는 기준에 충적되는 호스트명, 플랫폼 명 및 버전, 에이전트 버전, 서버 IP 주소등이 포함됩니다. 이들 값은 AWS에 안전하게 암호화 되어 저장되며 서버 등록을 해제하면 자동으로 삭제됩니다.

Managed Instances 설정하기
설정 과정은 매우 간단합니다. 아래 단계를 살펴 보시기 바랍니다.

  1. EC2 콘솔을 열어서 Commands 부분을 열어서 Activations에 첫번째 실행 명령을 설정합니다. 이 과정에서 제가 앞서 언급한 IAM 역할을 만들게 됩니다.
  2. 간단한 설명을 입력한 후, 최대 서버 댓수 (1000대 까지 가능)를 설정 합니다. 만료 시점과 콘솔에서 Managed Instances를 추적할 이름을 지정하고 Create Activation를 누릅니다.
  3. Activation Code와 Activation ID를 메모합니다.
  4. SSM Agent 설치 가이드에 따라서 원하는 서버에 설치하고 이전 단계에서 얻어둔 값들을 설정합니다. 아주 간단한 명령어로 에이전트 다운로드, 설치 및 값 설정까지 간단하게 할 수 있습니다.
  5. 이제 콘솔에 돌아가서 Managed Instances선택하면, 사용할 서버의 목록이 나타나고 확인을 하면 됩니다.

Managed Instances에 명령어 실행하기
이제 여러분은 아래와 같이 외부 서버에서 명령을 실행할 수 있습니다.

명령어 실행 상태 및 결과도 콘솔에서 확인할 수 있습니다.

더 자세한 사항은 원격으로 Amazon EC2 인스턴스 관리 도움말 문서를 참고하시기 바랍니다.

정식 출시
본 기능은 Run Command를 사용할 수 있는 US East, West 및 Europe (Islands)에서 사용 가능하며 더 자세한 것은 Run Command 페이지를 참고하시기 바랍니다.

Jeff;

이 글은 EC2 Run Command Update – Hybrid and Cross-Cloud Management의 한국어 번역입니다.

Elastic Network Adapter – EC2 고성능 네트워크 인터페이스 공개

AWS를 이용되는 고객의 대부분은 여러 EC2 인스턴스에 걸쳐 긴밀하게 연결된 시스템을 만들고 사용 가능한 모든 네트워크 대역폭을 효율적으로 활용되고 있습니다. 고객의 사용 형태에 따라서 단기적으로 EC2 처리량에 따른 대역폭 확대를 제공하지만, 장기적으로는 좀 더 견고한 드라이버 수준의 지원이 필요합니다.

오늘 AWS이 매우 일반적인 유스 케이스를 대상으로 지금까지 이상으로 우수한 지원을 제공하는 Elastic Network Adapter (ENA)를 출시했습니다. 새로운 X1 인스턴스 유형을 대상으로하는 ENA는 추가 비용 없이 Placement Group을 통해 낮은 레이턴시로 안정된 성능을 최대 20 Gbps에서 제공합니다. 이를 통해 장기적으로 vCPU 숫자 증가와 네트워크 대역폭에 대한 원활한 확장이 가능합니다.

ENA의 이점
ENA는 X1 인스턴스에서 볼 수있는 최신 프로세서와 함께 작동하도록 설계되어 있습니다. 이러한 프로세서는 다수의 가상 CPU (X1의 경우 128)를 포함하는 네트워크 어댑터 등의 공유 자원을 효율적으로 사용하는 것이 중요합니다. 높은 처리량과 패킷 초당 (PPS)의 성능을 제공하면서 ENA는 수많은 방법으로 호스트 프로세서의 부하를 최소화합니다.

  • 체크섬 생성 – ENA는 하드웨어의 IPv4 헤더 체크섬 생성 및 TCP / UDP 일부 체크섬 생성을 처리합니다.
  • 멀티 큐 장치 인터페이스 – ENA는 여러 전달을 사용하여 큐를 수신하고 내부의 오버 헤드를 줄일 수 있습니다.
  • 수신 측에 의한 실행 – ENA는 적절한 vCPU가 처리하도록 들어오는 패킷을 유도합니다. 따라서 오류를 방지하고 캐시의 효율성을 높일 수 있습니다.

이러한 기능은 가능한 프로세서 워크로드를 가볍게 하여, 네트워크 패킷 생성 또는 처리를 할 vCPU간에 짧고 효율적인 경로를 생성할 수 있습니다.

ENA 사용하기
X1 인스턴스간에 20 Gbps 성능을 실현하려면 플레이스먼트 그룹에서 시작할 수 있습니다. ENA의 또 다른 장점은 낮은 지연 시간과 안정된 성능을 인터넷 상에서 플레이스 그룹 외부와 통신에서 제공합니다. 새로운 ENA 드라이버는 최신 Amazon Linux AMI에서 사용할 수 있습니다. 또한, 조만간 Windows AMI에도 대응할 예정입니다. 오픈 소스 드라이버 코드 역시 Github에 제공하고 있습니다. 드라이버는 Intel® Data Plane Developer Kit (Intel® DPDK)를 사용하여 패킷 프로세스의 성능과 처리량을 향상시킵니다. 직접 AMI를 작성하는 경우 enaSupport 의 속성을 설정하십시오. 코맨드 라인 에서 만드는 방법은 다음을 참조하십시오 (register-image 문서 참고)

Bash
$ aws ec2 register-image --ena-support ...

You can still use the AMI on instances that do not support ENA.

출시 예정
말씀 드린 대로 ENA는 X1 인스턴스가 지원되는 리전에 제공되며, X1 인스턴스의 리전 지원은 계속 확대 될 예정입니다.

Jeff;

이 글은 Elastic Network Adapter – High Performance Network Interface for Amazon EC2의 한국어 번역입니다.

Amazon Elastic File System – 정식 서비스 개시 (3개 리전)

AWS 스토리지 서비스는 시간에 따라서 더 많아지면서 풍부해지고 있습니다.  초기에 Amazon S3 라는 단일 스토리지 서비스를 시작한 이후, 일반적인 스토리지 클래스, 자주 접근하지 않는 경우에 사용하는 스토리지, 백업 및 아케이빙용까지 다양하게 제공하고 있습니다.유사하게, Amazon Elastic Block Store (EBS) 의 경우, 단일 볼륨 타입을 비롯 네 가지 다양한 타입(SAN 스타일 블록 스토리지, 데이터 타입 및 접근 트래픽에 따른 블록 스토리지)을 제공합니다.

객체 스토리지와 블록 스토리지를 S3와 EBS를 통해 제공하는 사이에 파일 시스템에 대한 고객 요구에도 귀를 기울이게 되었으며,  작년에 여러 EC2 인스턴스 사이에 공유할 수 있는 지연속도가 낮은 네트워크 파일 시스템인 Amazon Elastic File System (EFS)에 대한 공개 계획 소식 을 알려드렸습니다.오랜 베타 및 미리보기 서비스를 마치고, 오늘 드디어 Amazon EFS를   US East (Northern Virginia), US West (Oregon)Europe (Ireland) 리전에 우선 공개하게 되었습니다.EFS 미리 보기 기간 동안, 웹 기반의 대용량의 처리량에 높은 워크로드에 대해 콘텐츠 처리를 할 수 있도록 개선을 해왔습니다. 그동안 많은 긍정적인 고객 피드백을 기반으로 성능을 향상하고, 파일 시스템 메타 데이터에 사용량, 데이터 읽기 지연 속도 등에 대한 민감한 워크로드에 대한 개선도 이루었습니다. 오늘 서비스 정식 출시를 통해 다양한 사용 케이스에 대해 더 좋은 서비스를 제공할 수 있게 되었고, 참여 고객사 역시 EFS를 실제 정식 서비스에 활용할 수 있게 되었습니다.

Amazon Elastic File System 소개

Amazon EFS는 여러 대의 EC2 인스턴스에서  네트워크 파일 시스템인 EFS 파일 시스템을 로컬 스토리지 디바이스처럼 접근할 수 있습니다. Amazon EFS를 사용하면 여러 EC2 인스턴스가 동시에 파일 시스템에 액세스하여 하나 이상의 인스턴스에서 실행 중인 워크로드와 애플리케이션에 대한 공통 데이터 소스를 제공할 수 있습니다.

이 분산 데이터 스토리지 설계는 다중 스레드 애플리케이션 및 여러 Amazon EC2 인스턴스에서 동시에 데이터에 액세스하는 애플리케이션이 전체 처리량과 IOPS를 크게 향상할 수 있다는 것을 의미합니다. 빅 데이터 및 분석 워크로드, 미디어 처리 워크플로, 콘텐츠 관리 및 웹 지원을 이러한 애플리케이션의 예로 들 수 있습니다.

또한, Amazon EFS 데이터는 여러 가용 영역으로 분산되어 높은 수준의 내구성과 가용성을 제공합니다.

각 EFS는 단일 VPC에서 접근 가능하며, VPC내에 생성되는 마운트 지점(Mount targets)에서 연결할 수 있습니다.

EFS는 “범용(General Purpose)“과 “최대 I/O(Maximized I/O)” 성능 두 가지의 모드를 제공합니다. “범용” 성능 모드는 대부분 파일 시스템에 적합하며, 파일 시스템을 생성할 때 기본적으로 선택되는 모드입니다. “최대 I/O” 성능 모드는 수십, 수백 또는 수천 개의 EC2 인스턴스가 파일 시스템에 액세스하는 애플리케이션에 최적화되어 있습니다. 파일 작업에 대한 지연 시간이 약간 늘어나는 대신 전체 처리량과 초당 작업 수준이 향상됩니다. 자세한 내용은 파일 시스템 성능에 대한 설명서를 참조하십시오.

Elastic File System  사용해 보기
AWS Management Console, AWS 명령줄 인터페이스(AWS CLI), Amazon EFS API(및 다양한 언어별 SDK)를 통해 파일 시스템을 생성할 수 있습니다.

먼저 콘솔에서 Create file system 버튼을 클릭합니다.

VPC와 함께 서브넷의 마운트 타겟을 생성 합니다.

내 보안 그룹 (corp-vpc-mount-target)에서  EC2 인스턴스가 2049 포트의 마운트 지점에 접근할 수 있도록 설정을 아래와 같이 바꿉니다.

이제 Name 및 Owner tags, 그리고 범용(General Purpose) 성능으로 선택합니다.

설정 내용을 모두 확인 후 Create File System을 선택합니다.

이제 새로운 파일 시스템이 준비 되었습니다. (몇 분 정도 소요 될 수 있음)

이제 EC2 마운트 도움말을 통해 어떻게  EC2 인스턴스에서 연결하는지 잘 살펴 봅니다.

제 인스턴스에서 /efs 디렉토리에 마운트를 하게 됩니다.

여러 개의 파일을 복사해 보면서,  NFS  통계를 살펴 볼 수 있습니다.

콘솔에서는 파일 시스템의 사용 용량 및 다양한 정보를 수집해서 보여 주며, 시간 단위로 수집되어 2-3시간 후에 보여집니다.

CloudWatch 통계 수치
각 파일 시스템에서 CloudWatch를 통해 아래 통계 수치를 수집합니다.

  • BurstCreditBalance – 급격하게 처리량이 높아질 때 대비한 크레딧 수치
  • ClientConnections – 파일 시스템에 접근한 클라이언트 연결 숫자
  • DataReadIOBytes – 파일 시스템 읽기 처리량
  • DataWriteIOBytes -파일시스템 쓰기 처리량
  • MetadataIOBytes – 읽기 및 쓰기 중 메타 데이터 처리량
  • TotalIOBytes – 읽기, 쓰기 및 메타 데이터 등 전체 처리량
  • PermittedThroughput -파일시스템크기에 따른 전체 처리 허용량
  • PercentIOLimit – 범용모드일 때, 허용 가능한 I/O 제한 수치

이들 통계 수치는 CloudWatch 콘솔에서 보실 수 있습니다.

EFS 버스팅 및 성능 모델

파일 시스템에서 지원할 수 있는 처리량은 파일 시스템이 확장됨에 따라 증가합니다. 일반적으로 파일 기반 워크로드는 변동이 심하므로 일정 시간 동안 높은 수준의 처리량이 필요하고 나머지 시간에는 더 낮은 수준의 처리량이 필요합니다. Amazon EFS는 일정 시간 동안 높은 처리량 수준으로 버스트할 수 있도록 설계되었습니다.

모든 파일 시스템은 스토리지의 TB당 50MB/초라는 일관된 기준 성능을 제공하며, 크기와 관계없이 모든 파일 시스템은 100MB/초까지 버스트할 수 있고, 1TB보다 큰 파일 시스템은 스토리지의 TB당 100MB/초까지 버스트할 수 있습니다. 파일 시스템에 데이터가 추가됨에 따라, 파일 시스템에서 지원할 수 있는 최대 처리량은 스토리지와 함께 선형적으로 자동 확장됩니다.

파일 시스템 처리량은 파일 시스템에 연결된 모든 Amazon EC2 인스턴스에서 공유합니다. 예를 들어 처리량을 100MB/초로 버스트할 수 있는 1TB 파일 시스템은 단일 Amazon EC2 인스턴스에서 100MB/초를 지원하거나 10개의 Amazon EC2 인스턴스에서 전체적으로 100MB/초를 지원할 수 있습니다. 자세한 내용은 파일 시스템 성능에 대한 설명서를 참조하십시오.

정식 출시
EFS는 현재 US East (Northern Virginia), US West (Oregon), Europe (Ireland) 리전에 출시하였으며 향후 더 많은 리전으로 확대될 계획입니다. 가격 모델은 여러분이 사용한 데이터 마다 GB당  $0.30 per GB (버지니아 리전 기준)입니다. 최소 비용이나 설정 비용은 없으며 자세한 것은  EFS 요금표 페이지를 참고하시기 바랍니다. 5GB까지 AWS 무료 티어 사용이 가능합니다.

Jeff;

이 글은 Amazon Elastic File System – Production-Ready in Three Regions의 한국어 번역 요약본입니다.

Amazon VPC NAT 게이트웨이 서울 리전 출시

지난해 12월 처음 출시된 Network Address Translation (NAT) Gateway 서비스가 오늘 부터 서울 리전에서 사용 가능합니다.

AWS내 사설 네트워크(VPC)로 구성된 서비스와 외부를 연결하는 주소 변환(NAT)를 제공하기 위해 별도 EC2 인스턴스 설정, 모니터링 및 확장(고 가용성을 위해 적어도 2대는 있어야 함)을 고려하고 운영 하는 대신, 몇 번의 클릭 만으로 NAT 게이트웨이를 설정하고 AWS에 운영을 맡길 수 있는 완전 관리형 서비스입니다.

간단한 사용 방법은 AWS 신규 NAT 게이트웨이 서비스 출시! 블로그 글을 참고하시고, 더 자세한 사용법은 VPC NAT Gateway 한국어 도움말을 살펴 보시기 바랍니다.

서비스 요금은 NAT 게이트웨이 사용 시간 당 $0.059(서울 리전 기준)이며, 데이터 처리 및 전송 비용은 별도입니다. 데이터 처리 비용은 NAT 게이트웨이를 통과하는 양에 따라 달라지며, 데이터 전송 비용은 EC2 인스턴스와 인터넷 망 사이의 요금입니다. 더 자세한 것은 VPC 요금표를 참고하시기 바랍니다.

– AWS코리아 마케팅팀

EC2 전용 호스팅으로 자체 라이센스로 윈도 서버 구동하기

얼마전 서울 리전에 Amazon EC2 전용 호스팅(Dedicated Hosting) 기능을 공개 되었습니다. 이 기능은 고객 전용의 EC2 인스턴스 용량을 갖춘 물리적 서버입니다. 전용 호스팅을 사용하면 기존 서버에 한정된 소프트웨어 라이선스를 사용할 수 있으므로 규정 준수 요구 사항을 해결하면서 비용도 절감할 수 있습니다. (자세한 기능 소개를 참고 하시기 바랍니다.)

오늘은 여러분이 기존 회사나 집에 Microsoft Windows 의 라이센스를 가지고 있고, 그대로 AWS 상에서 사용을 하고자 할 경우, 이 때  소켓 혹은 물리적 코어에 한정된 라이센스 약관을 해결할 수 있는 방법으로 Amazon EC2 전용 호스팅 사용 방법을 알아보겠습니다.

기존 소프트웨어 라이선스에 약관에 따르면, Microsoft Windows Server, Microsoft SQL Server, SUSE Linux Enterprise Server, Red Hat Enterprise Linux  등은 소켓당, 코어당 또는 VM 소트프웨어당 라이선스를 사용할 수 있습니다.

여러분이 전용 호스팅 서버를 선택하면 하나의 물리적인 서버가 할당됩니다. 본인의 EC2 인스턴스를 이 전용 호스트에 올려 실행할 수 있습니다. 즉, 특정 물리 서버에 본인이 원하는 사이즈의 인스턴스를 직접 배치함으로써 제어 및 가시성 역시 강화할 수 있습니다. 금융 등 기업 규정 및 규제가 존재하는 곳에서는 그 요구사항을 충족하는 구성이 가능하게 된다는 점에서 중요한 부분이라 할 수 있습니다.

Amazon EC2 전용 호스트 생성
전용 호스팅으로 본인의 라이선스를 그대로 적용하려면 기존에 운영하던 서버를 그대로 옮겨와야 합니다. 여러분이 Microsoft Windows 서버를 가상환경에서 운영을 하고 있는 경우, 온프레미스 환경의 윈도우 서버 이미지를 VM Import 기능을 이용해서 전용 호스트 위로 이동시킬 수 있습니다.

이 문서에서는VM Import기능을 이용해서 여러분의 윈도우 서버를 전용 호스트로 옮기는 방법을 살펴보도록 하겠습니다.

먼저 전용호스트를 생성합니다. 전용 호스트를 만드는 것은 매우 간단합니다. 콘솔의 EC2 에서 좌측 메뉴를 보면 “dedicated host”란 항목이 존재합니다.


[그림 1] dedicated host 메뉴

dedicated host 메뉴를 들어가서 상단에 존재하는 Allocate Dedicate Host 버튼을 눌러 원하는 전용 호스트를 생성합니다. 생성할 때 인스턴스 타입을 선택하게 되는데, 이는 전용 호스트에 올릴 수 있는 인스턴스 타입을 의미합니다.

m4.large 인스턴스 타입을 선택해서 호스트를 생성한 결과가 그림 2입니다. 하단의 정보를 보면 물리적 코어갯수(Physical Cores), 소켓수(Sockets) 등을 확인할 수 있습니다.


[그림 2] 전용 호스트 생성 모습

Windows VM Import 사전준비
여러분이 가상화 환경을 사용한다면 운용중인 서버 이미지를 생성해서 VM Import를 사용해서 AWS로 이동 시킬 수 있습니다. 작업을 하기 전에 먼저 확인을 해야하는 사항들이 존재합니다. 크게 보면 지원하는 O/S종류와 생성하는 이미지 파일의 포맷입니다. (더 자세한 정보는 기술 문서를 참고하시기 바랍니다.)

여기에는 지원하는 각종 O/S 종류와 지원이 안되는 종류(예를 들어 32비트 버전 Microsoft Windows 2012 R2)등이 자세히 기록되어 있습니다. 지원 이미지 형식은 RAW, 정적 혹은 동적 VHD, 스트림 최적화 ESX VMDK, OVA 형식입니다.

여기서는 OVA이미지 형식으로 만들었다고 가정합시다. (이 단계는 각자의 가상화 환경에 따라 다를 수 있으므로 자세한 기술은 피하도록 하겠습니다. 다만 위에 기술되어 있는 지원 가능한 이미지 형식으로 전환하시기를 바랍니다.)

제 경우는 맥 윈도우 환경에서 vmware fusion을 사용하는 환경에서 OVA를 만들어 보았습니다. 이 경우에는 vmware fusion이 메뉴에서 Export 기능을 지원하지 않아 ovftools을 이용해서 만들었습니다. 명령을 실행하기 위해서는 /Applications/VMware Fusion.app/Contents/Library/VMware OVF Tool 디렉토리로 이동해서 다음과 같은 명령을 실행합니다.

명령의 실행 예는 아래와 같습니다.

$ ./ovftool --acceptAllEulas   /Users/seon/Documents/vmware/win.vmwarevm/win81.vmx /Users/seon/Documents/win81.ova

그 다음은 두 가지를 준비해야 합니다. 생성된 OVA를 Import하기 위한 역할과 이미지가 올라갈 S3 버킷의 설정입니다. 먼저 S3 버킷을 적절히 생성합니다. 여기서는 서울 리전에seon-vmimport-2016 라는 이름으로 생성을 했습니다.

그 다음은 역할을 설정합니다. vmimport라는 역할을 생성합니다. 다음 링크의 json을 이용해서 생성합니다. (더 자세한 것은 기술 문서를 참고하시기 바랍니다.)

명령어는 다음과 같이 실행합니다.

$ aws iam create-role --role-name vmimport --assume-role-policy-document file://trust-policy.json

그 다음은 역할에 적용할 정책입니다. Role-policy.json이란 정책을 적용합니다. 이때 중요한 점은 이 정책에서 앞서 생성한 S3 버킷의 이름을 정확히 지정해서 주어야 한다는 점입니다. 다음 소스에서 붉은 색으로 된 부분이 버킷이름입니다.

{
"Version":"2012-10-17",
"Statement":[
    {
      "Effect":"Allow",
         "Action":[
          "s3:ListBucket",
          "s3:GetBucketLocation"
         ],
      "Resource":[
          "arn:aws:s3:::seon-vmimport-2016"
      ]
},
{
      "Effect":"Allow",
          "Action":[
            "s3:GetObject"
           ],
          "Resource":[
             "arn:aws:s3:::seon-vmimport-2016/*"
           ]
},
{
       "Effect":"Allow",
          "Action":[
            "ec2:ModifySnapshotAttribute",
            "ec2:CopySnapshot",
            "ec2:RegisterImage",
            "ec2:Describe*"
         ],
       "Resource":"*"
   }
  ]
}

다음 명령으로 위의 정책을 역할에 적용합니다. 설명서에 나와 있는대로 role-policy.json 이라는 json 파일을 이용해서 역할을 생성합니다.

$ aws iam put-role-policy --role-name vmimport --policy-name vmimport --policy-document file://role-policy.json

마지막으로 IAM 유저로 작업을 할 경우에는 그에 적절한 권한이 주어져아 하는데, 필요한 권한은 기술 문서를 통해서 확인할 수 있습니다.

VM의 준비
윈도우즈나 리눅스의 경우 해당 이미지를 생성할 때 O/S 내부에서 몇 가지 설정을 바꿔 줄 필요가 있습니다. 예를 들어 윈도우즈의 경우 Vmware tool 을 제거한다든가, RDP 를 활성화 한다던가 하는 작업이 필요합니다. 사전 준비내용은 기술 문서에서 확인할 수 있습니다.

O/S를 이 조건대로 설정한 이후에 이것을 OVA  파일등으로 이미지로 만듭니다. 이후에 앞서 만든 버킷에 업로드를 합니다. 아래 명령을 이용해 앞서 만든 버킷에 올리도록 하겠습니다.

$ aws s3 cp win8.ova s3://seon-vmimport-2016/win8.ova

자 이제 모든 준비가 끝났습니다.

앞서 만든 OVA 파일을 임포트 해보겠습니다. 관련 정보는 기술 문서를 참조하시면 됩니다.

임포트에는 위 올린 버킷의 정보를 기술하는 containter.json을 이용해서 명령을 수행합니다.

[{
  "Description": "First CLI task",
  "Format": "ova",
  "UserBucket": {
  "S3Bucket": "seon-vmimport-2016",
  "S3Key": "win8.ova"
  }
}]

 

명령은 다음과 같습니다.

$ aws ec2 import-image --description "Windows 2008 OVA" --disk-containers file://containers.json

임포트 진행 상태는 다음으로 확인합니다.

$aws ec2 describe-import-image-tasks

응답 예는 다음과 같습니다.

{
"ImportImageTasks": [
  {
    "Status": "active",
    "Description": "Windows 2008 OVA",
    "Progress": "2", 
    "SnapshotDetails": [
      {
        "UserBucket": {
        "S3Bucket": "seon-vmimport-2016",
        "S3Key": "win8.ova"
      },
    "DiskImageSize": 0.0,
    "Format": "OVA"
   }
  ],
  "StatusMessage": "pending",
  "ImportTaskId": "import-ami-fgmj6b"
  }
 ]
}

만약 vmdk 이미지로 여러 파일로 나누어져 있는 형식이라면 container.json 을 다음과 같이 변경하기 바랍니다.

[{
    "Description": "First CLI task",
    "Format": "vmdk",
    "UserBucket": {
       "S3Bucket": "my-import-bucket",
       "S3Key": "my-windows-2008-vm-disk1.vmdk"
    }
},
{
    "Description": "Second CLI task",
    "Format": "vmdk",
    "UserBucket": {
       "S3Bucket": "my-import-bucket",
       "S3Key": "my-windows-2008-vm-disk2.vmdk"
}
}]

status가 completed 로 변경되면, 가져오기가 완료된 것입니다. 완료되면 EC2 콘솔의 전용호스트 메뉴의 “Action”에서 “Launch Instance(s) onto Host” 명령을 실행한후My AMIs 가면 가져오기가 성공한 이미지를 선택해서 런치할 수 있습니다.


[그림 3] 전용 호스트에서 가져온 이미지 런치

vm-import 기능은 한번만 수행해 보면 쉽게 사용할 수 있습니다. 전용 호스트를 사용해서 비용 절감 뿐 아니라 적절한 최적화 인스턴스를 사용하여 성능향상의 혜택까지 누리시길 바랍니다.

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

EC2 인스턴스 콘솔 스크린샷 생성 기능

우리 고객 중에는 Amazon EC2 이미지를 클라우드로 전환 할 때, 드라이버 또는 부팅 파라미터, 시스템 구성, 소프트웨어 업데이트 등으로 인한 문제를 겪은 적이 있습니다. 이러한 문제의 경우, 인스턴스에 RDP(Windows) 또는 SSH (Linux)를 통해 연결할 수 없습니다. 기존 시스템에서는 물리적 콘솔에 로그 메시지와 무슨 일이 일어나고 있는지를 파악하고 이해하는 단서를 찾을 수 있습니다.

이러한 문제를 해결하기 위해, 인스턴스의 상태를 보다 쉽게​​ 시각화 할 수하기 위해 콘솔의 스크린 샷을 생성하고 캡처 할 수 있는 기능을 제공합니다. 인스턴스가 실행 중 또는 문제 발생 후 스크린 샷을 생성 할 수 있습니다.

아래는 콘솔에서 스크린 샷을 생성하는 방법입니다 (인스턴스가 HVM 가상화 사용 필수) :

아래는 그 결과입니다.

윈도우 인스턴스에서도 가능합니다.


AWS CLI 명령어 (aws ec2 get-console-screenshot) 또는 EC2 API (GetConsoleScreenshot)에서도 가능합니다.

정식 출시
이 기능은 US East (Northern Virginia), US West (Oregon), US West (Northern California), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), South America (Brazil)에서 사용 가능하며, 다른 리전에도 계속 확대할 예정입니다.

Jeff

이 글은 EC2 Instance Console Screenshot의 한국어 버전입니다.

AWS 클라우드 기반 Arduino Web Editor 및 Cloud Platform 공개

샌프란스시코에서 열린 Maker Faire 에서 Arduino는 AWS를 기반한 신규 Arduino Web EditorArduino Cloud Platform를 출시하였습니다.

아두이노를 활용하시는 분이시라면, 개발 시 여러 단계가 필요하다는 것을 아실 것입니다. 먼저 PC 시리얼에 보드를 연결하고, 필요한 쉴드(shield)와 Wi-Fi 연결을 한 후, 기본적인 통신이 가능합니다. 또한, 개발 환경을 설치 및 설정 한 후 애플리케이션 개발을 준비합니다. 아두이노 모델에 따라 사용 라이브러리도 다르기 때문에 이러한 모든 설치 작업이 마무리 되어야 마침내 개발 및 디버깅, 테스트가 가능해집니다.

Arduino Code Editor
Arduino Code Editor는 개발을 위한 설치 과정을 단순화 합니다. 웹 브라우저에서 AWS Lambda 및 여러 AWS 서비스를 사용한 웹 에디터를 실행하면, 클라우드 기반으로 프로그램 코드를 작성 및 수정 저장이 가능합니다. (동료들과 공동 작업도 가능합니다). 에디터는 여러분이 가진 보드(네이티브 플러그인이 필요)를 인지하고, 스스로 설정하게 됩니다. 코드에서 사용하는 보드 호환 라이브러리도 설치되고, 코드 역시 클라우드 기반으로 컴파일 되어서 보드로 바로 다운로드 되어 실행 가능한 상태로 됩니다.

좀 더 자세한 사항은 Sneak Peek on the New, Web-Based Arduino Create 문서를 참고하시기 바랍니다.

Arduino Cloud Platform

아두이노는 작은 크기에 낮은 전원에도 프로그램하기 쉽기 때문에 IoT 기기로도 많이 활용됩니다. 또한, 센서나 디스플레이 등에도 연결이 쉽고, 데이터 수집 및 전송에도 용이합니다.

새로운 Arduino Cloud Platform을 통해 아두이노 기술을 활용하여 IoT 애플리케이션을 개발 및 구축하는데 용이합니다. 인터넷에 연결된 다바이스를 통해 센서로 부터 생성된 데이터를 업로드하고, 주어진 명령에 반응하는 등 AWS IoT의 주요 기능을 활용하여, 인터넷 상의 각각의 기능과 소통할 수 있게 됩니다.

AWS 클라우드를 통해 좀 더 손 쉽게 아두이노 보드를 설정하고, 더 빠르게 개발함과 동시에 다양한 아두이노 기기 간의 통신도 더욱 쉽게 되었습니다. 아두이노 개발자라면, 지금 한번 해 보시길 바랍니다!

Jeff;

이 글은 Arduino Web Editor and Cloud Platform – Powered by AWS의 한국어 번역 편집본입니다.