Category: Amazon EC2*


T2 무제한(Unlimited) 기능 – 피크에도 고성능 컴퓨팅 활용하기

2014년 여름에 T2 인스턴스에 대해 처음으로 소개하고, 대부분 IT 업무에서 지속적인 컴퓨팅 파워가 크게 요구되지 않고 가끔 더 많은 컴퓨팅이 필요할 때 사용할 수 있는 이제 버스팅 모델을 선보였습니다. T2 인스턴스는 현재 인기가 매우 높아져서 마이크로 서비스, 지연 시간이 짧은 대화형 애플리케이션, 가상 데스크톱, 빌드 및 스테이징 환경, 프로토타입 등을 호스팅하는 데 사용되고 있습니다.

신규 T2 무제한(Unlimited) 기능 출시
오늘 T2에서 제공하는 버스트 모델을 확장하여, 이제 최대한 낮은 비용으로 원하는 기간 동안 높은 CPU 성능을 유지할 수 있는 기능을 추가합니다. 사용하시려면 인스턴스를 시작할 때, 이 기능을 활성화하면 되고, 이미 실행 중인 인스턴스에 대해 이 기능을 활성화할 수도 있습니다. 24시간 동안 평균 CPU 사용률이 기준선보다 낮을 경우, 중간에 급증하는 모든 사용량이 시간당 T2 인스턴스 가격에 포함됩니다. 인스턴스가 장기간에 걸쳐 높은 CPU 사용률로 실행될 경우 소액의 시간당 요금이 청구됩니다. 예를 들어, t2.micro 인스턴스를 평균 15% 사용률(기준선보다 5% 높음)로 24시간 동안 실행할 경우 6센트(vCPU-시간당 5센트 * 1 vCPU * 5% * 24시간)의 추가 요금이 청구됩니다.

EC2 콘솔에서 T2 Unlimited 인스턴스를 시작하려면 T2 인스턴스를 선택한 다음 [T2 Unlimited] 옆에 있는 [Enable]을 클릭합니다.

T2 Standard에서 실행 중인 인스턴스를 T2 Unlimited로 전환하는 방법은 다음과 같습니다.

CPU 크레딧 계산 기준
원래 T2 인스턴스는 실행될 때마다 CPU 크레딧을 누적하였다가 최대 코어 속도로 실행할 때 CPU 크레딧을 사용합니다. 이때 크레딧 공급이 고갈되면 기준 레벨로 속도가 느려집니다. 하지만, T2 Unlimited 인스턴스에서는 하루 분량의 크레딧을 미리 빌려서 추가 버스팅을 수행할 수 있습니다. 이 값은 CloudWatch에 CPUSurplusCreditBalance라는 신규 측정치로 기록합니다. 잔여 크레딧 레벨이 하루 분량으로 증가하면 인스턴스에서는 전체 코어 성능을 계속 제공합니다. vCPU별로 시간당 $0.05(Linux) 또는 $0.096(Windows)의 요금이 청구됩니다. 청구되는 이 초과 크레딧은 새 CPUSurplusCreditsCharged 측정치에 의해 기록합니다. 지정된 시간 내에 초과 크레딧을 다 쓴 경우 한 시간 미만의 버스팅 시간에 대해 밀리초 단위로 요금이 청구됩니다. 따라서, 추가적으로 비용을 절감할 수 있습니다.

나머지 CPUSurplusCreditBalance에 대한 요금은 인스턴스를 종료하거나 T2 Standard로 구성할 때 처리됩니다. 누적된 CPUCreditBalance는 T2 Standard로 전환하는 동안 유지됩니다.

T2 Unlimited 모델은 CloudWatch 측정치를 조회하는 수고를 덜어주기 위해 설계되었지만, 원하는 경우 직접 확인해도 됩니다. 예를 들어, t2.nano의 시간의 흐름에 따른 크레딧에 대해 알아보겠습니다. 먼저 CPU 사용률이 100%로 증가하면 인스턴스에서는 5분마다 5크레딧을 소비합니다(1크레딧은 1 VCPU 분에 해당).

크레딧이 생성과 동시에 소비되고 있으므로 CPU 크레딧 잔고는 0으로 유지됩니다. 이 때, CPUSurplusCreditBalance 측정치에 의해 추적되는 초과 크레딧 잔고가 72까지 증가합니다. 이 초과 크레딧 잔고는 향후 크레딧에서 임차한 크레딧을 나타냅니다.

초과 크레딧 잔고가 72가 되면 더 이상 크레딧을 임차할 수 없으며, 추가 CPU 사용량에 대해서는 시간이 끝날 때 청구되며 이는 CPUSurplusCreditsCharged 측정치에 의해 추적됩니다. 인스턴스에서는 5분마다 5크레딧을 소비하고 0.25크레딧을 획득합니다. 따라서 5분의 버스팅당 4.75 VCPU 분의 순수 요금이 청구됩니다.

원한다면 언제든지 T2 Standard 및 T2 Unlimited 간에 각 인스턴스를 전환할 수 있습니다. CPUSurplusCreditsCharged를 제외한 모든 크레딧 잔고는 유지되며 이월됩니다. T2 Unlimited 인스턴스는 언제든지 버스팅할 수 있으므로 새로 시작된 T2 Standard 인스턴스에 제공되는 30분 크레딧이 제공되지 않습니다. 각 AWS 계정에서 매일 초기 CPU 크레딧을 사용하여 제한된 수의 T2 Standard 인스턴스를 시작할 수 있으므로, T2 Unlimited 인스턴스는 자동 스케일링 그룹과 다수의 인스턴스를 매일 동작하는 시나리오용으로 더 적합합니다.

정식 출시
T2 Unlimited 인스턴스는 현재 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(캘리포니아 북부), 미국 서부(오리건), 캐나다(중부), 남아메리카(상파울루), 아시아 태평양(싱가포르), 아시아 태평양(시드니), 아시아 태평양(도쿄), 아시아 태평양(뭄바이), 아시아 태평양(서울), EU(프랑크푸르트), EU(아일랜드)EU(런던) 리전에서 시작할 수 있습니다.

Jeff;

이 글은 AWS re:Invent 2017 신규 서비스 소식으로 T2 Unlimited – Going Beyond the Burst with High Performance 의 한국어 번역입니다.

AWS PrivateLink 업데이트 – 자체 애플리케이션 및 서비스용 VPC 엔드포인트

이번 달 초에 Colm MacCárthaigh을 통해 여러분에게 AWS PrivateLink에 관한 소식을 전하고, 이를 사용하여 Amazon Kinesis Streams, AWS Service Catalog, EC2 Systems Manager, EC2 API, 그리고 VPC 엔드포인트를 통한 ELB API와 같은 AWS 서비스에 액세스하는 방법을 보여주었습니다. 엔드포인트(한  개 이상의 탄력적 네트워크 인터페이스 또는 ENI로 표시)는 VPC 내에 상주하고, VPC 서브넷으로부터 IP 주소를 가져오며, 인터넷이나 NAT 게이트웨이를 필요로 하지 않습니다. 이 모델은 명확하고 이해하기 쉬우며, 안전하면서도 확장까지 가능합니다!

프라이빗 연결용 엔드포인트
이제 PrivateLink 모델을 확장함으로써 여러분이 VPC 엔드포인트를 설정하고 사용하여 자체 서비스 및 다른 사람이 사용 가능하도록 한 서비스에 액세스할 수 있도록 합니다. AWS 서비스용 PrivateLink를 출시하기 전에도 이러한 기능에 대한 요청이 많았기에 굉장히 많이 사용될 것으로 예상합니다. 예를 들어 한 고객은 저희에게 수백 개의 VPC를 만들고, 각각의 VPC가 단일 마이크로서비스(자세히 알아보려면 AWS의 마이크로서비스 기술 백서 참조)를 호스팅 및 제공할 계획이라고 말했습니다.

이제 기업들은 관련 서비스를 만들어 다른 AWS 고객에 대한 판매용 프라이빗 연결을 통한 액세스용으로 제공할 수 있습니다. TCP 트래픽을 허용하는 서비스를 만들고, 이를 네트워크 로드 밸런서 뒤에서 호스팅한 다음, 직접 또는 AWS Marketplace를 통해 서비스를 사용할 수 있습니다. 새로운 구독 요청에 대한 알림을 받고 각각의 허용 또는 거부를 선택할 수 있습니다. 이 기능이 2018년에 강력하고 생동감이 넘치는 클라우드 서비스 공급자 생태계를 만드는 데 일조할 것으로 예상합니다.

서비스 공급자와  사용자는 별도의 VPC와 AWS 계정을 실행한 다음 엔드포인트를 통해 커뮤니케이션합니다. 이때 모든 트래픽은 Amazon의 프라이빗 네트워크를 통해 전송합니다. 서비스 소비자는 중첩되는 IP 주소를 걱정하거나 VPC 피어링을 처리하거나 VPC 게이트웨이를 사용할 필요가 없습니다. 또한, 클라우드 기반 애플리케이션이 온프레미스에서 실행 중인 서비스에 액세스하는 경우, 또는 그 반대의 경우를 허용하기 위해 AWS Direct Connect를 사용하여 기존 데이터 센터를 VPC 중 하나에 연결할 수 있습니다.

서비스 제공 및 사용 방법
신규 기능은  VPC API, VPC CLI 또는 AWS Management Console을 사용하여 모든 것을 설정할 수 있습니다. 이제 콘솔을 사용해서 서비스를 제공하고 활용하는 방법을 보여 드리겠습니다. 단, 시연을 목적으로 하는 것이기 때문에 하나의 AWS 계정에서 두 가지를 모두 하겠습니다.

우선 서비스 제공 방법 부터 살펴보겠습니다. 네트워크 로드 밸런서 뒤에서 실행이 되어야 하고, TCP를 통해 액세스가 가능해야 합니다. EC2 인스턴스, ECS 컨테이너, 또는 온프레미스(IP 대상으로 구성됨)에서 호스팅될 수 있으며, 예상 수준의 수요를 충족할 수 있도록 확장이 가능해야 합니다. 낮은 지연 시간과 내결함성을 위해 리전의 모든 AZ에 대상을 포함한 NLB를 사용하는 것을 권장합니다. 예로 들자면 아래와 같습니다.

VPC 콘솔을 열고 [Endpoint Services]로 이동한 다음 [Create Endpoint Service]를 클릭합니다.

NLB(이 경우에는 단 1개이지만, 2개 이상을 선택할 수 있고, 라운드 로빈 방식으로 사용자에게 매핑됩니다)를 선택합니다. [Acceptance required]를 클릭함으로써 각 요청을 기준으로 제 엔드포인트에 대한 액세스를 제어합니다.

[Create service]를 클릭하면 제 서비스가 즉시 준비됩니다.

이 서비스를 AWS Marketplace에서도 사용할 수 있도록 할 생각이라면 계속 진행하다 여기서 목록을 만들 것입니다. 이 블로그 게시물에서는 생산자도 되고 소비자도 될 것이기 때문에 이 단계는 건너뛰겠습니다. 대신 다음 단계에서 사용할 서비스 이름을 복사하겠습니다.

VPC 대시보드로 돌아가서 [Endpoints]로 이동한 다음 [Create endpoint]를 클릭합니다. [Find service by name]을 선택한 다음 서비스 이름을 붙여 넣고 [Verify]를 클릭하여 계속 진행합니다. 그런 다음 원하는 AZ와 각 AZ의 서브넷을 선택한 다음 보안 그룹을 고르고 [Create endpoint]를 클릭합니다.

엔드포인트 서비스를 만들 때 [Acceptance required]를 선택했기 때문에 연결이 수락을 대기 중입니다.

엔드포인트 서버 측(일반적으로는 별도의 AWS 계정)으로 돌아가면 대기 중인 요청을 확인하고 수락할 수 있습니다.

엔드포인트가 사용 가능한 상태가 되고, 1분 정도 이내에 사용 준비가 됩니다. 서비스를 만들고 유료 기반으로 액세스를 판매하고 있었다면 새로운 고객에 대한 더 큰 규모의 어쩌면 자동화된 온보딩 워크플로우의 일환으로 요청을 수락했을 것입니다.

사용자 측에서는 DNS 이름을 통해 저의 새로운 엔드포인트에 액세스할 수 있습니다.

AWS에서 제공하는 서비스와 AWS Marketplace에 있는 서비스는 분할-수평 DNS를 통해 액세스할 수 있습니다. 이 이름을 통해 서비스에 액세스하면 “최적의” 엔드포인트로 확인되고, 리전 및 가용 영역을 고려합니다.

Marketplace에서 활용하기
이미 언급한 대로 PrivateLink의 이 새로운 기능은 AWS Marketplace의 신규 및 기존 판매업체에 기회를 만들어 줍니다. 다음 SaaS 제품은 이미 엔드포인트로 사용 가능하며, 종류는 더 늘어날 것으로 예상합니다(시작하려면 AWS Marketplace에서의 판매 참조).

정식 출시
PrivateLink의 이 새로운 기능은 바로 오늘부터 사용할 수 있습니다!

Jeff;

이 글은 AWS re:Invent 2017의 신규 서비스로서 AWS PrivateLink Update – VPC Endpoints for Your Own Applications & Services의 한국어 번역입니다.

Amazon EC2 업데이트 – 손 쉬운 스팟 용량 접근 및 가격 변경, 인스턴스 최대 절전 기능 등

EC2 스팟 인스턴스를 통해 AWS 클라우드에서 컴퓨팅 파워를 아낄 수 있습니다. 고객들은 스팟 인스턴스 집합을 사용하여 CI/CD 환경 및 트래픽 생성기, 웹 서버 및 마이크로서비스 호스팅, 영화 렌더링을 구동하고, 많은 유형의 분석 작업을 실행합니다. 그리고 이 모든 것을 온디맨드 인스턴스와 비교하여 크게 절감된 가격으로 실행합니다.

간소화된 접근 방법
오늘은 새롭게 간소화된 스팟 인스턴스 액세스 모델을 소개하겠습니다. 다음을 통해 인스턴스를 시작할 때 스팟 용량을 사용하고 싶어하는 마음이 있을 것입니다. RunInstances 함수, run-instances 명령 또는 AWS 관리 콘솔을 통해 용량을 사용할 수 있는 동안 이행될 요청을 제출하고 싶을 것입니다. 별도의 수고 없이 인스턴스 유형에 대해 온디맨드 가격의 최대 90%를 절감한다면 동일한 예산으로 전체적인 애플리케이션 처리량을 최대 10배 늘릴 수 있는 셈입니다. 이렇게 시작한 인스턴스는 직접 종료하거나 EC2가 이를 온디맨드 사용으로 회수할 때까지 계속해서 실행될 것입니다. 이럴 경우 인스턴스가 일반적으로 2분의 경고가 주어진 다음 회수되기에 애플리케이션 내결함성에 있어 매우 적절합니다.

스팟 시장, 입찰 및 독립 실행형 비동기식 API에 대한 이해가 필요한 이전 모델과는 달리 새로운 모델은 동기식이고 온디맨드만큼 사용하기 쉽습니다. 코드와 스크립트가 인스턴스 ID를 즉시 받고, 요청이 처리 및 수락되었는지 여부를 재확인할 필요가 없습니다.

우리는 이를 최대한 명확하고 간단하게 만들었기 때문에 스팟 용량을 요청하고 사용할 많은 현재 스크립트 및 애플리케이션을 수정하기 쉬울 것으로 기대합니다. 스팟 인스턴스 예산에 대한 추가적인 통제를 행사하고자 한다면 용량 요청을 할 때 최고 가격을 지정하는 옵션이 있습니다. 스팟 용량을 사용하여 Amazon EMR, Amazon ECS 또는 AWS Batch 클러스터를 구동하거나 AWS CloudFormation 템플릿 또는 Auto Scaling 그룹을 통해 스팟 인스턴스를 시작하는 경우 어떠한 변화 없이 이 새로운 모델의 이점을 누릴 수 있습니다.

애플리케이션이 RequestSpotInstances 또는 RequestSpotFleet 를 중심으로 빌드되는 경우 어떠한 변화 없이 계속해서 작동합니다. 하지만 이제 다음 파라미터가 포함되지 않는 요청을 만들 수 있는 옵션이 있습니다. SpotPrice 파라미터입니다.

손쉬운 스팟 가격 변경
오늘 출시의 일환으로 스팟 가격의 변경 방식을 바꾸어 가격이 공급 및 수요의 장기적 추세를 기반으로 점진적으로 변하는 모델로 이동합니다. 앞서 언급한 대로 계속해서 온디맨드 가격의 평균 70~90%를 절감하고, 인스턴스가 실행 중인 기간 동안 적용되는 스팟 가격을 지불하면 됩니다. 스팟 집합 기능을 중심으로 빌드된 애플리케이션은 집합을 생성할 때 지정한 구성을 기반으로 하는 가장 비용 효율적인 풀 전체의 스팟 인스턴스 배치를 자동적으로 다양화합니다.

스팟 실행
명령줄에서 스팟 인스턴스를 시작하려면 스팟 시장을 지정하면 됩니다.

$ aws ec2 run-instances –-market Spot --image-id ami-1a2b3c4d --count 1 --instance-type c3.large 

인스턴스 최대 절전
많은 인 메모리 상태를 유지하는 워크로드를 실행한다면 이 기능이 마음에 드실 것입니다!

인스턴스가 회수될 때에도 인 메모리 상태를 저장하도록 조정하여 용량을 다시 사용할 수 있을 때 인스턴스와 인스턴스에 있는 애플리케이션이 중단된 지점에서 다시 시작하도록 할 수 있습니다. 마치 노트북을 닫았다가 다시 열어서 사용하는 것처럼 말이죠. 이 기능은 Amazon Linux, Ubuntu 또는 Windows Server를 실행하는 C3, C4, 그리고 특정 크기의 R3, R4 및 M4 인스턴스에서 작동하며, EC2 최대 절전 에이전트의 지원을 받습니다.

인 메모리 상태는 인스턴스 시작 시 별도로 확보된 공간을 사용하여 인스턴스의 루트 EBS 볼륨에 기록됩니다. 프라이빗 IP 주소와 탄력적 IP 주소 또한 중지/시작 주기에 걸쳐 유지됩니다.

Jeff;

이 글은 AWS re:Invent 2017 신규 서비스 소식으로 Amazon EC2 Update – Streamlined Access to Spot Capacity, Smooth Price Changes, Instance Hibernation의 한국어 번역입니다.

H1 인스턴스 – 빅 데이터 애플리케이션을 위한 빠른 고밀도 스토리지 정식 출시

AWS의 규모와 다양한 고객층 덕분에 우리에게는 많은 다양한 워크로드를 위해 특별히 설계된 EC2 인스턴스 유형을 만들 기회가 생겼습니다. 예를 들어 많은 대중적인 빅 데이터 사용 사례는 몇 테라바이트에 이르는 데이터에 대한 고속의 순차적 액세스에 의존합니다. 고객들은 매우 큰 MapReduce 클러스터를 빌드 및 실행하고, 분산된 파일 시스템을 호스팅하고, Apache Kafka를 사용하여 볼륨이 방대한 로그 파일을 처리하는 등의 작업을 원합니다.

새로운 H1 인스턴스
새로운 H1 인스턴스는 특히 이러한 사용 사례를 위해 설계되었습니다. 기존 D2(고밀도 스토리지) 인스턴스와 비교해 H1 인스턴스는 로컬 마그네틱 스토리지에 더 많은 vCPU와 더 많은 테라바이트당 메모리를 제공하고, 네트워크 대역폭 또한 증가하여 최적의 균형을 갖춘 리소스 조합을 통해 더욱 복잡한 문제를 해결할 수 있습니다.

인스턴스는 기본 클럭 주파수 2.3GHz에서 실행되는 인텔 Xeon E5-2686 v4 Broadwell 프로세서를 기반으로 하고, 4개의 인스턴스 크기로 구성됩니다(모두 VPC 전용 및 HVM 전용).

인스턴스 이름 vCPU
RAM
로컬 스토리지 네트워크 대역폭
h1.2xlarge 8 32GiB 2TB 최대 10Gbps
h1.4xlarge 16 64GiB 4TB 최대 10Gbps
h1.8xlarge 32 128GiB 8TB 10Gbps
h1.16xlarge 64 256GiB 16TB 25Gbps

크기가 가장 큰 2개는 올 코어 Turbo(2.7GHz) 및 싱글 코어 Turbo(3.0GHz)를 통해 인텔 Turbo 및 CPU 성능 관리를 지원합니다.

로컬 스토리지가 최적화되어 순차 I/O에 대한 높은 처리량을 제공합니다. 따라서 2메가바이크의 블록 크기를 사용한다면 최대 초당 4.5기가바이트의 전송을 기대할 수 있습니다. 스토리지는 256비트 XTS-AES와 1회용 키를 사용하여 유휴 상태에서 암호화됩니다.

향상된 네트워킹을 사용하여 인스턴스에서 대량의 데이터 이동이 지원되어 배치 그룹 내에서 최대 25Gbps의 네트워크 대역폭을 확보할 수 있습니다.

정식 출시
H1 인스턴스는 현재 미국 동부(버지니아 북부), 미국 서부(오레곤), 미국 동부(오하이오)EU(아일랜드) 리전에서 사용 가능합니다. 온디맨드 또는 스팟 형식으로 시작할 수 있습니다. 전용 호스트, 전용 인스턴스 및 예약 인스턴스(1년 및 3년) 또한 사용 가능합니다.

Jeff;

이 글은  AWS re:Invent 2017 신규 서비스 출시 소식으로 H1 Instances – Fast, Dense Storage for Big Data Applications의 한국어 번역입니다.

M5 – 차세대 범용 EC2 인스턴스 정식 출시

저는 항상 신규 EC2 사용자들에게 다른 인스턴스 유형을 살펴보기 전에 우리의 범용 인스턴스로 시작하여 스트레스 테스트를 몇 가지 실행하고, 애플리케이션의 컴퓨팅, 메모리 및 네트워킹 프로필이 정상적인지 확인할 것을 조언합니다. 컴퓨팅, 메모리 및 스토리지에 최적화된 인스턴스의 선택권이 폭넓은 가운데 우리 고객에게는 요구 사항에 가장 적합한 인스턴스 유형을 선택할 많은 옵션과 유연성이 있습니다.

EC2 인스턴스 내역 게시물에서 볼 수 있듯 범용(M) 인스턴스의 시작은 우리가 m1.small을 출시한 2006년으로 거슬러 올라갑니다. 그리고 M2(2009년), M3(2012년) 및 M4(2015년) 인스턴스를 출시하면서 제품군을 계속해서 진화시켰습니다. 우리의 고객들은 범용 인스턴스를 사용하여 웹 및 앱 서버를 실행하고, 엔터프라이즈 애플리케이션을 호스팅하고, 온라인 게임을 지원하며, 캐시 집합을 빌드합니다.

새로운 M5 인스턴스
오늘은 새로운 M5 인스턴스 출시를 통해 한 걸음 더 전진합니다. 이러한 인스턴스를 통해 우리의 지속적인 혁신에 대한 노력과 이전 인스턴스에 비해 더 나아진 가격/성능을 누릴 수 있습니다. 2.5GHz로 실행되는 맞춤형 인텔® Xeon® Platinum 8175M 시리즈 프로세서를 기반으로 하는 M5 인스턴스는 고도로 까다로운 워크로드를 위해 설계된 제품으로 코어당 기준으로 M4 인스턴스 대비 14% 더 나아진 가격/성능을 제공합니다. AVX-512 명령을 사용하는 애플리케이션은 FLOPS가 최대 2배에 달합니다. 또한 하이엔드에 새 크기를 추가하여 더 많은 옵션을 제공합니다.

M5 인스턴스는 다음과 같습니다(모두 VPC 전용, HVM 전용 및 EBS 최적).

인스턴스 이름 vCPU
RAM
네트워크 대역폭 EBS 최적 대역폭
m5.large 2 8GiB 최대 10Gbps 최대 2,120Mbps
m5.xlarge 4 16GiB 최대 10Gbps 최대 2,120Mbps
m5.2xlarge 8 32GiB 최대 10Gbps 최대 2,120Mbps
m5.4xlarge 16 64GiB 최대 10Gbps 2,120Mbps
m5.12xlarge 48 192GiB 10Gbps 5,000Mbps
m5.24xlarge 96 384GiB 25Gbps 10000Mbps

라인업에서 가장 높은 m5.24xlarge는 vCPU 수와 메모리에 있어 X1 인스턴스 다음으로, 워크로드를 확장 및 통합할 수 있는 더 많은 공간을 제공합니다. 향상된 네트워킹을 지원하는 인스턴스이며, 배치 그룹 내에서 사용할 때 최대 25Gbps를 제공합니다.

EBS에 대한 전용, EBS 최적 대역폭에 추가로 NVMe의 사용을 통해 EBS 스토리지에 대한 액세스가 향상됩니다(이전 AMI를 사용하는 경우 적절한 드라이버를 설치해야 합니다). 더 많은 대역폭과 NVMe의 조합을 통해 M5 인스턴스가 소화할 수 있는 데이터의 양이 증가합니다.

정식 출시
현재 미국 동부(버지니아 북부), 미국 서부(오레곤)EU(아일랜드) 리전에서 온디맨드 및 스팟 형식(예약 인스턴스 또한 사용 가능)으로 M5 인스턴스를 시작할 수 있으며, 리전 추가 작업이 진행 중입니다.

간단한 참고 사항: 현재 NVMe 드라이버가 고성능 순차 워크로드에 최적화되지 않은 경우 M5 인스턴스를 sc1 또는 st1 볼륨과 결합하여 사용하는 것을 권장하지 않습니다. 우리는 이 문제를 주시하고 있으며, 이러한 중요 사용 사례를 위한 드라이버 최적화에 노력을 기울이고 있습니다.

Jeff;

이 글은 re:Invent 2017의 신규 서비스 출시 소식으로 M5 – The Next Generation of General-Purpose EC2 Instances의 한국어 번역입니다.

Amazon EC2 베어 메탈 인스턴스(하드웨어 직접 액세스 포함) 출시!

고객들이 AWS에 대한 새롭고 특별한 요구 사항을 가지고 우리를 찾아오면, 우리는 여기에 귀를 기울이고, 많은 질문을 던지며, 그 요구 사항을 이해하고 해결하는 데 최선을 다합니다. 이렇게 할 때 결과로 나오는 서비스 또는 기능을 일반적으로 사용할 수 있도록 합니다. 각각의 고객에게 별개로 1회성 서비스나 기능을 빌드하지 않습니다. 그러한 모델은 복잡하고 확장이 어렵기 때문에 우리는 이런 방식으로 하지 않습니다.

대신 모든 AWS 고객은 우리가 빌드한 것이 무엇이든 액세스할 수 있고, 모두가 혜택을 누리게 됩니다. AWS 기반 VMware 클라우드가 이러한 전략 실행의 좋은 예입니다. 하드웨어에서, AWS 클라우드 내에서 가상화 스택을 직접 실행함으로써 고객이 AWS에서 제공하는 탄력성, 보안 및 안정성(다양한 서비스는 말할 것도 없습니다)에 액세스할 수 있기를 원한다는 이야기를 들었습니다.

우리는 다른 고객들 또한 베어 메탈 하드웨어에 대한 사용 사례에 관심이 있고, 중첩 가상화로 인한 성능 저하를 원치 않는 것을 파악했습니다. 가상화 환경에서 언제든 사용 가능하거나 완전히 지원되지 않는 성능 카운터인텔® VT와 같은 하위 수준 하드웨어 기능을 활용하는 애플리케이션은 물론 하드웨어에서 직접 실행되거나 비가상화 환경에서의 사용에 대한 라이선스 및 지원을 받는 애플리케이션에 대한 물리적 리소스 액세스를 원했습니다.

여러 해에 걸쳐 네트워킹, 스토리지 및 기타 EC2 기능을 가상화 플랫폼에서 전용 하드웨어로 이동하려는 노력이 이미 진행되어 가능한 해결책에 대한 완벽한 기반이 제공되었습니다. 이제 Amazon EC2용 컴퓨팅 집약적 C5 인스턴스 이용 가능이라는 게시물에서 설명한 이러한 노력에는 전용 하드웨어 액셀러레이터 세트도 포함됩니다.

요청한 대로 VMware에 베어 메탈 액세스를 제공했으니, 이제 모든 AWS 고객들을 위해서도 똑같이 하겠습니다. 이를 통해 여러분들이 할 수 있는 것들이 무척 기대됩니다!

새로운 베어 메탈 인스턴스
오늘은 i3.metal 인스턴스의 퍼블릭 미리 보기를 출시합니다. 양쪽의 장점을 모두 제공하는 EC2 인스턴스 시리즈의 첫 번째 제품으로, 운영 체제가 기본 하드웨어에서 직접 실행되도록 하면서 클라우드의 모든 이점에 액세스할 수 있도록 합니다. 인스턴스를 통해 프로세서 및 기타 하드웨어에 직접 액세스할 수 있으며, 사양은 다음과 같습니다.

  • 프로세싱 – 2.3GHz에서 실행되는 2개의 인텔 Xeon E5-2686 v4 프로세서, 총 36개의 하이퍼스레드 코어(72개의 논리 프로세서).
  • 메모리 – 512GiB.
  • 스토리지 – 15.2테라바이트의 로컬, SSD 기반 NVMe 스토리지.
  • 네트워크 – 25Gbps의 ENA 기반 향상된 네트워킹.

베어 메탈 인스턴스는 EC2 패밀리의 완성된 멤버이며, Elastic Load Balancing, Auto Scaling, Amazon CloudWatch, Auto Recovery 등을 활용할 수 있습니다. 또한 AWS 데이터베이스, IoT, 모바일, 분석, 인공 지능보안 서비스의 전체 스위트에 액세스할 수 있습니다.

현재 미리 보기 진행 중
현재 베어 메탈 인스턴스의 퍼블릭 미리 보기를 출시 중입니다. 시험해 보고자 하는 경우 지금 가입하세요.

이제 특수 애플리케이션 또는 가상화된 구성 요소 스택을 AWS로 가져와 베어 메탈 인스턴스에서 실행할 수 있습니다. 컨테이너를 사용 중이거나 이를 고려 중인 경우 이러한 인스턴스가 CoreOS의 뛰어난 호스트를 만듭니다.

새로운 C5 인스턴스 중 하나에서 작동하는 AMI는 I3 베어 메탈 인스턴스에서 또한 작동합니다. ENA 및 NVMe 드라이버를 보유해야 하고, ENA에 대해 태그 지정되어야 합니다.

Jeff;

이 글은 AWS re:Invent 2017 행사의 주요 서비스 출시 소식으로  Amazon EC2 Bare Metal Instances with Direct Access to Hardware의 한국어 번역입니다.

Amazon EC2 업데이트 – 신규 X1e 인스턴스 타입과 더욱 강력한 서비스 수준(SLA) 지원

올해 초에 4개의 AWS 리전에 4TB의 메모리를 포함한 x1e.32xlarge 인스턴스를 출시했습니다. 그리고 출시 후 2개월이 지난 현재, 고객들은 이 인스턴스를 사용하여 대용량 메모리를 활용할 수 있는 고성능 관계형 및 NoSQL 데이터베이스, 인 메모리 데이터베이스, 그리고 기타 엔터프라이즈 애플리케이션을 실행하고 있습니다.

5가지 이상 크기의 X1e
5개의 추가적인 인스턴스 크기가 포함된 메모리 최적화 X1e 패밀리를 소개합니다. 라인업은 다음과 같습니다.

모델 vCPU 메모리(GiB) SSD 스토리지(GB) 네트워킹 성능
x1e.xlarge 4 122 120 최대 10Gbps
x1e.2xlarge 8 244 240 최대 10Gbps
x1e.4xlarge 16 488 480 최대 10Gbps
x1e.8xlarge 32 976 960 최대 10Gbps
x1e.16xlarge 64 1,952 1,920 10Gbps
x1e.32xlarge 128 3,904 3,840 25Gbps

인스턴스는 대용량 L3 캐시와 많은 메모리 대역폭을 갖추고 2.3GHz에서 실행되는 쿼드 소켓 인텔® Xeon® E7 8880 프로세서에 의해 구동됩니다. ENA 네트워킹 및 EBS 최적화가 표준이며, 최대 14Gbps의 EBS 전용 처리량을 포함합니다(인스턴스 크기에 따라 다름).

오늘 출시의 일환으로 모든 크기의 X1e를 아시아 태평양(시드니) 리전에서 사용할 수 있습니다. 따라서, 미국 동부(버지니아 북부), 미국 서부(오레곤), EU(아일랜드), 아시아 태평양(도쿄)아시아 태평양(시드니) 리전의 온 디맨드 및 예약 인스턴스에서 이를 시작할 수 있습니다.

더욱 강력한 EC2 서비스 수준(SLA) 추가
좋은 소식이 하나 더 있습니다!

지금 이후로 모든 리전 및 모든 AWS 고객에 대한 EC2 및 EBS 모두의 EC2 서비스 수준 계약(SLA)을 99.99% (기존 99.95%)로 높혔습니다. 지속적인 인프라 및 서비스 품질 투자와 함께 운영 우수성에 집중한 덕분에 이러한 변화가 가능했습니다.

Jeff

AWS PrivateLink 출시 – VPC내 AWS 서비스 엔드 포인트 서비스

이 글은 Amazon Virtual Private Cloud의 선임 엔지니어인 Colm MacCárthaigh가 작성한 것입니다.


VPC 엔드포인트가 2015년에 출시된 이후, 인터넷 게이트웨이, NAT 게이트웨이 또는 방화벽 프록시 없이 Amazon Virtual Private Cloud(VPC)에서 S3 및 DynamoDB에 안전하게 액세스하는 방법으로 엔드포인트가 인기를 끌고 있습니다. VPC 엔드포인트를 사용하면 VPC와 AWS 서비스 사이의 라우팅이 AWS 네트워크에서 처리되고 IAM 정책을 사용하여 서비스 리소스에 대한 액세스를 제어할 수 있습니다.

모든 트래픽을 AWS 네트워크 내에 유지하면서 높은 가용성과 확장성으로 AWS 서비스를 액세스할 수 있도록 설계된 최신 VPC 엔드포인트인 AWS PrivateLink가 오늘 출시되었습니다. 이제 Kinesis, Service Catalog, Amazon EC2, EC2 Systems Manager(SSM) 및 Elastic Load Balancing(ELB) API를 VPC 내에서 사용할 수 있으며, Key Management Service(KMS) 및 Amazon Cloudwatch와 같은 더 많은 서비스가 곧 지원될 예정입니다.

기존 엔드포인트를 사용하는 것은 VPC와 AWS 서비스 사이를 가상 케이블로 연결하는 것과 매우 유사합니다. AWS 서비스를 연결하는 데 인터넷 또는 NAT 게이트웨이가 필요하지는 않지만, 엔드포인트가 VPC 외부에 유지됩니다. PrivateLink를 사용하면 VPC 서브넷의 IP 주소와 ENI를 사용하여 VPC 내에 엔드포인트가 직접 생성됩니다. 이제 서비스가 VPC 내에 있으므로 프라이빗 IP 주소를 통해 AWS 서비스에 연결할 수 있습니다. 즉, VPC 보안 그룹을 사용하여 엔드포인트에 대한 액세스를 관리하고 AWS Direct Connect를 통해 자체 환경에서 PrivateLink 엔드포인트에 액세스할 수도 있습니다.

이제 인터넷을 통해 트래픽을 전달할 필요 없이 PrivateLink에서 제공하는 서비스를 사용하여 인스턴스 플릿을 관리하고, IT 서비스의 카탈로그를 생성 및 관리하며, 데이터를 저장하고 처리할 수 있습니다.

PrivateLink 엔드포인트 만들기
PrivateLink 엔드포인트를 만들려면 VPC 콘솔로 이동하여 [Endpoints]를 선택하고 [Create Endpoint]를 선택합니다.

그런 다음 액세스할 서비스를 선택합니다. 새 PrivateLink 엔드포인트는 “interface” 유형입니다. 여기서는 내 VPC에서 직접 Kinesis 서비스를 사용할 것이므로 kinesis-streams 서비스를 선택합니다.

이 시점에서 내 새 엔드포인트를 시작할 VPC를 선택하고 ENI 및 IP 주소가 배치될 서브넷을 선택할 수 있습니다. 또한 엔드포인트를 신규 또는 기존 보안 그룹과 연결하여 엔드포인트에 액세스할 수 있는 인스턴스를 제어할 수 있습니다.

PrivateLink 엔드포인트에서는 내 VPC의 IP 주소를 사용하므로 VPC 프라이빗 DNS를 사용하여 AWS 서비스 DNS 이름에 대한 DNS를 재정의할 수 있습니다. [Enable Private DNS Name]을 선택된 상태로 두고 VPC 내에서 “kinesis.us-east-1.amazonaws.com”을 조회하여, 만들려는 엔드포인트에 대한 IP 주소를 확인할 수 있습니다. 그러면 애플리케이션을 변경하지 않고 엔드포인트로 원활하게 전환할 수 있습니다. 트래픽이 기본적으로 처리되기 이전에 엔드포인트를 테스트하거나 구성하려면 이 설정을 비활성화한 다음 언제든지 엔드포인트를 편집하여 변경할 수 있습니다.

준비가 되고 VPC, 서브넷 및 DNS 설정이 만족스러우면 [Create Endpoint]를 클릭하여 프로세스를 완료합니다.

PrivateLink 엔드포인트 사용

기본적으로 프라이빗 DNS 이름을 활성화한 상태에서 PrivateLink 엔드포인트를 사용하는 것은 VPC 내에서 서비스 API에 액세스하는 SDK, AWS CLI 또는 다른 소프트웨어를 사용하는 것만큼 간단합니다. 코드 또는 구성을 변경할 필요가 없습니다.

또한 테스트 및 고급 구성을 지원하기 위해 모든 엔드포인트에서는 엔드포인트에 고유하고 전용으로 사용되는 일련의 DNS 이름을 가져옵니다. 엔드포인트 및 영역 이름에 대한 기본 이름이 있습니다.

기본 이름은 온프레미스에서 DNS 재정의를 사용할 필요 없이 Direct Connect를 통해 엔드포인트에 액세스하는 데 특히 유용합니다. 일반적으로 기본 이름은 VPC 내에서도 사용할 수 있습니다.
재정의하도록 선택했으므로 기본 이름과 기본 서비스 이름은 영역 내결함성을 포함하며 가용 영역 간에 트래픽을 밸런스를 조정합니다. 또한 결함 제약 및 분류, 짧은 지연 시간, 리전 데이터 전송 최소화 등을 위해 영역 격리 기술을 사용하는 아키텍처가 있을 경우 영역 이름을 사용하여 트래픽을 트래픽 흐름을 영역 사이에서 유지할지 영역 내에서 유지할지를 명시적으로 제어할 수 있습니다.

요금 및 가용성
AWS PrivateLink는 이제 중국(베이징)을 제외한 모든 AWS 상용 리전에서 이용 가능합니다. 리전별 개별 서비스의 이용 가능 여부는 문서를 확인하십시오.

요금은 시간당 0.01달러에서 시작하며 GB당 0.01달러의 데이터 처리 요금이 추가됩니다. 또한 가용 영역 간에 전송된 데이터와 엔드포인트와 프레미스 간에 Direct Connect를 통해 전송된 데이터에는 일반 EC2 리전 및 Direct Connect 데이터 전송 요금이 청구됩니다. 자세한 내용은 VPC 요금을 참조하십시오.

Colm MacCárthaigh;

이 글은 New – AWS PrivateLink for AWS Services: Kinesis, Service Catalog, EC2 Systems Manager, Amazon EC2 APIs, and ELB APIs in your VPC 의 한국어 번역입니다.

Sprinklr의 AWS 리전간 대용량 재해 복구 구축 사례

Sprinklr에서 통합된 고객 경험 관리 플랫폼을 통해 세계에서 가장 큰 브랜드 기업들의 마케팅, 광고, 조사, 관리, 상거래를 지원합니다. Facebook, Twitter, LinkedIn 및 전 세계 22개 기타 소셜 채널과 통합된 당사 플랫폼은 수천 개의 서버를 사용하고, 페타바이트 단위의 데이터를 조사하고, 매일 수십억 건의 트랜잭션을 처리합니다. Twitter 하나만 해도 하루에 몇 억 개의 트윗을 처리해야 합니다.

매일 처리하는 엄청난 데이터 양을 고려할 때 재해 복구(Disaster Recovery, DR)는 더없이 중요한 문제입니다. 자연재해나 인재가 발생하더라도 비즈니스 연속성이 보장되어야 합니다.

대부분의 기업은 DR 대신에 고가용성(HA)을 구현하여 서비스 가동 중지 상황에 대비합니다. HA 보장을 위한 서비스 폴백 메커니즘을 갖추고 있습니다. HA 모드로 실행되는 서비스는 여러 가용 영역에서 실행되지만 동일한 지리적 리전에 속하는 호스트가 처리합니다. 그러나 이러한 접근 방식은 리전 전체가 다운된 경우에 비즈니스의 정상적인 운영을 보장하지 않습니다. DR은 250마일 이상 떨어진 다른 리전에서 복구할 수 있다는 점에서 완전히 새로운 차원을 보여 줍니다. DR 구현은 액티브/패시브 모델로, 이는 여러 리전에서 중요성이 가장 덜한 서비스를 항상 실행하지만 필요할 때 인프라의 주요 부분이 시작 및 복원됨을 뜻합니다.

당면 과제

재해 발생 시 비즈니스 운영이 중단되는 위험을 감수하고 싶지 않습니다. 고객에 대한 약속의 일환으로 튼튼한 재해 복구 프로세스를 갖춰야 합니다. 이는 어느 비즈니스에나 매우 중요합니다. 예를 들어 허리케인 샌디가 기승을 부릴 때 미국 북동부 지역에 데이터 센터가 있는 일부 회사만이 홍수로 인해 오프라인 상태가 되었습니다. 당사 DR의 경우 복구 목표 시점(RPO)이 24시간입니다. 이는 복구할 데이터가 생성된 지 24시간이 지나지 않았음을 뜻합니다. 복구 목표 시간(RTO)은 DR이 선언된 시점으로부터 복원이 완료되기까지 걸리는 시간을 뜻하며, 당사의 경우 고객 SLA에 따라 6시간~24시간입니다. 테스트를 하면서 RTO를 4시간으로 정했습니다.

재해 복구(DR)를 위한 단계

규모 파악

Sprinklr의 리전 간 재해 복구 동기화

목표를 이해하려면 서비스 유형과 그 개수를 포함하여 현재의 작업 규모를 고려해야 합니다. MongoDB, Elasticsearch, SOLR, Mesos, RDS 등 광범위한 데이터/비데이터 서비스 목록이 있습니다. 따라서 서버가 수천 개에 이르는데, ELB는 거의 100개, route53 항목 약 4,000개, 1페타바이트 이상의 기본 데이터, 그리고 RDS 인스턴스 50개 이상이 있습니다. 이러한 서비스는 모두 복원 시점에 DR 리전에서 시작되어야 합니다.

목적 달성을 위해 사용자 지정 스크립트를 작성했는데, 이 스크립트는 주로 AWS API 호출을 통해 인스턴스를 시작하고, 스냅샷을 연결하고, elb 및 경로 항목을 생성합니다.

위 그림과 같이, 관련된 모든 백업은 복원을 위해 DR 리전으로 복사됩니다.

복사할 백업 유형은 크게 세 가지입니다.

  1. EBS 스냅샷: 사용자 지정 로직을 구축하여 사용 가능한 모든 백업과 그 진행 상황 및 완료 여부를 지능적으로 추적합니다.  AWS 한도를 넘지 않고 전체 스냅샷 사본을 얻고자 노력합니다.
  2. S3 스냅샷: cross s3 동기화를 사용하며, 이는 매우 효과적으로 작동합니다. 단 몇 분만에 기본 리전에서 DR 리전으로 데이터를 복사할 수 있습니다.
  3. RDS 스냅샷: AWS RDS CopyDBSnapshot API를 사용하여 RDS 스냅샷을 복사합니다.

DR을 위한 파일럿 라이트 설정

재해 복구 미리 설정빠른 시작을 위해, 재해 복구를 위한 게이트웨이를 얻으려면 몇 가지 서비스가 실행 중이어야 합니다. VPC, 서브넷, Route53 항목을 설정하는 것도 여기에 포함됩니다. 이를 위해 사용자 지정 도구를 구축했습니다. 비슷한 CIDR 구성과 서브넷 마스킹으로 VPC를 만들고, 경로 항목의 경우 새 서브넷이 생성될 때마다 DR 리전에도 자동으로 생성되도록 합니다. 이를 위해 AWS API 호출을 통해 기본 리전의 서브넷 정보를 파악하고, 서부 리전에 해당하는 서브넷을 만들었습니다.

없을 경우 복원을 시작하기 위한 항목을 얻을 수 없는 필수 서비스를 파악합니다. 이는 인증 서버(ldap/IPA, 있는 경우), 빌드 서버 또는 모니터링 서버일 수 있습니다. 이러한 서비스는 항상 실행 중이어야 합니다. 즉 시작 및 설정한 후 어떠한 예기치 못한 상황에서도 항상 DR 리전으로 항목을 가져올 수 있도록 이러한 서비스를 계속 실행함을 뜻합니다.

또한 종속된 AWS 서비스를 사용할 수 있어야 합니다. 예를 들어 S3 버킷을 DR 리전에서 사용할 수 있어야 하고 항상 기본 리전과 동기화해야 합니다. 많은 구성, 속성 파일, 바이너리가 S3에 있기 때문에 이 단계는 중요합니다. 애플리케이션이 계속 작동되도록 하려면 DR 리전에서 이를 사용할 수 있도록 해야 합니다. 이를 위해 S3 교차 리전 복제 기능을 사용합니다. 이는 객체를 빠르고 거의 동시에 동기화하여 놀라운 작업을 수행합니다.

재해 복구 용량 계획의 그림

용량 계획

이제 규모를 고려하여 DR의 필요 용량을 알아내야 합니다.

애플리케이션 관점에서 첫 단계는 DR 리전에서 필요한 구성을 사용할 수 있는지 확인하는 것입니다. 이때 필요한 구성이란 DB별로 다른 파라미터일 수도 있고 사용자 지정된 설정 관련 파라미터일 수도 있지만, 기본적으로 애플리케이션이 작동하는 데 필요한 모든 것을 말합니다. 위 그림과 같이, 복원하는 각 파트너가 당사 DB에 저장한 속성을 토대로 다양한 서비스의 필요 용량을 파악합니다. 예를 들어 파트너 Z는 ES 클러스터 70개, MongoDB 40개, RDS 30개, SOLR 20개가 필요합니다. 다음 단계에서는 모든 서비스를 종합적으로 고려하여 특이한 것을 찾아냅니다. 파트너 간에 클러스터 DB를 공유하므로, 최초의 필요 용량에 있던 클러스터 중 일부를 실제로 다른 파트너들도 공유할 수 있기 때문입니다. 이렇게 해서 최종적인 필요 용량을 파악하고, 이를 인스턴스 유형별로 나눕니다. 위 그림과 같이 Elasticsearch 등 서비스마다 인스턴스 유형이 서로 다릅니다. 마지막으로 해당 인스턴스 유형의 총 필요 용량을 파악하는 일이 남았습니다.

첫 번째 단계가 명확해지면 ELB 및 경로 항목을 몇 개나 생성해야 하는지 알아냅니다. AWS API로 얻은 ELB 및 경로 항목 정보에 대한 메타데이터를 보유하고 있습니다. 이 정보는 서부에 항상 준비되어 있습니다. 이 방법으로 필요 용량의 정확한 수를 알아내고, 인프라를 추정합니다. 여기에는 EC2, ELB 및 경로 항목을 위한 용량 계획도 포함됩니다.

원활한 복구를 위해서는 위 단계 모두 중요하고 서로 밀접하게 관련되어 있으며, 가급적 이를 자동화하는 것이 좋습니다. 우리는 AWS API 호출을 사용한 Perl로 사용자 지정 스크립트를 작성하여 이 모든 단계를 자동화했습니다.

재해 발생 시

우선 순위 정하기

존재하는 여러 서비스 중에 가장 중요한 서비스를 기준으로 시작의 우선 순위를 정하고 서비스의 EC2 인스턴스를 시작해야 합니다. 서비스를 세 가지 세트로 나누는 것이 좋습니다. 이는 핵심적인 서비스를 쉽게 시작할 수 있도록 하기 위한 중요한 결정입니다. 우리가 피하고자 하는 주요 방해 요소는 AWS의 용량 또는 한도 문제입니다.  서비스를 나누면 API 호출 수가 적어지며, AWS가 그 시점에 보유하고 있는 티어 1 서비스에 사용 가능한 인스턴스 유형을 모두 활용할 수 있습니다. 두 번째 세트와 세 번째 세트는 다음에 시도합니다. 이러한 접근 방법의 장점은 우선 AWS API 호출을 너무 많이 사용하지 않고, 복원이 충돌하지 않는다는 것입니다. 이를 위해 다시 사용해야 할 것 같은 AWS API 호출 출력을 캐시하는 캐싱 로직을 개발했습니다. 이를 통해 API 호출 수를 50% 줄일 수 있습니다. 두 번째는 사용 가능한 용량이 대부분 가장 핵심적인 서비스에 할당된다는 점입니다.

용량에 대비한 플랜 B

당장 재해가 발생하면 원하는 인스턴스를 마음대로 시작하지 못할 수 있으므로 실행 시간 인텔리전스를 구축할 필요가 있습니다.

우선 순위가 두 번째나 세 번째인 서비스를 할 때쯤이면 사용 가능한 용량을 다 써버렸을 수도 있습니다. 따라서, 용량 한도를 이미 늘렸습니다. 그러나 어떤 인스턴스 유형은 DR 시점에 AWS에서 사용하지 못할 수 있고, 이로 인해 전체 DR 작업이 위험에 빠질 가능성이 있습니다.

이러한 위험을 완화하기 위해 플랜 B를 수립했습니다. 플랜 B가 준비되고 자동화를 통해 인텔리전스를 구축하여 동일한 패밀리의 다른 인스턴스 유형을 시작합니다. 이 인텔리전스를 구축하기 위해 AWS CloudWatch를 사용합니다. AWS CloudWatch 측정치의 정보를 사용하여 기본 리전의 인스턴스 사용량을 분석합니다. 이를 통해 현재 인스턴스 패밀리 및 유형을 사용할 수 없는 경우에 사용할 수 있는 인스턴스 패밀리 및 유형을 알아낼 수 있습니다. 다시 말해 r3.xlarge 인스턴스 유형을 사용하는 특정 서비스를 예로 들면, CloudWatch 측정치 덕분에 이 서비스가 사용하고 시작해 볼 수 있는 다음 인스턴스 유형을 정하기 위한 모든 정보를 확인할 수 있습니다.

새 인스턴스 유형을 결정하고 나면 인스턴스 개수를 계산해야 합니다. 예를 들어 r3.2xlarge에서 r3.xlarge로 한 단계 아래로 가면 용량을 두 배로 늘려야 할 수 있으며, 한 단계 위로 가면 용량을 절반으로 줄여야 할 수 있습니다. 따라서 실행 시 이를 계산해야 합니다.

다른 AWS 서비스 복원 및 시작

ELB, Route 등 EC2 이외의 서비스 시작이 이제 트리거됩니다. 기본 리전의 S3에서 동기화된 메타데이터를 사용하여 이러한 서비스를 불러옵니다. 메타데이터 정보에는 이 서비스를 시작하는 데 필요한 정보가 들어 있습니다. ELB의 경우 ELB 유형(내부 또는 외부), 인증서 정보, 연결된 서브넷, 연결된 인스턴스입니다. 경로 항목의 경우 DNS 레코드 유형과 그 값입니다.

구성을 위해 EC2 인스턴스 정보가 필요할 수 있으므로 EC2를 시작한 후 이를 시작합니다. 예를 들어 경로 항목에는 EC2 인스턴스의 퍼블릭 IP 주소 정보가 필요할 수 있습니다.

애플리케이션 복원

위 단계를 실행했으면 절반은 온 것입니다. AWS에서 리소스를 가져왔고 애플리케이션 요구 사항에 따라 이를 구성할 수 있었기 때문입니다. AWS에서 얻고자 하는 필요 용량이 대부분 처리되었습니다. 나머지는 주로 애플리케이션 및 로직과 관련이 있습니다. 코드베이스를 사용할 수 있게 준비해 두는 것과 필요 시 DR 리전에 바로 빌드를 배포할 수 있도록 하는 것도 여기에 포함됩니다.

직면한 문제 및 수정

위 모델을 구현한 후 API 호출과 관련된 몇 가지 문제에 직면했습니다. 복원 규모로 인해 엄청난 수의 API 호출이 발생했고, AWS에서는 이를 조정했습니다. API에서 보내는 막대한 정보를 캐시하기 위해 인텔리전트 캐싱 시스템을 개발했습니다. 그 결과 AWS API 호출이 처음의 4분의 1로 줄었습니다.

이 블로그 게시물에서 DR 프로세스의 계획 방식에 대한 아이디어를 얻으시기 바랍니다. DR 계획을 수립하고 주기적으로 테스트하는 것은 자연재해나 인재 발생 시 비즈니스 운영이 중단되지 않도록 하는 데 매우 중요합니다. 자세히 알아보려면 Sprinklr 웹 사이트를 방문하십시오.

이 글은 소셜 미디어 통합 관리 서비스인 Sprinklr의 책임 설계자인Senthilkumar Ramaswamy와 DevOps 책임 엔지니어 Rakesh Pillai가 작성한 AWS Startup 블로그의 Large scale disaster recovery using AWS regions의 한국어 번역입니다.

Amazon EC2 F1 인스턴스와 FireSim을 이용한 클라우드 기반 하드웨어 디자인 사례

AWS는 고급 분석, 심층 학습 및 AI 영역에서 글로벌 성장을 활성화하는 한 가지 방법으로 FPGA를 AWS 클라우드 컴퓨팅 제공에 추가했습니다. EC2  F1  인스턴스 타입은 하드웨어 가속을 사용하여 전용 PCIe x16 연결을 통해 각각 64GiB DDR4 ECC 보호 메모리를 포함한 최대 8개 FPGA의 상호 연결을 활성화합니다. 따라서, 이 서버는 모든 규모에서 상당히 빠른 속도로 고급 분석 애플리케이션을 처리할 수 있는 용량을 갖춘 강력한 엔진이 됩니다. 예를 들어, AWS 상업용 파트너인 Edico Genome은 F1 인스턴스로 구성되는 DRAGEN 플랫폼을 사용하여 전체 게놈 시퀀싱 데이터 세트를 분석할 때 약 30배의 속도 향상을 달성할 수 있습니다.

FPGA F1 컴퓨팅의 온디맨드 가용성이 확실한 액세스 가능성과 비용 이점을 제공하지만, 많은 메인스트림 사용자는 여전히 FPGA 가속 시뮬레이션을 개발하거나 실행할 때 “진입 임계값”이 너무 높다고 생각하고 있습니다. UC Berkeley RISE Lab의 연구자들은 Amazon FPGA F1 인스턴스로 구동되는 “FireSim“을 개발했습니다. 오픈 소스 리소스인 FireSim은 이러한 진입 장벽을 낮추고 모든 사람이 FPGA 가속 컴퓨팅 환경의 성능을 쉽게 활용할 수 있도록 지원합니다. 소규모 스타트업 기업의 개발 팀에 속하든 또는 대형 데이터센터 규모에서 작업하든 상관없이 하드웨어-소프트웨어 공동 설계를 사용하면 더 빠른 개발 시간, 더 낮은 비용, 더 예측 가능한 성능을 달성할 수 있습니다. UC-Berkeley의 Sagar Karandikar와 동료들의 FireSim을 이 게시물에서 소개하게 되어 기쁘게 생각합니다.

Amazon EC2 F1에 8노드 FireSim 클러스터 시뮬레이션 매핑

기존 하드웨어 조정이 한계에 도달함에 따라 향후 데이터 센터는 다양한 이질성을 지향하고 사용자 지정 하드웨어 액셀러레이터와 점점 더 높은 성능의 상호 연결을 채택하고 있습니다. 기존 방식으로는 규모에 맞게 새로운 하드웨어의 프로토타입을 작성하려면 비용이 매우 많이 들거나 속도가 매우 느렸습니다. 이 게시물에서는 UC Berkeley의 컴퓨터 아키텍처 연구 그룹에서 개발 중인 새로운 하드웨어 시뮬레이션 플랫폼 FireSim을 소개합니다. 이 플랫폼은 Amazon EC2 F1 인스턴스를 사용하여 빠르고 확장 가능한 하드웨어 시뮬레이션을 활성화합니다.

FireSim은 새로운 랙 규모 시스템에서 작업하는 하드웨어 및 소프트웨어 개발자에게 모두 이점을 제공합니다. 소프트웨어 개발자는 실제 머신을 사용할 때와 똑같이 새로운 하드웨어 기능과 함께 시뮬레이션된 노드를 사용할 수 있는 반면, 하드웨어 개발자는 시뮬레이션되는 하드웨어를 완전히 제어할 수 있으며 하드웨어가 여전히 개발 중인 동안 실제 소프트웨어 스택을 실행할 수 있습니다. 이 게시물과 함께 FireSim의 첫 번째 공개 데모를 릴리스하고 있습니다. 이 데모를 사용하여 고유의 8노드 시뮬레이션된 클러스터를 F1 인스턴스에 배포하고 해당 클러스터에 대해 벤치마크를 실행할 수 있습니다. 이 데모에서는 사전 빌드된 “vanilla” 클러스터를 시뮬레이션하지만, FireSim의 높은 성능과 가용성을 보여 줍니다.

FireSim + F1을 선택하는 이유

FPGA 가속 하드웨어 시뮬레이션은 새로운 개념이 아닙니다. 하지만 이전에는 FPGA를 시뮬레이션에 사용할 경우 가용성, 확장성 및 비용 문제가 발생했습니다. FireSim은 EC2 F1과 오픈 소스 하드웨어를 이용하여 FPGA 가속 시뮬레이션의 기존 문제를 해결합니다.
문제 #1: 기존 방식의 FPGA 기반 시뮬레이션은 비용이 많이 들고 배포하기 어려우며 재현하기 어려웠습니다.
FireSim은 F1과 같은 퍼블릭 클라우드 인프라를 사용하므로 선수금 없이 FPGA를 구입하여 배포할 수 있습니다. 개발자와 연구자는 이 공개 데모(추가 세부 정보는 이 게시물 뒷부분 참조)와 마찬가지로 사전 빌드된 AMI와 AFI를 배포하여 재현하기 쉬운 실험을 수행할 수 있습니다. 또한 FireSim은 FPGA 시뮬레이션 배포에 관련된 대부분의 작업을 자동화하므로 새로운 RTL에서 원클릭 변환을 통해 FPGA 클러스터에 배포할 수 있습니다.

문제 #2: 기존 방식의 FPGA 기반 시뮬레이션은 확장하기 어렵고 비용이 많이 들었습니다.
FireSim은 F1을 사용하기 때문에 사용자는 대규모 FPGA 클러스터에 수십만 달러를 소비하지 않고 추가 EC2 인스턴스를 스핀업하여 실험을 확장할 수 있습니다.

문제 #3: 기존 방식에서는 오픈 하드웨어를 찾기가 어려웠습니다. 실제 소프트웨어 스택을 실행할 수 있는 오픈 하드웨어를 찾는 것은 훨씬 더 어렵습니다.
FireSim은 업계에서 증명된 오픈 RISC-V 기반 프로세서 플랫폼인 RocketChip을 시뮬레이션하며 NIC 및 디스크 장치와 같은 주변장치를 추가하여 실제 시스템을 확장합니다. RISC-V를 구현하는 프로세서는 실제 운영 체제(예: Linux)를 자동으로 지원하며 Apache 및 Memcached와 같은 애플리케이션까지도 지원합니다. AWS는 시뮬레이션된 노드에서 실행되고 많은 인기 개발자 도구가 포함된 사용자 지정 Buildroot 기반 FireSim Linux 배포를 제공합니다.

문제 #4: 기존 HDL에서 하드웨어를 작성하려면 시간이 많이 소모됩니다.
FireSim과 RocketChip 둘 다 하드웨어 설명 언어에 현대적인 프로그래밍 패러다임을 더한 Chisel HDL을 사용합니다. Chisel은 파라미터 수가 많은 대형 하드웨어 구성 요소의 빌드 프로세스를 간소화합니다.

하드웨어/소프트웨어 공동 설계에 FireSim을 사용하는 방법

하드웨어 개발자와 소프트웨어 개발자 간의 공동 작업을 위한 푸시 버튼 인터페이스의 역할을 담당하는 FireSim은 하드웨어와 소프트웨어의 공동 설계 프로세스를 대폭 개선해 줍니다. 다음 다이어그램은 하드웨어 개발자와 소프트웨어 개발자가 FireSim으로 작업할 때의 워크플로우를 보여 줍니다.

그림 2. FireSim 사용자 지정 하드웨어 개발 워크플로우.

하드웨어 개발자의 관점:

  1. Chisel과 같은 생산적인 언어로 액셀러레이터, 주변장치 또는 프로세서 수정을 위한 사용자 지정 RTL을 작성합니다.
  2. 초기 단계 디버깅을 위해 표준 게이트 수준 시뮬레이션 도구에서 하드웨어 설계의 소프트웨어 시뮬레이션을 실행합니다.
  3. FireSim 빌드 스크립트를 실행하여 자동으로 시뮬레이션을 빌드하고 Vivado 도구 체인/AWS 셸 스크립트를 통해 시뮬레이션을 실행하며 AFI를 게시합니다.
  4. 생성된 시뮬레이션 드라이버와 AFI를 사용하여 EC2 F1에 시뮬레이션을 배포합니다.
  5. 소프트웨어 개발자가 릴리스하는 실제 소프트웨어 빌드를 실행하여 하드웨어를 벤치마크합니다.

소프트웨어 개발자의 관점:

  1. 하드웨어 개발자가 생성한 AMI/AFI를 F1 인스턴스에 배포하여 노드 클러스터를 시뮬레이션합니다(또는 더 큰 시뮬레이션된 코어 수를 위해 여러 F1 노드로 확장).
  2. SSH를 사용하여 클러스터에 있는 시뮬레이션된 노드에 연결하고 FireSim과 함께 포함된 Linux 배포를 부팅합니다. 이 배포는 쉽게 사용자 지정할 수 있으며 많은 표준 소프트웨어 패키지를 이미 지원합니다.
  3. 확장 시에도 소프트웨어에서 관찰되는 것과 동일한 성능 특성과 함께, 프로토타입을 작성하고 있는 미래의 실제 시스템에 배포될 때 소프트웨어에 나타나는 것과 정확히 동일한 인터페이스를 사용하여 소프트웨어의 프로토타입을 직접 작성합니다.

FireSim 데모 v1.0

그림 3. FireSim 데모 v1.0에서 시뮬레이션된 클러스터 토폴로지.

FireSim의 이 첫 번째 공개 데모는 앞에서 언급한 사용자 지정 하드웨어 개발 주기의 “소프트웨어 개발자 관점”에 중점을 둡니다. 이 데모는 작동하는 네트워크 시뮬레이션을 통해 상호 연결된 1에서 8개 RocketChip 기반 노드의 클러스터를 시뮬레이션합니다. 시뮬레이션된 노드는 “실제” 머신과 똑같이 작동합니다. 이 노드는 Linux를 부팅하고, SSH를 사용하여 노드에 연결할 수 있으며, 최상위에서 실제 애플리케이션을 실행할 수 있습니다. 노드는 네트워크에서 서로(및 노드가 배포되는 EC2 F1 인스턴스)를 보고 서로 통신할 수 있습니다. 데모는 현재 사전 빌드된 “vanilla” 클러스터를 시뮬레이션하지만, FireSim이 오픈 소스로 제공된 후에는 이 시뮬레이션된 노드의 전체 하드웨어 구성을 수정할 수 있습니다.

이 게시물에서는 숙련된 EC2 F1 사용자를 위한 단일 노드 FireSim 시뮬레이션 작성을 살펴봅니다. 초보 사용자를 위한 추가 세부 지침과 대규모 8노드 시뮬레이션 실행에 대한 지침은 Amazon EC2 F1에서 FireSim 데모 v1.0을 참조하십시오. 두 가지 데모는 데모 AMI/AFI에서 인스턴스를 설정하고 시뮬레이션된 노드에서 Linux를 부팅하는 과정을 보여 줍니다. 전체 데모 지침에서도 시뮬레이션된 노드에서 Memcached를 실행하고 YCSB를 Load Generator로 사용하여 네트워크 기능을 보여 주는 워크로드 예를 살펴봅니다.

F1에 데모 배포

이 릴리스에서는 호스트에서 시뮬레이션을 구동하기 위한 사전 빌드된 바이너리와 RocketChip 기반 노드를 시뮬레이션하는 데 필요한 FPGA 인프라가 포함된 사전 빌드된 AFI를 제공합니다.

F1 인스턴스 시작

먼저, f1.2xlarge 인스턴스에서 AWS Marketplace에서 사용 가능한 무료 FireSim Demo v1.0 제품을 사용하여 인스턴스를 시작합니다. 인스턴스가 부팅된 후 사용자 이름 centos를 사용하여 로그인합니다. 처음 로그인하면 “FireSim network config completed” 메시지가 나타납니다 이 단계에서 EC2 인스턴스의 필수 탭 인스턴스와 브리지를 설정하여 시뮬레이션된 노드와 통신을 활성화합니다.

AMI 콘텐츠

AMI에는 시뮬레이션을 실행하고 RISC-V 시스템용 소프트웨어를 빌드하는 데 도움이 되는 다양한 도구가 포함되어 있습니다. 예를 들면 riscv64 도구 체인, 시뮬레이션된 노드에서 실행되는 Buildroot 기반 Linux 배포, 시뮬레이션 드라이버 프로그램 등이 있습니다. 자세한 내용은 FireSim 웹 사이트의 AMI 콘텐츠 섹션을 참조하십시오.

단일 노드 데모

먼저 FireSim AFI로 FPGA를 플래시해야 합니다. 이렇게 하려면 다음을 실행합니다.

[centos@ip-IP_ADDR ~]$ sudo fpga-load-local-image -S 0 -I agfi-00a74c2d615134b21

시뮬레이션을 시작하려면 명령줄에서 다음을 실행합니다.

[centos@ip-IP_ADDR ~]$ boot-firesim-singlenode

이 명령은 시뮬레이션 드라이버를 자동으로 호출하여 Linux distro용 Linux 커널 이미지 및 루트 파일 시스템을 로드하도록 지시합니다. 그러면 다음과 비슷한 출력이 생성됩니다.

Simulations Started. You can use the UART console of each simulated node by attaching to the following screens:

There is a screen on:

2492.fsim0      (Detached)

1 Socket in /var/run/screen/S-centos.

이 화면에 연결하여 시뮬레이션된 UART 콘솔에 연결할 수 있지만, 그 대신 SSH를 사용하여 노드에 액세스하는 방법을 선택합니다.

먼저 노드를 ping하여 온라인으로 전환되었는지 확인합니다. NIC가 네트워크 트래픽을 수신하지 않으면 Linux 부팅 시 노드가 정체될 수 있기 때문에 현재는 이 단계가 필요합니다. 자세한 내용은 문제 해결/정오표를 참조하십시오. 노드에는 항상 IP 주소 192.168.1.10이 할당됩니다.

[centos@ip-IP_ADDR ~]$ ping 192.168.1.10

그러면 결국 다음과 같은 출력이 생성됩니다.

PING 192.168.1.10 (192.168.1.10) 56(84) bytes of data.

From 192.168.1.1 icmp_seq=1 Destination Host Unreachable

64 bytes from 192.168.1.10: icmp_seq=1 ttl=64 time=2017 ms

64 bytes from 192.168.1.10: icmp_seq=2 ttl=64 time=1018 ms

64 bytes from 192.168.1.10: icmp_seq=3 ttl=64 time=19.0 ms

이 시점에서 시뮬레이션된 노드가 온라인임을 알 수 있습니다. 사용자 이름 루트 및 암호 firesim과 함께 SSH를 사용하여 연결할 수 있습니다. TERM 변수가 올바르게 설정되었는지 확인하는 것도 편리합니다. 이 경우 시뮬레이션에서 TERM=linux가 예상되므로 다음을 입력합니다.

[centos@ip-IP_ADDR ~]$ TERM=linux ssh root@192.168.1.10

The authenticity of host ‘192.168.1.10 (192.168.1.10)’ can’t be established.

ECDSA key fingerprint is 63:e9:66:d0:5c:06:2c:1d:5c:95:33:c8:36:92:30:49.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added ‘192.168.1.10’ (ECDSA) to the list of known hosts.

root@192.168.1.10’s password:

#

이 시점에서 시뮬레이션된 노드에 연결됩니다. uname -a를 예로 실행합니다. 그러면 RISC-V 시스템에 연결되었음을 나타내는 다음과 같은 출력이 표시됩니다.

# uname -a

Linux buildroot 4.12.0-rc2 #1 Fri Aug 4 03:44:55 UTC 2017 riscv64 GNU/Linux

이제 실제 머신과 같은 방식으로 시뮬레이션된 노드에서 프로그램을 실행할 수 있습니다. 워크로드 예(running YCSB against Memcached on the simulated node)를 보거나 대규모 8노드 시뮬레이션을 실행하려면 전체 Amazon EC2 F1에서 FireSim Demo v1.0 데모 지침을 참조하십시오.

마지막으로, 모두 완료되면 시뮬레이션된 노드 내에서 다음 명령을 실행하여 시뮬레이션된 노드를 종료할 수 있습니다,

# poweroff

screen -ls를 실행하여 시뮬레이션이 종료되었는지 확인할 수 있습니다. 지금 이 명령을 실행하면 분리된 화면이 없다고 보고됩니다.

향후 계획

Berkeley에서는 FireSim 플랫폼을 계속 개선하여 FireBox와 같은 미래의 데이터 센터 아키텍처에 대한 독자적인 연구를 활성화할 계획입니다. FireSim 플랫폼은 더 많은 수의 FPGA로 확장하는 것 외에도 더욱 정교한 프로세서, 사용자 지정 액셀러레이터(예: Hwacha), 네트워크 모델, 주변 장치를 지원할 것입니다. 향후에는 사용자가 하드웨어/소프트웨어 스택의 모든 부분을 수정할 수 있도록 RTL을 FPGA 시뮬레이터로 변환하는 데 사용되는 도구인 Midas를 포함하여 전체 플랫폼을 오픈 소스로 제공할 예정입니다. Twitter에서 @firesimproject를 팔로우하여 FireSim 업데이트를 계속 주목해 주십시오.

감사의 말씀

FireSim은 Sagar Karandikar, Donggyu Kim, Howard Mao, David Biancolin, Jack Koenig, Jonathan Bachrach, Krste Asanović와 같은 Berkeley의 많은 학생과 교직원의 공동 작업입니다. 이 작업은 AWS(RISE Lab을 통해), Intel Science and Technology Center for Agile HW Design, ASPIRE Lab 후원사에서 일부 연구 기금 지원을 받으며 Intel, Google, HPE, Huawei, NVIDIA, SK hynix와 연계하여 진행됩니다.

―Mia Champion, 수석 데이터 과학자, AWS

이 글은  AWS Compute 블로그의 Bringing Datacenter-Scale Hardware-Software Co-design to the Cloud with FireSim and Amazon EC2 F1 Instances의 한국어 번역입니다.