Dev Study
← セキュリティとAIの仕組み
レッスン 12 / 13·約 9 分·第4期 セキュリティとAIの仕組み

壊れた後に何をするか — 検知・ログ・封じ込め

リクエストがアプリケーションに届くまで
  1. ブラウザURL入力
  2. DNS名前→IP
  3. ルータ経路選択
  4. ロードバランサ振り分け
  5. Nginx受け口今ここ
  6. アプリ処理今ここ
  7. DB保存

第40〜50週では「なぜ壊れるのか」を見てきました。今週は視点を変えて、壊れた後に手元の記録から何が言えるのかを扱います。

まず結論

壊れた後にまずやることは、原因を当てることではありません。**どこまで届いたのか**を確定させることです。第27週の「どの段が応答を作ったのか」と、まったく同じ問いを使います。

そして記録は万能ではありません。第13週の `strace` も第26週の tcpdump も、**自分が見ている境界を通ったものしか記録しません**。出力が空であることは「起きていない」の証明にはならず、「この境界は通らなかった」までしか言えません。

? 読む前に予測

「利用者からエラーが見えている」と報告が来ました。アプリのログを見ると、その時刻の記録が1件もありません。まず何が言えますか。

当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。

抽象原理

最初の問いは「原因は何か」ではない

真っ先に浮かぶ「原因は何か」という問いは、調べる場所を絞ってくれません。第27週で立てた問いが先に効きます。どの段が応答を作ったのか。 段ごとに見ている情報も権限も違うので、これが分かれば調べるべき設定と記録が絞り込めます。

壊れた後に、範囲を狭める順序
どこまで届いたか第27週の問いをそのまま使う○ 調べる段が決まる
その段に記録はあるか段によって残るものが違う○ 読む対象が決まる
記録が空だった第13週・第26週の読み方○ 「届かなかった」かもしれない
仮説ができてから観測第26週○ ここで初めてフィルタが書ける
↓
原因を当てにいくのではなく、原因がありうる範囲を先に狭める

第26週で見たとおり、キャプチャは仮説を確かめる道具であって、仮説を作る道具ではありません。範囲を絞らず全件記録を取れば、読む量が爆発します。

✓ ここまでの確認

第13週で見た `strace` に、あるシステムコールが1件も出ませんでした。「そのシステムコールは呼ばれていない」と結論できますか。

具体実物

記録が無いことは、何も起きなかったことではない

第13週で見たとおり、vdso(7) のmanページは「vDSOがエクスポートするシンボルはstraceの出力に現れない」と明記しています。vDSO経由の呼び出しはカーネル境界を越えないので、境界を監視している strace には原理的に見えません。同じことが第26週の tcpdump にも当てはまります。

観測器と、その境界の外側表
観測器 見ている境界 映らないもの
strace プロセス / カーネル vDSO経由の呼び出し
tcpdump ホスト / 網 別インタフェース経由の通信
アプリのログ アプリの内側 手前の段が返した応答

3行目が最も誤読されます。

✓ ここまでの確認

「503が返っている」という記録だけを見て、「上流のアプリが落ちている」と判断してよいですか。第36週の内容を踏まえて選んでください。

⇄ 2つを見比べる
具体例 A

アクセスの記録(第27週・第36週)

利用者に見えたエラーと同じ時刻の記録を探します。ただし手前の段が自分で応答を返していれば、その先の記録は残りません。さらに同じ503が、上流の障害からもレート制限からも出てきます。

記録から言えること・言えないこと表
見えたもの 言えること
アプリに記録がある アプリまで届いた
アプリに記録が無い アプリまで届かなかった「かもしれない」
503 が記録されている 上流障害とは限らない(既定のレート制限も503)
具体例 B

strace の出力(第13週)

プロセスがカーネルに出した依頼を記録します。アプリが何の言語で書かれていても、カーネルに頼む以上は記録されます。ただしカーネルに入らない処理は映りません。

記録から言えること・言えないこと表
見えたもの 言えること
呼び出しが出ている そのシステムコールは呼ばれた
呼び出しが出ていない 呼ばれていないとは言えない(vDSO)

アクセスの記録と strace。見ているものはまったく違いますが、壊れた後の使い方としては同型です。共通する構造は何でしょうか。そして、その構造から必ず生じる限界は何でしょうか。

「記録に出ていた」と「記録に出ていなかった」で、言えることの強さが同じかどうかを比べてください。

この章のまとめ

  • 最初の問いは「原因は何か」ではなく、どの段まで届いたのか(第27週)。段が決まれば調べる設定と記録が絞れる。
  • 記録の有無は非対称。 出ていれば「通った」と言えるが、出ていないことは「起きていない」の証明にならない(第13週のvDSO・第26週のキャプチャ)。
  • 同じ値が別の段から出てくる。 limit_req_status の既定は503なので、503だけでは上流障害と決められない(第36週)。
  • 記録を増やす判断には、その記録が何を抱えるかの検討が付く。誤検知のアラートには入力が平文で残る(第38週)。
  • 切り離しは第30週で見た仕組み。値に規定は無く、人間が置いた静的な値で動くことを込みで使う。

自分の現場で確かめる

読んだだけでは身につきません。手元の環境で実際に見てみてください。

環境:

理解度チェック

読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。

問題 1 / 3正解: 0

壊れた後の調査で、最初にやるべきこととして最も適切なものはどれですか。

用語集(2語)
観測器の見える範囲
記録を取る道具には、それぞれ監視している境界がある。`strace` はプロセスとカーネルの境界、tcpdump はホストと網の境界。**境界を通らなかったものは原理的に映らない**ため、出力が空でも「起きていない」の証明にはならない。
どの段が応答を作ったか
第27週で立てた問い。中継役は上流へ取り次がずに自分で応答を返せるので、利用者にエラーが見えていてもアプリのログは空のことがある。壊れた後の調査は、この特定から始める。