このページは Cloud Translation API によって翻訳されました。

AlloyDB のパフォーマンスと可用性を向上させるためのベストプラクティス

このページでは、AlloyDB for PostgreSQL のパフォーマンス、耐久性、可用性を向上させるための一般的なベストプラクティスについて説明します。このページは、AlloyDB と PostgreSQL に精通しているデータベース管理者とデベロッパーを対象としています。

インスタンスの構成と管理

ベストプラクティス:
AlloyDB ツールを使用してデータベースの使用状況とステータスをモニタリングする。
運用ガイドラインに従う。
プライマリインスタンスのメンテナンスの時間枠を構成する。
読み取りプールインスタンスを追加して読み取りトラフィックをオフロードする。
レプリケーションラグを管理する。
前のオペレーションが完了する前に管理オペレーションを開始しないでください。
重要なデータベースのメンテナンスに対応できる十分なストレージ割り当てを構成する。
CPU の過剰使用を防ぐ。
メモリ不足を回避する。
インスタンスに最適なトランザクション ID があることを確認します。

AlloyDB ツールを使用してデータベースの使用状況とステータスをモニタリングする

次の表に、データベースの使用状況、ステータス、パフォーマンスのモニタリングに役立つ AlloyDB ツールを示します。

AlloyDB ツール	説明
パフォーマンススナップショットレポート	2 つの異なる時点のシステム指標のスナップショットを比較します。
Query Insights	AlloyDB データベースのクエリパフォーマンスの問題を検出、診断、防止するのに役立ちます。このツールが提供する、単なる検出機能を超えた、セルフサービス方式の直観的にわかりやすいモニタリングと診断の情報は、パフォーマンスに関する問題の根本原因を特定するのに役立ちます。
システム分析情報	アクティブなノード数、CPU 使用率、ピーク接続数、ログエラー、1 秒あたりのトランザクション数、最大レプリケーションラグなど、データベースのリソースと指標をモニタリングできます。

オペレーションガイドラインに従う

インスタンスが AlloyDB for PostgreSQL SLA の対象となるようにするには、オペレーションガイドラインに従ってください。

プライマリインスタンスのメンテナンスの時間枠を構成する

中断更新が発生するタイミングを計画するため、プライマリインスタンスのメンテナンスの時間枠を構成します。詳細については、メンテナンス時間を表示、設定するをご覧ください。

読み取りプールインスタンスを追加して読み取りトラフィックをオフロードする

読み取り負荷の高いワークロードの場合は、読み取りプールインスタンスを追加して、プライマリインスタンスから読み取りトラフィックをオフロードします。

キャッシュを改善するために、インスタンス内の各データベースに 1 つ以上の読み取りプールを構成します。

自動ロードバランシングと高可用性を実現するために、プールごとにノードを追加することを検討してください。

レプリケーションラグを管理する

AlloyDB では、レプリケーションラグを改善するためにいくつかの機能強化が行われています。ただし、ログの再生がブロックされたり、追いつかなかったりするシナリオが発生し、レプリケーションラグが増加する可能性があります。

たとえば、プライマリ VM のサイズが読み取りプールノードのサイズよりもはるかに大きい場合、書き込みワークロードが重い場合、プライマリ VM は、読み取りノードがログレコードを再生するよりも速くログレコードを生成する可能性があります（特に、読み取りノードで同時に実行されている読み取りワークロードも重い場合）。このシナリオでは、読み取りノードのサイズを増やしてリソースを増やすと効果的です。

アプリケーションのニーズに応じて、次のパラメータを調整することをおすすめします。

max_standby_streaming_delay: リプレイをブロックしているクエリをキャンセルするまでのリプレイの待機時間を決定します。
google_storage.log_replay_throttle_read_transactions: 遅延が高い場合にクエリをスロットリングするかどうかを決定します。クエリの調整により、リプレイに多くのリソースが割り当てられ、より速く追いつき、古いデータをクエリに返さないようにすることができます。
alloydb.promote_cancel_to_terminate: キャンセルに応答しないクエリバックエンドを強制的に終了するかどうかを決定します。

前のオペレーションが完了する前に管理オペレーションを開始しないでください。

AlloyDB インスタンスは、前のオペレーションが完了するまで、新しいオペレーションリクエストを受け付けません。前のオペレーションが完了する前に新しいオペレーションを開始しようとすると、オペレーションリクエストは失敗します。これには、インスタンスの再起動も含まれます。

Google Cloud コンソールのインスタンスステータスには、オペレーションが実行されているかどうかは反映されません。緑色のチェックマークは、インスタンスが RUNNABLE 状態かどうかのみを示します。オペレーションが実行中かどうかを確認するには、[オペレーション] タブをクリックして、最新のオペレーションのステータスを確認します。

重要なデータベースのメンテナンスに対応できる十分なストレージ割り当てを構成する

デフォルトでは、クラスタごとに最大 16 TB のストレージを使用できます。追加のストレージが必要な場合は、ストレージ割り当ての増加を検討してください。

CPU の過剰使用を防ぐ

使用可能な CPU のうちインスタンスが使用している割合は、 Google Cloud コンソールのインスタンスの詳細ページで確認できます。詳細については、インスタンスをモニタリングするをご覧ください。また、指標しきい値のアラートポリシーを作成するを使用して、CPU 使用率をモニタリングし、指定したしきい値でアラートを受信することもできます。

過剰な使用を回避するために、インスタンスをより多くの CPU にスケールアップできます。CPU 数を変更するには、インスタンスの再起動が必要です。インスタンスがすでに CPU の最大数に達している場合は、データベースを複数のインスタンスにシャーディングすることをおすすめします。

メモリ不足を回避する

AlloyDB には、メモリ不足の問題を防ぐための自動メモリ管理があります。ただし、メモリ不足が続くと、パフォーマンスの問題が発生する可能性があります。メモリ不足の兆候を調べる際は、主に使用量指標を使用してください。最適なパフォーマンスを得るには、この指標を 90% 未満に保つことをおすすめします。

また、total_usage 指標を使用すると、データベースコンテナが使用しているメモリやオペレーティングシステムのキャッシュが割り当てたメモリなどを含め、AlloyDB インスタンスで使用されている使用可能なメモリの割合を確認できます。

使用量と合計使用量の指標の差を観察することで、プロセスによって使用されているメモリの量と、オペレーティングシステムのキャッシュで使用されているメモリの量を把握できます。このキャッシュ内のメモリは再利用できます。

AlloyDB インスタンスをスケーリングしてメモリのサイズを増やします。インスタンスのメモリサイズを変更するには、インスタンスを再起動する必要があります。インスタンスがすでに最大メモリサイズに達している場合は、データベースを複数のインスタンス間でシャーディングする必要があります。

Google Cloud コンソールでの使用量と合計使用量の指標のモニタリングの詳細については、インスタンスをモニタリングするをご覧ください。

インスタンスに最適なトランザクション ID があることを確認してください

Resource Type を AlloyDB for PostgreSQL Database に、Metric を Percentage of instance's transaction IDs consumed に設定すると、 Google Cloud コンソールの Metrics Explorer ページで、インスタンスのトランザクション ID の使用状況を確認できます。詳細については、Metrics Explorer でグラフを作成するをご覧ください。

AlloyDB には、バキューム関連の問題を軽減する適応型自動バキュームが組み込まれています。

データアーキテクチャ

ベストプラクティス:
大規模なインスタンスを、可能な限り小規模なインスタンスに分割します。
データベーステーブルが多すぎると、パフォーマンスが低下する可能性があります。

大規模なインスタンスを、可能な限り小規模なインスタンスに分割します。

可能であれば、1 つの大きなインスタンスを使用するのではなく、小さな AlloyDB クラスタを多数使用します。大規模なモノリシックインスタンスを管理する場合、小規模なインスタンスグループでは生じない問題に直面します。

データベーステーブルが多すぎる

インスタンスのテーブル数を常に 10,000 個未満にします。データベーステーブルが多すぎると、データベースのアップグレードに時間がかかる可能性があります。

クエリのパフォーマンス

ベストプラクティス:
分析クエリを実行する場合は、カラム型エンジンを有効にします。
インスタンスをスケールアップしてクエリのパフォーマンスを向上させる。
読み取りプールをデプロイし、読み取りクエリを読み取りプールにオフロードする。

分析クエリを実行する場合はカラム型エンジンを有効にする

AlloyDB のカラム型エンジンの概要を確認する。カラム型エンジンを有効にすることでメリットが得られるクエリのタイプを確認します。

カラム型エンジンの使用状況をモニタリングできます。

列エンジンを初めて使用する場合は、まず自動列化について学習してください。その後、列を手動で管理できます。

インスタンスをスケールアップしてクエリのパフォーマンスを向上させる

クエリのパフォーマンスが低い場合は、インスタンスのスケールアップを検討してください。

各 SKU には vCPU とメモリの構成が制限されています。また、各 SKU には高速キャッシュも制限されています。データサイズが大きく、クエリのパフォーマンスが低い場合は、より大きなインスタンスにスケールアップすることを検討してください。

読み取りプールをデプロイし、読み取りクエリを読み取りプールにオフロードする

アプリケーションで大量の書き込みと読み取りを実行している場合は、読み取りプールをデプロイし、読み取りクエリを読み取りプールにオフロードすることを検討してください。

アプリケーションの実装

ベストプラクティス:
適切な接続管理手法を使用する。
メンテナンス更新に対するアプリケーションのレスポンスをテストする。
フェイルオーバーに対するアプリケーションのレスポンスをテストする。
大規模なトランザクションは回避する。
サブトランザクションの数を減らす。
Auth Proxy の最新バージョンを使用する。

適切な接続管理方法を使用する

接続プーリングや指数バックオフなどの適切な接続管理方法を使用します。

適切な接続管理手法を使用すると、アプリケーションのリソース使用が改善され、AlloyDB の接続上限内に収まります。

メンテナンス更新に対するアプリケーションのレスポンスをテストする

メンテナンスの時間枠内でいつでも発生する可能性があるメンテナンス更新に対するアプリケーションのレスポンスをテストします。

メンテナンスアップデートをシミュレートするには、コンピューティングスケールオペレーションを実行するか、低いダウンタイムのメンテナンス（LDTM）をトリガーする静的 PostgreSQL フラグを更新します。

LDTM 中は、インスタンスが一時的に使用できなくなり、既存の接続が切断されます。LDTM をテストすることで、アプリケーションによる定期メンテナンスの処理方法や、システムを迅速に復旧する方法を確認できます。

フェイルオーバーに対するアプリケーションのレスポンスをテストする

いつでも発生する可能性があるフェイルオーバーに対するアプリケーションのレスポンスをテストします。

Google Cloud コンソール、Google Cloud CLI、または API を使用して、手動でフェイルオーバーを開始できます。詳細については、フェイルオーバーの開始をご覧ください。

大規模なトランザクションは回避する

トランザクションのサイズを小さくして、短時間で終わるようにしてください。大規模なデータベース更新が必要な場合は、1 つの大規模なトランザクションを実行するのではなく、複数の小規模なトランザクションで更新を実行します。

サブトランザクションの数を減らす

長時間実行トランザクションがある場合は、トランザクション内のサブトランザクションの数を減らします。

AlloyDB では、PL/pgSQL エラーブロックでトランザクションを実行すると、エラーブロックに対応するトランザクションのサブトランザクションが作成されます。長時間実行トランザクションがある場合にサブトランザクションの数が 64 を超えると、システム全体のパフォーマンスが低下します。

Auth Proxy の最新バージョンを使用する

AlloyDB Auth Proxy を使用している場合は、最新バージョンを使用していることを確認してください。詳細については、Auth Proxy クライアントを最新の状態に保つをご覧ください。

データのインポートとエクスポート

ベストプラクティス:
移行用に Cloud SQL for PostgreSQL のバックアップから復元する。
小規模なインスタンスのインポートを高速化。

移行用に Cloud SQL for PostgreSQL のバックアップから復元する

移行を容易にするには、Cloud SQL for PostgreSQL から AlloyDB に移行するをご覧ください。

継続的なデータレプリケーションを使用して Cloud SQL for PostgreSQL から AlloyDB にデータを移行する方法については、Database Migration Service（PostgreSQL から AlloyDB）をご覧ください。

小規模なインスタンスのインポートを高速化する

小規模なインスタンスに大規模なデータセットをインポートする場合は、インスタンスの CPU と RAM を一時的に増やして、パフォーマンスを向上させることができます。

バックアップとリカバリ

ベストプラクティス:
適切な AlloyDB 機能を使用してデータを保護する。
インスタンスとバックアップを誤って削除しないように保護します。

適切な AlloyDB 機能を使用してデータを保護する

冗長性と保護には、バックアップ、ポイントインタイムリカバリ（PITR）、エクスポートを使用します。それらはそれぞれ異なるシナリオで機能し、堅牢なデータ保護戦略でお互いを補います。

バックアップは軽量で、インスタンスのデータをバックアップ作成時の状態に復元する手段を提供します。ただし、AlloyDB のバックアップ機能にはいくつかの制限があります。インスタンスを削除すると、バックアップも削除されます。単一のデータベースまたはテーブルをバックアップすることはできません。また、インスタンスが配置されているリージョンを使用できない場合、使用可能なリージョンにあるバックアップからそのインスタンスを復元することはできません。

ポイントインタイムリカバリにより、インスタンスを特定のポイントインタイムに復旧できます。たとえば、エラーによってデータが失われた場合、エラーが発生する前の状態にデータベースを復旧できます。ポイントインタイムリカバリは、常に新しいインスタンスを作成します。既存のインスタンスには、ポイントインタイムを実行できません。

データの再作成に使用できる外部ファイルが Cloud Storage に作成されるため、エクスポートは作成するのに時間がかかります。インスタンスを削除しても、エクスポートは影響を受けません。また、エクスポート形式に応じて、単一のデータベースまたはテーブルだけをエクスポートすることもできます。

インスタンスとバックアップを誤って削除しないように保護する

デフォルトの誤削除防止を有効にするには、 Google Cloud コンソールまたは Terraform を使用して AlloyDB インスタンスを作成します。

保護を強化するため、AlloyDB のエクスポート機能を使用してデータをエクスポートします。Cloud Scheduler と Cloud Scheduler API を使用して、エクスポートの管理を自動化します。

より高度なシナリオでは、Cloud Scheduler と Cloud Run functions を使用して自動化します。

AlloyDB のパフォーマンスと可用性を向上させるためのベスト プラクティス