[https://www.youtube.com/watch?v=dr6JMO25Fds:embed:cite]
SaaS導入によるネットワーク遅延の原因と、その解決策となる最新のネットワークアーキテクチャを解説します。ハブ＆スポーク構成の限界から、SD-WANを用いたローカルブレイクアウトの仕組み、プロキシのボトルネック解消、そして現代の主流であるSASE（サシー）の考え方まで、ネットワークエンジニアが押さえておくべき実践的な知識を、試験対策のポイントを交えながらサクラ先輩と一緒に詳しく学んでいきましょう。 企業がSaaSを導入する際に直面する最大の課題は、全拠点の通信を一度本社へ集約するハブ＆スポーク構成によって引き起こされるネットワークの激しい遅延です。 この現象は、社内ユーザの代理人として通信を行うフォワードプロキシや本社のインターネット出口にアクセスが殺到し、ボトルネックが生じることで発生します。 Webサーバの保護や負荷分散を目的とするリバースプロキシに対し、今回問題となるフォワードプロキシは、大量のセッションを伴うSaaS通信により処理能力が限界に達してしまいます。 特にHTTPS通信において、ブラウザはCONNECTメソッドを使用して暗号化トンネルを作成しますが、この状態ではプロキシ側から通信の中身であるURLパスまでは見えず、セキュリティチェックができないというリスクを孕んでいます。 解決策として、一度暗号を解読してログを取得するSSLインスペクションという手法がありますが、プロキシが自身の証明書で暗号化し直すため、PC側で警告が出ないようプロキシサーバのルート証明書を全端末にインストールする対応が必要になります。 こうした課題に対し、ハードウェアの増強ではなく通信の流れ自体を変える技術がSD-WANです。 SD-WANの最大の特徴は機能の分離にあり、制御を司るコントロールプレーン（脳）と転送を担うデータプレーン（手足）を分けます。 この技術を応用したローカルブレイクアウトでは、SaaS宛ての通信だけを各拠点から直接インターネットへ逃がすことで、本社の負荷を劇的に軽減します。 ただし、SaaSのIPアドレスは頻繁に変更されるため、RSSを利用して経路情報を自動取得し、コントローラへ反映させる「Network as Code」の仕組み作りが重要です。 また、直接アクセスする通信はプロキシを通らないため、監査のためにSaaSのAPIを叩いてログを直接収集する仕組みや、ブラウザ側に特定の通信をプロキシ経由にしないよう指示するPACファイルの活用も必須となります。 現在はさらに進化し、クラウド上のプロキシであるSWGやCASBを経由させて場所を問わず同じセキュリティポリシーを適用するSASEやSSEといった考え方が、ゼロトラスト時代のネットワーク最適化における主流となっています。
