Amazon S3 이미지 온디맨드 리사이징을 통한 70% 서버 비용 줄이기 - AWS Summit Seoul 2017

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
김명보
비트윈 개발팀
On-demand Image Resizing을 통한
Amazon S3 비용 70% 줄이기

본 강연에서 다룰 내용
- S3 이미지 저장 비용을 줄이기 위한 아키텍쳐 변화
- Skia
- WebP
- 기존 이미지 Migration
- Auto-Scaling group
- Spot instance
- SQS
- S3 + CloudFront

발표자 소개
- 김명보
- VCNC에서 비트윈을 개발하고 개발자
- 서버팀과 데이터 팀에서 잡다한 것들을 고치는 중
- 회사에서 AWS에 돈을 쓰는 것을 담당

Between
- 커플들을 위한 모바일 서비스
- 아이폰, 안드로이드 어플리케이션 제공
- 채팅, 기념일, 사진, 메모, 캘린더 기능 제공
- 전 세계에서 2000만 다운로드

Old Architecture
New Architecture
Migration

비트윈 유저들은 사진을 좋아합니다

서로 다른 크기의 Thumbnail

기존 Thumbnail 생성 방식
- 사진 업로드 시에 4~6장의 Thumbnail을 생성
- S3 bucket에 원본 사진과 함께 저장

Between 사진 용량
- 2016년 3월 기준으로 11억장의 원본 사진이 존재
- Thumbnail 포함 총 66억장의 이미지 저장
- 738 TB

Amazon S3 이미지 온디맨드 리사이징을 통한 70% 서버 비용 줄이기 - AWS Summit Seoul 2017

좀 더 효율적인 방식을 찾아봅시다

낮은 Fan-out
- 커플 간에만 공유되는 사진
- 수천~수만명이 같이 보게 되는 일반적인 웹사이트와는
사용 패턴이 다름

Client Screen Size
- 특정 Thumbnail은 쓰이지 않게 될 수 있음
( Client 화면 크기에 따라 )

High Cache Hit Rate
- Client에 LRU-based file cache가 존재함 (hit rate가 높음)
- CloudFront도 일정한 cache hit을 제공함 (20~30% 정도)

S3 - Thumbnail Recall Rate
- 특정 크기의 Thumbnail 요청 이후 몇 일 이내로 다시 요청할 확률

Between 사진 사용 특성 - 정리
- 낮은 Fan-out
- 일부 Thumbnail은 아예 사용되지 않음
- 클라이언트 file cache의 높은 hit rate
- 요청했던 Thumbnail도 다시 요청하는 비율이 높지 않음

Thumbnail을 미리 만들어 저장하지
않아도 되지 않을까?

On-demand Resizing
- Thumbnail을 미리 만들어서 S3에 저장해놓지 않고, Client가
요청할 때 원본에서 Resize해주는 방식으로 변경하기로 함
On-demand
Resize
Resize during
Upload

Old Architecture – Resize during upload
S3Server
User
Client Original Image Thumbnails
- Client가 새로운 사진을 업로드 하면 Server가 Resize해서
Thumbnail들을 생성하고, S3에 저장

Old Architecture – Resize during upload
S3
Partner
Client
50x50.jpg
100x100.jpg
200x200.jpg
Original.jpg
DB
GET, 200x200.jpg
Thumbnail
Server
Thumbnails

New Architecture – On-demand resize
S3ServerOriginal Image Original Image
- Client가 새로운 사진을 업로드 하면 Server가 Resize하지
않고 원본을 바로 저장

New Architecture – On-demand resize
S3
Partner
Client
Original.jpg
DB
Resize Server
Server
Thumbnail
GET, Original.jpg, 200x200
Original Image

On-demand Resizing
- Client 요청마다 매번 Resizing을 하는 경우 긴 Resizing
Latency가 사용자 경험을 방해할 수 있음
- 빠른 Resizing이 필요함

SKIA
- Google에서 발표한 2D Graphic Library
- CPU instruction level로 최적화 되어 있어서 Resizing과 Image
format converting에 굉장히 빠름
- ImageMagicK 보다 4 배 가량 빠름 (Resize 기준)

SKIA Benchmark
- Resize 3264x2448 JPEG -> 1000x1000 JPEG
- ImageMagicK보다 4.11 배 빠름
ImageMagicK SKIA
Time (ms) 620 ms 151 ms

On-demand Resizing
- SKIA 덕분에 빠른 Resizing의 목표는 달성
- 여기서 한 발 더 나가 보기로 했습니다
- 원본 이미지를 저장하는 용량을 절약할 수는 없을까?

SKIA
- 역시(?) Google에서 오픈소스화한 이미지 포맷
- 같은 화질의 JPEG에 비해서 26% 용량이 절약됨
- 영상 포맷인 VP8의 파생으로, 영상을 압축할 때 쓰이는 테크닉과
유사한 테크닉이 사용됨

New Architecture
- 원본을 WebP 형식으로 저장
- 클라이언트가 요청하면 JPEG 형식으로 바꾸고 원하는 크기로
Resize해서 내려줌

Resizing Latency
- New Architecture로 migration후에 Resize Latency 측정
- 3백만 픽셀의 90% quality WebP 파일 (145KB)을 45KB의 JPEG로 리사이징
- 원본을 S3에서 받아오는데 걸리는 시간 : 59ms
- Resizing하는데 걸리는 시간 : 37ms
- Resizing Latency < Download Latency
- 충분히 빠르기 때문에 Resizing을 더 최적화 할 필요는 없음

Old Image Migration
- 아직 JPEG로 저장되어 있는 원본 파일들을 WebP로 변환하고, 과거에
만들어 놓은 Thumbnail들을 삭제할 필요가 있음
- 총 11억 장의 JPEG, PNG 파일
- 총 66억 장의 원본 + Thumbnail
- 유저의 이미지가 절대 손실되어서는 안됨

Old Image Migration 순서
1. 커플 작업을 분할해서 SQS에 쌓아놓습니다
2. Worker를 Auto Scaling Group을 통해서 Spot Instance로 띄울 수 있게 준비합니다
3. Worker가 SQS로부터 단위 작업을 받아와서 해당 커플에 존재하는 모든 사진을
WebP로 변환한 후에 S3에 올립니다
4. S3로 WebP변환이 업로드 된게 확인되면 그 사실을 DB에 기록합니다
5. 기존 Thumbnail들을 삭제합니다
6. 기존 Thumbnail이 삭제된 것이 확인되면 DB에 기록합니다.

Old Image Migration
- 모든 과정은 멱등적 (idempotent) 이어야 합니다
- Migration 과정 중에 오류가 발생할 수 있습니다
- Spot instance는 언제든지 다른 bidder에 의해서 뺏길 수 있습니다

Old Image Migration
- Compute-optimized instance를 사용해서 Migration을 진행함
- C3.4xlarge, C4.2xlarge
- DB의 CPU 사용량이 전체 과정의 병목이었음
- DB CPU 사용량에 CloudWatch Alarm을 걸어서 Auto-Scaling Group을
Scale in/out하는데 사용함
- 대부분의 작업이 밤부터 새벽 사이에 진행됨

Old Image Migration
- S3 단일 bucket이 1분당 1천만 개 이상의 object에 대해서는 삭제 요청을
받지 못함
- SQS에서 작업을 진행하면서 visibility를 extend시키고 있는 in-flight
message의 개수가 동시에 12만개를 넘을 수 없음

Old Image Migration
- 약 4일 소모됨
- 최대 140 대의 instance를 사용함
- 6,767 instance · hour
- 303,933 ECU · hour
- 1백만 개의 JPEG를 WebP로 인코딩하는데 $1.8 밖에 들지 않음

Migration 결과
Before Migration After Migration 감소 (%)
S3 파일 개수 66억 5천만 11억 7천만 82.40 %
S3 용량 (TB) 739 TB 184 TB 75.06 %

Migration 비용
Usage Cost ($)
EC2 Spot 6,767 hours 1,959.11
SQS 188,204,104 89.59
S3 Put/Get 2,492,466,860 5,608.34
Total 7,657.04

하지만 직접 만들어서 Migration 했더니
AWS Batch 가 출시되었다고 합니다

AWS Batch
- 배치 컴퓨팅 작업을 효율적으로 실행
- 작업 실행을 위한 배치 컴퓨팅 소프트웨어나 서버 클러스터를
관리할 필요가 없음

그러니까 여러분들도 직접 만들지 말고 AWS가
만들어줄때까지 기다리는게 낫습니다

Conclusion
- 비용 절약을 위한 이미지 처리 Architecture Migration
- SKIA / WebP를 이용한 빠른 이미지 처리와 용량 절약
- 11억장의 이미지를 Spot Instance + AutoScaling을 통해서 인코딩함
- 이미지 저장/처리 비용이 68% 감소

개발자를 모집합니다
- 비트윈 서비스를 같이 운영해 가실 개발자를 모집합니다!
- http://engineering.vcnc.co.kr/jobs/

Thank you!
함께 해주셔서 감사합니다!

https://www.awssummit.kr
AWS Summit 모바일 앱을 통해 지금 세션 평가에
참여하시면, 행사 후 기념품을 드립니다.
#AWSSummitKR 해시태그로 소셜 미디어에
여러분의 행사 소감을 올려주세요.
발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜
채널로 공유될 예정입니다.
여러분의 피드백을 기다립니다!

Amazon S3 이미지 온디맨드 리사이징을 통한 70% 서버 비용 줄이기 - AWS Summit Seoul 2017

Recommended

More Related Content

What's hot (20)

Similar to Amazon S3 이미지 온디맨드 리사이징을 통한 70% 서버 비용 줄이기 - AWS Summit Seoul 2017 (20)

More from Amazon Web Services Korea (20)

Amazon S3 이미지 온디맨드 리사이징을 통한 70% 서버 비용 줄이기 - AWS Summit Seoul 2017