Aurora PostgreSQL 쿼리 계획 관리에 대한 모범 사례 - Amazon Aurora
성능 역행 문제를 방지하기 위한 사전 대비형 계획 관리 성능 역행을 찾아내어 복구하기 위한 사후 대응형 계획 관리

Aurora PostgreSQL 쿼리 계획 관리에 대한 모범 사례

쿼리 계획 관리를 사용하면 쿼리 실행 계획을 변경하는 방식과 변경해야 하는 경우를 제어할 수 있습니다. DBA로서 QPM을 사용할 때의 주요 목표는 데이터베이스에 변경 사항이 있을 때 역행을 방지하고, 옵티마이저의 새 계획 사용 여부를 제어하는 것입니다. 아래에서 쿼리 계획 관리를 사용하는 데 권장되는 모범 사례를 확인할 수 있습니다. 사전 대비형 계획 관리와 사후 대응형 계획 관리는 새 계획의 사용이 승인되는 방식과 시점이 다릅니다.

성능 역행 문제를 방지하기 위한 사전 대비형 계획 관리

계획 성능 회귀가 발생하지 않게 하려면, 새로 검색된 계획의 성능을 승인된 계획의 기존 기준 성능과 비교한 다음 가장 빠른 계획 세트를 새 기준으로 자동 승인하는 프로시저를 실행하여 계획 베이스라인을 개선해야 합니다. 이렇게 하면 시간이 지남에 따라 더 빠른 계획이 검색되어 계획 기준이 개선됩니다.

  1. 개발 환경에서 성능 또는 시스템 처리량에 가장 큰 영향을 미치는 SQL 문을 식별합니다. 그런 다음 특정 SQL 문에 대해 계획을 수동으로 캡처 및 계획 자동 캡처에 설명된 대로 이러한 설명문에 대해 계획을 캡처합니다.

  2. 개발 환경에서 캡처한 계획을 내보내고 프로덕션 환경으로 가져옵니다. 자세한 내용은 계획 내보내기/가져오기 섹션을 참조하세요.

  3. 프로덕션 단계에서 애플리케이션을 실행하고 승인된 관리형 계획 사용을 적용합니다. 자세한 내용은 Aurora PostgreSQL 관리형 계획 사용 섹션을 참조하세요. 애플리케이션이 실행되는 동안 최적화 프로그램에서 검색되는 새 계획도 추가합니다. 자세한 내용은 계획 자동 캡처 섹션을 참조하세요.

  4. 미승인 계획을 분석하고 잘 수행되는 계획을 승인됩니다. 자세한 내용은 계획 성능 평가 섹션을 참조하세요.

  5. 애플리케이션이 계속 실행되는 동안 최적화 프로그램은 해당되는 경우 새 계획을 사용하기 시작합니다.

메이저 버전 업그레이드 후 계획 안정성 보장

PostgreSQL의 각 메이저 버전에는 성능 개선을 위해 설계된 쿼리 옵티마이저의 개선 사항 및 변경 사항이 포함되어 있습니다. 하지만 이전 버전에서 옵티마이저가 생성한 쿼리 실행 계획은 새로 업그레이드된 버전에서 성능 회귀를 일으킬 수 있습니다. 쿼리 계획 관리를 사용하여 이 성능 문제를 해결하고 메이저 버전 업그레이드 후 계획 안정성을 보장할 수 있습니다.

최적화 프로그램은 동일한 문에 대해 승인된 계획이 두 개 이상인 경우에도 항상 최소 비용의 승인된 계획을 사용합니다. 업그레이드 후 최적화 프로그램이 새 계획을 발견할 수 있지만 이러한 계획은 승인되지 않은 계획으로 저장됩니다. 이러한 계획은 unapproved_plan_execution_threshold 파라미터와 함께 반응형 계획 관리 스타일을 사용하여 승인된 경우에만 수행됩니다. evolve_plan_baselines 파라미터와 함께 선제적 스타일의 계획 관리를 사용하면 계획 안정성을 극대화할 수 있습니다. 이는 새 계획의 성과를 기존 계획과 비교하여 차선책보다 10% 이상 빠른 계획을 승인하거나 거부합니다.

업그레이드 후 evolve_plan_baselines 함수를 사용하여 쿼리 매개 변수 바인딩을 사용한 업그레이드 전후의 계획 성능을 비교할 수 있습니다. 다음 단계에서는 Aurora PostgreSQL 관리형 계획 사용에 설명된 대로 프로덕션 환경에서 승인된 관리형 계획을 사용하고 있다고 가정합니다.

  1. 업그레이드하기 전에 쿼리 계획 관리자가 실행 중인 상태에서 애플리케이션을 실행합니다. 애플리케이션이 실행되는 동안 옵티마이저에서 검색되는 새 계획을 추가합니다. 자세한 내용은 계획 자동 캡처 섹션을 참조하세요.

  2. 각 계획의 성능을 평가합니다. 자세한 내용은 계획 성능 평가 섹션을 참조하세요.

  3. 업그레이드 후 evolve_plan_baselines 함수를 사용하여 승인된 계획을 다시 분석합니다. 쿼리 매개 변수 바인딩을 사용하기 전후의 성능을 비교합니다. 새 플랜이 빠른 경우 승인된 계획에 추가하면 됩니다. 동일한 매개 변수 바인딩에 대한 다른 계획보다 빠르면 느린 계획을 거부됨(Rejected)으로 표시할 수 있습니다.

    자세한 내용은 더 나은 계획 승인 섹션을 참조하세요. 이 함수에 대한 자세한 내용은 apg_plan_mgmt.evolve_plan_baselines 단원을 참조하세요.

자세한 내용은 메이저 버전 업그레이드 후 Amazon Aurora PostgreSQL 호환 버전 쿼리 계획 관리를 통해 일관된 성능 보장을 참조하세요.

참고

논리적 복제 또는 AWS DMS를 사용하여 메이저 버전 업그레이드를 수행하는 경우 기존 계획이 업그레이드된 인스턴스에 복사되도록 apg_plan_mgmt 스키마를 복제해야 합니다. 논리적 복제에 대한 자세한 내용은 논리적 복제를 사용하여 Aurora PostgreSQL에 대한 메이저 버전 업그레이드 수행 섹션을 참조하세요.

성능 역행을 찾아내어 복구하기 위한 사후 대응형 계획 관리

애플리케이션이 실행될 때 애플리케이션을 모니터링하여 성능 역행을 발생시키는 계획을 찾아냅니다. 역행을 찾아내면 다음 단계를 따라 좋지 않은 계획을 수동으로 거부하거나 수정합니다.

  1. 애플리케이션이 실행되는 동안 관리형 계획의 사용을 적용하고 새로 검색된 계획을 미승인 계획으로 자동 추가합니다. 자세한 내용은 Aurora PostgreSQL 관리형 계획 사용 및 계획 자동 캡처 단원을 참조하십시오.

  2. 실행 중인 애플리케이션에서 성능 역행 문제가 있는지 모니터링합니다.

  3. 계획 역행 문제를 발견하면 계획의 상태를 rejected로 설정합니다. 최적화 프로그램은 다음 번에 SQL 문을 실행할 때 거부된 계획을 자동으로 무시하고 대신에 승인된 다른 계획을 사용합니다. 자세한 내용은 느린 계획 거부 또는 비활성화 섹션을 참조하세요.

    경우에 따라 좋지 않은 계획을 거부, 비활성화 또는 삭제하기 보다는 수정하는 것이 더 나을 수도 있습니다. pg_hint_plan 확장을 사용하여 계획 개선을 실습해 봅니다. pg_hint_plan을 통해 특별 설명을 사용하여 계획의 정상 생성 방식을 재정의하도록 최적화 프로그램에 지정합니다. 자세한 내용은 pg_hint_plan을 사용하여 계획 수정 섹션을 참조하세요.