クロスイデアblog

以前、とある業務システムで検索スピードが要件を満たさずにリリースが延期されたという話を耳にしたことがあります。それを聞いた時、かつて少し関わっていた現場で、検索するとCPU負荷が100％に張り付くシステムや、ちゃんと動いていたのにある日を境に検索がタイムアウトするようになったシステムの存在を思い出しました。

この手の話はデータベースの索引が適切でないことに原因があることが多いのですが、データベース設計の教科書でも索引は基本的な単元であるにもかかわらずわりと良く聞く話でもあったりします。プログラムはゴリゴリ書けるけど、DB設計をきちんと学んだことが無い人が作っているという可能性もあるのですが、もしかしたらある程度きちんと機能する索引を付けるにはそれなりに経験を積んでセンスを磨く必要があるということなのかもしれません。

索引は検索キーやソートキーに付与するというのが基本ですが、複数カラムを指定して検索する場合にその索引が使われなければ、別途使われるような索引を付与するといったことをします。ただ、あまり索引を付け過ぎると更新処理のパフォーマンスが落ちるので、検索スピードが欲しい場合はマスタとは別に検索用のテーブルを用意することもよくあります。最初は普通に結合して選択していたものが、段々パフォーマンスが落ちてきたために途中で検索用テーブルを追加するといったことは別におかしいことではありません。

適切な索引が無ければどんなにSQLを効率的に記述してもパフォーマンスは出ませんし、また、基本的な索引は理論だけで行けるとしても、RDBMSの実行計画は実際にテーブルに格納されているデータの件数だけでなく内容によっても変わってきます。なので、もし絶対に止めてはいけないようなシステムの場合は、テストの段階で本番さながらのテストデータを使って本番さながらの件数を格納した上で動作を確認しチューニングする必要があります。

チューニングの作業は私は結構楽しいと思っていますけれど（例えばチューニングして検索スピードが10分の1になったら楽しくないですか？）、面倒くさいと感じる人はなるべくやらずに済ませたいと思ってしまうのでしょうか。

久しぶりにアーキテクトっぽい話題としてログの話をします。その中でもログレベルとメッセージコードの設計にまつわる失敗談をお伝えしたいと思います。ログまたはロギングは情報システムにとって主要な機能でないにも拘らず、おざなりな設計をすれば後で痛い目に遭うという曲者です。

ログレベルというのはエラーレベルとも言いますが、ログに記録する事象の重要度（あるいは緊急度）を示しており、大別すると3種類で故障・警告・情報です。ただ、ログレベルの種類はそのレベルの定義も含めて運用設計に関わってくるので、一般化しようと思ってできるものではありません。ですので、ここではログレベルそのものの話題ではなく、メッセージコードの体系との兼ね合いについてお話しすることにしましょう。

メッセージ設計の観点

まず考えることとして、メッセージコードにログレベルを持たせるかどうかという点があります。それはつまりメッセージコードを見ただけで、ログのレベルを判断できるようにするかどうかということです。故障ならErrorの頭文字を取ってE001、警告ならWarningの頭文字を取ってW001などとするのはこの考え方です。

次に考えることとして、発生したメッセージのログレベルに応じた制御があります。例えばバッチプログラムではジョブストリームの制御、Webアプリなどのオンラインプログラムでは画面遷移の制御を切り替えるということ。それらに加えてログ監視によるエラー検知と警報（エラー通知）を行うことも最近ではごく一般的なことだと思います。

ログ出力の方式の失敗

さて、そのログ出力処理ですが、あるシステムでは、ログ出力処理にログレベルとメッセージコードの両方を渡していました。これは愚直な方法ですがシステム全体において両者の整合性を保つ必要があるため、正直しんどい方式です。

そこで、私がアーキテクチャを担当した別のシステムでは、メッセージコードだけを渡す方式を採用しました。ログ出力処理の中で渡されたメッセージコードからログレベルを判別して以降の制御を行うというものです。これはほとんどの場合においてうまく行きましたが、ログレベルの変更に弱いということが分かりました。ある事象についてのログレベルを変更したいという場合、ログ出力処理を呼び出している個所のメッセージコードも併せて変更する必要があるということです。

また、ログレベルと画面遷移が必ずしも対応してないケース、つまり、同じレベルのエラーでもエラー画面に遷移すれば良い時もあれば、前の画面に戻したい時もあり、そういったケースでは単純な共通コードでは実現できないため少々苦労しました。それに、ログレベルが変わっただけで画面遷移（あるいはジョブ制御）が変わってしまうと不都合もあるでしょうし、バグになりやすいのです。

ログレベルとメッセージの現実的なアイデア

そこで、現実的にはログレベルと制御を分離した上で、ログレベルの変更に強いログ出力方式を考案する必要があります。前提として、メッセージの文言は定義ファイルに設定されており、メッセージコードから一意に引当てることができるものとします。

いくつか考えられると思いますが、ログに記録するメッセージコードの体系は、既に運用設計の中で定められており自由に決められない場合があります。そういう場合でも対応できるようにログに記録するメッセージコードとは別に内部のメッセージコードを定義すると良いのではないかと考えています。

この方式では内部のメッセージコードにはログレベルを表す文字を含めず連番（とその他の記号）のみとし、ログレベルはメッセージ定義ファイルの中に文言と一緒に定義しておきます。ログを出力する時は内部メッセージコードをログ出力処理に渡します。するとメッセージ定義ファイルからログレベルと文言を引当ててログに記録します。

こうしておくと、ログレベルを変更するにはメッセージ定義のみを変更すればよく、ログ出力処理を呼び出しているコードの修正を行う必要がありません。ログレベルの変更で悩まされたという方は是非一度試してみてはいかがでしょうか。