느려진 서비스, 어디부터 봐야 할까?

본 내용은 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 도서를 참고하여 작성되었습니다.

주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 | 최범균 | 한빛미디어 - 예스24

 

 

성능 문제는 주로 DB나 외부 API를 연동하는 과정에서 발생한다.

• 외부 API 호출에 블로킹/타임아웃이 발생하는가?
• 힙 크기와 GC 방식에 적절한 최적화가 필요한가?
• OOM이 발생했는가?
• 응답해야 하는 데이터의 양이 많은가?
• DB 커넥션 풀이 고갈되었는가?

문제 예시

• 순간적으로 모든 사용자 요청에 대한 응답 시간이 심각하게 느려진다. 10초 이상 걸리는 요청이 늘어나고 다수의 요청에서 연결 시간 초과와 같은 오류가 발생한다.
• 서버를 재시작하면 잠시 괜찮다가 다시 응답 시간이 느려지는 현상이 반복된다.
• 트래픽이 줄어들 때까지 심각한 상황이 계속된다.

이럴 때를 대비하여 모니터링과 로깅이 병행되어야 한다.
이 둘은 디버깅의 필수불가결한 자산이 된다.

---

그렇다면 이러한 문제는 어떻게 해결해야 할까?

크게 이야기하면

1. 응답 시간, TPS 등의 지표를 참고해라.
2. 병목 지점이 어디인지 정확히 파악하라.
   1. 서버 문제인가?
   2. DB 문제인가?

이때, 주어진 지표의 패턴과 출력을 통한 디버깅을 통해 원인을 분석해야 한다.

해결책

• 서버를 무상태로 설계한 뒤, scale-out을 수행한다.
  • 이때, DB나 외부 API에 문제가 생기지 않을 정도로 Scale-out을 수행해야 한다.
  • 예를 들어, scale-out이 지나치게 커지면, DB 내 스레드 풀의 150개의 스레드가 고갈될 수 있다.
• 비동기로 작업을 수행한다.
  • 별도 스레드/메시징/트랜잭션 아웃박스/배치/CDC
• 대기 시간을 짧게 설정하여, 요청이 계속 누적되지 않도록 만든다.
• 지금 당장 해결책이 필요하다면, scale-up을 수행한다.
• 처리할 데이터의 크기가 큰 경우(OOM), 스트림 형태의 전송을 통한 분할 처리를 고려한다. 
• 응답 데이터의 양이 많을 경우, 응답 데이터 압축/CDN을 고려한다.

• DB 커넥션 풀 고갈 문제의 경우, 커넥션 크기를 조정한다.
  • 이때, DB에 부하가 가지 않을 정도로만 커넥션의 크기를 키우는 것이 좋다.
  • 커넥션이 지나치게 많아질 경우, DB에 가해지는 부하가 더 커져 쿼리 실행 시간이 급격히 증가할 수 있다.
  • 휴리스틱한 기준으로는, DB 서버의 CPU 사용률이 70%가 넘지 않도록 설정하자.
• DB 커넥션 풀이 끊긴 경우, 최대 유휴 시간/유효성 검사/최대 유지 시간 관련 정보를 확인한다.
  • DB는 커넥션이 유휴 상태일 경우, 임의로 클라이언트(여기서는 WAS)와의 연결을 끊는다.
  • 따라서 이 경우, WAS에서 그 전에 연결을 끊고 다시 커넥션을 연결하는 작업을 수행시켜야 한다.
• DB 서버의 확장이 불가능하거나, 데이터 사용 패턴이 캐시에 적합하다면, 캐시 사용을 고려한다.
  • 로컬 캐시 사용이 가능하다면 로컬 캐시를 사용하고, 필요할 때 리모트 캐시를 사용한다.
  • 이때 LRU, LFU, FIFO같은 캐시 데이터 삭제 정책을 고려해야 한다.
  • 또한 Cache Aside, Write Through 와 같은 읽기/쓰기 정책을 고려해야 한다.
  • 캐시 데이터의 "신선도" 문제 또한 고려해야 한다.
• 트래픽이 순간적으로 급증하는 패턴을 보인다면, 캐시에 데이터를 미리 저장하는 것도 고려할 수 있다.