PostgreSQL導入に向けての取り組み ～大規模システムへの適用を目指して～(5)

4.3 運用面の着目点 3： DB メンテナンスの改善

データの断片化による性能低下に対処する方法として、弊社では PostgreSQL の CLUSTER コマンドを利用するようにしていました。 それは、一時的に対象の表と同程度の空き領域がディスクに必要となるものの、テーブル再編成の処理が高速に行えるためです。 しかしながら、CLUSTER はテーブルに対して ACCESS EXCLUSIVE ロックを取得します。 そのため、データベース操作（参照/更新両方）がブロックされ CLUSTER 処理中はサービスを停止する必要があります。 24 時間 365 日運用でサービス停止時間の確保が不可能な場合や、夜間に大量のバッチを実行する必要があるシステムの場合、 CLUSTER によるサービスへの影響は、PostgreSQL 適用の大きな課題の  1 つとなっています。

そのようなシステムに対して、弊社では pg_reorg というツールの活用を検討しています。 pg_reorg は、CLUSTER 処理と同等のことが参照/更新処理をブロックせずに実施可能な、言わばオンライン CLUSTER とも呼べるツールです。

図4.3-1 のように、対象テーブルへトリガを設定し、操作ログ表へ再編成中の更新処理を記録しておき、 最後にその差分情報を反映するようにしているため、オンラインでの再編成が可能となっています。

図4.3-1

注目すべき点として、通常 CLUSTER を実施するような断片化度合いが大きい場合においては、 図4.3-2 のように CLUSTER の処理時間と比較して 10 倍以上速い検証結果が出ているということです。 CLUSTER は、INDEX 順にテーブルデータを取得するので、断片化度合いが大きい場合は、大量のランダムアクセスが起こりますが、 pg_reorg は、シーケンシャルにデータを読み、ソートした後にシーケンシャルにテーブルを構築するため、 断片化の状況によって所要時間が大きく変わることはありません。

図4.3-2

サービス中においても、参照/更新処理をブロックせず、断片化度合いが大きい場合は CLUSTER よりも高速にテーブル再構成が可能なツールということで、 弊社では導入を検討していこうと考えています。 ただし、利用する際は以下のような点には注意してください。

pg_reorg は、前記しました pg_statsinfo 同様に NTT OSS センタで開発した BSD ライセンスの OSS で、 こちらも pgFoundry の中の 1 つのプロジェクトとなっています。詳細については以下のアドレスを参照願います。

リンク先： http://reorg.projects.postgresql.org/index-ja.html

4.4 運用面の着目点 4： 監査への対応

皆様の中には、SOX 法という言葉をよく耳にされる方も多いと思います。SOX 法は、財務報告を適正化するための内部統制の義務化に関する法規制のことです。 その中の IT 内部統制として、コンピュータの不正利用を防ぐため監査ログを取得し、4W1H の情報を残すことがポイントとされます。

PostgreSQL の場合、標準機能を利用することで、IT 内部統制に必要な情報を蓄積することが可能です。 図4.4-1にありますように、ユーザ毎にログ取得の粒度を設定し監査ログとして蓄積します。 この例では admin ユーザは「all：全て」、normal ユーザは「mod：更新系のみ」、batch ユーザは「ログ取得なし」という設定をして、 該当する操作を監査ログとして蓄積できることを示しています。

図4.4-1

しかし、現状ではログ取得の粒度に関するカスタマイズ範囲が狭いため、 取得するログの量が大きくなってしまう傾向にあり、I/O 負荷も増大し性能へ影響を及ぼす可能性があります。 システム要件によっては性能と監査の両立が難しい場合もあり、PostgreSQL の導入を見送るケースもあります。

図4.4-2 にありますように、必要なログに絞りこんだり、I/O の量を低減するために、 例えば「監査対象テーブルに対して行われる処理のみをログ対象にしたり、ホワイトリストとして監査から外す SQL を設定する」などの機能があれば、 より PostgreSQL の適用領域が広がるのではないかと我々は考えています。

図4.4-2

現在執筆時点の最新版である PostgreSQL 8.4 には該当機能が実現されていないため、今後のさらなる機能拡充が期待されます。