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

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

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

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

5. Between

6. Old Architecture
New Architecture
Migration

7. Old Architecture
New Architecture
Migration

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

9. 정말 좋아합니다

10. Between 사진

11. 서로 다른 크기의 Thumbnail

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

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

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

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

18. Client Screen Size

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

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

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

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

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

24. Old Architecture
New Architecture
Migration

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

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

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

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

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

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

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

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

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

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

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

36. New Architecture

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

38. Old Architecture
New Architecture
Migration

39. Architecture Migration

40. Architecture Migration

41. Architecture Migration

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

43. 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에 기록합니다.

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

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

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

47. Old Image Migration

48. Old Image Migration

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

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

51. 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

52. 전체 비용 절약

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

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

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

57. Conclusion

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

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

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

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