はじめに
システムの耐障害性や高可用性についてどれだけ入念に検討し構築したとしても、システム障害を完全に防ぐことは不可能です。
そのため、「システムは止まるものである」という前提で、障害をいかに早く検知し、調査・対応できるかがポイントになります。特に、企業のビジネス（Business）、開発（Development）、運用（Operations）の3つの部門が連携してビジネスの生産性向上を目指すBizDevOpsにおいては、運用が要となりシステム障害の対応が基本となります。
本コラムでは、15年にわたり運用保守に携わってきた筆者の経験を基に、システム障害時の適切な対応に向けたログとの付き合い方について知見をご紹介します。
そのログ、役に立っていますか？
システムのログは、OS周りのシステムが出力するものと、アプリケーションが出力するものの2種類に分別されます。
本コラムでは、アプリケーションが出力するログを対象にしています。
例えばJavaでアプリケーションを開発する場合、ロギングライブラリとしてLog4jやLogbackを利用しているプロジェクトも多いかと思います。利用ツールに関わらず、ログとして、いつ・何を・どのように出力するかという点が重要になります。アプリケーション開発においてログ設計が十分でない場合は、運用に支障をきたす場面が多々あります。
ログ設計が不十分な事例
事例１）エラー時にログを出力していない
エラーが検知できないため、アプリケーションの利用者から問い合わせを受けて初めて障害の発生を知ることになる
事例２）出力されるログの内容が乏しい
エラーが発生したことは検知できるが、何が起きているのかが分からない
事例３）ログの出力が多すぎる
大量のログを出力すると必要な情報を抽出するだけでも手間がかかり、解析までに時間がかかる
事例１のようにログ出力をしていないのは論外ですが、見落としがちなのは、事例３のログの出力が多すぎるパターンです。
重要なのは、障害を素早く検知し解消することです。情報が多ければ多いほどよいということではありません。つまり、システム開発には、運用者の立場に立ったログ出力の設計が必要です。
ログに振り回されることなかれ
ログ設計において出力する内容を吟味することは重要ですが、出力する頻度についても検討が必要です。
例えば、通信処理においては接続エラーがしばしば発生しますが、再接続することで問題なく処理を継続できることも多いです。
このように、簡単に対処できるエラーまでログレベルをCRITICALに設定してしまうと、アラート通知が多発することになります。
アラート通知が多くなると、
- 軽微なエラーのアラート通知に慣れてしまいアラートを軽視する
- 対応が必要な重要なエラーに気付かない
といった問題を引き起こす恐れがあります。
そのような場合は、
- エラーの内容に合わせたアラート通知の頻度設定（複数回連続でエラーを検知すると1回発報する等）
- エラーの内容に合わせたログレベル設定（CRITICALからWARNINGに変更する）
などを見直す必要があります。
クラウド環境は銀の弾丸ではない
近年、企業のクラウド導入が進み、既存システムのオンプレミス環境からクラウド環境へ移行する案件をしばしば見かけます。
AWSを始めとするクラウドサービスは監視機能が備わっているものも多く、オンプレミス環境と比較するとサービス監視レベルも向上すると考えがちです。しかし、クラウドは導入すれば企業の課題をすべて解決してくれるような、いわゆる「銀の弾丸」※ではありません。
AWSの監視サービスAmazon CloudWatchは、マネージドサービスだけでなく、Amazon EC2のようなアンマネージドサービスも監視できます。しかし、サービスを導入しても、オンプレミス環境で言うところの物理サーバからミドルウェア部分までしか監視できず、アプリケーションレベルでの監視は利用者側に委ねられています。
そのため、アプリケーションのログ設計が適切に行われていないシステムでは、オンプレミス環境の監視レベルと何ら変わらない状況になりがちです。そのような、監視レベルに課題があるシステムでは、まずログ設計から見直すべきでしょう。
※銀の弾丸とは、解決が困難な問題を一撃で解決するような解決策のことを意味する。
フレデリック・ブルックスのソフトウェア工学の論文(1986年) 「No Silver Bullet – essence and accidents of software engineering（銀の弾などない）」
まとめ
システムの構築・運用についてログとどう付き合うべきかをご説明しました。
BizDevOpsにおいて、ログはサービスレベルを担保する上で極めて重要なファクターです。
システム構築・運用の現場において、本コラムが、ログ設計について改めて考えるきっかけとなれば幸いです。
システムのログ設計の見直しを検討される場合はぜひこちらから
富士ソフトBizDevOps
