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

リバースプロキシ — なぜ自分で返さず取り次ぐのか

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

第27週で全体地図を見ました。今回はその中の1段、「自分で答えず、奥へ取り次ぐ」段がなぜ置かれるのかを扱います。

まず結論

取り次ぎ役を1段挟むと、外から見える窓口と、実際に処理する実体とを切り離せます。窓口の側で受け口の規則を決められるので、実体を触らずに配置や経路を変えられます。

ただし「取り次ぐこと」と「どの実体へ配るか決めること」は別の関心事です。同じソフトウェアが両方を担うことが多いだけで、同じ機能ではありません。

? 読む前に予測

取り次ぎ役(リバースプロキシ)と、配り先を選ぶ役(ロードバランサ)の関係として、最も正確なものはどれでしょうか。

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

抽象原理

窓口と実体を切り離す

第27週で見たとおり、リクエストはアプリに届く前に何段かの手を経ます。その中に「自分で答えず、奥へ取り次ぐ」段があります。なぜわざわざ1段挟むのでしょうか。

**窓口と実体を切り離せるからです。**外から見えるURLと、実際に処理しているプロセスの配置を、別々に決められるようになります。

取り次ぎ役を挟むと、窓口と実体が分かれる
クライアントが知っているのは窓口だけ
受け取る
取り次ぎ役どの規則で処理するかを決める
取り次ぐ
実体(上流)配置も数もクライアントは知らない
  • ・窓口の見え方は取り次ぎ役の設定側にある
  • ・実体を移しても、窓口を変えずに済む

この切り離しが効くのは、受け口の規則が取り次ぎ役の設定に書かれているからです。どのパスをどう扱うかは第31週で、上流へ何を渡すかは第32週で扱います。

✓ ここまでの確認

取り次ぎ役を挟むと、上流のアプリが受け取るURIは、クライアントが送ったURIと必ず同じになりますか。

具体実物

窓口のパスと、実体が受け取るパスは別物になりうる

取り次ぎは「そのまま流す」ことではありません。nginx の proxy_pass は、書き方ひとつで上流に渡るパスを変えます。

実機(nginx/1.30.4)で上流が受け取ったURI表
窓口で受けたURI proxy_pass の書き方 上流が受け取った
/api/users http://127.0.0.1:9001/ /users
/noslash/users http://127.0.0.1:9001 /noslash/users

同じ「取り次ぎ」でも、上流が見るパスが違います。クライアントが叩いたURLと、アプリのログに出るパスが一致しないのは、取り次ぎ役を挟んだ構成では当たり前に起こります。詳しい規則は第32週で扱います。

✓ ここまでの確認

取り次ぎ役を挟むことで得られる利点の説明として、適切なものはどれですか。

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

取り次ぎ役(リバースプロキシ)

クライアントは回線の細さも読み込みの速さもばらばらです。取り次ぎ役が間に立つことで、上流のアプリは個々のクライアントと直接やりとりせずに済みます。アプリは取り次ぎ役を相手にするだけでよく、その先の事情から切り離されます。

誰が誰を相手にしているか表
やりとりする相手 速さの事情
クライアント ⇔ 取り次ぎ役 ばらばら。遅い相手もいる
取り次ぎ役 ⇔ 上流のアプリ アプリはこちらだけを相手にする
具体例 B

TCPの受信バッファ(第24週)

受信側にはデータを貯めておく受信バッファがあり、アプリケーションがそこから読み出します。送信側はアプリの読み出しを待たずに送れますが、無制限ではありません。バッファの空きは rwnd としてTCPヘッダのWindowフィールドで広告され、読み出しが滞れば縮み、その変化もそのまま伝わります。

緩衝が効いている間と、埋まったとき表
受信アプリの読み出し バッファの空き(rwnd) 送信側
順調に読んでいる 空きがある 送り続けられる
滞っている 縮む 広告された分しか送れない

取り次ぎ役と、TCPの受信バッファ。速さの違う2者の間に何が置かれていて、それは何を可能にし、どこまでを保証しないでしょうか。

「遅い側が詰まったとき、速い側はいつまで自由でいられるか」を両方で考えてみてください。

この章のまとめ

  • 取り次ぎ役を挟む目的は、外から見える窓口と、実際に処理する実体を切り離すこと。実体を移しても窓口を保てる。
  • 受け口の規則は取り次ぎ役の設定側にあるため、窓口のパスと上流が受け取るパスは別物になりうる(第32週)。
  • 「取り次ぐ」と「配り先を選ぶ」は別の関心事。 同じソフトウェアが両方を担うことが多いだけ。
  • 間に立つことで速度差のある2者を切り離せるが、緩衝は有限。第24週の受信バッファと同じく、吸収できるのは一時的な速度差であって、遅い側の影響が消えるわけではない。
  • 取り次ぎ役を置いた事実だけで奥が安全になるわけではない。受け口が1か所に集まるので検査を置けるようになる、というのが正確な言い方(第36〜38週)。

自分の現場で確かめる

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

環境:

理解度チェック

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

問題 1 / 3正解: 0

「リバースプロキシとロードバランサは同じものだ」という説明の評価はどれですか。

用語集(3語)
リバースプロキシ(取り次ぎ役)
クライアントからのリクエストを受け取り、奥の実体へ取り次ぐ役。外から見える窓口と、実際に処理する実体とを切り離す。取り次ぎ先が1つでも成立する。
上流 (upstream)
取り次ぎ先の実体。nginx の設定でもこの語が使われ、`proxy_pass` に取り次ぎ先を書く。
取り次ぎと配り先選択の区別
「受け取って奥へ渡す」ことと「複数の実体のどれへ渡すか決める」ことは別の関心事。同じソフトウェアが両方を担うことが多いが、同じ機能ではない。