[0607] 성능 테스트 - 병목 찾기

학습 목표

• 시스템의 가용성과 확장성을 평가할 수 있다.
• 부하 테스트의 목적을 이해할 수 있다.
• Throughput과 Latency의 개념을 이해할 수 있다.
• 시스템의 병목이 발생하는 주요 원인과 대책을 이해할 수 있다.
• SLO를 설정하고, 이를 기반으로 부하 테스트를 진행하고, 달성 여부를 파악할 수 있다.

---

병목 구간의 확인과 개선 기본 지식

---

• Throughput 개선
  • 병목 구간을 파악하는 것이 가장 중요함
• Latency 개선
  • 애플리케이션 개선
    • 개발된 애플리케이션을 개선하는 것으로 시작
    • 애플리케이션 성능 최적화는 현상을 파악(APM, Application Performance Monitoring)하는 것으로 시작하며, 알고리즘 개선, I/O 최소화 등의 개선 방안이 뒤따름
    • DevOps가 이를 모니터링할 수는 있으나, 결국 개발자가 APM 도구와 프로파일러 등을 이용해 이를 개선해야 함
  • (애플리케이션 성능 향상을 위한) 하위 시스템의 확장
    • Throughput의 개선이 Latency의 개선으로 이어지는 경우, “대기 시간”에 문제가 있다는 의미
    • 애플리케이션이 실행 환경(하위 시스템)의 성능을 최대한 활용할 수 있다면, 하위 시스템의 확장에 따라 Throughput도 개선되며 대기 시간도 줄어듦
    • 많은 경우 Throughput이 개선되면 Latency도 개선됨

---

응답 성능의 병목 원인과 대책

---

• 일반적인 문제 시나리오와 솔루션
  • 많은 사용자의 서비스 등록
    • DB에 데이터가 증가하므로 secondary 복제본 등을 이용해 읽기/쓰기를 분리하거나 검색에 최적화된 인덱스 사용을 고려
  • 많은 데이터의 저장
    • DB에 데이터가 증가하므로 secondary 복제본 등을 이용해 읽기/쓰기를 분리하거나 검색에 최적화된 인덱스 사용을 고려
  • 단기간 동안의 사용자 요청 증가(peak traffic)
    • Auto Scaling이 해결책이 될 수 있으며, 버스트 성능에 대해 이해해야 함
  • 배치 작업을 진행하는 데이터베이스
    • DB가 주기적으로 스냅샷을 만들거나 데이터 일관성을 위해 레플리카와 sync 과정을 진행하는 등의 배치 작업이 이루어질 경우, primary DB는 성능 저하가 발생할 수 있음
    • 사용자들의 요청과 맞물려 서비스 수준을 맞추기 어려울 수 있음
  • 많은 양의 로그 수집 처리
    • 애플리케이션이 잘 작동할 때에는 로그를 많이 남기지 않지만, 애플리케이션에 문제가 발생하면 추적을 위해 많은 로그를 남김
    • 이러한 상황이 반복적으로 진행될 경우, 에러 로그 수집 그 자체가 애플리케이션 병목을 일으킬 수 있음
  • 시스템 재시작 후의 캐시 초기화
    • 캐시가 초기화되면서 시스템으로 직접적인 요청 횟수가 증가할 수 있음
• 주요 병목 구간과 부하 테스트 시 고려해야 할 부분