AWS 비용 계산기가 새로 나왔습니다.

UI도 깔끔해졌고, 여러 리전을 그룹으로 지정해서 같이 계산도 가능합니다.

Edit Group으로 원하는 리전을 먼저 그룹으로 만들고 시작하세요.

EFS, nfs

cpio를 이런데 쓸줄이야. (사실 검색해보기 전까지는 backup용으로 쓰이던걸 몰랐다. Android fs 빼낼때나 썻지...)

fpart + cpio + GNU Parallel 은 참신하다. Amazon EFS 외에도 잘 써먹을 수 있겠다.

참고 :

원문 :

Amazon EFS Parallel File Transfer Test

AWS Storage Days | New York | September 6-8, 2017

Version 1.0

© 2017 Amazon Web Services, Inc. and its affiliates. All rights reserved. This work may not be reproduced or redistributed, in whole or in part, without prior written permission from Amazon Web Services, Inc. Commercial copying, lending, or selling is prohibited.

Errors or corrections? Email us at

Step-by-step Guide

Launch this environment to evaluate how the different instances types, I/O size, and thread count effects throughput to an Amazon EFS file system.

AWS CloudFormation template will launch:

  • Three Auto Scaling groups
  • Recommend using default instance types for each Auto Scaling group
    • t2.micro for Auto Scaling group 0
    • m4.large for Auto Scaling group 1
    • c4.xlarge for Auto Scaling group 2
  • Minimum and desired size for each Auto Scaling group is 1 (maximum 4)
  • Each Auto Scaling group instance will auto mount the identified Amazon EFS file system, generate 5GB of 1MB files & 5GB of 10MB files using smallfile, and install the following applications:
    • nload - is a console application which monitors network traffic and bandwidth usage in real time
    • smallfile - - used to generate test data; Developer: Ben England
    • GNU Parallel - - used to parallelize single-threaded commands; O. Tange (2011): GNU Parallel - The Command-Line Power Tool, ;login: The USENIX Magazine, February 2011:42-47
    • Mutil mcp - - multi-threaded drop-in replacement of cp; Author Paul Kolano (NASA)
    • fpart - - sorts file trees and packs them into partitions; Author Ganaël Laplanche
    • fpsync - wraps fpart + rsync - included in the tools/ directory of fpart

NOTICE!! Amazon Web Services does NOT endorse specific 3rd party applications. These software packages are used for demonstration purposes only. Follow all expressed or implied license agreements associated with these 3rd party software products.

WARNING!! If you build the above mentioned environment, this will exceed your free-usage tier. You will incur charges as a result of creating this environment and running these scripts in your AWS account. If you run this environment for 1 hour, you may incur a charge of ~$1.18.

You can launch this CloudFormation stack, using your account, in the following AWS Regions:

AWS Region CodeNameLaunch
us-east-1US East (N. Virginia)cloudformation-launch-stack
us-east-2US East (Ohio)cloudformation-launch-stack
us-west-2US West (Oregon)cloudformation-launch-stack
eu-west-1EU (Ireland)cloudformation-launch-stack
eu-central-1EU (Frankfurt)cloudformation-launch-stack
ap-southeast-2AP (Sydney)cloudformation-launch-stack

SSH to all three EC2 instances

Not all EC2 instances are created equal

Run this command against t2.micro

1. Write 17GB to EFS w/ 1MB block size

time dd if=/dev/zero of=/efs/dd/17G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=17408 conv=fsync &
nload -u M
While this is running, continue and run Step 2 in a separate terminal session.

Run this command against m4.large

2. Write 5GB to EFS w/ 1MB block size

time dd if=/dev/zero of=/efs/dd/5G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=5120 conv=fsync &
nload -u M

Maximize throughput using larger I/O size

Run the remaining commands against c4.xlarge

3. Write 2GB to EBS w/ 1MB block size - ‘sync’ once at the end

time dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=2048 status=progress conv=fsync
Record run time.

4. Write 2GB to EFS w/ 1MB block size - ‘sync’ once at the end

time dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=2048 status=progress conv=fsync
Record run time.

5. Write 2GB to EBS w/ 8MB block size - ‘sync’ once at the end

time dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=8M count=256 status=progress conv=fsync
Record run time.

6. Write 2GB to EFS w/ 8MB block size - ‘sync’ once at the end

time dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=8M count=256 status=progress conv=fsync
Record run time.

Sample run times

Step & CommandDuration
3. Write 2GB to EBS w/ 1MB block size - ‘sync’ once at the end22 seconds
4. Write 2GB to EFS w/ 1MB block size - ‘sync’ once at the end12 seconds
5. Write 2GB to EBS w/ 8MB block size - ‘sync’ once at the end22 seconds
6. Write 2GB to EFS w/ 8MB block size - ‘sync’ once at the end12 seconds
7. Write 2GB to EBS w/ 1MB block size - ‘sync’ after each block is written

time dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=2048 status=progress oflag=sync
Record run time.

8. Write 2GB to EFS w/ 1MB block size - ‘sync’ after each block is written

time dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=2048 status=progress oflag=sync
Record run time.

9. Write 2GB to EBS w/ 8MB block size - ‘sync’ after each block is written

time dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=8M count=256 status=progress oflag=sync
Record run time.

10. Write 2GB to EFS w/ 8MB block size - ‘sync’ after each block is written

time dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=8M count=256 status=progress oflag=sync
Record run time.

Sample run times

Step & CommandDuration
7. Write 2GB to EBS w/ 1MB block size - ‘sync’ after each block is written22 seconds
8. Write 2GB to EFS w/ 1MB block size - ‘sync’ after each block is written1 minute 43 seconds
9. Write 2GB to EBS w/ 8MB block size - ‘sync’ after each block is written22 seconds
10. Write 2GB to EFS w/ 8MB block size - ‘sync’ after each block is written48 seconds

Maximize throughput using parallel, multi-threaded access

Run the remaining commands against c4.xlarge

11. Write 2GB to EBS (4 threads of 512MB each) w/ 1MB block size - ‘sync’ after each block is written

time seq 0 3 | parallel --will-cite -j 4 'dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=512 oflag=sync'
Record run time.

12. Write 2GB to EFS (4 threads of 512MB each) w/ 1MB block size - ‘sync’ after each block is written

time seq 0 3 | parallel --will-cite -j 4 'dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=512 oflag=sync'
Record run time.

13. Write 2GB to EFS (4 threads of 512MB each) w/ 1MB block size - ‘sync’ once at the end

time seq 0 3 | parallel --will-cite -j 4 'dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=512 conv=fsync'
Record run time.

14. Write 2GB to EBS (8 threads of 256MB each) w/ 1MB block size - ‘sync’ after each block is written

time seq 0 7 | parallel --will-cite -j 8 'dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=256 oflag=sync'
Record run time.

15. Write 2GB to EFS (8 threads of 256MB each) w/ 1MB block size - ‘sync’ after each block is written

time seq 0 7 | parallel --will-cite -j 8 'dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=256 oflag=sync'
Record run time.

16. Write 2GB to EFS (8 threads of 256MB each) w/ 1MB block size - ‘sync’ once at the end

time seq 0 7 | parallel --will-cite -j 8 'dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=256 conv=fsync'
Record run time.

Sample run times

Step & CommandDurationThroughput
11. Write 2GB to EBS (4 threads of 512MB each) w/ 1MB block size - ‘sync’ after each block is written22 seconds~90 MB/s
12. Write 2GB to EFS (4 threads of 512MB each) w/ 1MB block size - ‘sync’ after each block is written26 seconds~77 MB/s
13. Write 2GB to EFS (4 threads of 512MB each) w/ 1MB block size - ‘sync’ once at the end12 seconds~167 MB/s
14. Write 2GB to EBS (8 threads of 256MB each) w/ 1MB block size - ‘sync’ after each block is written22 seconds~90 MB/s
15. Write 2GB to EFS (8 threads of 256MB each) w/ 1MB block size - ‘sync’ after each block is written14 seconds~143 MB/s
16. Write 2GB to EFS (8 threads of 256MB each) w/ 1MB block size - ‘sync’ once at the end12 seconds~167 MB/s

Maximize throughput - EFS parallel file transfer test

Run the remaining commands against c4.xlarge

Identify size of data set to be transferred.

du -csh /ebs/data-1m/
find /ebs/data-1m/. -type f | wc -l

Set variable

instanceid=$(curl -s

17. Transfer files from EBS to EFS using rsync

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
time rsync -r /ebs/data-1m/ /efs/rsync/${instanceid} &
nload -u M
Record throughput.

18. Transfer files from EBS to EFS using cp

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
time cp -r /ebs/data-1m/* /efs/cp/${instanceid} &
nload -u M
Record throughput.

Set variable

Set the threads variable to 4 threads per vcpu.
threads=$(($(nproc --all) * 4))

19. Transfer files from EBS to EFS using fpsync

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
time /usr/local/bin/fpsync -n ${threads} -v /ebs/data-1m/ /efs/fpsync/${instanceid} &
nload -u M
Record throughput.

20. Transfer files from EBS to EFS using mcp

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
time mcp -r --threads=${threads} /ebs/data-1m/* /efs/mcp/${instanceid} &
nload -u M
Record throughput.

21. Transfer files from EBS to EFS using efscp script (cp + GNU Parallel)

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
time /home/ec2-user/ /ebs/data-1m/ /efs/efscp ${threads} &
nload -u M
Record throughput.

22. Transfer files from EBS to EFS using fpart + cpio + GNU Parallel

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
time /usr/local/bin/fpart -Z -n 1 -o /home/ec2-user/fpart-files-to-transfer /ebs/data-1m
time parallel --will-cite -j ${threads} --pipepart --round-robin --block 1M -a /home/ec2-user/fpart-files-to-transfer.0 'sudo cpio -pdm {} /efs/parallelcpio/${instanceid}/' &
nload -u M
Record throughput.

Sample run times

Step & CommandDurationThroughput
17. Transfer 5000 ~1MB files from EBS to EFS using rsync10 minutes 3 seconds~8.3 MB/s
18. Transfer 5000 ~1MB files from EBS to EFS using cp7 minutes 55 seconds~10.5 MB/s
19. Transfer 5000 ~1MB files from EBS to EFS using fpsync4 minutes 38 seconds~18.6 MB/s
20. Transfer 5000 ~1MB files from EBS to EFS using mcp1 minute 40 seconds~50.0 MB/s
21. Transfer 5000 ~1MB files from EBS to EFS using cp + GNU Parallel1 minute 27 seconds~57.5 MB/s
22. Transfer 5000 ~1MB files from EBS to EFS using fpart + cpio + GNU Parallel1 minute 4 seconds~78.0 MB/s

Re-run steps 17-22, changing the source path from /ebs/data-1m to /ebs/data-10m to compare the throughput differences between small and large I/O size.


Delete all files on the EFS file system that were created using these scripts and delete the CloudFormation stack, so you don’t continue to incur additional charges for these resources.


The distributed nature of Amazon EFS enables high levels of availability, durability, and scalability. This distributed architecture results in a small latency overhead for each file operation. Due to this per-operation latency, overall throughput generally increases as the average I/O size increases, because the overhead is amortized over a larger amount of data. Amazon EFS supports highly parallelized workloads (for example, using concurrent operations from multiple threads and multiple Amazon EC2 instances), which enables high levels of aggregate throughput and operations per second.

For feedback, suggestions, or corrections, please email me at

메인프레임까지... ㅎㄷㄷ

 APN Blog 메인프레임 섹션 에 참조할 만한 많을 글이 있다.

클라우드 이전 시 많은 대기업 고객이 떨쳐버리지 못하는 걱정은 마이그레이션하고 나면 저 메인프레임(Mainframe)은 어떻게 해야 하는지에 대한 것입니다. 사실 클라우드 기반으로 설계된 워크로드는 수평적 확장성에 집중합니다. 즉, 컴퓨팅 처리 용량이 필요해지면 수요를 충족하기 위해 인스턴스를 추가하면 됩니다. 이에 반해 많은 레거시 시스템은 필요에 따라 더 크고 더 강력한 시스템을 추가하는 수직적 확장을 염두에 두고 설계되었으며, 결국 대기업에서 가장 중요한 워크로드는 메인프레임을 선정하고, 대체로 뛰어난 성능과 안정성을 제공했기 때문에 성공적입니다.

이 글은 메인프레임 워크로드를 클라우드로 마이그레이션하는 데 관심이 있는 기업들이 선택할 수 있는 여러 방안을 설명합니다.

왜 메인프레임이 아니고 클라우드인가?

대기업 고객에게는 기존 메인프레임을 AWS 클라우드로 마이그레이션하는 사업상 이유가 있습니다. 하지만, 메인프레임 현대화 프로젝트는 대체로 인내심과 강력한 리더십, 그리고 의도한 ROI를 달성할 탄탄한 접근 방법이 필요합니다. 기존에 AWS 클라우드로 이전하는 고객 프로젝트에서 성공을 거둔 경험을 바탕으로 우리는 새 메인프레임을 AWS로 이전하는 이니셔티브를 촉진하는 패턴, 교훈, 모범 사례를 파악했습니다.

우리는 고객이 AWS로 메인프레임 워크로드를 현대화하려는 여러 이유가 있음을 알게 되었습니다. 첫째, 비용 절감은 분명 메인프레임에서 AWS로 워크로드를 이전하는 데 따라오는 강력한 이점입니다. 자본 지출과 MIPS(millions of instructions per second)를 제거하고, 독립 소프트웨어 공급업체(ISV) 라이선스 비용을 줄이며, 탄력적 요금 모델을 활용할 수 있기 때문입니다. 둘째, 연속 통합 및 지속적인 업데이트(CI/CD)와 온디맨드로 사용하는 거의 무한한 인프라 리소스를 통해 개발 주기가 단축되어 민첩성을 얻게 됩니다. 셋째, 수십 년간의 비즈니스 거래가 포함되어 경쟁 차별화 요소를 모색하는 데이터 분석 또는 머신 러닝 이니셔티브를 제공할 수 있는 메인프레임 데이터 활용에 따른 장점이 있습니다. 마지막 네 번째로 AWS 클라우드로 이전을 통해 메인프레임 퇴역에 따른 기술 격차를 해결하고 새로운 인재를 유치하여 핵심 비즈니스 워크로드를 현대화할 수 있습니다.

AWS 클라우드를 통한 메인프레임 현대화에는 한 가지 해결책이 없습니다. 대기업 고객은 비즈니스 및 IT 전략에 따라 메인프레임 특유의 기술적 제약에 따라 가장 적합한 패턴을 선택해야 합니다. 메인프레임이 여러 워크로드를 처리할 만큼 크다면 각 워크로드의 특성마다 유리한 패턴이 다를 수 있습니다. 워크로드 자체가 특정 프로그램이나 데이터와 독립적일 경우에는 쉽게 파악할 수 있습니다. 하나의 메인프레임 내에서 안정화된 애플리케이션이 따르는 패턴이 있기도 하고, 계속해서 변화 중인 애플리케이션은 다른 패턴에 따를 수 있습니다. 이처럼 워크로드마다 적합한 여러 전략을 선택할 수 있다는 점이 위에서 설명한 네 가지 동인, 그중에서도 비즈니스 민첩성과 기술 격차를 활용하는 것이 고객이 성공을 거두는 비결입니다.

이를 바탕으로 AWS 고객 중 메인 프레임을 이전한 성공적인 패턴 몇 가지를 소개합니다.

패턴 1: 자동 리팩터링을 통한 단기 마이그레이션

자동 리팩터링은 레거시 스택(예: COBOL 기반)을 새로운 스택(예: Java 기반 또는 .Net 기반)으로 변환하기 위해 리버스 엔지니어링과 포워드 엔지니어링을 모두 자동화합니다. 효율성과 품질을 위해 이 변환에는 최대한 많은 자동화가 있지만 수동 코드 재작성은 없습니다. 일반적으로 이로 인해 애플리케이션은 클라우드 네이티브 애플리케이션과 비슷한 열 두가지 앱 모범 사례에 따라 다양한 AWS 서비스를 통해 탄력성, 수평적 확장성, 보다 간편한 통합을 제공합니다.

그림 1: 자동 리팩터링을 통한 단기 마이그레이션

이 패턴을 기본적인 줄 단위 코드 변환(예를 들어, 절차형 COBOL을 절차형과 유사한 Java(혹은 JOBOL)로 변환하는 것으로 유지 관리와 통합이 어려운 변환 작업)을 수행하는 언어 변환 도구와 혼동하면 안 됩니다. 자동 리팩터링 도구는 코드, 데이터 액세스, 데이터 스토어, 프레임워크, 트랜잭션 하위 시스템, 의존성 호출을 포함한 전체 레거시 스택을 분석하고 변환하는 종합적 접근 방법을 취합니다. 여기서 자동으로 생성되는 일관되고 기능적으로 동등한 대상 스택은 서비스 지향적이고 서비스 가능할 뿐 아니라 AWS 서비스를 위한 패키징된 최적화를 갖추고 있습니다. 또 마이크로서비스 생성을 위한 서비스 분해도 촉진합니다.

자동 리팩터링 도구의 가치와 차별화 요소는 주로 자동화된 포워드 엔지니어링 기능에 달려 있습니다. 리버스 엔지니어링 기능을 갖춘 도구는 많지만 강력하고 광범위한 포워드 엔지니어링 자동화를 갖춘 도구는 거의 없습니다.

일례로 미 국방부의 한 고객은 전체 메인프레임 COBOL 및 C-logistics 시스템(수백만 줄의 코드)을 AWS에서 Java로 자동으로 리팩터링하여 레거시 코드의 기술적 부채를 제거했습니다. APN 블로그는 ‘Blu Age와 AWS를 사용하여 메인프레임 배치를 클라우드 마이크로서비스로 마이그레이션하는 방법‘과 ‘클라우드 네이티브 Heirloom PaaS가 포함된 AWS의 고성능 메인프레임 워크로드‘에서 몇 가지 자동 리팩터링 도구를 보여 줍니다.

패턴 2: 에뮬레이터 리호스팅을 통한 단기 마이그레이션

이 패턴은 AWS 클라우드에서 실행되는 에뮬레이터에 대한 리플랫폼(re-platform)입니다. 이 접근 방법을 사용하면 레거시 애플리케이션 코드가 코드 변경이 최소화된 상태로 에뮬레이터로 이전되므로 동일한 애플리케이션 유지 관리 및 개발 기술이 유지되고 필요합니다. 이 마이그레이션은 최종 사용자의 관점에서 매끄러우며, 애플리케이션의 인터페이스와 룩 앤 필을 동일하게 유지합니다.

그림 2: 에뮬레이터 리호스팅을 통한 단기 마이그레이션

일반적으로 지원되는 소스 코드는 다시 컴파일되며 지원되지 않는 언어 코드는 먼저 지원되는 언어로 변환된 다음 다시 컴파일됩니다. 다른 타사 유틸리티 인터페이스와 통합하거나 그 과정에서 데이터 스토어 및 데이터 액세스를 현대화할 때는 코드 변경 또는 리팩터링이 필요합니다. 이 패턴의 경우, 도구에는 에뮬레이터와 컴파일러뿐 아니라 프로그램 및 데이터 마이그레이션 자동화에 필요한 유틸리티도 포함됩니다.

이 패턴을 더 큰 현대화 여정 내의 중간 단계 또는 안정화된 애플리케이션의 목표 상태로 보기도 합니다. 일례로 한 다국적 음료 회사는 AWS에서 에뮬레이터를 사용하여 배치 모드 및 온라인 트랜잭션 처리 기능을 다시 만들어 마이그레이션하면서 동일한 메인프레임 그린 스크린 경험을 제공했습니다. APN 블로그는 ‘NTT DATA 서비스를 사용하여 메인프레임 애플리케이션을 AWS로 리호스팅‘ 및 ‘5단계로 메인프레임을 AWS로 마이그레이션하기‘에서 몇 가지 에뮬레이터 도구를 보여 줍니다.

패턴 3: 데이터 분석을 통한 증설

이 패턴은 워크로드 마이그레이션이 아니라 AWS에서 민첩한 데이터 분석 서비스를 사용하는 메인프레임 증설에 대한 것입니다. 엄청나게 많은 사용자의 수십 년에 걸친 과거 비즈니스 트랜잭션이 포함될 수 있는 메인프레임 데이터는 강력한 비즈니스 장점입니다. 이에 따라 고객들은 빅 데이터 분석을 사용하여 메인프레임 데이터의 비즈니스 가치를 높입니다. 메인프레임이라는 대안에 비해 AWS의 빅 데이터 서비스를 사용하면 보다 빠른 분석 기능을 얻을 수 있으며, 데이터 레이크를 만들어 구조화된 데이터와 구조화되지 않은 데이터를 혼합하고 회사 데이터 자산에 대한 한층 더 종합적인 관점을 제공할 수 있습니다.

그림 3: 데이터 분석을 통한 확대

AWS는 수집부터 처리, 저장, 분석, 시각화, 자동화까지 전체 데이터 수명 동안 서비스를 제공합니다. 복제 도구는 메인프레임의 관계형, 계층적 또는 레거시 파일 기반 데이터 스토어에서 민첩한 AWS 데이터 레이크, 데이터 웨어하우스 또는 데이터 스토어로 메인프레임 데이터를 실시간으로 복사합니다. 이 실시간 복제로 데이터가 새것으로 유지되고 최신 분석과 대시보드가 가능해지며, 메인프레임은 레코드 원본으로 유지합니다.

일례로 미국의 한 여객 철도 회사는 이 절에서 설명한 패턴에 따라 판매, 마케팅, 수익, 사기 분석을 위한 실시간 대시보드와 보고를 통해 메인프레임 데이터를 활용했습니다. APN 블로그에서는 ‘AWS 및 Attunity Replicate로 메인프레임 데이터를 활용하는 방법‘을 통해 실시간 데이터 복제를 보여 줍니다.

패턴 4: 새로운 채널을 통한 확대

레거시 언어를 사용한 메인프레임 개발 주기는 느리고 융통성이 없기 때문에 고객들은 AWS를 사용하여 새로운 서비스를 신속히 구축하면서 로컬 AWS 데이터 스토어에 있는 실시간 메인프레임 데이터에 액세스합니다. 이것은 패턴 3의 변형으로서 로컬 메인프레임 데이터를 분석이 아니라 최종 사용자용 신규 통신 채널과 신규 기능에 사용합니다. AWS의 민첩한 새 기능은 레거시 메인프레임 애플리케이션을 확대합니다. 새로운 채널의 예는 모바일 또는 음성 기반 애플리케이션일 수도 있고, 마이크로서비스 또는 머신 러닝에 기반한 혁신일 수도 있습니다.

그림 4: 새로운 채널을 통한 확대

이 패턴은 AWS에서 새로운 채널을 배포하여 값비싼 메인프레임 MIPS 증가를 방지합니다. 데이터가 복제되기 때문에 데이터 아키텍트는 메인프레임과 AWS 데이터 스토어에서 잠재적인 데이터 일관성 또는 무결성 문제에 주의해야 합니다.

일례로 미국의 한 대형 상업 은행은 AWS에서 새로운 Lambda 기반 서버리스 마이크로서비스를 개발하여 DynamoDB에 있는 복제된 메인프레임 데이터에 액세스하고 이 새로운 서비스를 API 게이트웨이를 통해 모바일 사용자에게 제공했습니다. 이 패턴의 도구는 패턴 3 도구와 비슷하며, 레거시 데이터 스토어 또는 메인프레임 메시징 시스템에서 실시간 데이터 복제를 수행합니다.

메인 프레임 이전 과정 및 모범 사례

우리는 과거 프로젝트, 고객, 파트너 경험에서 배운 것을 토대로 메인프레임을 개발해 AWS 모범 사례로 개선하고 있습니다.

  1. 신기술 적용 테스트 (POC) – AWS로 이전할 메인프레임 워크로드의 가장 복잡한 기술적 측면을 해결할 수 없으면 프로젝트는 실패할 수 있습니다. 위험을 줄이려면 고객은 복잡한 POC를 요청해 고객만의 가장 어려운 시나리오로 도구 기능을 평가해야 합니다. 이것은 POC 범위가 커야 한다는 뜻이 아니라 소수의 POC 테스트 케이스가 최대한 세밀해야 한다는 뜻입니다. 고객 메인프레임 워크로드에 따라 배치 기간, 다수의 프로그램 및 데이터 의존성, 비지니스 논리, 일반적이지 않은 레거시 기술 또는 버전, 지연 시간 요구 사항, 높은 초당 처리량이나 트랜잭션 또는 많은 양의 코드나 데이터에 있을 수 있습니다. 세밀한 POC는 도구의 능력을 검증하고, 도구 결과물의 품질을 보여 주며, 도구 공급업체와 고객에게 성공적인 협업을 보증합니다.
  2. 자동화 – 메인프레임은 일반적으로 수백만 줄의 코드와 페타바이트 규모의 데이터를 호스팅합니다. 사람의 개입은 오류, 위험, 테스트, 기간, 비용을 늘립니다. 따라서 단기 현대화 프로젝트는 수동으로 재작성 없는 최대한의 자동화와 함께 입증된 소프트웨어 스택을 사용합니다. 이러한 자동화에는 마이그레이션 규칙을 적용하기 위한 자동화, 코드 리팩터링을 위한 자동화, 데이터 현대화를 위한 자동화, 테스트 실행을 위한 자동화(CI/CD 파이프라인)가 포함됩니다.
  3. 패턴, 도구, 아키텍처, 활동 순서 결정 – 개별 이전 패턴은 전체 접근 방법의 틀을 잡으며, 패턴마다 다른 도구 세트가 필요합니다. 개발 도구는 메인프레임 현대화의 중요한 성공 요인이며, 가능한 한 일찍 세밀한 POC를 사용하여 기술적으로 테스트해야 합니다. 도구가 검증되면 도구와 AWS 모범 사례를 바탕으로 전체 아키텍처가 생성됩니다. 그 다음에는 기술적 아키텍처가 현대화 구현 활동을 주도합니다.
  4. 벤더 중립적인 패턴 선택 – 메인프레임 현대화에서 모든 경우에 두루 적합한 단일 방법이나 단일 도구는 없습니다. 도구 공급업체들은 한 가지 패턴에만 집중하는 경향이 있습니다. 또한 패턴마다 여러 공급업체와 도구가 존재합니다. 따라서 패턴 선택은 공급업체 제약이 없어야 하고(vendor agnostic), 고객의 비즈니스 및 IT 전략 우선 순위와 고객 메인프레임 스택의 기술적 제약이 중심이 되어야 합니다.
  5. 시스템 통합 사업자 선택 – 컨설팅 및 시스템 통합 서비스 회사는 AWS로의 메인프레임 현대화 프로젝트의 모든 단계에서 다양한 정도로 도움을 줄 수 있습니다. 오직 한 가지 패턴과 선호하는 한 가지 도구에만 특화되어 있는 시스템 통합 사업자가 있는가 하면 여러 패턴과 패턴별로 여러 도구를 아우르는 시스템 통합 사업자도 있습니다. 현대화 도구 선택에 앞서 한 가지 특정 도구에 대한 시스템 통합 사업자의 전문성이 아닌 고객의 최선의 이익을 기준으로 패턴과 도구에 대해 조언하려면 컨설팅 전문 서비스가 패턴 중립적이고 공급업체 중립적이어야 합니다. 다른 한편 일단 고객 시스템 통합 사업자가 도구를 선택하고 나면 전문 서비스는 선택된 메인프레임 현대화 도구와 AWS 관련 전문성을 갖춰야 합니다. 관련된 기능이 다양하기 때문에(컨설팅, 메인프레임, AWS, 현대화, 도구, 통합, 테스트) 팀 또는 전문 서비스 회사의 연합이 참여하는 것을 흔히 볼 수 있습니다.
  6. 레거시 데이터 스토어 현대화 – AWS에서 계층적 데이터베이스 또는 색인 데이터 파일 같은 레거시 데이터 스토어를 유지하면 단일 장애 지점, 병목 현상 또는 낡은 데이터 모델 같은 레거시 기술 부채와 제약 및 인터페이스가 그대로 유지됩니다. 어떤 패턴이건 데이터 스토어 및 데이터 액세스 계층 현대화는 일반적으로 소규모 투자를 통해 확장성, 가용성, 민첩성, 운영, 기술, 비용 절감, 데이터 통합 및 새로운 기능 개발을 위한 더 큰 이득을 제공합니다.
  7. 워크로드 기반 현대화 – 여러 독립적 워크로드를 호스팅하는 대규모 메인프레임의 경우, 워크로드마다 서로 다른 현대화 패턴에 따를 수 있습니다.
  8. 기술적 이전과 비즈니스 팀과 동시 협업– 이전 도구는 일반적으로 빠르게 기술적인 현대화에 우선 최적화되어 있습니다. 비즈니스 수준의 변경 또는 리팩터링에는 수동 개입과 비즈니스 팀의 참여가 필요하며, 메인프레임과 AWS 사이에서 몇 가지 기능적 동등성 테스트를 수행할 수 없습니다. 따라서 비즈니스 현대화와 기술적 현대화를 동시에 혼용하면 복잡성, 기간, 위험, 비용이 증가합니다.
  9. 도구 평가 방식 정의 – 레거시 기술 스택 지원, 복잡한 POC 성공, IT 전략 정렬, 프로젝트 속도(매달 마이그레이션되는 코드 줄 수 등), 대상 애플리케이션 스택 민첩성, 대상 데이터 스토어 민첩성, 대상 코드 유지 관리, 코드 줄당 마이그레이션 비용, 대상 스택 라이선스 비용, 투자 수익(ROI) 속도 등을 정의해야 합니다.
  10. 이전 및 실행 시간 비용 추정 – 현대화 비용에는 현대화 과정에서 사용하는 도구의 라이선스 비용과 현대화 활동에 필요한 전문 서비스 비용이 포함됩니다. 여기에 더해 ROI 속도에 직접 영향을 미치는 대상 아키텍처의 반복적 실행 시간 비용이 중요합니다. 실행 시간 비용에는 도구 라이선스 비용(있는 경우)과 AWS 서비스 비용이 포함됩니다. 예를 들어 고객이 반복적인 연간 실행 시간 비용을 80% 줄이는 경우, 3년 후에 현대화 비용을 회수할 수 있어 그 이후로는 신규 투자에 사용할 수 있는 상당한 절감이 발생합니다.


최근 대기업 고객들은 AWS를 활용하여 메인프레임을 현대화합니다. 이 글에서 알려드린 패턴, 모범 사례, 파트너 프로그램 등이 이러한 프로젝트를 성공적으로 이끌고 있습다. 여러분이 메인프레임 현대화 프로젝트에 관심이 있으시다면, 여러 모로 도움이 되기를 바랍니다. 클라우드 이전을 시작하시려면 다음 조치를 취하는 것이 좋습니다.

  1. 비즈니스 및 IT 우선 순위와 더불어 메인프레임의 기술적 아키텍처를 수집합니다.
  2. 가능한 AWS 현대화 패턴을 이해하고 선호하는 패턴을 결정합니다.
  3. 선택한 패턴과 메인프레임 특성을 가장 잘 지원하는 도구와 공급업체를 파악합니다.
  4. 도구의 가치 제안을 평가하고 복잡한 개념 증명을 사용하여 선택을 확인합니다.

AWS로의 메인프레임 마이그레이션에 대해 자세히 알아보려면 언제든지 문의하십시오. APN Blog 메인프레임 섹션에서 우리 파트너의 가치 제안을 검토해 보십시오. 메인프레임이 아닌 레거시 AS/400 또는 iSeries 또는 IBM i 시스템을 위한 유사한 패턴과 모범 사례도 있습니다.

Amazon Aurora- MySQL은 데이터베이스 워크로드를 통합(Database consolidation)하려는 고객에게 인기 있는 옵션입니다. Aurora MySQL은 고성능 상용 데이터베이스의 속도와 안정성에 오픈 소스 데이터베이스의 간편성과 비용 효율성이 결합된 관계형 데이터베이스 엔진입니다. 또한, 표준 MySQL 커뮤니티 에디션과 비교하여 최대 5배의 처리량을 제공합니다.

이 블로그 게시물에서는 대규모 통합 데이터베이스 워크로드를 위해 Amazon Aurora를 최적화하는 데 도움이 되는 몇 가지 지침을 제공합니다. 또한, “얼마나 많은 DB를 통합할 수 있습니까?” 혹은 “데이터 세트가 얼마나 커질 수 있습니까?”와 같은 일반적인 질문에 대한 답을 제공합니다. 이러한 질문이 간단하긴 하지만 답 또한 항상 간단한 것은 아닙니다. 답은 데이터 세트와 워크로드 패턴에 따라 크게 좌우됩니다.

데이터베이스 통합 정의

통합 사용 사례의 경우, 다음 차원에 초점을 맞춘 후 Aurora MySQL이 이러한 컨텍스트에서 어떻게 작동하는지를 자세히 설명합니다.

  1. 테이블 크기. 더 큰 테이블은 일반적인 통합의 결과입니다. 광고 기술, IoT 또는 소비자 애플리케이션 분야라면 대개 대규모 동종 애플리케이션 데이터베이스를 데이터 하위 집합이 포함된 여러 개의 샤드로 분할합니다. Aurora에서는 샤딩을 완전히 포기할 수는 없지만 더 적은 수의 샤드로 통합하여 운영 오버헤드를 줄일 수 있습니다.
  2. 테이블 수. 늘어난 테이블 수 또한 통합의 결과입니다. 이러한 결과는 테넌트 격리가 필요한 SaaS 애플리케이션, 즉 각 테넌트가 자체 데이터베이스 또는 테이블 세트를 사용하는 SaaS 애플리케이션에서 일반적으로 발생합니다. 이러한 유형의 멀티 테넌트는 더 적은 수의 더 큰 Aurora 클러스터로 함께 패키징되어 테넌트당 운영 비용을 줄입니다.
  3. 데이터베이스 사용률. 동시 연결 수 증가를 비롯하여 여러 지표에서 통합된 데이터베이스 워크로드 사용률이 증가합니다.

실제로 동일한 프로젝트에서 이러한 차원 중 몇 가지가 증가하는 것을 경험하게 됩니다. 다음 지침은 이러한 차원 전체에서 워크로드를 최적화하는 데 도움이 됩니다.

데이터베이스의 최대 크기

Amazon Aurora에는 몇 가지 최대 한도가 있습니다. 가장 눈에 띄는 것은 Aurora 클러스터의 최대 스토리지 볼륨 크기가 64TB라는 것입니다. 볼륨 최대 크기는 Aurora 클러스터에 물리적으로 저장할 수 있는 데이터 양에 대한 상한을 제공합니다. 또한, 개별 테이블 크기에 대한 상한도 제공합니다.

MySQL 호환 데이터베이스 엔진인 Aurora MySQL은 MySQL과 InnoDB 스토리지 엔진의 속성을 다수 상속받습니다. 이 중 일부가 효과적으로 통합할 수 있는 양에 영향을 미칩니다.

테이블 크기를 최적화하는 방법

Amazon Aurora는 16KiB 페이지를 사용하여 데이터를 저장합니다. 페이지는 테이블과 관련 인덱스의 컨테이너 역할을 하는 테이블스페이스로 그룹화됩니다. 기본적으로 Aurora는 테이블별로 또는 테이블이 파티션된 경우 테이블의 파티션별로 별도의 테이블스페이스를 사용합니다. 테이블스페이스에 주로 포함된 것은 다음과 같은 데이터 구조입니다.

  • 테이블 레코드가 포함되어 있고 테이블의 기본 키 또는 고유 키로 정렬된 클러스터링된 인덱스. 두 키 모두 사용할 수 없는 경우, 일정하게 증가하는 내부 행 ID가 레코드를 식별하고 정렬하는 데 사용됩니다.
  • 테이블의 보조 인덱스.
  • 클러스터링된 인덱스 레코드에 적합하지 않은 가변 길이 필드에 대한 외부 저장 값(BLOB, TEXT, VARCHAR, VARBINARY 등).

앞의 테이블 아키텍처는 주어진 테이블에 저장할 수 있는 최대 행의 수가 정해져 있지 않다는 것을 의미합니다. 최대 행 수는 몇 가지 요인에 따라 달라집니다.

  • 기본 키 또는 고유한 키 옵션에서 지원하는 최대 고유 값 수. 예를 들어 기본 키에 부호 없는 INT 데이터 유형을 사용하는 경우(일반적인 선택), 테이블에서 최대 232 또는 최소 42억 9천 개의 행을 지원합니다.
  • 보조 인덱스의 수 및 크기.
  • 클러스터링된 인덱스 레코드에 직접 또는 외부 페이지에 저장된 가변 길이 데이터 양.
  • 데이터 페이지가 얼마나 효과적으로 사용되는지.

스키마 디자인 및 쿼리 패턴은 실제로 얼마나 효과적으로 테이블을 통합할 수 있는지를 결정할 때 행 수보다 중요한 요인입니다. 테이블의 행 수가 증가하면 클러스터링된 인덱스 및 보조 인덱스의 크기와 이러한 인덱스를 트래버스하는 데 걸리는 시간도 증가합니다. 따라서 쿼리 성능은 테이블 크기에 따라 감소합니다. 성능 저하를 좀 더 심층적으로 완화할 수 있는 몇 가지 모범 사례와 방법을 살펴보겠습니다.

1. 대량 레코드 포함 테이블을 위한 스키마 설계

쿼리 패턴 및 스키마의 컨텍스트에서 페이지당 레코드 밀도는 큰 테이블 크기에서 점점 더 중요해집니다. 가변 길이를 제외하고 Aurora MySQL의 최대 행 길이는 8KB에 약간 못 미칩니다(데이터 페이지의 절반). 데이터베이스는 페이지를 관리하여 성능 저하 없이 스토리지 효율성을 유지합니다. MySQL 커뮤니티 에디션의 InnoDB처럼 Aurora MySQL은 향후 쓰기 작업을 수용하고 페이지 분할 수를 줄이기 위해 페이지 일부를 채우지 않고 비워둡니다. 또한, 채우기 비율이 50% 이하로 떨어지면 페이지를 함께 병합하려고 시도합니다. 페이지가 완전히 채워지는 경우는 없으므로 항상 일정량의 스토리지 오버헤드가 발생합니다.

최적의 스키마 디자인은 유용한 오버헤드가 과도한 스토리지 낭비가 되지 않도록 보장하는 최선의 방법입니다. 이러한 낭비는 리소스 사용률과 지연 시간 증가로 이어지므로, 수용 가능한 성능 이상으로 워크로드에 부담을 줍니다.

효과적인 스키마 디자인을 위한 두 가지 매우 중요한 지침이 있습니다.

  1. 주어진 테이블 행의 모든 정보의 가치는 모두 같아야 합니다. 즉, 행의 모든 필드에 있는 데이터를 동일한 빈도로 쿼리하고 조작해야 합니다. 동일한 행에 사용 빈도가 다른 데이터를 저장하는 것은 비효율적입니다.
  2. 항상 주어진 열에 저장된 값을 나타낼 수 있는 가장 작은 데이터 유형을 선택하십시오. 개별 행 수준에서는 효과가 미비할 수 있지만, 잠재적으로 수십억 개의 행에서는 그 효과가 확대되어 현저한 차이를 보입니다.

스키마에 가변 길이 필드가 포함된 경우, Aurora MySQL은 가능한 많은 가변 길이 데이터를 클러스터링된 인덱스 레코드에 저장하려고 시도하며 나머지는 외부 페이지에 저장됩니다. 대규모 데이터 레코드는 데이터 페이지의 레코드 밀도를 낮추어 쿼리 성능을 저하시킵니다. 하지만 쿼리가 가변 길이 필드를 비롯하여 모든 레코드 데이터(읽기 및 쓰기)에 지배적인 영향을 미치는 경우 여전히 대규모 레코드를 원할 수도 있습니다. 그런 경우가 아니라면 대규모 필드는 별도 테이블로 오프로드하는 것이 유용할 수 있습니다. 또는 데이터베이스가 아닌 Amazon S3와 같은 객체 스토어에 저장하는 것이 더 좋습니다.

인덱스는 쿼리 성능을 높이는 데 효과적입니다. 하지만 추가 비용이 발생하고 추가 스토리지와 메모리 공간을 소비하며 쓰기 성능을 저하시킵니다. 보조 인덱스 레코드는 열의 물리적 스토리지 좌표를 직접 가리키지 않습니다. 대신에 해당 열의 기본 키 값을 가리킵니다. 따라서 모든 보조 인덱스 레코드에는 해당 행의 기본 키 값 사본이 포함되어 있습니다.

이에 따라 복합 기본 키로 인해 더 큰 인덱스 레코드가 생기고 궁극적으로 스토리지 및 I/P 효율성이 떨어집니다. 필요한 인덱스만 사용하고 복합 인덱스에서 인덱스 선택은 왼쪽에서 오른쪽으로 이동한다는 것을 기억하십시오. 쿼리 패턴에서 해당 선택 규칙을 따르도록 허용하는 경우, 인덱스를 더 적은 수의 복합 인덱스로 대체하여 인덱스 수를 줄일 수 있습니다.

궁극적으로 효과적인 스키마 디자인을 사용하면 수용할 수 없는 성능을 경험할 필요 없이 더 많은 수의 행이 있는 테이블을 보유할 수 있습니다. 하지만 최대 행 수가 몇 개가 될지는 실제 데이터 및 해당 데이터와 상호 작용하는 방법에 달려 있습니다.

2. 대량 레코드 포함 테이블 쿼리

파티션(및 하위 파티션)은 대규모 테이블에서 성능 감소를 완화하는 도구입니다. 기본적으로 각 파티션은 별도의 테이블스테이스에 저장되므로, 파티션에는 파티셔닝 표현식에 정의된 대로 클러스터링된 인덱스, 보조 인덱스, 해당 특정 데이터 하위 세트의 외부 페이지가 포함되어 있습니다. 테이블당 최대 8,192개의 파티션 및 하위 파티션을 가질 수 있습니다. 하지만 파티션 수가 많으면 그 자체로 성능 문제가 발생합니다. 많은 수의 파티션을 사용하는 쿼리로 인해 메모리 사용률이 증가하고 성능 문제가 발생하는 것이 이에 포함됩니다.

파티션의 인덱스 구조가 더 작으므로 트래버스하는 것이 더 빠릅니다. 쿼리 패턴이 단일 파티션 또는 매우 작은 파티션 세트를 선택적으로 읽는 경우(파티션 프루닝(partition pruning)이라고 부르는 최적화 기능), 성능 이점을 누릴 수 있습니다. 하지만 예를 들어 파티션된 열이 포함되지 않은 조건자가 있는 쿼리처럼 일부 특정 파티션만 선택적으로 읽지 않는 쿼리는 속도가 더 느릴 수 있습니다. 파티션에서는 엔진이 하나의 더 큰 인덱스 대신 여러 개의 더 작은 인덱스를 트래버스해야 하므로 이 효과가 발생합니다. 따라서 파티션된 대규모 테이블의 성능 영향은 워크로드에서 파티션 프루닝 또는 파티션 셀렉션을 얼마나 효율적으로 활용하는지에 달려 있습니다.

대규모 테이블의 경우 정확한 통계가 쿼리 옵티마이저에 중요합니다. 정확한 통계는 쿼리 옵티마이저가 올바른 카디널리티로 가장 선별된 인덱스를 사용하도록 지원하므로 쿼리 성능이 향상됩니다. 기본적으로 Aurora MySQL은 20개의 임의 인덱스 페이지를 샘플링하여 통계와 카디널리티를 예측합니다. 하지만 매우 큰 테이블 또는 열 내 값이 균일하지 않은 테이블을 처리할 때는 이 개수로는 충분하지 않을 수 있습니다. 또한, 기본적으로 통계는 디스크에 유지되고 테이블의 상당 부분이 변경되면 자동으로 다시 계산됩니다. 10% 이상의 행에 영향을 미치는 DML(데이터 조작 언어) 작업을 예로 들 수 있습니다.

매우 큰 테이블에서는 이 정도 규모의 변경은 자주 발생하지 않으므로 시간이 지나면서 통계의 정확도가 감소할 수 있습니다. 따라서 임계점에 도달하고 쿼리 옵티마이저가 실행 계획을 변경하면 영향을 받은 쿼리의 성능이 시간이 지나면서 계속해서 또는 급격히 저하됩니다. 이것이 문제가 된다고 생각하는 경우, EXPLAIN 문을 사용하여 쿼리 실행 계획을 검토하여 예상되는 동작의 변경 사항을 찾아내십시오.

또한, 핵심 워크로드 쿼리의 예상 성능 기준선을 설정하고 시간이 지나면서 성능을 모니터링하는 것이 좋습니다. 느린 쿼리 로그는 특정 임계값을 초과하는 쿼리를 로깅하는 데 효과적이지만, 시간 경과에 따라 천천히 진행되는 성능 저하를 캡처하는 데는 효과적이지 않습니다. MySQL 5.6 호환 버전에서 지속적으로 쿼리 성능을 모니터링하려면 MySQL 성능 스키마를 사용하면 됩니다. 하지만 이 기능을 활성화하면 메모리 소비가 증가하고 전반적인 시스템 성능도 저하될 수 있습니다.

통계의 정확성을 개선할 수 있는 두 가지 메커니즘이 있습니다.

  1. 정보 스키마를 사용하여 관련 테이블에 대한 테이블 및 인덱스 통계의 경과 시간을 모니터링(INNODB_TABLE_STATS 및 INNODB_INDEX_STATS)한 후 ANALYZE TABLE을 실행하여 적절하게 통계를 업데이트합니다.
  2. DB 인스턴스에 대한 DB 파라미터 그룹을 사용자 지정하고 샘플링되는 페이지 수를 늘리면 정확도가 증가합니다(아래 표 참조). 하지만 샘플링되는 페이지를 늘리면 통계를 계산하는 데 걸리는 시간 또한 늘어납니다.
DB 파라미터설명
innodb_stats_persistent_sample_pages256통계가 디스크에 유지되는 경우 샘플링된 페이지에 대한 글로벌 파라미터. 이 파라미터를 테이블별로 구성할 수도 있습니다.
innodb_stats_transient_sample_pages256위에 있는 것과 비슷하지만 통계가 디스크에 유지되지 않는 경우 사용되는 글로벌 파라미터.

3. 대규모 테이블의 데이터 스키마에 대한 변경 처리

DDL(데이터 정의 언어) 작업이 문제가 되려면 테이블이 얼마나 커야 합니까? 크기도 한 요인이지만 테이블이 얼마나 활발하게 사용되는지가 더 중요할 수 있습니다. 테이블이 초당 수천 개의 쓰기 작업을 지원하고 있다면, 상대적으로 레코드 수백만 개의 상대적으로 작은 테이블도 DDL 작업을 실행하기에 문제가 될 수 있습니다.

워크로드 또는 워크로드에 대한 업데이트가 빈번한 DDL 작업 및 스키마 변경에 의존하는 경우, 이러한 작업으로 인해 매우 큰 테이블을 사용할 수 있는 기능이 제한될 수 있습니다. 이 동작은 MySQL 커뮤니티 에디션이 작동하는 방식과 비슷합니다. 오프라인 DDL 작업은 데이터를 올바른 스키마의 새로운 테이블스페이스로 복사합니다. 따라서 적절한 여유 용량을 확보해야 합니다. 또한, 작업 범위에 따라 테이블이 잠기므로 일반 워크로드에 영향을 줍니다. 온라인 DDL 작업은(수행 가능한 경우) 테이블 데이터를 직접 변경합니다. 하지만 임시 스페이스에서 테이블에 대한 새로운 쓰기를 버퍼링하므로 해당 쓰기가 다시 병합될 때만 테이블이 잠깁니다. 장기 실행 온라인 DDL 작업을 수행하는 테이블에 대한 매우 많은 수의 쓰기를 생성하는 워크로드의 경우, 병합할 변경 사항의 양이 상대적으로 많습니다. 이 크기는 병합 단계 잠금에 걸리는 시간일 길어지는 데 영향을 줍니다. 극단적인 경우, 테이블 변경 작업이 완료되기 전에 임시 스페이스가 고갈되어 실질적으로 온라인 DDL 작업이 완료되지 못할 수 있습니다.

Aurora MySQL은 빠른 DDL을 지원하므로, 거의 즉각적인 작업으로 테이블 끝에 nullable 열을 추가할 수 있습니다. 이 기능은 앞에서 설명한 DDL의 단점 일부를 완화하는 데 도움이 됩니다. 일반 DDL 또는 빠른 DDL 작업으로는 효율적으로 처리할 수 없는 DDL 작업의 경우, Percona 온라인 스키마 변경 도구를 사용하여 이 작업을 실행하는 것을 고려해 볼 수 있습니다. 이 도구를 사용 사례에 적용하면, 덜 파괴적인 방법으로 DDL 작업을 수행할 수 있지만 매우 큰 테이블에서는 작업이 더 오래 걸립니다.

다수의 테이블을 최적화하는 방법

통합된 워크로드로 인해 많은 수의 테이블이 Aurora 클러스터에 저장될 수 있습니다. 실제로 하나의 Aurora 클러스터에 통합될 수 있는 적정 테이블 수는 워크로드와 액세스 패턴에 따라 달라집니다.

파일 시스템 속성이 데이터베이스 확장성(테이블 크기와 수)을 제한하는 MySQL 커뮤니티 에디션과는 달리 Aurora MySQL은 특별히 구축된 분산 로그 구조의 스토리지 서비스를 사용합니다. 따라서 파일 시스템의 상속된 한계를 완화하기 위해 MySQL에서 사용자 지정 테이블스페이스 구성을 사용하는 수많은 이유가 Aurora에는 적용되지 않습니다. 운영 측면 또는 장애 복구 측면에서, 테이블 수가 많다고 해서 파일 시스템에 영향을 주지는 않습니다. Aurora 사용자 지정 DB 클러스터 파라미터를 사용하여 inndb_file_per_table 옵션을 비활성화할 수 있지만, 권장하지는 않습니다. 성능 또는 복구 시간에 더는 영향을 주지 않기 때문입니다.

하지만 Aurora에 많은 수의 테이블이 있으면 메모리 사용률에 영향을 줍니다. 기본 파라미터가 설정된 Aurora 클러스터의 메모리 사용량은 다음과 같습니다.

사용된 DB 인스턴스 메모리소비자
3/4최근에 액세스된 데이터 페이지를 저장하는 버퍼 풀(페이지 캐시). DB 파라미터 그룹에서 이 구성을 변경할 수 있습니다. 하지만 버퍼 풀의 크기를 줄이는 것은 일반적으로 바람직하지 않습니다. 버퍼 풀 효율성을 추적하는 관련 Amazon CloudWatch 지표는 버펄 풀 캐시 적중률과 스토리지에 대한 읽기 IOPS입니다.
1/24쿼리 캐시. 버전 5.7.20에서 쿼리 캐시가 사용 중단되고 비활성화된 MySQL 커뮤니티 에디션과는 달리 Aurora는 업그레이드된 쿼리 캐시를 사용합니다. 이 쿼리 캐시에는 커뮤니티 에디션에 구현된 한계가 발생하지 않습니다. 쿼리를 캐시할 수 없는 것이 확실하고 다른 버퍼와 캐시에서 사용하도록 메모리를 회수하려는 것이 아니라면 쿼리 캐시를 활성화된 상태로 두는 것이 좋습니다.
나머지나머지 가용 메모리(약 20.8%)는 연결 또는 세션, 운영 체제, 관리형 서비스 프로세스에 특정되거나 전역적인 데이터베이스 엔진 버퍼 및 캐시와 같이 예측하기 힘든 다양한 소비자가 사용합니다. 이러한 메모리 일부는 즉시 사용 가능(free) 또는 확보 가능(freeable)합니다.

다수 테이블 관련 캐시 최적화

테이블 수가 많은 워크로드와 특히 관련이 캐시가 두 가지 있습니다. 이러한 캐시를 잘못 구성하면 잠재적으로 성능 및 안정성 문제가 발생할 수 있습니다.

테이블 캐시(또는 테이블 오픈 캐시)는 사용자 활동의 결과로 열린 테이블의 핸들러 구조를 저장합니다. 테이블은 각 세션별로 독립적으로 열립니다. 따라서 동일한 테이블에 액세스하는 여러 개의 동시 세션이 있는 경우 캐시는 해당 테이블에 대해 여러 항목을 포함할 수 있습니다. Aurora에서는 r4 클래스의 DB 인스턴스에 대해 이 캐시의 기본 크기를 6,000개의 오픈 테이블로 늘렸습니다. 하지만 이는 소프트 한도입니다. 이 캐시는 SQL 문과 관련된 테이블 수(및 해당 테이블의 파티션 수)에 따라 상당한 메모리를 소비하게 될 수 있습니다. 이러한 영향은 워크로드가 데이터베이스에서 실행하고 있는 동시 세션 수에 의해 증폭됩니다.

테이블 정의 캐시는 메모리에서 일반적으로 액세스되는 테이블에 대한 테이블 정의(스키마, 메타데이터)를 저장합니다. 테이블이 활발하게 사용될수록 테이블 정의를 캐시하는 것이 좋습니다. Aurora에서는 r4 클래스의 DB 인스턴스에 대해 이 캐시의 기본 크기를 최대 20,000개의 정의를 저장하도록 늘렸습니다. 따라서 이 캐시는 중요한 메모리 소비자가 될 수 있습니다. 수십만 개의 테이블을 사용하는 워크로드의 경우, 테이블 대부분이 활성 상태라면 이 캐시 크기를 기본 값 이상으로 늘릴 수 있는 혜택이 있습니다. 이 캐시 크기 또한 소프트 한도입니다. MySQL 데이터베이스 엔진은 상위-하위 외래 키 관련 테이블에 대한 테이블 정의를 제거하지 않습니다. 그러므로 캐시의 총 크기는 캐시 크기 한도를 초과할 수 있습니다.

따라서 효율적인 메모리 사용은 주어진 크기의 인스턴스로 Aurora 클러스터에서 운영할 수 있는 테이블 수를 실질적으로 제한할 수 있습니다. 이러한 캐시 공간을 줄이기 위해서는 이를 수용할 수 있도록 더 큰 DB 인스턴스 클래스를 사용해야 할 수 있습니다. 또는 이를 벌충하기 위해 쿼리 캐시 또는 버퍼 풀에 할당되는 메모리 양을 줄여야 할 수 있습니다. 이렇게 줄이면 다른 방식으로 워크로드 성능에 영향이 미칠 수 있습니다. 메모리가 작업 데이터 세트를 충족할 수 없기 때문입니다. 하지만 “너무 많은” 테이블이 정확히 몇 개를 말하는지 찾아내기가 어렵습니다. 다음 예제에서 이러한 효과를 더 잘 확인할 수 있습니다.

아래 차트는 테이블이 1,000개인 데이터베이스에 대해 40개의 동시 연결을 사용하여 수행된 sysbench 읽기 및 쓰기 OLTP 테스트의 향상된 모니터링 지표를 통해 보고된 free 메모리를 보여줍니다. 이 워크로드는 61GB의 메모리가 탑재된 Aurora MySQL 5.6 호환 db.r4.2xlarge DB 인스턴스(인기 있는 인스턴스 클래스)에서 단 10분 동안 실행되었습니다.

이 테스트의 경우 다음 명령을 사용해 테스트 실행 전에 데이터베이스와 테이블을 준비합니다.

sysbench oltp_read_write --table-size=1000 --tables=1000 --threads=40 --time=600 --max-requests=0 --db-driver=mysql --mysql-host=<aurora_db_cluster_endpoint> --mysql-db=sbtest --mysql-user=<user> --mysql-password=<password> prepare

이 시스템의 free 메모리는 테스트가 시작될 때 갑자기 12.2GB에서 5GB가 하락하고 CPU 리소스는 테스트를 거치면서 거의 모두 고갈됩니다. MySQL 커뮤니티 에디션과는 달리 Aurora는 버퍼 풀을 사전에 할당하며 이전 테스트에서 이미 워밍 상태였습니다. 비교적 적은 수의 활성 테이블(1,000개)과 총 동시 연결(40개)로 테스트를 수행했습니다. 메모리 소비는 테이블 캐시와 많은 수의 활성 테이블이 관련되어 있을 때 각 연결에 대한 증폭 효과로 인해 주로 발생합니다.

DB 인스턴스 파라미터 그룹의 table_open_cache 파라미터는 테이블 캐시 크기를 제어합니다. 기본적으로 이 파라미터는 다음 수식을 사용하여 설정됩니다.

lesser of (<DB instance class memory in bytes>/1,179,121) or 6,000

비교를 위해 다음 차트가 유사한 테스트를 보여줍니다. 유일한 차이점은 이 테스트에서 액세스하는 테이블이 500개뿐이라는 것입니다. 여기에서 시스템의 free 메모리는 테스트가 시작될 때 갑자기 12.2GB에서 약 2.5GB가 하락합니다.

다음 예제는 많은 수의 테이블이 사용될 때 테이블 정의 캐시의 영향을 보여줍니다. 이 테스트에서 예제 워크로드는 100,000개의 간단한 테이블을 생성하며, 각 테이블에는 자동 증가 정수 기본 키, 타임스탬프 열, 부동 소수점 열, 2개의 짧은 문자열 열이 있습니다. 이 테스트에서는 15.25GB의 메모리가 탑재된 Aurora MySQL 5.7 호환 db.r4.large DB 인스턴스에서 실행되는 단일 연결을 사용하여 하나의 행을 간단한 테이블 각각에 삽입합니다. Aurora 클러스터에서 실행되는 다른 활동은 없으며, 클러스터는 빈 상태에서 시작됩니다.

워크로드가 증가함에 따라 free 메모리가 어떻게 감소하는지 확인할 수 있습니다. 캐시 한도에 도달하면서 free 메모리가 안정화되며, 전체적으로 700MB의 메모리가 추가적으로 사용되고 이는 주로 테이블 정의 캐시에 사용됩니다.

DB 인스턴스 파라미터 그룹의 table_definition_cache 파라미터는 테이블 정의 캐시의 크기를 제어합니다. 기본적으로 이 파라미터는 다음 수식을 사용하여 설정됩니다.

lesser of (<DB instance class memory in bytes>/393,040) or 20,000

결론적으로 실제로 통합할 수 있는 테이블 수는 몇 가지 요인에 따라 달라집니다. 이러한 요인은 활발하게 사용되는 테이블 수, 가용 메모리 양, 지원해야 하는 동시 연결 수입니다.

높은 데이터베이스 리소스 사용률을 최적화하는 방법

이 게시물의 앞부분에서 더 큰 테이블 또는 더 많은 수의 테이블이 CPU 또는 메모리와 같은 서버 리소스 사용률에 영향을 미친다는 것을 설명했습니다. 하지만 워크로드 통합 자체가 사용률을 높입니다. 데이터베이스 샤드 수가 감소하면, 나머지 데이터베이스 샤드마다 더 많은 동시 연결이 설정될 수 있습니다. 각 통합 데이터베이스는 더 많은 작업을 수행하고 읽기 및 쓰기 쿼리 볼륨이 증가합니다.

Amazon Aurora for MySQL에는 내부 서버 연결 풀링 및 스레드 멀티플렉싱이 함께 제공되므로, 수천 개의 동시 연결을 처리할 때 경합을 줄이고 확장성을 개선할 수 있습니다. 최대 16,000개의 동시 연결을 허용하도록 각 Aurora DB 인스턴스를 구성할 수 있습니다. 하지만 워크로드 및 DB 인스턴스 클래스 선택에 따라 실제 최대 값이 이보다 적은 수로 제한될 수 있습니다.

각 연결, 세션 및 스레드는 현재 실행 중인 특정 SQL 문을 기반으로 다양한 버퍼, 캐시, 기타 메모리 구조에서 다양한 양의 메모리를 소비합니다. 이러한 소비는 결정적이지 않으며, 이 블로그 게시물의 앞부분에서 설명한 다른 구조들과 마찬가지로 같은 양의 가용 메모리를 두고 경쟁합니다. 효과적인 연결 관리 및 규모 조정에 대한 모범 사례를 이해하려면 연결 관리를 위한 Amazon Aurora MySQL DBA 핸드북 백서가 훌륭한 리소스입니다. 더 크고 더 높은 처리량의 워크로드에 대한 연결 사용률을 최적화하는 데 도움이 되는 유용한 조언이 포함되어 있습니다.


Amazon Aurora with MySQL Compatibility를 여러 데이터베이스 워크로드 통합을 위한 솔루션으로 고려할 때 여러 가지 요인이 개입하게 됩니다. 완전한 목록은 아니지만, 앞서 설명한 항목에는 이러한 통합을 구현하는 고객을 지원할 때 보게 되는 공통된 고려 사항이 포함되어 있습니다. 모든 워크로드가 다르므로, 통합에 대한 실질적인 제한은 사례마다 다릅니다.

모범 사례는 프로덕션 규모의 기본값에서 구성 변경 사항을 철저하게 테스트하고 성능과 안정성에 수량화할 수 있는 긍정적인 영향이 미치는 경우에만 이를 구현하는 것입니다. 이 모범 사례는 MySQL 커뮤니티 에디션에서 구성을 가져올 때 특히 중요합니다. Aurora는 같은 방식으로 동작하지 않을 수 있기 때문입니다. 워크로드 통합 프로젝트를 실행하는 방법에 대한 자세한 내용은 AWS 데이터베이스 블로그의 Reduce Resource Consumption by Consolidating Your Sharded System into Aurora 게시물을 참조하십시오. 기계번역문

우리는 TypeScript, JavaScript 및 Java 용 AWS 클라우드 개발 키트 (CDK) 개발자 미리보기 릴리스 를 발표하게 된 것을 기쁘게 생각합니다 .NET 및 Python이 곧 출시 될 예정입니다. AWS CDK는 클라우드 인프라를 코드로 정의하고 CloudFormation을 통해 프로비저닝하는 소프트웨어 개발 프레임 워크입니다. CDK는 AWS 서비스와 완벽하게 통합되며 AWS 리소스를 필수적으로 정의하기 위해 더 높은 수준의 객체 지향 추상화를 제공합니다. CDK는 현대 프로그래밍 언어의 힘을 사용하여 예측 가능하고 효율적인 방식으로 AWS 인프라를 정의하므로 엔드 투 엔드 개발 경험을 향상시킵니다.

CDK를 클라우드 인프라 스트럭처 "컴파일러"로 생각할 수 있습니다. AWS 클라우드 리소스를 추상화하고 AWS 모범 사례를 캡슐화하는 Constructs 라는 고수준 클래스 라이브러리 세트를 제공합니다 구문은 응용 프로그램 인프라를 정확하게 정의하고 모든 복잡한 상용구 논리를 처리하는 개체 지향 CDK 응용 프로그램 으로 함께 스냅 할 수 있습니다 CDK 응용 프로그램을 실행하면 AWS 클라우드 인프라의 "어셈블리 언어"인 CloudFormation 템플릿 으로 컴파일됩니다 그러면 템플릿이 CloudFormation 프로비저닝 엔진에 의해 처리되어 AWS 계정에 배포 될 준비가됩니다. CDK 도구를 사용하면 쉽게 정의 할 수 있습니다.애플리케이션 인프라 스트럭처 스택, CloudFormation 서비스는 스택의 안전하고 신뢰할 수있는 프로비저닝 을 처리합니다.

익숙한 도구

CDK를 통해 우리는 매일 사용하는 친숙한 환경과 팀 워크 플로에 인프라 정의를 가져 와서 가장 편안하고 생산적인 곳에서 만날 수 있습니다. CDK는 사용자가 선호하는 객체 지향 프로그래밍 언어를 지원하므로 루프 및 조건과 같은 코드 논리를 자연스럽게 표현하여 모든 환경 또는 시나리오에 맞게 인프라를 사용자 지정할 수 있습니다. CDK 코드는 코드 일 뿐이므로 인라인 설명서, 리팩토링 도구, 코드 탐색 및 단위 테스트와 같은 기존 IDE 기능이 모두 예상대로 작동합니다. 다음 코드는 가용성 영역 및 지역별 AMI ID와 같은 인프라 스트럭처 논리 및 환경 컨텍스트를 사용하여 단일 코드 기반에서 다른 지역에 대한 다양한 응용 프로그램 스택을 만드는 방법을 보여줍니다. 인프라 정의 복사 및 붙여 넣기가 필요하지 않습니다.

// 현재 지역 / 계정에 대한 AZ 목록 가져 오기

const azs = new cdk.AvailabilityZoneProvider(this).availabilityZones;


//이 영역의 특정 Windows 버전에 대한 AMI ID 가져 오기

const ami = new ec2.WindowsImage(ec2.WindowsVersion.WindowsServer2016EnglishNanoBase).getImage(this);


for (const az of azs) {

// 가용성 영역을 기반으로 구조체 이름을 렌더링합니다.

const constructName = `InstanceFor${az.replace(/-/g).toUpperCase()}`;


new ec2.cloudformation.InstanceResource(thisconstructName, {

imageId: ami.imageId,

availabilityZone: az,



세부 사항 요약

CDK는 개발자가 최신 프로그래밍 언어와 객체 지향 기술을 사용하여 CloudFormation 템플릿을 생성 할 수있는 최초의 솔루션이 아닙니다. CDK는 AWS 서비스와 완벽하게 통합되어 IAM 정책, 보안 그룹 및 네트워크 구성과 같은 주요 리소스를 자동으로 종합하는 유용한 API를 제공합니다. 예를 들어 인프라에 Amazon Virtual Private Cloud (VPC)를 추가하려면 다음 코드 줄을 CDK 응용 프로그램에 추가하기 만하면됩니다.

new ec2.VpcNetwork(this‘MyVPC’);

CDK 애플리케이션이 컴파일되면 대상 지역의 각 가용 영역에 대한 서브넷과 경로, 경로 표, 서브넷 경로 표 연결, NAT 게이트웨이, 인터넷 게이트웨이 및 필요한 탄성 IP를 정의하는 긴 CloudFormation 템플릿이 생성됩니다 모든 일을하도록하십시오. 스마트 한 기본값 중 일부가 요구 사항을 충족시키지 못하면 VPC 매개 변수를 자신의 값으로 쉽게 재정의 할 수 있습니다.

확장 가능

AWS에서 작성한 CDK Constructs가 제공하는 유용한 API를 활용하는 것 외에도 예측 가능하고 재사용 가능한 코드로 자신 만의 모범 사례를 정의 할 수 있습니다. 예를 들어, 암호화가 활성화 된 S3 버킷을 항상 만드는 CDK 응용 프로그램을 제작하여 팀이 기본적으로 자연스럽게이 작업을 수행 할 수 있습니다.

new s3.Bucket(this‘EncryptedBucket’, {

encryption: s3.BucketEncryption.KmsManaged


독창적 인 클라우드 고유의 디자인 패턴을 인코딩하고 특정 사용 사례에 중점을두고 내부적으로나 전 세계와 공유하는 더 높은 수준의 CDK 응용 프로그램을 정의 할 수 있습니다. 우리는 당신이 만든 멋진 것들을보기 위해 기다릴 수 없습니다.

바자Bazaar 방문

우리는 닫힌 성당이 아닌 열린 시장처럼 CDK를 건설하고 있습니다. 아직 끝나지 않았습니다! 참조, 익숙하지 않은 사람들을 위해 성당과 시장 , 두 가지 기본적인 소프트웨어 개발 스타일을 대조 에릭 S. 레이몬드에 의해 에세이이며, 오픈 소스, "감안할 때 충분히 눈알, 모든 버그 얕은하다"인수한다 . 오픈 소스 개발자 미리보기이므로 AWS에서 클라우드 애플리케이션을 개발할 때 CDK를 최고의 경험으로 활용할 수 있도록 도와주십시오. aws-cdk GitHub README 를 방문하여 CDK를 시작하는 방법을 배우십시오. Gitter 에 게시 하여 대화를 시작하고, 개발자와 의견 을 교환하고, 풀 요청을 제출하십시오.귀하의 상품을 기부하거나, 단지 우리에게 관심을 보이기 위해 프로젝트에 별표 를 붙이십시오. 우리는 당신과의 협력을 기대합니다.


  • EC2 - S3
    기존 5Gbps -> 25Gbps

  • EC2 - EC2
    5Gbps(단일 흐름 트래픽) , 25Gbps(다중 흐름 트래픽) , Multi-AZ 포함

  • EC2 - EC2(클러스터 배치 그룹)
    10Gbps(단일 흐름 트래픽) , 25Gbps(다중 흐름 트래픽) , Placement Group이므로 Single-AZ

AWS는 re:Invent 때 항상 깜짝 놀랄만한 서비스를 출시합니다.

아무도 예상 못해선... 설마했던... 그것을 아마존이 또 출시했네요.. 바로 VM이 아닌 물리서버인 베어메탈 서비스 입니다.

사실 VMware on AWS를 출시할 때 부터 가능성이 점쳐졌던 거긴 한데요...

설마 진짜 베어메탈 서비스를 출시 할지 몰랐네요. 사용자 입장에서의 사용성은 베어메탈도 VM과 동일 합니다.

서버의 순수한 성능을 다 확보 할수 있고, 라이센스 정책에서 좀 더 자유로울 수 있겠네요.

Softlayer(IBM Cloud)가 거의 베어메탈의 표준 처럼 잡고 있는 클라우드였는데요.... 이제 긴장해야겠습니다. 

아직 AWS가 프리뷰이긴하지만 언제 훅 치고 들어올지 모르니까요.


Amazon EC2 Bare Metal Instances with Direct Access to Hardware

When customers come to us with new and unique requirements for AWS, we listen closely, ask lots of questions, and do our best to understand and address their needs. When we do this, we make the resulting service or feature generally available; we do not build one-offs or “snowflakes” for individual customers. That model is messy and hard to scale and is not the way we work.

Instead, every AWS customer has access to whatever it is that we build, and everyone benefits. VMware Cloud on AWS is a good example of this strategy in action. They told us that they wanted to run their virtualization stack directly on the hardware, within the AWS Cloud, giving their customers access to the elasticity, security, and reliability (not to mention the broad array of services) that AWS offers.

We knew that other customers also had interesting use cases for bare metal hardware and didn’t want to take the performance hit of nested virtualization. They wanted access to the physical resources for applications that take advantage of low-level hardware features such as performance counters and Intel® VT that are not always available or fully supported in virtualized environments, and also for applications intended to run directly on the hardware or licensed and supported for use in non-virtualized environments.

Our multi-year effort to move networking, storage, and other EC2 features out of our virtualization platform and into dedicated hardware was already well underway and provided the perfect foundation for a possible solution. This work, as I described in Now Available – Compute-Intensive C5 Instances for Amazon EC2, includes a set of dedicated hardware accelerators.

Now that we have provided VMware with the bare metal access that they requested, we are doing the same for all AWS customers. I’m really looking forward to seeing what you can do with them!

New Bare Metal Instances
Today we are launching a public preview the i3.metal instance, the first in a series of EC2 instances that offer the best of both worlds, allowing the operating system to run directly on the underlying hardware while still providing access to all of the benefits of the cloud. The instance gives you direct access to the processor and other hardware, and has the following specifications:

  • Processing – Two Intel Xeon E5-2686 v4 processors running at 2.3 GHz, with a total of 36 hyperthreaded cores (72 logical processors).
  • Memory – 512 GiB.
  • Storage – 15.2 terabytes of local, SSD-based NVMe storage.
  • Network – 25 Gbps of ENA-based enhanced networking.

Bare Metal instances are full-fledged members of the EC2 family and can take advantage of Elastic Load BalancingAuto ScalingAmazon CloudWatchAuto Recovery, and so forth. They can also access the full suite of AWS databaseIoTmobileanalyticsartificial intelligence, and security services.

Previewing Now
We are launching a public preview of the Bare Metal instances today; please sign up now if you want to try them out.

You can now bring your specialized applications or your own stack of virtualized components to AWS and run them on Bare Metal instances. If you are using or thinking about using containers, these instances make a great host for CoreOS.

An AMI that works on one of the new C5 instances should also work on an I3 Bare Metal Instance. It must have the ENA and NVMe drivers, and must be tagged for ENA.

— Jeff;


Polly 가 드디어 한국어를 합니다. 기계합성어 답지않게 정말 자연스럽습니다. 이제 음성합성은 구글보다 Polly를 이용할것 같습니다.

더 자연스럽고, 더 쉽게 쓸 수 있습니다. 아래 링크로 한번 들어 보시죠.

음성 파일


Amazon Polly 서울 리전 출시 및 한국어 여성 ‘서연(Seoyeon)’ 음성 공개

 Amazon Polly는 고급 딥 러닝 기술을 사용하여 실제 사람 목소리처럼 음성을 합성하는 텍스트 음성 변환 서비스입니다. 텍스트를 다양한 언어로 수십 개의 생생한 음성이 제공되므로 여러 국가에서 적합한 음성을 선택하여 음성 지원 애플리케이션을 개발할 수 있습니다.

오늘부터 Amazon Polly를 서울 리전에서 사용 가능합니다. 또한, 한국어 여성 ‘서연(Seoyeon)’음성을 공개합니다.

Amazon Polly의 종량 요금제, 변환 문자당 저렴한 비용, 무제한 재생은 거의 모든 애플리케이션에서 음성 합성을 구현하는 비용 효과적인 방법을 제공합니다. 이전에 재생된 오디오를 재생할 때마다 로열티를 요구하거나 요금을 부과하는 다른 솔루션과 달리, Amazon Polly는 추가 요금 없이 무제한 재생을 허용합니다. 이러한 무료 재생은 오프라인 사용까지 확대됩니다. MP3 및 OGG와 같은 다양한 표준 형식으로 음성 파일을 생성하여 오프라인 재생 전용으로 휴대폰 또는 사물 인터넷(IoT) 디바이스와 같은 디바이스에 저장할 수 있습니다.

실제 같은 음성과 대화 사용자 경험을 제공하기 위해서는 일관되게 빠른 응답 시간이 요구됩니다. Amazon Polly API로 긴 텍스트를 전송하더라도 Amazon Polly API가 오디오를 스트림으로 애플리케이션으로 반환하므로 즉시 음성을 재생할 수 있습니다.

아래 샘플 코드에 대한 음성 파일을 확인해 보실 수 있습니다.


from boto3 import client
polly = client("polly", region_name="ap-northeast-2")
response = polly.synthesize_speech(
        Text="안녕하세요. 제 이름은 서연이에요! 저는 새내기 아마존 폴리 음성 비서입니다. 텍스트를 입력하시면 읽어드릴께요.",

특히, 음성 합성 애플리케이션을 위한 Speech Synthesis Markup Language(SSML), W3C 표준, XML 기반 마크업 언어를 지원하고 표현, 강조 및 억양을 위한 일반 SSML 태그를 지원합니다. 이러한 유연성은 청중의 관심을 끌 수 있는 생생한 음성을 생성하는 데 도움이 됩니다.

아래 샘플 코드에 대한 음성 파일을 확인해 보실 수 있습니다.


   오늘의 <prosody rate="x-slow">날씨를 전해 드리겠습니다</prosody>. 
   현재, 전국이 구름이 많은 가운데 일부 중부 지역과 전북에는 <prosody volume="x-loud">눈이 날리거나</prosody><break time="1s"/> <prosody pitch="x-high">빗방울이 떨어지는 곳이 있습니다.
   </prosody>. 서울의 경우 북부 지역을 중심으로 <amazon:effect name="whispered"><prosody rate="-10%">눈이 날리고 있으나,</prosody></amazon:effect> 공식적인 첫눈으로 기록되지는 않습니다.

자세한 내용은 SSML 태그에 대한 Amazon Polly 설명서를 참조하십시오.

Amazon Polly는 월 5백만자 까지 무료로 제공됩니다. 그 이상의 경우, 한 자당 $0.000004 per 또는 제작된 오디오 분당 $0.004로 과금 됩니다.  일반적인 한국어 뉴스 기사 (2,500자)의 경우, $0.01 (11원) 정도로 매우 저렴합니다. 예를 들어, 영어로 된 Adventures of Huckleberry Finn이라는 책 원문 전체는 약$2.4 정도 됩니다. 더 자세한 것은 Polly 요금 정보를 참고하세요.

이제 Amazon Polly를 통해 뉴스 및 전자책 리더, 게임, 전자 학습 플랫폼, 시각 장애가 있는 사람을 위한 접근성 애플리케이션, 빠르게 성장하는 사물 인터넷(IoT) 세그먼트 등과 같은 모바일 애플리케이션이 등 다양한 한국어 지원에 활용하실 수 있습니다. Amazon Polly에 대한 더 자세한 사항은 제품 페이지나 기술 문서를 참고하시기 바랍니다.

– 윤석찬(Channy);

OpsWorks 가 원래 Chef 기반이죠.. 그런데 이제 Puppet도 지원하네요. (이제 Ansible만 하면 되겠습니다;;;)

Puppet에 익숙한 사용자들이 더욱 접근 하기 좋아졌네요...


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 Redshift Spectrum은 Athena만큼 기대되는 제품이 였는데 드디어 서울리전에도 사용이 가능해졌습니다.

Athena가 EMR을 공유인프라를 활용한 SaaS 형으로 제공서비스라면

Redshift Spectrum은 이름처럼 Redshift를 공유인프라를 통해 SaaS형으로 제공하는 서비스입니다. 구글 빅쿼리랑 대응 되겠네요.

둘다 S3 데이터를 직접 다룰 수 있습니다. 

세부 내용은 아래 AWS 블로그 내용 참고 하시 면 되겠습니다.


Amazon Redshift Spectrum에 대한 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 ( 
partitioned by (L_SHIPDATE VARCHAR(128))
stored as PARQUET
location 's3://<your-bucket>/<xyz>/lineitem_partition/'

CREATE  external table spectrum.LINEITEM_CSV ( 
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을 사용하여 테스트를 수행하려면, 다음 두 가지 쿼리를 시작하는 것이 좋습니다.


SELECT l_returnflag,
       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 레이어에서 제공하는 추가 처리 성능을 강조 표시하는 데 사용할 수 있습니다.


SELECT  l_orderkey,
       sum(l_extendedprice * (1 - l_discount)) as revenue,
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

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

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

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

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

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

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

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

SELECT query,
	max(assigned_partitions) as total_partitions,
	max(qualified_partitions) as qualified_partitions 
FROM svl_s3partition 
WHERE query=<Query-ID>

클러스터 설정 모범 사례

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와 같은 조건부 조건 및 패턴 일치 조건
  • COUNTSUMAVGMINMAX 및 기타 많은 공통 집계 함수
  • regex_replace 및 기타 많은 함수

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

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

	from spectrum.LINEITEM_NPART_PARQ;
        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)수에서 큰 차이가 있다는 점을 알게 될 것입니다.


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

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

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

SELECT l_returnflag,l_linestatus 
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 TABLE 및 ALTER 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의 한국어 번역입니다.

+ Recent posts