이 항목에서는 병목 상태를 조사하는 방법에 대한 권장 프로세스를 설명합니다.
문제의 원인은 무엇인가요?
문제의 원인은 하드웨어 또는 소프트웨어 관련일 수 있습니다. 리소스가 과소 사용되면 일반적으로 시스템 어딘가에 병목 현상이 있음을 나타냅니다. 하드웨어 제한 또는 비효율적인 소프트웨어 구성 또는 둘 다로 인해 병목 현상이 발생할 수 있습니다.
병목 상태를 식별하는 것은 하나의 병목 상태를 완화하여 다음 병목 상태를 검색할 수 있는 증분 프로세스입니다. 이러한 병목 상태를 식별하고 완화하는 과학은 이 항목의 목표입니다. 시스템이 짧은 기간 동안 최고점에서 수행할 수 있습니다. 그러나 지속 가능한 처리량을 위해 시스템은 가장 느린 성능의 구성 요소만큼 빠르게만 처리할 수 있습니다.
직렬 접근 방식 사용
병목 현상은 시스템의 엔드포인트(진입/종료) 또는 중간(오케스트레이션/데이터베이스) 어딘가에서 발생할 수 있습니다. 병목 현상의 위치가 격리된 후에는 원본을 식별하기 위해 구조화된 접근 방식을 수행할 수 있습니다. 병목 현상이 완화된 후에는 시스템의 다른 곳에서 새로운 병목 현상이 발생하지 않도록 성능을 다시 측정해야 합니다.
병목 상태를 식별하고 수정하는 프로세스는 한 번에 하나의 매개 변수만 변경한 다음, 단일 변경의 영향을 확인하기 위해 성능을 측정해야 하는 직렬 방식으로 수행되어야 합니다. 한 번에 둘 이상의 매개 변수를 변경하면 변경의 영향을 숨길 수 있습니다.
예를 들어 매개 변수 1을 변경하면 성능이 향상될 수 있지만 매개 변수 1 변경과 함께 매개 변수 2를 변경하면 매개 변수 1을 변경하는 이점을 부정하는 데 해로운 영향을 줄 수 있으므로 순 제로 효과가 발생합니다. 그러나 이로 인해 매개 변수 1의 변화에 대한 효과는 거짓 부정으로, 매개 변수 2의 변화에 대한 효과는 거짓 긍정으로 나타납니다.
일관성 테스트
설정을 변경한 후 성능 특성을 측정하는 것은 변경의 효과에 대한 유효성을 검사하는 데 필수적입니다.
하드웨어: 하드웨어가 일관되지 않은 동작을 표시하여 오해의 소지가 있는 결과를 생성할 수 있으므로 일관된 하드웨어를 사용하는 것이 중요합니다. 예를 들어 랩톱을 사용하지 마세요.
테스트 실행 기간: 단순히 최고점이 아닌 지속 가능한 결과를 보장하기 위해 고정된 최소 기간의 성능을 측정하는 것도 중요합니다. 더 오랜 기간 동안 테스트를 실행하는 또 다른 이유는, 시스템이 모든 캐시가 채워지는 초기 예열 및 준비 단계를 거쳤는지, 데이터베이스 테이블이 예상 개수에 도달했는지 확인하고, 미리 정의된 임계값에 도달했을 때 스로틀링이 시작되어 처리량을 적절히 조절할 충분한 시간을 확보하기 위함입니다. 이 방법은 최적의 지속 가능한 처리량을 검색하는 데 도움이 됩니다.
테스트 매개 변수: 테스트 실행부터 테스트 실행까지 테스트 매개 변수를 변경하지 않는 것도 중요합니다. 예를 들어 다양한 맵 복잡성 및/또는 문서 크기는 다른 처리량 및 대기 시간 결과를 생성할 수 있습니다.
정리 상태: 테스트가 완료되면 다음 테스트 실행을 실행하기 전에 모든 상태를 정리해야 합니다. 예를 들어, 기록 데이터가 데이터베이스에 축적되어 런타임 처리 성능에 영향을 미칠 수 있습니다. 서비스 인스턴스를 재활용하면 메모리, 데이터베이스 연결 및 스레드와 같은 캐시된 리소스를 해제하는 데 도움이 됩니다.
예상: 처리량 및 대기 시간
배포된 시스템에서 일정량의 처리량 및/또는 대기 시간을 예상하는 것이 합리적입니다. 높은 처리량과 짧은 대기 시간을 모두 시도하는 것은 서로 다른 두 방향으로 끌어당기는 것과 같습니다. 그러나 적절한 대기 시간으로 최적의 처리량을 기대하는 것이 현실적입니다. 처리량이 증가된 스트레스(CPU 사용량 증가, 디스크-IO 경합 증가, 메모리 압력, 잠금 경합 증가)가 시스템에 배치되어 대기 시간에 부정적인 영향을 미칠 수 있습니다. 시스템의 최적 용량을 검색하려면 모든 병목 상태를 식별하고 완화해야 합니다.
병목 현상은 정리되지 않은 데이터베이스에 있는 레거시 데이터(완료된 인스턴스)로 인해 발생할 수 있습니다. 이 경우 성능이 저하 될 수 있습니다. 시스템에 드레이닝할 충분한 시간을 제공하면 문제를 완화하는 데 도움이 될 수 있습니다. 그러나 업무 적체의 원인을 찾아내고 문제를 완화하는 데 기여하는 것이 중요합니다.
백로그의 원인을 검색하려면 기록 데이터를 분석하고 성능 모니터 카운터를 모니터링하여 사용 패턴을 검색하고 백로그의 원본을 진단하는 것이 중요합니다. 이는 대량의 데이터가 야간에 일괄 처리된 방식으로 처리되는 일반적인 상황입니다. 시스템의 용량과 백로그에서 복구하는 기능을 검색하면 오버드라이브 시나리오를 처리하기 위한 하드웨어 요구 사항과 예기치 않은 처리량 급증을 처리하기 위해 시스템 내에서 수용할 버퍼 공간의 양을 예측하는 데 유용할 수 있습니다.
최적의 지속 가능한 처리량을 위해 시스템을 튜닝하려면 배포되는 애플리케이션, 시스템의 강점 및 약점 및 특정 시나리오의 사용 패턴에 대한 심층적인 이해가 필요합니다. 병목 상태를 검색하고 확실하게 지속 가능한 최적 처리량을 예측하는 유일한 방법은 프로덕션에서 사용되는 것과 밀접하게 일치하는 토폴로지에 대한 철저한 테스트를 통해서입니다.
이 섹션의 다른 항목에서는 해당 토폴로지를 정의하는 과정을 안내하고, 병목 상태를 완화하고 병목 현상을 방지하는 방법에 대한 지침을 제공합니다.
확장
병목 현상은 배포된 토폴로지의 다양한 단계에서 발생할 수 있습니다. 하드웨어를 업그레이드하여 일부 병목 상태를 해결할 수 있습니다. 스케일 업(더 많은 CPU, 메모리 또는 캐시) 또는 스케일 아웃(추가 서버)을 통해 하드웨어를 업그레이드할 수 있습니다. 스케일 업/스케일 아웃 결정은 발생한 병목 상태의 유형과 구성 중인 애플리케이션에 따라 달라집니다. 다음은 발생한 병목 현상에 따라 하드웨어 배포 토폴로지를 변경하는 방법에 대한 지침에 도움이 됩니다. 스케일 업/아웃을 활용할 수 있도록 처음부터 애플리케이션을 빌드해야 합니다. 예를 들어:
추가 CPU 및/또는 메모리를 사용하여 서버를 확장해도 애플리케이션이 직렬화되고 단일 실행 스레드에 종속되는 경우 문제를 완화하는 데 도움이 되지 않을 수 있습니다.
추가 서버가 단순히 확장할 수 없는 공통 리소스에 대한 경합을 추가하는 경우 추가 서버를 사용하여 시스템을 스케일 아웃하는 것은 도움이 되지 않을 수 있습니다. 그러나 스케일 아웃은 추가적인 이점을 제공합니다. 하나의 쿼드 프록시 서버 대신 두 개의 이중 프록시 서버를 배포하면 추가 처리량을 처리하고 고가용성 토폴로지 제공을 위해 크기 조정의 이중 용도를 제공하는 중복 서버를 제공할 수 있습니다.