プロンプト
本番環境のPostgreSQL 18において、レポートクエリ、bitmap heap scan、およびvacuumがストレージレイテンシによって制限されています。非同期I/O（AIO）を評価し、安全にロールアウトするための計画を設計してください。io_methodの選択、並行性のチューニング、pg_stat_ioおよびpg_aiosの検証、CPU・キャッシュ・ストレージのボトルネックの分離、レイテンシが悪化した場合のロールバックを含めてください。
面接官がテストしていること
ここでは、データベースのパフォーマンス実験手法と本番変更における規律がテストされています。AIOは複数の読み取りを並行して発行できますが、すべてのワークロードを高速化するわけではありません。優れた回答では、worker、io_uring、syncを説明し、再現可能なワークロードと統計情報を使用し、すべてのパラメータを最大化するのではなくロールバックのしきい値を定義します。
明確化のための質問
- 主要なアクセスパスはsequential scan、bitmap heap scan、vacuum、またはランダムなポイントルックアップのどれですか？
- ストレージはローカルNVMe、ネットワークバインドストレージ、またはコンテナボリュームですか？また、カーネルは
io_uringをサポートしていますか？ - 目標はスループット、P95レイテンシ、vacuum完了時間、またはCPU使用率の削減ですか？
- リードレプリカやシャドウインスタンスでテストを実行できますか？また、起動パラメータの変更には再起動が必要ですか？
30秒のフレームワーク
固定されたデータおよびキャッシュ条件下で、レイテンシ、スループット、CPU、I/O待機、vacuum所要時間のベースラインを構築します。次に、方式の選択（worker/io_uring/sync）、並行性制御（effective_io_concurrency、io_max_concurrency、io_workers）、およびオブザーバビリティ／ロールバック（pg_stat_io、pg_aios、SLOゲート）を網羅します。1回の高速な実行ではなく、段階的な実験に基づいて判断します。
ステップバイステップの設計
1. 比較可能なベースラインを確立する
PostgreSQL 18のマイナーバージョン、データ、インデックス、統計情報、およびクライアント並行性を固定します。コールドキャッシュとウォームキャッシュを個別に測定し、EXPLAIN (ANALYZE, BUFFERS, WAL)、pg_stat_io、ディスクレイテンシ、およびCPUを記録します。リグレッションが平均値の中に埋もれてしまわないよう、sequential scan、bitmap heap scan、およびvacuumを分けて測定します。
2. I/O方式を選択する
io_method=workerはPostgreSQLのI/Oワーカーを使用し、保守的な互換性ベースラインとなります。io_method=io_uringにはliburingビルドとカーネルのサポートが必要です。io_method=syncは対照群およびロールバックパスとなります。ビルドと権限を検証した後、同一ワークロードに対して各方式を複数ラウンド実行します。
3. 並行性を制御する
effective_io_concurrencyおよびmaintenance_io_concurrencyは、セッションおよびメンテナンス向けの並行性ヒントを提供します。io_max_concurrencyはプロセスごとの同時実行数を制限し、io_workersはworker方式に適用されます。値を徐々に増やしながらストレージキュー、P95、CPUを監視し、デフォルトですべての値を最大値に設定することは避けます。
4. シグナルを解釈する
pg_stat_ioを使用して、バックエンド、オブジェクト、操作ごとの読み取り、書き込み、待機を比較します。pg_aiosを使用して、準備中、実行中、または完了したハンドルを検査します。クエリが高速化する一方でストレージキューとテールレイテンシが増加している場合、スループットと競合がトレードオフになっています。ビューに変化がない場合、そのワークロードがサポート対象パスを使用していないか、キャッシュヒットが支配的である可能性があります。
5. 実験とキャパシティを設計する
レプリカまたはシャドウインスタンスでクライアント並行性を段階的に引き上げ、スループット、P95/P99、CPU、I/O深度、およびvacuumバックログを比較します。ネットワークストレージの場合は、バースト制限、読み取り増幅、ノイジーネイバーを考慮に入れます。WAL、チェックポイント、autovacuum、バックアップ用のキャパシティを確保します。
6. ロールアウトゲートとロールバックを設定する
ワークロードごとにメリットとしきい値（リグレッション基準）を定義します。P95が悪化しないこと、ストレージキューが飽和したままにならないこと、vacuumバックログが増加しないことなどです。明確な担当者を定めたメンテナンスウィンドウ内で、少数のインスタンスセットにロールアウトします。しきい値を超えた場合はsyncまたは前回の並行性値に切り替え、変更前後の統計情報を保持します。
7. 制限事項と次のステップを明確にする
PostgreSQL 18 AIOは並行I/Oを発行できるパスを改善するものであり、インデックス、クエリプラン、キャッシュチューニング、ストレージのアップグレードを代替するものではありません。カーネル、ビルドオプション、io_method、パラメータスナップショットを記録し、ロールアウトを拡大する前にアップグレード時にもマルチワークロードベースラインのテストを繰り返します。
優れた回答の例
「私なら、固定されたデータ、統計情報、キャッシュ条件を備えたリードレプリカを使用して、コールドおよびウォーム状態のsequential scan、bitmap heap scan、vacuumを測定し、EXPLAIN BUFFERS、pgstatio、ディスクレイテンシ、CPUを記録します。まずworkerから開始し、liburingとカーネルサポートを検証した後にのみiouringと比較し、対照群およびロールバック用としてsyncを維持します。iomaxconcurrencyとioworkersを制限しつつ、ストレージキューとP99を監視しながらeffectiveioconcurrencyとmaintenanceioconcurrencyを徐々に増やします。pg_aiosでアクティブなハンドルを確認します。キューの飽和なしにレイテンシ/スループットゲートをクリアしたワークロードのみにカナリア展開を行い、テールレイテンシやバックログのリグレッションが発生した場合は即座にsyncへ切り戻します。」
よくある失敗パターン
- ベースラインやキャパシティバジェットなしに並行性を最大化する。
- ビルドやカーネルのチェックを行わずにio_uringが利用可能であるとみなす。
- P95/P99、キュー、vacuumバックログを無視して平均レイテンシばかりを注視する。
- サポート対象パスやキャッシュヒットを無視して、pg_aiosをすべてのクエリがAIOを使用している証拠として扱う。
- カナリアゲート、担当者、しきい値、およびsyncへのロールバック手順を省略する。
フォローアップの方向性
どのような場合にio_uringではなくworkerを選択しますか？
ビルドやカーネルにliburingサポートがない場合、または保守的な互換性パスが必要な場合にworkerを選択し、測定結果に基づいて判断します。
コールドキャッシュとウォームキャッシュのテストを分ける理由は何ですか？
ウォームキャッシュテストは主にCPUとメモリを使用しますが、コールドキャッシュテストはストレージの並行性とテールレイテンシを露呈させます。これらを混在させると、実際のAIOの効果が見えなくなります。
effective_io_concurrencyは常に大きい方が良いですか？
いいえ。過剰な並行性はストレージの競合と全体のテールレイテンシを増大させる可能性があるため、デバイスとワークロードに合わせて調整する必要があります。
vacuumのメリットをどのように証明しますか？
肥大化（bloat）、不要タプル（dead tuples）、およびメンテナンスウィンドウを一定に保ち、完了時間、I/O待機、ロックの影響、バックログを比較します。
pg_aiosは長期的な監視ソースになりますか？
これは現在のハンドルを表示するものであり、診断やサンプリングには役立ちますが、傾向の把握にはpgstatio、システムメトリクス、ワークロードラベルが必要です。
参考文献
PostgreSQL 18「Release Notes」、「Resource Consumption Configuration」、および「pg_aios System View」。