AlloyDB for PostgreSQL の仕組み: 適応型自動バキューム

※この投稿は米国時間 2023 年 9 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud の AlloyDB は、クラウド規模の運用および分析ワークロードを処理するように設計された次世代のマネージド PostgreSQL サービスです。AlloyDB では、自動メモリ管理や適応型自動バキューム機能といったさまざまな自動パイロット機能により、自動更新と自動調整を実行できます。このブログ投稿では、AlloyDB の適応型自動バキューム機能により PostgreSQL VACUUM の課題が軽減され、プロセスが最も効率的な方法で途切れることなく実行される仕組みに焦点を当てています。

PostgreSQL のマルチバージョン同時実行制御（MVCC）では、各行（タプル）のバージョンを複数作成することで、複数のトランザクションが相互にブロックすることなく、同時に実行可能になります。各行のバージョンを複数作成することでこの処理が実現し、各バージョンは異なる時点に対応しています。MVCC では、各トランザクションに一意のトランザクション ID（XID）が割り当てられます。この ID は、トランザクションの実行順序を示します。PostgreSQL の MVCC では 2 つの問題が発生します。

1. トランザクション ID のラップアラウンド: PostgreSQL トランザクション ID（XID）は、各トランザクションに割り当てられている 32 ビットの符号なし整数であり、増分します。最大値に達すると（リング バッファと同様に）ゼロにラップアラウンドされ、これが原因でデータ破損が発生する可能性があります。

2. 肥大化: テーブル、インデックス、システム カタログで古いデータが大量に蓄積すると、肥大化が発生します。時間の経過に伴い、肥大化がクエリ プランナーの精度に影響し、また読み取り操作で読み取る必要があるページ数が増加するため、データベースのパフォーマンスが低下します。

これらの問題に対処するために、PostgreSQL には VACUUM プロセスがあります。このプロセスを手動で呼び出すと、テーブルがスキャンされ、無効なタプルが排除され、テーブル統計情報が更新されます。ユーザーは通常、PostgreSQL で AUTOVACUUM（PostgreSQL の自動バックグラウンド プロセス）を構成します。AUTOVACUUM は、autovacuum_vacuum_cost_limit、autovacuum_vacuum_cost_delay、vacuum_cost_page_hit、vacuum_cost_page_miss、vacuum_cost_page_dirty などのパラメータに基づいて VACUUM プロセスをトリガーします。

ただし、PostgreSQL AUTOVACUUM には次のような課題があります。

• デフォルトの自動バキューム設定ではすべてのワークロードに対して十分に対応できない可能性があります。特定のデータベースや特定のテーブルの最適な設定を判断することが困難な場合があります。

• 負荷の高いシステムでは特に、自動バキューム プロセスが原因で競合が発生する可能性があります。適切に構成または管理されていない自動バキューム プロセスは、パフォーマンスに悪影響をもたらす可能性があります。

• 自動バキュームには固定のリソース バジェット（費用制限、バキューム ワーカー プロセスの数、メモリ）があります。顧客のワークロードと利用可能なリソースに基づいてバキューム ワークロードを自動的に調整することはできません。

• データベースのトランザクション レートが非常に高く、VACUUM プロセスで対応できないほどである場合、これが原因でオープン XID が増加し、最終的には XID のラップアラウンドが発生し、長期のシステム ダウンタイムが発生する可能性があります。

• 処理が遅れている VACUUM はまた、多数のデッドタプルやインデックス エントリによるテーブル スペースの肥大化の原因となる可能性があります。これによりストレージ使用量が不必要に増加し、さらにはバックアップと復元にかかる時間に影響します。これはまた、クエリのパフォーマンスにも影響します。

可用性とパフォーマンスの問題の発生を回避するため、ワークロードに合わせて自動バキューム設定を慎重に調整する必要があります。ただし、ワークロードが常に変化する状況では、バキューム設定の調整が難しいことがあります。

AlloyDB の適応型自動バキューム

AlloyDB for PostgreSQL は、ミッション クリティカルな運用および分析ワークロードを処理するように設計されています。大規模で動的なワークロードでは、自動バキューム設定を手動で調整することは困難です。AlloyDB の適応型自動バキュームは、バキュームの頻度を自動的に調整し、データベースのワークロードに基づいて運用を分析する機能です。これにより、ワークロードが変化する場合でも、バキューム プロセスによる中断なしで、データベースが常にピーク パフォーマンスで運用されるようになります。AlloyDB の適応型自動バキュームの目標は次のとおりです。

• 確実かつ一貫したアプリケーション トランザクション パフォーマンスを実現する

• XID のラップアラウンドの問題を防ぐことでシステムの高可用性を維持する

• 人手が不要なバキューム調整アプローチを実現し、DBA が各ワークロードの設定を手動で調整する必要がないようにする

• ユーザーが更新または調整した自動バキューム設定に従って適応型設定を調整する

AlloyDB の適応型自動バキューム プロセスは、自動バキューム関連の PostgreSQL パラメータ値をリアルタイムでモニタリングし、更新します。たとえば、複数の自動バキューム ワーカーを異なるテーブルに対して同時に実行できますが、この処理は autovacuum_max_workers パラメータにより制御されます。各自動バキューム ワーカーが使用する作業メモリは、maintenance_work_mem パラメータの値によって定義されます。AlloyDB はこれらのパラメータを動的に調整します。

適応型自動バキュームの仕組み

AlloyDB の適応型自動バキュームは、次のようなさまざまな要素に基づいてバキューム実行と分析操作の頻度を決定します。

• データベースのサイズ

• データベース内のデッドタプルの数

• データベース内のデータの経過時間

• 1 秒あたりのトランザクション数と推定バキューム速度（XID スロットリングについては以下の項目 2 を参照）

AlloyDB における適応型自動バキュームによる改善内容と自動的に調整される設定は次のとおりです。

1. 動的バキューム リソース管理: AlloyDB では、固定費用制限の代わりにリアルタイムのリソース統計情報を使用して、バキューム ワーカーが調整されます。システムの負荷が高い場合には、バキューム プロセスとリソースがスロットリングされます。十分なメモリが使用可能な場合には、インデックス バキュームを加速するため、バキューム ワーカーに追加メモリが割り当てられます。

2. 動的 XID スロットリング: AlloyDB は、バキューム処理の進捗状況と XID の消費速度を自動的かつ継続的にモニタリングします。XID ラップアラウンドのリスクが検知されると、AlloyDB は XID 消費のスロットリングを徐々に開始するため、トランザクションの処理速度を下げます。また、バキューム処理の遅れを解消し、セーフゾーンまで戻ることができるように、バキューム処理に追加リソースを割り当てます。このプロセスでは、XID がセーフゾーンに収まるまで、秒あたりのトランザクション総数が減少します。XID の経過時間の増加に伴い、バキューム ワーカーは動的に増加します。

3. 大きなテーブルに対する効率的なバキューム処理: デフォルトのバキュームは、pg_stat_all_tables テーブルに格納されているテーブル固有の統計情報に基づいています。これにはデッドタプルの比率が含まれています。これは小さなテーブルでは有効ですが、大規模で頻繁に更新されるテーブルでは効率的に機能しない可能性があります。AlloyDB の最新のスキャン メカニズムでは、大きなテーブルをチャンク単位でスキャンする自動バキュームをより頻繁にトリガーし、デッドタプルをより効率的に削除できるようになります。

4. 警告メッセージをログに記録: AlloyDB では、長時間実行されているトランザクション、孤立した準備済みトランザクション、孤立したレプリケーション スロットなどのバキュームのブロッカーが検出されると、PostgreSQL ログに警告が登録されます。これによりユーザーは状況にタイムリーに対応できます。

• “Found a backend process XXX with a long running transaction whose transaction id age XXX is larger than or equal to the transaction age threshold XXX.”

• "Found an old prepared transaction XXX whose transaction id age XXX is larger than or equal to the transaction age threshold XXX, database oid: XXX, owner oid: XXX"

• "Found a replication slot XXX whose min transaction id age XXX is larger than or equal to the transaction id age threshold XXX."

AlloyDB 適応型自動バキュームの有効化

適応型自動バキュームはデフォルトで有効になっていますが、フラグ enable_google_adaptive_autovacuum を使用して無効にできます（または後で再び有効にできます）。  

AlloyDB 適応型自動バキュームのメリット

AlloyDB 適応型自動バキュームは、ワークロードのリアルタイムでのリソース使用状況に基づいてバキューム プロセスを調整し、ユーザーがバキューム パラメータを調整する必要がないように設計されています。ただし、ユーザーは自動バキューム関連のパラメータを調整でき、AlloyDB はユーザーによる設定に従います。

適応型自動バキュームを使用するメリットは多数ありますが、その一部を以下に示します。

• パフォーマンスの向上: 適応型自動バキュームにより、肥大化が解消されることで、ワークロードが変化する場合でもデータベースが常にピーク パフォーマンスで実行されるようになります。

• メンテナンスの削減: 適応型自動バキュームではバキューム処理と分析操作の頻度が自動的に調整されるため、これらの処理を心配する必要がありません。

• 可用性の向上: 適応型自動バキュームにより XID ラップアラウンドが防止されることで、データベース停止が回避され、可用性が向上します。

Google 社内で実施した 64vCPU SKU での 100% キャッシュ済み TPC-C 実行による AlloyDB ベンチマーク テストでは、適応型自動バキュームを有効にしたところ、平均して XID のフリーズ期間は ~1.5B から ~1B に減少し、デッドタプル数は ~1.2B から 0.7B に減少しました。その結果、より長い期間にわたってデータベースが最適なパフォーマンスを実現できました。

まとめ

適応型自動バキュームは、手動操作なしでバキューム プロセスを効率的に管理する優れた自動パイロット機能であり、AlloyDB データベースのパフォーマンスと可用性の向上を実現できる可能性があります。適応型自動バキュームをまだお使いではない場合は、今すぐ有効にしてご利用いただくことをおすすめします。

• 適応型自動バキュームについて詳しくは、適応型自動バキュームの構成のドキュメントをご覧ください。

• AlloyDB の詳細については、AlloyDB for PostgreSQL: インテリジェントでスケーラブルなストレージ | Google Cloud 公式ブログをお読みください。

• $300 分の無料クレジットと 20 種類以上の Always Free プロダクトを活用して Google Cloud で構築を開始しましょう。https://cloud.google.com/free