- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け今ここ
- Nginx受け口今ここ
- アプリ処理
- DB保存
第3期の初回です。第2期では宛先のホストへ届くまでを見ました。今回はその先、ホストに届いた後にアプリへ渡るまでの段を地図にします。
まず結論
ブラウザからアプリまでの間には、いくつもの中継役がいます。各段は自分の担当する情報だけを見て次へ渡し、その内側には踏み込みません。第2期で見た層の構造が、そのまま装置の並びとして現れます。
第3期で扱うのは、この途中の段が「何を見て何を決めているか」だけです。各段には自分で答えを返す権限もあり、リクエストがアプリまで届かないことも珍しくありません。
ブラウザで表示されたエラー画面に「502」と出ていました。この応答を作ったのは誰でしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
ブラウザとアプリの間には、何段もの手がある
第2期では、宛先のホストまで荷物が届く仕組みを見ました。第3期が扱うのはその先です。ホストに届いたリクエストは、アプリにたどり着くまでにさらに何段もの手を経ます。
- ・どの深さまで開けて見るかが、段によって違う
**この形は第2期で見た層そのものです。**層とは入れ子の一段一段で、各段は自分の宛名だけを見て次へ渡し、内側には踏み込みません。装置の並びも同じ構造をしています。
違うのは開ける深さです。ルータは宛先IPアドレスだけを見て次の行き先を決め、その内側が何の通信かを知りません。Nginx はさらに内側のHTTPまで開けて、パスを読んで処理を決めます。
第2期で見たルータと、今回扱う中継役(ロードバランサやNginx)は、見ている情報がどう違いますか。
途中の段は、自分で応答を返せる
ここが全体地図で最も重要な点です。**中継役は右から左へ流すだけの存在ではありません。**自分で応答を作って返す権限を持っています。
具体例が第32週で扱う nginx の規定です。location がスラッシュで終わる前置文字列で定義され、proxy_pass 等で処理される場合——
In response to a request with URI equal to this string, but without the trailing slash, a permanent redirect with the code 301 will be returned to the requested URI with the slash appended.
スラッシュを付けたURIへの301を、nginx が自分で返します。上流のアプリには何も届きません。
この事実の帰結はこうです。アプリのログに何も出ていないのに、利用者にはエラーや予期しない遷移が見えている——これは異常ではなく、途中の段が答えた場合の正常な姿です。
各段が「自分の担当する情報だけを見て次へ渡す」構造は、第2期のどの考え方と同じですか。
リクエストが通る中継役
ブラウザのリクエストは、アプリに届く前に中継役を通ります。中継役は設定に従ってパスを見て、上流へ取り次ぐか、自分で応答を返すかを決めます。上流に届かないまま完結することがあります。
応答した段 アプリのログ 利用者に見えるものアプリ 残る アプリが作った応答中継役(301など) 残らない 中継役が作った応答
システムコールの特権境界(第13週)
アプリはファイル操作や通信を自分で行えず、必ずカーネルに依頼します。カーネルは依頼を受け取って実行しますが、正当でなければ拒否してエラーを返します。依頼がハードウェアに届かないまま終わることがあります。
判断した側 ハードウェア操作 アプリが受け取るものカーネル(実行) 行われる 実行結果カーネル(拒否) 行われない エラー
HTTPの中継役と、カーネルの特権境界。まったく別の話に見えますが、共通する構造は何でしょうか。
「依頼したのに、その先まで届かなかった」場合に何が起きるかを、両方で考えてみてください。
この章のまとめ
- ブラウザからアプリまでには何段もの中継役があり、各段は自分の担当する情報だけを見て次へ渡す。第2期の層と同じ構造。
- 違うのは開ける深さ。ルータは宛先IP、Nginx はHTTPのパスまで見る。
- 中継役は自分で応答を作って返せる。 nginx には末尾スラッシュ無しURIへ301を返す規定があり、この場合アプリには届かない。
- だから切り分けの第一歩は「どの段が応答を作ったのか」の特定になる。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
「リクエストは必ずアプリケーションまで届いてから、応答が返ってくる」という理解の評価はどれですか。
用語集(3語)
- 中継役(intermediary)
- クライアントとアプリの間に立ち、リクエストを受け取って取り次ぐソフトウェアや装置の総称。単に転送するだけでなく、自分で応答を作って返すこともできる。
- 上流 (upstream)
- 中継役から見て、リクエストを取り次ぐ先。nginx の設定でもこの語が使われる。「上流が受け取ったURI」といえば、中継役が書き換えた後のURIを指す。
- 段(この教材での言い方)
- リクエストが通る経路上の1つの中継点。第2期で扱った層と同じく、各段は自分の担当する情報だけを見て次へ渡す。どの深さまで開けて見るかは段によって違う。