vol2. ログとHDDとサービスの未来

訪問いただきありがとうございます。

こんにちは、エスワイシステム関東の百瀬です。

今回はプログラムエラー時などに書き出す「ログ」に着目してお話をしていきます。

読み終わった頃にはログの大切さを実感し、エラー処理を丁寧に扱う体質になる…はず。

今回のテーマについて

初回テーマを『ログ』にした理由は、運用の仕事は「とにかくログを確認すること」が多いなと感じたからです。

システム運用では権限の都合で本番環境は運用者しかさわれない場合が多いです。

それゆえに、顧客からの問い合わせのたびに『本番環境のログとってきて』という作業が発生しています。

そんな業務をしながら「自分はプログラマをやっていた時、ここまで意識しなかったな」という事柄があったので、ログ周りのお話を書きたくなったのです。

それでは本編スタートします。

そもそもログって何に使うのか？

プログラムを作っていると上位SEの方から「ちゃんとログ出力書けよー」と指示されます。このログ、基本的な使い方は『システム障害時の調査』に使われます。

建物や車ならば一見しただけで壊れているとわかることが多いですが、プログラムは見た目だけでは異常が発生していることがわかりません。
どんなに内部でエラーを起こしても、カッコいい動きのあるサイトは見た目だけはカッコいいまま動いているように見えます。
そして動かなくなる頃にはもう手が付けられない状態になっているなんてことも…

こういった外からではわからないシステムの動き・異常を記録し、システムの足跡を残していくのがログの役割です。

ログのライフサイクル

日々プログラムを作っている皆さんは、ログを指定のファイルに出力して終わりとすることが多いと思います。
今回はログに着目するということで、運用目線でログ周りの知識を共有させていただきます。

それではまず、一般的なシステムにおけるログの発生から消滅までを見てみましょう。

※筆者はLinuxの運用経験が長いのでLinuxでの説明になります。ご了承ください。

※1 監視サーバはログ内の特定のエラーコードに反応して通知を始めるので、エラーコードが間違って設定されていると監視サーバは反応できません。

　   十分注意してください。
※2 ログの保管期間は顧客から指定を受けることがあります。
保存期間は要件によりますが、最低1ヶ月から長いところだと「一年はログを保持して何か

        あったときに追跡できるようにすること」を契約条件にしてくる会社もあります。


　   感覚的に、金融系の会社はログの保持期間が長い場合が多いです。

ログ作成時の注意

これは私が運用者として関わったシステムでおきた話です。
とあるシステムでプログラムの不具合改修を実施し、本番環境に適用しました。

 
受入試験では不具合が発生した箇所も問題なく修正されており、既存機能のデグレード(※3)もありません。
しかし、本番環境へ適用し1週間経った日、システムで障害が発生しました。

機能には全く問題がなかったにも関わらず何故問題が発生したのでしょう。

 
原因は「ログがデバッグモード出力」(※4)になっていたため、ログが肥大化し、HDDが枯渇しあと少しでシステムが完全停止する寸前でした。
 

この例のように、開発者はログの出力量をあまり意識しない傾向があります。しかし、ログの出力量が膨大だとそれだけでHDDは枯渇し、サービスは停止してしまう可能性があるのです。

システムエンジニアの皆さんは自分が作ったシステムは１日にどれくらいのログを出力するか把握していますか？

ログを出力すること自体は意識出来ても、ログの出力量までは意識したことがなかったのではないでしょうか。
これを機に、今一度自身の作成したプログラムがどの程度のログを出力しているかを意識してみてください。

また今回の件は、本来であれば「エージング試験」と呼ばれる一定期間継続利用し問題ないかを確認する試験をすべきでしたが、顧客対応期日を優先するあまり確認を怠ったことに原因があります。

どんなに注意してもヒューマンエラーは起きるものです。運用者はサービス品質のために、どんなに優秀な開発者が作ったものでも「あえて信用せず」受領したプログラムが運用に耐えうるかを確認しなければならないのです。

※3 不具合改修時のミスにより、他の機能に新たな不具合を発生させること。もしくは、以前修正した不具合が再発してしまうこと。

※4 プログラマが開発中や障害調査のために、通常時よりログを細かく・多く出力する状態にしておくこと。

ログとサービスの未来

最初に「ログはシステム障害の調査に使う」とお伝えしましたが、実はそれ以外にも使われています。

最近では障害調査だけでなく「顧客がシステムのどの機能を多く使っているか」や「どのような順序で使っているか」の分析にもログは使われています。

 
サービス戦略として、サービスの新機能追加を検討する際、営業は各顧客に利用満足度アンケートをとり、それを元に新機能を検討します。
しかし、利用満足度のヒアリング相手が「システム導入責任者のみ」だと、実際の利用者がどのように使っているか、どんな使い方の傾向があるかはわかりません。

偏りなくみるためにはシステムログを使った分析が役に立ちます。このような使い方をするためにもプログラマの方はどこにどれだけログを書き込むべきかを検討してシステム開発をしていただければと思います。

終わりに

たかがログと思うかもしれませんが、そのログを元に監視システムや運用者が動き、サービスの進むべき方向性まで示してくれるのです。
今後開発するときは「運用しやすいログの書き方」を意識していただけると、運用者は救われます。
そして運用しやすいシステムは、きっとあなた自身にもより良いフィードバックをくれるはずです。

 
継続して利用される良いシステムを作るため、開発時に少しだけシステム運用のことを考えてもらえたら嬉しいです。

それでは、また！