성능을 벤치마킹할 때는 테스트를 시작하기 전에 테스트를 통해 무엇을 알 수 있을지 정의하세요. 예를 들면 다음과 같습니다.
- 시스템이 달성할 수 있는 최대 처리량은 얼마인가요?
- 특정 쿼리 또는 워크로드에 얼마나 걸리나요?
- 데이터 양이 증가함에 따라 성능은 어떻게 변하나요?
- 두 시스템의 성능을 어떻게 비교하나요?
- 열 형식 엔진은 쿼리 성능의 응답 시간을 얼마나 단축하나요?
- 더 강력한 머신으로 업그레이드하기 전에 데이터베이스에서 처리할 수 있는 부하량은 얼마나 되나요?
성능 연구의 목표를 이해하면 실행할 벤치마크, 필요한 환경, 수집해야 하는 측정항목을 알 수 있습니다.
반복 가능성
성능 테스트에서 결론을 도출하려면 테스트 결과를 반복할 수 있어야 합니다. 테스트 결과의 변동이 크면 애플리케이션이나 시스템 구성에서 변경한 사항의 영향을 평가하기가 어렵습니다. 더 많은 데이터를 제공하기 위해 테스트를 여러 번 실행하거나 더 오랜 기간 실행하면 변동량을 줄일 수 있습니다.
성능 테스트는 다른 시스템과 격리된 시스템에서 실행하는 것이 좋습니다. 외부 시스템이 애플리케이션의 성능에 영향을 줄 수 있는 환경에서 실행하면 잘못된 결론을 도출할 수 있습니다. 멀티 테넌트 클라우드 환경에서 실행할 때는 완전한 격리가 불가능한 경우가 많으므로 결과의 변동성이 더 클 수 있습니다.
반복 가능성의 일부는 실행 간에 테스트 워크로드가 동일하게 유지되도록 하는 것입니다. 무작위성이 애플리케이션 동작에 큰 차이를 일으키지 않는 한 테스트 입력의 무작위성은 허용됩니다. 무작위로 생성된 클라이언트 입력이 실행마다 읽기 및 쓰기의 혼합을 변경하면 성능이 크게 달라집니다.
데이터베이스 크기, 캐싱, I/O 패턴
테스트하는 데이터 양이 애플리케이션을 대표하는지 확인합니다. 수백 기가바이트 또는 테라바이트의 데이터가 있는데 소량의 데이터로 테스트를 실행하면 애플리케이션의 성능을 제대로 나타내지 못할 수 있습니다. 데이터 세트의 크기도 쿼리 최적화 도구의 선택에 영향을 줍니다. 소규모 테스트 테이블에 대한 쿼리는 대규모에서 성능이 저하되는 테이블 검색을 사용할 수 있으며 이 구성에서는 누락된 색인을 식별할 수 없습니다.
애플리케이션의 I/O 패턴을 복제하도록 노력하세요. 읽기와 쓰기의 비율은 애플리케이션의 성능 프로필에 중요합니다.
벤치마크 기간
복잡한 시스템에서는 시스템이 실행될 때 유지되는 상태 정보가 많습니다. 데이터베이스 연결이 설정되고, 캐시가 채워지고, 프로세스와 스레드가 생성됩니다. 성능 테스트를 시작할 때 이러한 구성요소의 초기화가 시스템 리소스를 차지하고 워크로드의 런타임이 너무 짧으면 측정된 성능에 부정적인 영향을 미칠 수 있습니다.
시스템 워밍업의 영향을 최소화하기 위해 성능 테스트를 20분 이상 실행하는 것이 좋습니다. 시작 후 안정적인 상태에서 데이터베이스 작업의 모든 측면이 포함되도록 충분히 긴 시간 동안 성능을 측정합니다. 예를 들어 데이터베이스 체크포인트는 데이터베이스 시스템의 중요한 기능이며 성능에 상당한 영향을 미칠 수 있습니다. 체크포인트 간격 전에 완료되는 짧은 벤치마크를 실행하면 애플리케이션 동작의 중요한 요소가 숨겨집니다.
체계적인 테스트
성능을 조정할 때는 한 번에 하나의 변수만 변경하세요. 실행 간에 여러 변수를 변경하면 어떤 변수로 인해 실적이 개선되었는지 파악할 수 없습니다. 실제로 여러 변경사항이 서로 상쇄되어 적절한 변경사항의 이점을 확인할 수 없습니다. 데이터베이스 서버가 과도하게 사용되는 경우 부하를 일정하게 유지하면서 vCPU가 더 많은 머신으로 전환해 보세요. 데이터베이스 서버가 충분히 활용되지 않는 경우 CPU 구성을 일정하게 유지하면서 부하를 늘려 보세요.
네트워크 토폴로지 및 지연 시간
시스템의 네트워크 토폴로지는 성능 테스트 결과에 영향을 줄 수 있습니다. 영역 간 지연 시간은 다릅니다. 성능 테스트를 실행할 때 클라이언트와 데이터베이스 클러스터가 동일한 영역에 있는지 확인하면 네트워크 지연 시간이 최소화되고 최상의 성능이 제공됩니다. 특히 네트워크 지연 시간이 전체 트랜잭션 응답 시간의 큰 구성요소가 될 수 있는 높은 처리량의 짧은 트랜잭션이 있는 애플리케이션의 경우 더욱 그렇습니다.
두 시스템의 성능을 비교할 때는 두 시스템의 네트워크 토폴로지가 동일해야 합니다. 네트워크 지연 시간 변동성은 완전히 제거할 수 없습니다. 동일한 영역 내에서도 기본 네트워크 토폴로지로 인해 지연 시간이 다를 수 있습니다.
애플리케이션을 배포할 때 일반적인 대량 웹 애플리케이션을 고려하여 교차 영역 지연 시간의 영향을 더 잘 이해할 수 있습니다. 애플리케이션에는 고가용성을 위해 여러 영역에 배포된 여러 웹 서버에 요청을 전송하는 부하 분산기가 있습니다. 크로스존 지연 시간 차이로 인해 요청을 처리하는 웹 서버에 따라 지연 시간이 다를 수 있습니다.
다음 그림은 AlloyDB Omni를 사용하는 웹 애플리케이션의 일반적인 아키텍처를 보여줍니다. 클라이언트 요청은 부하 분산기에 의해 처리되며, 부하 분산기는 각 요청을 여러 웹 서버 중 하나로 전달합니다. 웹 서버는 모두 AlloyDB Omni에 연결되어 있습니다. 일부 서버는 AlloyDB Omni가 실행되는 영역과 다른 영역에 있으며 데이터베이스 요청 시 지연 시간이 더 길어집니다.
리소스 모니터링
데이터베이스 시스템의 성능을 최적화하려면 데이터베이스 시스템과 데이터베이스 시스템을 사용하는 클라이언트 시스템의 리소스 사용량을 모니터링해야 합니다. 두 시스템을 모두 모니터링하면 클라이언트 시스템이 데이터베이스 시스템에서 의미 있는 측정값을 얻을 수 있을 만큼 충분한 워크로드를 제공하는지 확인할 수 있습니다. 테스트 중인 시스템의 리소스 사용량을 모니터링하는 것이 중요합니다. 워크로드를 실행하는 데 사용하는 클라이언트 시스템의 리소스 사용률을 모니터링하는 것도 마찬가지로 중요합니다. 예를 들어 데이터베이스 시스템이 CPU 리소스가 부족해지기 전에 지원할 수 있는 최대 클라이언트 수를 확인하려면 데이터베이스 시스템의 모든 CPU 리소스를 사용하는 데 필요한 워크로드를 생성할 수 있는 충분한 클라이언트 시스템이 필요합니다. 부하를 생성하는 클라이언트 머신에 CPU가 충분하지 않으면 데이터베이스 시스템을 충분히 구동할 수 없습니다.
확장성 테스트
확장성 테스트는 성능 테스트의 또 다른 측면입니다. 확장성은 워크로드의 한 특성이 변함에 따라 성능 측정항목이 어떻게 변하는지를 나타냅니다. 확장성 연구의 예는 다음과 같습니다.
- 동시 요청 수가 증가하면 처리량과 응답 시간이 어떻게 달라지나요?
- 데이터베이스 크기가 증가하면 처리량과 응답 시간이 어떻게 달라지나요?
확장성 테스트는 워크로드를 여러 번 실행하여 구성되며, 실행 간에 단일 차원이 변경되고 하나 이상의 측정항목이 수집되어 표시됩니다. 이러한 유형의 테스트는 시스템에 어떤 병목 현상이 있는지, 특정 구성에서 시스템이 처리할 수 있는 부하, 시스템이 지원할 수 있는 최대 부하, 부하가 이러한 수준을 초과할 때 시스템의 동작에 관한 결정을 내리는 데 도움이 됩니다.
머신 크기 고려사항
AlloyDB Omni는 데이터베이스의 안정성과 가용성을 개선하기 위해 Postgres에 많은 새로운 기능을 도입합니다. 이를 위해 필요한 모니터링은 AlloyDB Omni를 실행하는 머신의 리소스를 사용합니다. 매우 작은 머신 크기에는 처음부터 메모리 및 CPU 리소스가 제한되어 있으므로 벤치마킹에는 최소 4개의 vCPU가 있는 머신 크기를 사용하는 것이 좋습니다.