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