- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理今ここ
- DB保存
第7期でアプリを2プロセスにすると何が起きるかを見ました。今回はそれを「台数が増えると何が始まるか」として一般化します。
まず結論
1台で動かしている間、故障は「全部動く」か「全部止まる」かのどちらかでした。部品が運命を共にしているからです。
2台目を置いた瞬間、片方だけが落ちる・片方だけが遅い、という今まで無かった状態が生まれます。ここから状態の置き場・順序・故障の判定という3つの問いが始まります。
アプリを1台から2台に増やしたとき、1台のときには存在しなかった状態が生まれます。それは何でしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
1台のとき、故障は全部か無かだった
第7期『状態を持たないHTTPとCookie/セッション』で、アプリを2プロセスにするとセッションが引き継げないことを見ました。結論は「状態をどこかに置く義務からは逃げられない」でした。今回はそこを出発点に、台数が増えたときに何が新しく始まるのかを一般化します。
まず増える前の話から。1台で動かしているとき、故障の型は驚くほど少なくてすみます。AWS の文書はその理由をこう書いています。
If these failures do happen, it's safe to assume that everything else will fail too. Technically, we say that they all share fate. Fate sharing cuts down immensely on the different failure modes that an engineer has to handle.
CPUが焼き切れた機械の上で、メモリだけが正常に働き続けることはありません。部品が運命を共にしているので、結果は「全部動く」か「全部止まる」かの2通りに畳まれます。同じ文書は、そうした故障を扱うコードは「概念的にすら書けない」とも述べています。
2台目を置くと、運命が分かれる
同じ文書は、2台目以降がそうでないことをこう書きます。
the servers and the network do not share fate. Unlike the single machine case, if the network fails, the client machine will keep working. If the remote machine fails, the client machine will keep working
呼び出した側は動き続けます。つまり「相手がどうなったか」を扱う側に回ります。
構成 取りうる状態1台 全部動く / 全部止まる2台 両方動く / 両方止まる / Aだけ止まる / Bだけ止まる / 片方が遅い
下の行の後ろ3つが、1台のときには存在しなかった状態です。本コースではこの「一部だけが壊れ、残りは動き続けている」状態を部分故障と呼びます。本コースの呼び名で、AWS の文書にも、本レッスンで引いた Google SRE Book の章(The Production Environment at Google)にも出てきません。原文が使うのは fate sharing と fault domain です。
1台で動かしているとき、CPUが壊れたらアプリも一緒に止まります。この性質を AWS の文書は英語で何と呼んでいますか。
増やす目的は台数ではなく、運命の単位を分けること
台数を増やす目的を「性能」や「可用性」と説明すると、大事な条件が落ちます。Google SRE Book は Borg の配置についてこう書いています。
Borg won't run all of a job's tasks on the same rack, as doing so means that the top of rack switch is a single point of failure for that job
2台に増やしても、同じラックに置けば運命は分かれていません。 分けたいのは台数ではなく、まとめて壊れる範囲です。AWS はこれを fault domain、SRE Book は failure domain と表記します。第8期『クラウドは他人のコンピュータ — リージョンとAZの物理』で見たAZの分け方も、この単位の話でした。
分けた結果として、3つの問いが同時に始まります。
- ・3つは独立ではなく、判定ができないことが順序と置き場の難しさを押し上げる
- ・1台のときはどれも問いとして立たなかった
3つ目が一番やっかいだと分かる場面
3つのうち、判定だけは性質が違います。同じ文書がこう書いています。
What's worse, it's impossible always to know whether something failed.
呼び出した側に届くのは「応答が返ってこない」という1つの事実だけです。これが少なくとも3つの原因に対応します。
原因 相手の状態 送った処理相手が停止している 止まっている 実行されていない相手が遅いだけ 動いている 実行中かもしれない経路が切れている 動いている 実行済みかもしれない
1台のときは関数呼び出しだったので例外が直接返り、この曖昧さは生じませんでした。第3期『死活監視 — 壊れた実体を外す仕組み』で見た仕組みは、この曖昧さを前提に「外す・戻す」の運用を決めるものでした。なぜ判定が原理的に難しいのかは本コース4本目、送った処理をもう一度送ってよいのかは6本目で扱います。
アプリ2台とロードバランサという構成で「相手が落ちた」と判定するのが難しいのはなぜですか。
アプリを2台にする
1台ではその機械が止まればサービスも止まります。2台なら片方が止まっても他方が応答します。ただし片方だけが持つ情報があると、どちらに振られたかで結果が変わります。
台数 止まったときの結果 新しく生まれる状態1台 サービス全体が止まる なし2台 片方は応答し続ける どちらに振られたかで結果が変わる
DNSの権威を複数置く(第9期)
権威が1台だと、落ちた時点でゾーン全体が引けません。複数台にすれば1台落ちても引けます。ただし各台が同じ中身を持つ保証は自動では付かず、揃える仕掛けが別に要ります。
台数 止まったときの結果 新しく生まれる状態1台 ゾーンが引けない なし複数台 残りの台から引ける どの台に聞いたかで中身が違いうる
アプリの台数を増やすことと、DNSの権威を増やすこと。扱う中身はまったく違いますが、増やした瞬間に共通して生まれるものは何でしょうか。
「増やして良くなったこと」ではなく、「増やす前には存在しなかった問い」の方に注目してください。
この章のまとめ
- 1台のとき、部品は運命を共にしている。AWS の文書はこれを fate sharing と呼ぶ。だから故障は「全部動く」か「全部止まる」かに畳まれる。
- 2台目を置くと運命が分かれ、片方だけが止まる・片方だけが遅い状態が生まれる。本コースではこれを部分故障と呼ぶ。
- 増やす目的は台数ではなく、まとめて壊れる範囲を分けること。
- ここから状態の置き場・順序・故障の判定の3つが始まる。残りの12本はこの3つへの答え。
- 中でも判定は性質が違う。「応答が返らない」という1つの観測に、停止・遅延・経路断が対応する。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
「1台のときは故障が全部か無かだった」のは、なぜですか。
用語集(4語)
- fate sharing(運命の共有)
- 一方が壊れたら他方も必ず使えなくなる関係。AWS の文書が使う語。1台の中の部品どうしがこれにあたる。
- fault domain / failure domain(故障の単位)
- まとめて壊れる範囲。AWS は fault domain、SRE Book は failure domain と表記する。
- single point of failure(単一障害点)
- そこが壊れると全体が止まる1点。SRE Book はラック上部のスイッチや配電を例に挙げる。
- 部分故障
- 一部だけが壊れ、残りは動き続けている状態。本コースの呼び名で、AWS の文書と本レッスンで引いた SRE Book の章には無い語。