S.H.

뭔가 뭔가 하고 있음. 아마도

부하 테스트의 기본

업데이트:     Updated:

카테고리:

태그:

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

시스템 성능 지표인 처리량(throughput)과 지연 시간(latency)을 기반으로 개선을 진행하는 경우, 무엇을 먼저 개선해야 할지는 시스템의 특징과 현재의 성능 제한 요소에 따라 달라집니다.

  1. 처리량(Throughput): 처리량은 단위 시간당 시스템이 처리할 수 있는 작업의 양을 나타냅니다. 시스템의 처리량을 늘리려면 일반적으로 하드웨어 리소스를 늘리거나(예: CPU, 메모리, 디스크 공간), 시스템의 병렬 처리 능력을 향상시키는 것이 필요할 수 있습니다. 처리량이 부족한 경우, 시스템이 과부하 상태에 빠질 수 있으므로, 이런 상황에서는 로드 밸런싱, 캐싱, 분산 처리 등의 전략을 사용하여 처리량을 늘릴 수 있습니다.

    • 처리량 개선 사례

      이 웹 서버가 하루에 수백만 명의 사용자로부터 요청을 받아야 하는데, 한 번에 수천 명의 사용자 요청만 처리할 수 있다면, 이는 처리량 문제입니다. 이 경우, 처음에는 사용자의 요청을 더 많이 처리할 수 있도록 하드웨어를 업그레이드하거나, 더 많은 서버를 추가하여 로드 밸런싱을 할 수 있습니다. 이렇게 하면 요청을 더 많이, 더 빠르게 처리할 수 있게 되므로 처리량이 증가합니다.

  2. 지연 시간(Latency): 지연 시간은 시스템이 작업을 완료하는 데 걸리는 시간을 나타냅니다. 지연 시간을 줄이려면, 네트워크 최적화, 효율적인 알고리즘 사용, 소프트웨어 최적화 등이 필요할 수 있습니다. 지연 시간이 긴 경우, 사용자 경험에 부정적인 영향을 미칠 수 있으므로, 이런 상황에서는 데이터베이스 쿼리 최적화, 캐싱 전략, CDN(Content Delivery Network) 사용 등의 방법으로 지연 시간을 줄일 수 있습니다.

    • 애플리케이션 개선

      Latency의 개선은 개발된 애플리케이션을 개선하는 것으로 시작합니다. 애플리케이션 성능 최적화는 현상을 파악(APM, Application Performance Monitoring)하는 것으로 시작하며, 알고리즘 개선, I/O 최소화 등의 개선 방안이 뒤따릅니다. DevOps가 이를 모니터링할 수는 있으나, 결국 개발자가 APM 도구와 프로파일러 등을 이용해 이를 개선해야 합니다.

    • 지연 시간 개선 사례

      다른 한편으로, 사용자가 웹 페이지를 요청하고 페이지가 로드되는 데까지의 시간이 너무 길다면, 이는 지연 시간 문제입니다. 웹 서버가 데이터베이스에서 정보를 가져오는 데 많은 시간이 소요되는 것이 원인일 수 있습니다. 이 경우, 데이터베이스 쿼리를 최적화하거나 캐싱 전략을 사용하여 필요한 정보를 더 빠르게 접근할 수 있게 하는 것이 도움이 될 수 있습니다. 이렇게 하면 사용자 요청에 대한 응답 시간이 단축되므로 지연 시간이 감소합니다.

  3. (애플리케이션 성능 향상을 위한) 하위 시스템의 확장

    보통은 Throughput의 개선이 Latency의 개선으로 이어진 것을 확인할 수 있습니다. 이는 곧 “대기 시간”에 문제가 있다는 의미입니다. 만일 애플리케이션이 실행 환경(하위 시스템)의 성능을 최대한 활용할 수 있다면, 하위 시스템의 확장에 따라 Throughput도 개선되며, 대기 시간도 줄어듭니다. 즉 많은 경우 Throughput이 개선되면 Latency도 개선됩니다.

이러한 두 가지 지표는 종종 상충하는 관계에 있을 수 있습니다. 예를 들어, 처리량을 늘리기 위해 병렬 처리를 늘리면, 이로 인해 지연 시간이 증가할 수 있습니다. 따라서 무엇을 먼저 개선할지 결정하기 위해서는 시스템의 성능 모니터링을 통해 어떤 요소가 가장 큰 병목 현상을 일으키는지 파악하는 것이 중요합니다. 이를 위해 성능 분석 도구를 사용하여 시스템의 다양한 요소를 평가하고, 그 결과를 바탕으로 개선 전략을 세울 수 있습니다.



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

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

서비스를 시작한 후 발생할 수 있는 문제 시나리오는 다양합니다. 이러한 문제는 응답 성능의 병목을 가져다줍니다. 아래 제시된 시나리오는 매우 일반적이며, 부하 테스트를 통해 응답 성능을 예측할 수 있습니다.

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

주요 병목 구간과 부하 테스트 시 고려해야 할 부분

부하 테스트 관련 레퍼런스 : https://aws.amazon.com/ko/blogs/korea/how-to-loading-test-based-on-aws/



Performance Test 카테고리 내 다른 글 보러가기 🤠

댓글남기기