“xxx-api CPU가 계속 스파이크를 찍네요, 이유가 무엇인가요?”
위 질문에 답변을 못한다는 것을 장애가 터지고 깨달았다, 사실 인지는 했지만 외면해두고 있었다
최근 배포한 기능들을 뒤져보며 문제가 될 만한 부분을 찾아 급한 불은 우선 껐지만, 현 구조가 장애 대응 능력이 부족하다는 것이 느껴졌다.
또한 사용자와 서비스 규모가 늘어나면서, 장애 상황에서의 빠른 대응이 팀의 우선순위가 되었다.
“무엇이 원인인지“ 더욱 빠르게 파악할수 있는 해결책이 필요하다.
현재 우리의 서버는 아래 로깅을 지원하고 있다
- 서버 예외 sentry 로그
- k8s pod 시스템 성능 지표 (CPU, MEM, Net I/O, …)
- db 시스템 성능 지표 (CPU, MEM, Net I/O, …)
- nginx http 로그
시스템 레벨의 지표는 수집하고 있지만, 애플리케이션 레벨의 관찰 가능성이 부족하여 “어떤 코드에서 발생했는지" 파악할 수 없는 상황이다.
따라서 다음과 같은 요소들이 추가로 필요하다:
Metric
어플리케이션의 상태 트렌드를 파악하기 위해 필요하다.
- API 엔드포인트별 응답시간, 처리량(TPS), 에러율
- 비즈니스 로직별 실행시간 (예: 결제 처리, 데이터 조회 등)
Logging
metric에서 트렌드를 파악하고, 구체적으로 어떤 문제인지 파악하기 위해 필요하다
- nginx http 로그
- 애플리케이션 에러 로그 (stack trace, 예외 상황)
Trace
하나의 요청이 여러 서비스를 거쳐가는 과정을 추적하여, 어느 구간에서 지연이나 문제가 발생했는지 파악하기 위해 필요하다
- 각 API 호출의 상세 실행 과정 로깅
- 마이크로서비스 간 호출 관계와 소요시간
Alert
문제 발생 시 즉시 인지하고 빠른 대응을 위해 필요하다
- 임계값 기반 실시간 알림 (응답시간 >3초, 에러율 >5% 등)
- 일정 시간 내 미응답 시 상위 담당자에게 자동 확대 알림
현재 logging은 loki 기반으로 nginx http 로그를 수집하고 있어 어느정도 갖춰져 있는 상태이다.
우선 어플리케이션 레벨 metric을 수집하는 것에 초점을 맞춰보자