ローカルブレイクアウト導入の勘所と、押さえておくべきポイントを実践的に解説

Web会議やオンラインストレージサービスの大量のトラフィック消費による通信の輻輳、またそれに伴うアプリケーションの動作遅延を回避する手段として「ローカルブレイクアウト」のニーズが高まっています。社内ネットワークの負荷を軽減し、ローカルブレイクアウトにより、社内システムやクラウドサービスを快適に利用できるようになります。ただし、前提条件や注意すべきポイントをしっかり押さえておかないと、思わぬ問題を抱え込むことになります。“失敗しない”ローカルブレイクアウトの勘所を分かりやすく解説します。

目次

1. ローカルブレイクアウトによるメリットとは
2. ローカルブレイクアウトの前提条件となるセキュリティ担保
3. 既存環境でローカルブレイクアウトする方法とは
4. プロキシ環境は「除外対象」の設定が必要
5. SaaSの宛先追従は大きなネック
6. ローカルブレイクアウトを実現するIIJサービス

ローカルブレイクアウトによるメリットとは

ローカルブレイクアウトとは、SaaSなどのクラウド向けトラフィックを直接インターネットにブレイクアウト（脱出）させる通信形態です（図1）。社内ネットワークのゲートウェイ環境を経由することなく、各拠点やエッジから直接インターネットへ抜けるようにすることで、社内ネットワークの負荷を軽減します。

通信の輻輳やアプリケーションの動作遅延などが解消されることで、ストレスなく快適に業務を行うことができます。リモートワークが円滑になり、働き方改革の促進や生産性の向上が期待できるでしょう。

通信のボトルネックが解消されれば、業務部門からのクレームも激減します。IT部門やネットワーク管理者のサポート工数が減り、付加価値の高い業務により多くのリソースを注力できます。

（図1）ローカルブレイクアウトイメージ

ローカルブレイクアウトの前提条件となるセキュリティ担保

ローカルブレイクアウトの目的は社内ネットワークに集中するトラフィックの負荷分散です。しかし、だからと言って、すべてのインターネット・トラフィックをブレイクアウトさせることはできません。

インターネット・トラフィックのすべてを拠点から直接ブレイクアウトさせると、本来許可していない通信まで社内ネットワークを経由せず、インターネットにアクセスできてしまうからです。いわゆるシャドーITと言われるサービスが無防備なまま利用されてしまうリスクがあるのです。

Microsoft 365などの信頼できるクラウドサービスのみブレイクアウトさせ、それ以外はファイアウォールやWebフィルタリング、アンチウイルスといった十分なセキュリティ機能を施した社内ネットワークを経由させる。こうすることで、十分な安全性を確保することができます。

どのトラフィックを社内ネットワーク経由にし、どのトラフィックをブレイクアウトさせるか――。自社のセキュリティポリシーやネットワーク負荷を元に、最適な「ローカルブレイクアウト設計」を行うことが肝要です。

既存環境でローカルブレイクアウトする方法とは

各拠点や社外端末からのトラフィックは社内ネットワークのルータなどの機器でその内容を識別します。ここに一部のクラウドサービス向け通信を事前登録しておくことで、社内ネットワークを経由しないインターネット回線への振り分けが可能になります。

この振り分けは、クラウドサービスのIPアドレスやドメインを元に行います。例えば、特定のSaaSをローカルブレイクアウトしたい場合は、そのIPアドレスやドメインを事前登録しておくわけです。

ただし、一度登録したものが、その後も永続的に使えるわけではありません。SaaSの宛先情報は不定期に変更されるからです。新しい宛先情報はSaaSの提供元より公開されますが、その情報はユーザ自身がクラウド事業者のWebサイトをチェックして入手しなければなりません。SaaSの宛先がいつ、どのように変更されたかを把握した上で、新しい宛先情報を登録し直す作業が必要です。

プロキシ環境は「除外対象」の設定が必要

プロキシサーバを利用している場合は特に注意が必要です。というのもインターネット・トラフィックはこのプロキシサーバで制御されるからです。インターネット通信はプロキシサーバを経由するように定義されているのが一般的です。すべてのインターネット通信はプロキシ経由となるため、基本的にローカルブレイクアウトはできません（図2）。

（図2）プロキシ環境におけるローカルブレイクアウトのイメージ
（クリックして拡大）

プロキシ環境でローカルブレイクアウトを可能にするためには「PACファイル」の修正が必要です。PACファイルとは、プロキシサーバを経由してアクセスするかどうかを定義した設定ファイルのこと。ここですべてのインターネット通信はプロキシ経由となるように定義されているのです。

クライアント端末は、まずこのPACファイルを参照します。PACファイルに「除外対象」を定義すれば、プロキシサーバを経由しないアクセスが可能になります。特定のSaaSの宛先をプロキシ経由から除外することで、ローカルブレイクアウトが可能になるわけです。

SaaSの宛先追従は大きなネック

PACファイルの定義変更は人が手作業で行います。定義変更自体は難しい作業ではありませんが、実はこの場合も宛先情報の追従が必要です。

除外対象を設定し、ローカルブレイクアウトできるようにしても、追従が遅れると、ローカルブレイクアウトできなくなります。昨日までブレイクアウトできたのに、今日はできない――。通信の輻輳やレスポンス遅延に悩まされ、仕事にならない――。変更情報を常にチェックしておかないと、そんなクレームが多発するかもしれません。いつ変更されるか分からない情報を常にチェックしなければならない手間と負担は決して小さなものではありません。

プロキシサーバの有無に関わらず、SaaSの宛先追従は既存環境でローカルブレイクアウトを実現する場合の“宿命”とも言える課題です。

ローカルブレイクアウトを実現するIIJサービス

SaaSの宛先情報が不定期に変更されても、ローカルブレイクアウトを実現する――。IIJはそのためのサービスを提供しています。サービスはいくつかの種類があり、組み合わせることで、SaaSの宛先追従問題に煩わされないローカルブレイクアウトを容易に実現できます。

そのサービスパターンの1つがSD-WANサービスの「IIJ Omnibusサービス」と「IIJクラウドプロキシサービス」「IIJクラウドナビゲーションデータベース」の組み合わせです。

IIJ Omnibusサービスはシンプルに導入・運用できるSD-WANサービス。データセンター中心のネットワーク構成を、クラウドベースのSD-WANに容易に移行できます。

IIJクラウドプロキシサービスはプロキシ環境をクラウド上で提供するサービスです。クラウド上のプロキシがお客様の通信を適切に振り分けることで、社内ネットワークの負荷を軽減できます。

IIJクラウドナビゲーションデータベースはSaaSの宛先情報の収集とPACファイルへの反映を自動化するサービス。Microsoft 365、Windows Update、Google Workspace、Zoom、Boxをはじめとする代表的なSaaSの宛先はあらかじめテンプレートが用意されています。PACファイルは分かりやすいWeb UIとなっており、テンプレート以外の任意のSaaSもお客様自身で除外設定することが可能です。

3つのサービスを組み合わせることにより、ローカルブレイクアウト設計をお客様自身が定義し、なおかつSaaSの宛先変更にも自動で追従するローカルブレイクアウトを容易に実現できるのです（図3）。

IIJのサービスを活用すれば、新たな設備投資をすることなく、導入できる点もメリットです。ローカルブレイクアウトの導入を検討している担当者様はぜひお気軽にご相談ください。

（図3）IIJサービスによるローカルブレイクアウト実現のイメージ
（クリックして拡大）

この記事を読んだらチェックしたいサービス

クラウド時代に最適なSD-WANサービス

IIJ Omnibusサービス

DL資料あり

快適通信とシンプル運用を実現するSD-WANサービス

SaaSなどへのトラフィックをクラウド上で最適経路に振り分け

IIJクラウドプロキシサービス

DL資料あり

クラウドサービス利用時におけるWebアクセスの課題を、クラウド上で最適な経路に振り分けることで解決するネットワークサービス

クラウド通信のブレイクアウトを実現

IIJクラウドナビゲーションデータベース

DL資料あり

SD-WANサービスの拠点に対して、クラウドサービスの経路を配信してクラウド通信の拠点ブレイクアウトを実現