翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
信頼性
定義
信頼性とは、サービスまたはシステムが必要に応じて期待どおりの機能を実行する能力を指します。システムの信頼性は、特定の期間における運用品質のレベルによって測定できます。これを回復性と比較してください。回復性とは、インフラストラクチャやサービスの中断から動的かつ確実に回復するシステムの能力を指します。
可用性と耐障害性を使用して信頼性を測定する方法の詳細については、 AWS Well-Architected フレームワークの信頼性の柱を参照してください。
重要な質問
可用性
可用性は、ワークロードが使用可能な時間の割合です。一般的な目標としては、99% (年間に許容されるダウンタイムの日数 3.65 日)、99.9% (8.77 時間)、99.99% (52.6 分) があり、そのうち 9 の数字を省略しています (「ツーナイン」は 99%、「スリーナイン」は 99.9% など)。 AWS とオンプレミスデータセンター間のネットワークソリューションの可用性は、全体的なソリューションやアプリケーションの可用性とは異なる場合があります。
ネットワークソリューションの可用性に関する重要な質問には以下があります。
-
オンプレミス AWS リソースと通信できない場合、リソースは引き続き運用できますか？ その逆も可能ですか。
-
計画的なメンテナンスのための予定されたダウンタイムは可用性指標に含めるべきですか、それとも除外すべきですか。
-
アプリケーション全体の状態とは別に、ネットワーク層の可用性を測定する方法を教えてください。
Well-Architected フレームワーク信頼性の柱の「可用性」セクションには、計算の可用性に関する提案と公式が掲載されています。
回復性
回復性は、インフラストラクチャまたはサービスの中断から復旧し、需要に合わせて動的にコンピューティングリソースを取得し、設定ミスや一時的なネットワーク問題のような障害を軽減するワークロードの能力です。冗長ネットワークコンポーネント (リンク、ネットワークデバイスなど) がそれ自体では期待どおりの機能を提供するのに十分な可用性を備えていない場合、障害に対する回復性は低くなります。その結果、ユーザーエクスペリエンスが低下します。
ネットワークソリューションの回復性に関する重要な質問には以下があります。
-
同時に発生する個別の障害はいくつまで許容すべきですか。
-
接続ソリューションと社内ネットワークの両方で単一障害点を減らすにはどうすればよいでしょうか。
-
分散サービス拒否 (DDoS) イベントに対する脆弱性は何ですか？
テクニカルソリューション
まず、すべてのハイブリッドネットワーク接続ソリューションが高レベルの信頼性を必要とするわけではなく、信頼性のレベルが上がるとそれに応じてコストも増加することに注意することが重要です。シナリオによっては、ダウンタイムがビジネスに与える影響が大きいため、プライマリサイトには信頼性の高い (冗長で耐障害性のある) 接続が必要になることがあります。一方、地域のサイトでは、障害発生時のビジネスへの影響が少ないため、同じレベルの信頼性を必要としない場合があります。 AWS Direct Connect 設計に対する高いAWS Direct Connect 耐障害性を確保するためのベストプラクティスを説明するため、耐障害性に関する推奨事項
回復性の観点から信頼性の高いハイブリッドネットワーク接続ソリューションを実現するには、設計時に次の点を考慮する必要があります。
-
冗長性： ネットワーク接続、エッジネットワークデバイス、アベイラビリティーゾーン間の冗長性、DX ロケーション、デバイス電源、ファイバーパス AWS リージョン、オペレーティングシステムなど、ハイブリッドネットワーク接続パスの単一障害点を排除することを目指します。このホワイトペーパーの目的と範囲について、冗長性はネットワーク接続、エッジデバイス (カスタマーゲートウェイデバイスなど）、 AWS DX ロケーション、 AWS リージョン （マルチリージョンアーキテクチャの場合) に焦点を当てています。
-
信頼性の高いフェイルオーバーコンポーネント: シナリオによっては、システムが機能していても、必要なレベルでその機能を実行していない場合があります。このような状況は、単一の障害イベントで、計画された冗長コンポーネントが非冗長的に動作していたことが判明したときによく見られます。つまり、使用状況により、ネットワーク負荷が他に行き場がなく、その結果ソリューション全体の容量が不十分になります。
-
フェイルオーバー時間: フェイルオーバー時間は、セカンダリコンポーネントがプライマリコンポーネントの役割を完全に引き継ぐまでにかかる時間です。フェイルオーバー時間には、障害を検出するまでにかかる時間、セカンダリ接続を有効にするまでの時間、変更をネットワークの残りの部分に通知する期間など、複数の要因があります。リンクにはデッドピア検出 (DPD）、VPNリンクには双方向転送検出 (BFD) を使用して、障害検出を改善できます AWS Direct Connect 。セカンダリ接続を有効にする時間は、非常に短い場合 (これらの接続が常にアクティブである場合）、短い時間枠 (事前設定済みのVPN接続を有効にする必要がある場合）、または長い場合 (物理リソースを移動する必要がある場合、または新しいリソースを設定する必要がある場合) です。ネットワークの残りの部分への通知は、通常、お客様のネットワーク内のルーティングプロトコルを介して行われ、それぞれコンバージェンス時間と設定オプションが異なります。これらの設定はこのホワイトペーパーの範囲外です。
-
トラフィックエンジニアリング: 回復性に優れたハイブリッドネットワーク接続設計におけるトラフィックエンジニアリングは、通常のシナリオと障害シナリオにおいて、利用可能な複数の接続上でトラフィックがどのように流れるかを扱うことを目的としています。さまざまな障害シナリオでソリューションがどのように動作するか、またそれがビジネスで受け入れられるかどうかを検討する必要がある、障害に備えた設計の概念に従うことが推奨されます。このセクションでは、ハイブリッドネットワーク接続ソリューションの全体的な回復性レベルを高めることを目的とした、一般的なトラフィックエンジニアリングのユースケースについて説明します。AWS Direct Connect ルーティングのセクションと ではBGP、トラフィックフロー (コミュニティ、BGPローカル設定、AS パス長) に影響を与えるためのいくつかのトラフィックエンジニアリングオプションについて説明します。効果的なトラフィックエンジニアリングソリューションを設計するには、各 AWS ネットワークコンポーネントがルートの評価と選択の観点から IP ルーティングをどのように処理するか、およびルートの選択に影響を与える可能性のあるメカニズムを十分に理解する必要があります。これについての詳細は、このドキュメントの対象外です。詳細については、「Transit Gateway Route Evaluation Order 」、Site-to-Site VPN「Route Priority 」、および必要に応じて Direct Connect Routing とBGPドキュメントを参照してください。
注記
VPC ルートテーブルでは、追加のルート選択ルールを含むプレフィックスリストを参照できます。このユースケースの詳細については、プレフィックスリストのルート優先度を参照してください。 AWS Transit Gateway ルートテーブルはプレフィックスリストもサポートしていますが、適用すると特定のルートエントリに展開されます。
より具体的なルートを含むデュアル Site-to-SiteVPN接続の例
このシナリオは、インターネット経由で への冗長な単一の AWS リージョン VPN接続に接続する小規模なオンプレミスサイトに基づいています AWS Transit Gateway。図 10 に示すトラフィックエンジニアリング設計は、次のような方法でパスの選択に影響を与え、ハイブリッド接続ソリューションの信頼性を高めることができることを示しています。
-
回復力のあるハイブリッド接続: 冗長VPN接続はそれぞれ同じパフォーマンス容量を提供し、動的ルーティングプロトコル (BGP) を使用して自動フェイルオーバーをサポートし、VPNデッドピア検出を使用して接続障害の検出を高速化します。
-
パフォーマンス効率: 両方のVPN接続ECMPで を設定することで、 AWS Transit Gateway VPN接続帯域幅全体を最大化できます。または、サイト概要ルートとともに異なる、より具体的なルートをアドバタイズすることで、2 つのVPN接続間で負荷を独立的に管理できます。
図 10 – より具体的なルートを含むデュアル Site-to-SiteVPN接続の例
複数の DX 接続を使用するデュアルオンプレミスサイトの例
図 11 に示すシナリオは、異なる地理的リージョンにあり、 と AWS を使用して最大耐障害性接続モデル (AWS Direct Connect 「耐障害性に関する推奨事項」に記載
BGP コミュニティ属性を にアドバタイズされたルートに関連付けることで AWS DXGW、エグレスパスの選択を横から AWS DXGW行うことができます。これらのコミュニティ属性は、アドバタイズされたルートに割り当てられた AWSのBGPローカル設定属性を制御します。詳細については、 AWS 「DX ルーティングポリシーとBGPコミュニティ」を参照してください。
AWS リージョン レベルでの接続の信頼性を最大化するために、各 AWS DX 接続ペアは、各オンプレミスサイトと 間のデータ転送に両方を同時に利用できるECMPように を設定します AWS。
図 11 – 複数の DX 接続を使用するデュアルオンプレミスサイトの例
この設計では、オンプレミスネットワーク (アドバタイズされたプレフィックスの長さとBGPコミュニティが同じ) 宛てのトラフィックフローは、 を使用してサイトあたりのデュアル DX 接続に分散されますECMP。ただし、DX 接続全体で が必要ECMPでない場合は、先に説明し、Routing ポリシーとBGPコミュニティドキュメントで説明されているのと同じ概念を使用して、DX 接続レベルでパス選択をさらに設計できます。
注: オンプレミスデータセンター内のパスにセキュリティデバイスがある場合、これらのデバイスは、トラフィックフローが 1 つの DX リンクを経由し、同じデータセンターサイト内の別の DX リンク ( で使用されているリンクの両方ECMP) から送信されるように設定する必要があります。
VPN AWS DX 接続へのバックアップとしての接続の例
VPN は、接続への AWS Direct Connect バックアップネットワーク接続を提供するように選択できます。通常、このタイプの接続モデルは、インターネットを介した不確定なパフォーマンスによりハイブリッド接続ソリューション全体の信頼性が低く、パブリックインターネットを介した接続で取得SLAできるものがないため、コストによって駆動されます。これは有効で費用対効果の高い接続モデルであり、コストが最優先で予算が限られている場合や、セカンダリ DX をプロビジョニングできるようになるまでの暫定的なソリューションとして使用できます。図 12 は、この接続モデルの設計を示しています。この設計では、 VPN と DX 接続の両方が で終了する場合 AWS Transit Gateway、VPN接続は に接続された DX 接続を介してアドバタイズできるルートと比較して、より多くのルートをアドバタイズできるという重要な考慮事項があります AWS Transit Gateway。これにより、最適なルーティング状況にならない可能性があります。この問題を解決するオプションは、VPN接続から受信したルートに対してカスタマーゲートウェイデバイス (CGW) でルートフィルタリングを設定し、サマリールートのみを受け入れることです。
注: で概要ルートを作成するには AWS Transit Gateway、概要がより特定のルートに沿って送信されるように、 AWS Transit Gateway ルートテーブル内の任意のアタッチメントへの静的ルートを指定する必要があります。
AWS Transit Gateway ルーティングテーブルの観点からは、オンプレミスプレフィックスのルートはVPN、同じプレフィックス長の AWS DX 接続 ( 経由DXGW) と の両方から受信されます。のルート優先度ロジック AWS Transit Gatewayに従って、Direct Connect 経由で受信されたルートは、 経由で Site-to-Site受信されたルートよりも優先されるためVPN、 経由のパスがオンプレミスネットワーク (複数可) に到達するのが優先 AWS Direct Connect されます。
図 12 – AWS DX VPN接続へのバックアップとしての接続の例
以下の決定木では、回復性のある (その結果として信頼性の高い) ハイブリッドネットワーク接続を実現するための必要な決定を下す手順を示しています。詳細については、「AWS Direct Connect Resiliency Toolkit」を参照してください。
図 13 - 信頼性の決定木
