現場で役立つ実践ノウハウWeb開発の「べし」「べからず」(運用編)
～性能を最大限に引き出すための設計・開発・運用～
永安 悟史
本記事は、技術評論社 WEB+DB PRESS Vol.63 で掲載されたものを、著者と出版社の許可を得て転載したものです。なお、一部 記述に変更のある箇所もあります。
【運用】データベースのPDCA 注4 を回す
注4：Plan（計画）、Do（実行）、Check（評価）、Act（改善）を1サイクルとしたマネジメントプロセスのこと。
【べからず】 サーバログを無視してはいけない
運用の基本中の基本として、サーバログをきちんと取得し、その内容を確認する必要があります。
ここまでも述べてきたように、データベースの挙動は蓄積されたデータの量や、外部環境（接続数など）によって徐々に変化してきます。そのため、トラブルが起こる前に、ある程度その兆候が出てくるものです。
データベースの挙動が外部からはなかなかわかりづらいですが、実際にはサーバログをきちんと確認することで、相当な情報を確認できます。リスト6は、PostgreSQLでよく見られるメッセージの例です。
このように、データベースのサーバログからは、パフォーマンスチューニングのヒントや、大きなトラブルの「兆候」を読み取ることができます。
よって、運用を開始する前にこれらのメッセージをきちんと記録される設定になっていることを確認し、運用開始後はサーバログに出力されるこれらの内容を把握しておく必要があります。これによって、トラブルシューティング時の解決時間が大きく変わってきます。
PostgreSQLであれば、次のようにpostgresql.confでサーバログの設定を行うことで、「接続元ホストIPアドレス、時刻、接続ユーザ名、データベース名、サーバプロセスID」をサーバログとして出力できます。
log_line_prefix = '%h [%t] %u/%d:%p '
リスト6 PostgreSQLのcheckpoint_segmentsの値が小さいときに出るメッセージ
[2011-05-20 12:49:29 JST] /:22983 LOG: checkpoints are occurring too frequently (9 seconds apart) [2011-05-20 12:49:29 JST] /:22983 HINT: Consider increasing the configuration parameter "checkpoint_segments". [2011-05-20 12:49:40 JST] /:22983 LOG: checkpoints are occurring too frequently (11 seconds apart) [2011-05-20 12:49:40 JST] /:22983 HINT: Consider increasing the configuration parameter "checkpoint_segments".
参考
【べからず】 性能監視／リソース監視を行わずに稼働してはいけない
前述のとおり、データベースはさまざまなハードウェアコンポーネント（ハードウェアリソース）が関連して動作しています。そのため、性能低下やトラブル発生時には、問題の切り分けが難しくなります。そのような状況において、非常に重要なことは「各システムコンポーネントを監視しており、データが蓄積されている」ということです。
トラブルが発生してから初めて情報収集を始めても、それは「過去に正常に稼働していたとき」の状況と比較できるものではありません。そのため、トラブルシューティングの手間がよりかかってしまうことになります。
また、メモリ不足やディスク不足などに陥ると、一部のSQLや管理系のコマンドが動作しなくなることがあります。たとえば、PostgreSQLのソート処理はデータ量が増えるとディスクを一時領域として使いますし（サーバがメモリ不足になるのを防ぐため）、REINDEX/VACUUM FULLなど処理のためにディスクを使用するものがあるためです。
そのため、定常的な性能監視／リソース監視を実施し、処理性能および各リソースの使用がどのような状況にあるのかを、記録・監視しておく必要があります。 システムリソースの監視をするには、vmstatやtopなどのコマンドラインのツールから、NagiosやCactiなどのWebを使った監視ツールまであります。また、データベースの運用監視にも、コマンドラインツールからWeb系管理ツールまで、各RDBMSに応じてさまざまなツールがありますので、それらを使って監視できます（図7）。
【べし】 統計情報をメンテナンスすべし
データベースの運用で見落とされがちな点として、「統計情報（テーブル統計情報）のメンテナンス」が挙げられます。統計情報は、各テーブルにどのようなデータがどの程度保存されているのか、そのデータの偏り（カーディナリティ）がどうなっているのか、といった情報で、データベースの内部に保存されています。
前述したように「実行計画の生成／最適化」では、この統計情報をもとにアクセスパス、つまり「どのテーブルにどのような順序でアクセスするか、テーブルスキャンをするかインデックスを使うか」などの判断を行います。
この統計情報は、テーブルデータが変更されていくのに合わせて、更新されていく必要があります。この統計情報は、実行計画を決める際の判断材料となるため、統計情報がテーブルデータの実態と異なっていると、本来行うべきでないアクセスパスを選択してしまうことになりかねません 注5。
通常、統計情報は自動的に更新されますが、設定によって自動メンテナンスが無効にされている場合、あるいは大量のデータ更新（バッチ処理など）が発生した場合など、管理者自身が更新する必要がある場合もあります。
運用を行う際には、統計情報がどのようなタイミングで更新されているのか、きちんと状況を把握し、特に大規模なデータ更新（バッチ処理など）を行った際にはデータベース管理者が統計情報を更新する必要があります 注6。
注5：たとえば、インデックスを使うべきところで、テーブルスキャンをしてしまうなどです。
注6：PostgreSQLであればANALYZEコマンドを使います。
【べし】 アップグレードを見込んで運用計画を立てるべし
データベース製品のバージョンアップには、大きく分けて2種類のバージョンアップがあります。メジャーバージョンアップとマイナーバージョンアップです。
前者は、データベース製品のバージョン番号が大きく変わるもの、つまり新しく大きな機能が追加されたり、あるいは一部の機能の互換性が失われたりするケースです。後者は、基本的にはバグフィックスであり、主にセキュリティ対策などが行われるものです。
メジャーバージョンアップは頻繁に起こることではありませんが、生じるインパクトが大きいため、アップグレード実施にあたっては綿密な計画を立てる必要があります。一方、マイナーバージョンアップは比較的頻繁に発生することから、定常的な運用計画の中に組み込んでおくことが望ましいと言えます。
たとえばPostgreSQLであれば、マイナーバージョンアップではデータの互換性が確保されていますが、どのファイル（プログラムのファイルやデータファイル）をどのようにバックアップするのかを運用計画に組み込んでおくべきでしょう。
また、メジャーバージョンアップの場合は、データベースのdump/restore方式でアップグレードするのか、pg_upgradeのような専用ツールを利用するのか、あるいはSlony-Iのようなレプリケーションソフトウェアを用いてアップグレードするのかなど、選択肢がいくつか存在しますので、これらも検討する必要があります。