Yahoo!ショッピングにおけるログ設計と監視

こんにちは、ショッピング事業部開発部の吉野と申します。

今回は「アプリケーションログの設計と監視」について、実際にYahoo!ショッピングで採用している方法を少し交えながらお話しさせていただきます。

1.ログ設計のポイント

ログ設計は、以下のポイントに注意して行うとよいでしょう。

・ログ出力のポイントが押さえられているか

　⇒セッションの始まりと終わり、処理の過程、例外処理の中など。
　　フローチャートのような処理フロー図があれば、そこにログ出力ポイントを書き込むとわかりやすくなります。

・出力する情報に過不足はないか

　⇒「いつ(システム時間)」「だれが(プロセスID・IPアドレスなど)」
　　「どこで(パスなど)」「なにをした(実行コマンド)」といった情報が必要です。
　　処理に掛かった時間などもあるといいでしょう。
　　しかし、逆に情報を出力しすぎてもよくありません。
　　webアプリケーションでHTMLをすべてログに出力していたり、オブジェクトの内容をすべてダンプするなどをしていたら、
　　ディスクがいっぱいになりサービスが停止した なんてことになってしまったら本末転倒です。
　　(この手のケースは意外によくあります)
　　出力する情報が本当に必要かどうかの検討も行いましょう。

・ログの出力先の分け方は適切か

　⇒すべてのログを一つのファイルに出力するのを避け、目的別に出力ファイルを分けましょう。
　　アクセス状況を集計する目的のログに処理過程を出力してもあまり意味がありません。

・ログローテーションの間隔は適切か

　⇒ローテーションの間隔は、ログの容量や解析するタイミングを考慮して決めます。
　　その際、ローテーションしたログの圧縮も行った方がよいでしょう。
　　ローテーションにはloglotateが便利です。

・ログの保存期間は適切か

　⇒ログの保存期間は内部統制などでも話題になりますので、
　　そのあたりも考慮しながら決める必要があります。
　　ディスク容量も気にしないといけないので、外部記憶装置(DVD-RやDAT装置など)への保存も考えましょう。
　　とはいえすべてのログを永久に保存するのは無理がありますので、
　　重要でないバッチの処理ログは1か月保存、エラーのログは1年保存 など、重要度に応じて保存期間を決めましょう。

・ログ集計の仕組みは考慮しているか

　⇒「日次でログを回収し、ツールで読み込んでグラフで表示する」など。
　　ログが再利用できる仕組みを考えましょう。
　　Yahoo!ショッピングでは独自に統計ツールを作成し、売上やアクセス状況などを集計しています。

上記ポイントにプラスして、Yahoo!ショッピングでは独自に以下の点についてもチェックしています。

・ログに個人情報が出力されていないか

　⇒Yahoo! JAPANでは個人情報に関する取り扱いのルールが厳しく取り決められており、お客様が入力した
　　氏名、住所、カード番号などの個人情報はログに出力してはいけないルールになっています。
　　これにより私たち開発者はログから個人情報を取得することが不可能になっています。

・ログ出力のテストを行っているか

　⇒後述する「監視対象ログ」については、テスト項目書に記述して出力内容を検証します。

・監視対象とするログはどれか

　⇒後述「2.ログの監視」でご説明します。

ログは問い合わせや障害時の対応だけに使うものではありません。
ログを基にアクセス解析を行うことにより、ユーザーの行動パターンを把握できます。
それによって、
「この機能はあまり使われてないな。。使いづらいのかな？」
「ここのリンクはあまりクリックされてないな。。見せ方が悪いのかな？」
といった分析ができ、サービスの改良にも役立ちます。
ログ設計の際にはこのような点も考慮して行うとよいでしょう。

2.ログの監視

次に、ログの監視について、Yahoo!ショッピングで実際に行っている例をご紹介します。

まず、ログ設計の際に出力するログを「通常ログ」と「監視対象ログ」の2つに分類します。
「監視対象ログ」に分類されたログは、以下のようにログ設計を行います。

監視の対象とするログはsyslogdを使用して出力します。

出力するログには、一つ一つにIDとログレベルを割り当てます。
IDの体系は「サービス名-連番」となっています。
サービス名とは、Yahoo!ショッピングの中で動いているサービスのことで、
たとえばショッピングカートに関するログは「CART」課金システムに関するログは「BILL」といった感じで命名していきます。

ログレベルは、syslogでは[debug][info][notice][warn][err][crit][alert][emerg]の8つのレベルがありますが、
私たちはこの中の[info][notice][warn][err][crit][alert]の6つを使用しています。

レベルを割り当てる基準は以下のように取り決めています。

ログレベル	基準・対応要否
info	バッチの正常終了報告などのログ。 対応は不要。
notice	通常とは違うルートで終了したが、問題がない場合のログ。 対応は不要。
warn	n分以内にn回以上発生した時点※1で対応が必要になる場合のログ。 営業時間内のみ対応する。
err	1回発生した時点で対応が必要になる場合のログ。 営業時間内のみ対応する。
crit	n分以内にn回以上発生した時点で対応が必要になる場合のログ。 即時対応が必要。
alert	1回発生した時点で対応が必要になる場合のログ。 即時対応が必要。

※1「何回リトライしても同じエラーが発生する」「ほかのサーバーでも同じエラーが発生している」など

syslogdには、出力したログをリモートサーバーに送信する機能があります。
この機能を利用して、あらかじめ設置されているログ集約サーバーにログを送信します。

ログ集約サーバーではYahoo独自のログ監視アプリケーションがcronで動いています。
このアプリケーションでは、
「何のエラーが」「何分以内に」「何回発生したら」「何のアクション(メール送信やスクリプト実行など)を行う」
といった設定ができます。

通常はアクションとしてメール送信を使用しています。
サービスごとにPC用・携帯用のメーリングリストを作成し、ログのレベルがinfo〜errであればPC用のメーリングリストに、crit〜alertレベルの場合は携帯用のメーリングリストに送信します。

■まとめ

システム開発をする際、ログ設計は非常に重要な工程です。
しかし、スケジュールの短縮や設計エンジニアの考慮不足によって、残念ながらこの工程がスキップされてしまうケースが少なくありません。
ログを最大限に活用することで、システム運用コストを抑えたり、よりよいサービスを提供する手掛かりにもなります。

今回お話したのはあくまで一例です。機会があればもう少し掘り下げてご紹介できればと思います。
またお会いしましょう。