運用日和 vol.02 ログとHDDとサービスの未来

こんにちは、むおんせいです。

今回はプログラムエラー時などに書き出す「ログ」に着目してお話をしていきます。
読み終わった頃にはログの大切さを実感し、exceptionを握りつぶしたりしない体質になる、、はず。。　

▼何で書いたのか

システム運用の具体的な内容初回となりますが、テーマをログにした理由は、運用の仕事はとにかくログを確認することが多いなと感じたからです。

私が担当しているサービス運用では権限の都合で本番環境は運用者しかさわれません。
それゆえに、顧客からの問い合わせのたびに『本番環境のログとってきて』という作業が発生しています。

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

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

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

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

建物や車ならば一見しただけで壊れているとわかることが多いですが、プログラムは見た目だけでは異常が発生していることがわかりません。

どんなに内部でエラーを起こしても、カッコいい動きのあるサイトは見た目だけはカッコいいまま動いているように見えます。そして動かなくなる頃にはもう手が付けられない状態になっているなんてことも。。

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

▼ログの一生

日々プログラムを作っている皆さんは、ログを指定のファイルに出力して終わりとすることが多いと思います。

今回はログに着目するということで、運用目線でログ周りの知識を共有させていただきます。

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

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

　1. アプリケーションからのログ出力

　運用中のアプリケーションから任意のタイミングでログが出力されます。
　もし監視システムがある場合はこのタイミングでエラーコード(※1)毎にアラートが通知され、運用担当者がシステムを確認したり、再起動をするなどしてシステムの正常性を確保します。

　「システムからのアラート」で即時サービス復旧すれば顧客からの苦情を防げます。 

　2. ログローテート

　日毎/時間毎のタイミングで古いログは別ファイルに切り分けられます。この処理を「ログローテート」と言います。

　この処理があることで「古いログだけをファイル単位で古い順に削除」できるようになり、ログによるHDDの容量圧迫を防げます。

　もしログローテートを実施しないと、1ファイルにログを継続して書き続けることになり、ファイル単位での削除ができないためログが肥大化しHDD使用量を圧迫します。

　3. ログの圧縮

　ローテートされたログは日次でgzipなどの形式で圧縮されます。
　通常は○日以上経過したログはgzipするという形で新しいログは圧縮されておらず、すぐに中身を確認できる状態になっています。
　こちらの処理もHDDの容量圧迫を避けるための工夫の一つです。

　4.ログの削除
　 ローテート・圧縮されたログは一定期間保管(※2)された後、削除されます。

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

※2
　ログの保管期間は顧客から指定を受けることがあります。
私の運用していたシステムは通常1ヶ月が保管期間でしたが、長いところだと「一年はログを保持して何かあったときに追跡できるようにすること」を契約条件にしてくる会社もありました。
　感覚的に、金融系の会社はログの保持期間が長い場合が多いです。

▼ログ作成時の注意

　これは私が運用者として関わったシステムでおきた話です。

　とあるシステムで音声プログラムの不具合改修を実施し、本番環境に適用しました。
　受入試験では不具合が発生した箇所も問題なく修正されており、既存機能のデグレード(※3)もありません。

　しかし、本番環境へ適用し1週間経った日、システムで障害が発生しました。
　機能には全く問題がなかったにも関わらず何故問題が発生したのでしょう。
　原因は「ログがデバッグモード出力」(※4)になっていたためログが肥大化し、HDDが枯渇しあと少しでシステムが完全停止する寸前でした。
　
　この例のように、開発者はログの出力量をあまり意識しない傾向があります。しかし、ログの出力量が膨大だとそれだけでHDDは枯渇し、サービスは停止してしまう可能性があるのです。
　今一度自身の作成したプログラムがどの程度のログを出力しているかを意識してみてください。

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

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

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

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

▼ログとサービスの未来

最初に「ログはシステム障害の調査に使う」とお伝えしましたが、実はそれ以外にも使われています。
　
　最近では障害調査だけでなく「顧客がシステムのどの機能を一番使っているか」や「どのような使い方をしているか」の分析にもログは使われています。

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

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

▼おわりに

　たかがログと思うかもしれませんが、そのログを元に監視システムや運用者が動き、サービスの進むべき方向性まで示してくれるのです。

　今後開発するときは「運用しやすいログの書き方」を意識していただけると、運用者は救われます。

　そして運用しやすいシステムは、きっとあなた自身にもより良いフィードバックをくれるはずです。より良い開発環境のために、少しだけ運用のことを考えてみてください。

次回へ続く ->