2025年までには楽になろう…

そのローカルブレイクアウト、最適化されてますか？（前編）

我々のような外資ベンダーの日本法人で働くと、たまにトランスレータの壁にあたることがあります。同じ IT 業界で同様のソリューションを扱っている身ではありますが、US を始め海外では一般的に使われているワードが日本ではあまり使われておらず、そのままでは伝わりにくかったりします。例えば SD-WAN 周りで言うと、海外では“MPLS”という言葉が使われるとほぼニアリイコール“閉域 VPN サービス”と言う意味合いで使われているのですが、国内では同等の言い回しとしては“広域イーサネット”や“IPVPN”などがより一般的なので、”MPLS”という言葉が通じるのは Service Provider 分野で活躍している SE さんたちだけだったりします。（MPLS というのは一般的に SP さんが VPN サービスを提供するために内部で使っているネットワークのテナント分離を提供するためのプロトコルの名前なのです。）よって、海外で利用される VMware SD-WAN by Velocloud の資料を日本のお客さまに卸すときには、PowerPoint の置換で“MPLS”を“VPNサービス”か“閉域網”と一括置換したうえでなおかつフォントのサイズと絵面の合わせを行いつつ和訳していたりします。（最近量が多くて疲れてきちゃったので MPLS という言葉も漏れがちなのと、それにより徐々に伝わることも多くなってきたのですが…）
また逆に、日本でのソリューションにおける流行り言葉が和製英語的な使われ方をしていてそのまま英語にしただけでは海外に伝わらなかったりすることもあります。SD-WAN におけるキラーアプリケーションに上り詰めた感のある「ローカルブレイクアウト」も日本ではよく使われる言葉ですが、実は海外ではそのままでは伝わらなかったりするワードだったりします。（海外では、Internet Direct、もしくは、Internet Breakout と呼ばれたりしています。ためしに Google 先生における英語指定で “Local Breakout” を検索してみていただくと、SD-WAN とは異なった風味の Link が上位に上がってくるのをご確認いただけると思います。ご興味があれば見てみてください。）

そんなこんなで日本では SD-WAN を検討する際の鉄板要件になってきた感のあるローカルブレイクアウトですが、実はいろんなローカルブレイクアウトの手法があるんですよ、というのが今回のお話です。

バックホール接続　vs ローカルブレイクアウト

まず、ローカルブレイクアウトを定義するために反対語？のバックホール接続についてお話します。SD-WAN の構成を語る上でよく使われるバックホール接続とは、ブランチサイトからの通信を一度データセンターに集約し、データセンターからセキュリティやロギングを経て外部インターネットやSaaSにアクセスするトラフィックフローのことを指しています。一昔前は、ブランチサイトのクライアントがアクセスする主な宛先がデータセンター内に配備されたオンプレのアプリケーションだったためこの構成が主なデザインとして多くのエンタープライズ WAN のリファレンスとなっていましたが、気がつけばアクセスするターゲットのアプリがオンプレからクラウドにシフトしてしまったが故に、旧来のトラフィックフローを維持したままではコスト的な効率が悪い、もしくはユーザーエクスペリエンスが低下する、という問題が発生してしまいます。

SD-WAN によるローカルブレイクアウトの登場

クラウドの利用が加速化する昨今、この課題に対処するソリューションを提供することが可能な SD-WAN がにわかに市場で注目を浴び始めます。旧来型のルーターが基本的には“Routing Table”を参照してパケットをフォワードするのに対して、その進化版である SD-WAN では“アプリケーション”を認識し、そのアプリケーションに最適な経路を選択してクライアントからのリクエストを転送することが可能となっています。よってこの構成の様に特定のアプリだけ、をブランチサイトから直接インターネット経由でクラウドに接続することを非常にかんたんな手間で提供することできます。

このブランチ拠点から必要なアプリケーションだけを直接インターネット経由で通信させる手法が（バックホール接続と対比した形で）一般的に「ローカルブレイクアウト」と呼ばれています。

ローカルブレイクアウトは SD-WAN の花形機能ではありますが、一方で普通のローカルブレイクアウトであれば大概どのベンダーの SD-WAN 装置であっても実装が可能です。では、この領域もすでに市場としてはサチっていて、どのベンダーのソリューションを選んでも大差ないのか？！価格の差だけ気にしていればよいのか？という疑問には、否！と強く申し上げたいのが我々 VMwareのSD-WAN でございます。

そもそもローカルブレイクアウトすればすべて問題は解決なのか？

一般論としてバックホール接続と比べれば、オーバーサブスクリプション比率が少ないであろうブランチ拠点からのローカルブレイクアウト接続のほうが効率的に SaaS やクラウドにアクセスができそうです。ではそれだけですべてのお客さまの期待値に答えられるのか？と言われれば、必ずしもそうではなさそうだ、と言わざるを得ません。SD-WAN を国内にご紹介し始めた頃によく言われたのは、「回線品質の悪い海外であれば、このようなソリューションも有要だろうけど、回線品質のよい日本だとねぇ…（要らないのでは？）」という日本の回線品質神話です。国内のサービスプロバイダーさんの頑張りにより、日本のインターネットバックボーンが海外よりも高品質で安価なのは確かな事実ですが、とはいえラストワンマイルの足回りまで含めて確実に高品質な回線が日本全国の各企業ブランチサイトまで届いているか？というと疑問を持たざるを得ません。また、COVID19 により働き方が大きく変わろうとしている昨今、今まで以上に様々な立地からの高品質なインターネットアクセスが期待される潮流になってきています。そこで我々の SD-WAN を利用いただくとこれまで見れなかった国内インターネット回線品質の現実が見えてきたり、それによって対策を講じたりすることができます。

我々 Virtual Cloud Network Team の SE 宅（Green ランプのところ）には、こんな感じで検証用の VMware SD-WAN 網が張り巡らされています。こちらを利用して国内インターネット環境の品質サンプルをご紹介したいと思います。

以下は私の同僚の家に引いてあるブロードバンドインターネット回線を VMware SD-WAN で覗き見たサンプル画面です。

“Before” と “After” という2本のバーグラフが表示されていますが、まずは “Before” に注目してください。これが私の同僚の家の素のインターネット回線品質です。このサンプルは一週間の幅でバーを表示していますが、イエローやレッドで表現された時間帯はインターネット回線品質の劣化が起きていることを意味しています。（ちなみにこの例に限らず、COVID19 によりラストワンマイルにおけるインターネットトラフィックとその品質の傾向が露骨に変わってきています。）

試しにある時間をマウスオーバーすると、ダウンストリームにおいて 26ms の遅延、7ms のジッター、3.03％ のパケットロスを検知していることがわかります。

総評としてこの回線の一週間の品質スコアは VMware SD-WAN によって 4.75 と評価されています。この 4.75 という品質スコアの回線にただただローカルブレイクアウトを行ったとして果たしてビジネスに耐えられる品質の WAN 環境が手に入るでしょうか？

答えはおそらく NO でしょう。

ちなみにこのような品質のインターネット回線環境はなにも私の同僚宅に限った話ではなく、我々のお客さま環境における実際のインターネット回線を拝見していると、たとえ東京のど真ん中であったとしても地域や時間帯によって（周辺環境のインターネットアクセス状況に大きく依存）このような品質状態になってしまうことはまま散見されます。このようなインターネット回線環境においてもビジネスに耐えうる高品質な仮想 WAN 環境と最適なローカルブレイクアウトを手に入れるためには…？ 答えは、上記バーグラフの“After”に隠されています。

この “After” が何を意味するのか？を次回の Blog でご紹介したいと思います。

後編につづく