Amazon Web Services 한국 블로그

Amazon EC2 P3 인스턴스를 위한 신규 Deep Learning AMI 출시

어제 출시된 Amazon EC2 P3 인스턴스에 탑재한 NVIDIA Volta V100 GPU를 위해 최적화된 딥러닝 프레임워크를 사전에 설치한 새로운 AWS Deep Learning AMI 세트를 발표하였습니다.

새로운 P3 인스턴스는 단일 p3.16xlarge 인스턴스에서 8개의 NVIDIA Volta GPU를 통해 초당 125조 개의 단 정밀도 부동 소수점 연산이 가능하므로 딥러닝에 탁월합니다. 따라서 정교한 딥러닝 모델의 학습 시간이 수 일에서 수 시간으로 크게 단축됩니다.

딥러닝 AMI: Volta용 CUDA 9 출시
새로운 AMI는 Ubuntu와 Amazon Linux 모두를 위한 CUDA 9, cuDNN 7.0, NCCL 2.0.5 및 NVIDIA Driver 384.81 등의 P3 Volta의 성능을 활용하는 다른 GPU 드라이버와 함께 사전 설치, 구성됩니다.

최신 드라이버 외에도, 이 AMI에는 P3와 Volta를 위해 최적화된 주요 프레임워크가 포함되어 있습니다. 갓 출시된 Volta를 위한 첫 번째 릴리스인 이 CUDA 9 AMI에는 가장 최신 버전의 소스로부터 빌드된 프레임워크가 포함되어 있습니다. Volta는 아직 초기 단계이므로 이 프레임워크들은 시간이 흐름에 따라 안정성과 성능이 개선될 것으로 기대되며, 이 최신 버전의 프레임워크들은 학습 시간의 관점에서 상당한 성능 향상을 제공할 것입니다. 즉, 이 빌드들은 가장 최신이므로 프로덕션으로 올리기 전에 테스트해보시기 바랍니다. P3에서 실험하면서 오픈 소스 프로젝트에 피드백을 주시면 개선에 도움이 될 것입니다.

  • Apache MXNet v0.12 RC1: CNN 학습은 float16을 사용할 때 Pascal GPU보다 3.5배 빠릅니다. MXNet 버전 0.12의 전체 릴리스 노트는 여기에서 볼 수 있습니다.
  • Caffe2 v0.8.1: Caffe2의 FP16 지원으로 인해 개발자는 NVIDIA Tesla V100 GPU를 사용해 딥러닝 작업의 성능을 극대화 할 수 있습니다.
  • TensorFlow (마스터): 2017년 10월 24일 오전 11시(커밋 : 5bef42)의 마스터에서 빌드한 TensorFlow 버전과 Volta 지원을 위한 NVIDIA의 8 패치를 제공합니다. 초기 테스트에서 이 빌드는 p2.16xlarge의 최신 공식 릴리스 (TensorFlow 1.3)와 비교하여 p3.16xlarge에서 3배의 성능을 보입니다.
  • Gluon: 이전 버전의 AMI와 마찬가지로, 학습 속도를 떨어뜨리지 않고도 쉽고 빠르게 머신러닝 모델을 작성할 수 있게 해주는 새로운 오픈 소스 딥러닝 인터페이스인 Gluon이 포함됩니다. Gluon 출시 소개에서 더 많은 정보를 얻고, 50개 노트북의 샘플 코드를 시작해보세요.

작업에 적합한 AMI 선택하기
AWS Deep Learning AMI를 시작하는 것은 간단합니다. AWS 마켓 플레이스에서 한 번의 클릭으로 시작하거나 이 단계별 안내서를 따라 첫 번째 노트북을 시작할 수 있습니다.

CUDA 9 AMI는 다음 버전에서 사용할 수 있습니다.

그 밖의 다른 프레임워크도 Volta를 위해 준비되면 추가할 것입니다. 아직 유지되고 있는 CUDA 8 AMI도 사용 가능하며, TensorFlow, MXNet, Caffe, Caffe 2, Microsoft Cognitive Toolkit (CNTK) 및 Keras의 최신 안정화된 공식 “포인트” 릴리스를 포함하고 있습니다. CUDA 8 AMI는 다음 버전에서 사용할 수 있습니다.

딥러닝에 대해 더 알고 싶다면 2017년 11월 27일부터 12월 1일까지 열릴 re:Invent 머신러닝 안내서를 참조하십시오. 딥러닝의 미래를 전망하는 첫 Deep Learning Summit에 참석하시고 50여 개의 머신러닝 세션, 워크샵, 실습에도 이번 re:Invent 컨퍼런스에서 참여해보세요.

이글은 Amazon AI 블로그의 Announcing New AWS Deep Learning AMI for Amazon EC2 P3 Instances의 한국어 번역으로 AWS코리아의 강지양 솔루션즈아키텍트가 번역해 주셨습니다.

Stephen Orban – 오늘날 비즈니스와 기술의 병합에서 CIO의 역할

“항상 목적을 염두에 두고 시작하라.”- Stephen R. Covey

 

지난 게시물에서 저는 오늘날 기술 경영자들은 기업의 엔터프라이즈 클라우드 여정을 주도하는 최고 변화 관리 책임자(CCMO™)의 역할을 수행해야 한다고 단언하였습니다. 이번 게시물에서는 이러한 역할과 관련된 세 가지 주제 중 첫 번째인 비즈니스와 기술의 병합(수평적 관리)을 살펴보겠습니다. 나머지 2개 주제인 명확한 목적 제시(수직적 관리)와 새로운 규칙 만들기(실제로는 규칙 깨기) (관리 이행)는 다음 게시물에서 다룹니다.

오늘날 성공적인 기술 경영자들은 기술이 비즈니스에 어떻게 적합한지,더욱 정확하게는 비즈니스에 어떻게 동력을 공급하는지 상대 임원들이 이해할 수 있도록 설명해야 합니다. 이렇게 이해를 도울 수만 있다면 자신이 기업의 비즈니스 목표를 완전히 꿰뚫고 있으며, 임원진에 중요한 구성원이라는 사실을 동료 임원들에게 각인시킬 수 있습니다.

기술이 비즈니스에 어떻게 적합한지를 잘 알고 있을 뿐만 아니라 전 산업에 걸쳐 기술의 역할을 정의하고 있는 임원과 기업가들이 회사를 설립하고 운영하면서 오늘날의 비즈니스 환경은 파괴되고 있습니다. 호텔 산업의 AirBnb, 자동차 서비스 산업의 Uber, 가정 자동화 산업의 Nest Labs, 그리고 스토리지 산업의 Dropbox는 일부 예에 불과합니다. 경쟁력을 유지해야 하는 기존 기업에게는 이러한 변화가 압박으로 다가오지만 전 세계 IT 임원들에게는 기회나 다름 없습니다. 기술을 통해 점차 증가하는 시장 수요를 충족할 방법을 이해하기 쉽게 설명하라고 하면, 그누구도 자신의 경력을 기술 관련 업무로 가득 채우고 있는 전문가보다 유리하지 못합니다. 특히 대부분의 경력을 대기업에서 보낸 우리 같은 사람이라면 더욱 그렇습니다. 우리는 엔터프라이즈와 말이 통할 뿐만 아니라 어떤 제약 조건이 쉽고 어려운 지, 그리고 임원 동료에 따라 어떤 레버를 당겨야 할지 잘 알고 있습니다. 이제는 기술 경영자들이 앞으로 나서지 않는 한 기업의 성공을 바라기는어렵습니다.

또한, 클라우드가 기존의 엔터프라이즈 IT에서 무차별적으로 발생하던 과부하 작업 대부분을 제거하고 있기 때문에 오늘날 IT 임원들은 비즈니스를 촉진하여 기업의 경쟁력을 유지하는 활동에 더 많은 시간과 자원을 투자할 수 있습니다. 클라우드는 이처럼 새로운 파괴적인 원동력을 주도하는 핵심 요소입니다. 클라우드가 비즈니스 성장을 위한 아이디어를 반드시 제공하는 것은 아니지만 추가적인 가능성의 문을 활짝 열고 경쟁의 장을 공정하게 할 것입니다.

기업의 클라우드 여정을 이끌 수 있는 몇 가지 아이디어를 아래에 소개합니다.

동료와 공감대를 형성하라

클라우드는 단순히 기술 변화만을 의미하지 않습니다. 임원진 모두 관심을 가져야 하는 비즈니스의 변화를 의미하기도 합니다. 당신은 임원진을 배려하는 동시에 클라우드 여정이 각 직무에 미치거나, 혹은 미칠 수 있는 영향에 대해서 살펴야 합니다.

한 게시물에서 다루기에는 너무나 많은 유형의 임원들이 있지만, 일부 유형의 임원들을 살펴보자면 다음과 같습니다.

CFO는 일반적으로 선불 비용을 낮추거나 사용한 부분에 대해서만 비용을 지불하는 데 매력을 느낍니다. 매월 달라지는 비용 변동성 때문에 갈등이 발생하는 경우를 보기도 하지만, 특히 용량 계획 및 유지관리 활동에 따른 업무 부담에서 해방될 때 총소유비용이 낮아지는 경우를 거의 언제나 보게 됩니다. 비즈니스 환경에 대한 이해의 폭이 넓어질수록 매월 담당 관리자와 긴밀하게 협력하여 지출을 예측하거나, 자원 사용량을 통합 관리하거나, 간격을 두고 예약 인스턴스(RI)를 구매하십시오. 또한, 제품 및 자산 개발에 집중되는 자원이늘어날 수록 인건비의 활용 방법에 대해서도 고민할 필요가 있습니다.

CMO는 일반적으로 기업 브랜드를 새롭게 유지하고 변화하는 시장 환경에 따라 대응하는 역할을 합니다. 만약 브랜드 웹사이트를 월 1회가 아니라 하루에도 여러 차례 업데이트 할 수 있다면 어떻게 될까요? 데이터 웨어하우스를 무한 확장할 수 있다면 CMO가 고객을 더욱 정확하게 이해하는 데 어떤 도움이 될까요? 비용이 거의 혹은 전혀 들지 않는다고 할 때 소수의 사용자와 어떤 시도를 해보고 싶을까요?

HR 부서의 임원은 올바른 직원 관리와 신규직 채용 방법을 궁금해 할 것입니다. AWS 교육 및 자격증 프로그램을 이용하고, AWS의 교육 전문성을 기업의 자체 교육 과정에 원하는 대로 추가할 수 있습니다. 다음 게시물에서는 이번 주제에 이어서 직원 교육 방법에 대해서 살펴보겠습니다. 스포일러가 될 수도 있지만, 팀원 누구나 배울 자세만 되어 있다면 기업의 클라우드 여정에 기여할 수 있습니다. 또한, 클라우드 여정에 참여한 다른 기업들과 네트워크를 형성하여 신규직 채용이나 기존 직원의 직무 변경 방법을 알아보십시오. 가령, DevOps가 기업에 적합한지, 혹은 자산 개발 및 운영이 기업에 어떤 의미인지 알아보는 것도 좋습니다.

CEO는 위에서 언급한 모든 것을 비롯해 기업의 경쟁력을 유지하는 방법에 관심을 둡니다. 나머지 임원에게서 배운 내용을 바탕으로 최신 기술을 이용하여 전체적인 비전을 설계하고 그 방법을 제시할 수 있다면 동일한 제약 조건에서 할 수 없을 것만 같던 일들이 가능해 보일 것입니다.

저는 Dow Jones 재직 시 매월 몇몇 임원들과 식사한다는 목표를 세웠습니다. 함께 식사하는 동안 임원들의 불만에 귀를 기울이는 것 외에는 아무 것도 하지 않았습니다. 이렇게 알게 된 불만을 전략을 조정하는 데 사용하였으며, 이후 임원들의 불만에 따라 회사의 방향이 어떻게 수정되었는지 반드시 다시 얘기를 나눴습니다. 임원들의 요구 사항에 공감하고, 신뢰를 쌓으며, 지지를 얻을 수 있는 간단한 방법이지만(사람과 음식을 좋아한다면 즐길 수도 있는) 여기에서 중요한 핵심은 단순히 듣기만 하는 것이 아니라 학습한 내용을 기초로 행동해야 한다는 것입니다.

도움을 요청하라

이 모든 일을 혼자서 할 필요는 없습니다. 어카운트 매니저를 여정의 길잡이로 생각해도 좋습니다. 어카운트 매니저는 임원진과 협력하여 비즈니스 목적과 일치하는 클라우드 마이그레이션의 메시지와 이점을 구체화 할 수 있도록 기꺼이 지원할 것입니다. 어카운트 매니저의 전문적 범위를 벗어나면 이들이 AWS 내부 또는 외부에서 적임자를 찾아줄 것입니다. 우리는 AWS 이벤트는 물론이고 그 밖에 다른 여정의 교차점에서 같은 생각을 하는 동료들을 만나 네트워크를 형성할 수 있는 기회를 창출하려고 합니다. 저는 지난번 재임 시 다른 회사들에로부터 몇 차례 레퍼런스 콜을 받았고 다른 임원들의 말에 귀를 기울이는 것은 배울 수 있는 기회인 동시에 유효성을 검증하는 방법이기도 합니다.

AWS 파트너 네트워크와 AWS 교육 및 자격증 프로그램 역시 클라우드 여정의 속도를 높일 수 있는 최고의 리소스입니다. 이 두 가지는 모범 사례를 다룰 때 자세하게 설명하겠지만 자체 프로그램 외에도 HR 부서와 파트너십을 맺고 AWS 교육을 제도화하고 있는 회사들이 많습니다. 제가 Dow Jones에 있었을 때 DevOps 팀이 HR 부서와 파트너십을 맺고 DevOps Day를 개최하여 점차 진화하는 도구와 모범 사례를 정기적으로 전파하는 데 힘을 썼습니다. 이는 지리적으로 넓게 분산된 팀의 역량을 높일 수 있는 좋은 방법입니다. 앞에서도 얘기했지만, 어카운트 매니저가 이 두 가지 부문과 바로 연계할 수 있도록 지원할 것입니다.

IT 브랜드를 발전시켜라

저는 IT 부서의 브랜드를 개선하려는 다수의 IT 임원들과 대화를 나누는 일이 많습니다. Bloomberg에서는 비즈니스 소프트웨어를 개발하면서 10년 이상을 보냈습니다. 이후 IT는 비용 센터라고 생각하던 Dow Jones가 IT는 사실 비즈니스를 움직이며 동력을 불어넣는 분야라고 생각 할 수 있도록 돕고자 하는 마음에 Dow Jones로 옮겼습니다. 근면과 성실을 보여준 부서의 직원들에게 빚을 진 느낌이었고, 우리가 만들어가는 변화의 바람에 전 직원들이 합류할 수 있게 된 것도 이들의 도움이 매우 컸습니다.

AWS가 이러한 변화의 한 축을 담당했지만, 임원 개개인의 고충과 임원들이 IT에게서 기대하는 바에 대한 이해, 그리고 임원들의 목적을 달성할 수 있는 기술 적용 등은 임원진과 함께 일하면서 겪게 되는 어려움 중 대부분을 차지했습니다. 몇 개월 동안 클라우드를 사용하여 더욱 빠르게 성과를 높이고 난 후에는 임원진을 비롯한 각 부서가 우리를 IT가 아닌 기술로 여길 수 있도록 재교육하는 데 수개월을 보냈습니다. 그 결과, 미묘하기는 했지만 대화의 어조와 생산성에서 유의미한 차이가 보이기 시작했고, 이는 변화의 바람이 회사 전체로 퍼져간다는 것을 암시했습니다.

이 글과 비교하여 여러분의 경험은 어떤가요? 여러분의 이야기를 듣고 싶습니다.

 

– Stephen
@stephenorban
http://aws.amazon.com/enterprise/

본 블로그 글은 Stephen Orban의 엔터프라이즈 클라우드 여정 시리즈 입니다. 더 자세한 것은 전체 목록을 참고하시기 바랍니다.

NVIDIA Tesla V100 GPU 지원 Amazon EC2 P3 인스턴스 타입 정식 출시

AWS는 고객 요청에따라 기술 변화에 맞는 EC2 인스턴스 타입을 지속적으로 추가해 왔습니다. 2006년 m1.small을 시작으로, 컴퓨팅 최적화, 메모리 최적화 혹은 스토리지 및 I/O 등에 최적화된 인스턴스 타입 등 많은 고객 선택 옵션을 제공하고 있습니다.

새로운 P3 인스턴스 타입 출시
오늘 AWS의 4개의 리전에 차세대 GPU 기반 EC2 인스턴스를 출시합니다. 최대 8개의 NVIDIA Tesla V100 GPU로 구동되는 P3 인스턴스는 고성능 컴퓨팅 작업을 요하는 기계 학습, 딥러닝, 전산 유체 역학, 전산 금융, 지진 분석, 분자 모델링 및 유전체 분석 작업 등의 부하를 처리할 수 있게 설계되었습니다.

P3 인스턴스는 최대 2.7GHz로 실행되는 맞춤형 Intel Xeon E5-2686v4 프로세서를 사용합니다. 세 가지 크기 (모든 VPC 전용 및 EBS 전용)로 사용할 수 있습니다.

모델 NVIDIA Tesla V100 GPUs GPU 메모리
NVIDIA NVLink vCPUs 주메모리 네트워크대역폭 EBS 대역폭
p3.2xlarge 1 16 GiB n/a 8 61 GiB Up to 10 Gbps 1.5 Gbps
p3.8xlarge 4 64 GiB 200 GBps 32 244 GiB 10 Gbps 7 Gbps
p3.16xlarge 8 128 GiB 300 GBps 64 488 GiB 25 Gbps 14 Gbps

각 NVIDIA GPU는 5,120개의 CUDA 코어와 640개의 Tensor 코어로 구성되어 있으며 최대 125 TFLOPS의 혼합 부동 소수 정밀도, 15.7 TFLOPS의 단일 부동 소수점 정밀도 및 7.8 TFLOPS의 복수 부동 소수점 정밀도를 지원합니다. 8xlarge 및 16xlarge 사이즈에는 각 GPU가 최대 300GBps의 데이터 속도로 실행되는 NVIDIA NVLink 2.0을 통해 서로 연결됩니다. 이를 통해 GPU는 중간 결과 및 기타 데이터를 CPU 또는 PCI-Express 패브릭을 통해 이동하지 않고 고속으로 교환할 수 있습니다.

텐서코어(Tensor Core) 소개

NVIDIA 블로그에 따르면, Tensor 코어는 딥러닝 신경망 학습 및 추론을 가속화하도록 설계되었습니다. 각 코어는 한 쌍의 4×4 반 정밀도 (FP16이라고도 함) 행렬을 빠르고 효율적으로 연산해서 얻은 4×4 행렬을 다른 반 또는 단일 정밀도 (FP32) 행렬에 더한 다음, 절반 또는 단일 정밀도 형식의 4×4 행렬 NVIDIA 블로그 게시물의 다이어그램은 다음과 같습니다.

이 작업은 딥러닝 네트워크를 위한 학습 과정에서 가장 먼저 실행하는 것으로, 오늘날의 NVIDIA GPU 하드웨어가 매우 구체적인 시장 요구를 해결하기 위해 특별한 방법으로 구축되었는지 보여주는 훌륭한 예입니다. 텐서 코어 성능의 혼합 정밀도 한정자(mixed-precision qualifier)는 16비트 및 32비트 부동 소수점 값의 조합으로 작업하기에 충분히 유연하다는 것을 의미합니다.

정식 출시
NVIDIA Tesla V100 GPU 및 Tensor 코어를 최대한 활용하려면 CUDA 9cuDNN7을 사용해야합니다. 이 드라이버와 라이브러리는 이미 최신 버전의 Windows AMI에 추가되었으며, 11 월 7 일에 출시예정인 업데이트 된 Amazon Linux AMI에 포함될 예정입니다. 새로운 패키지는 기존 Amazon Linux AMI에 설치하려는 경우 이미 레포지터리에서 사용할 수 있습니다.

최신 AWS Deep Learning AMI에는 Apache MXNet, Caffe2 및 Tensorflow (각각 NVIDIA Tesla V100 GPU 지원)의 최신 버전이 사전 설치되어 있으며 Microsoft Cognitive Toolkit과 같은 다른 기계 학습 프레임 워크로 P3 인스턴스를 지원하도록 업데이트됩니다. 이 프레임 워크가 NVIDIA Tesla V100 GPU에 대한 지원을 출시하면, PyTorch를 사용할 수 있습니다. 또한 NGC 용 NVIDIA Volta Deep Learning AMI를 사용할 수도 있습니다.

P3 인스턴스는 On-Demand, Spot, Reserved Instance 및 Dedicated Host 양식의 미국 동부 (버지니아 북부), 미국 서부 (오레곤), EU (아일랜드) 및 아시아 태평양 지역 (도쿄) 지역에서 사용할 수 있습니다. 더 자세한 사항은 P3 인스턴스 소개 페이지를 참고하세요!

Jeff;

이 글은 New – Amazon EC2 Instances with Up to 8 NVIDIA Tesla V100 GPUs (P3)의 한국어 편집본입니다. Amazon 인공 지능에 대한 좀 더 자세한 사항은 아래 한국어 발표 자료 및 동영상을 참고하시기 바랍니다.

자세히 알아보기

Apache Flink를 이용한 AWS기반 실시간 스트림 처리 파이프라인 구성하기

오늘날 비즈니스 환경에서, 다양한 데이터 소스의 꾸준한 증가에 맞추어 데이터는 계속적으로 생성되고 있습니다. 따라서, 원시 데이터의 대규모 스트림을 통해 실행 가능한 통찰력을 얻기 위한 데이터를 지속적으로 수집하고, 저장하고, 처리하는 능력을 갖춘다는 것은 조직의 경쟁력 측면에서 장점이라 하겠습니다.

Apache Flink스트림 프로세싱 파이프라인의 기반을 갖추는 데 매우 적합한 오픈소스 프로젝트 입니다. 스트리밍 데이터의 지속적인 분석에 적합한 고유한 기능을 제공합니다. 하지만, Flink를 기반으로 파이프라인 을 구축하고 유지하려면 때때로 물리적 자원 및 운영상의 노력 외에 상당한 전문 지식이 필요합니다.

이 글을 통해서 Amazon EMR, Amazon KinesisAmazon Elasticsearch Service (ES)를 사용하는 Apache Flink를 기반으로 일관성 있고 확장 가능하며 안정적인 스트림 프로세싱 파이프라인에 대한 레퍼런스 아키텍처를 설명해드리고자 합니다. AWSLabs GitHub 저장소는 레퍼런스 아키텍처를 실제로 탐색하는데 필요한 아티팩트(artifact)를 제공합니다. 리소스에는 샘플 데이터를 Amazon Kinesis Stream으로 수집하는 프로듀서(producer) 애플리케이션과 실시간으로 데이터를 분석하고 그 결과를 시각화하기 위해 Amazon ES로 보내는 Flink 프로그램이 포함되어 있습니다.

실시간으로 택시 데이터 지리적 위치 분석하기
택시의 차량 운영 최적화와 관련하여 다음과 같은 시나리오를 생각해보겠습니다. 뉴욕시에서 현재 운영중인 수많은 택시들로부터 운행 정보를 지속적으로 확보합니다. 그리고 이 데이터를 사용하여 수집된 데이터를 실시간으로 분석하고 데이터에 기반한 의사 결정을 내림으로써 운영을 최적화하고자 합니다.

예를 들어, 현재 택시 수요가 많은 지역을 의미하는 핫스팟(Hot spot)을 식별해서 빈 택시들이 이 곳으로 이동하도록 할 수 있습니다. 또, 현재 교통 상황을 파악해서 가까운 공항으로 가기 위한 대략적인 운행 시간을 고객에게 알려드릴 수도 있습니다. 당연히, 이러한 결정은 현재의 수요와 교통 상황을 상세하게 반영하고 있는 정보를 기반으로 합니다. 유입되는 데이터는 지속적이면서도 시간에 맞춰 적절하게 분석되어야 합니다. 이와 관련한 KPI와 이를 통해 도출되는 인사이트는 실시간으로 대시보드에서 액세스할 수 있어야 합니다.

이 글의 목적에 맞게, 뉴욕시에서 수집된 택시 운행 이력 데이터셋을 Amazon Kinesis Streams로 재생해서 운행 이벤트를 만들어보겠습니다. 이 데이터셋은 New York City Taxi & Limousine Commission 웹사이트에서 얻을 수 있으며, 지리적 위치 정보와 택시 운행 관련 요금 정보 등이 포함되어 있습니다.

보다 현실적인 시나리오에서는, AWS IoT를 사용하여 택시에 설치된 원격 측정 유닛에서 데이터를 수집한 다음 이 데이터를 Amazon Kinesis Streams로 처리할 수도 있습니다.

높은 신뢰성과  확장 가능한 스트림 프로세싱 파이프라인 아키텍처
파이프라인이 택시를 운영하고 최적화하기 위한 중앙 집중형 툴을 제공하므로, 단일 노드의 장애에 대한 내성을 갖는 아키텍처를 구축하는 것은 매우 중요합니다. 파이프라인은 유입되는 이벤트의 변화율에 맞춰 적응할 것입니다. 따라서, 이벤트 수집, 실질적인 처리, 확보한 인사이트의 시각화를 다른 구성 요소들로 분리합니다. 인프라의 구성요소들 간의 결합도를 낮추고, 관리형 서비스를 사용해서 장애에 대해 파이프라인의 견고성(robustness)을 증가시킬 수 있습니다. 또, 인프라의 여러 부분을 확장시킬 수 있고 전체 파이프라인을 구축하고 운영하는데 필요한 노력을 줄일 수 있습니다.

기대하는 데이터 통찰력을 얻기 위한 쿼리 계산으로부터 택시를 통해 전송된 이벤트의 수집과 저장을 분리하여, 인프라의 견고성을 상당히 증가시킬 수 있습니다.

이벤트는 처음에는 Amazon Kinesis Streams를 통해 유지됩니다. Amazon Kinesis Streams는 재생 가능하고 순서가 있는 로그(log)를 보유하며 여러 가용 영역(Availability Zone)에 이벤트를 중복 저장합니다. 이후에, 스트림에서 이벤트를 읽어서 Apache Flink에서 처리합니다. Flink는 내부 상태를 지속적으로 스냅샷으로 남겨놓기 때문에, 스냅샷에서 내부 상태를 복원하고 스트림에서 재처리가 필요한 이벤트를 재생하여 오퍼레이터 또는 전체 노드에서 발생한 장애를 복구 할 수 있습니다.

이벤트 저장을 위해 이렇게 한 곳에 로그를 보유하는 또 다른 장점은 여러 애플리케이션에서 데이터를 소비(Consume)할 수 있다는 점입니다. 벤치마크 테스트 및 일반 테스트를 위해 다른 버전의 Flink 애플리케이션을 나란히 실행시키는 것도 가능합니다. 또는, 장기간 아카이빙을 위해 스트림에서 Amazon S3로 데이터를 저장하는 데에 Amazon Kinesis Firehose를 사용할 수 도 있고, 그런 다음 Amazon Athena를 사용하여 과거의 기록을 상세하게 분석할 수도 있습니다.

Amazon Kinesis Streams, Amazon EMR, Amazon ES는 간단한 API 호출을 통해 생성 및 확장할 수 있는 관리형 서비스입니다. 따라서 이러한 서비스를 사용하면 비즈니스 가치를 제공하기 위한 전문 작업에 집중할 수 있습니다. 파이프라인 전체를 구축하고, 운영하고, 확장하기 위해 필요한 것들이 구분되어 있지 않은 무거운 작업을AWS로 수행하시기 바랍니다. 파이프 라인 생성은 AWS CloudFormation으로 완전히 자동화 될 수 있습니다. 개별 구성 요소는 Amazon CloudWatch를 통해 모니터링되고 자동으로 확장될 수 있습니다. 오류 사항 감지 및 자동 완화 역시 지원됩니다.

이후 부분에서는, AWS에서 레퍼런스 아키텍처를 만들고 실행하는 것에 관련된 부분에 중점을 두겠습니다. Flink에 대한 자세한 사항은, API를 이용하여 Flink 프로그램을 어떻게 구현하는지 다루는 Flink training session 을 참조하시기 바랍니다. 이 세션에서 사용된 시나리오는 이 글에서 다루는 내용과 상당히 비슷합니다.

레퍼런스 아키텍처 빌드 및 실행

실제 택시 운행 분석 애플리케이션을 위해, 다음 2 개의 CloudFormation 템플릿을 사용하여 레퍼런스 아키텍처를 만들고 실행합니다:

  • 첫번째 템플릿은 택시 운행을 스트림으로 수집하고 Flink로 운행 정보를 분석하기 위한 런타임 아티팩트(artifact)를 구축합니다.
  • 두번째 템플릿은 애플리케이션을 실행시키는 인프라 리소스를 생성합니다.

Flink 애플리케이션과 CloudFormation템플릿을 비롯한, 레퍼런스 아키텍처를 구축하고 실행시키는데 필요한 리소스는 AWSLabs GitHub 저장소의 flink-stream-processing-refarch에 있습니다.

런타임 아티팩트(Artifacts) 빌드 및 인프라 생성

우선 첫번째 CloudFormation 템플릿을 실행해서 AWS CodePipeline 파이프라인을 생성합니다. 이 파이프라인은 서버리스 방식으로 AWS CodeBuild를 사용해서 아티팩트를 만듭니다. 여기에 Maven을 설치하고 Flink Amazon Kinesis 커넥터 및 기타 런타임 아티팩트를 수동으로 구축할 수 있습니다. 파이프라인의 모든 단계가 성공적으로 완료되면, CloudFormation 템플릿의 출력 섹션에 지정되어 있는 S3 버킷에서 아티팩트를 검색할 수 있게 됩니다.

첫번째 템플릿이 생성되고 런타임 아티팩트가 만들어지면, 두번째 CloudFormation 템플릿을 실행합니다. 이를 통해 앞에서 설명한 레퍼런스의 리소스를 생성합니다. (SSH 접속을 위한 Key Pair가 없을 경우 두번째 CloudFormation 템플릿 실행 전에 미리 생성하여 준비합니다)

다음 단계를 진행하기 전에 위의 템플릿 2개가 모두 성공적으로 생성될 때까지 기다립니다. 약 15분 정도 걸릴 수 있으니, CloudFormation이 모든 작업을 마칠 때까지 자유롭게 커피 한 잔 하면서 기다립니다.

Flink 런타임 시작 및 Flink 프로그램 제출하기
Flink 런타임을 시작하고, 분석을 하는 Flink 프로그램을 서브밋(submit)하기 위해, EMR 마스터 노드에 연결합니다. 인프라 프로비저닝과 런타임 아티팩트 빌드를 위해 사용된 2개의 CloudFormation 템플릿의 실행 결과를 다음 명령어와 관련 파라미터를 통해 확인할 수 있습니다.

$ ssh -C -D 8157 hadoop@«EMR master node IP»

CloudFormation 템플릿을 통해 프로비저닝 된 EMR 클러스터는 노드당 4개의 vCPU를 지닌 2개의 c4.xlarge 코어 노드로 구성됩니다. 일반적으로, 태스크 매니저당 슬롯의 개수와 노드 코어의 수를 동일하게 맞춥니다. 여기서는, 2개의 태스크 매니저와 각 태스크 매니저 당 4개의 슬롯을 지닌 long-runnig Flink 클러스터로 시작하면 적절하겠습니다 (EMR 마스터 노드에 접속한 상태에서 다음 명령어를 실행합니다):

$ flink-yarn-session -n 2 -s 4 -tm 4096 -d

Flink 런타임이 실행되고 나면, 택시 스트림 프로세서 프로그램은 Amazon Kinesis 스트림 내의 운행 이벤트를 실시간으로 분석하기 위해 Flink 런타임에 제출 됩니다.

$ aws s3 cp s3://«artifact-bucket»/artifacts/flink-taxi-stream-processor-1.0.jar .
$ flink run -p 8 flink-taxi-stream-processor-1.0.jar --region «AWS region» --stream «Kinesis stream name» --es-endpoint https://«Elasticsearch endpoint»

Flink 애플리케이션이 실행 중이니, 스트림에서 유입되는 이벤트를 읽습니다. 그런 다음 이벤트 시간에 따라 타임 윈도우 내에서 이들을 집계하여 결과를 Amazon ES로 전송합니다. Flink 애플리케이션은 소규모 요청으로 Elasitcsearch 클러스터에 과부하가 걸리지 않도록 배치 레코드를 처리하고, 배치 처리 요청에 서명을 통해서Elasticsearch 클러스터의 보안 구성이 가능하도록 합니다.

브라우저에서 프록시(proxy)를 활성화 해놓았다면, 마스터 노드에 대한 SSH 세션을 수립하는 동적 포트 포워딩을 통해서Flink 웹 인터페이스를 볼 수 있습니다.

택시 운행 이벤트를 Amazon Kinesis Stream으로 입력
이벤트를 수집하기 위해, 택시 스트림 프로듀서 애플리케이션을 사용합니다. 이 애플리케이션은 미국 뉴욕 시에서 기록한 택시 운행의 이력 데이터셋을 S3로부터 읽어와서 8개의 샤드(shard)가 있는 Amazon Kinesis Stream으로 재생합니다. 택시 운행에 외에도, 프로듀서 애플리케이션은 워터마크 이벤트를 스트림으로 가져옵니다. 이를 통해서 프로듀서가 이력 데이터셋을 재생하는 시간을 Flink 애플리케이션이 결정할 수 있게 됩니다.

$ ssh -C ec2-user@«producer instance IP»
$ aws s3 cp s3://«artifact-bucket»/artifacts/kinesis-taxi-stream-producer-1.0.jar .
$ java -jar kinesis-taxi-stream-producer-1.0.jar -speedup 1440 -stream «Kinesis stream name» -region «AWS region»

이 애플리케이션은 이번 블로그에서 논의한  레퍼런스 아키텍처에만 특화된 것은 아닙니다. 예를 들어 Apache Flink 대신 Amazon Kinesis Analytics를 기반으로 유사한 스트림 처리 아키텍처를 구축하는 식으로 다른 목적에도 쉽게 재사용이 가능합니다.

Kibana 대시보드 탐색

전체 파이프라인이 실행중이므로, Flink 애플리케이션에 의해 실시간으로 제공되는 인사이트를 보여주는 Kibana 대시보드를 볼 수 있습니다:

https://«Elasticsearch end-point»/_plugin/kibana/app/kibana#/dashboard/Taxi-Trips-Dashboard

이 글의 목적에 맞게 Elasticsearch 클러스터는 인프라를 생성하는 CloudFormation 템플릿의 파라미터로 지정된 IP 주소 범위의 연결을 허용하도록 구성됩니다. 프로덕션-준비 상태의 애플리케이션의 경우, 이러한 설정이 맞지 않을 수도 있고 설정 자체가 불가능할 수도 있습니다. Elasticsearch 클러스터에 안전하게 연결하는 방법에 대한 자세한 내용은 AWS 데이터베이스 블로그의 Amazon Elasticsearch Service에 대한 액세스 제어 설정을 참조하시기 바랍니다.

Kibana 대시 보드에서 왼쪽의 지도는 택시 운행의 시작 지점을 시각화하여 보여주고 있습니다. 사각형이 빨간색에 가까울수록 해당 위치에서 더 많은 택시 운행이 시작됨을 의미합니다. 오른쪽의 그래프 차트는 John F. Kennedy 국제 공항과 LaGuardia Airport까지의 택시 운행 평균 시간을 각각 보여줍니다.

이러한 정보를 가지고, 현재 수요가 많은 지역에 빈 택시를 사전 조치하여 보내고 현지 공항으로의 운행 시간을 보다 정확하게 예측함으로써 택시 차량 운영 최적화가 가능해집니다.

이제 기본 인프라를 확장시킬 수 있습니다. 예를 들면, 스트림의 샤드 용량을 확장 시킵니다. Elasticsearch 클러스터의 인스턴수 갯수 또는 타입도 변경합니다. 아울러, 전체 파이프라인이 스케일 조정 중에도 제대로 동작하고 응답하는지 확인합니다.

AWS 에서 Apache Flink 실행

앞에서 본 것처럼, Flink 런타임은 YARN을 통해서 배포될 수 있습니다. 따라서 EMR은 AWS 상에서 Flink를 실행시키기에 매우 적합합니다. 하지만, Flink 애플리케이션을 빌드하고 실행시키기 위해 해야할 AWS에 관련된 고려사항이 몇 가지 있습니다:

  • Flink Amazon Kinesis 커넥터 빌드
  • Amazon Kinesis 컨슈머(Consumer) 환경 설정 수정
  • Amazon Kinesis에 워터마크를 서브밋해서 이벤트 시간 처리를 가능하게 함
  • Flink를 Amazon ES에 연동

Flink Amazon Kinesis 커넥터 빌드

Flink는 Amazon Kinesis Streams를 위한 커넥터를 제공합니다. 다른 Flink 아티팩트와는 달리, Amazon Kinesis 커넥터는 Maven central에서는 사용할 수 없습니다. 따라서 여러분이 직접 빌드하셔야 합니다. Maven 3.3.x의 경우 부적절하게 가려진 의존성(dependency)으로 인한 출력이 만들어질 수 있으므로, Maven 3.3.x 이상의 배포판 보다는 Maven 3.2.x로 Flink 빌드를 권장합니다.

$ wget -qO- https://github.com/apache/flink/archive/release-1.2.0.zip | bsdtar -xf-
$ cd flink-release-1.2.0
$ mvn clean package -Pinclude-kinesis -DskipTests -Dhadoop-two.version=2.7.3 -Daws.sdk.version=1.11.113 -Daws.kinesis-kcl.version=1.7.5 -Daws.kinesis-kpl.version=0.12.3

Flink Amazon Kinesis 커넥터를 받고 나면, 로컬 Maven 저장소에 .jar 파일들을 임포트 할 수 있습니다.

$ mvn install:install-file -Dfile=flink-connector-kinesis_2.10-1.2.0.jar -DpomFile=flink-connector-kinesis_2.10-1.2.0.pom.xml

Amazon Kinesis consumer 환경 설정 적용
Flink는 최근 EMR 클러스터와 관련된 role에서 AWS 자격 증명을 얻을 수 있도록 지원하기 시작했습니다. Flink 애플리케이션 소스 코드에서 AWS_CREDENTIALS_PROVIDER 속성을 AUTO로 설정하고 Properties 객체에서 AWS_ACCESS_KEY_ID 및 AWS_SECRET_ACCESS_KEY 파라미터를 생략하여 이 기능을 활성화합니다.

Properties kinesisConsumerConfig = new Properties();
kinesisConsumerConfig.setProperty(AWSConfigConstants.AWS_CREDENTIALS_PROVIDER, "AUTO");

자격 증명은 인스턴스의 메타데이터에서 자동으로 검색되므로 장기 자격 증명을 Flink 애플리케이션 또는 EMR 클러스터의 소스 코드에 저장할 필요가 없습니다.

프로듀서 애플리케이션은 초당 수천 개의 이벤트를 스트림으로 가져오므로, 단일 GetRecords 호출에서 Flink가 가져온 레코드 수를 늘리는 데 도움이 됩니다. 이 값을 Amazon Kinesis 에서 지원하는 최대값으로 변경하시기 바랍니다.

kinesisConsumerConfig.setProperty(ConsumerConfigConstants.SHARD_GETRECORDS_MAX, "10000");

Amazon Kinesis에 대한 워터마크 제출을 통한 이벤트 타임 프로세싱 지원
Flink는 여러 가지 개념의 타임, 특히 이벤트 타임을 지원합니다. 이벤트 타임은 스트리밍 응용 프로그램에 매우 적합한데, 이는 쿼리에 대해 안정적인 의미의 결과를 내주기 때문입니다. 이벤트 타임은 프로듀서 또는 프로듀서에 근접한 경우에 의해 결정됩니다. 네트워크로 인한 이벤트 순서의 재지정이 쿼리 결과에 미치는 영향은 매우 작습니다.

이벤트 타임을 실현하기 위해, Flink는 일정한 시간 간격으로 프로듀서가 보낸 워터마크를 사용하여 소스의 현재 시간을 Flink 런타임에게 알립니다. Amazon Kinesis Streams와 통합할 때 Flink 에 워터 마크를 제공하는 두 가지 방법이 있습니다:

  • 스트림에 워터마크를 수동으로 추가
  • 스트림 수집 과정에서 이벤트에 자동으로 추가되도록 ApproximalArrivalTime을 이용

Amazon Kinesis 스트림에서 시간 모델을 이벤트 시간으로 설정하면, Flink는 Amazon Kinesis에서 제공하는 ApproximalArrivalTime 값을 자동으로 사용합니다.

StreamExecutionEnvironment env = StreamExecutionEnviron-ment.getExecutionEnvironment(); 
env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);

또는, 스트림의 해당 이벤트에서 워터 마크 정보를 추출하는 사용자 정의 Timestamp Assigner 연산자를 지정하여 프로듀서가 정해 놓은 시간을 사용하도록 선택할 수도 있습니다.

DataStream<Event> kinesis = env
	.addSource(new FlinkKinesisConsumer<>(...))
	.assignTimestampsAndWatermarks(new PunctuatedAssigner())

PunctuatedAssigner 를 사용할 경우, 모든 개별 샤드에 워터 마크를 가져오는 것이 중요합니다. 왜냐하면Flink는 스트림별 샤드를 개별적으로 처리하기 때문입니다. 이는 스트림의 샤드를 나열하여 해결할 수 있습니다. 워터마크가 전송될 샤드의 해시 범위에 대해 해시 키를 명시적으로 세팅해서 특정 샤드에 워터마크를 수집합니다.

Amazon Kinesis를 이용하여 택시 운행 정보를 수집하는 프로듀서는 후자의 접근법을 사용합니다. 구현에 관련된 자세한 사항은 AWSLabs GitHub 저장소의flink-stream-processing-refarch를 참고하시기 바랍니다.

Amazon ES와 Flink의 연동
Flink는 Elasticsearch에 대한 몇 가지 커넥터를 제공합니다. 그러나 이러한 모든 커넥터는 단지 Elasticsearch의 TCP 전송 프로토콜을 지원합니다. 반면 Amazon ES는 HTTP 프로토콜을 사용합니다. Elasticsearch 5부터는 TCP 전송 프로토콜이 더 이상 사용되지 않습니다. HTTP 프로토콜을 지원하는 Flink 용 Elasticsearch 커넥터는 여전히 동작하지만, Jest 라이브러리를 사용하여 Amazon ES에 연결할 수 있는 사용자 정의 싱크(sink)를 빌드 할 수 있습니다. 싱크(sink)는 IAM 자격 증명으로 요청에 서명 할 수 있어야합니다.

Elasticsearch 싱크의 전체 구현에 대한 자세한 내용은 Flink 애플리케이션의 소스 코드가 포함 된 flink-taxi-stream-processor AWSLabs GitHub 저장소를 참조하십시오.

요약

이 글에서는 Apache Flink를 기반으로 일관성 있고 확장 가능하며 안정적인 스트림 처리 아키텍처를 구축하는 방법에 대해 설명했습니다. 또한 관리형 서비스를 활용하여 짧은 대기 시간 및 높은 처리량 스트림 처리 파이프라인을 구축하고 유지 관리하는 데 필요한 전문 지식과 운영 노력을 줄이는 방법을 보여줌으로써 전문 지식을 비즈니스 가치를 제공하는 데에 집중할 수 있습니다.

오늘부터 Amazon EMR에서 Apache Flink를 사용해보시기 바랍니다. AWSLabs GitHub 저장소에는 주어진 예제를 실행하는 데 필요한 리소스가 포함되어 있으며 빠르게 시작하는 데 도움이 되는 추가 정보가 포함되어 있습니다.

이 글은 AWS Bigdata 블로그의 Build a Real-time Stream Processing Pipeline with Apache Flink on AWS의 한국어 번역으로, AWS 프로페셔널 서비스의 남궁영환 컨설턴트께서 번역해 주셨습니다.

 

Amazon Aurora 기반 PostgreSQL 호환 서비스 정식 출시

작년 말 Amazon Aurora 서비스에 PostgreSQL 호환 기능 추가 계획에 대해 이야기했습니다.  발표 직후 비공개 베타 버전을 출시했으며, 금년 초 공개 프리뷰를 통해이를 따라 갔다. 베타 및 미리보기 중에 많은 피드백을 받았으며 제품이 고객의 요구를 충족시키고 기대치를 초과 할 수 있도록 최선을 다했습니다.

정식 출시
오늘 Amazon Aurora기반 PostgreSQL 서비스를 정식 출시 하며, 우선 토교 리전을 포함 4개 AWS 리전에서 사용가능합니다.  PostgreSQL 9.6.3과 호환되며 최대 64TB의 스토리지를 지원하도록 자동으로 확장되며, 컴퓨팅 성능과 가용성을 개선하기 위해 6-way 복제 기능을 제공합니다.

Amazon Aurora 기반 MySQL 서비스 처럼  관리 서비스로서 설정과 사용이 매우 쉽습니다. 성능 측면에서 보면 PostgreSQL을 직접 실행 한 경우 얻을 수있는 처리량의 최대 3 배를 기대할 수 있습니다 (Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases  참고)

RDS Console에서 Amazon Aurora를 엔진으로 선택하고 PostgreSQL과 호환되는 에디션을 선택하고 Next를 클릭하여 PostgreSQL과 호환되는 Amazon Aurora 인스턴스를 시작할 수 있습니다.

그런 다음 인스턴스 클래스, 단일 또는 다중 AZ 배포 (각각 dev / test 및 production에 적합)를 선택하고 인스턴스 이름 및 관리자 자격 증명을 설정하고 Next를 클릭합니다.

6개의 인스턴스 클래스 (2 – 64 vCPU 및 15.25 – 488 GiB 메모리) 중에서 선택할 수 있습니다.

db.r4인스턴스 클래스는 Aurora와 RDS에 추가 된 새로운 클래스이며 최상위 더 많은 용량을 제공합니다. db.r4.16xlarge 는 추가 쓰기 성능을 제공하며 두 개 이상의 샤드 된 데이터베이스 대신 단일 오로라 데이터베이스를 사용할 수 있습니다.

또한 다음 페이지에서 VPC 및 공용 액세스 가능성과 같은 네트워크 옵션부터 많은 고급 옵션을 설정할 수 있습니다.

클러스터 이름 및 기타 데이터베이스 옵션을 설정할 수 있습니다. 암호화는 사용하기 쉽고 기본적으로 사용 가능합니다. 내장 기본 마스터 키를 사용하거나 직접 선택할 수 있습니다.

장애 조치 (failover) 동작, 스냅 샷 백업의 보존 기간을 설정하고 향상된 모니터링을 통해 세부 (OS 수준) 메트릭 수집을 활성화하도록 선택할 수도 있습니다.

원하는대로 설정 한 후에는 Launch DB Instance를 클릭하여 계속 진행하십시오!

새 인스턴스 (다중 AZ를 지정한 이후 Primary 및 Secondary 지정)가 몇 분 안에 실행됩니다.

각 PostgreSQL과 호환되는 인스턴스는 CloudWatch에 44개의 메트릭을 자동으로 게시합니다.

향상된 모니터링을 사용하면 각 인스턴스는 인스턴스 별 및 프로세스 별 메트릭을 추가로 수집합니다. 인스턴스가 시작될 때 또는 나중에 Modify Instance을 통해 활성화 할 수 있습니다. 다음은 향상된 모니터링이 활성화되었을 때 수집 된 일부 측정 항목입니다.

Manage Graphs (그래프 관리)를 클릭하면 표시되는 메트릭을 선택할 수 있습니다.

프로세스 별 메트릭도 사용할 수 있습니다.

최대 15 개의 Aurora 복제본을 만들어 읽기 용량을 확장 할 수 있습니다.

클러스터는 복제본에서 요청을로드 밸런스하기 위해 접근할 수있는 단일 엔드 포인트를 제공합니다.

성능 살펴보기
이전에 언급했듯이 통계는 자동으로 사용 설정됩니다. Amazon Aurora 기능은 데이터베이스 엔진에 직접 연결되어있어 각 쿼리를 깊이 조사하고 사용하는 데이터베이스 리소스 및 전반적인 응답 시간에 기여하는 방식을 확인할 수 있습니다. 다음은 초기보기입니다.

각 쿼리의 동시 복사본 수를 보려면 SQL 쿼리로 보기 방식을 구분 할 수 있습니다.

이 글에 있는 것 보다 더 많은보기와 옵션이 있습니다. 자세한 내용은 Using Performance Insights을 참조하십시오.

Amazon Aurora PostgreSQL 서비스로 이전
AWS Database Migration ServiceSchema Conversion Tool은 상용 및 오픈 소스 데이터베이스에 저장된 데이터를 Amazon Aurora로 이동할 수 있도록 도와줍니다. 스키마 변환 도구는 MySQL과 PostgreSQL 사이에서 선택할 수 있도록 데이터베이스 스키마와 코드를 신속하게 평가합니다. 신규 무료 DMS 프로그램을 사용하면 DMS 및 SCT를 사용하여 무료로 Aurora로 마이그레이션 할 수 있으며 여러 유형의 DMS 인스턴스에 최대 6 개월간 접근 할 수 있습니다.

이미 PostgreSQL을 사용하고 있다면 PostGISdblink를 포함한 확장 기능 목록을 지원한다는 소식을 듣게 될 것입니다.

정식 출시
미국 동부 (버지니아 북부), 유럽 연합 (아일랜드), 미국 서부 (오레곤) 및 미국 동부 (오하이오) 지역에서는 Amazon Aurora와 PostgreSQL 호환성을 사용할 수 있으며 가능한 한 빨리 다른 사람들과 함께 할 수 있습니다.

Jeff;

이 글은 Now Available – Amazon Aurora with PostgreSQL Compatibility 의 한국어 번역입니다.

Stephen Orban – 오늘날 IT 임원이란 최고 변화 관리 책임자(CCMO, Chief Change Management Officer)

저는 IT 임원들이 조직의 클라우드 여정을 이끌 때 3가지 분야에 에너지를 집중하는 것을 확인한 바 있습니다. 이 게시물에서 저는 각 분야를 미리 살펴보고 향후 몇 주 동안 모든 분야에 대해 자세히 설명하고자 합니다. 또한 다음 주에 열리는 re:Invent의 Executive Summit에서 본 주제에 대해 논의하는 여러 세션을 진행할 예정이며, 여러분의 많은 참석을 바랍니다!

여정(Journey)은 반복적인 과정이며 시간이 걸릴 것이라는 점을 기억하십시오. 여정은 단순히 조직의 기술을 변화시키는 데 그치지 않습니다. 여정은 IT 부서가 기술을 제공하고 비즈니스 가치를 부여하는 방식을 변화시키는 것입니다. 클라우드가 동반하는 기술 변화 및 새로운 비즈니스 모델을 통해 여러분은 조직 전반에 걸쳐 직무 기능, 재무, 제품 개발 방법론 등을 살펴볼 기회를 얻게 됩니다. 사업 동기가 재무적 또는 경쟁적 성격을 띠든 혹은 두 가지 성격을 모두 갖고 있든 상관 없이, 이러한 여정은 여러분의 경력 전반에 걸쳐 비즈니스를 개선하기 위한 변혁을 추진하는 IT 임원이 될 흔치 않은 기회를 제공합니다. 이는 무엇이 적합하고 무엇이 부적합한지를 여러분 스스로 판단하고, 귀사의 비즈니스에 가장 적합한 환경을 조성할 수 있음을 의미합니다.

저는 오늘날 IT 임원이 이른바 최고 변화 관리 책임자 즉, CCMO™(Chief Change Management Officer)의 역할을 담당해야 한다고 주장합니다. 이제 기술은 더 이상 단지 비즈니스를 지원하는 역할만으로 볼 수 없습니다. 오늘날의 IT 임원은 바로 이러한 점을 이해함으로써 점점 더 경쟁적이면서도 기술적인 환경에 적응하는 데 필요한 변화를 주도할 최적의 위치에 있습니다. 모든 산업 분야에서 이러한 CCMO는 다른 경영진 및 직원들의 변화를 주도하며 결단을 갖고 실행을 관리해야 합니다.

CCMO의 성공적인 역할 수행을 위해 필수적인 것으로 판단되는 3가지 책임은 다음과 같습니다.

비즈니스와 기술의 병합. 클라우드 도입은 기술 변화 이상의 이점을 제공합니다. 또한 새로운 비즈니스 수행 방식을 제공합니다. 이것은 경영진에 속하는 모든 이들이 관심을 가져야 할 대상에 해당됩니다. 경영진을 고려하고 해당 여정이 각 직무에 어떤 영향을 미치고 있거나 혹은 미칠 수 있는지를 검토하는 것이야말로 IT 임원이 할 일입니다. 분명히 긍정적인 결과들 (재무적 성과, 민첩성, 글로벌 확장 지원 등)과 몇 가지 과제들 (고용, 교육, 익숙하지 않은 것들에 대한 두려움)이 모두 존재합니다. 변화하는 IT 환경을 각 임원의 목표 달성에 도움이 되는 방향으로 포지셔닝하려면 먼저 그러한 목표와 과제에 대해 공감해야 하며, 어떻게 하면 해당 여정에서 제반 목표가 보다 수월해지면서 과제들이 줄어드는지를 보여줘야 합니다. (업데이트: 오늘날 비즈니스와 기술의 병합에서 CIO의 역할)

명확한 목적을 제시. 귀사의 경영 이해관계자들에게 있어 기술을 비즈니스 성과와 연계하는 것이 중요합니다. 특히 각자의 역할에 변화가 있을 때 여러분이 속한 팀의 역할들을 비즈니스 이익과  결부시킨다면 팀원들이 각자 자신의 업무에 얼마나 적합한지를 이해하는 데 도움이 될 것입니다. 기업의 임원이 된 지 얼마 되지 않은 시절에 저는 단지 부서 차원의 지침을 발표했다는 이유로 모든 구성원들이 이를 따를 것이라는 다소 순진한 생각을 했던 것 같습니다. 제가 정말로 중요한 사항들을 확인하고 이를 반복적으로 전달한 후에야 비로소 구성원들은 이를 받아들이기 시작했던 것입니다. 오히려 클라우드는 귀사의 직원들을 위해 새로운 기회를 많이 창출하고 있으며 그들이 기꺼이 배우고자 한다면 비즈니스에 기여할 수 있는 새로운 방법들도 많이 있습니다. (업데이트: 리더의 자질을 높일 수 있는 조건)

새로운 규칙을 세우기(만들기). 대부분의 전통적인 IT 운영 모델은클라우드가 제공하는 것들을 최대한 활용할 수 없습니다. Uber, AirBnB, DropBox 및 기타 여러 경쟁업체들이 최신 기술뿐만 아니라 빠른 속도로 진행되는 사업 운영을 통해 언제든지 불쑥 나타날 수 있는 오늘날의 세상에서, 여러분은 귀사의 조직이 이러한 변화에 계속 부응할 수 있도록 새로운 규칙들을 고려할 필요가 있습니다. 이는 앞서 언급한 2가지 책임보다 훨씬 더 중요한 것으로써 최상위 IT 담당자가 제일 먼저 맡아야 할 책임에 속합니다. 조직의 모든 단계에서 확인되지 못한 규칙 위반은 피해야 합니다.

앞으로 몇 주 동안 이 3가지 사항에 대해 좀 더 자세히 살펴보기로 하겠습니다. 적합한 사례들이 있다면 언제든지 알려주십시오.

– Stephen;
@stephenorban
http://aws.amazon.com/enterprise/

본 블로그 글은 Stephen Orban의 엔터프라이즈 클라우드 여정 시리즈 입니다. 더 자세한 것은 전체 목록을 참고하시기 바랍니다.

 

AWS 주간 소식 모음 – 2017년 10월 23일

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

aws-korea-weekly

AWS코리아 블로그

AWS코리아 발표 자료

AWS코리아 동영상

AWS 관련 뉴스 및 추천 콘텐츠

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

AWS 제품별 블로그(영문)

AWS 주요 행사 온라인 세미나

AWS 마케팅 행사

AWS 공인 교육 일정

AWSKRUG 소모임

AWS 주요 파트너사 블로그

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

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

– AWS코리아 마케팅팀;

Stephen Orban – 클라우드를 통해 구현된 실험 문화의 조성

비즈니스에서 중요한 것은 속도” – Jeff Bezos

 

시장에서 기업의 경쟁력을 유지한다는 것은 예나 지금이나 늘 어려운 일입니다. Wired는 1955년부터 집계된 Fortune 500에서 매년 20~50개의 기업들이 탈락하고 있다고 지적합니다. 이러한 회전율은 기술과 많은 관련이 있습니다. 구체적으로, 클라우드는 지난 몇 년간이런 트렌드를 가능하게 한 핵심 요소 중 하나입니다. 소자본 기업들은 클라우드를 통해 갑자기 두각을 나타내어 산업 전반에 혼란을 불러일으킬 수 있습니다. 예를 들면 AirBnB, Pinterest, Uber 및 Spotify 같은 업체들은 설립된 지 10년도 채 되지 않았음에도 불구하고 현재 클라우드를 통해 비즈니스를 구현함으로써 업계 전체를 새롭게 정의하고 있습니다.

이러한 파괴적 기업들 (그리고 대부분의 신생 기업들)의 공통점은 무엇일까요? 그들은 실험으로부터 시작되었습니다. 그 누구도 이들 업체가 시장에서 성공할 것이라고 확신하지 못했습니다.

실험은 더 이상 스타트업의 전유물이 아니다

좋은 소식은, 클라우드가 실험을 가능하게 할 뿐 아니라,기업의 규모나 사업 기간에 관계 없이 계속 경쟁력을 유지하도록 도움을 줄 수 있다는 것입니다. 물론, 회사의 규모가 커지고 IT 운영이 더욱 확립될수록 클라우드를 최대한 활용하기 위해서는 더 많은 것들이 바뀌어야 할 것입니다.

클라우드의 이점을 극대화하는 데 성공한 기업의 경우, 변화는 기회가 됩니다. 이러한 기업들의 임원들은 현 상태를 넘어서는 도전을 두려워하지 않으며, 실험 문화 조성은 그들이 일으키려고 하는 가장 공통적인 변화 중 하나입니다. 저는 Dow Jones에서 CIO를 맡고 있던 시절 분명 실험 문화를 구축하려 노력했고,  똑같은 일을 하고 있는 그 밖의 많은 업체들(Capital OneGEJohnson & Johnson 및 News Corp 등)을 높이 평가하게 되었습니다. 이들 기업은 고객을 만족시킴과 동시에 경쟁사보다 앞서 나가기 위해 끊임없이 현실에 안주하지 않고 도전합니다.

이러한 트렌드 때문에 기업의 클라우드 여정에서 기업 내 실험 문화를 조성하는 것이 세 번째 모범 사례로 자리매김하게 되었습니다. 실험 문화를 조성하려는 기업들을 위해 이 게시물은 해당 주제에 대해 시리즈가 될 만한 내용을 소개하고 있으며, 기업의 실험이 클라우드를 통해 어떻게 더 수월하게 진행되는지를 중점적으로 다루고 있습니다. 앞으로 몇 주 동안 후속 게시물에서 오늘날의 기술직 임원이 실험 문화를 조성할 수 있는 방법에 대해 좀 더 자세히 살펴보겠습니다.

기업의 실험은 클라우드를 통해 어떻게 더 수월하게 진행되는가?

오늘날 시장에서 확실히 자리매김한 대부분의 엔터프라이즈조차도 시장을 선도하는 위치와 자본만으로 경쟁력을 유지하기에는 역부족입니다. 이에, 기업에게 유용할 클라우드를 통해 실험을 더욱 수월하게 진행하는 몇 가지 방법들을 소개하고자 합니다.

굳이 자본이 없도 실험을 할 수 있습니다. 저의 모든 경력을 통틀어, 유망한 제품에 필요 같다고 생각된 리소스에   투자하기위해  합리적인 투자 수익률(ROI)을 제시하는 것에 가장 많은 시간을 보냈습니다. 예상 수익률 계획을 제대로 세울 수 있었던 경우는 거의 없었으며  항상 인프라를 필요 이상으로 구축했습니다. 어떤 경우에는 저희 팀이 해당 제품의 첫 번째 버전을 제작하는 것보다 정당한 투자 근거를 제시하는 것에 더 많은 시간을 할애했습니다. 클라우드는 선불형 및 종량제로 제공되기 때문에 며칠 내에 실험할 수 있는 것들에 대해 몇 개월의 시간을 투자 수익률을 계산하면서 허비할 필요가 더 이상 없습니다. 이제 막 창업을 한 기업들은 이보다 훨씬 더 간편한 옵션에 접근할 수 있습니다. 예를 들면, 일부 AWS 서비스는 프리 티어를 포함하고 있어 실험 비용이 전혀 들지 않습니다.

성과를 보이지 않는 프로젝트에 비용을 들일 필요 없습니다. 때때로 가장 흥미로운 비전조차도 제품/시장에 적합하지 않을 수도 있습니다. 제가 꽤 공을 들인 제품이 시장에서 신통치 않았던 적도 있었습니다. 매번 교훈을 얻었기 때문에 실패에 대해 부끄럽게 생각하지 않습니다. 다만 실패한 제품에 대한 비용을 회사의 대차 대조표에 계속 올리는 것이 정말 마음 아픈 일이기는 합니다. 때로는 애초의 사용 목적이 아니었던 것을 위해 투자해야 한다면 더 마음 아픕니다. 회사의 위키 페이지(wiki page)를 운영하기 위해 16코어 시스템을 허비하는 것은 두말할 것도 없이 절대  합리적이지 않습니다. 클라우드를 통해서는 회사의 제품이 시장에서 별 성과가 없다면 리소스를 줄이고 그에 따른 비용 지출을 모두 중단하면 됩니다.

클라우드는 자동화에 최적화되어 있습니다올해 초에 저는 클라우드에서 자동화의 중요성에 관한 글을 쓴 바 있습니다. 또한 저는 DevOps 역량을 개발하려는 업체들에게 자동화가 얼마나 중요한지를 설명하는 글을 쓰기도 했습니다. 자동화를 통해 소프트웨어에서 반복 가능한 작업을 처리하면 기업들은 수익성을 위해 제품개발에 더 많은 시간을 할애할 수 있습니다.

가장 중요한 것에 집중할 수 있습니다. 클라우드는 엔터프라이즈 IT의 과중한 업무 부담을  제거합니다. 최근에 Talen Energy의 Bruce Kantor는 제게 이렇게 말했습니다. “이제 저희는 더 이상 로드 밸런서 노릇을 하지 않습니다. 다만 로드 밸런싱을 하고 있는 것이죠.” 결국 로드 밸런싱이 바로 임원들이 비즈니스 전반에 걸친 플랫폼으로써 클라우드를 앞다투어 도입하려는 동기인 셈입니다. 클라우드를 사용하면 과중한 업무 부담을 덜 수 있으며, 수익성을 위해 기업의 리소스를 더욱 의미있게 사용할 수 있습니다.

이 주제에 대해 다뤄야 할 다른 내용으로 무엇이 있는지 여러분의 의견을 꼭 듣고 싶습니다.

-Stephen
@stephenorban
http://aws.amazon.com/enterprise/

본 블로그 글은 Stephen Orban의 엔터프라이즈 클라우드 여정 시리즈 입니다. 더 자세한 것은 전체 목록을 참고하시기 바랍니다.

 

Amazon ECR 수명 주기 정책을 통한 컨테이너 이미지 자동 삭제 기능 출시

오늘부터 Amazon EC2 Container Registry(Amazon ECR)의 일부인 수명 주기 정책을 사용하여 오래되거나 사용하지 않는 이미지를 자동으로 제거함으로써 컨테이너 이미지 리포지토리를 깔끔하게 정리할 수 있습니다.

Amazon ECR은 종합 관리형 도커 컨테이너 레지스트리로 서비스 규모 조정을 통해 수백 개의 이미지의 일괄 풀링을 처리하는 데 따른 일반적인 문제를 염려할 필요 없이 도커 컨테이너 이미지를 용이하게 저장하고 관리하고 배포할 수 있습니다. 규모가 커지면 Amazon ECR을 사용하는 개발팀이 여러 컨테이너 이미지 버전으로 리포지토리가 가득차는 현상을 자주 접하게 됩니다. 그럴 경우 코드 변경을 찾기 힘들어지고 불필요한 스토리지 비용이 발생하여 문제가 됩니다. 이전에는 리포지토리를 정리하려면 오래된 이미지를 직접 삭제하거나 스크립트를 작성하고 실행하는 데 많은 시간이 소요되었습니다.

이제는 수명 주기 정책을 통해 규칙 집합을 정의하여 오래된 컨테이너 이미지를 자동으로 제거할 수 있습니다. 또한 규칙 미리 보기를 통해 규칙을 실행할 때 영향을 받는 컨테이너 이미지가 어떤 것인지 정확히 파악할 수 있습니다. 결과적으로 리포지토리를 더 잘 구성하여 문제의 소지가 있는 코드 수정을 보다 용이하게 찾고 스토리지 비용을 절감할 수 있습니다.

그럼 수명 주기 정책의 작동 방식을 알아보겠습니다.

 

기본 규칙

컨테이너에 코드를 배포하는 것에 따른 가장 큰 이점 중 하나는 이전 버전을 신속하고 용이하게 되돌릴 수 있다는 것입니다. 무언가가 잘못되었을 때 이전 컨테이너 버전으로 쉽게 되돌릴 수 있고 잘못된 배포 전처럼 애플리케이션 실행되기 때문에 위험 부담을 덜 안고 배포할 수 있습니다. 대부분은 아마도 몇 개 버전씩이나 롤백하는 경우는 없을 것입니다. 상황이 비슷하다면, 수명 주기 규칙 하나만으로 최근 30개 이미지를 보관하는 데 충분합니다.

최근 30개 이미지

ECR 레지스트리에서 [Dry-Run Lifecycle Rules, Add]를 선택합니다.

  • [Image Status]에서 [Untagged]를 선택합니다.
  • [Match criteria]의 [Count Type]에서 [Image Count More Than]을 입력합니다.
  • [Count Number]에서 30을 입력합니다.
  • [Rule action]에서 [expire]를 입력합니다.

Save를 선택합니다. 어떤 이미지가 정리되는지 확인하려면, [Save and dry-run rules]를 선택합니다.

물론 규정 준수 이유 때문에 특정 이미지의 경우 횟수 기준이 아니라 기간 기준으로 보관하는 것을 선호하는 경우도 있습니다. 그와 같은 상황에서는 90일이 지난 이미지를 정리하는 것을 선택할 수 있습니다.

Last 90 Days(지난 7일)

방금 생성한 규칙을 선택하고 [Edit]을 선택합니다. 태그 없는 이미지의 경우 90일 간만 보관하도록 파라미터를 변경합니다.

  • [Match criteria]의 [Count Type]에서 [Since Image Pushed]를 입력합니다.
  • [Count Number]에서 90을 입력합니다.
  • [Count Unit]에서 [days]를 입력합니다.

태그

90일은 임의로 제시한 기간으로, 특정한 종류의 이미지에 대해서는 더 긴 기간을 요하는 정책을 시행할 수도 있을 것입니다. 그와 같은 상황에서도 계속하여 정리를 원하는 경우, 태그가 앞에 붙는 이미지를 삭제하는 것을 검토할 수 있습니다.

아래는 태그 없는 이미지, 개발, 스테이징 및 프로덕션 이미지를 정리하기 위한 규칙의 목록입니다.

  • 90일이 지난 태그가 없는 이미지 삭제
  • 90일이 지난 개발 태그가 붙은 이미지 삭제
  • 180일이 지난 스테이징 태그가 붙은 이미지 삭제
  • 1년이 지난 프로덕션 태그가 붙은 이미지 삭제

확인할 수 있듯이 새 Amazon ECR 수명 주기 정책은 강력하며, 필요한 이미지는 간단하게 보관하고 다시 사용할 일이 없는 이미지는 쉽게 삭제할 수 있게 해 줍니다. 이 기능은 Amazon ECR을 이용할 수 있는 모든 리전에서 추가 비용 없이 지금 바로 이용할 수 있습니다. 자세한 내용은 Amazon AWS 기술 설명서의 Amazon ECR 수명 주기 정책을 참조하십시오.

Brent;

이 글은 AWS Compute Blog의 Clean up Your Container Images with Amazon ECR Lifecycle Policies 글의 한국어 번역입니다.

Github에 대한 AWS DevOps 개발 도구 기능 확대

AWS 개발자 도구는 AWS CodeCommit, AWS CodePipeline, AWS CodeBuildAWS CodeDeploy를 포함하는 서비스 모음입니다. 이들 서비스는 애플리케이션 소스 코드의 버전 관리를 안전하게 저장 및 유지하고 애플리케이션을 AWS 또는 온프레미스 환경에 자동으로 구축하고 테스트하고 배포하는 데 도움이 됩니다. AWS 개발자 도구는 개발자 및 IT 전문가가 소프트웨어를 신속하고 안전하게 제공할 수 있도록 설계되어 있습니다.

AWS는 AWS 개발자 도구 에코시스템을 타사의 도구 및 서비스로 확장하려는 지속적인 노력의 일환으로 마침내 AWS CodeStarAWS CodeBuild와 GitHub의 통합을 실현했습니다. 이 덕분에 GitHub 사용자도 이제 AWS 개발자 도구를 사용하여 지속적 통합 및 배포 도구 체인을 릴리스 프로세스의 일부로 보다 용이하게 구축할 수 있게 되었습니다.

이 게시물에서는 다음에 대해 알아보겠습니다.

사전 조건:

AWS 계정, GitHub 계정, Amazon EC2 키 페어, 그리고 AWS Identity & Access Management(IAM), AWS CodeStar, AWS CodeBuild, AWS CodePipeline, Amazon EC2, Amazon S3의 관리자 수준 권한이 필요합니다.

GitHub와 AWS CodeStar의 통합

AWS CodeStar를 사용하면 AWS에서 애플리케이션을 빠르게 개발하고 빌드하고 배포할 수 있습니다. AWS CodeStar의 통합 사용자 인터페이스는 한 곳에서 소프트웨어 개발 활동을 손쉽게 관리할 수 있게 해 줍니다. AWS CodeStar를 사용하면 몇 분 이내에 지속적 배포 도구 체인 전체를 구축할 수 있으므로 코드 릴리스를 보다 빨리 시작할 수 있습니다.

AWS CodeStar가 올해 4월에 출시되었을 때 AWS CodeCommit을 호스팅 대상 소스 리포지토리로 사용했습니다. 이제는 AWS CodeCommit 또는 GitHub 중에 선택하여 CodeStar 프로젝트를 위한 소스 제어 서비스로 지정할 수 있습니다. 이에 더해, CodeStar 프로젝트 대시보드를 사용하면 커밋, 이슈 및 풀 요청과 같은 GitHub 활동을 추적할 수 있습니다. 이 기능은 CI/CD 도구 체인의 구성 요소 전체에 걸쳐 프로젝트 활동을 용이하게 관리할 수 있도록 해 줍니다. GitHub 대시보드 보기 기능이 추가되면 AWS 애플리케이션의 배포가 더욱 간단해질 것입니다.

여기에서는 CodeStar 프로젝트를 위한 소스 공급자로 GitHub를 활용하는 방법을 보여 드릴 것입니다. 아울러 CodeStar 대시보드에서 최근의 커밋, 이슈 및 풀 요청과 관련된 작업을 수행하는 방법을 알려 드릴 것입니다.

AWS Management Console에 로그인한 다음 [Services] 메뉴에서 [CodeStar]를 클릭합니다. CodeStar 콘솔에서 [Create a new project]를 선택합니다. 그러면 [Choose a project template] 페이지가 나타납니다.

CodeStar 프로젝트

프로그래밍 언어, 애플리케이션 범주 또는 AWS 서비스 별로 옵션을 선택합니다. 저는 Amazon EC2에서 실행되는 Rails 웹 애플리케이션에서 Ruby를 선택할 것입니다.

이제 [Project details] 페이지에서 GitHub 옵션을 확인할 수 있습니다. 프로젝트의 이름을 입력하고 [Connect to GitHub]를 선택합니다.

프로젝트 세부 정보

GitHub 리포지토리에 연결할 수 있는 권한을 요청하는 메시지가 표시됩니다. 메시지가 표시되면 [Authorize]를 선택한 다음 GitHub 계정 암호를 입력합니다.

승인

그러면 GitHub ID가 OAuth를 통해 AWS CodeStar에 연결됩니다. 언제나 [GitHub application settings]에서 탐색을 통해 설정을 살펴볼 수 있습니다.

설치된 GitHub 앱

아래와 같이 [AWS CodeStar is now connected to GitHub]라는 메시지가 표시됩니다.

프로젝트 만들기

퍼블릭 또는 프라이빗 리포지토리를 선택할 수 있습니다. GitHub는 퍼블릭 및 오픈 소스 프로젝트에 참여하는 사용자 및 조직에 대해 무료 계정을 제공하는 한편 무제한 프라이빗 리포지토리와 사용자 관리 기능 및 보안 기능(옵션)이 포함된 유료 계정 또한 제공하고 있습니다.

이 예제에서는 퍼블릭 리포지토리 옵션을 선택합니다. 원할 경우 리포지토리 설명을 편집한 다음 [Next]를 선택합니다.

CodeStar 프로젝트 세부 정보를 검토한 다음 [Create Project]를 선택합니다. [Choose an Amazon EC2 Key Pair]에서 [Create Project]를 선택합니다.

키 페어

[Review project details]에서 [Edit Amazon EC2 configuration]이 표시됩니다. 이 링크를 선택하여 인스턴스 유형, VPC 및 서브넷 옵션을 구성합니다. AWS CodeStar의 경우 AWS 리소스 및 IAM 권한을 생성하고 관리하려면 서비스 역할이 필요합니다. 이 서비스 역할은 [AWS CodeStar would like permission to administer AWS resources on your behalf ] 확인란을 선택하면 생성됩니다.

[Create Project]를 선택합니다. 프로젝트 및 리소스를 생성하는 데 몇 분 정도 걸릴 수 있습니다.

프로젝트 세부 정보 검토

CodeStar 프로젝트를 만들면 프로젝트 팀에 소유자로 추가됩니다. AWS CodeStar를 처음으로 사용하는 경우 다음과 같은 정보를 제공하라는 메시지가 표시되는데, 다른 사람에게 공개되는 정보입니다.

  • 표시 이름
  • 이메일 주소

이 정보는 AWS CodeStar 사용자 프로필에 사용됩니다. 사용자 프로필은 프로젝트가 아닌 단일 AWS 리전에 한정됩니다. 사용자가 여러 리전의 프로젝트 일원인 경우 각 리전마다 사용자 프로필을 생성해야 합니다.

사용자 설정

사용자 설정

[Next]를 선택합니다. AWS CodeStar는 여러분이 설정한 구성에 따라 GitHub 리포지토리를 생성합니다(예: https://github.com/biyer/ruby-on-rails-service).

IDE(통합 개발 환경)를 AWS CodeStar와 통합하면 원하는 환경에서 계속 코드를 작성하고 개발할 수 있습니다. 변경 사항은 코드를 커밋하고 푸시할 때마다 AWS CodeStar 프로젝트에 포함됩니다.

IDE

IDE를 선택한 후에, [Next]를 선택하여 CodeStar 대시보드로 이동합니다. 익숙해지도록 몇 분 정도 대시보드를 살펴보십시오. 작업 항목의 백로그에서 최근의 코드 배포까지 전체 소프트웨어 개발 프로세스에 걸쳐 진행 사항을 용이하게 추적할 수 있습니다.

대시보드

애플리케이션 배포가 완료되면 애플리케이션을 표시할 엔드포인트를 선택합니다.

Pipeline

해당 애플리케이션의 엔드포인트를 열면 다음과 같은 화면이 표시됩니다.

대시보드의 [Commit history] 섹션에 GitHub 리포지토리의 커밋 이력이 표시됩니다. 커밋 ID 또는 [Open in GitHub ]옵션을 선택하면, GitHub 리포지토리에 대한 핫링크를 사용할 수 있습니다.

커밋 이력

AWS CodeStar 프로젝트 대시보드에서 사용자와 사용자의 팀은 프로젝트에 대한 최신 커밋, 지속적 제공 파이프라인의 상태, 인스턴스 성능을 비롯한 프로젝트 리소스의 상태를 확인합니다. 이 정보는 특정 리소스 전용 타일에 표시됩니다. 이러한 리소스에 대한 자세한 내용을 보려면 해당 타일에서 세부 정보 링크를 선택합니다. 해당 AWS 서비스의 콘솔이 해당 리소스의 세부 정보 페이지에서 열립니다.

문제

또한 상태 및 할당된 사용자를 기준으로 이슈를 필터링할 수 있습니다.

필터

AWS CodeBuild, 이제 GitHub 풀 요청 구축 지원

CodeBuild는 소스 코드를 컴파일하고 테스트를 실행하며 배포 준비가 완료된 소프트웨어 패키지를 생성하는 완전 관리형 빌드 서비스입니다. CodeBuild를 사용하면 자체 빌드 서버를 프로비저닝, 관리 및 확장할 필요가 없습니다. CodeBuild는 지속적으로 확장되며 여러 빌드를 동시에 처리하기 때문에 빌드가 대기열에서 대기하지 않습니다. 사전 패키징된 빌드 환경을 사용하여 신속하게 시작할 수 있으며 혹은 자체 빌드 도구를 사용하는 사용자 지정 빌드 환경을 만들 수 있습니다.

최근 AWS는 AWS CodeBuild에서 이제 GitHub 풀 요청 구축을 지원한다는 사실을 발표했습니다. 이 기능을 사용하면 CodeBuild로 애플리케이션 코드를 편집하고 빌드하는 동시에 팀원들과 보다 용이하게 협업할 수 있습니다. AWS CodeBuild 콘솔 또는 AWS CodePipeline 콘솔에서 AWS CodeBuild를 실행할 수 있습니다. 또한 AWS Command Line Interface(AWS CLI), AWS SDK 또는 AWS CodeBuild Plugin for Jenkins를 사용하여 AWS CodeBuild의 실행을 자동화할 수 있습니다.

AWS CodeBuild

이 단원에서는 Webhook을 통한 GitHub로부터의 풀 요청을 사용하여 AWS CodeBuild에서 빌드를 트리거하는 방법을 알아보겠습니다.

https://console.aws.amazon.com/codebuild/에서 AWS CodeBuild 콘솔을 엽니다. [Create Project]를 선택합니다. CodeBuild 프로젝트가 이미 있는 경우, [Edit project]를 선택한 다음 지시를 따르면 됩니다. CodeBuild는 AWS CodeCommit, S3, BitBucket 및 GitHub와 연결하여 빌드의 소스 코드를 가져올 수 있습니다. [Source provider]에서, [GitHub]를 선택한 다음, [Connect to GitHub]를 선택합니다.

구성

GitHub와 CodeBuild 프로젝트를 성공적으로 연결한 후에는 GitHub 계정에서 리포지토리를 선택할 수 있습니다. CodeBuild 또한 임의의 퍼블릭 리포지토리에 대한 연결을 지원합니다. [GitHub application settings]에서 탐색을 통해 설정을 살펴볼 수 있습니다.

GitHub 앱

[Source: What to Build]의 [Webhook]에서 [Rebuild every time a code change is pushed to this repository ] 확인란을 선택합니다.

참고: 이 옵션은 [ Repository]에서 [Use a repository in my account]를 선택한 경우에만 선택할 수 있습니다.

소스

[Environment: How to build]의 [Environment image]에서 [Use an image managed by AWS CodeBuild]를 선택합니다. [Operating system]에서 [Ubuntu]를 선택합니다. [Runtime]에서 [Base]를 선택합니다. [Version]에서 가용한 최신 버전을 선택합니다. [Build specification]에서 빌드 명령 및 관련 설정 모음을 YAML 형식(buildspec.yml)으로 제공하거나 빌드 명령을 콘솔에 직접 삽입함으로써 빌드 사양을 재정의할 수 있습니다. AWS CodeBuild는 이들 명령을 사용하여 빌드를 실행합니다. 이 예제에서 출력은 문자열 “hello”입니다.

환경

[Artifacts: Where to put the artifacts from this build project]의 [Type]에서 [No artifacts]를 선택합니다. (이는 테스트를 실행하거나 도커 이미지를 Amazon ECR에 넣을 경우 선택하는 유형이기도 합니다.) AWS CodeBuild가 사용자를 대신하여 종속 AWS 서비스와 상호 작용할 수 있으려면 AWS CodeBuild 서비스 역할이 있어야 합니다. 기존에 역할이 없는 경우에는 [Create a role]을 선택하고 [Role name]에서 역할 이름을 입력합니다.

결과물

이 예제에서는 고급 설정을 기본값으로 둡니다.

[Show advanced settings]를 확장하면 다음을 포함하여 빌드를 지정할 수 있는 옵션이 표시됩니다.

  • 빌드 제한 시간
  • 이 프로젝트의 빌드에서 사용할 모든 결과물을 암호화하는 KMS 키
  • 도커 이미지 빌드 옵션
  • 빌드 작업 동안의 권한 상승(예: 빌드 컨테이너 내의 도커에 액세스하여 Dockerfile을 빌드)
  • 컴퓨팅 유형을 빌드하기 위한 리소스 옵션
  • 환경 변수(내장 또는 사용자 지정) 자세한 내용은 AWS CodeBuild 사용 설명서의 [Create a Build Project]를 참조하십시오.

고급 설정

AWS CodeBuild 콘솔을 사용하여 Amazon EC2 시스템 관리자에서 파라미터를 생성할 수 있습니다. [Create a parameter]를 선택한 다음, 대화 상자에 표시되는 지시에 따릅니다. (대화 상자의 [KMS key]에서 계정에 있는 AWS KMS 키의 ARN을 선택적으로 지정할 수 있습니다. Amazon EC2 시스템 관리자는 이 키를 사용하여 저장하는 동안 파라미터의 값을 암호화하고 검색 동안 암호를 해독합니다.)

파라미터 생성

[Continue]를 선택합니다. 나중에 [Review] 페이지에서 [Save and build] 또는 [Save]를 선택하여 빌드를 실행합니다.

[Start build]를 선택합니다. 빌드가 완료되면 [Build logs ]에 빌드에 관한 세부 정보가 표시됩니다.

로그

풀 요청을 시연하기 위해 리포지토리를 다른 GitHub 사용자로 포크하고, 포크된 리포지토리로 커밋하고, 변경 사항을 새로 생성된 브랜치로 체크인한 다음, 풀 요청을 엽니다.

풀 요청

풀 요청이 제출되는 즉시, CodeBuild가 빌드 실행을 시작합니다.

구축

GitHub가 HTTP POST 페이로드를 Webhook의 구성된 URL(강조 표시된 부분)로 전송합니다. 이 URL은 CodeBuild가 최신 소스 코드를 다운로드하고 빌드 단계를 실행하는 데 사용합니다.

빌드 프로젝트

GitHub 풀 요청에 대해 [Show all checks] 옵션을 확장하면 CodeBuild가 빌드를 완료하였고, 모든 확인이 통과되었고, CodeBuild 콘솔에서 빌드 이력을 여는 데 사용하는 딥 링크가 [Details]에 제공됨을 확인할 수 있습니다.

풀 요청

요약:

이 게시물에서 GitHub를 CodeStar 프로젝트의 소스 공급자로 활용하는 방법과 CodeStar 대시보드에서 최근의 커밋, 이슈 및 풀 요청과 관련된 작업을 수행하는 방법을 알아봤습니다. 또한 GitHub 풀 요청을 사용하여 AWS CodeBuild에서 빌드를 자동으로 트리거하는 방법과 특히 이 기능을 사용하면 CodeBuild를 통해 애플리케이션 코드를 편집하고 빌드하는 동시에 팀원들과 보다 용이하게 협업할 수 있다는 것을 알려 드렸습니다.


작성자 소개:

Balaji Iyer는 AWS 전문 서비스 팀에서 엔터프라이즈 컨설턴트로 활약하고 있습니다. Balaji Iyer는 이 역할을 맡으면서 다수의 고객이 AWS 제품을 알아보고 선택하는 데 일조했습니다. 그의 전문 분야는 고도 확장형 분산 시스템, 서버 없는 아키텍처, 대규모 마이그레이션, 운영 보안, 전략적 AWS 이니셔티브 등의 설계 및 구현입니다. Balaji Iyer는 Amazon에 합류하기 전에 10년 이상 운영 체계, 빅 데이터 분석 솔루션, 모바일 서비스 및 웹 애플리케이션을 구축해 왔습니다. 여가 시간에는 아웃도어 활동을 즐기거나 가족과 함께 시간을 보냅니다.

이 글은 AWS DevOps 블로그의 AWS Developer Tools Expands Integration to Include GitHub의 한국어 번역입니다.