Amazon Web Services 한국 블로그

Stephen Orban – 클라우드 혁신 센터를 위한 공동 책임

“옳은 일과 어려운 일은 대개 동일하다.” ― Steve Maraboli

 

저는 최근에 클라우드 혁신 센터(CCoE)라는 주제를 소개하였습니다. 클라우드 혁신 센터란 클라우드 모범 사례, 통합 관리 및 프레임워크를 개발함으로써 클라우드를 통해다른 직원들의 비즈니스 혁신을 지원하는 부서를 말합니다. CCoE의 설립은 엔터프라이즈 클라우드 여정 시리즈에 설명한 7가지 모범 사례 중 다섯 번째입니다.

기업의 CCoE는 처음에는 작게 시작하지만 비즈니스 가치가 더해지면서 점차 확장해야 합니다. 여기에 능숙한 기업들은 CCoE 지표 또는 KPI를 설정 및 비교하면서 진행 상황을 측정합니다. 이러한 지표들은 IT 리소스 사용량부터 대응 능력의 향상을 나타내는 매일/매주/매월 제품 출시 수, 그리고 CCoE가 영향을 미치는 프로젝트 수에 이르기까지 다양합니다. 이러한 지표들을 고객 서비스 중심의 접근 방식(원문)과 결합하면 다른 사업 부서들도 CCoE가 제공하는 가치와 협업의 즐거움을 깨닫고 CCoE와 함께 협업하는 데 관심을 보일 것입니다.

마지막 게시물에서 알아볼 내용은 CCoE의 인력 배치 방법입니다. 여기에서는 CCoE 확장에 성공한 기업들로부터 공통적으로 발견한 몇 가지 사항에 대해서 살펴보겠습니다. 이 게시물은 최종적인 목록이라기보다는 CCoE에게 맡길 수 있는 적절한 업무에 대해 생각해보는 기회로 활용해야 하며, 추가로 활용할 수 있는 몇 가지 자원에 대한 결론으로 끝을 맺습니다. 처음에는 작게 시작하는 것을 잊지 마십시오. 쓸데없는 데 시간을 낭비하지 말고 현재 프로젝트에서 당면한 문제를 해결하는 데만 집중하십시오. 문제를 해결하면서 실험과 측정을 통해 학습할 수 있습니다.

자격 증명 관리: 클라우드 환경에서 맡게 되는 역할과 권한을 이미 기업 내에서 맡고 있는 역할과 의무에 연계하려면 어떻게 해야 할까요? 어떤 환경에서 어떤 서비스와 기능을 이용하는 것이 편리할까요? Active Directory 및/또는 SSO(Single Sign On) 플랫폼과 통합하려면 어떻게 해야 할까요? 예를 들어 AWS의 IAM 플랫폼은 AWS 서비스마다 접근 수준을 세분화하여 제공합니다. 이러한 접근 수준의 세분화는 수많은 엔터프라이즈에게 새로운 경험이자, 기업 내에서 어떤 역할이 어떤 환경의 어떤 자원 및 서비스에 접근해야 할지 고민해볼 수 있는 기회가 될 것입니다.

계정 및 비용 관리: IT 서비스를 논리적으로 분리하거나 사업 부서별 비용을 파악할 수 있도록 계정을 각 사업 부서와 비용 센터로 연계하고 싶으신가요? 사업 부서별로 각자 소비 비용에 대해 책임을 지는 방법도 있지만 자원 포트폴리오의 규모가 커질수록 비용 최적화를 중앙에서 관리하는 것이 더욱 용이합니다. 이때 CCoE는 비즈니스에 따라 유연함을 유지할 수 있도록 시간차를 두고 RI를 구매하는 방법에 대해서 진지하게 생각하는 동시에 도움이 될 수 있는 몇 가지 도구(CloudHealthCloudability 등)를 살펴보아야 합니다.

자산 관리/태그 지정: 제공하는 자원마다 어떤 유형의 정보를 추적하시겠습니까? 제가 경험한 몇 가지 예로는 예산 코드/비용 센터, 사업 부서, 환경(테스트, 스테이징, 프로덕션 등), 담당자 등이 있습니다. Dow Jones에 재직할 당시 가장 먼저 직면한 성장통 중 하나는 실험에 참여하는 개발자들이 늘어나면서점차 불어나는 비용이었습니다. 하지만 개발 VPC에서 시작한 인스턴스마다 태그를 지정하고 야간이나 주말에는 해당 인스턴스를 멈추도록 스크립트를 작성함으로써 단 몇 시간 만에 이 문제를 해결하였습니다. 이때부터 처음으로 매우 정교한 태그 지정과 자동화 라이브러리를 구현하여 확장과 동시에 환경을 관리할 수 있게 되었습니다. 저는 다른  수많은 고객들도 고가용성 아키텍처와 “재해 무관심(disaster indifference)“의 수준에 점차 다가갈수록 프로덕션 환경에서 태그를 기준으로 작업을 진행하는 모습을 보았습니다. (재해 무관심이라는 표현은 Nike의 Wilf Russell에게서 차용함)

참조 아키텍처: 처음부터 보안 및 통합 관리 시스템을 환경에 구축하고 자동화를 통해 최신 상태를 유지하려면 어떻게 해야 할까요? 애플리케이션에서 사용하는 도구와 접근방식의 공통점을 찾아 정의할 수만 있다면 애플리케이션의 설치부터 패치 및 통합 관리까지 자동화할 수 있습니다. 이때는 전체 엔터프라이즈에서 각 사업 부서마다 자동화가 필요한 프로세스를 유연하게 추가할 수 있는 참조 아키텍처가 하나 필요합니다. 또는, 애플리케이션 클래스이나계층마다 다수의 참조 아키텍처가 필요할 수도 있습니다. 이 두 가지 사이에서 결정될 가능성이 가장 높지만, 이유야 어떻든, 시간이 지날수록 더 많은 프로세스를 자동화 할 수 있는 방법을 고민하여 각 사업 부서가 인프라에 대한 고민은 줄이고 자신의 애플리케이션에 대해 더 많이 생각할 수 있도록하십시오.

시간이 지나면서 CCoE의 학습 효과가 높아지면 더욱 규범적으로 대처할 수 있는 사업 부서가 늘어나 일관성은 그대로 유지하면서 혁신의 자유는 모든 부서가 동일하게 누릴 수 있습니다. 여기에서 다루지는 않았지만 그 밖에도 자동화 전략의 정의, 하이브리드 아키텍처에 대한 탐구, 각 사업 부서가 신속한 움직임으로 개발한 자산을 직접 운영할 수 있는 연속 전달(continuous delivery) 기능 지원, 데이터 통합 관리의 정의, 그리고 비즈니스에 중요한 지표/KPI에 대한 투명성을 보장하는 대시보드 구현 등이 고려해야 할 사항입니다.

AWS 클라우드 도입 프레임워크에는 지금까지 얘기한 모범 사례를 비롯한 여러 가지에 대해 고찰할 수 있는 규범적 지침에 관한 견해가 다수 포함되어 있습니다. 또한 AWS Trusted Advisor를 이용하면 비용, 성능, 보안 및 내결함성 최적화를 사전에 살펴볼 수 있습니다. 마지막으로, AWS Well-Architected Framework를 통해 CCoE의 업무를 지금까지 AWS 고객에게서 알아본 모범 사례와 비교하여 벤치마킹하는 것도 가능합니다.

그 밖에 중요한 문제에 집중할 수 있도록 CCoE가 기여한 점이 있다면 무엇이 있을까요? 있다면 꼭 듣고 싶습니다!

 

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

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

Amazon S3 및 AWS Glue를 이용한 데이터 레이크 구축하기

데이터 레이크(Data Lake)는 다양한 유형의 대량 데이터를 처리해야 하는 과제를 해결하는 데이터 저장 및 분석 방법으로서 점차 인기를 얻고 있습니다. 데이터 레이크를 사용하면 모든 데이터(정형 및 비정형)를 중앙 집중식 리포지토리 한 곳에 저장할 수 있습니다. 데이터를 있는 그대로 저장할 수 있으므로 데이터를 사전 정의된 스키마로 변환할 필요가 없습니다.

많은 기업들은 데이터 레이크에서 Amazon S3를 사용하는 데 따르는 이점을 잘 알고 있습니다. 예를 들어, 스토리지를 컴퓨팅과 분리한 상태에서 오픈 데이터 형식을 지원하는 Amazon S3는 매우 내구력 있는 경제적 객체 시작점으로서 모든 AWS 분석 서비스와 연동됩니다. Amazon S3는 데이터 레이크의 토대이지만, 다른 서비스를 추가하여 업무상 필요에 맞게 데이터 레이크를 조정할 수 있습니다. AWS를 기반으로 데이터 레이크를 구축하는 방법에 대한 자세한 내용은 데이터 레이크란 소개를 참조하십시오.

데이터 레이크를 사용하는 데 따른 주요 과제 중 하나는 데이터를 찾고 스키마와 데이터 형식을 이해하는 것이므로 Amazon은 최근에 AWS Glue를 도입했습니다. AWS Glue를 사용하면 데이터의 구조와 형식을 검색하여 Amazon S3 데이터 레이크로부터 신속하게 비즈니스 통찰을 이끌어 내는 데 필요한 시간과 노력을 획기적으로 줄일 수 있습니다. 이 서비스는 자동으로 Amazon S3 데이터를 크롤링하여 데이터 형식을 식별한 후 다른 AWS 분석 서비스에 사용할 스키마를 제안합니다.

이 게시물에서는 AWS Glue를 사용하여 Amazon S3에서 데이터를 크롤링하고 다른 AWS 제품군에서 사용 가능한 메타데이터 저장소를 구축하는 과정을 안내합니다.

AWS Glue 기능

AWS Glue는 까다롭고 시간이 많이 소요되는 데이터 검색, 변환, 작업 일정 조정 등과 같은 작업은 간소화 및 자동화하는 종합 관리형 데이터 카탈로그 및 ETL(추출, 변환, 로드) 서비스입니다. AWS Glue는 데이터 소스를 크롤링하고 CSV, Apache Parquet, JSON 등을 비롯한 널리 사용되는 데이터 형식과 데이터 유형에 대해 사전 구축된 분류자를 사용하여 데이터 카탈로그를 생성합니다.

AWS Glue는 최신 데이터 아키텍처의 핵심 구성 요소인 Amazon S3, Amazon RDS, Amazon Athena, Amazon RedshiftAmazon Redshift Spectrum과 통합되어 있으므로 데이터 이동과 관리를 원활하게 조율할 수 있습니다.

AWS Glue 데이터 카탈로그는 Apache Hive 메타스토어와 호환되며 Hive, Presto, Apache Spark, Apache Pig 등 널리 사용되는 도구를 지원합니다. 또한 Amazon Athena, Amazon EMR 및 Amazon Redshift Spectrum과 직접 통합됩니다.

이와 함께 AWS Glue 데이터 카탈로그는 사용 편의성과 데이터 관리 기능을 지원하기 위해 다음과 같은 확장을 제공합니다.

  • 검색을 통해 데이터 찾기
  • 분류를 통해 파일 식별 및 구문 분석
  • 버전 관리를 통해 변화하는 스키마 관리

자세한 내용은 AWS Glue 제품 세부 정보를 참조하십시오.

Amazon S3 데이터 레이크

AWS Glue는 Amazon S3 데이터 레이크의 필수 구성 요소이며, 최신 데이터 분석을 위한 데이터 카탈로그 및 변환 서비스를 제공합니다.

이전 그림에는 다양한 분석 사용 사례에 대한 데이터가 준비되어 있습니다. 처음에는 변경 불가능한 원본 형식으로 데이터를 수집합니다. 그런 다음 데이터를 변환하고 보강하여 각 사용 사례에 유용하게 만들 수 있습니다. 이 예에서는 원시 CSV 파일을 Amazon Athena에서 사용할 수 있는 Apache Parquet으로 변환합니다. Amazon Athena에서 변환된 데이터를 사용하여 성능을 높이고 비용을 절감할 수 있습니다.

또한 다른 데이터 세트와 결합하는 방식으로 데이터를 보강하여 추가적인 통찰력을 얻을 수 있습니다. AWS Glue 크롤러는 작업 트리거 또는 사전 정의된 일정에 따라 데이터 단계별로 테이블을 생성합니다. 이 예에서는 AWS Lambda 함수를 사용하여 원시 데이터 S3 버킷에 새 파일이 추가될 때마다 ETL 프로세스를 트리거합니다. 이 테이블을 사용하면 Amazon Athena, Amazon Redshift Spectrum 및 Amazon EMR에서 표준 SQL 또는 Apache Hive를 사용하여 모든 단계의 데이터를 쿼리할 수 있습니다. 이 구성은 민첩한 비즈니스 인텔리전스를 제공하여 다양한 데이터로부터 빠르고 쉽게 비즈니스 가치를 창출하는 인기 설계 패턴입니다.

직접 실습하기

이 연습에서는 데이터베이스 정의, Amazon S3 버킷에서 데이터를 탐색하도록 크롤러 구성, 테이블 생성, Parquet으로 CSV 파일 변환, Parquet 데이터에 대한 테이블 생성, Amazon Athena를 사용하여 데이터 쿼리 등과 같은 작업을 연습합니다.

데이터 검색

AWS Management Console에 로그인하고 AWS Glue 콘솔을 엽니다. [Analytics] 섹션에서 AWS Glue를 찾을 수 있습니다. AWS Glue는 현재 미국 동부(버지니아), 미국 동부(오하이오) 및 미국 서부(오레곤) 지역에서 사용 가능합니다. 다른 AWS 지역이 수시로 추가됩니다.

데이터를 검색하려면 먼저 데이터베이스를 추가해야 합니다. 데이터베이스는 다수의 테이블로 구성된 집합입니다.

  1. 콘솔에서 [Add database]를 선택합니다. [Database name]에 nycitytaxi를 입력하고 [Create]를 선택합니다.
  2. 탐색 창에서 [ Tables]를 선택합니다. 테이블은 열 이름, 데이터 유형 정의, 데이터 세트에 대한 기타 메타데이터로 구성됩니다.
  3. nycitytaxi 데이터베이스에 테이블을 추가합니다. 크롤러를 사용하거나 수동으로 테이블을 추가할 수 있습니다. 크롤러는 데이터 스토어에 연결하여 분류자의 우선 순위 지정 목록을 통해 데이터의 스키마를 결정하는 프로그램입니다. AWS Glue는 CSV, JSON, Avro 등과 같은 일반 파일 형식에 대한 분류자를 제공합니다. grok 패턴을 사용하여 고유한 분류자를 작성할 수도 있습니다.
  4. 크롤러를 추가하려면 데이터 원본을 입력합니다(Amazon S3 버킷 즉, s3://aws-bigdata-blog/artifacts/glue-data-lake/data/). 이 S3 버킷에는 2017년 1월 한 달 동안의 녹색 택시에 대한 모든 승차 정보로 구성된 데이터 파일이 포함되어 있습니다.
  5. [Next]를 선택합니다.
  6. [IAM role]에 대한 드롭다운 목록에서 기본 역할 AWSGlueServiceRoleDefault를 선택합니다.
  7. [Frequency]에서 [Run on demand]를 선택합니다. 크롤러를 온디맨드로 실행하거나 일정에 따라 실행하도록 설정할 수 있습니다.
  8. [Database]에서 nycitytaxi를 선택합니다. 적절한 방법을 선택하려면 AWS Glue에서 스키마 변경을 처리하는 방법을 잘 알고 있어야 합니다. 이 예에서는 테이블을 변경 사항으로 업데이트합니다. 스키마 변경에 대한 자세한 내용은 AWS Glue 개발자 안내서에서 크롤러를 사용하여 테이블 카탈로그 작성을 참조하십시오.
  9. 단계를 검토하고 [Finish]를 선택합니다. 크롤러를 실행할 준비가 되었습니다. [Run it now]를 선택합니다.

    크롤러가 종료되면 테이블 한 개가 추가되었습니다.
  10. 왼쪽 탐색 창에서 [Tables]를 선택한 다음 [data]를 선택합니다. 이 화면에서는 스키마, 속성 및 기타 중요한 정보를 비롯한 테이블에 대해 설명합니다.

CSV에서 Parquet 형식으로 데이터 변환

이제 CSV에서 Parquet로 데이터를 변환하는 작업을 구성하여 실행할 수 있습니다. Parquet는 Amazon Athena 및 Amazon Redshift Spectrum과 같은 AWS 분석 서비스에 적합한 컬럼 형식입니다.

  1. 왼쪽 탐색 창에서 [ETL]을 선택하고 [Jobs]를 선택한 다음 [Add job]을 선택합니다.
  2. [Name]에 nytaxi-csv-parquet를 입력합니다.
  3. [IAM role]에서 AWSGlueServiceRoleDefault를 선택합니다.
  4. [This job runs]에서 [A proposed script generated by AWS Glue]를 선택합니다.
  5. 스크립트를 저장할 고유한 Amazon S3 경로를 제공합니다.
  6. 임시 디렉터리에 대한 고유한 Amazon S3 디렉터리를 제공합니다.
  7. [Next]를 선택합니다.
  8. 데이터 원본에서 [data]를 선택합니다.
  9. [Create tables in your data target]을 선택합니다.
  10. [Parquet]를 형식으로 선택합니다.
  11. 결과를 저장할 새 위치(기존 객체가 없는 새 접두사 위치)를 선택합니다.
  12. 스키마 매핑을 확인하고 [Finish]를 선택합니다.
  13. 작업을 확인합니다. 이 화면에서는 전체 작업 보기를 제공하며 작업을 편집, 저장 및 실행할 수 있습니다. AWS Glue에서 이 스크립트를 생성했습니다. 필요한 경우 스크립트를 직접 생성할 수 있습니다.
  14. [Save]를 선택한 다음 [Run job]을 선택합니다.

Parquet 테이블 및 크롤러 추가

작업이 완료되면 크롤러를 사용하여 Parquet 데이터에 대한 새 테이블을 추가합니다.

  1. [Crawler name]에 nytaxiparquet를 입력합니다.
  2. S3를 [Data store]로 선택합니다.
  3. [ETL]에서 선택한 Amazon S3 경로 포함
  4. [IAM role]에서 AWSGlueServiceRoleDefault를 선택합니다.
  5. [Database]에 대해 nycitytaxi를 선택합니다.
  6. [Frequency]에서 [Run on demand]를 선택합니다.

크롤러가 완료되면 nycitytaxi 데이터베이스에 두 개의 테이블이 있습니다. 즉, 원시 CSV 데이터용 테이블 한 개와 변환된 Parquet 테이블 한 개가 있습니다.

Amazon Athena를 사용하여 데이터 분석

Amazon Athena는 표준 SQL을 사용해 Amazon S3에 저장된 데이터를 간편하게 분석할 수 있는 대화식 쿼리 서비스입니다. Athena를 사용하여 CSV 데이터를 쿼리할 수 있습니다. 하지만 Parquet 파일 형식을 사용하면 데이터를 쿼리하는 데 필요한 시간과 비용을 획기적으로 줄일 수 있습니다. 자세한 내용은 Analyzing Data in Amazon S3 using Amazon Athena 블로그 게시물을 참조하십시오.

AWS Glue를 Amazon Athena와 함께 사용하려면 Athena 데이터 카탈로그를 AWS Glue 데이터 카탈로그로 업그레이드해야 합니다. Athena 데이터 카탈로그를 업그레이드하는 방법에 대한 자세한 내용은 이 단계별 지침을 참조하십시오.

    1. Athena용 AWS Management Console을 엽니다. 쿼리 편집기에 nycitytaxi의 두 테이블이 표시됩니다.

표준 SQL을 사용하여 데이터를 쿼리할 수 있습니다.

  1. nytaxigreenparquet를 선택합니다.
  2. 유형 "nycitytaxi"에서 *를 선택합니다."data" limit 10;
  3. [Run Query]를 선택합니다.

마무리

이 게시물에서는 AWS Glue 및 Amazon S3를 사용하여 데이터 레이크의 기초를 얼마나 쉽게 구축할 수 있는지를 보여 줍니다. AWS Glue를 사용하여 Amazon S3에서 데이터를 크롤링하고 Apache Hive 호환 메타데이터 저장소를 구축하면 AWS 분석 서비스와 주요 Hadoop 에코시스템 도구를 통해 메타데이터를 사용할 수 있습니다. 이 AWS 서비스 조합은 강력하고 간편하며 비즈니스 통찰을 더 빠르게 얻을 수 있도록 해줍니다.

자세한 내용은 다음 블로그 게시물을 참조하십시오.

작성자 소개

Gordon Heinrich는 글로벌 SI(Systems Integrator)로 활동 중인 솔루션 아키텍트이며, 파트너 및 고객과 협력하여 데이터 레이크를 구축하고 AWS 분석 서비스를 사용하는 데 유용한 설계 지침을 제공합니다. 여가 시간에는 가족과 함께 시간을 보내거나 콜로라도에서 스키, 하이킹, 산악 자전거 등을 즐깁니다.

이 글은 AWS BigData 블로그의 Build a Data Lake Foundation with AWS Glue and Amazon S3의 한국어 버전입니다.

AWS 주간 소식 모음 – 2017년 11월 13일

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

AWS 한국 블로그

AWS 추천 콘텐츠

AWS 최신 뉴스

AWS 제품별 블로그(영문)

AWS 주요 행사 온라인 세미나

AWS 마케팅 행사

AWS 공인 교육 일정

AWSKRUG 소모임

AWS 주요 파트너사 블로그

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

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

– AWS코리아 마케팅팀;

 

AWS Direct Connect Gateway 출시 – 리전 간 VPC 접근 기능 제공

지난 2012년 AWS Direct Connect를 출시하여, 기업 고객들이 기존 사무실 및 데이터 센터와 AWS와 전용선으로 연결할 수 있게 되어 개인 정보 보호 개선, 데이터 전송 대역폭 추가, 보다 예측 가능한 데이터 전송 성능 개선이 가능합니다.  최근 집계에 따르면 60곳 이상에서 접근 가능하며, 서울 리전의 경우도  드림라인, KINX, 세종 텔레콤, LG유플러스 등 파트너를 통해 연결하실 수 있습니다.

오늘 부터 AWS Direct Connect 게이트웨이(Gateway)를 추가하여 Direct Connect를 더 단순하면서도 더 강력한 도구로 만들고 있습니다. 모든 리전의 Direct Connect 고객에게 전역 Amazon IP 경로를 수신할 수 있는 퍼블릭 가상 인터페이스를 만들고, Amazon 서비스에 대한 퍼블릭 엔드포인트에 액세스하고, Direct Connect 요금 모델을 업데이트할 수 있는 기능을 제공합니다.

그럼 각 기능을 자세히 살펴보겠습니다.

새로운 Direct Connect 게이트웨이
이제 새로운 Direct Connect 게이트웨이를 사용하여 여러 AWS 리전에 걸쳐 있는 Virtual Private Cloud(VPC)에 연결할 수 있습니다. 더 이상 VPC마다 BGP 세션을 여러 개 설정할 필요가 없기 때문에, 관리 워크로드는 물론 네트워크 장치의 부담도 줄어듭니다.

또한 이 기능을 사용하면 모든 Direct Connect 위치에서 연결된 모든 VPC에 연결할 수 있으므로 리전 간 AWS 서비스를 사용하는 비용이 한층 더 절감됩니다.

다음은 Direct Connect 게이트웨이로 간소화된 구성을 보여 주는 다이어그램입니다(각 “자물쇠” 아이콘은 가상 프라이빗 게이트웨이를 나타냄). 먼저 아래와 같은 상태로 시작합니다.

그리고 최종적으로 다음과 같은 상태가 됩니다.

특정 Direct Connect 게이트웨이를 참조하는 VPC들의 IP 주소 범위가 중첩되지 않아야 합니다. 현재는 모든 VPC가 동일한 AWS 계정에 속해야 하지만, 앞으로 이를 좀 더 유연하게 만들 계획입니다.

각 게이트웨이는 모든 퍼블릭 AWS 리전에 걸쳐 존재하는 전역 객체입니다. 게이트웨이를 통한 리전 간의 모든 통신은 AWS 네트워크 백본에서 이루어집니다.

Direct Connect 게이트웨이 생성
Direct Connect 게이트웨이는 Direct Connect 콘솔에서 만들거나 코드에서 CreateDirectConnectGateway 함수를 호출하여 만들 수 있습니다. 저는 콘솔을 사용해 보겠습니다.

Direct Connect 콘솔을 열고 [Direct Connect Gateways]를 클릭해 시작합니다.

아직 게이트웨이가 없기 때문에 목록이 비어 있습니다. [Create Direct Connect Gateway]를 클릭해 다음과 같이 변경합니다.

게이트웨이 이름을 지정하고, 우리 네트워크의 프라이빗 ASN을 입력한 다음 [Create]를 클릭합니다. 이때 ASN(자율 시스템 번호)은 RFC 6996에 정의된 프라이빗 범위 중 하나에 속해야 합니다.

잠시 후 상대방 AWS 리전에 새 게이트웨이가 나타납니다.

오하이오에 Direct Connect 연결이 생겼고, 저는 이것으로 VIF를 생성하려고 합니다.

이제 해당 게이트웨이 및 연결을 참조하는 프라이빗 VIF를 생성합니다.

몇 초 안에 사용할 준비가 됩니다.

이미 CIDR이 중첩되지 않는 VPC 한 쌍이 있고, 각각에 가상 프라이빗 게이트웨이가 연결되어 있습니다. 다음은 VPC입니다. 데모이기 때문에 편의상 둘 다 같은 리전에 있는 VPC를 보여 드리겠습니다.

가상 프라이빗 게이트웨이는 다음과 같습니다.

Direct Connect 콘솔로 돌아가서 Direct Connect 게이트웨이로 이동합니다. 게이트웨이를 선택하고 [Actions] 메뉴에서 [Associate Virtual Private Gateway]를 선택합니다.

그런 다음 가상 프라이빗 게이트웨이 두 개를 선택하고 [Associate]를 클릭합니다.

일반적인 경우처럼 두 VPC가 별개의 AWS 리전에 있더라도 동일한 절차가 적용됩니다. 이 블로그 게시물에서는 일을 쉽게 하기 위해 두 번 대신 한 번만 작업을 했습니다.

1분 정도면 가상 게이트웨이 연결이 완료됩니다([associating] 상태로 시작).

상태가 associated로 바뀌면 VPC가 어떤 AWS 리전에 있든 간에 AWS Direct Connect 연결을 통해 온-프레미스 네트워크와 VPC 간에 트래픽이 흐를 수 있습니다.

서비스 엔드포인트를 위한 퍼블릭 가상 인터페이스
이제 퍼블릭 가상 인터페이스를 만들고, 여기에서 Direct Connect를 통해 AWS 퍼블릭 서비스 엔드포인트에 액세스한 다음 원하는 AWS 리전(AWS 중국 리전 제외)에서 실행 중인 AWS 서비스를 이용할 수 있습니다. 이러한 인터페이스는 (BGP를 통해) Amazon의 전역 IP 경로를 수신합니다. Direct Connect 콘솔에서 이러한 인터페이스를 만들 수 있습니다. 먼저 아래 그림처럼 [Public] 옵션을 선택합니다.

업데이트된 요금 모델
AWS 리전과 AWS Direct Connect 위치가 계속해서 늘어난다는 점을 고려하여, 이제 Direct Connect 위치와 원본 AWS 리전의 위치를 기준으로 데이터 전송 요금을 산정합니다. 새 요금 체계는 AWS Direct Connect 위치를 기준으로 하던 이전 모델보다 간단합니다.

지금 사용 가능
이 새로운 기능은 바로 오늘부터 사용할 수 있습니다. 무료로 Direct Connect 게이트웨이를 만들고 사용해 보십시오. 포트 시간 및 데이터 전송에는 일반적인 Direct Connect 요금이 청구됩니다.

Jeff;

이 글은 New – AWS Direct Connect Gateway – Inter-Region VPC Access의 한국어 번역입니다.

Amazon S3 신규 기본 암호화 및 보안 기능 업데이트

지난 2006년 S3를 발표했을 때, “각 블록은 ACL(액세스 제어 목록)로 보호되기 때문에 개발자가 원한다면 데이터를 프라이빗 데이터로 유지해도 되고, 읽을 수 있는 데이터로 공유해도 되고, 읽고 쓸 수 있는 데이터로 공유해도 된다”라고 알려드렸습니다.

접근 권한 부여를 위한 ACL과 프라이빗 버킷을 적용했던 바로 그 첫 번째 모델부터 우리는 필요에 따라 고객 및 파트너와 데이터를 공유하는 동시에 데이터를 안전하게 보호할 수 있는 도구를 제공하겠다는 목표를 가지고 버킷 정책, 서버 액세스 로깅, 버전 관리, API 로깅, 교차 리전 복제, 그리고 클라이언트서버 측 암호화 옵션 등의 지원을 추가해 왔습니다. 이와 함께 대규모 콘텐츠 검색, 분류 및 보호 도구인 Amazon Macie를 출시하여 인공 지능과 기계 학습의 장점도 가져왔습니다.

그리고 오늘, 드디어 S3에 다음 다섯 가지의 암호화 및 보안 기능을 새로 추가합니다.

  • 기본 암호화 – 이제 암호화되지 않은 객체를 거부하는 버킷 정책을 구성하지 않고도 버킷의 모든 객체를 암호화된 형식으로 저장하게 할 수 있습니다.
  • 권한 확인 – S3 콘솔에서는 공개 액세스가 가능한 각 S3 버킷 옆에 눈에 잘 띄는 표시가 나타납니다.
  • 교차 리전 복제 ACL 덮어쓰기 – AWS 계정 간에 객체를 복제할 때, 대상 계정에 대한 모든 액세스 권한을 제공하는 새 ACL을 해당 객체로 가져오도록 지정할 수 있습니다.
  • KMS를 사용한 교차 리전 복제 – 이제 AWS Key Management Service(KMS)로 관리하는 키를 사용해 암호화된 객체를 복제할 수 있습니다.
  • 세부 인벤토리 보고서 – 이제 S3 인벤토리 보고서에 각 객체의 암호화 상태도 표시됩니다. 또한 이 보고서 자체도 암호화가 가능합니다.

그럼 각 기능을 자세히 살펴보겠습니다.

기본 암호화
S3 객체를 위한 서버 측 암호화 옵션에는 S3 관리 키를 사용하는 SSE-S3, AWS KMS 관리 키를 사용하는 SSE-KMS, 사용자 관리 키를 사용하는 SSE-C, 이렇게 세 가지가 있습니다. 특히 유휴 상태에서도 반드시 암호화해야 한다는 규정 준수 요건을 충족해야 하는 고객을 비롯하여 일부 고객들은 새로 저장하는 모든 객체를 버킷 정책으로 암호화해 왔습니다. 이렇게 하면 요건을 준수하는 데 도움이 되기는 하지만, 암호화되지 않은 객체의 저장을 거부하는 것만으로는 완벽한 솔루션이라 할 수 없습니다.

이제 버킷 암호화 구성을 설치하여 버킷의 모든 객체를 암호화된 형태로 저장하도록 강제할 수 있습니다. 즉, 암호화되지 않은 객체가 S3에 입력되면 이 구성에 따라 암호화 사용을 지시하고, 해당 버킷에 지정된 암호화 옵션을 사용해 그 객체를 암호화하게 됩니다(PUT 요청으로 다른 옵션도 지정 가능).

다음은 버킷을 새로 만들 때 S3 콘솔을 사용하여 이 기능을 활성화하는 방법입니다. 평상시처럼 버킷의 이름을 입력하고 [Next]를 클릭합니다. 그런 다음 아래로 스크롤하여 [Default encryption]을 클릭합니다.

원하는 옵션을 선택하고 [Save]를 클릭합니다(AWS-KMS를 선택하면 KMS 키도 지정해야 함).

PUT 버킷 암호화 기능을 호출해서 이와 같이 변경할 수도 있습니다. 이 경우에는 SSE 알고리즘(SSE-S3 또는 SSE-KMS)을 지정해야 하고, 선택적으로 KMS 키를 참조할 수 있습니다.

이 기능을 구현할 때는 다음을 염두에 두십시오.

SigV4 – S3 REST API를 통해 버킷 정책에 액세스하려면 SigV4로 서명하고 SSL 연결을 이용해야 합니다.

버킷 정책 업데이트 – 암호화되지 않은 객체를 거부하는 기존의 버킷 정책을 살펴본 다음 주의해서 수정해야 합니다.

대량 사용 – SSE-KMS를 사용하고 초당 수백에서 수천 개의 객체를 업로드하는 경우, 암호화 및 암호 해독 작업에 대한 KMS 제한에 걸릴 수 있습니다. 이 경우 다음과 같이 지원 사례를 제출해 한도를 높여 달라고 요청하기만 하면 됩니다.

교차 리전 복제 – 암호화되지 않은 객체는 대상 버킷의 구성에 따라 암호화됩니다. 이렇게 암호화된 객체는 그 상태로 유지됩니다.

권한 확인
버킷 정책, 버킷 ACL 및 객체 ACL를 조합하면 버킷과 버킷 내 객체에 대한 액세스를 매우 세밀하게 제어할 수 있습니다. 사용자의 정책과 ACL을 합쳐 원하는 효과를 얻을 수 있도록 하기 위해, AWS는 최근 S3 버킷 보호를 위한 관리형 구성 규칙을 선보였습니다. 게시물에서 언급했듯이, 이러한 규칙에는 자동 형식 추론을 사용하기 위한 기술이 들어가 있습니다.

이제 바로 그 기본 기술을 사용하여 버킷 정책 및 ACL을 변경하자마자 그 효과를 확인할 수 있습니다. 퍼블릭 액세스를 위해 버킷을 여는 즉시 이러한 효과가 확인되기 때문에 자신 있게 변경할 수 있습니다.

다음은 S3 콘솔 기본 페이지의 모양입니다(편의상 액세스 열 기준으로 정렬).

버킷 중 하나로 들어가 살펴보면 퍼블릭 표시기도 나와 있습니다.

또한 어떤 권한 요소(ACL, 버킷 정책 또는 둘 다)가 퍼블릭 액세스를 지원하고 있는지도 확인할 수 있습니다.

교차 리전 복제 ACL 덮어쓰기
고객들은 흔히 미션 크리티컬 객체 및 데이터를 다른 AWS 계정의 대상 버킷으로 복사할 때 S3의 교차 리전 복제를 사용합니다. 이 복제 프로세스는 객체를 복사하는 한편 객체 ACL 및 그 객체와 연결된 모든 태그를 복사합니다.

여기에 전송 중 ACL를 교체하여 대상 버킷의 소유자에게 모든 액세스 권한을 부여할 수 있도록 함으로써 이 기능을 더욱 유용하게 만들었습니다. 이러한 변경 덕분에 소스 및 대상 데이터의 소유권을 AWS 계정 간에 나눌 수 있고, 이를 토대로 원본 객체와 그 복제본에 대한 소유권 스택을 별도로 관리할 수 있습니다.

복제 설정 시 이 기능을 활성화하려면 계정 ID 및 버킷 이름을 지정한 다음 [Save]를 클릭하여 다른 계정과 다른 리전에 있는 대상 버킷을 선택합니다.

그런 다음 [Change object ownership…]을 클릭합니다.

또한 대상 계정의 대상 버킷에 대한 키 정책을 보다 쉽게 설정할 수 있도록 했습니다. 따라서 계정에 로그인하여 원하는 버킷을 찾은 다음, [Management] 및 [Replication]을 차례로 클릭하고 [More] 메뉴에서 [Receive objects…]를 선택하기만 하면 됩니다.

소스 계정 ID를 입력하고, 버전 관리를 활성화하고, 정책을 살펴보고 적용한 다음 [Done]을 클릭합니다.

KMS를 사용한 교차 리전 복제
SSE-KMS로 암호화한 객체를 리전 간에 복제하는 데는 흥미로운 문제가 있는데, 오늘은 이 문제를 다루고자 합니다. KMS 키는 특정 리전에 고유한 키이기 때문에 암호화된 객체를 복제만 해서는 효과가 없습니다.

이제 교차 리전 복제를 설정할 때 대상 키를 선택할 수 있습니다. 복제 프로세스 중 암호화된 객체는 SSL 연결을 통해 대상으로 복제됩니다. 이어서 대상에서는 복제 구성에 지정된 KMS 마스터 키로 데이터 키를 암호화합니다. 이때 객체는 원래의 암호화된 형태를 끝까지 유지하며, 실제로 달라지는 것은 키가 들어 있는 봉투뿐입니다.

아래 그림은 복제 규칙을 설정할 때 이 기능을 활성화하는 방법을 보여줍니다.

단, 앞서 언급한 것처럼 이 기능을 많이 사용하려면 먼저 KMS 한도 증가를 요청해야 할 수 있습니다.

세부 인벤토리 보고서
마지막으로 역시 중요한 기능이라면, 이제 각 객체의 암호화 상태에 대한 정보를 담은 일별 또는 주별 S3 인벤토리 보고서를 요청할 수 있습니다.

보시다시피 보고서에 대한 SSE-S3 또는 SSE-KMS 암호화를 요청할 수도 있습니다.

정식 출시
모든 기능을 바로 사용할 수 있습니다! 이러한 기능은 무료로 제공되지만 KMS 호출, S3 스토리지, S3 요청 및 리전 간 데이터 전송에는 일반 요금이 청구됩니다.

Jeff;

이 글은 New Amazon S3 Encryption & Security Features의 한국어 버전입니다.

Stephen Orban – 엔터프라이즈 클라우드 혁신 센터(CCoE)의 인력 구성

“미래는 지식이 아닌 태도, 적성 그리고 감사에 의해 좌우된다.” – Debasish Mridha M.D.

 

여러분이 습득한 것들을 기반으로 작게 시작하고 반복하여 성장하는 것은 성공적인 엔터프라이즈 클라우드 여정에서 계속 되풀이되는 주제에 속합니다. 저는 제 게시물에서 이 주제를 자주 거론하고 있으며, 이와 동일한 반복적 사고를 여러분이 속한 조직의 클라우드 혁신 센터(CCoE)를 이끌어 갈 하나의 팀을 구성할 때 적용할 것을 권합니다.

여러분은 클라우드가 조직에 어떤 영향을 미칠 수 있는지에 대해 기꺼이 배우고 싶어 하며 흥미를 느끼는 소수의 미래 지향적인 사람들을 모집하는 일부터 시작하게 될 것입니다. 3~5명의 팀원만 있어도 눈에 띄는 차이가 즉시 생길 수 있습니다. 그럼 이제 매월 CCoE가 조직에 미치는 영향을 평가하고, 필요한 조정을 하고, 그러한 조정이 영향을 미치는 프로젝트의 수효와 규모가 증가할수록 팀을 확장해 보십시오.

해당 업무의 적임자를 찾았다는 것은 어떻게 알 수 있을까요?

임원들은 찾아야 할 인재의 유형과 그러한 인재들을 채용할 수 있는 장소/방법을 제게 물을 때가 많습니다. 저는 대체로 태도가 적성만큼이나 중요하다는 사실을 발견했습니다. 이는 어떤 대규모 조직이든 클라우드를 활용하는 데 필요한 인력을 이미 보유하고 있음을 의미합니다. 새로운 것을 배우는 것에 대해 진정한 열정과 흥미를 가진 인재들을 찾아보십시오. 담당 프로젝트에서 클라우드를 사용하는 데 열성적인 직원들은 여러분이 속한 조직 내에 많이 있을 것이며 그러한 직원들을 찾는 일은 결코 어렵지 않을 것입니다. 시장에서 채용된 인재로 팀을 증원하는 것은 좋은 일입니다. 다만 그런 생각을 실행에 옮기기까지 시간을 지체하지는 마십시오. 만약 모든 조직이 신입 팀원의 채용을 기다리기만 한다면 그러한 인재를 내부에서 직접 쉽게 발굴할 수 있는 경우에도 외부의 새로운 인재를 찾느라 업무상 불필요한 차질을 빚게 될 것입니다.

CCoE 팀의 구성원들은 다양한 역할과 배경을 가진 사람들로 구성하는 것이 가장 이상적입니다. 이러한 팀의 구성원으로는 애플리케이션 개발자, 시스템 관리자, 네트워크 엔지니어, 보안 실무자, IT 운영자 및 데이터베이스 관리자를 예로 들 수 있습니다. (다만 이에 국한할 필요는 없습니다.) 다양한 전문 기술 그룹을 하나로 모으면 다양한 시각을 가진 팀을 얻게 될 것이며 보다 완벽한 플랫폼을 구축하는 결과로 이어질 수 있습니다. 기업의 기존 제품 및 프로세스에 대한 팀의 조직적 지식은 여러분의 조직에 가장 적합한 클라우드 모범 사례를 만들고 관리하는 방법에 관한 의사 결정을 안내하는 데 도움이 될 것입니다.

대부분의 클라우드 서비스가 제공하는 “서비스화(as-a-service)” 모델 역시 교차 기능적 관점에 아주 적합합니다. 예를 들면, 많은 서버 및 데이터베이스 관리 업무들은 현재 자동으로 실행되며 소프트웨어를 통해 제어 가능합니다.서버 및 데이터베이스에서 애플리케이션을 최적화하는 방법을 아는 직원들이 여전히 필요하지만, 이러한 작업에는 자동화 코드를 작성하는 방법을 아는 사람이 도움이 될 것입니다.

이처럼 다양한 분야의 융합은 DevOps가 증가하게 된 배후 요인 중 하나이며, CCoE가 일반적으로 DevOps로 명명되고 DevOps 엔지니어와 같은 역할들이 CCoE를 담당하는 이유 중 하나이기도 합니다. “DevOps”와 “DevOps 엔지니어”는 매우 새로운 기술 용어에 속하지만 개념 자체는 지난 수십 년 동안 존재해왔다고 생각합니다. 오늘날 이러한 역할들을 맡는 사람들은 대부분 다양한 분야 및/또는 전문 분야에서 배출되고 있으며, 각자의 지평을 넓히고 더욱 다양한 가치를 그들이 소속된 조직에 전달하고자 합니다.

물론 모든 기업에서는 클라우드 챔피언들은 물론 변화를 싫어하는 집단도 함께 존재하게 될 것입니다. 주저하는 직원들을 더 많이 설득하기 위해서는 올바른 방향으로 움직이기만 하면 됩니다. 저는 CCoE 에 한두 명의 회의론자를 배치하여 이러한 시도를 한 일부 기업과 대화를 나눈 적이 있습니다. 많은 영향력을 행사하며 클라우드 전환 방향으로 이끌어가는 리더들이 여러분의 조직 내에 있다면, 그들을 CCoE 내부 또는 그 주변에 배치하여 클라우드 내에서의 빠른 가치 창출을그들의 성공과 연계시키는 방안도 고려해볼 수 있을 것입니다. 이러한 방법은 신중하게 관리할 필요가 있으며, 다만 저는 그것이 문화적 변화를 위한 능력을 배가시키는 요인으로 작용한다고 생각합니다. 회의론자들이 클라우드가 기업의 비즈니스와 자신의 경력에 어떤 도움을 줄 수 있는지에 대해 더 많이 알면 알수록, 조직이 나아갈 방향을 지키면서 조직 내 다른 구성원들로 하여금 이를 따르도록 독려할 가능성도 그만큼 높아집니다.

다음에 게시글에서는CCoE를 통해 모든 모범 사례들을 집중시킬 방법에 관하여 기업의 조직 내에서 CCoE가 보고할 부문은 어디인지를 다룰것입니다. 현재로서는 CCoE가 보고를 하는 부문이 CCoE가 받는 경영 지원보다 덜 중요하다는 점만언급할 것입니다. 기업의 CCoE는 영향력이 강한 변화를 일으킬 수 있도록 조직의 권력 구조 내에서 충분히 높은 위치에 있어야 합니다.

CCoE 인력을 배치한 경험은 어땠습니까? 팀을 돋보이게 하며 성공적으로 운영하기 위한 다른 전략이 있습니까? 있다면 꼭 들어보고 싶습니다.

 

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

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

AWS 최신 기능 모음 – Amazon RDS 사용자 인증, SES 데이터 추적 및 AWS 솔루션 업데이트 등

AWS의 새로 출시된 몇 가지 서비스와 기능을 따라잡기 위해, 이 게시물에서는 지난 여름부터 9월 말까지 출시된 몇 가지 멋진 서비스를 요약 정리하고자 합니다. 더 자세한 업데이트 내역은 AWS 신규 기능 업데이트 페이지를 참고하세요.

오늘 여러분께 소개할 새로운 서비스와 기능은 다음과 같습니다.

  • RDS MySQL 및 Amazon Aurora의 데이터베이스 사용자 인증을 위한 AWS IAM
  • Amazon SES 평판 대시보드
  • Amazon SES 확인 및 클릭 추적 지표
  • Solutions Builder 팀의 서버리스 이미지 핸들러
  • Solutions Builder 팀의 AWS Ops Automator

그럼 자세히 살펴보겠습니다.

RDS MySQL 및 Amazon Aurora의 데이터베이스 사용자 인증을 위한 AWS IAM

Amazon RDS 데이터베이스 인스턴스 및 클러스터에 대한 액세스를 AWS IAM으로 관리하고 싶지 않으셨습니까? 이제 그 소원이 이루어졌습니다. Amazon RDS에서 MySQL용 Amazon RDS 및 Amazon Aurora DB에 대한 데이터베이스 액세스를 IAM으로 관리하는 기능을 출시했습니다.

이 새로운 서비스 기능에서 가장 마음에 드는 부분은 시작하기가 정말 쉽다는 점입니다. IAM을 이용한 데이터베이스 사용자 인증을 활성화하려면 DB 인스턴스 또는 클러스터를 생성, 수정 또는 복원할 때 [Enable IAM DB Authentication] 확인란을 선택하면 됩니다. RDS 콘솔, AWS CLI 및/또는 Amazon RDS API를 사용해서 IAM에 액세스하도록 할 수 있습니다.

IAM 인증을 사용하도록 데이터베이스를 구성하면, 클라이언트 애플리케이션은 데이터베이스 엔진에 대해 자신을 인증할 때 IAM 보안 토큰 서비스에서 생성된 임시 보안 자격 증명을 제출합니다. 데이터베이스 엔진에 암호를 제시하는 대신 이러한 자격 증명을 사용하는 것입니다.

IAM으로 MySQL 및 Aurora에 대한 목표 권한 및 인증을 제공하는 자세한 방법은 Amazon RDS 사용 설명서에서 알아볼 수 있습니다.

Amazon SES 평판 대시보드

Amazon Simple Email Service 고객이 이메일 전송을 위한 모범 사례 지침을 활용할 수 있도록 이메일 전송 상태를 포괄적으로 보고해 주는 평판 대시보드가 출시되었다는 소식을 기쁜 마음으로 알려 드립니다. 이제 고객들은 전반적인 계정 상태, 전송 지표, 규정 준수 또는 시행 상태를 파악하여 전송 중인 이메일을 선제적으로 관리할 수 있습니다.

평판 대시보드는 다음과 같은 정보를 제공합니다.

  • 계정 상태: 계정 상태에 대한 설명입니다.
    • 정상 – 현재 계정에 영향을 주는 문제가 없습니다.
    • 관찰 – 계정이 관찰 상태입니다. 일시 중지 사태를 방지하기 위해 관찰을 유발한 문제를 해결해야 합니다.
    • 관찰 종료 결정 보류 중 – 계정이 관찰 상태입니다. Amazon SES 팀원이 해당 계정을 검토한 뒤 조치를 취해야 합니다.
    • 종료 – 계정이 종료되었습니다. Amazon SES를 사용해 이메일을 보낼 수 없습니다.
    • 종료 보류 중 – 계정이 관찰 상태이고 관찰 상태를 유발한 문제가 해결되지 않았습니다.
  • 반송 메일 발생률: 반송된 이메일의 비율과 반송률 상태에 대한 메시지입니다.
  • 불만 제기 비율: 수신자가 스팸으로 보고한 이메일의 비율과 불만 제기율에 대한 상태 메시지입니다.
  • 알림: 기타 계정 평판 문제에 대한 메시지입니다.

Amazon SES 확인 및 클릭 추적 지표

최근 Amazon SES에 추가된 또 한 가지 흥미로운 기능은 이메일 확인 및 클릭 추적 지표입니다. SES 고객은 이제 이메일 확인 및 클릭 추적 지표 기능으로 보낸 이메일의 확인 시점과 이메일 내 링크의 클릭 시점을 추적할 수 있습니다. 이 SES 기능을 사용하면 이메일 캠페인에 대한 참여도와 효과를 더욱 정확하게 추적할 수 있습니다.

이 기능은 어떻게 작동할까요?

이메일 확인 추적 기능을 사용하는 경우, SES에서는 사용자가 추적하도록 선택한 이메일에 투명한 작은 이미지를 추가합니다. 받는 사람이 이메일을 열어 보면 메일 애플리케이션 클라이언트가 앞서 언급한 추적 이미지를 로드하고, 이에 따라 Amazon SES에서 확인 추적 이벤트가 트리거됩니다. 이메일 클릭(링크) 추적의 경우 이메일 및/또는 이메일 템플릿에 들어 있는 링크가 사용자 지정 링크로 바뀝니다. 받는 사람이 이 사용자 지정 링크를 클릭하면 SES에 클릭 이벤트가 기록되고, 이메일 사용자는 사용자 지정 링크를 통해 원본 이메일의 링크 대상으로 리디렉션됩니다.

새로운 확인 추적 및 클릭 추적 기능을 사용하려면 SES에서 새로운 구성 집합을 생성하거나 기존 구성 집합을 변경하면 됩니다. 두 방법 중 하나를 선택한 다음, 확인 및 클릭 지표를 수신하기 위한 AWS 서비스로 Amazon SNS, Amazon CloudWatch 또는 Amazon Kinesis Firehose를 선택하십시오. 이제 전송할 모든 이메일에 대해 이러한 새 기능을 적용하는 새로운 구성 집합만 선택하면 됩니다.

AWS 솔루션: 서버리스 이미지 핸들러 및 AWS Ops Automator

AWS Solution Builder 팀은 AWS에서 애플리케이션 빌드 및 실행을 위해 일반적인 아키텍처 질문에 대한 답변을 쉽게 찾을 수 있도록 많은 노력을 기울이고 있습니다. 이러한 솔루션은 AWS Answers 페이지에서 찾을 수 있습니다. 올 가을 초 AWS Answers에 발표된 두 가지 새로운 솔루션은 서버리스 이미지 핸들러AWS Ops Automator입니다.
서버리스 이미지 핸들러AWS 클라우드의 이미지 취급 과정을 실시간으로 처리, 조작 및 최적화하는 고객을 위한 지원 솔루션으로 개발되었습니다. 이것은 캐싱을 위해 Amazon CloudFront를, 실시간 이미지 검색과 수정을 위해 AWS Lambda를, 이미지 저장을 위해 Amazon S3 버킷을 결합한 솔루션입니다. 또한 서버리스 이미지 핸들러는 이미지를 더 세밀하게 조작, 처리 및 최적화할 수 있도록 오픈 소스 이미지 처리 제품군인 Thumbor를 사용합니다.

AWS Ops Automator 솔루션의 자동 작업 프레임워크에서 시간 기반 트리거나 이벤트 기반 트리거를 사용하여 스냅샷 예약 등의 수작업을 자동화할 수 있습니다. 여기에는 작업 감사 추적, 로깅, 리소스 선택, 조정, 동시 처리, 작업 완료 전달 및 API 요청 재시도 등이 포함됩니다.

이 솔루션에는 다음 AWS 서비스가 포함됩니다.

  • AWS CloudFormation: 마이크로서비스 및 솔루션에서 생성한 작업 구성의 핵심 프레임워크를 시작하기 위한 템플릿
  • Amazon DynamoDB: 이벤트 트리거 및 리소스를 정의하기 위한 작업 구성 데이터와 작업 및 오류의 결과를 저장하는 테이블
  • Amazon CloudWatch Logs: 경고 및 오류 메시지 추적을 위한 로깅 기능 제공
  • Amazon SNS: 솔루션에서 로깅 정보를 보내는 구독자 이메일 주소로 관련 주제의 메시지 전송

즐겁게 탐구하고 코딩하시기 바랍니다.

Tara

이 글은 Just in Case You Missed It: Catching Up on Some Recent AWS Launches의 한국어 번역입니다.

Stephen Orban – 엔터프라이즈 클라우드 혁신 센터(CCoE)를 설립하는 방법

“내게 충분히 긴 지렛대와 지렛대를 놓을 받침점을 달라. 그러면 세상을 움직이겠다.” -Archimedes

 

지금까지 엔터프라이즈 클라우드 여정 시리즈에서는 임원의 역할 직원 교육실험 시간 부여, 그리고 파트너 참여 방법을 (다시) 고려하는 것이 얼마나 중요한 지 살펴봤습니다. 이 게시물에서는 그 다음 모범 사례로 구현 자체는 아마 가장 힘들지만 조직에서의 변화 창출에 관해서는 가장 효과가 큰 클라우드 혁신 센터(CCoE – Cloud Center of Excellence) 설립에 대해 소개합니다.

2012년, 저는 운 좋게도 Dow Jones의 CIO로 임명되었습니다. 당시 Dow Jones는 유서 깊은 123년 역사의 조직으로 강력한 브랜드, 풍부한 콘텐츠, 충성도 높은 고객 기반을 가지고 있었습니다. 제 일은 갈수록 경쟁이 치열해지는 환경에서 살아남고 운영 효율성을 개선하며 비용을 절감하기 위해 기술 조직의 업무 초점을 기술 개발로 전환하는 것이었습니다.

이런 목표를 달성하기 위해 끊임없이 전략을 개발하는 과정에서 우리는 비즈니스에 집중할 수 있도록 사내 인재 확충, 오픈 소스 활용, 클라우드 서비스 도입 등 여러 가지 지렛대를 활용했습니다. 하지만 우리가 내린 최고의 결정은 아마도 조직 전체에 클라우드 전략을 어떻게 구축하고 실행할지 규범화하기 위해 우리가 DevOps라고 불렀던 CCoE를 창설한 것이었습니다. 저는 일하는 동안 변화 관리 프로그램의 성공과 실패를 지켜보면서 조직에서 가장 중요한 프로그램에 대해 단일 소유권을 지닌 전담 팀을 두는 것이 빠르게 결과를 얻고 변화에 영향을 미치는 효과적 방법 중 하나라는 것을 알고 있었습니다. 제 엔터프라이즈 DevOps 시리즈에서는 이런 경험 몇 가지를 더 자세히 다루고 있습니다.

 

© Les Chatfield https://www.flickr.com/photos/elsie/

그 이후로 제가 만나 본 기업 중 여정에서 유의미한 발전을 이뤄낸 기업들은 하나같이 모범 사례, 프레임워크, 진화하는 기술 운영 거버넌스의 창출, 전파, 제도화를 전담하는 팀을 두고 있었으며, 이러한 구현에서 클라우드의 활용은 점점 늘어나고 있습니다. 이 CCoE 팀은 소규모 조직으로 시작하여 기업의 규모에 맞게 클라우드 기술을 구현할 방법에 대한 관점을 개발하며, 제대로 구현될 경우, 기술이 비즈니스에 기여하는 방식을 혁신하는 지렛대 받침점이 될 수 있습니다.

다음 몇몇 게시물에서는 엔터프라이즈가 다음 요소를 통해 이를 수행하는 방법을 살펴보겠습니다.

팀 구축

다양한 직업적 배경을 가진 3명에서 5명 정도의 팀을 꾸리는 것이 좋습니다. 개발자, 시스템 관리자, 네트워크 엔지니어, IT 운영 및 데이터베이스 관리자를 찾으십시오. 원칙적으로 이들은 생각이 열려 있고 현대 기술과 클라우드 서비스를 활용하여 일하는 방식을 바꾸고 조직을 미래로 이끌 방법을 고민하는 사람들이어야 합니다. 경험이 일천한 직원을 합류시키는 것을 꺼리지 마십시오. 태도가 능력만큼 중요할 수 있으며, 필요한 인재는 이미 조직에 있을 수 있습니다.

팀의 책임 범위 설정(및 확장)

CCoE는 조직의 나머지 부분이 클라우드에 시스템을 구현할 때 (또는 시스템을 이전할 때) 활용하는 모범 사례, 거버넌스, 프레임워크 구축을 책임져야 합니다. 역할과 권한, 비용 거버넌스, 모니터링, 사고 관리, 하이브리드 아키텍처, 보안 모델 등 기본부터 시작하십시오.

시간이 지나면서 이러한 책임은 복수계정 관리, “골든” 이미지 관리, 자산 관리, 사업 단위 요금상환, 재사용 가능한 참조 아키텍처 등을 망라하는 수준까지 발전할 것입니다. 분석 불능 상태에 빠지지 않도록 하십시오. 실무 경험이 쌓이면서 역량은 자연스럽게 발전시킬 수 있습니다.

팀을 다른 모범 사례에 연계

제가 글에 썼던 모든 모범 사례는 상호 의존적입니다. CCoE가 성공하기 위해서는 경영진의 파격적 지원을 확보하고, CCoE 방법에 대해 조직을 교육하며, 경쟁력을 유지하기 위해 실험을 받아들이고, 환경에 가장 좋은 도구와 파트너를 늘 파악하며, 조직의 하이브리드 아키텍처를 소유하고, 클라우드 우선 전략에서 핵심 플레이어가 되어야 합니다.

이 각각의 주제는 앞으로 몇 주에 걸쳐 자세히 살펴볼 계획입니다. 공유하고 싶은 경험이 있거나 시리즈에서 앞으로 다루기를 바라는 분야가 있다면 알려 주십시오!

 

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

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

Amazon Redshift, 비용 최적 고밀도 컴퓨팅(DC2) 노드 활용하기

Amazon Redshift를 사용하면 엑사바이트 규모의 데이터를 빠르고 쉽고 비용 효율적으로 분석할 수 있습니다. 이 솔루션은 병렬 실행, 압축된 컬럼 방식 스토리지, 종단 간 암호화 등과 같은 고급 데이터 웨어하우징 기능을 종합 관리형 서비스로 제공합니다. 비용은 TB당 연간 $1,000 미만입니다. Amazon Redshift Spectrum을 사용하면 Amazon S3에서 엑사바이트 규모의 비정형 데이터에 대해 SQL 쿼리를 직접 실행할 수 있습니다. 비용은 스캔 용량 기준 TB당 $5입니다.

현재 이전 세대 DC1과 동일한 가격에 새로운 2세대 Dense Compute(DC2) 노드를 지원하여 DC(Dense Compute) 제품군을 더 빠르고 비용 효율적으로 개선하고 있습니다. DC2는 지연 시간이 짧고 처리량은 많아 까다로운 데이터 웨어하우징 워크로드를 위해 설계되었습니다. DC2는 강력한 Intel E5-2686 v4(Broadwell) CPU와 빠른 DDR4 메모리, 그리고 NVMe 기반의 SSD(Solid State Disk)를 사용합니다.

특히 DC2 노드에서 더 좋은 CPU와 네트워크, 디스크를 활용하도록 Amazon Redshift를 조정한 결과, 같은 가격에 DC1의 최대 두 배에 달하는 성능을 발휘합니다. DC2.8xlarge 인스턴스는 이제 데이터 슬라이스당 두 배의 메모리를 제공하며, 최적화된 스토리지 레이아웃으로 스토리지 사용률을 30%나 높였습니다.

고객 활용사례

급성장 중인 스타트업부터 Fortune 100대 기업까지 굴지의 여러 고객들이 새로운 DC2 노드 유형을 미리 살펴보았습니다. 이들의 테스트에서 DC2는 DC1에 비해 최대 두 배에 달하는 성능을 발휘했습니다. 고객 프리뷰 결과, DC1과 동일한 비용에 ETL(추출, 변환, 로드) 작업 속도, 쿼리 처리량, 동시성, 보고 속도, 데이터 통찰 시간 등이 모두 향상되었습니다. 또한 DC2.8xlarge 고객의 경우 최적화된 스토리지 형식 덕분에 데이터베이스가 차지하는 디스크 공간이 최대 30%나 줄어 비용을 절감할 수 있었습니다.

아메리카 지역에서 가장 빠르게 성장하는 민간 기업 중 하나인 4Cite Marketing에서는 Amazon Redshift를 사용하여 고객 데이터를 분석하고 소매업체를 위한 맞춤형 제품을 추천합니다. “Amazon Redshift의 새로운 DC2 노드가 100% 향상된 성능을 발휘한 덕분에 소매업체에 더 빠른 분석 정보를 더 경제적으로 제공함으로써 매출이 점점 증가하고 있다”고 4Cite의 Jim Finnerty 제품 담당 수석 부사장은 말합니다.

브랜드 보호 및 규정 준수 업체인 시애틀의 BrandVerity는 온라인 브랜드, 상표 및 규정 준수 침해를 모니터링하고 감지하여 문제를 완화하는 솔루션을 제공합니다. “DC2 노드로 Redshift Spectrum 쿼리를 실행하자 성능이 70%나 높아졌습니다. 그 결과 훨씬 더 많은 고객 데이터를 분석하고, 훨씬 더 빠르게 결과를 제공할 수 있게 되었습니다.” BrandVerity의 책임 소프트웨어 엔지니어인 김현준 씨가 말합니다.

핀란드 최대의 통신 그룹이자 핀란드 최대의 케이블 방송사 겸 유료 TV 공급자로 손꼽히는 DNA Plc의 Jarno Kartela 분석 책임자 겸 수석 데이터 과학자 역시 “Amazon Redshift는 운영 및 마케팅 자동화 도구의 핵심”이라고 주장합니다. “Amazon Redshift의 DC2 노드로 바꾼 결과 52%의 성능 향상을 실현했습니다. 지금은 쿼리 시간이 절반으로 줄었고, 분석 및 마케팅 자동화 고객들에게 강화된 분석 역량과 더 빠른 통찰력을 제공할 수 있습니다.”

고객 성공 사례 페이지에서 고객들의 경험담을 읽어 보십시오.

시작하기

시작 안내서에 따라 새 노드 유형에 도전해 보십시오. Amazon Redshift 콘솔에서 dc2.large 또는 dc2.8xlarge를 선택하면 됩니다.

DC1.large Amazon Redshift 클러스터가 있다면 기존 스냅샷을 사용하여 새 DC2.large 클러스터로 복원할 수 있습니다. DS2.xlarge, DS2.8xlarge 또는 DC1.8xlarge Amazon Redshift 클러스터에서 마이그레이션할 때는 크기 조정 작업을 이용하여 데이터를 새 DC2 클러스터로 옮기면 됩니다. 자세한 내용은 Clusters and Nodes in Amazon Redshift를 참조하십시오.

최신 Amazon Redshift 기능 발표 알림을 받으려면 새로운 기능 페이지를 선택하고 RSS 피드를 구독하시기바랍니다.

이 글은 AWS Big Data 블로그의 Amazon Redshift Dense Compute (DC2) Nodes Deliver Twice the Performance as DC1 at the Same Price의 한국어 번역입니다.

Amazon EC2 차세대 컴퓨팅 최적화 C5 인스턴스 출시

수년 동안 우리는 고객에게 최상의 네트워킹, 스토리지 및 컴퓨팅 성능을 제공하기 위해 끊임없이 노력해 왔으며 AWS에 의해 설계되고 구축 된 전용 하드웨어로 다양한 유형의 작업을 오프로드하는 데 오랜 기간 집중했습니다. 오늘 새로운 Amazon EC2 C5 인스턴스 타입을 추가하여, 최신 세대의 하드웨어 오프로드를 통합하며 하드웨어와 함께 새로운 하이퍼 바이저를 추가하여 했습니다.

EC2 C5 인스턴스 타입 출시
EC2 C5 인스턴스는 Amazon EC2의 차세대 컴퓨팅 최적화 인스턴스로, 3.0GHz Intel® Xeon® Scalable 프로세서(Skylake)로 구동됩니다. C5 인스턴스는 새로운 경량 하이퍼바이저를 사용하여 빌드되며, 이 하이퍼바이저가 고객의 인스턴스에 거의 모든 컴퓨팅 및 메모리 리소스를 제공합니다. 그 결과, C5 인스턴스는 EC2 제품군에서 최상의 가격 대 컴퓨팅 성능 비율을 자랑합니다.

C5 인스턴스의 가격 대 성능비는 C4 인스턴스에 비해 25% 개선되었고 일부 애플리케이션에서는 50% 이상 개선되었습니다. C5 인스턴스는 배치 처리, 분산 분석, 고성능 컴퓨팅(HPC), 머신/딥 러닝 추론, 광고 서비스, 확장성이 높은 멀티플레이어 게임, 비디오 인코딩 등 컴퓨팅 집약적 워크로드를 실행하는 데 이상적입니다.

C5 인스턴스는 6가지 크기로 이용 가능하며, 고객이 효과적으로 워크로드를 병합할 수 있도록 72개 vCPU 및 144GiB 메모리를 제공하는 더 큰 크기의 c5.18xlarge를 새로 출시했습니다.

인스턴스 타입 vCPUs
RAM
EBS 대역폭
네트워크 대역폭
c5.large 2 4 GiB Up to 2.25 Gbps Up to 10 Gbps
c5.xlarge 4 8 GiB Up to 2.25 Gbps Up to 10 Gbps
c5.2xlarge 8 16 GiB Up to 2.25 Gbps Up to 10 Gbps
c5.4xlarge 16 32 GiB 2.25 Gbps Up to 10 Gbps
c5.9xlarge 36 72 GiB 4.5 Gbps 10 Gbps
c5.18xlarge 72 144 GiB 9 Gbps 25 Gbps

차세대 Elastic Network Adapter(ENA) 및 NVM Express(NVMe) 기술이 적용되어 C5 인스턴스는 네트워킹 및 Amazon Elastic Block Storage(Amazon EBS)를 위한 높은 처리량, 낮은 지연 시간 인터페이스를 제공합니다. C5 인스턴스는 최대 25Gbps의 네트워크 대역폭과 최대 9Gbps의 Amazon EBS 대역폭을 제공합니다. 또한 C5 인스턴스는 더 작은 인스턴스 크기에서 월등히 높은 네트워킹 및 Amazon EBS 성능을 자랑합니다. 새로운 Intel Advanced Vector Extensions 512(AVX-512) 명령 집합을 지원하여 이전 세대 C4 인스턴스에 비해 사이클당 코어별 FLOPS가 최대 2배에 달합니다.

정식 출시
C5 인스턴스는 미국 동부, 미국 서부 및 EU에서 온디맨드, 예약 및 스팟 인스턴스로 제공됩니다. 자세히 알아보려면 Amazon EC2 요금 페이지를 참조하십시오.

Jeff;