병목 상태 조사 방법
이 항목에서는 병목 상태를 조사하는 방법으로 권장되는 프로세스에 대해 설명합니다.
문제 원인
문제 원인은 관련된 하드웨어 또는 소프트웨어가 될 수 있습니다. 리소스가 충분히 활용되고 있지 않으면 이는 일반적으로 시스템의 어딘가에 병목 상태가 있음을 나타내는 것입니다. 병목 상태는 하드웨어 제한이나 비효율적인 소프트웨어 구성 또는 둘 다로 인해 발생할 수 있습니다.
병목 상태 확인은 하나의 병목 상태를 해소하면 다음 병목 상태를 발견할 수 있는 증분 프로세스입니다. 이러한 병목 상태를 확인하고 해소하는 것이 이 항목의 목적으로 단기간에 시스템이 최대 속도로 작업을 수행할 수 있도록 합니다. 그러나 유지 가능한 처리량의 경우 시스템의 처리 속도는 해당 구성 요소 중 성능이 가장 느린 구성 요소와 같습니다.
직렬 방법 사용
병목 상태는 시스템의 엔드포인트(진입/종료)나 그 사이에서(오케스트레이션/데이터베이스) 발생할 수 있습니다. 병목 상태의 위치가 격리된 후 구조화된 방법으로 문제 원인을 식별할 수 있습니다. 병목 상태가 해소된 후 다시 성능을 측정하여 시스템 하부에서 새 병목 상태가 발생하지 않는지 확인하는 것이 중요합니다.
병목 상태를 확인하고 해결하는 프로세스는 직렬 방식으로 수행해야 합니다. 즉, 한 번에 하나의 매개 변수만 변경한 다음 성능을 측정하여 해당 변경 결과를 확인해야 합니다. 한 번에 여러 매개 변수를 변경하면 변경 결과가 확인되지 않을 수 있습니다.
예를 들어 매개 변수 1을 변경하면 성능이 향상될 수 있는데 매개 변수 1 변경과 함께 매개 변수 2를 변경하면 매개 변수 1 변경의 이점이 상실되어 최종 결과에 아무런 영향이 없을 수 있습니다. 그러나 이로 인해 매개 변수 1 변경 결과에 대해 잘못된 부정이 발생하고 매개 변수 2 변경 결과에 대해 잘못된 긍정이 발생할 수 있습니다.
일관성 테스트
설정을 변경한 후 성능 특징을 측정하는 것은 변경 결과의 유효성 검사에 중요합니다.
하드웨어: 하드웨어가 일관되지 않은 동작을 표시하여 오해의 소지가 있는 결과를 생성할 수 있으므로 일관된 하드웨어를 사용하는 것이 중요합니다. 예를 들어 랩톱을 사용하지 마세요.
테스트 실행 기간: 고정된 최소 기간에 대한 성능을 측정하여 결과가 단순히 최고점이 아닌 지속 가능한지 확인하는 것도 중요합니다. 장기간 테스트를 실행하는 또 다른 이유는 시스템이 모든 캐시가 채워지는 초기 준비 기간을 마치고, 데이터베이스 테이블이 필요한 수에 도달하고, 미리 정의된 임계값에 도달한 경우 조정이 시작되어 처리량을 제어할 충분한 시간을 제공하기 위해서입니다. 이 방법은 유지 가능한 최적 처리량을 찾는 데 도움이 됩니다.
테스트 매개 변수: 테스트 실행에서 테스트 실행까지 테스트 매개 변수를 변경하지 않는 것도 중요합니다. 예를 들어 맵 복잡성 및/또는 문서 크기를 변경하면 처리량과 대기 시간 결과가 다르게 생성될 수 있습니다.
정리 상태: 테스트가 완료되면 다음 테스트 실행을 실행하기 전에 모든 상태를 정리하는 것이 중요합니다. 예를 들어 기록 데이터가 데이터베이스에 누적되어 런타임 처리량에 영향을 줄 수 있습니다. 서비스 인스턴스를 재생하면 메모리, 데이터베이스 연결, 스레드 등의 캐시된 리소스를 해제하는 데 도움이 됩니다.
예상: 처리량 및 대기 시간
배포된 시스템에서 특정 처리량 및/또는 대기 시간을 예상할 수 있습니다. 높은 처리량과 낮은 대기 시간을 모두 얻는 것은 불가능합니다. 그러나 적절한 대기 시간의 최적 처리량을 예상하는 것은 가능합니다. 처리량이 향상되면 CPU 사용 증가, 디스크 IO 충돌 증가, 사용 가능한 메모리 감소, 잠금 충돌 증가 등 시스템의 스트레스가 증가하여 대기 시간이 늘어날 수 있습니다. 시스템의 최적 용량을 찾으려면 모든 병목 상태를 확인하고 해소하는 것이 중요합니다.
병목 현상은 정리되지 않은 데이터베이스에 있는 레거시 데이터(완료된 인스턴스)로 인해 발생할 수 있습니다. 이 경우 성능이 저하 될 수 있습니다. 이는 시스템에 이러한 데이터를 정리할 충분한 시간을 주면 문제가 완화될 수 있습니다. 그러나 백로그 누적의 원인을 찾고 문제를 완화시키는 것이 중요합니다.
백로그의 원인을 찾으려면 기록 데이터를 분석하고 성능 모니터 카운터를 모니터링하여 사용 패턴을 찾고 백로그의 소스를 진단하는 것이 중요합니다. 대량의 데이터가 야간에 일괄 처리 방식으로 처리되는 경우가 일반적인 현상입니다. 시스템 용량 및 백로그에서 복구할 방법을 찾아 시나리오 처리를 가속화하기 위한 하드웨어 요구 사항과 예측할 수 없는 처리량 급증을 처리하기 위한 시스템 내의 버퍼 공간 크기를 예상할 수 있습니다.
유지 가능한 최적 처리량을 위해 시스템을 조정하려면 배포되는 응용 프로그램, 시스템의 장단점 및 특정 시나리오의 사용 패턴을 잘 알아야 합니다. 병목 상태를 찾고 유지 가능한 최적 처리량을 명확하게 예측하는 유일한 방법은 프로덕션에서 사용할 토폴로지와 거의 일치하는 토폴로지에 대한 철저한 테스트뿐입니다.
이 섹션의 다른 항목에서는 해당 토폴로지를 정의하는 프로세스에 대해 설명하며, 병목 상태를 완화시키고 무엇보다 병목 상태가 발생하지 않도록 하는 방법에 대한 지침을 제공합니다.
크기 조정
병목 상태는 배포된 토폴로지의 여러 단계에서 발생할 수 있습니다. 일부 병목 상태는 하드웨어를 업그레이드하여 해결할 수 있습니다. 하드웨어는 업그레이드(CPU, 메모리 또는 캐시 추가) 또는 확장(서버 추가)에 의해 업그레이드할 수 있습니다. 업그레이드/확장 결정은 발생한 병목 상태의 유형과 구성 중인 응용 프로그램에 따라 달라집니다. 다음은 발생한 병목 상태에 따라 하드웨어 배포 토폴로지를 변경하는 방법에 대해 설명합니다. 스케일 업/아웃을 활용할 수 있도록 처음부터 애플리케이션을 빌드해야 합니다. 예를 들어:
응용 프로그램이 serialize되어 있고 하나의 실행 스레드에 종속된 경우 CPU 및/또는 메모리를 추가하여 서버를 업그레이드해도 문제가 완화되지 않을 수 있습니다.
추가 서버가 확장할 수 없는 공용 리소스에 대한 경쟁만 더하는 경우 서버를 추가하여 시스템을 확장해도 도움이 되지 않을 수 있습니다. 그러나 확장하면 다른 이점이 있습니다. 네 개의 프로세서가 장착된 서버 한 대를 배포하는 대신 두 개의 프로세서가 장착된 서버 두 대를 배포하면 추가 처리량을 처리할 이중 확장과 고가용성 토폴로지를 제공하는 중복 서버를 얻을 수 있습니다.