© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

박준형 | 리디북스

인프라관점에서접근하는

신규서비스개발기

발표자소개

박준형

6년차개발자

C / C++ 빠

마소빠

윈도우최고

지금까지손댄것

Linux 응용프로그램

MFC 응용프로그램

WPF 응용프로그램

Reverse proxy

리디북스

리디스토리

이야기할서비스는이렇게생겼어요

뒤에서보면좀복잡해보이네요

서비스개발시작

회원: 개발자 2명

- 만들고있는사이트를테스트해보자.

- WAS

- DB

회원: 개발자 3명

- 서울 Region에 Zone 이두개니까이중화를하자.

- WAS 2개- DB Multi-AZ

회원: 팀원 4명

- 비동기작업- 이메일발송이나시간이오래걸리는작업은비동기로하자.

- Celery 를인스턴스에서같이돌리자.

- Queue는 Rabbit MQ를쓰려고하는데, 이중화랑 Failover가어렵네.

- Session 때문에 Redis 쓸꺼니까 Redis에 Queue 역할도주자.

- Redis Failover는 Sentinel 로하자.

- WAS 2개, Redis 2개- DB Multi-AZ

회원: 팀원 4명

회원: 팀원 6명

- DB 분리- Main DB는소중하니까 Slave를붙이자.

- DB req는가능하면 Slave로가도록개발하자.

- Log 데이터나읽은기록데이터는서비스와무관하니까죽더라도혼자죽으라고 DB를분리하자.

- 물론 Log, 읽기기록은장애가있어도서비스이용에차질이없도록개발하자.

- WAS 2개, Redis 2개- Main DB Multi-AZ, Main DB Slave 1개, Log DB, Reading DB

회원: 팀원 6명

회원: 사내 10명

- 뷰어서버- 뷰어테스트를위해뷰어서버를추가하자.

- 기존의리디북스서버를가져와서개조하자.

- 부하가별로없을것같긴한데다른언어니까따로서버를두자.

- 객체저장- 책파일과미디어(이미지, 동영상) 저장을 S3에하자.

- 책파일은중요하니까미디어와 Bucket을분리하자.

- WAS 2개, View WAS 2개,Redis 2개- Main DB Multi-AZ, Main DB Slave 1개, Log DB, Reading DB

- S3

회원: 사내 10명

회원: 사내 15명

- CDN- 미디어는노출되도상관없고전송이빨라야하니까앞에 CDN을두자.

- JS랑 CSS도 CDN을이용하자.

- TTL 관리하기어려우니모든파일은불변으로간주하자.

- WAS 2개, View WAS 2개, Redis 2개- Main DB Multi-AZ, Main DB Slave 1개, Log DB, Reading DB

- S3, CloudFront

회원: 사내 15명

드디어서비스오픈

회원: 5,000명

- Worker- 기다리면무료, 최신편알림등이비동기 Queue에쌓여서가끔늦게되네.

- 실시간성작업들은전용 Worker에서돌리자.

- Cron도그 Worker가돌리자.

- 모니터링- CloudWatch에연결하자.

- 배포전테스트- Staging서버하나만들자.

- WAS 2개, Worker 1개, Staging 1개, View WAS 2개, Redis 2개- Main DB Multi-AZ, Main DB Slave 1개, Log DB, Reading DB

- S3, CloudFront, CloudWatch

회원: 5,000명

회원: 1만명

- 조회전용 DB- DB가자꾸죽네.

- 운영, 재무팀에서서비스분석을위해엄청난 Query를날리고있네.

- DB인스턴스가여러개라서분석이불편하네.

- 조회전용 DB를만들어서서비스와분리하고모든 DB를 Replication하자.

- WAS 2개, Worker 1개, Staging 1개, View WAS 2개, Redis 2개- Main DB Multi-AZ, Main DB Slave 1개, Log DB, Reading DB, Read DB

- S3, CloudFront, CloudWatch

회원: 1만명

회원: 5만명

- 뷰어서버개선- 설날에차례지내다가뷰어서버죽었네.

- 가끔가끔뷰어서버죽네.

- 만화서비스해야하는데이대로가면안되겠네.

- 책파일은불변이니까뷰어서버가파싱한데이터를 S3에저장하고 CDN

태우자.

- 인증기능은 CloudFront의 Private contents(signed-cookies) 기능을사용하자.

- WAS 2개, Worker 1개, Staging 1개, View WAS 2개, Redis 2개- Main DB Multi-AZ, Main DB Slave 1개, Log DB, Reading DB, Read DB

- S3, CloudFront, CloudWatch

회원: 5만명

회원: 10만명

- ElasticCache- 가끔 Redis 연결이끊기고운영하기번거롭네.

- 운영비용(내인건비포함)도많이차이안나니까 ElasticCache 가자.

- Push Worker- 전체 Push 보내려니까너무느리다 → 대량발송은 SNS쓰자.

- 사람많아지니까기다리면무료알림발송도빡세다 → Push 전용 Worker.

- 서비스 Scale out- 전체 Push 자주보내니까 DB부하가커지네 → Slave추가.

- DB Slave추가하니까 WAS죽네 → WAS 증가.

- WAS증가하니까로그보기어렵다 → 로그수집기추가.

- WAS 8개, Worker 2개, Staging 2개, View WAS 2개, 로그수집기- Main DB Multi-AZ, Main DB Slave 2개, Log DB, Reading DB, Read DB

- S3, CloudFront, CloudWatch, ElasticCache, SNS

회원: 10만명

회원: 20만명

- 이미지최적화- 이미지다운로드가가끔느린게있네. - 헉! 30MB짜리썸네일(?)이다.- 운영팀에서압축하고올린다고했지만, 실수할수있으니따로해주자.- 모든이미지를미리변환하지말고, 필요할때적절하게변형할수있도록하자.- 이럴때Lambda를쓰면최고.

- WAS 8개, Worker 2개, Staging 2개, View WAS 2개, 로그수집기- Main DB Multi-AZ, Main DB Slave 2개, Log DB, Reading DB, Read DB

- S3, CloudFront, CloudWatch, ElasticCache, SNS

- Lambda, API Gateway

회원: 20만명

현재

- TDD- 배포만하면오류나고장애가발생하네.

- 테스트에시간도오래걸리고, 누락되는테스트도있고.

- CI 랑 API tester 추가하자.

- CDN 이중화

- WAS 8개, Worker 2개, Staging 2개, View WAS 2개, 로그수집기- API tester, Travis CI

- Main DB Multi-AZ, Main DB Slave 2개, Log DB, Reading DB, Read DB

- S3, CloudFront, CloudWatch, ElasticCache, SNS

- Lambda, API Gateway

현재

회원: 100만명되기전에할일

- 밤에사람안오니까, 혹은엄청나게올수있으니Auto scailing

- 배포가더쉬워져야하니까 Front & Backend 나누고Docker!

- 회원수증가로DB 데이터가더쌓기전에Sharding준비

- 개발자님모시기

정리를하자면

- 이중화및Auto-failover 는필수입니다.

- RDS를쓴다면Multi-AZ 꼭사용하세요.

- AWS에서제공하는서비스들은따로구축하지말고사용하세요.

- 가능하면Serverless로구성하세요.

감사합니다.