[2017 AWS Startup Day] 인프라 관점에서 접근하는 리디스토리 개발기
3 likes3,458 views
연사: 리디북스 박준형 책임 https://aws.amazon.com/ko/events/start-up/
[2017 AWS Startup Day] 인프라 관점에서 접근하는 리디스토리 개발기
- 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. 감사합니다.