5.4ネットワーク方式設計

システムアーキテクトは、利用者からの通信をサーバ群にどう振り分け、コンテンツをどこに配置し、障害時にどう経路を切り替えるかというネットワーク方式を、性能・可用性・コストのトレードオフから設計します。この節では負荷分散の階層による違い、CDN/DNSの役割、冗長経路と遅延最適化の判断を学びます。

5.4.1負荷分散：L4とL7

• L4負荷分散（トランスポート層）＝送信元/宛先IPアドレスとポート番号、TCP/UDPのコネクション情報のみを見て振り分け先を決める方式。パケットの中身（HTTPヘッダ等）を解析しないため処理が軽く高速でスループットに優れるが、URLパスやCookie等アプリケーションの内容に基づいた柔軟な振り分け（例：特定パスだけ別サーバ群へ）はできない。
• L7負荷分散（アプリケーション層）＝HTTPヘッダ・URLパス・Cookie等アプリケーション層の内容まで解析して振り分け先を決める方式。「/api/ 配下はAPIサーバ群へ」「特定Cookieを持つ利用者は特定バージョンのサーバへ（A/Bテスト等）」といった柔軟な振り分けが可能だが、パケットの中身を解析する分だけL4より処理オーバーヘッドが大きくスループットは劣る。SSL/TLS終端（暗号化通信の復号）を負荷分散装置側で行う構成もL7に位置づけられることが多い。
• 判断軸は「単純に処理を高速に振り分けたいか」対「URLパスや利用者属性に基づく柔軟な制御が要るか」。高スループットが最優先の単純な振り分けはL4、パスベースルーティングやA/Bテスト等の柔軟性が要る場合はL7、というように要件次第で使い分ける（併用も一般的：まずL4で大まかに分散し、その先でL7がアプリケーション単位に振り分ける多段構成）。

5.4.2CDNとDNS

• CDN（Content Delivery Network）＝静的コンテンツ（画像・動画・JS/CSS等）を利用者の地理的に近いエッジサーバにキャッシュして配信するネットワーク。オリジンサーバ（本来のコンテンツ保有元）までの物理的距離を減らすことで通信遅延（レイテンシ）を短縮し、同時にオリジンサーバへの直接アクセスを減らしてオリジンの負荷を軽減する。動的に変化するコンテンツ（個人化された注文情報等）はキャッシュに向かず、CDN経由でもオリジンへ都度問い合わせる設計が必要になる。
• DNS（Domain Name System）＝ドメイン名をIPアドレスへ変換する階層的な名前解決の仕組み。可用性の観点では、権威DNSサーバを複数（かつ地理的に分散して）冗長化することで単一障害点を排除する。また、DNSの応答で複数のIPアドレスを返す、あるいは利用者の地理的位置に応じて近い拠点のIPを返す（GeoDNS的な仕組み）ことで、負荷分散や障害時の切り替えの入口としても機能する。ただしDNSの変更はTTL（Time To Live）の間キャッシュされ反映が遅れうるため、障害時の即時切り替え手段としてはDNSだけに頼らず、後述の冗長経路と組み合わせる設計が実務的である。

5.4.3冗長経路と遅延最適化

• 冗長経路＝単一の通信経路（回線・機器）に障害が起きてもサービスを継続できるよう、経路を複数用意しておく設計。回線を2系統以上契約する、ルータ/スイッチを二重化し障害時に自動的に迂回経路へ切り替える、複数のデータセンター/リージョンにシステムを配置し一方が使えない場合は他方へ通信を振り向ける、といった手段がある。単一障害点（SPOF）を作らないことが設計の要諦であり、DNSの切り替えだけに頼らず経路レベルでの自動フェイルオーバーを組み込むのが望ましい。
• 遅延最適化＝利用者からの応答時間を短縮する設計。物理的な距離を縮める（CDNのエッジ配置、利用者に近いリージョンへのシステム配置）、経路のホップ数や輻輳を減らす、コネクションの確立コストを下げる（TLSセッションの再利用、HTTP/2やHTTP/3の活用によるコネクション多重化）などが代表的な手段。キャパシティプランニング（想定アクセス量に対しどこにボトルネックが生じるかの見積もり）を伴わない遅延対策は、ピーク時の輻輳を見落としやすい点に注意する。

あるシステムアーキテクトが、全国の利用者を対象とする動画配信サービスのネットワーク方式を設計しているとします。まず負荷分散層について、当初はシンプルに全リクエストを一律で振り分ける方針を検討しましたが、「/api/ 配下のリクエストは動的なAPIサーバ群へ、それ以外の静的アセットへのリクエストは別のサーバ群へ」というURLパスに基づく柔軟な振り分けが要件にあったため、パケットの中身を解析できるL7負荷分散を採用しました。ただし全リクエストをL7だけで処理すると解析オーバーヘッドで全体のスループットが落ちることを懸念し、まずL4負荷分散で複数のL7負荷分散装置へ大まかに振り分け、その先でL7がパス単位に細かく振り分ける多段構成にすることでスループットと柔軟性を両立させました。次に動画ファイルという静的コンテンツについては、全国の利用者から東京の単一オリジンサーバへ直接アクセスが集中すると、地理的に遠い利用者ほど遅延が大きくなり、かつオリジンの負荷も過大になると判断し、CDNを導入して各地域のエッジサーバに動画をキャッシュさせ、遅延短縮とオリジン負荷軽減の両方を実現しました。一方、利用者の視聴履歴や個人化されたおすすめ情報のような動的コンテンツはCDNでのキャッシュに向かないため、これらはオリジンサーバへ都度問い合わせる設計のままとしました。さらに可用性を高めるため、東京リージョンに加えて大阪リージョンにもオリジンの複製を配置し、DNSの複数IP返却や地理的振り分けで平常時は近い拠点へ誘導しつつ、東京リージョンに障害が起きた場合は経路レベルで自動的に大阪リージョンへ切り替わる冗長経路を組み込みました。この際、DNSのTTLによるキャッシュのため切替が即座には反映されないことを踏まえ、DNS切替だけに頼らず、ロードバランサ側でも障害検知と自動フェイルオーバーの仕組みを重ねて持たせました。このように、振り分けの柔軟性要件にはL4/L7の多段構成、地理的遅延とオリジン負荷にはCDN、単一障害点の排除には冗長経路とDNSの限界を踏まえた多層防御、という形で、課題ごとに手段を積み重ねて設計することが、ネットワーク方式設計の核心です。

5.4.4この節のまとめ

• L4負荷分散はIP/ポートのみで高速だが柔軟性なし、L7負荷分散はアプリ内容で柔軟だがオーバーヘッド大＝要件で使い分け・多段構成も一般的
• CDNはエッジキャッシュで遅延短縮とオリジン負荷軽減の両方を実現、動的コンテンツはキャッシュ不向き
• DNSの切替はTTLで遅延しうるため、単一障害点排除には経路レベルの冗長経路（自動フェイルオーバー）を併用する