ログが追えないWebサービスを調査しやすくする方法

「障害の原因を調べてほしいと開発会社に頼んだら、まず『どのサーバーのログを見ればいいか分からない』と言われた」——これは決して珍しい相談ではありません。サービスを立ち上げた当初はサーバー1台でログもシンプルだったのに、機能が増え、サーバーが分かれ、担当者も入れ替わるうちに、ログがどこに何が出ているのか誰も把握していない状態になっている。そんなプロダクトを、私たちは何度も見てきました。

障害やバグの調査は「ログを見て原因を特定する」作業が土台です。その土台が崩れていると、調査そのものに何時間もかかり、原因が分からないまま応急処置を繰り返すことになります。この記事では、ログが追えないWebサービスによくある問題と、調査しやすくするための具体的な改善方法を、発注者・経営者の方向けに分かりやすく整理します。

なぜ「ログが追えない」状態になるのか

ログが調査に使えない状態には、いくつかの典型パターンがあります。

• サーバーごとにログが個別に存在する: アプリケーションサーバーが複数台あると、ログもサーバーの台数分バラバラに存在します。どのリクエストがどのサーバーで処理されたか分からず、障害発生時に「1台ずつSSHでログインしてログを見て回る」という調査が必要になります。オートスケールでサーバーが増減する構成だと、障害を起こしたサーバー自体が既に消えていて、ログごと失われているケースすらあります。
• grep頼みで検索性がない: ログがテキストファイルとしてサーバー上に置かれているだけだと、調査はgrepコマンドで該当行を探す作業になります。エラーメッセージの一部を覚えていればまだしも、「あるユーザーIDに関するログをすべて追いたい」「特定の時間帯の全リクエストを見たい」といった横断的な調査には向いていません。
• 保持期間が管理されていない: ログローテーションの設定がなく、ディスク容量を圧迫して突然サーバーが不安定になる。逆に、ログが数日で消えるように設定されていて、数週間前に起きた不具合の再現調査ができない。どちらの方向にも設計されていない「なんとなく残っている」状態がよくあります。
• 機密情報がログに混入している: パスワードやクレジットカード情報、個人情報がリクエストログやエラーログにそのまま出力されてしまっているケース。これは調査効率以前に、情報漏えいリスクとコンプライアンス上の問題です。意図せず混入しているケースがほとんどで、誰も気づかないまま長期間ログに残り続けます。
• 構造化されておらず機械的に扱えない: ログが自由記述の文字列として出力されていると、後から「このエラーが何件発生したか」「特定のAPIのレスポンスタイムの分布はどうか」といった集計ができません。人間が目で追う以外の使い方ができない状態です。

これらは個別に発生するというより、サービスが成長する過程で少しずつ積み重なり、気づいたときには「障害が起きても原因調査に半日かかる」状態になっているのが実態です。

調査に時間がかかることの実害

ログが整備されていないことの問題は、単に「調べるのが面倒」という話にとどまりません。

障害対応の初動が遅れれば、サービス停止時間がそのまま長引きます。ユーザーからの問い合わせに対しても「原因を確認中です」としか答えられない時間が伸び、信頼を損ないます。さらに、原因が特定できないまま暫定対応で済ませることが繰り返されると、同じ不具合が形を変えて再発し続けるという悪循環にも陥ります。監視の仕組み自体が無い場合はそもそも障害の発生に気づくのが遅れるという、もう一段手前の問題もあります。この点は監視体制がないWebサービスの改善で詳しく解説していますので、あわせてご覧ください。

また、開発会社を切り替えるタイミングでも、ログ管理の不備は大きな障壁になります。新しい担当チームがまず最初に行うのは「このサービスで何が起きているかを把握すること」ですが、ログが散在していると状況把握そのものに時間がかかり、引き継ぎコストが跳ね上がります。

ログを調査しやすくする改善のアプローチ

私たちが既存サービスのログ整備に着手するときは、次のような順番で進めます。

1. ログ集約基盤の導入

まず、複数サーバーに散らばっているログを1箇所に集約します。CloudWatch Logs、Datadog、Sentry、あるいはOSSのELKスタック(Elasticsearch・Logstash・Kibana)など、サービスの規模やAWS環境との相性に応じて選定します。集約基盤があれば、サーバーを横断してキーワード検索や時系列での絞り込みができるようになり、「1台ずつSSHでログイン」という調査スタイルから脱却できます。オートスケール環境でサーバーが消えても、ログは集約先に残るため調査可能な状態を保てます。

2. 構造化ログへの移行

自由記述のテキストログを、JSON形式などのキーと値を持つ構造化ログに変更します。リクエストID・ユーザーID・処理時間・エラー種別といった情報をフィールドとして出力するようにすることで、「このユーザーIDのログだけ抽出する」「エラー種別ごとに件数を集計する」といった機械的な絞り込みや集計が可能になります。これは大掛かりな改修ではなく、ログ出力ライブラリの設定変更やラッパーの導入で対応できることが多い領域です。

3. 検索基盤・アラートの整備

集約・構造化したログに対して、検索しやすいダッシュボードを用意し、特定のエラーパターンが一定件数を超えたら通知が飛ぶアラートを設定します。これにより「障害が起きてから気づく」のではなく「異常の兆候をログから先に検知する」運用に近づけます。

4. 保持期間の設計

ログの種類ごとに、どのくらいの期間保持すべきかを決めます。アクセスログは短期間で十分な一方、エラーログや監査目的のログはコンプライアンス要件や過去障害の再現調査のニーズに応じて長めに残す、といった使い分けです。合わせてライフサイクルポリシー(古いログを安価なストレージへ移行、あるいは自動削除)を設定し、「無期限に溜まってディスクを圧迫する」「必要な時に既に消えている」の両方を防ぎます。

5. 機密情報のマスキング

ログ出力の実装を確認し、パスワード・トークン・個人情報などがそのまま出力されている箇所を洗い出してマスキング処理を入れます。ログ集約基盤を導入するタイミングは、こうした機密情報混入のリスクを棚卸しする良い機会でもあります。集約先に情報が一元化される分、対策を怠ると漏えい時の影響範囲も大きくなるため、この工程は後回しにせず基盤整備と同時に進めるべき項目です。

外注する際の進め方

ログ管理の整備を外部に依頼する場合、私たちはまず1〜2週間程度で現状のログ出力箇所・保存先・保持設定を棚卸しし、どこにリスクや調査の障壁があるかを可視化するところから始めます。全サーバー・全アプリケーションのログ出力コードを一度に洗い出し、集約基盤への移行と構造化ログ化を段階的に進める、という流れが現実的です。棚卸し後の継続的な整備は保守・運用の一環として、監視体制の構築とあわせて進めることもできます。

この際、既存のコードやインフラ構成に手を入れることになるため、他の改善と同様にまず現状を壊さずに動いている状態を把握してから着手します。既存プロダクト改善全般の進め方については、既存プロダクトの改善、外部チームが最初に見る観点にまとめていますので、あわせてご覧ください。インフラ構成そのものの見直しが必要な場合は、インフラの構成整備とあわせて進めることもあります。

まとめ

• ログが追えない状態は、サーバーごとの散在・grep頼みの検索性・保持期間の未設計・機密情報の混入・非構造化という複数の要因が積み重なって生まれる
• 調査に時間がかかることは障害対応の初動の遅れや信頼低下に直結し、開発会社の切り替え時の引き継ぎコストも押し上げる
• ログ集約・構造化ログ化・検索基盤とアラートの整備・保持期間の設計・機密情報のマスキングという順で段階的に取り組むことで、調査しやすい状態に改善できる

torcheees では、既存プロダクトのログ管理を含む運用面の開発診断、継続的な改善が必要な場合は継続的な改善支援を提供しています。障害調査に時間がかかっている、ログがどこにあるか把握できていないといったお悩みがあれば、まずは現状の棚卸しから一緒に進められます。お問い合わせフォームからお気軽にご相談ください。