ExpressRouteで障害が発生する可能性のあるポイントとその対応策

2024.03.13

はじめに

こんにちは。前回の記事 から所属が変わり、現在は株式会社プログライブコンサルティングの酒見（さけみ）として記事を執筆しています。

内容はこれまでと変わらず、主にAzureのネットワークに関するテーマを取り扱っていきます。

今回のテーマは、ExpressRouteの冗長化についてです。

この話題を深く理解するためには、ExpressRoute を物理的に deep dive する (第1回) のシリーズや Azure ExpressRouteとは？概要と接続方法などについてデータセンター会社が解説、さらには 詳説 Azure ExpressRoute のシリーズや、ExpressRoute の計画メンテナンスガイダンス も参考にしていただくと良いでしょう。

個人的な見解ですが、ExpressRouteは一対の回線だけでも十分な冗長性を備えていると考えています。

他社のパブリッククラウドと比較するとコストが高く感じられることもありますが、それはAzureがExpressRoute接続に要求する冗長性のレベルが高いためだと理解しています。

冗長化のメリット・デメリット

ExpressRouteの冗長化は、オンプレミスやデータセンターなどの社内ネットワークからのアクセス経路を冗長化することであり、以下のようなメリットとデメリットがあります。

メリット

- 通信の信頼性が向上します

- 全国どこからでも高品質な通信を実現可能にします

多くのシステムやワークロードがAzureに移行した後、そのアクセス経路の信頼性は自社ビジネスにとって重要な要素になります。

障害による社内システムの停止を避け、ビジネスへの大きな影響を防ぐためには、障害が発生し得るポイントを特定しておくことが重要です。

デメリット

- コストが増加します

- 構成や設定が複雑になります

冗長化を実現するためには、一部のコンポーネントを二重化することが求められ、結果としてコストが2倍になる可能性があります。

また、構成や設定の複雑化により、フェイルオーバーが正しく機能するかの確認や、運用コストの見えない増加もデメリットとして挙げられます。

冗長化の個所

ここでは、以下のような図をもとに障害が起こる可能性のあるポイントや冗長化が可能なポイントを検討していきます。

ExpressRouteの要素による障害ポイントと可用性のための選択肢

ExpressRouteでつながっている「ネットワーク機器（L1）」の冗長化

ExpressRouteは、多くのケースでExpressRoute接続プロバイダーのネットワーク機器とAzure側のネットワーク機器が接続されています。

これらの機器は、冗長性を前提とした構成が取られており、物理的に異なるネットワーク機器による冗長構成が実施されています。

そのため、この観点から障害が発生した場合でも、自動的に切り替わることが期待できます。

追加のコストは発生しません。

ExpressRouteでつながっている「リンク（L2）」の冗長化

加えて、L2レベルでの冗長化も重要です。

ExpressRouteのPrivate Peeringを設定する際には、/30のIPアドレスを2つ設定する必要があります。

この2つのリンクはサービス設計の前提として両方とも使用されることを想定しています。

Azure側でメンテナンスが必要な場合、このうち1つのリンクが一時的に切断される可能性がありますが、その際はもう一方のリンクがトラフィックを引き継ぎます。

多くのユーザーは、L3プロバイダーを使用していると思われますが、この場合、ExpressRoute接続プロバイダーのレベルで2つのリンクが冗長化されているため、ユーザーが特に意識する必要はありません。

しかし、L2プロバイダーを利用しており、ユーザー自身でルーターの設定を行っている場合は、それぞれの/30を物理的に別の機器に設定し、適切な冗長化プロトコルや自動的なルーティング変更を設定することが重要です。

この場合でも、Azureに関しては追加のコストが発生することはありません。

ExpressRoute「回線」の冗長化

以上の内容から、1対のリンクを持つ1つのExpressRoute回線でも、一定レベルの冗長化が実現されていることがお分かりいただけたかと思います。

しかし、ExpressRouteのロケーション自体の障害や、ExpressRoute接続プロバイダーの障害など、重要度の非常に高いシステムに対応する場合は、別のExpressRoute回線を利用してさらなる冗長化を図ることが可能です。

「ロケーション」とは、tokyo/tokyo2/tokyo3/osakaなどと表現され、ユーザーがAzureに接続するために用意された「出島」のような場所を指します。

また、大規模な災害を想定する場合、東京近郊だけではなく、大阪などの別のリージョンからの接続も検討する必要があります。

ExpressRoute自体の冗長化を検討する際は、以下の点を考慮します。

- ロケーションを分けるかどうか

- ExpressRoute接続プロバイダーを変えるかどうか

- 東日本・西日本など、地理的に回線を分けるかどうか

ExpressRoute の接続プロバイダーと場所の一覧には、各ExpressRoute接続プロバイダーが対応しているロケーションが記載されています。

現在お使いのExpressRoute接続プロバイダーにお問い合わせいただき、必要に応じて他のロケーションへの接続も検討してください。

ExpressRoute回線を冗長化した場合、複数の回線を1つのExpressRoute Gatewayに接続しますが、ロケーションやExpressRoute GatewayのSKUによって対応できる最大値が異なるため、Azure サブスクリプションとサービスの制限、クォータ、制約 - ExpressRoute の制限を確認してください。

コストはExpressRoute接続プロバイダーによって異なります。