HTTP/2導入とハイブリッドクラウドの設計

読み：えいちてぃーてぃーぴーつーどうにゅうとはいぶりっどくらうどのせっけい　／　英語表記：HTTP/2 and hybrid cloud web system design

Webシステムの一部をクラウドへ移し、HTTP/2で利用者との通信を効率化するための設計である。通信方式を変えるロードバランサの終端と、クラウドと社内を結ぶ往復の経路を区別して検討する。

イマシルちゃんの解説

Webページを開くと、本文だけでなく画像やプログラムも取りに行くよ。
そのやり取りを一つの接続の中で同時に進められるのが、HTTP/2というWeb通信のプロトコルなんだ。
ただし、入口をHTTP/2に変えたからといって奥のサーバまで同じ方式になるわけではないよ。
手前のロードバランサが要求を受け取り、別の方式でサーバへ送り直す構成もあるんだ。
サーバの一部をクラウドへ移して社内の環境と組み合わせる構成は、ハイブリッドクラウドの一例だよ。
この場合はクラウドから社内へ要求を送るだけでなく、応答が戻れることも確かめよう。
どこで接続を区切るかと、その先まで通信できるかを分けて考えると、移行後の通信の問題も絞りやすいんだ。

より深い解説

全体を一つの通信として扱わない

Webシステムを更改するときは、利用者からデータベースまでを一本の接続として考えない。ブラウザの要求を受け付ける装置、静的なファイルを返すサーバ、業務処理を行うアプリケーションサーバでは役割が異なる。

ハイブリッドクラウドは、社内などで管理する環境とクラウドを組み合わせる構成である。例えば画像を配信するWebサーバをクラウドへ移し、業務処理は社内に残すことができる。この場合はクラウド内だけでなく、両環境を結ぶ回線と戻り経路もサービスの一部になる。

区間	主な確認事項
ブラウザからロードバランサ	名前解決、公開アドレス、TLS、利用するHTTPの版を確認する
ロードバランサからWebサーバ	転送先、バックエンド用のHTTPの版、監視方法を確認する
クラウドから社内のアプリケーションサーバ	専用線などの経路、アクセス制御、応答の戻り先を確認する
各装置からDNSなどの共通サービス	問合せ先と到達性、移行前の設定が残っていないかを確認する

前段の通信を終端して後段へ新しい要求を送る場合、前後でTCP接続もHTTPの版も異なり得る。HTTP/2対応の表示だけで、どの区間が対応するのかを決め付けない。

HTTP/1.1で残る応答順序の制約

HTTP/1.1には一つのTCP接続を再利用する持続的接続がある。さらにパイプライン処理では、先の応答を待たずに複数の要求を続けて送れる。したがって「HTTP/1.1は必ず応答を受け取ってから次の要求を送る」という説明は正確ではない。

ただし同じ接続でパイプライン処理を行う場合、サーバは原則として要求を受け取った順序で応答を返す必要がある。最初の要求に時間がかかると、後の処理が終わっていてもその応答を先に返せない。これがHTTP層のHead-of-Lineブロッキングである。

例として、大きな画像Aと小さな設定ファイルBをこの順に要求したとする。Bの準備が先に終わっても、同じ接続の応答列ではAの後になる。複数のTCP接続へ分ければ待ち合わせを分散できるが、接続の確立や管理に使う資源も増える。

パイプライン処理の応答順序はRFC 9112の9.3.2節に規定されている。

HTTP/2はデータを区別しながら多重化する

HTTP/2は要求と応答のやり取りをストリームという単位で管理する。ヘッダーや本文をフレームへ分け、各フレームのストリームIDによって、どのやり取りに属するかを識別する。

異なるストリームのフレームを同じTCP接続へ交互に流せるため、画像Aを転送しながら設定ファイルBの応答も進められる。同じストリームの中での順序は守る必要があるが、別の要求までHTTP/1.1の応答列に並べる必要はない。

構成要素	役割
ストリーム	個々の要求・応答を扱う論理的な通信単位になる
フレーム	ヘッダーや本文、制御情報を運ぶ単位になる
ストリームID	フレームが属する論理的な通信を識別する
HPACK	ヘッダー情報を圧縮し、同じ情報を繰り返し送る量を抑える

HPACKが圧縮するのは主にHTTPヘッダーである。画像や動画そのものの圧縮方式とは異なる。また、HTTP/2で多重化しても回線容量が増えるわけではない。複数のストリームは同じ接続の転送能力を共有する。

HTTP/2のフレームと多重化はRFC 9113、ヘッダーの圧縮はRFC 7541で確認できる。

擬似ヘッダーとフロー制御を読み取る

HTTP/1.1ではリクエスト行にメソッドや対象のパスを記述する。HTTP/2ではコロンで始まる擬似ヘッダーフィールドを使い、要求に必要な情報を表現する。

フィールド	表す内容
`:method`	GETやPOSTなどのメソッドを表す
`:scheme`	httpsなどのスキームを表す
`:authority`	接続先サービスのホスト名やポートに相当する情報を表す
`:path`	パスと必要に応じたクエリを表す
`:status`	応答のステータスコードを表す

表は通常のHTTP要求・応答の整理であり、CONNECTなどには別の条件がある。メソッドの意味が変わるのではなく、情報を運ぶ形式が変わると理解する。

HTTP/2ではDATAフレームの受信量を調整するフロー制御を、ストリーム単位と接続全体の両方で行う。受信側が処理できる量を超えて送り続けないためである。これはどのデータを先に送るかという優先制御や、TCPの再送制御とは別の機能になる。

TCPの損失による待ち時間は残る

HTTP/2が取り除くのは、HTTP/1.1の応答順序による制約である。下位のTCPは引き続き、欠けた部分のない順序付きのバイト列をアプリケーションへ渡す。

TCPの途中のデータが失われると、後から届いたデータに別のストリームの内容が含まれていても、欠損が回復するまでその部分を渡せない。このためHTTP/2でもTCP層のHead-of-Lineブロッキングは残る。

高速化の効果を評価するときは、回線の遅延やパケット損失も確認する。接続数が減ることによってNAPTの変換エントリーや接続確立の負担を減らせる場合はあるが、どの環境でも処理時間が一定割合で短くなるとは限らない。HTTP/3はQUICを使う別の構成であり、HTTP/2の設定名を変えるだけで移行できるものではない。

TLSの途中で利用するプロトコルを合意する

HTTPSでHTTP/2を使うときは、TLSのALPN拡張によってアプリケーションプロトコルを選ぶ。クライアントが対応候補を送り、サーバがその中から使うものを選択する。HTTP/2を表す識別子はh2である。

ALPNは暗号スイートを選ぶ拡張ではない。同じTLS接続の上でHTTP/2を使うかHTTP/1.1を使うか、という合意を行う。サーバ名を知らせるSNIとも役割が違う。

段階	確認する内容
TCP接続の確立	宛先アドレスと待受ポートへ到達できるかを確認する
TLSの開始	対応するTLSの版や暗号方式、ALPN候補などを提示する
サーバ側の認証	証明書の信頼性、有効期間、期待する接続先名などを確認する
HTTPの開始	合意した版で要求・応答を行う

令和5年度午後Ⅰ問1のシーケンスはClientHelloとServerHelloを読む構成である。ただしALPNの選択結果を「TLSでは必ずServerHelloに入れる」と一般化してはいけない。TLS 1.3では選択結果をEncryptedExtensionsで通知する。試験図が扱う版と現在の実装を分けて読む必要がある。

ALPNの基本はRFC 7301、TLS 1.3での拡張の配置はRFC 8446の4.2節を参照できる。

ロードバランサのどこで通信を区切るか

ブラウザ側をHTTP/2、バックエンド側をHTTP/1.1にするには、前段でHTTPの内容を解釈して後段へ送り直す処理が必要である。IPアドレスとTCPポートだけを見て転送するL4の動作と、HTTP要求を扱うL7の動作を区別する。

URLのパスによって静的コンテンツと業務処理を振り分ける場合も、装置がHTTPの情報を読めることが前提になる。HTTPSのまま内容を見ない構成では、パスを使った判断はできない。

TLSを終端するロードバランサには、サーバ証明書と対応する秘密鍵を利用できる構成が必要になる。後段をHTTPにするかHTTPSで再暗号化するかは別に決める。前段を暗号化しただけで、クラウドと社内の全区間が自動的に保護されるわけではない。

移行時はタイムアウトや要求サイズの上限も合わせる。前段が処理を待てても後段の待ち時間が短ければ、長い業務処理だけ失敗する。通信方式の互換性とアプリケーションの動作確認を分けて試験する。

クラウドと社内の経路表を対にして読む

経路表の宛先ネットワークは最終的に届けたい範囲、ネクストホップはその範囲へ送るための次の装置である。両者を同じアドレスにするとは限らない。

次は理解用の独自例である。クラウドのサーバ網を192.0.2.0/24、社内のサーバ網を198.51.100.0/24とする。両者を結ぶ区間では社内側ルータが203.0.113.1、クラウド側ルータが203.0.113.2を使用する。これらは説明用アドレスである。

設定する側	宛先ネットワーク	ネクストホップ
社内側	192.0.2.0/24	203.0.113.2
クラウド側	198.51.100.0/24	203.0.113.1

要求を送れることと応答が戻ることは別に確認する。片側だけに経路を追加しても、反対側に適切な経路がなければ通信は成立しない。実際にはクラウドのサブネットに関連付ける経路表、仮想ルータ、社内側ルータ、ファイアウォールの設定も対応させる。

令和5年度の問題では、一部の宛先だけでなくデフォルトルートの指定も扱う。これは問題で与えられた接続方針に基づく設定であり、一般に全てのクラウドのデフォルトルートを社内へ向けるという規則ではない。より具体的な経路があれば、まずロンゲストマッチによって対象が選ばれる。

名前解決の役割と更改後の試験を分ける

DNSの権威サーバは担当するゾーンの情報を答え、キャッシュDNSサーバは利用者に代わって名前を解決して結果を一時保存する。一台が両方の機能を持つ構成でも、役割は別である。公開サービスのAレコードと、社内端末が問合せ先として使うDNSサーバの設定を混同しない。

サービスの接続先をロードバランサへ変更する際は、公開DNS、社内向けDNS、証明書が表す名前を照合する。IPアドレスを直接指定して疎通できても、名前解決や証明書の検証まで成功したことにはならない。

試験	判断できること
名前解決を確認する	意図したサービスの接続先を得られるか確認する
TLSの合意内容を確認する	証明書を検証し、期待するHTTPの版を選べるか確認する
静的ファイルと業務処理を別々に利用する	パスごとの振分けと後段への到達性を確認する
クラウドと社内の両側で通信を観測する	要求・応答のどこで停止するかを切り分ける
高負荷時や回線障害時に試す	タイムアウト、処理能力、切替え後の経路を確認する

午後問題での問われ方

令和5年度午後Ⅰ問1では、HTTPの通信方式を理解したうえで、Webシステムの一部をクラウドへ移した構成を読む。プロトコル名を覚えるだけでなく、どの装置が接続を終端し、どの区間でその方式を使うかを説明することが重要である。

問いの観点	答えを組み立てる順序
HTTP/2で待ち時間を減らせる理由	HTTP/1.1の応答順序と、別ストリームを多重化する動作を比べる
ALPNで通知する情報	クライアントが提示する候補と、サーバが選ぶ結果を区別する
ロードバランサに必要な動作	版の変換やパスの判定に、どの層の情報が必要かを考える
経路表の空欄	設定する装置から見た宛先と次の装置を決め、戻りも確認する

本稿は公式問題を題材にした学習用の解説であり、問題文や全設問の解答を転載したものではない。設問の条件と解答例は次の一次資料で確認できる。