Amazon EC2 | Amazon Web Services 한국 블로그

EC2 Spot Fleets – 신규 자동 스케일링 기능

EC2 Spot Fleet API – 한번에 수천개의 스팟 인스턴스 관리하기 글을 통해 한번의 요청에서 EC2 스팟 인스턴스 집합을 만들 수 있습니다. 스팟 집합 대상 용량을 지정하고 시간 당 입찰 가격을 입력하고, 인스턴스 유형을 선택하면됩니다.

백그라운드 작업을 통해 AWS는 최저가 스팟 인스턴스를 시작하여 필요한 대상 용량 (인스턴스 또는 가상 vCPU의 숫자로 표기)을 유지합니다. 인스턴스 집합 가격 상승으로 종료되면, 그 시점에서 최저가 인스턴스 교체가 시작됩니다.

신규 자동 확장 기능
오늘 스팟 집합 모델에 Auto Scaling을 추가함으로서 기능을 더욱 강화하였습니다. Amazon CloudWatch 메트릭을 기반으로 스팟 집합을 스케일-업 혹은 다운 할 수 있게되었습니다. 본 통계치를 통해 EC2, Amazon EC2 Container Service, 또는 Amazon Simple Queue Service (SQS) 등의 AWS 서비스 역시 사용할 수 있습니다. 또한, 응용 프로그램에서 만든 맞춤 통계수치를 사용하여 자동 스케일링이 시작되도록 할 수도 있습니다. 따라서, 이러한 통계 수치를 사용하여 스팟 집합의 크기 제어, 조건이나 부하가 바뀌더라도 응용 프로그램 가용성 및 성능과 비용을 세부적으로 제어 할 수 있습니다.

아래는 스팟 집합 자동 스케일링에 사용할 수 있는 애플리케이션의 예제들입니다.

콘테이너 동작 – Amazon ECS에서 CPU 및 메모리 사용량을 기반한 콘테이너 기반 애플리케이션의 확장
일괄 작업 – SQS 큐의 메시지 수를 기반한 일괄 작업의 확장
스팟 집합 – MaxPercentCapacityAllocation와 같은 스팟 집합 통계를 기반한 집합 확장
웹 서비스 – 초당 평균 요청 및 반응 시간에 따른 웹 서비스 확장

스팟 인스턴스 콘솔이나 AWS Command Line Interface (CLI), AWS CloudFormation, 및 AWS SDKs API 호출을 자동 스케일링을 설정할 수 있습니다.

잠깐 실제 콘솔에서 설정 방법을 살펴 보고자 합니다. 스팟 집합을 시작하고 이를 스케일업/다운을 하기 위해 Request and maintain 요청 형식을 선택합니다.

스팟 집합이 1분내로 올라옵니다.

예제로 SQS 큐를 만들고 일부 메시지를 큐에 넣은 다음 CloudWatch 알람(AppQueueBackingUp)을 정의했습니다. 메시지 큐에 10 건 이상의 메시지가 들어가면 알람이 시작됩니다.

또한, 알람 (AppQueueNearlyEmpty)도 정의했습니다. 이는 메시지 큐에 메시지가 2 건 이하가 될 때, 취소되는 것입니다.

마지막으로, 알람을 스팟 집합의 ScaleUp과 ScaleDown 정책에 연결했습니다.

이 글을 쓰기 전에 SQS 대기열에 5개의 메시지를 넣었습니다. 스팟 집합을 시작하고 스케일링 정책을 설정한 후, 추가로 5개의 메시지를 보내 알람이 시작되는 것을 기다렸습니다.

스팟 함대 용량이 예상대로 증가한 것으로 나타났습니다. 이 결과는 History 탭에 표시되었습니다 ( “New targetCapacity : 5”).

마무리로 큐에서 모든 메시지를 삭제하고, 돌아 가면 스팟 집합이 예상대로 축소 된것을 알 수 있습니다 ( “New targetCapacity : 2”).

정식 출시
스팟 집합 자동 스케일링 기능은 스팟 인스턴스가 지원되는 모든 리전에서 지금 부터 바로 이용할 수 있습니다.

— Jeff;

본 글은 New – Auto Scaling for EC2 Spot Fleets의 한국어 번역입니다.

AWS 기반 웹 및 애플리케이션 서버 부하 테스트: A to Z

사용자가 이용하고 있는 온라인 서비스로부터 예상치 못한 느려짐을 겪거나, 접속 불가로 인해 서비스 이용 조차 할 수 없다면, 서비스에 중요한 재방문율(Retention Rate)과 유료 전환율(Conversation Rate)을 하락 시켜 비지니스에 큰 손실을 야기 할 수 있습니다. 이런 성능 관련 문제를 예방하기 위해 성능 테스트, 특히 부하 테스트에 대한 중요성이 크게 증가하고 있으며, 더불어 관련 도구 및 서비스의 다양성 또한 증가하고 있습니다.

이번 글은 AWS 클라우드에서 어떻게 웹/애플리케이션 서버의 부하 테스트를 하는지 모범 사례를 알려드리기 위한 것으로, 부하테스트 목적과 고려 사항 그리고 단계 및 도구 등을 대해 다루고자 합니다.

부하 테스트의 목적
일반적으로 부하 테스트는 서비스 개발 이후, 운영을 하기 직전 수행하는 테스트 중 하나로서, 실제 요구되는 부하를 서비스가 수용할 수 있는지를 확인하기 위한 작업 입니다. 사용자 활동을 시뮬레이션 하고 인프라 및 서버의 동작을 모니터링 함으로써, 전부는 아닐지라도, 많은 부분의 병목 현상(Bottleneck)을 제거할 수 있습니다.

부하 테스트의 목적으로는 보통 다음 세가지가 있습니다.

현재 서비스 구성의 제한(limit)을 찾기 위함
원하는 부하를 수용할 수 있게끔 구성되었는지 확인하기 위함
병목 지점을 찾고 병목 현상을 제거하기 위함

부하 테스트 전 고려되어야 할 점
실제 성능 테스트 시, 부하 테스트를 비중 있게 여기지 않는 경우가 많으며, ApacheBench 나 JMeter 와 같은 도구를 다운로드 한 뒤, 특정 시나리오를 기반으로 하여 도구를 실행하는 것만으로 충분하다고 생각하는 경우가 있습니다. 하지만, 실제 워크로드는 다양한 변수와 시나리오를 가지고 있기 때문에, 부하 테스트를 진행할 때 충분히 이점을 반영 하여 야지만 실제 서비스에서 예상 가능한 결과를 가져올 수 있다는 것은 분명한 사실 입니다.

그럼 실용적인 부하 테스트를 위해 어떤 부분들을 고려해야 할까요?

충분한 테스트용 서버 자원 확보: 최대의 트래픽을 생성하여 테스트 하기 위해서는 충분한 서버 자원이 요구되며, 부족할 경우 적절한 테스트가 이루어지기 힘듭니다.
테스트 시, 블랙박스 혹은 격리된 환경 제어: 부하 테스트는 많은 요청과 패킷을 생성하기 때문에 사내 인프라의 많은 부분을 포화 상태로 만들기 쉽습니다. 이를 방지하기 위해 제한된 자원만 할당된 블랙 박스 혹은 격리된 환경에서 테스트를 수행하는 경우가 많습니다.
글로벌 기반의 부하 생성: 글로벌 서비스의 경우, 전 세계 각 지역에서 부하를 생성하여 테스트를 진행하여야만 실제 사용 패턴에 가까운 시나리오가 될 수 있습니다. 이를 통해 글로벌 커버리지를 확인할 수 있으며, 실제 워크로드에서 얻을 수 있는 유사한 각종 성능 관련 지표도 얻을 수 있습니다.
높은 비용과 불규칙적인 사용성에 대한 주의: 격리된 환경과 더불어 여러 리전을 커버하기 위한 테스트 환경은 때로 높은 비용을 요구합니다. 구성된 환경은 짧은 기간 동안만 집중적으로 사용되기도 하며, 안정적인 서비스가 유지될 땐 드물게 사용되기도 하기 때문에, 사용하지 않을 때도 유지하여야 하는 등의 자원을 효율적으로 사용하지 못해 불필요한 비용이 발생 하기도 합니다.
높은 아키텍처 복잡성에 대한 주의: 상기 언급된 부분들을 고려하여 부하 테스트 환경을 구성한다면 꽤나 높은 복잡성이 요구 됩니다. 나아가 반복적인 테스트를 위해, 가상의 가짜(Dummy) 데이터 등에 의해 지저분해진 환경을 초기화 시켜줄 수 있는 방안도 필요 합니다.

AWS 클라우드 기반 부하 테스트의 장점
AWS 클라우드는 부하 테스트를 진행하기 위해 고려할 사항에 대한 적절한 해답을 가지고 있습니다. AWS 클라우드에서 부하 테스트 하게 된다면 어떤 특징을 가지고 있을까요?

사용한 만큼 지불하는 비용 효율성: Amazon EC2 인스턴스는 사용한 만큼만 비용이 발생하기 때문에, 테스트 조건에 맞는 인스턴스 타입을 선택하여 비용 효율성을 높일 수 있습니다. 예를 들어, 정식 부하 테스트를 진행하기 전에 저렴한 마이크로 인스턴스 수십~수백대를 활용하여, 서버 워밍업을 저렴한 비용으로 할 수 있습니다. 또한, 인스턴스 사용이 끝나면 즉시 종료할 수 있어 불필요한 비용 발생을 줄일 수 있습니다.
충분하고 유연한 컴퓨팅 자원 제공: AWS가 제공하는 컴퓨팅 자원을 활용한다면, 필요한 규모의 부하에 대해 자유롭게 테스트를 수행할 수 있습니다. 또한, 오토스케일링(Auto Scaling)을 통해 부하 테스트 시 자원을 자동으로 증설 혹은 감소 시킬 수 있습니다.
글로벌 리전(Region)으로부터의 부하 생성: AWS가 제공하는 글로벌 인프라를 통해 전 세계 각 리전으로부터의 부하 생성을 손쉽게 할 수 있습니다.
쉽고 단순한 아키텍처 구성 및 관리: AWS CloudFormation 을 비롯한 다양한 배포 자동화 서비스 및 기능을 통해 프로덕션과 테스트 용 환경을 동일한 방법으로 손 쉽게 구성할 수 있습니다. 뿐만 아니라 관리형 서비스를 활용하여 운영 측면에서의 부담도 줄일 수 있어, 테스트 환경 구축에 관한 복잡성을 줄일 수 있습니다.

부하 테스트의 단계
부하 테스트는 서비스 전체 스택을 대상으로 진행할 수도 있지만, 최근에는 마이크로서비스(Microservices) 나 서비스 지향 구조(Service-Oriented Architecture) 등의 형태로 서비스를 디자인하는 경우가 많아, 전체 스택을 구성하고 있는 작은 컴포넌트들부터 진행되는 경우가 많아지고 있습니다.

또, 빠른 병목 현상 발견과 수정을 위해, 애플리케이션 로직이 적용되기 전 순수한 인프라 수준에서 시작하여 작은 컴포넌트들, 솔루션, 그리고 애플리케이션 순으로 부하 테스트를 확대해 나갈 수도 있습니다.

아래는 일반적으로 수행할 수 있는 부하 테스트 단계 입니다.

비결합(Loosely Coupled)된 개별 컴포넌트에 대한 부하 테스트: 이를 통해 각 컴포넌트 별 병목 현상을 보다 빠르게 발견하고 수정할 수 있습니다.
내부 서비스에 대한 부하 테스트: 로그 기록 서비스와 같이 높은 처리량이 요구되는 서비스나, 결제 서비스와 같이 전체 서비스 품질에 있어 중요한 내부 서비스를 대상으로 테스트를 진행 합니다.
외부 서비스에 대한 부하 테스트: Facebook, Twitter 등의 소셜 서비스나 Google 등의 플랫폼에 대한 서비스들, 또는 푸시 알림 서비스 등의 외부 서비스를 대상으로 테스트를 진행 합니다.
전체 스택에 대해 부하 테스트: 개별 컴포넌트들에 대한 테스트를 완료한 뒤, 컴포넌트간의 상호작용을 알기 위해 처음부터 끝까지 전체 스택에 대해서 테스트 진행 합니다.

단계별 부하 테스트 수행 방법
앞서 언급한 것처럼, 부하 테스트는 전체 스택에 대해서도 수행 가능하지만, 작은 비결합된 컴포넌트나 기능 단위로도 수행 가능합니다. 그리고 작은 단위로 수행될 수록 더 분명하게 병목 지점을 파악하기에 수월 합니다. 그렇기에, 가능한 작은 단위부터 단계별로 진행하는게 원하는 결과를 얻어내는데 효율적입니다.

다음은 전형적인 3단계(3-tier) 웹 서비스에 대해 단계별로 부하 테스트를 진행하는 것을 설명하고 있습니다.

load-test-image001

최초 ‘WEB’ 을 출력하는 웹 페이지를 대상으로 동시 연결성에 대한 테스트 수행 → 결과 평가→최적화 진행 (Client →Web Server)
웹 서버를 통해 애플리케이션 서버에서 넘겨 받은 ‘APPLICATION’ 을 출력하는 웹 페이지를 대상으로 동시 연결성에 대한 테스트 수행→ 결과 평가 → 최적화 진행 (Client →Web Server → App Server – w/o Logic)
데이터베이스에서 최소한의 쿼리 결과를 전달 받아 출력하는 웹 페이지를 대상으로 동시 연결성에 대한 테스트 수행 →결과 평가 → 최적화 진행
(Client →Web Server → App Server – w/o Logic → Database)
3-tier 스택 전체를 대상으로 애플리케이션 로직이 적용된 페이지에 동시 연결성에 대한 테스트 수행 → 결과 평가 → 최적화 진행
(Client → Web Server → App Server – with Logic →Database)
4번을 기반으로 다양한 시나리오를 지정하여 테스트 수행 → (얻고자 하는 지표 기준에 대해서) 결과 평과 → 최적화 진행

부하 테스트 시, 각 레이어별 고려하여야 할 사항
부하 테스트를 수행한 뒤 각 레이어별로 발생할 수 있는 상황과 고려하여야 할 부분에 대해서 알아보도록 하겠습니다.

네트워크 용량 확인: 테스트 환경이 구성된 인프라와 관련하여 여러가지 지표를 확인할 수 있지만, 대표적으로 아웃바운드 연결이 예상되는 최대의 부하를 처리할 수 있는지 확인할 필요가 있습니다. Amazon EC2 의 경우 인스턴스 타입 마다 서로 다른 네트워킹 성능을 제공하고 있기에, 부하에 따른 적절한 인스턴스 타입 선택이 중요 합니다. 또 사내 인프라와 프라이핏하게 연결되어 있다면, VPN 관련 네트워킹 성능에 대해서도 확인을 하여야 합니다.
부하 생성 클라이언트: 앞서 설명하였듯이 부하 테스트의 요구사항 중 하나로, 필요한 만큼의 부하를 생성할 수 있는 충분한 인스턴스의 확보가 요구됩니다. 하지만, 설정 및 구현 방식에 의해 하나의 부하 생성 클라이언트가 처리할 수 있는 동시성에 큰 제한이 있다면, 필요 이상으로 복수개의 인스턴스가 요구되어 비용이 증가할 수 있습니다. 이럴 땐 Thread 기반의 툴 보다는 높은 동시성을 제공하는 Async IO 기반의 툴을 사용하여 테스트를 진행하는게 좋습니다.
로드 밸런싱: ELB(Elastic Load Balancing)는 서비스 전체 부하를 백엔드에 등록된 복수개의 인스턴스로 분산하는 기능을 제공합니다. 부하 테스트를 수행할 때 다양한 이유로 기대치 보다 낮은 결과나 5xx 에러가 발생하는 것을 볼 수 있습니다. 이 때, ELB 가 제공하는 다양한 모니터링 지표들을 확인하면, 어느 곳에서 병목 현상이나 에러가 발생되는지 확인하는데 도움이 됩니다. 가장 자주 발생하는 문제는, 503 Server Unavailable 이나 504 Gateway Timeout 에러 발생과 동시에, ELB 의 모니터링 지표에 SurgeQueueLength 가 1024 로 기록되고 SpilloverCount 가 0 보다 높을 경우 입니다. SurgeQueueLength 는 ELB 에 등록된 백엔드 인스턴스가 요청을 처리하지 못하여 쌓이게 되는 ELB 의 큐 이며, 앞서 언급한 것처럼 1024가 큐의 최대 크기 입니다. 이 최대 크기를 넘어서면 요청을 한 클라이언트에 5xx 에러를 보내게 되고, 동시에 SpilloverCount 가 기록 됩니다. 이 문제를 해결하기 위해서는 적시에 Auto Scaling 이 일어날 수 있도록 적절한 지표를 기준으로 알람을 발생 시킬 수 있도록 해야 합니다. 백엔드 인스턴스에서 동작하는 시스템이 어떤 자원을 더 많이 사용하는지 확인을 하고, 그 자원의 지표를 기준으로 Auto Scaling 을 설정하는 것이 좋습니다. SurgeQueueLength 를 기준으로 알람이 발생하게 하는 것도 한 가지 방법 입니다. ELB 가 제공하는 지표들은 여기에서 확인할 수 있습니다.
추가로 ELB 도 발생하는 부하에 따라 Auto Scaling 을 통해 규모가 변화되도록 설계 되어 있습니다. 만약, 매우 급격한 트래픽 증가가 일어날 때 ELB 가 확장되는 속도가 증가하는 트래픽을 수용하지 못한다면 5xx 에러가 발생할 수 있습니다. 이를 방지 하기 위해, 미리 점차적으로 증가하는 부하 테스트를 통해 어느정도 ELB 를 확장 시켜 둘 수 있습니다. 또한, ELB 에 등록된 백엔드 인스턴스에서 Keep-Alive 기능을 활성화 시켜, ELB 와 백엔드 인스턴스간에 불필요한 연결 수립이 일어나는 것을 방지한다면 더 높은 성능을 기대할 수 있습니다.
서버 인스턴스: 서버 인스턴스의 설정 값에 따라 웹/애플리케이션 서버의 자원 사용 효율성이 달라 집니다. 대표적으로 Linux 서버의 open files 숫자를 늘려 두지 않으면, 동시 접속이 기본값인 1024 개로 제한되어 서버 인스턴스를 효과적으로 사용할 수 없습니다.
애플리케이션 서버: 애플리케이션 서버의 종류마다 다르지만, 일반적으로 Tomcat 등의 Thread 기반의 애플리케이션 서버일 경우, Thread Pool 의 크기가 너무 작다면 처리 되어야할 요청들이 기다리는(waiting) 상태가 길어져 전체 부하 테스트의 효율성을 떨어뜨릴 수 있습니다. 최근에는 Thread 기반의 애플리케이션 서버가 가지고 있는 제약으로 인해, Event 기반의 비동기 형태의 애플리케이션 서버가 자주 사용되어 집니다.
애플리케이션: 애플리케이션 코드와 프레임워크 둘로 나누어 생각해 볼 수 있습니다. 애플리케이션 코드 내에서 잘못된 방식으로 프레임워크나 API 를 사용할 수 있으며, blocking 코드가 포함되어 있다거나, 불필요한 연산을 진행, 또 테스트 코드를 삭제하지 않았다는 등의 문제가 있을 수 있습니다. 이 때에는 적절한 Unit Test 와 Lint 등을 통해 문제를 조기에 발견할 수 있어야 합니다. 사용하는 웹 프레임워크나 ORM(Object-relational mapping)과 같은 라이브러리가 가지고 있는 버그로 인하여 문제가 발생할 수도 있습니다. 애플리케이션 관련 다양한 문제를 해결하기 위해 APM(Application Performance Monitoring) 을 활용하여 성능을 모니터링 하는 것도 한가지 방법 입니다.
데이터베이스: CPU 사용률과 응답 시간(response time) 등을 확인할 필요가 있습니다. 특히 데이터베이스를 설정한 방법에 따라 더 요구되는 자원을 눈 여겨 볼 필요가 있습니다. 최근에는 성능을 향상 시키기 위해 메모리를 적극 활용하게끔 설정을 하는 경우가 많으며, 이때에는 메모리 사용률이 특정 수치 이상으로 넘어갈 경우, 알람을 발생 하도록 설정하여 병목 지점 확인이 가능 하겠습니다.

부하 테스트 관련 도구 및 서비스
부하 테스트를 위해 사용할 수 있는 다양한 툴과 서비스들이 존재 합니다. 간단한 소개와 함께 특징들을 살펴보겠습니다.

ApacheBench (http://httpd.apache.org/docs/2.2/en/programs/ab.html): 일반적으로 HTTP 웹 서버의 성능을 측정하기 위해서 자주 사용되는 툴입니다. 기본적인 HTTP 연결에 대해서 테스트를 할 때 자주 사용되는 툴이지만, HTTP/1.1 을 지원하지 않고, 한번에 하나의 대상 URL로 테스트가 가능한 것 등의 제한이 있습니다.
Siege (https://www.joedog.org/siege-home/): HTTP 부하 테스트와 벤치마킹 유틸리티 입니다. 한번에 복수개의 URL 로 테스트가 가능하고, Basic 인증을 지원하며 HTTP와 HTTPS 프로토콜로 테스트가 가능하는 등 ApacheBench 의 제한을 어느정도 해소 해 줍니다. 또 ApacheBench 와 비슷한 인터페이스를 가지고 있어 다른 툴과의 연계가 자유로운 편입니다. 하지만 Thread 기반으로 구현되어 있어 동시성에 제한이 있으며, 미미할 수 있지만 Context Switching 등으로 인하여 성능에도 영향이 있습니다.
JMeter (http://jmeter.apache.org/): 1998 년 부터 시작된 프로젝트로서 오랫동안 기능 강화를 지속해오고 있는 Java 기반의 부하 테스트 툴 입니다. HTTP 뿐만 아니라 다양한 프로토콜을 지원하며, 많은 기능을 가진 GUI 를 제공 합니다. 실제 워크로드를 시뮬레이션 하기 위해 다양한 방법으로 커스터마이징이 가능합니다. 하지만 앞서 언급한것처럼 Thread 기반으로 구현되어 있어 성능과 동시성에 대해서 제한이 있습니다. 이를 해결하기 위해, 복수개의 인스턴스에서 실행시켜 테스트를 수행할 수 있는 Remote Testing 기능을 지원 합니다. 복수개의 EC2를 활용하거나, BlazeMeter 나 Flood.io 와 같은 JMeter 를 지원하는 부하 테스트 서비스를 사용할 수도 있습니다.
The Grinder (http://grinder.sourceforge.net/): Java 기반의 부하 테스트 프레임워크 입니다. Agent 가 지정한 값을 기반으로 부하를 생성하며, IDE 형태의 콘솔에서 Agent 들을 제어 및 결과 모니터링이 가능합니다. 마찬가지로 Thread 기반으로 구현되어 있어 성능과 동시성에 대해 제한이 있습니다.
Gatling (http://gatling.io/): Akka 와 Netty 기반의 Scala 로 개발된 부하 테스트 프레임워크 입니다. Thread 기반이 아닌 Event 와 Async IO 기반으로 구현되어, 높은 성능을 제공하며 HTML 보고서 생성 기능은 물론 시나리오를 DSL 로 작성하여 부하 테스트에 사용할 수 있는 기능을 제공하고 있습니다.
Tsung (http://tsung.erlang-projects.org/): Erlang 으로 개발된 부하 테스트 툴로서, HTTP는 물론 Websocket 이나 인증 시스템, 데이터베이스, MQTT 와 같은 TCP 기반의 다양한 프로토콜을 지원합니다. 동시성 지향 프로그래밍 언어 (concurrency-oriented programming language) 인 Erlang 이 가지고 있는 장점으로 인해, 성능과 확장성, 내결함성(Fault Tolerance)에서 큰 이점을 제공하고 있습니다. GUI 를 제공하지 않아 CLI 또는 Script 를 활용하여야 합니다.
Bees (https://github.com/newsapps/beeswithmachineguns): AWS 의 장점을 적극 활용한 오픈 소스 부하 테스트 툴로서, 부하를 분산 생성하기 위해 사용자의 AWS 계정에서 EC2 인스턴스를 지정한 개수만큼 생성하여 부하 테스트 대상에 테스트를 진행합니다. 비용을 줄이기 위해 스팟 인스턴스를 생성하여 활용할 수 있는 옵션도 제공하고 있습니다. 부하 테스트를 위해 ApacheBench 를 사용하기 때문에 ApacheBench 가 가지고 있는 제한을 그대로 가지고 있습니다.
Vegeta (https://github.com/tsenart/vegeta): Go 언어로 개발된 오픈소스 HTTP 부하 테스트 툴이며 CLI 로 사용하거나 라이브러리로 사용 가능합니다. 보통의 다른 툴과 다르게 초당 일정한 속도로 특정 수치의 요청을 지속하는데 초점을 맞추고 있어, 예상되는 최대 트래픽이 지속적으로 발생하였을 때 서비스와 인프라의 상태가 어떻게 변화하는지 확인하는데 적합한 툴 입니다.
RedLine13 (https://www.redline13.com/): AWS 의 Advanced Technology Partner 중 하나로서, AWS 기반의 부하 테스트를 수행하는 서비스 입니다. 사용자의 AWS 계정에서 IAM 을 생성하여 RedLine13 과 연동을 하면, 사용자의 AWS 계정에서 Agent 가 포함된 인스턴스가 실행되어 테스트가 진행 됩니다. 스팟 인스턴스를 활용할 수 있어 비용을 줄일 수 있습니다. 여기에서 RedLine13 과 Apache JMeter 를 활용하여 모바일 애플리케이션을 테스트 하는 데모를 보실 수 있습니다.
Loader.io (https://loader.io/): 클라우드 기반의 부하 테스트 서비스로서, 웹 페이지에서 대상 서버를 선택하고 원하는 동시성 등을 지정할 수 있으며, 그 결과를 보기 좋게 표시해 줍니다. 또한, 진행한 테스트를 추후에 리플레이 할 수도 있습니다.
Goad (https://goad.io/): AWS Lambda 를 활용하여 부하를 분산 생성하여 테스트를 수행하는 오픈 소스 툴로서 Go 언어로 개발 되었습니다. 실제 AWS 의 이점과 AWS Lambda 의 강력함을 잘 활용한 툴 입니다. 툴을 실행하면 AWS Lambda 함수를 생성 (혹은 갱신) 하여, 대상 URL 에 동시적으로 부하 테스트를 시작합니다. 그리고 각 결과는 AWS SQS 로 보내어지고, 최종적으로 최초 실행한 툴에서 결과를 취합하여 보여줍니다.

그밖에도 다양한 AWS Marketplace에서도 다양한 파트너들의 부하 테스트 솔루션을제공하고있습니다.

부하테스트 시 유용한 팁 모음
AWS 클라우드 기반으로 부하 테스트를 진행하는데 있어서 알아두면 도움이 되는 팁들을 간단하게 소개해 드리고자 합니다.

로그 기록과 확인: 부하 테스트를 진행할 때, 로그 작성은 File IO 를 요구하는 작업이기에, 미미하게 테스트 수행 능력에 영향을 미칠 수 있습니다. 특히나 테스트 환경에서는 로그 수준을 낮추어(verbose 또는 debug) 더 많은 로그가 기록되도록 하는 경우가 많아, 실제 프로덕션에 비해 성능에 미치는 영향이 더 클 수 있습니다. 하지만 가능한 로그를 기록하는게 추후 발생하는 문제 파악에 도움을 줄 수 있기 때문에 기록을 하는게 권장 됩니다. 또는, 최초의 워밍업을 진행할 때 로그를 활성화하여 진행을 하고, 이후의 테스트에 대해서는 로그를 비활성화하여 진행할 수도 있겠습니다. 만약 그 결과가 기대에 미치지 않는다면, 다시 로그를 활성화 한 뒤 테스트를 진행하고, 생성되는 로그를 통해 문제를 파악할 수 있겠습니다.
적절한 인스턴스의 선택: EC2 인스턴스는 요구되는 워크로드에 맞추어 선택할 수 있도록 다양한 종류가 준비되어 있습니다. 사용하는 웹/애플리케이션/데이터베이스에 따라 상대적으로 더 요구되는 자원은 다를 수 있으며, 그에 맞추어 인스턴스를 선택하는 것이 비용도 절약하며 더 적합한 성능을 발휘할 수 있겠습니다. 예를 들어, 특별한 연산이 수행되지 않고 다른 서비스와 통신이 주 목적이라면, 적은 CPU 자원과 적절한 Memory 자원, 그리고 높은 Bandwidth 와 Enhanced Networking 을 제공하는 인스턴스가 비용과 성능 관점에서 좋은 선택일 수 있습니다.
비용 최소화: 유의미한 결과를 얻기 위해 부하 테스트 대상 환경을 가능한 실제 환경과 비슷하게 구성할 필요가 있습니다. 물론, 실제 프로덕션 환경에서 테스트를 수행할 수도 있지만, 이는 가상의 가짜(Dummy) 데이터를 생성하여 프로덕션 환경을 어지럽히고 라이브 서비스의 안정성을 헤치는 등의 위험성이 있기에 적극적으로 피해야 합니다. 실제 프로덕션 환경과 비슷한 환경을 구성하여 부하 테스트를 수행하는데 있어서 가장 먼저 고려하여야 할 사항은 비용 입니다. 일반적으로 최대 부하에 대한 테스트 진행을 위해, 수십에서 수백 대의 인스턴스가 필요할 수 있으며, 큰 규모의 부하를 생성하기 위해서도 많은 인스턴스가 요구되기 때문입니다. 이 때, 비용을 최소화 하기 위해 스팟 인스턴스를 활용할 수 있습니다. 스팟 인스턴스는 EC2 컴퓨팅 예비 용량에 입찰을 통해 온디맨드 요금과 비교하여 할인된 요금으로 사용할 수 있는 방법을 제공하며, 일반적으로 50~90% 저렴한 비용으로 사용할 수 있습니다. 자세한 내용은 여기를 참조 하시기 바랍니다.

다양한 도구와 서비스의 복합적 활용: 앞서 부하 테스트를 위한 다양한 툴과 서비스에 대해서 알아 보았습니다. 부하 테스트를 진행할 때, 어떤 특정 툴 또는 서비스 하나만 선택해서 사용 할 필요는 없습니다. 각 툴과 서비스 별로, 목적성과 고유의 특징을 가지고 있기에, 용도에 맞게 복합하여 사용하는게 더 효율적일 수 있습니다. 예를 들어, GUI 의 완성도가 높고 다양한 시나리오를 설정할 수 있는 JMeter 는 웹 애플리케이션 내에서 사용자의 행동 흐름에 대해 부하 테스트를 하는데 적합할 수 있습니다. 그 이외의 툴과 서비스들도 특징들이 있으며 다음과 같이 활용할 수 있겠습니다.

도구 명	활용 방법
JMeter	웹 애플리케이션 내에서 사용자의 행동 흐름에 대해 부하 테스트를 하고 싶을 때
Tsung	API 가 수용할 수 있는 최대치의 부하를 알고 싶을 때
Vegeta	어떤 API 에 대해 초당 특정 수치의 요청이 지속될 경우 발생하는 상황을 파악하고 싶을 때
Goad	부하 생성 클라이언트 구성을 포함한 부하 테스트 관련 인프라 구성을 피하고 싶을 때
RedLine13	JMeter 로 테스트 플랜을 작성하여 활용을 원하지만, 비용을 최소화 하고 싶고 사용한 만큼만 비용이 발생하길 원할 때
Blazemeter	높은 동시성을 위해 JMeter 의 Remote Testing 기능을 활용하고 싶지만, 테스트 플랜 작성에 집중하고, 부하 테스트 관련 인프라 구성은 하고 싶지 않을 때
Loader.io	부하 테스트 관련 인프라 구성을 하고 싶지 않고, Tsung 과 비슷한 목적으로 사용하고 싶을 때

부하 테스트에는 보통의 시나리오 기반의 가상의 워크로드에 대한 부하 테스트 뿐만 아니라, 실제 워크로드에 대한 부하 테스트를 위해 프로덕션에서 발생하는 트래픽을 활용하는 방법도 있습니다. 프로덕션 환경의 실제 트래픽을 활용하기 위해서는, 트래픽을 재사용 하기 위해 기록하거나 곧바로 테스트 환경으로 리플레이 해 주는 gor (https://goreplay.org/) 와 같은 툴을 사용할 수 있습니다. 프로덕션 환경의 실제 트래픽을 반복하여 활용할 수 있다는 이점 이외에도, 서비스 및 애플리케이션 업데이트 예정 버전에 실제 트래픽을 흘려 보내 사용성에 대한 테스트도 진행할 수 있는 장점도 있습니다.

추가로, 많은 경우 부하 테스트는 개발 주기 마지막에 진행되는 경우가 많습니다. 애자일 방법론과 지속적인 통합(CI/CD)을 활용하는 경우 조금 더 일찍, 자주 부하 테스트를 진행할 수 있으며, 이를 통해 추후 발생할 수 있는, 비용이 많이 드는 성능 문제를 미리 방지할 수 있습니다. 따라서, 가능한 개발 주기에 부하 테스트를 포함하여 자주 진행하는 것이 바람직하다고 볼 수 있습니다.

AWS 에서 제공하는 방대한 인프라와 이미 부하에 대해 고려되어 설계된 관리형 서비스, 그리고 다양한 규모 관련 기능들을 적극 활용하여 서비스를 구축한다면 가변적인 부하에도 유연한 서비스를 제공할 수 있을 것 입니다.

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

AWS Application Load Balancer 서비스 공개

지난 2009년 Elastic Load Balancing (ELB) 서비스를 시작하였습니다.(New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatch 참고). ELB는 AWS 기반 애플리케이션의 가장 중요한 아키텍처의 구성으로서 자동 스케일링과 함께 고가용성을 유지하면서 손쉽게 확장 및 감소를 할 수 있도록 도와 주고 있습니다.

상위 레이어 로드 밸런싱 기능 지원
잘 알려진 OSI 모델에 따르면, 로드밸런싱은 일반적으로 Layer 4 (네트워크) 또는 Layer 7 (애플리케이션)에서 처리합니다.

Layer 4 로드밸런싱은 네트워크 프로토콜 레벨에서 제공 되며, 실제 패킷을 살펴 보지는 못하기 때문에 HTTP나 HTTPS 같은 특정 프로토콜을 인지하지 않고 부하를 분산합니다.

대신 Layer 7 로드밸런싱은 좀 더 정교하고 강력한 기능을 제공합니다. 패킷을 조사하고, HTTP 및 HTTPS 헤더에 접근해서 좀 더 지능적인 부하 분산 작업이 가능합니다.

AWS Application Load Balancing 서비스 제공
오늘 ELB의 새로운 옵션인 애플리케이션 로드밸런서(Application Load Balancer)를 공개합니다. 이 서비스는 Layer 7 로드밸런싱을 통해 많은 고급 기능을 제공합니다. 기존의 로드 밸런싱 기능은 앞으로 Classic Load Balancer라고 부르게 되며, 여전히 Layer 4 및 Layer 7 기능을 제공합니다.

애플리케이션 로드밸런싱은 콘텐트 기반 라우팅 및 콘테이너 상 애플리케이션을 지원합니다. 표준 프로토콜인 WebSocket 및 HTTP/2를 지원하며, 인스턴스 및 콘테이너의 추가 가시성을 제공하게 됩니다. 콘테이너 및 EC2 인스턴스에서 실행하는 웹 사이트 및 모바일 앱에 대해 부하 분산에 대한 효과가 매우 높을 것입니다.

이제 좀 더 자세하게 애플리케이션 로드밸런싱 기능을 살펴 보겠습니다.

콘텐츠 기반 라우팅
애플리케이션 로드밸런서는 HTTP 헤더에 접근해서 다른 백엔드 서비스에 따라 다른 요청을 처리할 수 있습니다. 예를 들어, URL에 /api라는 경로를 포함하고 있는 경우, 다른 서버 그룹(일명 target group)으로 요청을 보낼 수 있으며 /mobile은 또 다른 서버 그룹으로 보낼 수 있습니다. 이를 통해 여러 개의 마이크로서비스를 독립적으로 실행하고 확장할 수 있도록 할 수 있습니다.

각 애플리케이션 로드밸린서는 10개의 URL 규칙을 만들 수 있으며, 앞으로 더 많은 라우팅 방법을 제공할 계획입니다.

콘테이너 기반 애플리케이션 지원
많은 AWS 고객들이 자사의 마이크로서비스를 콘테이너 형식으로 만들어서 Amazon EC2 Container Service를 통해 배포하고 있습니다. Amazon ECS는 하나의 EC2 인스턴스에 한 개 이상의 서비스를 배포 및 운영할 수 있습니다. 그러나, 포트 맵핑 및 헬스 체크 등에 대해 전통적인 로드밸린서로는 어려운 문제가 있습니다.

애플리케이션 로드밸린서를 통해 콘테이너 기반의 애플리케이션 역시 같은 타겟 그룹 내에 다수의 포트를 사용할 수 있으며, 세부적인 포트 수준의 헬스 체크를 지원할 수 있게 되었습니다.

더 자세한 통계 수치 제공
애플리케이션 로드밸린서는 포트 기반의 헬스 체크에 대한 리포트를 실행할 수 있어, HTTP 응답에 대한 범위를 정의할 수 있고 자세한 오류 코드에 대한 부분도 확인할 수 있습니다.

콘텐츠 기반의 라우팅을 제공함으로서 각 마이크로서비스의 다양한 통계 수치도 얻어낼 수 있습니다. 이는 마이크로서비스 기반에서 운영하는 타겟 그룹 또는 특정 EC2 인스턴스 그룹에 대한 유효한 부수 효과입니다. 개별 서비스에 대한 부하에 대해 좀 더 자세히 살펴 볼 수 있음으로서 확장성에 대한 도움을 얻을 수 있습니다.

애플리케이션 로드밸린서는 CloudWatch에서 전체 트래픽 (overall traffic in GB), 액티브 연결 갯수, 시간당 연결 비율 등의 새로운 통계 수치를 제공합니다.

추가 프로토콜 지원
애플리케이션 로드밸린서는 WebSocket 및 HTTP/2를 지원합니다.

WebSocket은 클라이언트와 서버간 긴 TCP 연결을 제공하는 프로토콜로서, 긴 연결이 필요할 경우 기존의 HTTP 연결을 통해 하던 고전적인 풀링 방식을 개선할 수 있습니다. 모바일 앱의 경우, 주식 가격이나 스포츠 경기 점수 등 다양한 동적 데이터를 서로 주고 받을 때 유용하며 ALB는 ws:// 및 wss:// 프로토콜을 지원합니다.

HTTP/2 역시 기존 HTTP 1.1에 비해 중요한 기능 향상을 가진 프로토콜로서 단일 연결에 멀티플렉스 요청을 처리할 수 있고, 바이너리 속성을 통한 네트웍 트래픽을 줄여줍니다.

애플리케이션 로드밸린서는 실시간 스트리밍 뿐만 아니라 WebSocket 로드를 최적으로 처리 가능합니다. 요청 및 응답에 대한 버퍼링 대신 스트리밍 방식으로 처리함으로서 지연 속도를 줄이고 애플리케이션의 성능을 눈에 띄게 높일 수 있습니다.

ALB 생성하기
이제 애플리케이션 로드밸린서를 만들어서 트래픽을 처리해 보겠습니다.

The Elastic Load Balancing Console에 두 가지 중 하나의 로드밸린서를 선택할 수 있습니다.

Application load balancer을 선택하고 이름(MyALB)을 넣고 internet-facing를 선택 후, HTTPS listener를 추가합니다.

같은 화면에서 VPC를 선택하고 (VPC만 지원함), 원하는 가용 영역과 서브넷을 선택합니다. 애플리케이션 로드밸린서를 태그하고 Configure Security Settings 설정으로 갑니다.

HTTPS listener를 선택했기 때문에 ALB는 인증서가 필요합니다. IAM에 있는 기존 인증서를 선택하거나, AWS Certificate Manager (ACM)에서 발급 받거나 또는 로컬 인증서를 업로드할 수 있습니다.

오른쪽에서 보안 그룹을 설정합니다. 새로운 보안 그룹을 만들었으나 기존 VPC나 EC2 보안 그룹을 사용하실 수도 있습니다.

다음 단계로 타겟 그룹(main)을 만들고, 헬스 체크를 기본으로 체크합니다.

이제 타겟그룹의 EC2 인스턴스 세트를 선택하여 애플리케이션 로드밸린서를 통해 분산할 80포트를 선택합니다.

마지막 단계로 모든 설정을 확인 한후 Create를 누르면 됩니다.

Create 누르고 나면, 애플리케이션 로드밸린서가 수 분 안에 만들어집니다.

추가 타겟 그룹을 만들 수도 있습니다.

각 타겟 그룹에 원하는 경로, 즉 /api 호출을 보낼 수 있습니다.

애플리케이션 로드밸린서는 Auto Scaling, Amazon ECS, AWS CloudFormation, AWS CodeDeploy 및 AWS Certificate Manager (ACM) 서비스와 연동해서 사용할 수 있습니다.

신규 로드밸런서로 이전하기
현재 기존 로드밸런서를 사용하고 있으시고, 애플리케이션 로드밸린서로 옮기고 싶으시다면, Load Balancer Copy Utility를 활욜하시기 바랍니다. 기존 설정을 그대로 애플리케이션 로드밸린서에 맞게 옮겨주는 Python 기반의 도그로서 기존 EC2 인스턴스를 신규 로드밸런서로 등록하는 기능도 있습니다.

가용성 및 가격
애플리케이션 로드밸린서는 모든 AWS 리전에서 오늘 부터 사용가능합니다. ALB의 시간당 사용 비용은 기존 로드밸런서 보다 10% 낮습니다.

ALB를 사용하시면 로드밸런서 용량 단위(LCU)를 기반으로 시간당 과금하게 되며, LCU는 초당 연결 갯수, 활성 연결수, 및 데이터 전송량 등을 측정하게 됩니다. 이 세 가지 측면의 데이터를 기반으로 비용이 결정됩니다. 하나의 LCU는 다음 중 하나를 선택합니다.

25 초당 연결 수 (2 KB 인증서, 3,000 활성 연결 수, 2.22 Mbps 데이터 전송량) 혹은
5 초당 연결 수 (4 KB 인증서, 3,000 활성 연결 수, 2.22 Mbps 데이터 전송량

시간당 1 LCU에 대해 0.008 달러가 과금되며, 저희의 계산에 따르면 모든 고객들이 기존 로드밸런서에서 ALB로 이전할 경우 기본적으로 총 비용이 감소할 것으로 생각합니다. 지금 부터 한번 활용해 보시기 바랍니다.

— Jeff;

본 글은 New – AWS Application Load Balancer의 한국어 번역본으로 AWS Summit 뉴욕 행사의 신규 발표 소식입니다.

EC2 Run Command 서울 리전 기능 출시

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

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

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 설정하기
설정 과정은 매우 간단합니다. 아래 단계를 살펴 보시기 바랍니다.

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

Category: Amazon EC2