피플펀드 웹서비스 성능개선기(+초기 스타트업의 개발방법론) 20171220
•
4 likes•879 views
AWS위에 Django를 올려서 활용하고 있는 피플펀드의 서비스에서 성능개선을 위해 AWS CloudWatch, New Relic APM 등을 활용해 점검했던 포인트와 해결방법, 그리고 성과에 대해서 공유합니다.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 피플펀드 웹서비스 성능개선기(+초기 스타트업의 개발방법론) 20171220
Similar to 피플펀드 웹서비스 성능개선기(+초기 스타트업의 개발방법론) 20171220 (20)
피플펀드 웹서비스 성능개선기(+초기 스타트업의 개발방법론) 20171220
- 2. 피플펀드 웹서비스 성능개선기 피플펀드 한섬기 어쩌면, 스타트업의 개발 방법론
- 3. 이 이야기는 피플펀드 개발팀이 모두 함께 작업한 내용입니다.
- 4. 이 이야기는 피플펀드 개발팀이 모두 함께 작업한 내용입니다. 하지만 마치 제가 다 한 것처럼 이야기 해볼게요.
- 5. 오늘의 퀘스트
- 6. 손들고 질문해보기노말 퀘스트 오늘의 퀘스트
- 7. 손들고 질문해보기 손들고 반대해보기 노말 퀘스트 하드 퀘스트 오늘의 퀘스트
- 8. 손들고 질문해보기 손들고 반대해보기 노말 퀘스트 하드 퀘스트 오늘의 퀘스트 해도 되고 안 해도 그만퀘스트 보상 없습니다
- 9. 갑자기 예상보다 많은 유저가 몰렸을 때 대처했던 이야기
- 10. 갑자기 예상보다 많은 유저가 몰렸을 때 대처했던 이야기 이면서, 초기 스타트업이 어떻게 개발해야하는지에 대한 고민 이야기
- 11. 문제 발견 원인 파악 선행 작업 개선 작업 성과 측정
- 12. 문제 발견
- 13. 사실 알고 있었다.
- 15. “섬기님, 사이트가 느려요!!!” “네, 좀 느리네요.”보지도 않고 얘기하기
- 16. “섬기님, 사이트가 느려요!!!” “네, 좀 느리네요.” 바쁜 스타트업에서 사이트가 조금 느린 것은 업무의 우선순위에 들어오지 않는다. 보지도 않고 얘기하기
- 17. “섬기님, 사이트가 느려요!!!” “네, 좀 느리네요.” 바쁜 스타트업에서 사이트가 조금 느린 것은 업무의 우선순위에 들어오지 않는다. 보지도 않고 얘기하기 그런데 진짜 문제가 있었다…
- 19. 업무 우선순위가 아니었음에도 어떻게든 시간을 내서,
- 20. AWS CloudWatch*에 몇몇 지표를 생성해두었음 https://aws.amazon.com/cloudwatch* 업무 우선순위가 아니었음에도 어떻게든 시간을 내서,
- 21. AWS CloudWatch*에 몇몇 지표를 생성해두었음 https://aws.amazon.com/cloudwatch https://newrelic.com/python * ** 업무 우선순위가 아니었음에도 어떻게든 시간을 내서, New Relic APM**을 API서버에 연동해두었음
- 22. AWS CloudWatch*에 몇몇 지표를 생성해두었음 https://aws.amazon.com/cloudwatch https://newrelic.com/python * ** 업무 우선순위가 아니었음에도 어떻게든 시간을 내서, New Relic APM**을 API서버에 연동해두었음 Django ORM을 어떻게 하면 좀 더 빠르게 동작하도록 만들 수 있는지, 적어도 방향성에 대한 논의를 조금 해두었음
- 23. AWS CloudWatch*에 몇몇 지표를 생성해두었음 https://aws.amazon.com/cloudwatch https://newrelic.com/python * ** 업무 우선순위가 아니었음에도 어떻게든 시간을 내서, New Relic APM**을 API서버에 연동해두었음 Django ORM을 어떻게 하면 좀 더 빠르게 동작하도록 만들 수 있는지, 적어도 방향성에 대한 논의를 조금 해두었음 이에 따라 야금야금 개선하고 있었음
- 24. 그럼에도 불구하고, 터진 사건
- 25. 웹페이지 로딩시간이 10~30초 API 응답도 10~30초
- 26. 웹페이지 로딩시간이 10~30초 API 응답도 10~30초 뙇 더불어서 약 25%의 접속은 Nginx가 바로 내려주는 502 Bad Gateway
- 27. 원인 파악
- 28. 사실, 역시 알고 있었다.
- 29. 피플펀드 서비스는, 점심 때 신규채권 안내문자와 알림톡이 발송된 직후 10~20분간 하루의 모든 트래픽이 몰리는 구조
- 31. Auto-scaling 같은 거 안됨
- 32. Auto-scaling 같은 거 안됨 30초 안에 Auto-scaling 하는 것은 불가능 감지되고 추가 서버 올라올 때쯤이면 이미 메인 트래픽은 모두 오류를 겪는 상황
- 33. 가장 중요한 입금, 출금, 투자, 상환 모두 LOCK과 함께하는 트랜젝션으로 처리됨
- 34. 가장 중요한 입금, 출금, 투자, 상환 모두 LOCK과 함께하는 트랜젝션으로 처리됨 물론 row 단위 lock이기는 함
- 35. 투자자 분들의 자금도 중요하고 사이트 속도도 빨라야함
- 36. 그런데, 개발도 빨리해야함
- 37. 최우선 순위는 투자자 분들의 자금
- 38. 최우선 순위는 투자자 분들의 자금 나머지는 잠시(?) 포기
- 39. 여기서 잠깐, 기술 부채는 어느 정도가 적당할까?
- 40. 다른 것들은 잘 모르겠지만 피플펀드 시스템을 만들면서 얻은 교훈 하나,
- 41. 처음 사용하는 거라면 어떻게든 조금은 공부하고 사용하자 다른 것들은 잘 모르겠지만 피플펀드 시스템을 만들면서 얻은 교훈 하나,
- 42. 처음 사용하는 거라면 어떻게든 조금은 공부하고 사용하자 다른 것들은 잘 모르겠지만 피플펀드 시스템을 만들면서 얻은 교훈 하나, 달려가는 자동차의 바퀴를 갈아끼는 것은 정말 힘들다. 시간이 누구보다 소중한 스타트업에서는.
- 43. 처음 사용하는 거라면 어떻게든 조금은 공부하고 사용하자 다른 것들은 잘 모르겠지만 피플펀드 시스템을 만들면서 얻은 교훈 하나, 달려가는 자동차의 바퀴를 갈아끼는 것은 정말 힘들다. 시간이 누구보다 소중한 스타트업에서는. 하지만 개발팀이 사업의 성장을 견인하지 못하면, 모든 것이 물거품이다.
- 44. 처음 사용하는 거라면 어떻게든 조금은 공부하고 사용하자 다른 것들은 잘 모르겠지만 피플펀드 시스템을 만들면서 얻은 교훈 하나, 달려가는 자동차의 바퀴를 갈아끼는 것은 정말 힘들다. 시간이 누구보다 소중한 스타트업에서는. 하지만 개발팀이 사업의 성장을 견인하지 못하면, 모든 것이 물거품이다. 안타깝지만 결론은 상황에 따른 적절한 판단력이 가장 최고의 해결책. 그럼에도 불구하고, 시급성과 중요성 중에서 중요한 것을 놓지지 않을 수 있는 방법을 항상 고민하자.
- 45. 아무튼, 그 결과 이렇게 됨 w/ NewRelic APM * NewRelic APM에서는 사건 당시 처참한 장면을 스샷으로 찍어두지 못함
- 46. 아무튼, 그 결과 이렇게 됨 w/ NewRelic APM * NewRelic APM에서는 사건 당시 처참한 장면을 스샷으로 찍어두지 못함
- 47. 아무튼, 그 결과 이렇게 됨 w/ NewRelic APM * NewRelic APM에서는 사건 당시 처참한 장면을 스샷으로 찍어두지 못함
- 48. 아무튼, 그 결과 이렇게 됨 w/ CloudWatch * CloudWatch는 몇 개월 전 데이터도 다 보관됨 무서운 놈들임
- 49. 아무튼, 그 결과 이렇게 됨 SWAP 사용율 미친듯이 올라감 w/ CloudWatch * CloudWatch는 몇 개월 전 데이터도 다 보관됨 무서운 놈들임
- 50. 아무튼, 그 결과 이렇게 됨 DB 연결/사용량 미친듯이 늘어남 w/ CloudWatch * CloudWatch는 몇 개월 전 데이터도 다 보관됨 무서운 놈들임
- 51. 아무튼, 그 결과 이렇게 됨 응답시간 ‘평균’ 8초 이상 w/ CloudWatch * CloudWatch는 몇 개월 전 데이터도 다 보관됨 무서운 놈들임
- 52. 아무튼, 그 결과 이렇게 됨 HTTP Status 200 외의 다른 응답이 미친듯이 나감 w/ CloudWatch * CloudWatch는 몇 개월 전 데이터도 다 보관됨 무서운 놈들임
- 53. 선행 작업
- 54. 목표는 3가지
- 55. NewRelic APM의 ‘Most time consuming’ 페이지를 기준으로 TOP 5 API를 순위권에서 없애기 웹서버의 에러응답 비율 낮추기 EC2 인스턴스의 사양을 높이고 수를 늘리기 목표는 3가지
- 56. 히든 퀘스트
- 57. 딱 하나의 병목을 해결한다고 끝나는 문제가 아님을 다른 부서와 공유하기 히든 퀘스트 당황하지 말고 수치로 말할 수 있는 전후 결과 만들기
- 58. 딱 하나의 병목을 해결한다고 끝나는 문제가 아님을 다른 부서와 공유하기 히든 퀘스트 당황하지 말고 수치로 말할 수 있는 전후 결과 만들기 덜떨어진 개발팀, 혹은 자존심만 쎈 개발팀이 되는 순간 신뢰를 잃는다
- 59. 딱 하나의 병목을 해결한다고 끝나는 문제가 아님을 다른 부서와 공유하기 히든 퀘스트 당황하지 말고 수치로 말할 수 있는 전후 결과 만들기 덜떨어진 개발팀, 혹은 자존심만 쎈 개발팀이 되는 순간 신뢰를 잃는다 명확한 의사소통 능력과 자연스러운 성과 공유 또한 몸값을 올리는 중요한 사회생존기술 중에 하나이다
- 60. 개선 작업
- 61. API 개선하기 ORM을 정확히 파악하기
- 62. API 개선하기 ORM을 정확히 파악하기 * https://pypi.python.org/pypi/django-debug-toolbar
- 63. API 개선하기 # DB에 접속 e = Entry.objects.get(id=5) # 관련된 Blog 객체를 가져오기 위해 DB에 한번 더 접속 b = e.blog ORM을 정확히 파악하기 *https://tech.peoplefund.co.kr/2017/11/03/django-db-optimization.html
- 64. API 개선하기 # DB에 접속 e = Entry.objects.get(id=5) # 관련된 Blog 객체를 가져오기 위해 DB에 한번 더 접속 b = e.blog ORM을 정확히 파악하기 *https://tech.peoplefund.co.kr/2017/11/03/django-db-optimization.html loop였다면…!
- 65. API 개선하기 # DB에 접속 e = Entry.objects.get(id=5) # 관련된 Blog 객체를 가져오기 위해 DB에 한번 더 접속 b = e.blog ORM을 정확히 파악하기 *https://tech.peoplefund.co.kr/2017/11/03/django-db-optimization.html # select_related을 사용 # DB에 접속 e = Entry.objects.select_related('blog').get(id=5) # 이미 위에서 관련된 Blog객체들을 가져왔기 때문에 DB에 접속하지 않음 b = e.blog loop였다면…!
- 67. API 개선하기 미리 계산해두기 채권 목록에서 각 채권에 법인이나 기관이 투자한 비중을 표시하기 위해 목록을 순회하며 각 채권에 투자된 건을 계산하는 대신, 채권 정보에 법인/기관의 투자 금액을 투자 시점에 기록해둔다. 예시:
- 68. API 개선하기 미리 계산해두기 채권 목록에서 각 채권에 법인이나 기관이 투자한 비중을 표시하기 위해 목록을 순회하며 각 채권에 투자된 건을 계산하는 대신, 채권 정보에 법인/기관의 투자 금액을 투자 시점에 기록해둔다. 예시:
- 69. API 개선하기 미리 계산해두기 채권 목록에서 각 채권에 법인이나 기관이 투자한 비중을 표시하기 위해 목록을 순회하며 각 채권에 투자된 건을 계산하는 대신, 채권 정보에 법인/기관의 투자 금액을 투자 시점에 기록해둔다. 예시:
- 70. API 개선하기 미리 계산해두기 채권 목록에서 각 채권에 법인이나 기관이 투자한 비중을 표시하기 위해 목록을 순회하며 각 채권에 투자된 건을 계산하는 대신, 채권 정보에 법인/기관의 투자 금액을 투자 시점에 기록해둔다. 예시: 채권 투자건 기관 투자자 투자건 법인 투자자 투자건 일반 투자자 … …
- 71. API 개선하기 미리 계산해두기 채권 목록에서 각 채권에 법인이나 기관이 투자한 비중을 표시하기 위해 목록을 순회하며 각 채권에 투자된 건을 계산하는 대신, 채권 정보에 법인/기관의 투자 금액을 투자 시점에 기록해둔다. 예시: 채권 투자건 기관 투자자 투자건 법인 투자자 투자건 일반 투자자 + 기관 투자자의 총 투자금액 + 전체 투자자의 총 투자금액 … …
- 72. API 개선하기 미리 계산해두기 채권 목록에서 각 채권에 법인이나 기관이 투자한 비중을 표시하기 위해 목록을 순회하며 각 채권에 투자된 건을 계산하는 대신, 채권 정보에 법인/기관의 투자 금액을 투자 시점에 기록해둔다. 예시: 교과서적인 방법론으로 해결할 수 없는 부분은 과감히 원칙을 버린다. 반정규화(역정규화)
- 73. API 개선하기 DB Indexing w/ MySQL WorkBench Execution Plan
- 74. API 개선하기 DB Indexing w/ MySQL WorkBench Execution Plan
- 75. API 개선하기 DB Indexing w/ MySQL WorkBench Execution Plan 나의 Query가 Index를 탐색하는지 살펴보자
- 76. API 개선하기 DB Indexing w/ MySQL WorkBench Execution Plan 꿀팁
- 77. API 개선하기 Caching w/ CloudFront
- 78. API 개선하기 Caching w/ CloudFront 채권 목록 API는 1분 단위 캐싱을 한다.예시:
- 79. API 개선하기 Caching w/ CloudFront 채권 목록 API는 1분 단위 캐싱을 한다.예시: CloudFront의 캐싱 결과
- 80. API 개선하기 Caching w/ CloudFront 채권 목록 API는 1분 단위 캐싱을 한다.예시:
- 81. 502 Bad Gateway w/ Nginx
- 82. 502 Bad Gateway w/ Nginx 뙇
- 83. 502 Bad Gateway … connect() to unix: … sock failed (Resource temporarily unavailable) … w/ Nginx Nginx 로그에 남아있는 하나의 단서
- 84. 502 Bad Gateway … connect() to unix: … sock failed (Resource temporarily unavailable) … w/ Nginx Nginx 로그에 남아있는 하나의 단서 +@ “설정값 하나만 바꾸면 될 것 같은데…”
- 85. 502 Bad Gateway … connect() to unix: … sock failed (Resource temporarily unavailable) … w/ Nginx Nginx 로그에 남아있는 하나의 단서 +@ “설정값 하나만 바꾸면 될 것 같은데…” +@ “누구는 되고 누구는 안되요”
- 86. 502 Bad Gateway sudo vi /etc/sysctl.conf w/ Nginx net.core.somaxconn=1024 sudo reboot now * http://www.ryanfrantz.com/posts/apache-tcp-backlog/ * http://meetup.toast.com/posts/54 * https://brunch.co.kr/@alden/6
- 87. 성과 측정
- 88. 아무튼, 그 결과 이렇게 됨 w/ CloudWatch
- 89. 아무튼, 그 결과 이렇게 됨 w/ CloudWatch * CloudWatch는 몇 개월 전 데이터도 다 보관됨 무서운 놈들임
- 90. 아무튼, 그 결과 이렇게 됨 w/ CloudWatch * CloudWatch는 몇 개월 전 데이터도 다 보관됨 무서운 놈들임
- 91. 아무튼, 그 결과 이렇게 됨 w/ 일반인
- 92. 아무튼, 그 결과 이렇게 됨 w/ 일반인 월요일 피크타임과 동일한 x개의 접속 중, 오류 비율을 25%에서 3%로 낮췄습니다.
- 93. 아무튼, 그 결과 이렇게 됨 w/ 일반인 월요일 피크타임과 동일한 x개의 접속 중, 오류 비율을 25%에서 3%로 낮췄습니다.