アルアカ - Arcadia Academia

Arcadia Academiaは「エンジニアリングを楽しむ」を合言葉に日本のデジタル競争力を高めることをミッションとするテックコミュニティです。

ログ設計の基礎とベストプラクティスについて開発に役立つログと運用で必要なログ

Featured image of the post

エンジニアであればログに助けられた経験は多いと思います。何もしなくても勝手にログが湧いてくるわけもなく、ログだって、誰かが設計し出力するべきものを取捨選択しているわけです。

きっとこの記事を読んでいるということはあなたもログ設計しようとしているのでしょう。優れたログは開発を効率化し運用時の障害調査などにも役にたちます。システム開発する人間や運用する人間、それに未来の自分を思い浮かべましょう。ログ設計は、そんな未来の自分とシステムに関わる人への思いやりで出来ています。

それではやっていきましょう!

💡
この記事の対象読者とゴール

■ 対象読者
ログ設計のベストプラクティスについてヒントが欲しい方

■ ゴール
ログ設計の基本を理解しシステムに適したログ設計を考えられるようになること

[目次を開く]

ログ設計とは?

ログ設計は、システムやアプリケーションが生成するログデータの構造や内容を計画・設計するプロセスです。適切なログ設計は、システムの監視、トラブルシューティング、セキュリティの確保、パフォーマンスの最適化に欠かせません。ログは、運用中のシステムの状態や動作を記録する重要な情報源です。

ログ設計の重要性

  1. トラブルシューティング
    • システム障害やエラーが発生した際に、ログを参照することで問題の原因を迅速に特定できます。これにより、ダウンタイムを最小限に抑えることができます。
  2. セキュリティ監視
    • 不正アクセスや攻撃の兆候をログから検出することができます。適切なログ設計は、異常な活動を早期に発見し、迅速な対応を可能にします。
  3. パフォーマンス最適化
    • システムのパフォーマンスを監視し、ボトルネックを特定するためにログは欠かせません。これにより、システムの効率を改善できます。
  4. コンプライアンス
    • 企業や組織は、業界規制や法令に基づいて特定のログを保存・管理する必要があります。ログ設計は、これらの要求を満たすための基盤を提供します。

ログ設計の基本要素

  1. ログの種類
    • ログにはさまざまな種類があります。例えば、アプリケーションログ、システムログ、セキュリティログ、アクセスログなどです。各ログは特定の目的に応じて設計されます。
  2. ログの内容
    • ログに含めるべき情報は、タイムスタンプ、ログレベル、メッセージ内容、ソース(どのコンポーネントから生成されたか)などです。これにより、ログの可読性と有用性が向上します。
  3. ログレベル
    • ログメッセージは、その重要度に応じて分類されます。一般的なログレベルには、DEBUG、INFO、WARN、ERROR、FATALなどがあります。これにより、必要に応じてフィルタリングが可能です。
    ログレベル 内容
    INFO 主に処理結果などの情報
    DEBUG システムの動作に関する情報
    NOTICE 正常ではあるが重要な状態
    ALERT すぐにアクションを起こさなければならない状態
    WARN 警告されている状態
    EMERG システムの利用が不可能
    CRIT 致命的な欠落がある状態
    ERROR エラーが起こっている状態

    上記の表のようにログは、情報と状態に分類されます。

  4. ログフォーマット
    • ログのフォーマットは統一することが重要です。一般的にはJSONフォーマットやテキストフォーマットが使用されます。統一されたフォーマットにより、自動化された解析や監視が容易になります。
  5. ログの保存場所
    • ログは通常、ファイルシステム、データベース、クラウドストレージなどに保存されます。保存場所の選定は、ログの量、アクセス頻度、保存期間に依存します。

ログ設計のベストプラクティス

  1. 一貫性のあるフォーマット
    • ログフォーマットを統一し、全てのシステムコンポーネントで一貫して使用します。これにより、ログ解析が容易になります。
  2. 詳細なログ
    • 必要な詳細情報を含めることが重要です。例えば、エラーメッセージにはエラーコード、発生場所、詳細なスタックトレースなどを含めます。
  3. ローテーションとアーカイブ
    • ログファイルのサイズが大きくなり過ぎないように、定期的にローテーション(古いログを新しいファイルに移動)し、必要に応じてアーカイブ(長期保存)します。
  4. セキュリティ
    • ログファイルには機密情報が含まれることがあるため、適切なアクセス制御と暗号化を施します。
  5. モニタリングとアラート
    • ログをリアルタイムで監視し、異常なパターンやエラーメッセージが検出された場合にアラートを発生させます。

開発と運用のためのログの分類と管理

ここからは少し踏み込んで開発中に必要なログと運用が始まってから必要なログについて考えてみます。

開発中に必要なログ

開発中のログは、主にシステムの動作確認やデバッグ、機能の検証を目的としています。この段階で収集するログは、細かく、詳細な情報が求められます。

1. デバッグログ(Debug Log)

デバッグログは、開発者がコードの実行状況や変数の状態を詳細に把握するためのログです。このログは、コードの特定の部分が正しく動作しているかどうかを確認する際に役立ちます。

  • : 関数が呼び出された際の入力パラメータや処理結果、各ステップの実行状況など。
  • 使用タイミング: 新しい機能を実装した直後や、エラーが発生した際に、その原因を特定するために使用します。

2. エラーログ(Error Log)

エラーログは、システム内で発生したエラーや例外の詳細を記録するためのログです。このログは、バグの修正やシステムの堅牢性を向上させるために重要です。

  • : スタックトレース、エラーメッセージ、エラー発生時のコンテキスト情報。
  • 使用タイミング: 開発中に予期しないエラーが発生した場合、その原因を分析するために使用します。

3. 追跡ログ(Trace Log)

追跡ログは、システム内のプロセスやリクエストの流れを詳細に追跡するためのログです。これは、複雑な処理や分散システムにおいて、リクエストがどのように処理されているかを理解するために役立ちます。

  • : リクエストの開始から終了までのタイムスタンプ、通過した各モジュールやサービスの情報。
  • 使用タイミング: パフォーマンス問題の診断や、特定のリクエストがどのように処理されたかを確認するために使用します。

4. テストログ(Test Log)

テストログは、単体テストや統合テストの実行結果を記録するログです。これは、テストの成否や実行時間、失敗したテストケースの詳細を確認するために使用します。

  • : 各テストケースの開始・終了時間、テストの結果、失敗した場合のエラー内容。
  • 使用タイミング: 自動化テストの実行時に、テスト結果を確認し、必要な修正を加えるために使用します。
運用開始後に必要なログ

運用開始後のログは、システムの安定稼働を維持し、異常や問題を早期に検知・解決するために使用されます。この段階では、リアルタイムの監視や長期的なトレンド分析が重視されます。

1. 監視ログ(Monitoring Log)

監視ログは、システムの健康状態やパフォーマンスをリアルタイムで監視するためのログです。これにより、異常検知やリソースの使用状況を把握し、プロアクティブな運用が可能になります。

  • : CPU使用率、メモリ使用量、ディスクI/O、ネットワークトラフィックなどのメトリクス。
  • 使用タイミング: システムのリソース使用状況やパフォーマンスを監視し、異常が発生した場合にアラートを発生させます。

2. アクセスログ(Access Log)

アクセスログは、ユーザーや外部システムからのリクエストやアクセスの記録です。このログは、ユーザーの利用状況の分析や、セキュリティインシデントの調査に使用されます。

  • : ユーザーのIPアドレス、リクエストのタイムスタンプ、リクエストされたリソース、HTTPステータスコード。
  • 使用タイミング: 利用者の行動を分析し、セキュリティ対策を講じるために使用します。

3. エラーログ(Error Log)

エラーログは、運用中のシステムで発生したエラーや例外を記録するためのログです。これは、運用中の問題を迅速に解決するために不可欠です。

  • : アプリケーションエラー、データベース接続失敗、外部APIの呼び出し失敗など。
  • 使用タイミング: エラーが発生した際に、迅速に原因を特定し、修正を行うために使用します。

4. セキュリティログ(Security Log)

セキュリティログは、システムのセキュリティ関連イベントを記録するログです。不正アクセスの試みやシステムの脆弱性に関する情報を記録し、セキュリティインシデントを未然に防ぐために使用されます。

  • : ログイン試行、認証失敗、権限の変更、ファイアウォールのブロックイベント。
  • 使用タイミング: セキュリティインシデントの監視と、疑わしい活動の検知に使用します。

ログの分類と適切な管理

開発中と運用開始後のログは、それぞれ異なる目的に基づいて設計・管理する必要があります。開発段階では、詳細なデバッグ情報やテスト結果を重視し、運用開始後はパフォーマンス監視やセキュリティに焦点を当てることが重要です。また、以下のポイントを考慮してログ設計を行うと効果的です。

  • ログレベルの設定: ログの重要度や詳細度を設定するために、ログレベル(例: DEBUG、INFO、WARN、ERROR)を適切に活用します。
  • ログの保存期間: ログデータの保存期間をシステムのニーズに応じて設定し、ストレージコストを最適化します。
  • 集中管理と分析ツール: 複数のログを集中管理し、迅速に分析できるツール(例: ELK Stack, Splunk, AWS CloudWatch)を活用します。

ログ設計する際の注意点

情報を取捨選択する

よくある間違いとして、不要な情報まで出力してしまうというものがあります。必要なデータのみ取捨選択するように心がけましょう。

機密情報の取り扱い

機密情報についても注意が必要です。クライアントサイドで出力されないとしても基本的には機密情報はログに含まれないようにした方がよいでしょう。

ローテーションの設計を後回しにしない

すでに運用されているがローテーションまで設計されておらず気付いた時には肥大化したログデータがサーバを圧迫していたなんてこともあったりします。ローテーションの設計を後回しにせず初期段階でしっかりローテーションを組んでおきましょう。

まとめ

効果的なログ設計は、システムの運用管理において極めて重要です。適切なログ設計により、トラブルシューティングが迅速化され、セキュリティが強化やパフォーマンスの最適化が可能となります。ログ設計の基本要素とベストプラクティスを理解し、実践することで、信頼性の高いシステム運用を実現できます。

また既に運用されているシステムのログ設計を見直したいと思っても、ログまわりでよほどクリティカルな問題が起こっていれば別ですが、この手の課題は、予算が通りづらく後回しになりやすいです。

そのため開発段階で細かく設計するようにしましょう。

私が実際に遭遇したログ設計のアンチパターンも紹介するので興味がある方は怖い話として、ぜひ、読んでみてください。

実際に遭遇したログ設計のアンチパターン

とある基幹システムの追加開発+運用保守の案件でのことです。

そのシステムは1系と2系で冗長化されており24時間稼働しているシステムだったのですが、ある日、1系のサーバがダウンしました。原因を調査したところログの肥大化による影響でした。ログ自体は月1回のバッチで別のストレージに圧縮し退避される設計だったのですが、既に2年稼働しているシステムであり、システムがスケールすることを想定した設計ではなく、さらに、ログ自体もアクションログだけではなく、SQLのクエリなどもロギングしており、運用に必要ないような情報も蓄積しているような状態でしたので月1のバッチ処理が走る前にログがサーバを圧迫していたのです。

前述した情報から察することができるかと思いますが、基本的には止められないシステムで起こったことです。迅速に障害報告を作成し解決策をいくつか提案しました。

1.ログを退避する頻度を増やす
2.サーバーのスペックをあげる
3.ログの設計をみなおす

上記の3案です。サーバのスペックをあげるとランニングコストにもろに響くので結果的に1と3を採用することになりました。とはいえ、2と3を実施するのも、もちろん、開発コストはかかります。設計段階から考慮が漏れているとこのようなことが起こり得るのでサービスが止まって慌てて障害調査なんてことにならないように皆さんは気を付けてください。

よくある質問

質問はお問合せより随時、受付中です。

質問をみる

Q: ログ設計とは何ですか?

A: ログ設計とは、システム内で発生するイベントやエラー、パフォーマンスデータを記録・監視するための設計プロセスです。適切に設計されたログは、トラブルシューティングやシステムの改善に役立ちます。


Q: どのような情報をログに記録すれば良いですか?

A: 記録すべき情報には、エラーメッセージ、システムの状態、ユーザーアクション、外部APIのレスポンス時間などがあります。プロジェクトの性質によって適切なログ内容は異なるため、要件を慎重に評価する必要があります。


Q: ログレベルにはどんな種類がありますか?

A: 一般的なログレベルには、DEBUGINFOWARNERRORFATAL があります。それぞれのレベルは、ログに記録するイベントの重要度や詳細度を示しています。設計段階で、どのレベルのログが必要かを明確に定義しましょう。


Q: ログ設計のベストプラクティスは何ですか?

A: ベストプラクティスとしては、以下のポイントが挙げられます:

  • 必要以上に詳細なログを記録しない
  • ログフォーマットを統一する
  • セキュリティに配慮し、個人情報や機密情報を記録しない
  • ログの保管期間や容量を適切に管理する

Q: ログが多すぎる場合の対策はありますか?

A: ログが多すぎると、ストレージや分析が負担になることがあります。フィルタリングやアーカイブ、特定のログレベルのみを保存する設定を利用して、効率的にログ管理を行うことが重要です。


Q: メンタリングプログラムではログ設計にどのようなサポートをしてくれますか?

A: メンタリングプログラムでは、あなたのプロジェクトに最適なログ設計を一緒に考え、システム全体の可視性を高めるための具体的なアドバイスを提供します。また、実際の運用や問題発生時のログ活用方法についてもサポートいたします。ログ設計でお悩みの方は、ぜひメンタリングセッションをご検討ください。


学習を進める中で不安があれば、プロのメンターに相談してみませんか?
無料カウンセリングを試してみる

あなたを爆速で成長させるメンタリングプログラムはこちらから↓↓

転職ボックス|IT/ゲーム業界の正社員求職者の集客の無料会員登録↓↓