[読書メモ]再考・ログ設計 障害に強いアプリケーションのログ出力・管理の極意（Software Design 2026年3月号）

これは何

Software Design 2026年3月号の中の特集の一つである「再考・ログ設計 障害に強いアプリケーションのログ出力・管理の極意」に関する読書メモです

自分自身がちょうどログ分析基盤の構築に関わっていることもあり、改めてログ設計について学び直そうと思い読みました

アプリケーションログをパブリッククラウドでどのように使うのかという観点に重きが置かれていますが、ログ設計全般に応用できる考え方もあるので非常に勉強になりました

なお、本記事では個人的に気になった点や新しい学びがあった点をピックアップしています。割愛してる部分も結構ありますので、気になる方はぜひ購入して読んでみてください。

読書メモ

アプリケーションログの設計原則

• クラウドの発展と普及により、マイクロサービスは構成が当たり前となってきた
  • 同時に、アプリケーションが増えたためログの管理や分析がより重要になってきた
  • 目視確認は無理なため、構造化ログの需要性が増す
• 分析するには、ログ単体ではなくトレースとメトリクスに紐づける必要がある
  • トレースIDとログに含めておくと紐付けができる
  • メトリクスやトレースよりも細かい情報を含める
• 本当に意味のあるログが埋もれないようにログ設計をする必要がある
  • 「いつ」「誰が」「何をして」「どのような状況で」発生したログなのかがわかるようにする
  • セキュリティログの設計のガイダンス：OWASPのロギングチートシート
    • https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
  • OTelが定義しているログレコード
    • https://opentelemetry.io/ja/docs/concepts/signals/logs/#log-record
• どのように出力するのか、だけではなく主力されたログをどうやってログストレージに保存するのかというパイプラインも重要
  • Twelve Factor Appの11番目のベスプラ
    • アプリケーションは標準出力にログを吐き出すのみとする
    • その後の配信と出力先への保存はログルーターに任せる
    • https://12factor.net/logs
  • ECSのログドライバーのブロッキングモードのように、サービス側のマネージドな機能があればアプリケーションからの直接配信もOK
    • https://aws.amazon.com/jp/blogs/news/preventing-log-loss-with-non-blocking-mode-in-the-awslogs-container-log-driver/
• ログのセキュリティにも考慮し、個人情報が含まれないようにする
  • プログラミング言語のライブラリをつかってオーバーライドする方法、ログルーターで機密情報を検知してマスクする方法、保存された後のログを検査する方法、組み合わせる必要がある
  • ただし、機密情報保護に使うコンピュートリソースやコストも考慮する必要あり

構造化ログ戦略

• コンピューターが処理しやすい構造化ログを採用することでログ管理がしやすくなる
  • 従来のsyslogのような非構造化ログは人が読むことを目的に作られている
  • パーサーを使うことでコンピューターが処理しやすい構造にできる、ただしパーサーの運用が手間になる
  • とはいえ非構造化ログが不要ではなく、使い分けするべき
• 構造化ログにおいてはキー設計を考える必要がある
  • キー名にドットが使えるかどうか、追加する項目に使えない名前が無いか、など
  • とはいえ、まずは検索や集計をしてみて経験値を積むことが重要
• ログの編集はアプリケーションのログ出力時に全て行う必要はない
  • とはいえ、アプリケーション固有の処理を行うパーサーなどを別で作ると、それはそれでパーサーの運用コストがかかるため注意

実運用を見据えたログ設計の観点

• 運用を見据えたログ設計で一番大事なのは、「何に、誰が、どのように使用するのか」を見据えた上で、「どのイベントやアクションをどのタイミングで収集するのか」という戦略
  • ログは多すぎても少なすぎてもダメ
  • ログ出力のタイミングも重要
  • 「リクエストや処理1つにつき情報を詰め込んだログを1つ出力する」「関数単位でログを出力する」など、ユースケースに合わせた戦略を取るべき
• ログメッセージには関数名などを入れるのではなく、現実にあった情報（対処法を思い出させるようなメッセージなど）を入れる
• ログ監視はログメッセージに依存しない設計を推奨する
  • ログメッセージは簡単に変更できるため意図しない監視無効化につながる、ログのフィールドに監視用のカテゴリを追加する方が良い

AWSにおけるログ設計／管理

• AWSでログ管理を行う場合は初期投資費用を抑えることができるが、取り込み量や保存量が直接コストに跳ねる
  • 「どこまでをリアルタイム監視し、どこからを低コスト保管に回すか」という観点を持つべき
• 「短期保存はCloudWatch、長期保存はS3」が王道パターン
  • とはいえ、まずは不要なログを出しすぎないようにするのが重要
  • Logs InsightsやAthenaは検索クエリの実行に費用が跳ねるため、クエリコストも考慮する必要がある
• X-Rayなどを使ったトレースでは「いつ困るか」から逆算してサンプリングルールを決めるのが重要
  • トレースIDをログに含めておくことで、トレースから該当処理のログを辿って調査することができる

参考URL：ロギングやオブザーバビリティのベストプラクティス

上記以外にもいろいろな参考URLが掲載されていたので、最後にまとめて記載しておきます

• コンピュータセキュリティログ管理ガイド
  • https://www.ipa.go.jp/security/reports/oversea/nist/ug65p90000019cp4-att/begoj9000000bfnm.pdf
• Logging best practices - AWS Prescriptive Guidance
  • https://docs.aws.amazon.com/prescriptive-guidance/latest/logging-monitoring-for-application-owners/logging-best-practices.html
• AWS Observability Best Practices
  • https://aws-observability.github.io/observability-best-practices/
• Best practices for collecting and managing serverless logs with Datadog
  • https://www.datadoghq.com/blog/manage-serverless-logs-datadog/
• ロギングで技術スタックのすべてを見るベストプラクティス
  • https://newrelic.com/jp/blog/log/log-management-practices
• Logging best practices in an app or add-on for Splunk Enterprise
  • https://dev.splunk.com/enterprise/docs/developapps/addsupport/logging/loggingbestpractices/