Amazon Web Services 한국 블로그

Stephen Orban – 고객 서비스가 엔터프라이즈 DevOps의 핵심인 두 가지 이유

“고객은 그들을 향한 우리의 관심이 느껴질 때 우리의 지식에 관심을 갖게 된다.” -Damon Richards

 

고객 서비스는 DevOps 시리즈 소개에서 간략히 언급한 것처럼, DevOps 문화를 구현할 때 조직에게권하는 세 가지 원칙 중 하나입니다.

오늘날의 세상은 기술 솔루션으로 가득하고, 어떠한 요구에도 대응가능한 다양한 옵션들이 마련되어 있습니다.기술 솔루션을 제공하는 사람으로서 비즈니스 성공이란 훌륭한 제품을 제공하는 것뿐만 아니라 뛰어난 고객 서비스를 제공하는 것을 의미합니다. 고객 서비스가 좋을수록 고객이 경쟁업체의 솔루션을 찾게 될 가능성이 줄어들게 될 것입니다.

기존의 전통적인 사고방식에서 고객이란 Amazon.com의 구매자나 AWS를 사용하는 기업들 같이 여러분의 제품과 서비스를 구매하는 사람들을 의미했습니다.

그러나 엔터프라이즈 IT에서 고객이란 협력하는 사람을 의미하는 경우가 많습니다. 다양한 기술을 통해 자신의 업무를 처리해내는 사람이라면 누구나 내부 이해관계자가 될 수 있습니다. 다른 부서(마케팅, 영업 등)나 때로는 다른 기술자가 여기에 해당될 수 있습니다.

내부 DevOps 조직의 제품 및 서비스를 소비하는 사람은 누구일까요? 물론 이 질문에 대한 대답은 때에 따라 다를 수 있지만 많은 경우 애플리케이션 개발자 및 회사 내에 있는 타 기술 팀을 의미합니다. 왜냐하면 중앙 집중식 DevOps를 도입하게 되는 큰 이유중 하나가 제품 개발 시간을 단축할 수 있다는 것이기 때문입니다. 여러 부서 간에 공동 작업을 수행하고 의견을 공유하는 중앙 집중식 팀은 독자적으로 과제에 대해 고민하는 팀보다는 훨씬 요구 사항을 잘 예측하고 더 나은 고객 서비스를 제공할 수 있을 것입니다.

고객 서비스를 조직의 최우선으로 두어야 할 두 가지 이유는 다음과 같습니다.

1. 고객 서비스 중심 방침은 IT 브랜드를 발전시킨다

20년 전에는 엔터프라이즈 기술 요구 사항에 대해 IT를 통해서만 서비스를 제공했습니다. 기술은 복잡한 것으로 인식되어 기술을 잘 사용하려면 엄청난 전문 지식이 필요한 것이라고 생각하기도 했습니다. 팀 전체가 구축한 것을 직접 실행할 수 있는 DevOps와는 달리, 기존의 조직은 IT를 구매하고 배포하는 방법을 이해하는 소수의 사람들에게 이를 집중해야 한다는 편견을 가지고 있었습니다. 이로 인해 IT의 고객들, 즉 조직의 나머지 팀들은 IT 관련 요구 사항을 충족할 수 있는 방법이 제한되었습니다.

하지만 지금은 고객의 문제를 해결해주는 제품과 솔루션이 너무나 많습니다. 그리고 기술은 지속적으로  상용화되고 있습니다. 이전에 비해 컴퓨터, 스마트폰, 웹 사이트, 앱을 사용하는 사람들이 늘어났고 가정과 직장에서 누리는 선택의 폭이 넓어졌습니다. 이러한 추세로 인해 기술 선도업체들이 고객 서비스를 바라보는 방식, 특히 조직 내부에서 보는 방식이 바뀌고 있습니다.

경험상 누구나 작업을 실행하는 더 쉬운 방법을 찾게 되면 그 방법을 사용할 가능성이 높습니다. 만약 IT에서 필요한 서비스를 얻지 못하면 다른 곳에서 그 서비스를 찾으려고 할 것입니다. IT가 자체 버전을 원하는 만큼 빠르게 제공하지 않거나 못하면 뉴스룸에서는 편집 소프트웨어를 스스로 다운로드할지 모릅니다. HR에서는 내부 캘린더 시스템 외에 다른 스케줄링 툴을 찾아다닐지 모릅니다. 마케팅은 타사에서 브랜드 웹 사이트를 다시 제작할 수도 있습니다. 업계는 이것을 “Shadow IT”라고 합니다. 이 때문에 대규모 IT 환경을 효율적으로 관리하고 안정적으로 운영하기가 훨씬 어려워질 수 있습니다. 현실에서는 내부 이해관계자가 IT를 통해 원하는 것을 얻는 방법을 모르거나 전달받는 사항에 만족하지 못하기 때문에 “Shadow IT”가 존재합니다.

고객 서비스 중심 방침을 유지하는 중앙 집중식 DevOps 조직은 이러한 시나리오를 피할 수 있을 가능성이 높습니다. 처음부터 고객을 염두에 둔다면 고객의 요구 사항과 우려 사항에 공감하고 요구 사항에 대한 솔루션이 회사 전체에 얼마나 잘 부합하는지 확인할 수 있을 것입니다. “그걸 작업에 쓰면 안 됩니다”라고 말하는 대신 “어떤일을 하려고 하고 어떻게 하면 제가 효율적으로 도와드릴 수 있을까요? ” 라고 질문하는 것이 좋습니다. 애플리케이션 팀이 DevOps 팀이 제공할 수 없는 것에 대한 차선책을 구현할 때마다 조직은 그런 일이 발생한 경위와 원인을 알아내고 앞으로 어떻게 개선할 것인지 결정할 기회가 생기는 것입니다. 앞으로 차선책을 덜 필요로 하게 만드는 방법이 있을까요? 아마도 그 답은 “없다”일 것입니다. 많은 경우 차선책을 받아들여도 괜찮지만 조직에게 문제에 의도적으로 접근해볼것을 권합니다. 이를 통해 IT는 마찰이 아닌조력자로 작용할수 있습니다. 이것이 고객을 여러분과 함께 협력하게 만드는 유도책이 될것입니다.

2. 고객 서비스 중심 방침은 경력에도 도움이 된다

애플리케이션 팀이 구축한 것을 직접 실행하는 DevOps 모델에서는 오너십과 고객 서비스가 연장선상에  있습니다. 제가 그동안 근무했던 모든 회사에서는 오너십을 핵심 성능 지표로 사용했었습니다. 오너십은  Bloomberg의 핵심 가치 중 하나였고, Dow Jones의 IT의 핵심 가치였으며 Amazon의 리더십 원칙 중 하나입니다.

오너십이란 모든 제품 또는 서비스 담당자는 제품이나 서비스를 자신의 비즈니스처럼 다루어야 한다는 것을 의미합니다. 제품과 서비스는 웹 사이트, 모바일 애플리케이션, 회사 이메일 서비스, 데스크톱 지원, 보안 도구, CMS 또는 고객에게 제공하는 그 무엇이 될 수 있고, 다양한 형태를 취할 수 있습니다.

오너십은 제품을 감독하는 담당자에게 직접 책임과 평판을 부여하기 때문에 고객 서비스를 개선하게 됩니다. 그러면 이 담당자는 다른 사람의 의견을 듣고, 고객의 대안을 파악하고 제품의 성능에 대해 지속적으로 관심을 가질 동기가 생기게 됩니다. 제품 책임자는 문제가 발생할 때 그저 “책임을 전가”할 수 없기 때문입니다. 이들은 결단력을 통해 문제를 식별하고 필요할 때 도움을 받을 책임이 있습니다.

이 부분에서 개인의 경력에도 도움을 받게 됩니다. 제품에 대해 적극적으로 주인 의식을 가지고 고객과 건전한 관계를 쌓는 사람은 회사와 관련하여 안정성과 신뢰성이라는 평판을 얻게 됩니다.

지금까지 말씀드린 내용은 고객 서비스가 매우 중요한 크고 복잡한 조직 내부에서, 특히 DevOps를 고려할 때 고객 서비스가 중요한 이유 중 두 가지일 뿐입니다.여러분이 다른 이유들을 알게된다면 들려주십시오.

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

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

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

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

 

AWS코리아 블로그

AWS코리아 발표 자료

AWS코리아 동영상

AWS 추천 콘텐츠

AWS 최신 뉴스

AWS 제품별 블로그(영문)

AWS 주요 행사 온라인 세미나

AWS 마케팅 행사

 

AWS 공인 교육 일정

 

AWSKRUG 소모임

AWS 주요 파트너사 블로

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

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

– AWS코리아 마케팅팀

Amazon Redshift Spectrum에 대한 10가지 모범 사례

지난 4월 Amazon Redshift Spectrum 출시 이후, 이번 주에는 서울 리전에도 출시하였습니다. 이 글에서는 한국 고객 분들이 Redshift Specturm을 더 잘 활용하기 위한 10가지 모범 사례를 전달해 드립니다.

Amazon Redshift Spectrum 을 사용하면 Amazon S3에 저장된 데이터에 대해 Amazon Redshif SQL 쿼리를 실행할 수 있습니다.  즉, Amazon Redshift의 분석 기능을 데이터웨어 하우스(DW) 내 로컬 디스크에 저장된 데이터 이상으로 확장 할 수 있습니다.  시간이 많이 걸리는 추출, 전송 및 로드 (ETL) 프로세스를 거치지 않고 Amazon S3내의 “데이터  레이크(Data Lake)”에서 방대한 양의 데이터를 바로 쿼리 할 수 있으며, 정교한 쿼리 최적화를 적용하고 수천 노드의 프로세싱을 확장하여 빠른 성능을 제공합니다.이 글에서는 Amazon Redshift Spectrum에 대한 중요한 모범 사례를 몇 가지 분류를 통해 알려 드리고자 하며, 주로 Amazon Redshift 고객과의 많은 대화와 직접 진행한 프로젝트에서 나온 것들입니다.

언제 Amazon Redshift를 선택하나요?

Amazon Athena와 Amazon Redshift Spectrum를 언제 사용하는지 궁금해 하는 고객들이 있습니다.

Amazon Athena는 SQL을 사용하여 Amazon S3에 저장된 데이터에 대해 대화 형 애드훅(Ad-hoc) 쿼리를 실행하는 경우에 유용합니다. Amazon Athena의 서버리스 아키텍처는 쿼리를 수행하기 위해 클러스터를 미리 프로비저닝하지 않아도 됩니다. 각 쿼리에서 스캔 한 S3 데이터의 양에 따라 요금이 부과됩니다. 데이터를 압축, 분할 또는 컬럼 형식으로 변환하여 비용을 크게 절감하고 성능을 향상시킬 수 있으므로 Amazon Athena가 쿼리를 실행하기 위해 스캔해야 하는 데이터 양이 줄어 듭니다. JDBC를 사용하는 모든 주요 BI 도구 및 SQL 클라이언트는 Amazon Athena에서 사용할 수 있습니다. 쉬운 시각화를 위해 Amazon QuickSight를 사용할 수도 있습니다.

만약, 대용량의 구조화 된 데이터 집합에 대해서는 Amazon Redshift를 사용하는 것이 좋습니다. Redshift Spectrum은 원하는 형식으로 원하는 위치에 자유롭게 데이터를 저장할 수 있게 해주며, 필요시 언제든지 처리 할 수 ​​있으며, 클러스터 확장에 대해 걱정할 필요가 없습니다. 이를 통해 스토리지를 분리하고 계산할 수 있으므로 각 스토리지를 독립적으로 확장 할 수 있습니다. 동일한 Amazon S3 데이터 레이크에 대해 여러 개의 Amazon Redshift 클러스터를 실행하여 대량으로 동시성을 구현할 수도 있습니다. 즉, 자동으로 수천 개의 인스턴스로 확장되기 때문에, 쿼리가 테라 바이트, 페타 바이트 또는 엑사 바이트를 처리하든 상관없이 신속하게 실행됩니다. 이를 염두하시고 판단하시면 됩니다.

모범 사례 테스트 환경 설정

Amazon Redshift Spectrum을 시작하기 위한 전제 조건 및 단계에 대한 정보는 Redshift Spectrum 시작하기 문서를 참조하십시오.

모든 데이터 세트를 사용하여 테스트를 수행하여, 이 글에서 설명한 모범 사례를 검증 할 수 있습니다. 한 가지 중요한 요구 사항은 가장 큰 테이블의 S3 파일이 CSV 형식, 분할 Parquet, 비분할 Parquet 형식 등 세 가지 데이터 형식이어야 합니다. 한 파일 형식에서 다른 파일 형식으로 변환하는 방법은 아래 방법을 참고하시기 바랍니다.

외부 스키마 만들기
Amazon Athena 데이터 카탈로그를 메타 데이터 저장소로 사용하고, 다음과 같이 “spectrum”이라는 외부 스키마를 만듭니다.

create external schema spectrum 
from data catalog 
database 'spectrumdb' 
iam_role 'arn:aws:iam::<AWS_ACCOUNT_ID>:role/aod-redshift-role'
create external database if not exists;

Redshift 클러스터와 Amazon S3의 데이터 파일은 동일한 AWS 리전에 있어야합니다. Redshift 클러스터에는 Amazon Athena의 외부 데이터 카탈로그 및 Amazon S3의 데이터 파일에 액세스 할 수 있는 권한이 필요합니다. 클러스터에 연결된 AWS Identity and Access Management (IAM) 역할 (예 : aod-redshift-role)을 참조하여 해당 권한을 제공합니다. 자세한 내용은 Amazon Redshift 용 IAM 역할 만들기를 참조하십시오.

외부 테이블 정의
Partwise Parquet 파일을 사용하는 Amazon Redshift Spectrum 외부 테이블과 CSV 파일을 사용하는 다른 외부 테이블은 다음과 같이 정의됩니다.

CREATE  external table spectrum.LINEITEM_PART_PARQ ( 
 L_ORDERKEY BIGINT,
 L_PARTKEY BIGINT,
 L_SUPPKEY BIGINT,
 L_LINENUMBER INT,
 L_QUANTITY DECIMAL(12,2),
 L_EXTENDEDPRICE DECIMAL(12,2),
 L_DISCOUNT DECIMAL(12,2),
 L_TAX DECIMAL(12,2),
 L_RETURNFLAG VARCHAR(128),
 L_LINESTATUS VARCHAR(128),
 L_COMMITDATE VARCHAR(128),
 L_RECEIPTDATE VARCHAR(128),
 L_SHIPINSTRUCT VARCHAR(128),
 L_SHIPMODE VARCHAR(128),
 L_COMMENT VARCHAR(128))
partitioned by (L_SHIPDATE VARCHAR(128))
stored as PARQUET
location 's3://<your-bucket>/<xyz>/lineitem_partition/'
;

CREATE  external table spectrum.LINEITEM_CSV ( 
 L_ORDERKEY BIGINT,
 L_PARTKEY INT,
 L_SUPPKEY INT,
 L_LINENUMBER INT,
 L_QUANTITY DECIMAL(12,2),
 L_EXTENDEDPRICE DECIMAL(12,2),
 L_DISCOUNT DECIMAL(12,2),
 L_TAX DECIMAL(12,2),
 L_RETURNFLAG VARCHAR(128),
 L_LINESTATUS VARCHAR(128),
 L_SHIPDATE VARCHAR(128) ,
 L_COMMITDATE VARCHAR(128),
 L_RECEIPTDATE VARCHAR(128),
 L_SHIPINSTRUCT VARCHAR(128),
 L_SHIPMODE VARCHAR(128),
 L_COMMENT VARCHAR(128))
row format delimited
fields terminated by '|'
stored as textfile
location 's3://<your-bucket>/<xyz>/lineitem_csv/'

데이터 쿼리
요약하면, Amazon Redshift Spectrum은 외부 테이블을 사용하여 Amazon S3에 저장된 데이터를 쿼리합니다. 다른 Amazon Redshift 테이블과 동일한 SELECT 구문을 사용하여 외부 테이블을 쿼리 할 수 있습니다. 다만, 읽기 전용이므로 외부 테이블에 쓸 수 없습니다.

먼저 외부 데이터베이스를 참조하는 외부 스키마를 작성합니다. 외부 스키마는 Amazon Athena 데이터 카탈로그 또는 Amazon EMR과 같은 Apache Hive 메타 스토어에 있을 수 있습니다. 그런 다음 외부 스키마를 사용하여 Amazon Redshift에서 외부 테이블을 생성합니다. 테이블을 생성하고 Amazon Redshift로 읽어 올 필요 없이 테이블 이름 앞에 스키마 이름을 붙임으로써 SELECT 문에서 외부 테이블을 참조하면 됩니다.

외부 스키마는 외부 데이터 카탈로그의 데이터베이스를 참조합니다. 이를 위해서는 클러스터를 대신하여 Amazon S3 및 Amazon Athena에 액세스 할 수 있는 권한을 부여하는 IAM 역할이 필요합니다.

Amazon Redshift Spectrum을 사용하여 테스트를 수행하려면, 다음 두 가지 쿼리를 시작하는 것이 좋습니다.

QUERY 1:

SELECT l_returnflag,
       l_linestatus,
       sum(l_quantity) as sum_qty,
       sum(l_extendedprice) as sum_base_price,
       sum(l_extendedprice*(1-l_discount)) as sum_disc_price,
       sum(l_extendedprice*(1-l_discount)*(1+l_tax)) as sum_charge,
       avg(l_quantity) as avg_qty,
       avg(l_extendedprice) as avg_price,
       avg(l_discount) as avg_disc,
       count(*) as count_order
FROM lineitem
WHERE l_shipdate <= '1998-09-01'
GROUP BY l_returnflag, l_linestatus
ORDER BY l_returnflag, l_linestatus;

이 쿼리에는 하나의 테이블 만 포함되며 Amazon Redshift Spectrum 레이어에서 제공하는 추가 처리 성능을 강조 표시하는 데 사용할 수 있습니다.

QUERY 2:

SELECT  l_orderkey,
       sum(l_extendedprice * (1 - l_discount)) as revenue,
       o_orderdate,
       o_shippriority
FROM	customer, orders, lineitem
WHERE	c_mktsegment = 'BUILDING'
       AND c_custkey = o_custkey
       AND l_orderkey = o_orderkey
       AND o_orderdate < date '1995-03-15'
       AND l_shipdate > date '1995-03-15'
GROUP BY l_orderkey, o_orderdate, o_shippriority
ORDER BY revenue desc, o_orderdate
LIMIT 20;

이 쿼리에는 3 개의 테이블이 결합되어 Amazon Redshift Spectrum의 성능과 기본 Amazon Redshift의 성능을 비교하는 데 매우 유용합니다.

동시성 모범 사례

아래 모범 사례는 Amazon Redshift Spectrum을 사용하여 동시 작업 부하 성능을 최적화하는 데 도움이됩니다.

1. 스캔 집약적인 동시 작업 부하 향상
Amazon Redshift Spectrum은 클러스터와 독립적 인 전용 Amazon Redshift 서버에 있습니다. 조건부 필터링 및 집계와 같은 많은 컴퓨팅 집약적인 작업을 Redshift Spectrum에서 처리하기 때문에, 쿼리를 위한 클러스터 처리 용량을 훨씬 적게 사용합니다. 또한 Amazon Redshift Spectrum은 지능적으로 확장되기 때문에 쿼리 요구를 기반으로 잠재적으로 수천 개의 인스턴스를 사용하여 대규모 병렬 처리 (MPP)를 활용할 수 있습니다. 동시 스캔 및 / 또는 집약적 인 작업 부하의 일부 사용 사례의 경우 Amazon Redshift Spectrum이 평균 Amazon Redshift보다 우수한 성능을 보입니다.

모든 MPP 시스템에서 가장 자원이 많이 드는 과정이 바로 데이터 로딩 프로세스입니다. 이는 컴퓨팅 뿐 아니라 MVCC (Multiversion Concurrency Control)를 통해 테이블을 잠그는 것과 같은 능동적인 분석 쿼리와 경쟁하기 때문입니다. 그러나, Amazon Redshift Spectrum을 사용하여 Amazon S3에 작성한 새 외부 파일에 파일을 추가 한 다음 메타 데이터를 새 파티션으로 포함하도록 업데이트하면 Amazon Redshift 클러스터에서 이러한 부하가 제거됩니다. 이것은 동시성에 즉각적이고 직접적인 긍정적 영향을 주게 됩니다.

2. 다수 Redshift 온 디멘드 클러스터를 통한 동시성 확장
Redshift Spectrum은 Amazon S3에 데이터를 저장합니다. Amazon S3에 여러 Amazon Redshift 클러스터에서 접근하여 동시 작업 로드 성능을 향상 시킵니다. 일반적인 Redshift 고객은 업무 패턴과 관련 없이 많은 동시적 쿼리 작업 부하를 가지게 되는데,  Redshift Spectrum 이 나오기 전에는 동시성을 처리하기 위해 스냅샷을 복원하여 여러 개의 “읽기 전용”  클러스터를 만들어 두어야 했습니다. 이 접근법의 문제점은 수 테라 바이트의 데이터가 있는 DW의 경우 복원 프로세스가 오래 걸릴 수 있어 데이터 대기 시간 문제가 발생한다는 것입니다.

Amazon Redshift Spectrum을 사용하면 가장 큰 테이블을 Amazon S3로 옮길 수 있으며, 각 Amazon Redshift 클러스터는 로컬 디스크에 적은 양의 데이터만 보관합니다. 데이터 양이 줄어들기 때문에 까다로운 쿼리 작업 부하를 처리하기 위한 “읽기 전용” 클러스터를 생성 및 복원하는 것이 훨씬 빠릅니다 (그림 1 참조). 비용을 줄이려면 이러한 “온-디멘드” 클러스터를 작업후 바로 종료하면 됩니다.

그림 1:  다중 읽기 전용 Amazon Redshift 클러스터에서 Redshift Spectrum 공유하기

Amazon Redshift 고객은 pgbouncer-rr을 사용하여, 여러 Redshift 클러스터를 배포 할 때 클라이언트 쿼리 라우팅을 단순화하고 제어하여 동시성을 확장할 수 있습니다. 자세한 내용은 Amazon Redshift 및 PostgreSQL을위한 pgbouncer-rr 소개 : Query Routing and Rewrite (영문)를 참조하십시오.

스토리지 모범 사례

스토리지 최적화 고려 사항에서는 모든 단계에서 I/O 워크로드를 줄이는 것이 좋습니다. 이는 각 스토리지 블록에 더 많은 레코드를 맞추기 위해 압축을 사용하고 데이터 파티셔닝을 지원하는 형식을 사용하여 컬럼 기반 파일 형식을 사용해야 합니다. Amazon Redshift Spectrum에서 지원되는 파일 형식으로는 CSV, TSV, Parquet, Sequence 및 RCFile이 있습니다.

추가적인 최적화 방법은 압축을 사용하는 것입니다. 현재 Amazon Redshift Spectrum은 Gzip, Snappy 및 BZ2를 지원합니다.

3. 성능 향상과 비용 절감을 위해 Apache Parquet 파일 사용

Apache Parquet은 데이터 처리 프레임 워크, 데이터 모델 또는 프로그래밍 언어의 선택 여부와 상관없이 Apache Hadoop의 모든 프로젝트에서 사용할 수 있는 컬럼 형식 저장소 형식입니다. 자세한 내용은 Apache Parquet 정보 페이지를 참조하십시오.

Redshift Spectrum은 S3에서 쿼리에 필요한 파일의 컬럼(Column)만을 읽으며, 쿼리 당 S3에서 스캔되는 데이터의 양에 따라 요금을 부과합니다. 따라서, Parquet 형식의 데이터는 컬럼 형식으로만 저장하므로,  스캔 중에 불필요한 데이터를 제거 할 수 있습니다. 예를 들어, CSV 텍스트 파일과 Parquet 파티션 파일 간의 쿼리 성능 차이를 비교하면 바로 알 수 있습니다. 여러 가지 테스트 결과에 따르면 파티션 된 Parquet 파일은 성능이 빠르고 비용 효율적입니다.

SVL_S3QUERY_SUMMARY를 사용하면 분할 된 Parquet 파일을 사용하는 쿼리에 대한 흥미로운 S3 측정값에 대한 통찰력을 얻을 수 있습니다.

select * from SVL_S3QUERY_SUMMARY where query=<Query-ID>;

s3_scanned_rowss3query_returned_rows 등 두 가지 측정 항목에  주의하십시오. CSV 파일과 비교할 때 최종 처리를 위해 Redshift Spectrum에서 Redshift 네이티브로 반환 되는 데이터의 양이 엄청나게 줄어들 것입니다.

4. 자주 사용하는 칼럼에 대한 Parquet 파일 분할

최적의 파티션 칼럼을 정할 때는 아래 사항을 고려하시기 바랍니다.

  • 공통 필터로 사용되는 칼럼을 선택합니다.
  • 과도하게 세분화 된 파티션은 스캔 시간이 증가될 수 있으나, 파티션 정리에 도움이 되고 S3에서 스캔 한 데이터의 양을 줄일 수 있습니다.
  • 실제 성능은 파일 배치, 쿼리 패턴, 파일 크기 분포, 파티션에 있는 파일 수, 적합한 파티션 수 등에 따라 달라질 수 있습니다.
  • 칼럼을 분할 할 때, 데이터가 잘 분할되고 있는지 모니터링하시기 바랍니다.
  • 파일 크기 분포가 가능한 한 균일해야 합니다. 즉, 한 개의 1GB 파일과 6 개의 256MB 파일보다는 256MB Parquet 파일 10 개로 처리하는 것이 좋습니다.

파티션 정리 (partition pruning)의 이점을 살펴보려면, Parquet 형식을 사용하여 두 개의 외부 테이블을 작성하는 것을 고려해야 합니다. 하나의 테이블은 파티션하지 않고, 다른 파티션은 일별로 분할합니다.

파티션한 테이블 스캔은 파티션 하지 않은 테이블보다 2~4 배 빠릅니다.

“파티션 정리”가 유효한 지 알아보려면, SQL을 사용하여 파티션 정리의 효율성을 분석 할 수 있습니다. 쿼리가 몇 개의 파티션에만 적용하여, 실제 예상대로 작동하는지 확인할 수 있습니다.

SELECT query,
	segment,
	max(assigned_partitions) as total_partitions,
	max(qualified_partitions) as qualified_partitions 
FROM svl_s3partition 
WHERE query=<Query-ID>
GROUP BY 1,2;

클러스터 설정 모범 사례

5. 올바른 클러스터 구성으로 Redshift Spectrum 성능 최적화

Amazon Redshift Spectrum 쿼리에는 두 가지의 Amazon S3 요청 병렬 처리 방식이 있습니다.

  • 쿼리 수준 (슬라이스 쿼리 당 최대 10 개) 숫자는 실행 중인 동시 쿼리 수에 따라 상이함
  • S3 스캔에 사용되는 스레드 수에 따른 작업

노드 수준 (노드에서 실행되는 모든 S3 쿼리, 노드 유형에 따라 상이함)노드 인스턴스 타입에 따라 상이함
간단한 계산 방법은 다음과 같습니다. “총 파일 수 <= 쿼리당 병렬 처리 수 (예 : 10) * 총 슬라이스 수” 일 때, 더 많은 노드를 가진 클러스터를 만들어도 성능이 향상되지 않을 수 있습니다. 좋은 방법은 Amazon Redshift Spectrum 테이블에 있는 파일 수를 확인하는 것입니다. 그리고, 특정 클러스터 크기 (슬라이스 관점에서)까지 추세를 측정하여 클러스터 노드 수가 증가하는 경우에도 성능이 더 이상 올라가지 않을 때를 확인합니다. Amazon Redshift 클러스터의 최적의 크기 (주어진 노드 유형에 대한)는 더 이상의 성능 향상을 얻을 수 없는 지점입니다.

쿼리 성능 모범 사례

몇 가지 간단한 기술을 사용하여 Amazon S3에서의 쿼리 성능을 향상시킬 수 있습니다.

6.  신속하게 스캔 및 집계가 필요한 쿼리에 주로 활용하기
Query 1과 같은 조인(Join)이 없는 특정 쿼리에서 성능은 일반적으로 검색 속도와 같은 물리적 I/O 비용에 의해 좌우됩니다. 이러한 쿼리의 경우, Redshift Spectrum이 Redshift보다 빠를 수 있습니다. 반면에 쿼리 2와 같이 여러 테이블 조인이 포함될 경우, 로컬 스토리지를 사용하는 매우 최적화 된 네이티브 Redshift 테이블이 훨씬 성능이 좋습니다.

7.  조건절(Predicate) 푸시 다운으로 S3 쿼리 성능 향상
Amazon Redshift Spectrum 수준 (S3 스캔, 프로젝션, 필터링 및 집계)에서 수행되는 처리는 개별 Amazon Redshift 클러스터와는 독립적이고, Redshift 클러스터의 리소스를 사용하지 않습니다.

따라서, Redshift Spectrum 에서 푸시 다운 할 수 있는 특정 SQL 작업이 있습니다. 가능한 한 이를 활용하고 싶다면, 다음 몇 가지 예를 참고하시기 바랍니다.

  • GROUP BY 절 및 일부 문자열 함수
  • LIKE와 같은 조건부 조건 및 패턴 일치 조건
  • COUNT, SUM, AVG, MIN, MAX 및 기타 많은 공통 집계 함수
  • regex_replace 및 기타 많은 함수

DISTINCTORDER BY와 같은 특정 SQL 작업은Redshift Spectrum으로 푸시 다운 될 수 없기 때문에 Redshift에서 수행해야 합니다. 가능한 경우 사용을 최소화하거나 사용하지 않아야 합니다.

다음 두 가지 쿼리를 사용하여 테스트를 수행하면 큰 차이가 있음을 알 수 있습니다.

Select MIN(L_SHIPDATE), MAX(L_SHIPDATE), count(*)
	from spectrum.LINEITEM_NPART_PARQ;
Select MIN(DATE(L_SHIPDATE)), MAX(DATE(L_SHIPDATE)), count(*)
        from spectrum.LINEITEM_NPART_PARQ;

자연 스럽게 왜 그런지 의문이 듭니다.첫 번째 쿼리에서는 S3 Aggregate가 Redshift Spectrum으로 푸시되고, 집계 된 결과만 최종 처리를 위해 Amazon Redshift로 반환됩니다.

반면에 두 번째 쿼리를 면밀히 살펴보면 Redshift Spectrum이 DATE를 일반 데이터 형식 또는 DATE 변환 함수로 지원하지 않았기 때문에 Redshift Spectrum 계층에서 S3 집계가 없음을 알 수 있습니다. 결과적으로 이 쿼리는 S3에서 대용량 데이터를 Redshift로 직접 가져와 변환 및 처리를 해야합니다.

또 다른 대안적인 방법은 두 SQL 문에 대한 SVL_S3QUERY_SUMMARY 시스템 뷰 (s3query_returned_rows 컬럼)에 대해 쿼리하는 것입니다. Redshift Spectrum에서 Redshift로 반환되는 행(row)수에서 큰 차이가 있다는 점을 알게 될 것입니다.

8. DISTINCT를 GROUP BY로 바꾸기

GROUP BY, MIN/MAX/COUNT 등과 같은 특정 SQL 연산자는 Redshift Spectrum 계층으로 푸시 다운 할 수 있습니다. 다만, DISTINCT 및  ORDER BY와 같은 다른 SQL 연산자는 푸시 다운 할 수 없습니다. 일반적으로 Redshift Spectrum을 지원하는 강력한 인프라 때문에 푸시 다운 할 수 있는 모든 작업의 성능이 Redshift 대비 향상됩니다.

예를 들어, 다음 두 기능적으로 동일한 SQL 문을 테스트해보시기 바랍니다.

SELECT DISTINCT l_returnflag,
        l_linestatus 
FROM 	spectrum.LINEITEM_PART_PARQ 
WHERE 	EXTRACT(YEAR from l_shipdate::DATE) BETWEEN '1995' AND  '1998' 
ORDER BY l_returnflag, l_linestatus
;

SELECT l_returnflag,l_linestatus 
FROM 	spectrum.LINEITEM_PART_PARQ 
WHERE EXTRACT(YEAR from l_shipdate::DATE) BETWEEN '1995' AND  '1998' 
GROUP BY l_returnflag, l_linestatus 
ORDER BY l_returnflag, l_linestatus
;

DISTINCT로 인해 첫 번째 쿼리에 푸시 다운은 없습니다. 대신 Amazon Redshift에 다량의 행(row)이 반환 및 정렬됨으로서 중복을 제거합니다. 두 번째 쿼리에서 S3 HashAggregate 는 Redshift Spectrum으로 푸시됩니다. 여기서는 대부분 무거운 작업 및 집계를 수행합니다. SVL_S3QUERY_SUMMARY에 대한 질의 계획상 차이점을 확인할수 있습니다.

여기서 우리는 가능하면 SQL 문에서 “DISTINCT“를 “GROUP BY“로 대체하면 좋다는 사실을 알 수 있습니다.

테이블 대체에 대한 모범 사례

아래 간단한 지침은 최고의 성능을 위해 테이블을 저장할 최적의 위치를 결정하는 데 도움을 줄 것입니다.

9. S3에 큰 팩트 테이블을 넣고 Redshift에 다른 팩트 테이블 두기

3 개의 테이블 조인이 있는 Query 2를 생각해 보겠습니다. 자연스럽게 세개의 테이블 모두가 S3에서 분할 된 Parquet 파일로 되어 있는 경우 어떻게 될까요? 일반적으로 Amazon Redshift에서 세 개의 테이블 모두 사용하는 것보다 성능이 좋을까요 아니면 나쁠까요?

조인(Join) 최적화 된 Amazon Redshift 테이블 세트 (적절한 분배 및 정렬 키 포함)가  Redshift Spectrum보다 성능면에서 뛰어 납니다. Redshift Spectrum 외부 테이블은 통계를 지원하지 않습니다. 데이터베이스 엔진은 추론 또는 간단한 행 수를 사용하여 조인 순서를 결정합니다. 어떤 경우에는 이것이 최적의 방법이 아닐 수 있습니다. AWS의 권장 사항은 Amazon S3에 가장 큰 팩트 테이블만 넣고,  중간 혹은 작은 크기의 테이블은 edshift에 남겨 두는 것입니다. 이렇게 하면 최적화 프로그램을 가장 효과적으로 활용할 수 있습니다.

최근에 CREATE EXTERNAL TABLEALTER TABLE 명령에서 TABLE PROPERTIES 절을 사용하여 테이블 통계 (numRows)를 설정하는 지원을 추가했습니다. 이를 활용하여 테이블의 정확한 행 번호를 설정하고, 최적의 쿼리 실행 계획을 생성하도록 프로그램에 지시 할 수 있습니다. 자세한 내용은 Amazon Redshift 설명서의 CREATE EXTERNAL TABLE을 참조하십시오.

적어도 세 개의 외부 테이블을 포함하는 추가 쿼리를 정의하고, 올바른 조인 순서 (Explain을 활용 가능)를 사용하여 실행하도록 요청합니다. Amazon Redshift Spectrum을 사용하여 여러 개의 외부 테이블을 절대 결합해서는 안된다는 결론을 성급히 내리지 않도록 하기 위함입니다.

10. 자주 조인하는 대형 테이블을 S3에 넣을 때 조심하기

Amazon Redshift는 Query 2처럼 보이는 질의에 대해서 Redshift Spectrum에서는 많은 동시성 레벨에서 거의 3 배 이상 높은 성능을 보일 수 있습니다. Query 1과 Query 2의 차이점은 Query 1에서 하나의 테이블에 대한 집계 연산만, Query2에서는 비교적 큰 세 개의 테이블 조인 된다는 점입니다.

좀 더 명확하게 말하자면, 성능 차이의 주요 원인은 Amazon Redshift에서 조인이 실행 되기 때문입니다. 조인하는 모든 데이터는 먼저 S3에서 로드되어 Amazon Redshift 클러스터의 개별 슬라이스로 즉시 배포되어야 합니다. 따라서 Amazon Redshift 로컬 스토리지에 접근할 때 보다 Redshift Spectrum을 사용하면 지연 시간이 현저하게 길어집니다.

따라서 조인을 자주하는 서 너개의 테이블이 Amazon Redshift에 있고, 이들 쿼리 작업 부하가 엄격한 SLA의 영향을 받는 경우, 이들은 Amazon S3에 두지 않는 것이 나을 수 있습니다.

마무리

이 글은 Amazon Redshift Spectrum의 성능을 향상시키는 몇 가지 중요한 모범 사례를 설명하였습니다. 각 경우는 특이하기 때문에 모범 사례에 맞는 권장되는 특정 상황에 적용에 대한 테스트를 직접해야 합니다. 질문이나 제안 사항이 있으시거나, Amazon Redshift 클러스터 최적화에 대한 추가 지원이 필요하면 AWS  기술팀에 문의하십시오.

이 글은 AWS 프로페셔널 서비스팀의 빅데이터 컨설턴트로 있는 Po Hong 박사와 Peter Dalton 컨설턴트가 작성하였으며, AWS 빅데이터 블로그의 10 Best Practices for Amazon Redshift Spectrum의 한국어 번역입니다.

AWS IoT, 가격 인하를 위한 신규 요금 모델 예고

많은 AWS 고객들이 AWS IoT를 사용해 연결된 디바이스를 보다 지능적으로 만들고 있습니다. 이러한 디바이스는 개별 현장(지하, 공중, 수중, 공장 및 병원 입원실)에서 데이터를 수집하여 측정하고 AWS 클라우드에 대한 게이트웨이로 AWS IoT를 사용합니다. 클라우드에 연결되면 고객은 Amazon Simple Storage Service(S3)Amazon DynamoDB에 디바이스 데이터를 기록하고, Amazon KinesisAWS Lambda 함수를 사용해 데이터를 처리하며, Amazon Simple Notification Service (SNS) 푸시 알림과 기타 다양한 기능을 시작할 수 있습니다.

새로운 요금 모델(20-40% 인하)
고객 여러분에게 더 나은 가치를 제공하기 위해 오늘부터 AWS IoT 요금 모델을 변경합니다. 대부분의 고객은 20-40%의 가격 인하 혜택을 누릴 수 있으며, 일부는 워크로드에 따라 훨씬 더 많은 할인을 받게 됩니다.

기존 모델은 서비스와 주고 받는 메시지 수에 부과되는 요금을 기반으로 했습니다. 이와 같은 통합형 모델이 출발점으로는 좋았지만, 일부 고객은 실제 사용하지 않은 AWS IoT 부분에 대한 요금을 지불하게 된다는 맹점이 있었습니다. 예를 들어 어떤 고객은 자주 발생하지 않는 스파스 규칙 세트를 이용해 매우 자주 AWS IoT를 ping하는 디바이스를 사용합니다. 새로운 모델은 각 구성 요소마다 독립적으로 요금을 부과하도록 세분화되었습니다(모든 요금은 미국 동부(버지니아 북부) 리전)에 연결되는 디바이스에 적용됨.

연결 – 디바이스가 AWS IoT에 연결된 총 시간을 기준으로, 1분 단위로 측정됩니다. 100만 분 연결에 대해 $0.08의 요금이 부과됩니다(24시간 연중 무휴 연결 시 디바이스 한 대당 연 $0.042 상당). 디바이스는 추가 비용 없이 30초 ~ 20분 간격으로 연결 유지 ping을 보낼 수 있습니다.

메시징 – 디바이스와 AWS IoT 사이에 전송되는 메시지 수를 기반으로 측정됩니다. 요금은 메시지 백만 건당 $1에서부터 시작되며 대량 구매 요금은 백만 건당 $0.70로 매우 저렴합니다. 최대 128킬로바이트 크기의 메시지를 주고 받을 수 있습니다. 메시지는 5킬로바이트 단위로 측정됩니다(이전의 512바이트에서 증대). 예를 들어 8킬로바이트 메시지 한 건은 두 건의 메시지로 측정됩니다.

규칙 엔진 – 규칙당 최소 하나의 작업이 있다는 전제 하에 규칙이 트리거될 때마다, 규칙 내에서 실행된 작업의 수를 기준으로 측정됩니다. 트리거된 규칙 백만 건당 $0.15, 실행된 작업 백만 건당 $0.15로 요금이 책정되었습니다. 5킬로바이트를 초과하는 메시지를 처리하는 규칙은 5킬로바이트 크기의 다음 배수에서 계산됩니다. 예를 들어 8킬로바이트 메시지를 처리하는 하나의 규칙은 두 개의 규칙으로 계산됩니다.

디바이스 섀도우 및 레지스트리 업데이트 – 디바이스 섀도우 또는 레지스트리 데이터에 액세스하거나 수정하기 위한 작업 수를 기준으로 측정되며, 작업 백만 건당 $1.25입니다. 디바이스 섀도우 및 레지스트리 작업은 디바이스 섀도우 또는 레지스트리 레코드 크기의 1킬로바이트 단위로 측정됩니다. 예를 들어 1.5킬로바이트 섀도우 레코드 업데이트 한 건은 두 건의 작업으로 측정됩니다.

AWS 프리 티어는 최대 50대의 디바이스 집합을 수행하기에 충분한 연결 시간(분), 메시지, 트리거된 규칙, 규칙 작업, 섀도우 및 레지스트리 사용량을 할당합니다. 새로운 요금은 2018년 1월 1일부터 자동으로 적용됩니다. 업데이트된 요금이 적용되는 시점에 AWS IoT 요금 페이지에 게시됩니다.

re:Invent의 AWS IoT
올해 AWS re:Invent에 전체 AWS IoT 트랙이 실려 있습니다. 예시:

Philips, Panasonic, Enel, Salesforce가 발표하는 고객 세션도 마련되어 있습니다.

Jeff;

이 글은 AWS IoT Update – Better Value with New Pricing Model의 한국어 번역입니다.

Stephen Orban – 엔터프라이즈의 DevOps 문화

“개발은 점진적 개선을 수반하는 인내심 훈련이다.”
-Sri Mulyani Indrawati

 

DevOps는 오랜 시간 회자되고 있는 그 개념에 비해 비교적 최근에 새롭게 만들어진 용어입니다. 현재 일부에서는, 이전에 사일로 현상을 겪었던 팀들의 융합 지점이 되어 더욱 빈번하게 신속하고 안정적인 결과를 도출할 수 있는 기업문화로 받아들여지고 있습니다.

이 용어가 대세가 되기 전부터DevOps 문화 속에서 일을 시작할 수 있었던 것은 저에게 큰 행운이었습니다. 2001년 Bloomberg에서 개발자로 첫 발을 내디뎠을 때 이 회사는 이미 출시 시간을 앞당기기 위한 부단한 노력과 반복적 개발 주기, 그리고 자신이 개발한 시스템의 지속적인 운영까지 책임지는 개발자들로 잘 알려져 있었습니다. 그래서 새로운 개발자들이 새벽 4시(런던 증권 거래소 개장 시간)에 시스템 문제를 해결하는 것이 어떠한 일인지 배우는 데 오랜 시간이 걸리지 않았습니다. 저는 밤늦게 작업하는 이러한 경험이 시스템을 더욱 견고하게 개발해야 한다는 강력한 동기로 작용한다는 것을 깨달았습니다..

DevOps는 소규모 기업일수록 비교적 쉽게 접근할 수 있기 때문에 직관적으로 스타트업에게 명백해 보일 수 있습니다. 하지만 조직 규모가 커질수록 상당한 기술 부채와 모놀리식 아키텍처, 그리고 위험을 기피하는 비즈니스 관행으로 인해 이러한 업무는 감히 엄두도 내기 어렵습니다.

© Will Fisher https://www.flickr.com/photos/fireatwillrva/6541738007/

하지만 이제 그럴 필요가 없습니다. 앞으로 몇 주간 엔터프라이즈 의 DevOps 구현을 위한 구체적인 영역 및 전략에 대해서 이야기하려고 합니다. DevOps 문화로 전환하고 싶은 기업이 있다면 저는 작은 프로젝트부터 시작하여 반복, 학습 및 개선을 이루어가는 DevOps 방식으로 시작해보라고 이야기합니다. 다시 말해, 먼저 기업 전체에서 공통적으로 허용되는 업무 전략의 구현 방안에 대해서 고찰한 후 이러한 업무가 자동화되고 나면 운영 업무가 탈중앙화되고 여러 부서들이 자신이 구축한 시스템을 스스로 운영할 수 있다는 생각을 포용하도록 장려합니다.

Dow Jones에서 CIO로 재직할 당시에는 소규모 팀을 중심으로 DevOps 업무를 처리하였습니다. 4~5명의 인원으로도 몇 가지 프로젝트를 충분히 처리할 수 있었으니까요. 또한 우리의 목표는 새로운 팀을 구성하는 것이 아니라 회사의 문화를 바꾸는 데 일조하는 것이었습니다. DevOps는 프레임워크, 모범 사례 및 통합 관리를 구현 및 창안하고, 이 모든 것을 자동화함으로써 앞으로의 혁신을 견인하고 제품 개발을 가속화하는 주요 수단이 되었습니다. 우리는 작은 프로젝트부터 시작하였고, 그 결과를 통해 동일한 모델로도 점차 늘어나는 프로젝트들을 얼마나 성공적으로 실행할 수 있는지 보여주었습니다. 느리지만 확실하게, 우리는 더욱 다양한 기능을 개발하기 시작했고,제품 출시 기간을 앞당겼습니다. 이전에는 화요일과 목요일 야간에 제품을 출시하면서 종종 일이 잘못되는 경우도 있었지만 이제는 개발자들이 매주 수십 가지의 변경 사항을 발표하기에 이르렀습니다.

DevOps를 고려하는 동시에 기술 부채까지 처리해야 하는 기업이라면 다음과 같이 세 가지 원칙부터 시작하는 것이 좋습니다.

1. 전사적인 수준에서 고객 서비스에 중점을 두십시오. 오늘날 기업들은 내부 관계자들까지 고객으로 생각해야 합니다. 마케팅 부서 직원, 제품 관리자 또는 개발자 등 어느 누구든지 고객이 될 수 있습니다. 개인이나 그룹 모두 기술 없이는 자신의 업무를 처리하기 어렵습니다. 이러한 기술적 요건을 최우선으로 생각하는 팀들은 고객이 다른 솔루션(섀도우 IT)을 찾아 헤매지 않도록 지원하여 더 나은 결과를 더욱 신속하고 저렴한 비용으로 제공할 뿐만 아니라 고객 만족도까지 높일 수 있습니다. 우수한 서비스의 부재는 고객이 기업과 함께 하기 보다는 오히려 피하게 만들 뿐입니다.

2. 모든 것을 자동화하십시오. 오늘날 클라우드를 최대한 활용하기 위해서는 코드를 사용해 시스템을 안정적으로 복제할 수 있어야 한다고 널리 알려져 있습니다. 특히 Auto Scaling(탄력성)에서는 더욱 그렇습니다. 그 밖에도, 자동화는기업이 변화를 추구하는 데 더욱 적극적인 움직임을 취할 수 있도록 도와줍니다. 예를 들어, 혹시 실수가 있더라도 신속히 예전 상태로 돌아갈 수 있습니다. 그 외에도 효율성, 보안 및 감사 능력의 향상 역시 빼놓을 수 없는 이점입니다. (자세한 내용은 자동화에 대한 이전 게시물을 참조하십시오.)

3. 개발한 자산을 직접 운영하십시오. 이 문제와 관련하여 기존 IT 부서들이 고민하는 모습을 종종 보게 됩니다. 기존 IT 모델에서는 자산 개발에 참여하지 않은 사람들이 애플리케이션 또는 서비스를 관리하는 경우가 종종 있습니다. 과거에는 저렴한 인력 비용, 전문 기술의 중앙화 등 많은 이유가 있었지만 현 시점에서 이러한 이유들은 사라지고 있습니다. 이제 클라우드 기술이 IT 운영에서 발생하는 대부분의 어려운 일들을 처리할 뿐만 아니라, 소프트웨어를 사용해 대부분 작업을 자동화할 수 있기 때문입니다. 개발자들은 소프트웨어에 매우 익숙하고, 따라서 굳이 운영 업무를 따로 분리할 이유가 없습니다. 결국 DevOps라는 용어도 바로 여기에서 시작되는 셈입니다. 개발자들은 시스템의 미묘한 차이를 가장 정확하게 알 수 있는 사람들이기 때문에, 문제를 해결하는 속도도 가장 빠를 가능성이 높습니다. 또한 자동화를 통해, 변경 사항을 체계적으로 전파하거나 변경 이전으로 되돌리는 것이 쉬울 뿐만 아니라 고객에게 영향을 미치기 전에 문제를 해결할 수 있습니다. 중앙 집중된 DevOps팀들은 각 개발 팀이 점차적으로 독립성을 키울 수 있도록 지원하고, 지속적인 운영/출시 업무에서 DevOps팀이 주요 경로(critical path)가 되지 않도록 해야합니다.

조금이라도 관심이 있는 기업이라면 지금이야 말로 좋은 타이밍입니다. 작게 시작하여 점차 개선되는 모습에 만족감을 느껴보세요. 문화적 변화는 하루 아침에 일어나지 않습니다. 서서히 포트폴리오에 이러한 개념을 적용하기 시작하면 새로운 업무 방식과 이전 업무 방식 모두 개선될 수 있을 것입니다. 경험이 쌓여갈수록 학습한 내용을 다음 학습에 활용하고,  점차 늘어나는 자동화 인벤토리를 이용함으로써 더 나은 결과를 보게 될 것입니다.

다음 게시물에서는 고객 서비스 중심의 IT 조직이란 무엇을 의미하는지 자세하게 알아보겠습니다.

여러분의 DevOps 경험은 무엇입니까? 있다면 꼭 듣고 싶습니다!

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

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

Amazon QuickSight 업데이트 – 공간 정보 시각화, 프라이빗 VPC 액세스 등

AWS에서는 특별히 기념일에 축하하는 경우가 많지 않습니다. 지금까지 AWS에서 제공하는 100여개의 서비스를 개발하면서 축하를 했다면, 아마 일주일에 몇 번이나 케이크와 샴페인을 마셨을 것입니다. 저희는 그보다 고객의 의견을 경청하고 혁신하는 데 더 시간을 쏟고 있습니다. 이에 따라 정식 출시된 지 일 년이 조금 넘은 Amazon QuickSight에 대한 새로운 기능 업데이트를 제공해 드리고자 합니다.

QuickSight 실행
운송, 법률, 광업, 의료 등 다양한 업종의 스타트업에서 대기업에 이르기까지 오늘날 수만 명의 고객이 QuickSight를 사용하여 회사의 비즈니스 데이터를 분석하고 보고합니다.

다음은 몇 가지 예입니다.

Gemini는 산재 근로자를 대변하는 캘리포니아 변호사를 위해 법적 증거를 입수합니다. 사용자 지정 보고서를 만들고 일회용 쿼리를 실행하는 것부터 드릴다운과 필터링을 통해 동적 QuickSight 대시보드를 만들고 공유하는 것까지 다양한 작업을 수행합니다. QuickSight는 영업 파이프라인을 추적하고, 주문 처리량을 측정하며, 주문 처리 파이프라인에서 병목을 찾는 데 사용됩니다.

Jivochat은 방문자를 웹 사이트 소유자에게 연결하는 실시간 메시징 플랫폼을 제공합니다. 이 회사는 QuickSight를 통해 대화형 대시보드를 만들고 공유하는 동시에 기본 데이터세트에 대한 액세스도 제공합니다. 이를 통해 정적 스프레드시트를 공유하는 차원이 아니라, 모든 작업자가 같은 정보를 보고 최신 데이터에 기반하여 시기적절한 의사결정을 내릴 수 있도록 지원합니다.

Transfix는 첨단 기술을 활용하는 화물 운송 마켓플레이스로, 소매, 식음료, 제조 등의 다양한 산업에 속한 Fortune 500 기업의 화물 운송을 연결하여 물류에 대한 모든 정보를 파악할 수 있게 합니다. QuickSight를 통해 BI 엔지니어와 일반 비즈니스 사용자는 모두 분석을 액세스할 수 있습니다. 이들은 배송 경로, 운송업체 능률, 프로세스 자동화를 비롯한 핵심 비즈니스 및 운영 측정치를 면밀히 검토합니다.

검토/전망
QuickSight에 대한 의견은 엄청난 도움이 되었습니다. 고객은 회사 직원들이 자체 BI 인프라를 설정하거나 실행하지 않고도 QuickSight를 사용하여 데이터에 연결하고, 분석을 수행하고, 데이터에 기반한 신속한 의사결정을 내린다고 말합니다. AWS는 고객의 모든 의견에 진심으로 감사하며, 의견을 바탕으로 로드맵을 추진함으로써 불과 1년 사이에 40개가 넘는 새로운 기능을 소개할 수 있었습니다. 요약하면 다음과 같습니다.

이제 AWS는 고객의 사용 패턴 중 흥미로운 동향을 주시하고 있습니다. 각 고객들은 데이터를 분석하고 보고하는 방식을 주의 깊게 바라보면서 서버리스(Serverless) 접근 방식이 실질적인 이점을 제공한다는 점을 깨닫고 있습니다. 이들은 Amazon Simple Storage Service(S3)를 데이터 레이크로 사용하고, QuickSight와 Amazon Athena를 함께 사용하여 이를 쿼리함으로써 정적 인프라 없이도 민첩성과 유연성을 발휘합니다. 또한, QuickSight의 대시보드 기능을 최대한 활용하여 비즈니스 결과와 운영 측정치를 모니터링한 후 수백 명의 사용자와 통찰 정보를 공유합니다. 더 자세한 것으 Building a Serverless Analytics Solution for Cleaner CitiesServerless Big Data Analytics using Amazon Athena and Amazon QuickSight 글을 참고 하시기 바랍니다.

새로운 기능 및 향상
AWS는 고객의 의견을 경청하고 받아들이며 QuickSight가 계속하여 고객의 요구를 충족할 수 있도록 항상 최선의 노력을 다하고 있습니다. 그 결과 다음과 같은 7가지 중요한 기능을 추가했음을 기쁜 마음으로 알려드립니다.

  • 공간 정보 시각화 – 이제 지리적 데이터 세트에서 공간 정보 시각적 객체를 만들 수 있습니다.
  • 프라이빗 VPC 액세스 – 등록 후, 퍼블릭 엔드포인트 없이 VPC 또는 온프레미스 내의 데이터에 안전하게 연결할 수 있는 새로운 기능의 프리뷰 버전을 이용할 수 있습니다.
  • 플랫 테이블 지원 – 테이블 형식 보고에 피벗 테이블 외에 플랫 테이블도 사용할 수 있습니다. 자세히 알아보려면 표 형식 보고서 사용을 참조하십시오.
  • 계산된 SPICE 필드 – 이제 분석의 일부로 SPICE 데이터에 대한 실시간 계산을 수행할 수 있습니다. 자세한 내용은 분석에 계산된 필드 추가를 참조하십시오.
  • 와이드 테이블 지원 – 이제 열이 최대 1,000개인 테이블을 사용할 수 있습니다.
  • 기타 버킷Amazon QuickSight의 시각 요소 유형 사용에서 설명한 대로 카디널리티가 높은 데이터의 긴 테일을 버킷으로 요약할 수 있습니다.
  • HIPAA 규정 준수 – 이제 QuickSight에서 HIPAA 준수 워크로드를 실행할 수 있습니다.

공간 정보 시각화
이 기능은 누구나 원하는 기능일 것입니다. 이제 지리적 식별자(국가, 도시, 주 또는 우편 번호)가 포함된 데이터를 가져와 단 몇 번의 클릭으로 아름다운 시각 효과를 만들어 낼 수 있습니다. QuickSight는 사용자가 제공하는 식별자를 지오코딩하며, 위도/경도 지도 좌표를 적용할 수도 있습니다. 이 기능을 사용하여 영업을 주별로 시각화하고, 스토어를 배송 목적지에 매핑하는 등의 작업을 할 수 있습니다. 다음은 시각화 샘플입니다.

이 기능에 대해 자세히 알아보려면 지리 공간 차트 사용(지도)지리 공간 데이터 추가를 읽어보십시오.

프라이빗 VPC 액세스 프리뷰
퍼블릭 연결이 없는 서버에 Teradata 또는 SQL Server 형식의 온프레미스 데이터가 있거나 AWS(Amazon Redshift, Amazon RDS(Relational Database Service), EC2 등)에 데이터가 있는 경우, 이 기능이 매우 유용합니다. QuickSight의 프라이빗 VPC 액세스는 VPC의 데이터 원본과 기밀로 안전하게 통신할 수 있도록 탄력적 네트워크 인터페이스(ENI)를 사용합니다. 또한 AWS Direct Connect를 사용하여 온프레미스 리소스와의 안전한 프라이빗 연결을 생성할 수 있습니다. 다음 그림을 참조하십시오.

프리뷰에 참여할 준비가 되었다면 지금 바로 등록하십시오.

Jeff;

이 글은 Amazon QuickSight Update – Geospatial Visualization, Private VPC Access, and More의 한국어 번역입니다.

새 소식 – 대화형 AWS 비용 탐색기 API

몇 년 전 AWS 비용의 추적, 할당 및 관리가 가능하도록 AWS 비용 탐색기를 출시했습니다. 그 출시에 대한 대응과 이후의 추가 기능은 매우 긍정적이었습니다. 하지만, 일부 고객들은 Jeff Bezos의 의견처럼 매우 불만스러워 했습니다.

새롭게 서비스를 출시하면, 항상 고객에게 더 많은 것을 요구합니다. 예를 들어 많은 고객들은 IT 인프라 대부분을 AWS 클라우드로 이동한 후, 비용 탐색기에 공급되는 전체 데이터에 대한 많은 요청을 받았습니다. 이러한 고객들은 프로그래밍 방식으로 AWS 비용을 탐색하고, 애플리케이션별 및 부서별 비용으로 원장 및 회계 시스템을 업데이트하기 위한 목적을 가지고 있습니다. 또한 지출을 요약하는 높은 수준의 대시보드를 직접 만들어 운영 합니다. 일부 고객들은 비용 탐색기에서 공급하는 차트 및 보고서로부터 데이터를 추출하는 데 공을 들여왔습니다.

새로운 비용 탐색기 API 출시
오늘 비용 탐색기로 공급되는 기본 데이터를 프로그래밍 방식으로 이용 가능합니다. 새로운 비용 탐색기 API는 위에 설명한 모든 것을 할 수 있도록 여러 기능을 제공합니다. 비용 및 사용량 데이터를 검색하여 여러 차원(서비스, 연결 계정, 태그, 가용 영역 등)에 걸쳐 필터링 및 그룹화하고, 일 또는 월별로 집계할 수 있습니다. 이를 통해 단순하게 시작(총 월별 비용)하고, 요청을 원하는 상세 수준(프로덕션으로 태그 지정된 DynamoDB 테이블에 쓰기)으로 구체화하면서 몇 초 만에 해답을 얻을 수 있습니다.

작업은 다음과 같습니다.

GetCostAndUsage – 필터링 및 그룹화를 포함하여 단일 계정 또는 모든 계정(모든 멤버 계정에 액세스할 수 있는 조직의 마스터 계정)에 대한 비용 및 사용량 지표를 검색합니다.

GetDimensionValues – 지정된 기간에 대한 지정된 필터로 이용 가능한 필터 값을 검색합니다.

GetTags – 지정된 기간에 대해 이용 가능한 태그 키 및 태그 값을 검색합니다.

GetReservationUtilization – 지정된 기간(일별 또는 월별 세부 수준에 필터링 및 그룹화 포함)에 대한 EC2 예약 인스턴스 활용을 검색합니다.

이러한 기능, 그리고 이를 통해 얻는 데이터가 비즈니스에 대한 더 나은 통찰력을 제공하는 흥미로운 무언가를 하는 능력을 제공할 것입니다. 예를 들어 개별 마케팅 캠페인 또는 개발 프로젝트를 지원하는 데 사용하는 리소스에 태그를 지정한 다음 비용을 심층 분석하여 비즈니스 가치를 측정할 수 있습니다. 이제 사이버 먼데이블랙 프라이데이와 같은 중요 이벤트에 대해 인프라에 어느 정도 비용을 사용할지 상세한 단위까지 파악할 수 있는 잠재력을 갖게 된 것입니다.

알아야 할 것들
다음은 API를 사용하는 방법에 관해 생각할 때 몇 가지 알고 있어야 할 사항입니다.

그룹화 – 비용 탐색기 웹 애플리케이션은 한 가지 수준의 그룹화를 제공하지만, API는 두 가지 수준을 제공합니다. 예를 들어 비용 또는 RI 사용률을 서비스별 및 리전별로 그룹화할 수 있습니다.

페이지 매김 – 대용량 데이터를 반환하고 nextPageToken을 포함하여 페이지 매김에 대한 AWS 차원의 모델을 따릅니다. 추가 데이터를 이용 가능한 경우의 페이지 매김 예입니다. 이 기능을 간단하게 호출하여 토큰을 제공하면 계속 진행됩니다.

리전 – 서비스 엔드포인트는 미국 동부(버지니아 북부) 리전에 있으며, 모든 AWS 리전에 대한 사용량 데이터를 반환합니다.

요금 – 각 API 호출 요금은 0.01 USD입니다. 좀 더 자세히 살펴보기 위해 API를 사용하여 대시보드를 만들고, 사용자들로부터 월별 1,000회의 호출이 있다고 가정하겠습니다. 대시보드에 대한 운영 비용은 10 USD정도로 예측합니다. 자체 시스템을 설치하고 데이터를 추출 및 수집한 다음 대화형 쿼리에 응답하는 데 비하면 훨씬 저렴합니다.

비용 탐색기 API는 지금 이용 가능하며 오늘부터 사용할 수 있습니다. 자세히 알아보려면 비용 탐색기 API에 대해 읽어 보십시오.

Jeff;

이 글은 New – Interactive AWS Cost Explorer API의 한국어 번역입니다.

새 소식 – AWS OpsWorks for Puppet Enterprise 지원

작년 AWS re:Invent에서 고객이 AWS가 관리하는 Chef Automate 서버를 갖도록 할 수 있는 AWS OpsWorks for Chef Automate를 출시했습니다. 고객 피드백을 기반으로 이제 Puppet Enterprise를 OpsWorks에 도입합니다.

Puppet Enterprise를 사용하면 각각의 관리하는 노드에 배포된 Puppet 에이전트를 통해 인스턴스 프로비저닝, 구성 및 관리를 자동화할 수 있습니다. 한 번 구성을 정의하면 자동 롤백 및 드리프트 감지를 통해 수천 개의 노드에 적용할 수 있습니다. AWS OpsWorks for Puppet Enterprise는 기존 Puppet 매니페스트를 사용하여 원활하게 작업하면서 고유한 Puppet 마스터를 유지 관리할 필요를 없앱니다.

OpsWorks for Puppet Enterprise는 Puppet 마스터 서버를 관리하고 설치, 업그레이드 및 백업과 같은 운영 작업을 처리합니다. 또한 노드 등록을 간소화하고 노드 부트스트래핑에 유용한 스타터 키트를 제공합니다. 추가 정보는 아래를 참조하십시오.

관리형 Puppet 마스터 생성

OpsWorks에서 Puppet 마스터 생성은 간단합니다. 우선 OpsWorks 콘솔의 Puppet 섹션으로 이동한 다음 “Create Puppet Enterprise Server”를 클릭합니다.

설정의 첫 번째 부분은 Puppet 마스터에 대한 리전 및 EC2 인스턴스 유형을 구성하는 것입니다. c4.large가 최대 450개의 노드를 지원하는 반면 c4.2xlarge는 1,600개 이상의 노드를 지원할 수 있습니다. Puppet Enterprise 서버는 최신 버전의 Amazon Linux(2017.09)와 Puppet Enterprise(2017.3.2)와 함께 프로비저닝됩니다.

설정의 다음 화면에서 Puppet 마스터에 연결할 SSH 키를 선택적으로 구성할 수 있습니다. 주요 사용자 지정을 할 때 유용하지만 인스턴스 자체에서보다 클라이언트 도구를 통해 Puppet과 상호 작용하는 것이 모범 사례입니다.

또한 이 페이지에서 r10k repo가 동적 구성을 가져오도록 설정할 수 있습니다.

고급 설정 페이지에서 VPC, 보안 그룹, IAM 역할 및 인스턴스 프로파일에 맞는 일반적인 배포 옵션을 선택할 수 있습니다. OpsWorks에서 인스턴스 보안 그룹을 생성하도록 선택한 경우 그룹이 기본적으로 열리기 때문에 이후에는 액세스를 제한하는 것이 중요합니다.

이 페이지에서 주목해야 하는 두 가지 구성 요소는 유지 관리 기간과 백업 구성입니다. Puppet 소프트웨어의 새 마이너 버전이 나오면 AWS 테스트를 통과하는 즉시 Puppet 마스터에서 Puppet Enterprise 마이너 버전을 자동으로 업데이트하도록 시스템 유지 관리가 설계됩니다. AWS는 철저한 테스트를 실시하여 Puppet 업그레이드가 프로덕션 지원이며 기존 고객 환경을 방해하지 않고 배포하는지 확인합니다. 자동 백업을 통해 Puppet 마스터의 내구성이 뛰어난 백업을 S3에 저장하고 언제든지 백업을 복원할 수 있습니다. 업무상 필요에 따라 백업 주기 및 보존을 조정할 수 있습니다.

AWS OpsWorks for Puppet Enterprise 사용하기

Puppet 마스터가 프로비저닝하는 동안 콘솔에 두 가지 유용한 정보 상자가 제공됩니다.

Windows 및 Linux 노드에 Puppet 에이전트를 설치하기 위한 샘플 사용자 데이터는 물론 로그인 자격 증명을 다운로드할 수 있습니다. 여기서 중요한 점은 Puppet 마스터 연결이 가능한 경우 온프레미스 노드 또한 관리할 수 있다는 점입니다.

Puppet 마스터가 완전히 프로비저닝되면 Puppet Enterprise http 콘솔에 액세스하여 사용하던 대로 Puppet을 사용할 수 있습니다.

유용한 세부 정보

AWS OpsWorks for Puppet Enterprise는 관리하는 노드의 노드 시간에 따라 요금이 책정됩니다. 요금은 노드 시간당 $0.017부터 시작하여 노드의 볼륨에 따라 감소합니다. 여기에서 전체 요금 페이지를 볼 수 있습니다. 또한 Puppet 마스터 실행에 필요한 기본 리소스에 대한 요금이 부과됩니다. 출시 시점에서 AWS OpsWorks for Puppet Enterprise는 미국 동부(버지니아 북부) 리전, 미국 서부(오레곤) 리전, EU(아일랜드) 리전에서 사용할 수 있습니다. 물론 콘솔에서 봤던 모든 것을 AWS SDK 및 CLI를 통해 수행할 수 있습니다. 시작 안내서에서 자세한 정보를 얻을 수 있습니다.

Randall;

이 글은 New – AWS OpsWorks for Puppet Enterprise의 한국어 번역입니다.

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

Amazon ElastiCache 업데이트– Redis 클러스터 온라인 크기 조절 기능 출시

Amazon ElastiCache를 사용하면 고속 인 메모리 데이터 스토어와 캐시를 쉽게 설정할 수 있습니다. ElastiCache에서는 가장 인기 있는 두 오픈 소스 제품(Redis 및 Memcached)을 지원하여 게임 리더보드, 인 메모리 분석 및 대규모 메시징의 까다로운 요구 사항을 지원합니다.

오늘은 Redis용 Amazon ElastiCache의 중요한 추가 기능에 대해 살펴보겠습니다. 최대 15개의 샤드를 포함하는 클러스터를 만들 수 있습니다. 각 샤드는 특정 슬롯 세트에 대한 키와 값을 저장하고, 각 클러스터에는 정확히 16,384개의 슬롯이 있습니다. 단일 클러스터를 확장하여 초당 최대 2,000만 회의 읽기와 450만 회의 쓰기를 지원하면서 3.55TB의 인 메모리 데이터를 저장할 수 있습니다.

온라인 크기 조절
이제 클러스터를 온라인 상태로 유지하고 요청에 응답하면서 실행 중인 Redis용 ElastiCache 클러스터에서 샤드 수를 조정할 수 있습니다. 그러면 클러스터를 오프라인으로 전환하거나 빈 캐시로 시작할 필요 없이 트래픽 및 데이터 볼륨 변경에 대응할 수 있습니다. 또한 샤드 수를 변경하지 않고도 실행 중인 클러스터를 재조정하여 슬롯 공간을 균일하게 재배포할 수 있습니다.

리샤딩 또는 재분배 작업을 시작하면 Redis용 ElastiCache는 클러스터 내 전체 샤드에 슬롯을 균등하게 배포하는 계획을 준비하여 시작됩니다. 그런 다음 전체 샤드에 슬롯을 전송하여 많은 슬롯을 병렬로 이동하는 방식으로 효율성을 확보합니다. 이 과정에서 클러스터는 요청에 지속적으로 응답하여 이동 중인 슬롯에 대한 쓰기 처리량에 미치는 영향을 완화합니다. 마이그레이션 속도는 인스턴스 유형, 네트워크 속도, 슬롯에 대한 읽기/쓰기 트래픽 등에 따라 달라지며 일반적으로 분당 약 1GB입니다.

리샤딩 및 재분배 작업은 클러스터 모드를 활성화하여 만든 Redis 클러스터에 적용됩니다.

클러스터 리샤딩
일반적으로 메모리가 심각하게 부족하거나 개별 노드에서 병목 현상이 발생할 경우 리샤딩을 통해 클러스터를 확장해야 합니다. 클러스터의 CloudWatch 측정치를 조사하여 각 상황을 확인할 수 있습니다.

메모리 부족 – FreeableMemory, SwapUsage, BytesUsedForCache.

CPU 병목 현상 – CPUUtilization, CurrConnections, NewConnections.

네트워크 병목 현상 – NetworkBytesIn, NetworkBytesOut.

CloudWatch 대시보드를 사용하여 이러한 측정치를 모니터링하고 CloudWatch 경보를 사용하여 리샤딩 프로세스를 자동화할 수 있습니다.

ElastiCache 대시보드에서 Redis 클러스터를 리샤딩하려면 클러스터를 클릭하여 세부 정보 페이지를 방문한 다음 [Add shards] 버튼을 클릭합니다.

추가할 샤드 수와 (선택 사항)원하는 가용 영역을 입력한 다음 [Add]를 클릭합니다.

클러스터의 상태가 [modifying]으로 변경되고 리샤딩 프로세스가 시작됩니다. 위에 표시된 대로 이 작업은 몇 분에서 몇 시간까지 걸릴 수 있습니다. 클러스터에 대한 세부 정보 페이지에서 진행률을 추적할 수 있습니다.

샤드 간에 이동하는 슬롯을 볼 수 있습니다.

클러스터에 대한 이벤트를 확인할 수도 있습니다.

리샤딩 중에 클러스터 샤드에 대한 부하를 완화하기 위해 KEYSSMEMBERS 명령 및 컴퓨팅 집약적인 Lua 스크립트를 사용해서는 안 됩니다. 또한 FLUSHDBFLUSHALL 명령을 사용해서는 안 됩니다. 그러면 리샤딩 프로세스가 중단됩니다.

프로세스가 완료되면 각 샤드의 상태가 [available]로 되돌아갑니다.

샤드를 삭제할 때에도 동일한 프로세스를 수행합니다.

슬롯 재분배
클러스터의 세부 정보 페이지로 이동한 다음 [Rebalance Slot Distribution]을 클릭하여 이 작업을 수행할 수 있습니다.

알아야 할 것들
다음은 이 새로운 기능과 관련하여 몇 가지 알고 있어야 할 사항입니다.

  • 엔진 버전 – 클러스터에서 3.2.10 버전 Redis 엔진을 실행하고 있어야 합니다.
  • 마이그레이션 크기 – 직렬화 이후에 256MB를 초과하는 항목을 포함하는 슬롯은 마이그레이션되지 않습니다.
  • 클러스터 엔드포인트 – 클러스터 엔드포인트는 리샤딩 또는 재분배로 인해 변경되지 않습니다.

지금 이용 가능
이 기능은 지금 이용 가능하며 오늘부터 사용할 수 있습니다.

Jeff;

이 글은 Amazon ElastiCache Update – Online Resizing for Redis Clusters의 한국어 번역입니다.