Dev Study
← Webを支えるソフトウェア
レッスン 13 / 13·約 9 分·第3期 Webを支えるソフトウェア

無停止で入れ替える — そして期末の切り分け

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

第3期の最終週です。個々の仕組みを足すのではなく、27〜38週で見た段を並べ直して「どこが決めたのか」を言えるようにします。

まず結論

設定の反映は「再起動」ではありません。**入れ替え**です。古いワーカーは処理中の接続を捌き切ってから終わるので、その間は新旧が同居します。

第3期の締めくくりとして、**どの段が決めたのかを切り分ける**問いを置きます。27〜38週で見てきた各段は、それぞれ別のものを見て別の判断をしていました。

? 読む前に予測

nginx に設定のリロードをかけた瞬間、処理の途中だったリクエストはどうなるでしょうか。

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

抽象原理

止めるのではなく、入れ替える

設定を変えたあと、それを反映させる操作は「再起動」と呼ばれがちです。しかし実際に起きているのは入れ替えです。

新しい設定のワーカーが立ち上がり、古いワーカーは処理中の接続を捌き切ってから終了します。処理中のリクエストが一律に切られる再起動とは、ここが違います。公式によれば、古いワーカーは listen ソケットを閉じ、既存のクライアントを捌き終えてから終了します。上限は worker_shutdown_timeout(1.11.11〜)で決められますが既定値は無く、長い接続があれば古いワーカーは残ります。

この違いは言葉の綾ではなく、切り分けに直結します。反映の途中では、新旧の設定が同居するからです。「設定を変えたのに古い挙動が見える」は、異常とは限りません。入れ替えが終わっていないだけ、という正常な経過でも同じ症状になります。ここで反射的に再起動をかけると、切れないはずの接続を自分で切ることになります。

✓ ここまでの確認

設定を変更してリロードしたのに、一部のリクエストで古い挙動が見えています。まず疑うべきことはどれですか。

具体実物

第3期の切り分け — どの段が決めたのか

第3期で見てきた各段は、それぞれ違うものを見て、違う判断をしていました。症状から原因へ遡るには、この対応を持っておくのが近道です。

各段が見ているものと、決めていること表
段 何を見ているか 何を決めるか
配り先の選択(29-30) 実体の状態 どの実体へ送るか
location (31) 正規化後のURI どの設定を適用するか
proxy_pass (32) location との一致部分 上流に渡すURI
キャッシュ (35) 鍵と鮮度(age) 上流に聞くかどうか
レート制限 (36) 単位時間あたりの数 遅らせるか拒否するか
WAF (37-38) 中身(ペイロード) 通すか遮断するか

並べると、レート制限とWAFの違いがはっきりします。片方は量で止め、もう片方は中身で止める。同じ「止める」でも判断の材料が別です。

そして切り分けを難しくするのが、症状と段が1対1でないことです。たとえば503は、上流が応答しないときにも、レート制限が拒否したときにも現れます(nginx の拒否コードの既定は503でした)。ステータスコードだけを見て段を決めつけると、最初から線を1本落とすことになります。

✓ ここまでの確認

「あるURLだけ意図した設定が効かない」とき、第31週で学んだことから最初に確かめるべきことはどれですか。

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

nginxの設定リロード(第39週)

新しい設定のワーカーを立ち上げ、古いワーカーには処理中の接続を捌き切らせます。捌き終わるまで古いワーカーは生きているので、その間は新旧の設定が同時に動いています。

入れ替えの経過表
1. 新しい設定でワーカーを起動
2. 新規の接続は新しいワーカーへ
3. 古いワーカーは処理中の接続を継続
4. 捌き終わった古いワーカーから終了
具体例 B

プロセスのグレースフルシャットダウン

終了の合図を受けたプロセスが、その場で落ちずに処理中の仕事を終わらせてから終了します。第12週は終了の作法までは扱っていないので、比較のために足します。

終了の経過表
1. 終了の合図を受け取る
2. 新規の受け付けをやめる
3. 処理中の仕事を続ける
4. 終わったら自分で終了する

2つはよく似た経過をたどります。では、この2つは何のために同じ仕組みを使っているのでしょうか。目的の違いはどこに出ますか。

経過が終わったあと、そこに何が残っているかを比べてください。

この章のまとめ

  • 設定の反映は再起動ではなく入れ替え。古いワーカーは処理中の接続を捌き切ってから終了する。
  • だから反映の途中は新旧が同居する。「古い挙動が見える」は異常とは限らず、経過のこともある。
  • 各段は別のものを見て別の判断をしている。レート制限は量で、WAFは中身で止める。
  • 症状と段は1対1ではない。 503は上流の不調でも、レート制限の拒否(nginx既定)でも現れる。
  • 第3期に共通した崩れ方は、出典や層の違うものがひとまとまりの常識として語られること。確認の単位は「どの文書のどこに、どう書かれているか」。

自分の現場で確かめる

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

環境:

理解度チェック

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

問題 1 / 4正解: 0

「リロードはダウンタイムを伴うので、再起動と実質同じである」という説明は妥当ですか。

用語集(3語)
リロード(設定の再読み込み)
新しい設定でワーカーを立ち上げ、古いワーカーは処理中の接続を捌き切ってから終了する入れ替えの操作。処理中のリクエストを一律に切る再起動とは区別する。反映の途中では新旧のワーカーが同居しうる。
グレースフルシャットダウン
処理中の仕事を終わらせてから終了すること。リロードが「入れ替え」のためにこれを使うのに対し、シャットダウンは文字どおり**止める**ために使う。
切り分け
症状から原因の段を絞り込むこと。同じ症状(たとえば503)が複数の段の別々の判断から出るため、症状と段を1対1で結ばないことが要点になる。