[데일리 스크럼] 2022 11 29

문제 상황

• 초당 약 60개 이상의 응답 제출 요청 시 급격하게 Latency가 증가
  • 응답시간의 median 값과 상위 95, 99 % 의 응답 속도간 차이가 매우 커지는 현상 발생/

• 심한 경우 Timeout 발생
  • 초당 100개 이상의 응답 제출 요청 시 응답 시간이 10초를 넘어가서 errors.ETIMEDOUT가 발생

• 결과 그래프

원인 파악

MongoDB에서의 write 작업 병목 현상(추정)

• 근거
  • 서버를 분산하여 동작시킨 경우에도 여전히 문제가 발생
    • 배포 서버로 초당 50개, 로컬 서버로 초당 50개의 요청을 보냄
    • 배포 서버에서의 결과

    - 로컬 서버에서의 결과

- 배포 서버 측에서 CPU 점유율이나 메모리 사용량에 문제점이 발견되지 않음

해결 방법

Sharding 도입

• 현재 사용하는 atlas 서비스의 스펙은 sharding 불가능하다. atlas에서 sharding 이용하려면 일단 더 좋은 서비스로 이동해야 함
• 장점
  • 고가용성
    • shard 하나에 문제가 생겨도 다른 shard는 정상적으로 동작한다
• 단점
  • 여러 shard를 거치게 되는 query의 경우 문제가 발생한다
  • 신중하게 해야한다
  • 관리가 어려워 진다

Caching 도입

• Redis 캐시의 write-back 전략을 이용하여 캐시를 queue 처럼 사용한다.

  • 참고자료:

    [[REDIS] 📚 캐시(Cache) 설계 전략 지침 💯 총정리](https://inpa.tistory.com/entry/REDIS-%F0%9F%93%9A-%EC%BA%90%EC%8B%9CCache-%EC%84%A4%EA%B3%84-%EC%A0%84%EB%9E%B5-%EC%A7%80%EC%B9%A8-%EC%B4%9D%EC%A0%95%EB%A6%AC)

• 장점

  • 백엔드 개발자 직무에 좀 더 알맞다.
  • 실패해도 돌아갈수 있다
  • 읽기, 쓰기 모두에서 부하 분산이 가능하다.

• 단점

  • 캐시서버가 부하를 다 맞는다
  • 주기적으로 DB와 cache간 업데이트를 해 주어야 한다
  • 캐시 서버가 죽으면 데이터가 날아간다.

Scale up

• ncp에 mongoDB 직접 설치

선택한 해결 방안

Caching 도입

• 선택 이유
  • 주기적인 업데이트가 필요하다는 단점의 경우, 설문조사 서비스에서는 큰 문제가 되지 않음
    • 결과를 실시간으로 보여주지 않는 이상 큰 문제가 되지 않음
    • 설문지의 내용은 자주 바뀌지 않음
  • 게시판 읽기 캐싱 커스텀 최적화
    • 같은 데이터를 여러 사용자가 읽는 경우
    • 한번의 사용자 접근에 DB를 여러번 읽는 경우

오늘 할 일

• 레디스 전략 선택
• 레디스 학습
• 레디스 캐시 서버 구성 - [참고자료](https://jinho9610.tistory.com/47?category=1009788)
• 응답 페이지 백엔드와 연동
• 응답 페이지 상태 관리 구현