ネットワーク / Web
リクエストが届くまでに何が起きているか
ブラウザの URL 欄に文字を打ってから画面が出るまで、名前解決・接続確立・暗号化・キャッシュという4つの関門がある。障害調査で「どこまでは届いているのか」を切り分けられるかは、この層を絵で描けるかどうかで決まる。
読み終わると、これに答えられるようになります
- ?DNS の TTL を短くすると何が起きるのか
- ?HTTP/2 にしたのにページが速くならないのはなぜか
- ?CDN のキャッシュが消えないとき、どこを疑うか
DNS — 名前からIPアドレスにたどり着くまで
ブラウザが example.com を数字の住所に変換する経路と、その途中に置かれたキャッシュがなぜ事故の原因になるのか。
TTL を確認せずにサーバーを切り替え、旧サーバーに丸一日アクセスが流れ続けた
TCP/IP — データが相手に届くまでの4層
アプリが送った1行の文字列が、どう包まれて、どう運ばれ、どう元に戻るのか。障害の切り分けはこの層の把握から始まる。
「サーバーが落ちている」と報告したが、実際は SYN が返らないだけでプロセスは生きていた
HTTP/1.1 → 2 → 3 — 何が遅くて、何を直したのか
バージョンが上がるたびに解かれてきたのは「待ち」の問題。どの待ちがどこで消えたかを知らないと、HTTP/2 にしても速くならない。
HTTP/2 対応したのに表示が速くならず、ドメイン分割の設定がそのまま残っていたのが原因だった
TLS — 盗聴・改ざん・なりすましを同時に防ぐ
HTTPS の鍵マークが保証しているのは3つ。何を保証していて、何を保証していないのかを分けて理解する。
証明書の期限切れで全社のサービスが停止。監視していたのは死活だけで、有効期限は誰も見ていなかった
CDN — 利用者の近くに置いて、オリジンを守る
配信を速くする仕組みであると同時に、オリジンへのアクセスを減らす仕組みでもある。キャッシュキーの設計を誤ると、どちらも機能しない。
CDN が Cookie をキャッシュキーに含めておらず、他人のログイン後の画面が配信された
キャッシュ戦略 — いつ捨てるかを設計する
キャッシュを置くのは簡単で、正しく捨てるのが難しい。max-age・ETag・stale-while-revalidate の使い分けを判断軸から組み立てる。
緊急修正をデプロイしたのに、1年キャッシュされた JS のせいで利用者に届かなかった