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