연사: 리디북스 박준형 책임 https://aws.amazon.com/ko/events/start-up/

1. © 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
박준형 | 리디북스
인프라 관점에서 접근하는
신규 서비스 개발기

2. 발표자 소개
박준형
6년차 개발자
C / C++ 빠
마소 빠
윈도우 최고

3. 지금까지 손댄것
Linux 응용프로그램
MFC 응용프로그램
WPF 응용프로그램
Reverse proxy
리디북스
리디스토리

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

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

6. 서비스 개발 시작

7. 회원: 개발자 2명
- 만들고 있는 사이트를 테스트 해보자.
- WAS
- DB

8. 회원: 개발자 3명
- 서울 Region에 Zone 이 두개니까 이중화를 하자.
- WAS2개
- DBMulti-AZ

9. 회원: 팀원 4명
- 비동기 작업
- 이메일 발송이나 시간이 오래 걸리는 작업은 비동기로 하자.
- Celery 를 인스턴스에서 같이 돌리자.
- Queue는 Rabbit MQ를 쓰려고 하는데, 이중화랑 Failover가 어렵네.
- Session 때문에 Redis 쓸꺼니까 Redis에 Queue 역할도 주자.
- Redis Failover는 Sentinel 로 하자.
- WAS2개,Redis2개
- DBMulti-AZ

10. 회원: 팀원 4명

11. 회원: 팀원 6명
- DB 분리
- Main DB는 소중하니까 Slave를 붙이자.
- DB req는 가능하면 Slave로 가도록 개발하자.
- Log 데이터나 읽은 기록 데이터는 서비스와 무관하니까 죽더라도 혼자 죽
으라고 DB를 분리하자.
- 물론 Log, 읽기 기록은 장애가 있어도 서비스 이용에 차질이 없도록 개발하
자.
- WAS2개,Redis2개
- MainDBMulti-AZ,MainDBSlave1개,LogDB,ReadingDB

12. 회원: 팀원 6명

13. 회원: 사내 10명
- 뷰어서버
- 뷰어 테스트를 위해 뷰어 서버를 추가하자.
- 기존의 리디북스 서버를 가져와서 개조하자.
- 부하가 별로 없을것 같긴 한데 다른 언어니까 따로 서버를 두자.
- 객체 저장
- 책파일 과 미디어(이미지, 동영상) 저장을 S3에 하자.
- 책파일은 중요하니까 미디어와 Bucket을 분리 하자.
- WAS2개,ViewWAS 2개,Redis2개
- MainDBMulti-AZ,MainDBSlave1개,LogDB,ReadingDB
- S3

14. 회원: 사내 10명

15. 회원: 사내 15명
- CDN
- 미디어는 노출되도 상관 없고 전송이 빨라야 하니까 앞에 CDN을 두자.
- JS랑 CSS도 CDN을 이용하자.
- TTL 관리 하기 어려우니 모든 파일은 불변으로 간주하자.
- WAS2개,ViewWAS2개,Redis2개
- MainDBMulti-AZ,MainDBSlave1개,LogDB,ReadingDB
- S3,CloudFront

16. 회원: 사내 15명

17. 드디어 서비스 오픈

18. 회원: 5,000명
- Worker
- 기다리면 무료, 최신편 알림 등이 비동기 Queue에 쌓여서 가끔 늦게 되네.
- 실시간성 작업들은 전용 Worker에서 돌리자.
- Cron도 그 Worker가 돌리자.
- 모니터링
- CloudWatch에 연결하자.
- 배포전 테스트
- Staging서버 하나 만들자.
- WAS2개,Worker1개,Staging1개,ViewWAS2개,Redis2개
- MainDBMulti-AZ,MainDBSlave1개,LogDB,ReadingDB
- S3,CloudFront,CloudWatch

19. 회원: 5,000명

20. 회원: 1만명
- 조회 전용 DB
- DB가 자꾸 죽네.
- 운영, 재무팀에서 서비스 분석을 위해 엄청난 Query를 날리고 있네.
- DB인스턴스가 여러개라서 분석이 불편하네.
- 조회 전용 DB를 만들어서 서비스와 분리 하고 모든 DB를 Replication하자.
- WAS2개,Worker1개,Staging1개,ViewWAS2개,Redis2개
- MainDBMulti-AZ,MainDBSlave1개,LogDB,ReadingDB,ReadDB
- S3,CloudFront,CloudWatch

21. 회원: 1만명

22. 회원: 5만명
- 뷰어서버 개선
- 설날에 차례지내다가 뷰어 서버 죽었네.
- 가끔 가끔 뷰어 서버 죽네.
- 만화 서비스 해야 하는데 이대로 가면 안되겠네.
- 책파일은 불변이니까 뷰어서버가 파싱한 데이터를 S3에 저장하고 CDN
태우자.
- 인증 기능은 CloudFront의 Private contents(signed-cookies) 기능을 사용
하자.
- WAS2개,Worker1개,Staging1개,ViewWAS2개,Redis2개
- MainDBMulti-AZ,MainDBSlave1개,LogDB,ReadingDB,ReadDB
- S3,CloudFront,CloudWatch

23. 회원: 5만명

24. 회원: 10만명
- ElasticCache
- 가끔 Redis 연결이 끊기고 운영하기 번거롭네.
- 운영비용(내 인건비 포함)도 많이 차이 안나니까 ElasticCache 가자.
- Push Worker
- 전체 Push 보내려니까 너무 느리다 → 대량발송은 SNS쓰자.
- 사람 많아지니까 기다리면 무료 알림발송도 빡세다 → Push 전용 Worker.
- 서비스 Scale out
- 전체 Push 자주 보내니까 DB부하가 커지네 → Slave추가.
- DB Slave추가하니까 WAS죽네 → WAS 증가.
- WAS증가하니까 로그 보기 어렵다 → 로그 수집기 추가.
- WAS8개,Worker2개,Staging2개,ViewWAS2개,로그수집기
- MainDBMulti-AZ,MainDBSlave2개,LogDB,ReadingDB,ReadDB
- S3,CloudFront,CloudWatch,ElasticCache,SNS

25. 회원: 10만명

26. 회원: 20만명
- 이미지 최적화
- 이미지 다운로드가 가끔 느린게 있네.
- 헉! 30MB짜리 썸네일(?)이다.
- 운영팀에서 압축하고 올린다고 했지만, 실수 할 수 있으니 따로 해주자.
- 모든 이미지를 미리 변환하지 말고, 필요할 때 적절하게 변형할 수 있도록 하자.
- 이럴때 Lambda를 쓰면 최고.
- WAS8개,Worker2개,Staging2개,ViewWAS2개,로그수집기
- MainDBMulti-AZ,MainDBSlave2개,LogDB,ReadingDB,ReadDB
- S3,CloudFront,CloudWatch,ElasticCache,SNS
- Lambda,API Gateway

27. 회원: 20만명

28. 현재
- TDD
- 배포만 하면 오류 나고 장애가 발생하네.
- 테스트에 시간도 오래 걸리고, 누락되는 테스트도 있고.
- CI 랑 API tester 추가하자.
- CDN 이중화
- WAS8개,Worker2개,Staging2개,ViewWAS2개,로그수집기
- API tester,Travis CI
- MainDBMulti-AZ,MainDBSlave2개,LogDB,ReadingDB,ReadDB
- S3,CloudFront,CloudWatch,ElasticCache,SNS
- Lambda,APIGateway

29. 현재

30. 회원: 100만명 되기 전에 할일
- 밤에 사람 안오니까, 혹은 엄청나게 올 수 있으니 Auto
scailing
- 배포가 더 쉬워져야 하니까 Front & Backend 나누고 Docker!
- 회원수 증가로 DB 데이터가 더 쌓기 전에 Sharding 준비
- 개발자님 모시기

31. 정리를 하자면
- 이중화 및 Auto-failover 는 필수 입니다.
- RDS를 쓴다면 Multi-AZ 꼭 사용하세요.
- AWS에서 제공하는 서비스들은 따로 구축하지 말고 사용하세
요.
- 가능하면 Serverless로 구성하세요.

32. 감사합니다.