분산 애플리케이션 성능 튜닝
이 시리즈에서는 개발 팀이 부하 테스트 및 메트릭을 사용하여 성능 문제를 진단하는 방법을 보여 주는 여러 클라우드 애플리케이션 시나리오를 살펴봅니다. 이러한 문서는 예제 애플리케이션을 개발할 때 수행한 실제 부하 테스트를 기반으로 합니다. 각 시나리오에 대한 코드는 GitHub에서 사용할 수 있습니다.
시나리오:
성능이란?
성능은 처리량, 응답 시간 및 가용성 측면에서 자주 측정됩니다. 성능 목표는 비즈니스 운영을 기반으로 해야 합니다. 고객 관련 작업에는 보고서 생성과 같은 운영 작업보다 더 엄격한 요구 사항이 있을 수 있습니다.
각 워크로드에 대한 성능 목표를 정의하는 SLO(서비스 수준 목표)를 정의합니다. 일반적으로 다음과 같은 KPI(핵심 성과 지표) 집합으로 성능 목표를 세분화하여 이 목표를 달성합니다.
- 특정 요청의 대기 시간 또는 응답 시간
- 초당 수행된 요청 수
- 시스템에서 예외를 생성하는 속도입니다.
성능 대상에는 대상 부하가 명시적으로 포함되어야 합니다. 또한 시스템에 동시에 액세스하고 동일한 작업을 수행하는 경우에도 모든 사용자가 정확히 동일한 수준의 성능을 받는 것은 아닙니다. 따라서 SLO는 백분위수 측면에서 프레임되어야 합니다.
SLO의 예는 다음과 같습니다. "클라이언트 요청은 500ms @ P90 내에서 최대 25K 요청/초의 로드에 응답합니다."
분산 시스템 성능 튜닝의 과제
분산 애플리케이션에서 성능 문제를 진단하는 것은 특히 어려울 수 있습니다. 몇 가지 과제는 다음과 같습니다.
단일 비즈니스 트랜잭션 또는 작업에는 일반적으로 시스템의 여러 구성 요소가 포함됩니다. 단일 작업의 전체적인 엔드 투 엔드 뷰를 가져오는 것은 어려울 수 있습니다.
리소스 사용량은 여러 노드에 분산됩니다. 일관된 보기를 얻으려면 로그와 메트릭을 한 곳에서 집계해야 합니다.
클라우드는 탄력적 규모를 제공합니다. 자동 크기 조정은 급증하는 부하를 처리하는 데 중요한 기술이지만 기본적인 이슈를 마스킹할 수도 있습니다. 또한 크기를 조정해야 하는 구성 요소와 시기를 알기 어려울 수 있습니다.
워크로드는 코어 또는 스레드 간에 확장되지 않는 경우가 많습니다. 워크로드의 요구 사항을 이해하고 더 나은 최적화된 크기를 살펴보는 것이 중요합니다. 일부 크기는 단일 코어 지향 및 코어 라이선스 워크로드당 향상을 위해 제한된 코어 및 비활성화된 하이퍼스레딩을 제공합니다.
연속 실패로 인해 근본 문제의 업스트림 오류가 발생할 수 있습니다. 결과적으로 문제의 첫 번째 신호는 근본 원인과 다른 구성 요소에 나타날 수 있습니다.
일반적인 모범 사례
성능 조정은 예술과 과학 모두이지만 체계적인 접근 방식을 취하여 과학에 더 가깝게 만들 수 있습니다. 다음은 몇 가지 모범 사례입니다.
원격 분석을 사용하도록 설정하여 메트릭을 수집합니다. 코드를 계측합니다. 모니터링에 대한 모범 사례를 따릅니다. 트랜잭션의 모든 단계를 볼 수 있도록 상관 관계 추적을 사용합니다.
평균뿐만 아니라 90/95/99 백분위수 모니터링 평균은 이상 값을 마스킹할 수 있습니다. 메트릭에 대한 샘플링 속도도 중요합니다. 샘플링 속도가 너무 낮으면 문제를 나타낼 수 있는 급증 또는 이상값을 숨길 수 있습니다.
한 번에 하나의 병목 상태를 공격합니다. 가설을 작성하고 한 번에 하나의 변수를 변경하여 테스트합니다. 한 병목 상태를 제거하면 업스트림 또는 다운스트림에서 또 다른 병목 현상이 발생하는 경우가 많습니다.
오류 및 재시도는 성능에 큰 영향을 줄 수 있습니다. 백 엔드 서비스가 시스템을 제한하고 있는 경우 데이터베이스 쿼리를 튜닝하는 등 사용량을 확장하거나 최적화하려고 합니다.
일반적인 성능 안티패턴을 찾습니다.
병렬화할 기회를 찾습니다. 병목 상태의 일반적인 두 가지 원인으로는 메시지 큐와 데이터베이스가 있습니다. 두 경우 모두 분할이 도움이 될 수 있습니다. 자세한 내용은 가로, 세로 및 기능 데이터 분할을 참조 하세요. 불균형 읽기 또는 쓰기 부하를 나타낼 수 있는 핫 파티션을 찾습니다.
다음 단계
성능 튜닝 시나리오 읽기