ExpressRoute を物理的に deep dive する (第4回)｜クラウド&DC間接続サービス ATBeX

2022.05.02

はじめに

第2回ぶりとなります、酒見です。

前回の記事までの連載を読むことで、ExpressRouteについての皆様の理解がかなり進んだかと信じています。

今回は、ExpressRoute回線（circuit）とは結局なにか、私なりの理解をもとにまとめてみようと思います。

ここまで読み進めていただいた結果として、ExpressRouteの回線があまり物理的なものではないことに

気付いた方がいらっしゃるのではないかと思います。

私の理解としてもそのとおりで、ExpressRouteの物理的（physical）な接続としてのそれはISPとの共用接続であり、

ユーザ固有のAzureリソースと1対1に紐づくものではありません。

各ユーザがExpressRoute回線をデプロイした結果として、論理的（logical）な回線というか、

端的に言えばVLANを設定しているようなものです。

「回線」という用語を聞いて多くの方が物理的な線（UTPとか光ケーブルとか）を

イメージするケースが多いと思いますが、そうではないということですね。

物理的な回線にほぼ等しいものはExpressRoute Directであり、これは前回の記事で説明されていたものです。

利用例によっては、一連のプロジェクトタスクの中でISPとの物理的な回線を新規に敷設することもあり、

その場合にはExpressRouteが最終的に利用可能になるまで数か月単位での納期となることがほとんどです。

しかし、論理的な接続が新しく作られるだけということに着目すると、場合によっては既存回線のままVLAN追加する形で

数日単位でのExpressRoute開通が可能であることも理解ができるかとは思います。

納期についてはキャリア側の都合とMicrosoft側の都合が絡むケースもあるため、都度ご確認いただいた方がよいです。

ExpressRoute回線が論理的なものであるがゆえに、その帯域幅を増やす（増速、とよく呼ばれます）が可能ではないケースがあります。

論理的なユーザの帯域幅の合算値と物理的な回線の帯域幅は一定の比率が守られており、

これを超えるケースでは増速に失敗する可能性があります。

極端な例ではありますが、物理的な帯域幅10GbpsのポートでISPとMicrosoft間が接続されているとして、

1GbpsのExpressRoute回線がすでに7つ（7つのユーザと大体同義です）収容されている状態で、

あるユーザが40Gbpsに増速することはできません。

その場合は、新しい物理的な接続（これはISPとMicrosoftの間で新規に交渉されるものです）が確立した後に、

別のExpressRoute回線を作成し、乗り換えていく必要があります。

こちらは[docs]にも書いてある内容ですが、要注意です。

なお、2つのExpressRoute回線を振り替えていく方法については、冗長化で利用される手法を利用することになります。

Azure側での1つの対応例としては、ExpressRoute GatewayとExpressRoute回線を結びつけるリソースである接続（connection）リソースのプロパティである重みを変更します。

オンプレミス側での対応例としてはBGPのLocal Preference値を変更するなどの作業が必要です。

詳細については[docs]ご参照ください。