概要
最近、エンジニアとして働く中で、logの重要性について痛いほど思い知らされたので、ここにlogの重要性をまとめてみることにしました。
今までは、正常に動くことを目的とした基礎設計にばかり目を奪われ、アプリケーションを長く、安全に運用していくという視点が完全に抜け落ちていました。logは、大きく分けると「正常系」と「異常系」に分けられますが、その中でどのようなlogを残すべきなのか、どうやってlogを観察するのか、自分なりに調べまとめておきます。もし興味があったら最後までお付き合いください。
logの分析が後回しになる３つの理由
近年になって、webアプリケーションが数多くの企業に生産、そして、運用される中でlogはとても重要な位置を占めています。その重要性は大きく分けると二つあると考えられます。
一つ目は、「分析のためのlog。」これは、アプリケーションが多くのユーザーに使用されればされるほど重要性が増します。amazonショッピングなどでは、各ユーザーのlogを取得、分析し、精度の高いレコメンデーションを行ってくれています。
二つ目が、「不正アクセスを検知するためのlog。」これは、サイバー攻撃の検知をいち早く行い、エンドユーザーを守るために使用されます。
このような重要性を持つlogですが、logの取得・分析は後回しにされがちです。では、なぜlogの取得・分析は、後回しにされがちなのか。私の経験上、３つの理由があると考えています。
- アプリケーションの要件定義段階で異常系の設計が抜け落ちてしまっている
- アプリケーションの仕様を満たすために用意されたエンジニアリソースが少なく、開発時間が限られてしまっている
- 膨大に記録されたlogを分析するには、忍耐が求められる
以上の理由となります。
以下でそれぞれについて自分なりに考察していきます。
アプリケーションの要件定義段階で異常系の設計が抜け落ちてしまっている
これは、アプリケーションを開発する前段階です。アプリケーションに求める要求が高く、仕様を設計する人数も限られているときに起こりやすいです。顧客が求める要求がシンプルだということはほぼありません。基本的には、複雑でシステム設計者がシンプルにしていくことを強く求められます。また、顧客はアプリケーションが正常に動くことを前提に話を進めます。どのようなバグが起きるかを想定して対話することは、顧客が熟練のシステム設計者でない限りは難しいでしょう。
アプリケーションの仕様を満たすために用意されたエンジニアリソースが少なく、開発時間が限られてしまっている
これは、アプリケーションを開発段階です。短納期なweb開発を求めらた時に起こりやすいです。競合が増えやすい状況下で、ビジネスサイドの要求は高く、かつ、スピードが求められます。新人エンジニアは特にですが、正常系の動作に気を取られてしまいます。これは、ＱＡエンジニアの話しの中でよく話題に上がることですが、「開発者は、成功させることをモットーに、テスターは、失敗させることをモットーに設計を行う」と言われてます。短納期であることは、この格言をさらに強調させるでしょう。
膨大に記録されたlogを分析するには、忍耐が求められる
これは、開発後のことです。膨大なlogを分析することは、時に人間の認識能力を凌駕することさえあるでしょう。logを取得することに成功したとて、膨大に取得されたlogをいつ、だれだ、どこで、どのように分析するのかが、はたまたそのリソースはあるのか。この問題に取り組めるほどの人的リソースの余裕と思考を持ち合わせることは非常に難しいでしょう。
ではどうすればよいのか
結論から言うと、ログの設計をする時間をとれるように交渉する、以外に解決策はないように思っています。
元も子もない結論ですが、アプリケーションの設計は開発工程における最重要ポイントです。
ウォーターフォールであろうとアジャイルであろうと、（それは設計の粒度と速度の問題であって）設計をしなくて言い訳ではありません。
ログの設計もその例外ではないと思っています。
まとめ
備忘録含めて僕の考えをまとめておきました。
今度はどうやったら良いログの設計ができるかコーディング含めてまとめてみようと思います。
いろいろな考えがあるとは思いますが、何か良い考えがあればご教授いただきたいです。
よろしくおねがいいたします。