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

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

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

https://calculator.aws/

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

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

참고 : https://github.com/aws-samples/amazon-efs-tutorial

원문 : https://s3.amazonaws.com/aws-us-east-1/demo/efs-parallel-file-transfer-test.html

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 darrylo@amazon.com.

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 - https://github.com/bengland2/smallfile - used to generate test data; Developer: Ben England
  • GNU Parallel - https://www.gnu.org/software/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 - https://github.com/pkolano/mutil - multi-threaded drop-in replacement of cp; Author Paul Kolano (NASA)
  • fpart - https://github.com/martymac/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 Code	Name	Launch
us-east-1	US East (N. Virginia)
us-east-2	US East (Ohio)
us-west-2	US West (Oregon)
eu-west-1	EU (Ireland)
eu-central-1	EU (Frankfurt)
ap-southeast-2	AP (Sydney)

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

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

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

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 http://169.254.169.254/latest/meta-data/instance-id)

17. Transfer files from EBS to EFS using rsync

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
exit
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
exit
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
exit
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
exit
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
exit
time /home/ec2-user/efscp.sh /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
exit
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

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.

Cleanup

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.

Conclusion

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 darrylo@amazon.com.

마이크로서비스로만 가면 만능일것 같은 시대에 한번 쯤 읽고 고민해 볼만한 글이다.

"마이크로서비스는 답이 아니었다"··· 세그먼트가 모놀리틱으로 돌아온 이유

Tamlin Magee | Computerworld UK

원문보기: http://www.ciokorea.com/news/39258

다른 많은 기업과 마찬가지로, 데이터 스타트업 세그먼트(Segment) 역시 오래된 인프라스트럭처로 인한 문제 때문에 마이크로서비스(microservice)로 눈을 돌렸다. 하지만 곧 단일 구조(monolithic) 아키텍처로 돌아오지 않으면 해결할 수 없는 복잡한 문제가 있다는 것을 깨달았다.

세그먼트의 주 고객은 타임(Time), IBM, 리바이스(Levi’s) 등이다. 이들 기업의 모든 고객 데이터를 세일즈, 애널리틱스, 헬프데스크 등에 피딩하기 전에 한 지점에 모아 볼 수 있는 서비스를 제공한다.

세그먼트의 CTO이자 공동창립자인 캘빈 프렌치-오웬은 “처음에는 단일 API와 라이브러리를 제공하고 그들이 데이터를 보내오는 식의 개발자 우선 방식을 택했다. 우리가 데이터를 모아 구성한 후 이를 적절한 스키마로 정렬하고, 고객사가 사용하는 200여 가지 이상의 툴에 이 데이터를 보냈다. 여기서 툴이란 세일즈포스 같은 세일즈 툴 일수도 있고, 젠데스크(Zendesk) 같은 고객 관련 툴, 혹은 레드시프트(Redshift)나 빅쿼리(BigQuery)같은 데이터 웨어하우스 일수도 있다”라고 말했다.

세그먼트사는 전적으로 AWS에 의존하고 있으며, ECS(Elastic Container Service)가 관리하는 1만 6000개 컨테이너가 250여 가지 마이크로서비스를 제공한다.

세그먼트는 원래 단일 구조 아키텍처를 사용했다. API가 데이터를 처리해 싱글 큐(queue)에 포워딩하면 직원이 데이터를 읽고 이벤트를 모든 서버측 ‘목적지’, 그러니까 파트너 API에 선형 체인을 통해 전송했다. 그러나 이런 방식은 이내 문제를 발생시켰다. 툴에서 서버 에러를 반송할 때의 재시도가 큐와 만나 다른 이벤트와 뒤섞이는 것이다. 이로 인해 파이프가 막히고 성능 장애로 이어졌다.

세그먼트의 소프트웨어 엔지니어 알렉스 누난은 “단일 구조에서 탈피해 마이크로서비스로 전환한 것도 이 때문이었다. 우리에게는 데이터를 수집하는 API와 라우터가 있고, 라우터는 이벤트를 목적지별 큐와 서비스로 라우팅했다. 이벤트가 발생하면 라우터가 ‘좋아, 이 이벤트는 구글 애널리틱스와 맥스 패널로 보내야겠어’라고 판단을 내리고 해당 이벤트의 카피를 2개 생성해 각각의 큐로 이를 보내는 식이었다”라고 말했다.

바람 잘 날 없었던 “마이크로서비스”의 세계

마이크로서비스 방식은 한동안 잘 돌아 가는 것처럼 보였다. 그러나 역시 문제가 발생했다. 누난의 표현을 빌리면 '마이크로서비스 세계의 더 깊숙한 곳에서 개별 파트너의 API 목적지와 서비스에 대한 새로운 타입의 큐가 형성됨'에 따라 발생했다. 결국 개발자는 모든 업데이트를 수동으로 처리해야 했고 어떤 업데이트 버전이 어디의 어느 리포(repo)에 있는지를 일일이 기억하는 것이 한계에 다다랐다.

누난은 “시간이 갈수록 개발자의 생산성이 급격히 저하됐다. 모든 것이 각기 다른 별개의 큐와 별개의 서비스, 그리고 자체적인 리포에 있었기 때문이다. 우리는 통합을 유지, 생성하기 위해 공유 라이브러리를 만들었지만 이것을 전개할 좋은 방법도, 또 제대로 테스팅할 여건도 안됐다. 공유 라이브러리를 업데이트하기에는 시간도 자원도 부족했다. 결국 구글 애널리틱스 버전만 업데이트하는 식이 됐다. 모든 라이브러리가 서로 다른 업데이트 버전을 갖게 됐다"라고 말했다.

세그먼트 팀은 파트너 API가 각각 어느 라이브러리 버전에서 구동되는지 추적하고, 그 버전 간의 차이도 기억해야 했다. 누난은 “라이브러리 관리 업무 만으로도 개발자에게 너무 큰 부담이 됐다. 꾹 참고 서비스마다 하나하나 변경할 수도 있지만 그러려면 수 일이 걸렸고, 특히 서비스 하나 하나를 테스트하고 전개하는데 여러 명의 개발자가 필요하게 됐다. 이것이 너무 큰 부담으로 작용한 끝에 결국 꼭 필요한 변경사항조차도 적용하지 않게 되는 일까지 발생했다. 모든 서비스에 아주 작은 변경사항만 적용하기 위해서도 팀 전체가 달려 들어 일주일 이상 소모해야만 했다”라고 말했다.

세그먼트의 직원은 이러한 큐를 처리하기 위해 수면 부족에 시달리는 것도 모자라, 성능 이슈에도 직면했다. 예를 들어 구글 애널리틱스와 같은 대규모 목적지의 경우 초당 수천 건에 달하는 이벤트를 처리하는 반면 하루에 수 건 이내의 이벤트만을 처리하는 곳도 있었다. 세그먼트 팀은 오토-스케일링 룰을 적용해 이러한 서비스의 수동 커스터마이징을 최소화 했지만 서비스마다 고유의 CPU 및 메모리 로드 패턴이 있었기 때문에 모든 통합에 같은 룰을 적용할 수는 없었다.

누난은 “하루에도 수십 번씩 쉴 새 없이 호출이 왔고, 직원이 일일이 개입해 이러한 서비스를 처리해야 했다. 이런 식으로 2년 넘게 마이크로서비스 방식을 이용한 결과 큐와 리포에 140여 가지 서비스를 갖게 됐지만 시스템 장애를 막는 데에만 모든 에너지를 쏟아도 역부족이었기에 그보다 더 건설적이거나 선제적인 어떤 노력도 할 수 없는 상황이었다. 이쯤 되자 한걸음 물러나 생각해 보지 않을 수 없었다. ‘대체 이 상황을 해결하려면 어떻게 해야 하지?’ 결국 인력을 추가해야 한다는 결론이 나왔지만, 그런 식으로 문제를 해결하고 싶지는 않았다”라고 말했다.

그러나 결국 세그먼트는 마이크로서비스 아키텍처가 지속 불가능하다는 결론에 다다랐다. 목적지를 추가할수록 성능 저하가 눈에 띄게 증가했고 이것은 ‘상당히 뚜렷한 경고 신호’였다. 누난은 “한창 마이크로서비스로 인한 광기가 극에 달했을 때 내가 세그먼트에 합류했다. 당시 이미 어떻게 하면 이 문제를 해결할 것인가에 대한 논의가 이루어지고 있었다”라고 말했다.

단일 구조로 돌아가다

세그먼트 팀은 마이크로서비스를 어떻게 다시 하나의 거대한 시스템으로 재설계할 것인지 방법을 찾아야 했다. 이른바 ‘신(新) 단일구조’로의 이행이었다. 결국 당시 세그먼트가 진행 중이던 ‘센트리퓨즈(Centrifuge)’ 인프라스트럭처 프로젝트를 통해 새로운 단일 구조로 이행하기로 결정됐다. 센트리퓨즈는 세그먼트 비즈니스의 핵심이라 할 수 있는 단일 이벤트 딜리버리 시스템이다.

프렌치-오웬은 “센트리퓨즈는 큐를 생성하고 실패가 발생했을 때 트래픽을 흡수하기 위한 시스템이다. 이 시스템 덕분에 우리는 여러 코드를 한 장소에 통합하고, 이를 통해 두 마리 토끼를 잡는 전략을 취하기로 했다"라고 말했다.

이를 위해 먼저 모든 목적지 코드를 하나의 리포로 통합했다. 하나의 리포에 모든 종속 항목과 테스트를 합병하는 것이었다. 서비스가 하나뿐이므로 논리적으로 당연했다. 그러나 이 과정이 대단히 복잡하고 머리 아픈 과정이었다. 누난은 "120개가 넘는 고유의 종속 항목들 각각에 대해 우리는 모든 목적지에 대한 하나의 버전을 만드는 데 집중했다. 또한 목적지를 이동하면서 사용 중인 종속 항목을 확인하고 이들을 최신 버전으로 업데이트했다. 또 목적지의 새로운 버전에서 생긴 부분을 바로 바로 수정했다"라고 말했다.

이렇게 일관성을 확보한 결과 코드베이스를 어지럽히던 혼란이 상당 부분 해소되었다. 세그먼트 팀은 또한 빠르고 쉽게 모든 목적지 테스트를 한 번에 진행할 수 있는 테스트 스위트는 개발했다. 지나치게 길고 복잡한 테스트 과정 역시 업데이트를 방해하던 주요 요소 중 하나였기 때문이다.

이처럼 목적지 코드를 단일 리포로 이동시켜 단일 서비스로 통합하자 곧바로 개발자 생산성 증대라는 성과로 이어졌다. 서비스 전개 시간도 수 분 이내로 단축됐다. 누난은 “인프라스트럭처의 가장 큰 부분을 재설계해야 했기 때문에 단일 구조로의 전환에는 상당한 시간이 걸렸다. 당연한 일이었다. 하지만 적어도 예전처럼 계속해서 고객 지원 요청이 들어오거나 하는 일은 없다. 모두가 수면 부족에 시달리지 않을 수 있게 됐다. 모든 것을 하나의 리포로 통합하고 나니 관리도 쉬워졌다”라고 말했다.

이어 "이제 공유 라이브러리에 업데이트를 생성하고 싶을 때, 엔지니어 1명이 한 시간만 투자해 테스트하고 전개할 수 있다. 우리에게는 정말 획기적인 변화였다. 처음 마이크로서비스를 채택했을 때 당시 그런 선택을 할 만한 사정이 있었다고 생각한다. 당시 팀이 처한 상황이나 겪고 있던 성능 이슈를 고려하면 최고의 선택이었다. 그러나 시간이 지날수록 마이크로서비스의 장점은 사라지고 생산성과 성능만 잡아먹게 됐다. 그래서 다시 단일 구조로 돌아온 것이다"라고 말했다.

세그먼트 사가 다른 기업에 비해 처리하는 데이터 양에서 압도적으로 많긴 하지만 비슷한 불편을 겪는 다른 기업 역시 단일 구조로 돌아오는 것이 하나의 대안이 될 수 있다. 누난도 "그런 선택을 한다고 해도 전혀 놀라운 일이 아니다"라고 말했다.

단일 구조로 돌아온 후 나아진 건 세그먼트 사 직원의 워크-라이프 밸런스 뿐 만이 아니다. 고객 역시 훨씬 일관되고 안정적인 서비스를 누릴 수 있게 됐다. 프렌치-오웬은 “모든 서비스가 한 장소에, 단일 리포에 통합됨에 따라 추가된 변경 사항이 다음 번에도 모든 서비스에 똑같이 전개될 것이라는 확신을 가질 수 있게 됐다. 덕분에 고객 역시 서비스 별로 각기 다른 버전으로 인해 발생하는 혼란이나 비일관성을 더 이상 겪지 않아도 됐다"라고 말했다. 

ciokr@idg.co.kr