ログ管理基盤の設計方法

目的と要件を数値で決める

ログは「なんとなく全部集める」と破綻します。まず用途を棚卸しし、SLOとコスト上限を数値化します。用途は大きく、インシデント解析（分単位の深掘り）、監査証跡（改ざん耐性・長期保存）、プロダクト改善（傾向分析）、SREの可観測性（相関・トレース連携）に分かれます。用途ごとに以下を決めます。

• 取り込み遅延SLO：例）P95で90秒以内
• 検索SLO：例）P95で2秒、最大スキャン1日分
• 保持期間：例）障害対応は14日、監査は365日、デバッグは7日
• 1日の増分量：例）600GB/day（ピーク1.5倍を考慮）
• コスト上限：例）ingest 3円/GB、保存 1.2円/GB-month
• 機密区分とアクセス制御：PIIの有無、チーム単位のRBAC

決めたら「ログ分類表」を作ります。ソース（アプリ、Webサーバ、DB、OS）、重要度、想定クエリ、保持ティア（Hot/Warm/Cold/Archive）、所有者、削除条件を1枚にまとめ、例外は表に追記するだけにします。これが後工程の分岐（パイプライン、インデックス、保存先）を機械的に決める鍵になります。

収集パイプラインとスキーマ設計のコツ

収集は「落とさない・詰まらない・読める形に整える」が原則です。エージェント（例：軽量フォワーダ）でJSON Linesに正規化し、ローカルディスクに数分〜数時間のバッファを持たせ、再送で少なくとも一度（at-least-once）を担保します。ネットワークはTLS、可能ならmTLS、圧縮はgzipやzstdで帯域を削減します。スパイク対策にレート制御とバックプレッシャーを入れ、あふれ時のドロップ基準も明記します（監査系はドロップ禁止、デバッグ系は古い順に破棄など）。

識別子の設計が検索効率を決める

スキーマは共通化します。最低限、timestamp（RFC3339）、severity、service.name、env（prod/stg）、host、cluster、message、trace_id/span_id、request_idを持たせます。アプリにはX-Request-Idを発行・伝播し、リバースプロキシやジョブキューでも引き継ぎます。ユーザー関連は直接IDを入れず、不可逆ハッシュ（ソルト付き）で検索可能な擬似IDにします。フィールド名はチーム横断で統一し、動的フィールドの氾濫を避けるため「labels.*」配下に逃がすと破綻しにくいです。

個人情報とセキュリティを収集側で完結させる

メール、電話、住所、クレカっぽいパターンは収集側でマスキングかトークナイズを行います。アプリ改修が難しい場合は、エージェントのフィルタで正規表現置換をかけます。監査要件がある場合は、改ざん検知用にハッシュチェーンや署名を付与し、保存先とは別系統に転送ログを残すと説明責任が立てやすくなります。

保管・検索アーキテクチャをユースケース別に

万能ストアは存在しません。用途で分けます。

• 探索・全文検索中心（障害対応）：検索エンジン型ストア。日次の時系列インデックス、Hot/Warm/Coldの階層化、サイズ/期間ロールオーバーを基本にします。1シャード20〜50GB目安で日量から逆算し、マッピングは必要フィールドのみkeyword化してカーディナリティ爆発を防ぎます。
• 集計・トレンド中心（プロダクト分析）：列指向の高速集計基盤。日付パーティション＋service.nameやuser_hashでクラスタリングし、頻出クエリをマテビュー化してP95を1秒台に。
• 長期アーカイブ（監査・再解析）：オブジェクトストレージに圧縮保存。遅延容認でクエリする場合は外部テーブルやサーバーレスSQLを使い、ストレージクラスは30/90/180日で段階的に廉価層へ移行します。
• ストリーミング連携（リアルタイム検知）：メッセージブローカを経由し、同一ストリームを検索系と集計系にファンアウト。ルールエンジンでしきい値検知やパターン照合を行います。

共通の最適化として、よく使うフィルタ列（env、service、severity、request_id）はインデックス化し、不要フィールドは取り込み時に破棄します。保存時は圧縮を有効にし、サンプリング（例：infoは10%）を検討します。ただし監査と課金はフル保持を原則に。

バックアップはスナップショットをオブジェクトストレージへ日次で取得し、月1回は復元リハーサルを回します。DRは別リージョンへ非同期レプリカ、RPO/RTOを要件表に明記して運用が選べるようにします。

身近な企業活用例と運用の勘所

当初はアプリとWebサーバのログを全文検索基盤に7日分すべて投入（約1TB/day）。動的マッピングでフィールドが爆発し、クエリは10秒超、月次コストも想定の1.8倍。障害時の相関も取れず、深夜のアラートが乱発しました。

改善では、ログ分類表を作成しHot2日/Warm14日/Archive180日を定義。スキーマを統一し、X-Request-Idとtrace_idを必須化、メールと電話は収集側でマスキング。探索系はHotのみ全文検索、Warmは圧縮重視、長期はオブジェクトストレージ＋サーバーレスSQLに退避。プロダクトKPIは列指向基盤へ別経路で投入。結果、P95検索2秒、取り込み遅延60秒内、保存コスト30%削減、オンコールは週2件→週0〜1件に減少。定常の誤検知は、ルールを「5分間に同一serviceでerror率>1%かつrequest数>100」に調整して抑止しました。

運用では、チームごとにプレフィックスで論理分離しRBACを適用、監査系は書き込み専用キーを分離。メタ監視として「取り込み遅延」「ドロップ率」「変換失敗率」「トップN重いクエリ」を可視化。ランブックは「高遅延時はWarm→Cold移行を一時停止」「インデックス膨張時はマッピング見直し→ラベル退避」のように手順と判断基準をセットで残します。日々の解析や整形ルール作成には生成AIの補助も有効です。例えば、Copilotでパイプライン定義の雛形を作り、ChatGPTやClaudeでエラーログの要約や正規表現の検査を行い、Geminiでダッシュボード説明文やアラート文面の明瞭化を支援すると、運用手戻りが減ります。

ログ基盤はサーバ監視の土台であり、収集・スキーマ・保存・運用を用途別に分解し、数値化したSLO/コストで管理すると持続可能になります。サーバ監視運用事業の現場でも、この型に沿うことで「見たいときに、すぐ、確実に」見える状態を長く保てます。