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
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의 파생으로, 영상을 압축할 때 쓰이는 테크닉과
유사한 테크닉이 사용됨
37. Resizing Latency
- New Architecture로 migration후에 Resize Latency 측정
- 3백만 픽셀의 90% quality WebP 파일 (145KB)을 45KB의 JPEG로 리사이징
- 원본을 S3에서 받아오는데 걸리는 시간 : 59ms
- Resizing하는데 걸리는 시간 : 37ms
- Resizing Latency < Download Latency
- 충분히 빠르기 때문에 Resizing을 더 최적화 할 필요는 없음
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만개를 넘을 수 없음
58. Conclusion
- 비용 절약을 위한 이미지 처리 Architecture Migration
- SKIA / WebP를 이용한 빠른 이미지 처리와 용량 절약
- 11억장의 이미지를 Spot Instance + AutoScaling을 통해서 인코딩함
- 이미지 저장/처리 비용이 68% 감소
59. 개발자를 모집합니다
- 비트윈 서비스를 같이 운영해 가실 개발자를 모집합니다!
- http://engineering.vcnc.co.kr/jobs/
61. https://www.awssummit.kr
AWS Summit 모바일 앱을 통해 지금 세션 평가에
참여하시면, 행사 후 기념품을 드립니다.
#AWSSummitKR 해시태그로 소셜 미디어에
여러분의 행사 소감을 올려주세요.
발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜
채널로 공유될 예정입니다.
여러분의 피드백을 기다립니다!