알람몬으로 알아보는 Node.js 트러블 슈팅 케이스 스터디
- 1. 알람몬으로 알아보는 Node.js 트러블 슈팅 케이스 스터디 말랑스튜디오 최치웅
- 2. 소개 • 2006.03 ~ 2008.05 ㈜모빌탑 • 2008.06 ~ 2010.12 ㈜네이블커뮤니케이션즈 • 2011.01 ~ 2011.12 ㈜말랑스튜디오 • 2012.01 ~ 2014.01 ㈜삼성전자 • 2014.02 ~ 현재 ㈜말랑스튜디오
- 3. 0. 시작하기에 앞서 • 알람몬 • Standalone Application 형태 • 이미 유저는 많이 모인 상태 • 비즈니스 모델 고도화를 위하여 서버 개발이 필요했음 • 회사에는 서버 개발 해본 사람이 없음 • 처음에는 KTH에서 서비스하던 baas.io를 사용, baas.io의 서비스 종료로 인하여 node.js로 직접 서버 개발 및 구축
- 4. 1. Spike traffic • 다들 비슷한 시간에 일어남 • 대부분의 사람들이 0, 15, 30 등 딱 떨어지는 숫자를 선호 • 알람 어플의 특성 상 그 외의 시간은 자원들이 놀고 있음
- 6. 1. Spike traffic • Shared Instance • Node.js – Heroku • MongoDB – compose.io • Redis - RedisLabs • Time based Scaling • Heroku API를 이용하여 직접 구현
- 7. 2. Cluster • Node.js를 돌릴 때, 아무리 성능 좋은 서버에 배포하더라도 실제 성능이 나아지지 않음 • Single thread 사용 • V8 엔진 자체의 기본 제약조건들이 영향을 미침 • 위의 부분들을 해결하기 위해 Node.js에서는 Cluster API를 제공 • Cluster API가 굉장히 쉽게 되어있지만 더 잘 만들어진 throng을 사용 • https://github.com/hunterloftis/throng
- 8. 3. Database • 특별히 이상 지표가 없이 DB와 관련된 부분의 성능이 급격히 하락하기 시작함
- 9. 3. Database • 1차 수정 • Connection Pool 사이즈 조정 • Default: 5 -> 10으로 조정
- 10. 3. Database • 2차 수정 • Index를 생성하기 시작 • Compound Index를 적극적으로 활용
- 11. 3. Database • 2차 수정 • explain()을 적극 활용
- 12. 3. Database • 3차 수정 • KeepAlive 설정을 활성화
- 13. 4. Cache • MongoDB의 Index 추가 이후로도 성능문제가 해결되지 않아 Redis를 이용한 Cache를 도입 • Peak Time의 Transaction Data를 분석 시, Redis가 병목
- 14. 4. Cache • CDN을 API 서버 앞에 도입 • GET에 한하여 Expire header로 Cache control
- 15. TIP – EC2 • 메모리 릭에 주의!! • (EC2 사용 중 RAM을 모두 사용하면 ssh조차 붙지 못하는 좀비 모드(가칭)에 들어감) • Auto Scaling은 만능 툴이 아님 • Auto Scaling으로 EC2 Instance가 추가될 때 EBS I/O가 발생하여 추가 요금 발생함
- 16. TIP – Atomic Function by MySQL • MySQL의 User Lock을 이용하여 Atomic Function을 구현
- 17. TIP – Optimistic Lock by Redis • Redis의 Transaction을 이용하여 MongoDB에서 지원하지 않는 Optimistic Lock 을 구현
- 18. 5. 결론 • 리소스를 알뜰하게 투자하면서 투자대비 효용성 높은 목표지향 • 외부서비스 사용에는 장점과 단점이 분명히 존재함 • 외부서비스를 사용시 서비스 선정의 기준을 세우는것이 중요함 그러나 무엇보다 중요한것은 메인 프로덕트와 핵심 비즈니스에 집중할 수 있는 시간을 만드는것!
- 19. Q&A
- 20. 감사합니다.