CI部1課の山﨑です。
今回はオンプレミスと AWS 間の接続の冗長構成について再考してみました
はじめに
本ブログでは2021年9月2日 の 午前7時30分から午後1時42分までの間に発生していた東京リージョンにおけるDirect Connect 障害を受け、オンプレミスと AWS 間の接続の冗長構成について再考してみました。
本DX障害についてはAWSがパブリックコメントをしておりますので以下ご覧ください。
上記のDX障害において復旧に至るまでの経緯(時系列)や復旧手順等については以下のブログに整理されていますのでご覧ください。
またDirect Connect 接続そのものについては以下のブログに整理されていますのでご一読ください。
以降の内容はAWSが無償で提供しているBlackbeltという素晴らしい資料を元に再考することにします。
www.slideshare.net
オンプレミスと AWS 間の接続において障害が発生する可能性がある場所
オンプレミスと AWS 間の接続において障害が発生する可能性がある場所として例えば以下の図の箇所が考えられます。
9月2日に発生した障害では Direct Connect を利用したネットワークトラフィックを AP-NORTHEAST-1 リージョン内の全てのアベイラビリティーゾーンに接続するのに使用される複数のコアネットワークデバイスのOSに起因した障害であり、おそらく図中の黄色で示した箇所付近で発生したものと推測されます。障害はいつどこで発生するか予測がつきませんが、来たる障害に備えて冗長化が可能なコンポーネントについて以降整理していきます。
※今回はDirect Connect Gateway と Transit Gateway を使ってオンプレミスと AWS 間を接続している構成を前提にしています。
※※Transit Gateway を利用するためにはTransit VIFを敷設する必要がありますが、通常のVIFとは異なり制約があるためご利用の際はパートナー企業に利用可否についてご確認ください。
冗長化できるコンポーネントについて
オンプレミスと AWS 間の接続における冗長化では以下の6つの冗長化を組み合わせてお客様の要件に合った冗長構成を検討する必要があります。
- 通信キャリアの冗長化
- Direct Connect ロケーションの冗長化
- 専用線接続の冗長化
- 接続方式の冗長化
- 接続先リージョンの冗長化 - シングル専用線パターン -
- 接続先リージョンの冗長化 - マルチ専用線パターン -
それぞれのメリット・デメリットについて整理してみます。
役割 | メリット | デメリット |
---|---|---|
通信キャリアの冗長化 | 通信キャリア障害の影響を受けない。 | ・複数の専用線を調達する必要があるためコストが高い。 ・オンプレミス側のネットワーク機器が増えるため管理に手間がかかる。 ・リージョン障害には対応できない。 |
Direct Connect ロケーションの冗長化 | Direct Connect ロケーションの障害の影響を受けない。 | ・複数の専用線を調達する必要があるためコストが高い。 ・オンプレミス側のネットワーク機器が増えるため管理に手間がかかる。 ・リージョン障害には対応できない。 |
専用線接続の冗長化 | 一方の専用線接続に障害が発生した場合に影響を緩和できる。 | ・複数の専用線を調達する必要があるためコストが高い。 ・複数回線でトラフィックの負荷分散を行っている場合は一方にトラフィックが集中してしまうのでパフォーマンスに影響する可能性あり ・オンプレミス側のネットワーク機器が増えるため管理に手間がかかる。 ・Direct Connect ロケーションの障害に対応できない。 ・通信キャリア障害に対応できない。 ・リージョン障害には対応できない。 |
接続方式の冗長化 | ・Direct Connectで障害が発生した場合に Site to Site VPN を利用することで障害の影響を緩和できる ・専用線の調達コストを抑制することができる。 |
・Site to Site VPN はDirect Connect と比較して帯域幅が狭いためパフォーマンス低下の懸念あり ・リージョン障害には対応できない。 |
接続先リージョンの冗長化 - シングル専用線パターン - | ・接続先リージョンの障害の影響を受けない。 ・専用線の調達コストを抑制することができる。 |
・Direct Connect ロケーションの障害に対応できない。 ・通信キャリア障害に対応できない。 ・AWSリソースが増えるため管理に手間がかかる |
接続先リージョンの冗長化 - マルチ専用線パターン - | ・接続先リージョンの障害の影響を受けない。 ・Direct Connect ロケーションの障害の影響を受けない |
・複数の専用線を調達する必要があるためコストが高い。 ・オンプレミス側のネットワーク機器が増えるため管理に手間がかかる。 ・AWSリソースが増えるため管理に手間がかかる |
通信キャリアの冗長化
東京リージョンにてDirect Connect ロケーションへ接続するための回線を提供することができるパートナー(AWS Direct Connect デリバリーパートナー)から複数のパートナーを選択して通信キャリアの冗長化を実現することが可能です。パートナーの一覧は以下のドキュメントをご確認ください。
Direct Connect ロケーションの冗長化
通信キャリアから調達した専用線をAWSルータに接続するDCであるDirect Connect ロケーションを冗長化することが可能です。東京リージョンで利用可能なDirect Connect ロケーションは以下の5箇所です。
- AT Tokyo CC1 Chuo Data Center, Tokyo, Japan
- Chief Telecom LY, Taipei, Taiwan
- Chunghwa Telecom, Taipei, Taiwan
- Equinix OS1, Osaka, Japan**
- 大阪リージョンに接続するわけではないためご注意ください。
- 2021年9月7日現在、大阪リージョンに関連付けられた DXロケーション はありません
- またDirect Connect Gateway を経由して他リージョンに関連付けられた DXロケーション と大阪リージョンを接続することが可能です。
- Equinix TY2, Tokyo, Japan
詳細は以下のドキュメントをご確認ください。
例えば、Direct Connect ロケーションを大阪と東京の2つのロケーションに冗長化するとリージョンをまたぐ冗長化のように見えますが専用線接続の終端となる接続先リージョンは同じ東京リージョンであるためリージョン障害が発生した場合は同様に影響を受けるため注意が必要です。
専用線接続の冗長化
費用は高くなりますが専用線接続自体を増強することで冗長化を実現することが可能です。
接続方式の冗長化
Direct Connect のバックアップとしてAWS Site to Site VPNを利用することで接続方式を冗長化することが可能です。専用線接続の冗長化と比較してコストメリットが大きい冗長化方式です。
接続先リージョンの冗長化 - シングル専用線パターン - ※2021年9月8日修正
接続先リージョンを2つ以上確保することで冗長化することが可能です。この構成では1本の専用線を2つ以上のリージョンで利用します。
本構成において理解しておくべき点は以下の通りです。
Q.Direct Connect ゲートウェイを使用する場合、希望する AWS リージョンへのトラフィックは、関連する AWS のホームリージョンを経由しますか?
いいえ。Direct Connect ゲートウェイを使用する場合、ユーザーが接続している Direct Connect のロケーションに関連付けられた AWS のホームリージョンに関係なく、トラフィックは Direct Connect のロケーションから送信先の AWS リージョン間 (およびその逆方向で) の最短パスを取ります。
参考リンク:よくある質問 - AWS Direct Connect | AWS
本構成を例に取るとDirect Connect ロケーション からシンガポールリージョンへの最短パスを取ります。
接続先リージョンの冗長化 - マルチ専用線パターン - ※2021年9月8日修正
接続先リージョンを2つ以上確保することで冗長化することが可能です。この構成ではDirect Connect ロケーションも冗長化します。また東京リージョンで障害が発生してTransit Gateway に異常が発生する可能性まで想定するならばTransit Gateway もリージョンを分けて冗長化することも可能です。
冗長構成を取る上での注意点
- AWS側の設定によってオンプレミスと AWS 間の経路設定を行うことはできないため、基本的には経路設定を行う場合はお客様もしくはパートナーが保有しているネットワーク機器側で設定を行う必要があります
DX障害から再考する冗長構成
9月2日に発生したDX障害では影響範囲が東京リージョン全域に及びました。しかしながら東京リージョン内の個別のAWSリソースには直接的な影響がなかったため、Direct Connect を利用しないSite to Site VPN が暫定的な対応策として有効な手段となりました。本事象を踏まえるとオンプレミスと AWS 間の接続の冗長構成を考える上では接続方式の冗長化と接続先リージョンの冗長化を考慮した構成を取ることで障害の影響を緩和することができそうなので構成例を以下考えてみました。
前提条件
- 9月2日に発生したDX障害と同様の障害が再度発生することを想定する
1. Direct Connect ロケーション × 接続方式 の冗長化
Direct Connect ロケーション を冗長化することで専用線自体の障害やDirect Connect ロケーションが起因する障害の影響を受けることがなくなります。また接続方式を冗長化することで今回の障害のようにDirect Connect が東京リージョン全域に渡って影響が出た場合にバックアップ回線としてSite to Site VPNを用意しています。Site to Site VPN は Direct Connect よりも帯域が狭いためパフォーマンスの低下を招く恐れがありますが、Site to Site VPN を冗長化して負荷分散するとなるとさらにコストが発生してしまうためDirect Connect が復旧するまでの間に長時間の通信断を発生させないの副回線としての利用シーンを想定しています。
2. 接続先リージョン × 接続方式 の冗長化
Direct Connect ロケーション × 接続方式 の冗長化 では専用線を2本敷設していましたが、この冗長化ではコスト抑制の優先度が高い場合を想定しています。接続先リージョンは東京リージョンとシンガポールリージョンに分けることでリージョン障害の影響を排除します。リージョン間でActive - Active構成を取ると余計なコストが発生するため、障害発生時にリソースを迅速にプロビジョニングできるように予めCloudFormationテンプレートを用意したり、AWSコンソール画面を利用した構築手順を用意しておくことを想定しています。
3. 接続先リージョン × 接続方式 の冗長化 (Transit Gateway のリージョン間ピアリング)
2. 接続先リージョン × 接続方式 の冗長化 では障害発生時のリソースのプロビジョニングに時間がかかるためTransit Gateway のリージョン間ピアリングを利用してできるようにしておけば今回のようなDX障害時にはシンガポールリージョンから迂回して東京リージョン内のAWSリソースにアクセス可能になります。
本構成を採用する上では以下の点をご認識ください。
- DX障害発生時にはオンプレミス側のネットワーク機器の設定変更とTransit Gateway のピアリング間にStatic経路を追加する必要があります。
- 2021年9月9日現在、Transit Gateway のピアリング間の経路設定では動的ルーティングがサポートされていません。
Transit Gateway のリージョン間ピアリングについては以下のブログもご一読ください。
まとめ
今回はDX障害を受けてオンプレミスと AWS 間の接続の冗長構成について再考してみましたが、コストや管理/運用面から実際にどの組み合わせの冗長構成を選択するかはお客様の要件次第となりますのでご検討の際に本ブログがお役に立てば幸いです。
山﨑 翔平 (Shohei Yamasaki) 記事一覧はコチラ
2019/12〜2023/2までクラウドインテグレーション部でお客様のAWS導入支援を行っていました。現在はIE(インターナルエデュケーション)課にて採用周りのお手伝いや新卒/中途オンボーディングの業務をしています。2023 Japan AWS Top Engineers/2023 Japan AWS Ambassadors