翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Example Corp. Automotive のユースケース
このホワイトペーパーの本セクションでは、考慮事項、要件定義の質問、決定木をどのように活用すると、最適なハイブリッドネットワーク設計を決定できるかについて説明します。決定木への入力情報には要件を使用するため、それらを特定し、定義しておくことが重要です。要件を前もって定義しておけば、設計を何度も繰り返す必要がなくなります。設計の見直しが必要な場合にプロジェクトを完全に停止し、貴重なリソースを保留するなどの事態を最小限に抑えるには、あるいは、そうした事態の回避を理想とするなら、要件を把握しておくと良いでしょう。
このセクションでは、Example Corp. Automotive を説明用の顧客名として使用します。同社は、最初の分析プロジェクトを AWS にデプロイすることを検討しています。この分析プロジェクトで重点を置くのは、同社製の自動車から取得したデータに加え、自社のデータセンターにあるその他の既存データセットを分析することです。同社のアーキテクチャグループは当初、本番環境と開発環境をホストするには、AWS アカウント アカウント、Amazon VPC、少数のサブネットが必要になると考えていました。一方で、着手に意気込むプロジェクトチームは、可能な限りすぐにアクセスできる開発環境を求めていました。同社の目標は、3 か月後に本番環境での稼働を開始することです。
Example Corp. Automotive は、今後その他のプロジェクトでも AWS を使用する予定です。例えば、ERP システムと、仮想デスクトップインフラストラクチャ (VDI) に加え、20 のアプリケーションを、今後 6 か月間でオンプレミスから AWS に移行するなどを想定しています。追加するプロジェクトの要件の一部は、定義中の段階にありますが、AWS クラウド の利用が拡大することは明らかです。
アーキテクチャチームは、このホワイトペーパーで概説されている方法を活用することにし、各考慮事項で示されている要件定義の質問を使用して、設計上の意思決定に必要な入力情報を収集しました。
チームはまず、接続タイプ関連の要件を考察しました。次の表はそれらを大まかに示しています。
表 4 – Example Corp. Automotive の信頼性に関する入力情報
- ** **デプロイ完了までの時間****
- **要件定義の質問:** デプロイ完了までに、どれくらいの期間が必要か。数時間、数日、数週間、数か月
- **回答:** + **開発/テスト:** 1 か月
+ **本番:** 3 か月
- ** **セキュリティ** **
- **要件定義の質問:** セキュリティの要件とポリシーでは、AWS への接続についてインターネット経由の暗号化接続の使用を許可しているか。それともプライベートネットワーク接続の使用を義務付けているか。 / **回答:** + **開発/テスト:** Site-to-Site VPN を使用可能
+ **本番**: プライベートネットワークが必要
- **要件定義の質問:** プライベートネットワーク接続を利用する場合、ネットワーク層での転送中に暗号化を行える必要がありますか。 / **回答:** 不要。アプリケーション層の暗号化を使用する
- ** **SLA** **
- **要件定義の質問:** ハイブリッド接続の SLA では、サービスクレジットも定める必要があるか / **回答:** + **開発/テスト**: 定める必要はない
+ **本番**: 定める必要がある
- **要件定義の質問:** どの程度の稼働時間目標を設定するか。 / **回答:** + **開発/テスト**: 設定しない
+ **本番:** 99.99%
- **要件定義の質問:** ハイブリッドネットワーク全体で、稼働時間目標を遵守する必要があるか。 / **回答:** + **開発/テスト**: 設定しない
+ **本番**: 定める必要がある
- ** **パフォーマンス** **
- **要件定義の質問:** 必要なスループットはどれくらいか。 / **回答:** + **開発/テスト:** 100 Mbps
+ **本番:** 500 Mbps から 2 Gbps に拡大
- **要件定義の質問:** AWS とオンプレミスネットワーク間では、最大で、どの程度のレイテンシーを許容するか。 / **回答:** + **開発/テスト:** 厳しい要件は設定しない
+ **本番:** 30 ミリ秒未満
- **要件定義の質問:** 最大で、どの程度のネットワークジッターを許容するか。 / **回答:** + **開発/テスト:** 厳しい要件は設定しない
+ **本番:** 可能な限り最小にする
- ** **コスト** **
- **要件定義の質問:** 1 か月あたり、どれくらいの量のデータを AWS に送信するか。 / **回答:** + **開発/テスト:** 2 TB
+ **本番:** 20 TB から 50 TB に増量
- **要件定義の質問:** 1 か月あたり、どれくらいの量のデータを AWS から送信するか。 / **回答:** + **開発/テスト:** 1 TB
+ **本番:** 10 TB から 25 TB に増量
- **要件定義の質問:** この接続は永続的なものか。 / **回答:** Yes
要件を受け取ったアーキテクチャチームは、それを基に、図 9 の接続タイプの決定木に従って検討を進め、開発環境、テスト環境、本番環境の接続タイプを決定しました。本番環境については、当面の要件だけでなく将来の要件も考慮しました。開発およびテスト環境向けには、インターネット上にサイト間 VPN を確立します。また、本番環境構築のために、サービスプロバイダーと協力して、自社ネットワークを AWS Direct Connect に接続します。当初は、Direct Connect ホスト接続の使用を検討していましたが、[AWS が示す SLA](https://aws.amazon.com/directconnect/sla/) の要件を理由に、Direct Connect 専用接続を選択しました。
接続タイプ決定後の次のステップは、接続設計の選択に影響を与える要件を明確に示すことです。このプロセスは、ビジネスおよび技術上の要件に対応するにはどのように接続を構成し、どの AWS サービスを利用すべきかといった論理設計に関係があり、そうした設計に影響を与えます。
スケーラビリティと通信モデルの要件を明確にしようと、アーキテクチャチームは、このホワイトペーパーの関連セクションにある要件定義の質問を使用しました。次の表に、これら 2 つの考慮事項に関連する要件を大まかに示します。
表 5 - 要件定義に関する質問
- ** **スケーラビリティ** **
- **要件定義の質問:** オンプレミスサイトへの接続が必要な VPC の現在数または想定数は、どれくらいか。 / **回答:** 当初は 2。6 か月で 30 に増加すると想定
- **要件定義の質問:** これらの VPC は、1 つの AWS リージョン にデプロイされているか。あるいは、複数のリージョンにデプロイされているか。 / **回答:** 1 つのリージョン
- **要件定義の質問:** AWS に接続する必要があるオンプレミスサイトはいくつですか。 / **回答:** 2 か所のデータセンター
- **要件定義の質問:** AWS への接続が必要なカスタマーゲートウェイデバイスは、サイトごとに何台あるか。 / **回答:** データセンターごとに 2 台のルーター
- **要件定義の質問:** AWS VPC にアドバタイズするルートの数と、AWS 側から受信するルートの数はどれくらいになると想定しているか。 / **回答:** + **AWS にアドバタイズするルート:** 20 ルート
+ **AWS から受信するルート**: 1 `/16` ルート
- **要件定義の質問:** 近い将来、AWS への接続に必要な帯域幅の拡大を検討する予定はあるか。 / **回答:** + **開発/テスト:** 100 Mbps
+ **本番**: 500 Mbps から 2 Gbps に拡大
- ** **接続設計モデル** **
- **要件定義の質問:** VPC 間通信を (リージョン内および/またはリージョン間で) 有効にする必要はあるか。 / **回答:** AWS リージョン 内での有効化が必要
- **要件定義の質問:** オンプレミスから AWS パブリックエンドポイントサービスに直接アクセスする必要はあるか。 / **回答:** Yes
- **要件定義の質問:** オンプレミスから VPC エンドポイントを使用して AWS サービスにアクセスする必要はあるか。 / **回答:** No
アーキテクチャチームは、入力情報に従って、接続設計セクションの決定木をたどりました。今後 6 か月で VPC の数が 2 から 30 に増加すると予想した同チームは、接続および VPC 間のルーティングに使用する終端ゲートウェイとして AWS Transit Gateway の導入を決定しました。各 AWS Transit Gateway は、開発およびテスト環境用 VPN 接続と、AWS Direct Connect との本番環境用 VPN 接続で、独立した終端装置として機能します。独立した AWS Transit Gateway を使用すると、変更管理が簡素化されると共に、開発/テスト環境と本番環境との境界が明確になります。本番環境には AWS Direct Connect があるため、AWS Transit Gateway ゲートウェイが必要です。AWS パブリックエンドポイントサービスへのアクセスには、パブリック VIF を使用します。図 14 は、収集した要件に基づいて決定木をどのようにたどったかを示しています。
スケーラビリティと通信モデルの要件を満たすソリューションを決定したら、次のステップは、信頼性に関連する要件を明確に示すことです。このプロセスは、可用性と耐障害性がどの程度必要かに影響を与えます。
信頼性要件を明確にしようと、アーキテクチャチームは、このホワイトペーパーの関連セクションにある要件定義の質問を使用しました。次の表は、それらの要件を大まかに示しています。
表 6 - 信頼性要件に関する質問
- ** 信頼性 **
- **要件定義の質問:** AWS への接続で障害が発生した場合、ビジネスにどの程度の影響が及ぶか。 / **回答:** + **開発/テスト**: 影響は小さい
+ **本番**: 影響は大きい
- **要件定義の質問:** ビジネスの観点から考えると、AWS への接続で障害が発生した場合のコストは、高信頼性の接続モデルを AWS に展開するコストを上回るか。 / **回答:** + **開発/テスト**: 定める必要はない
+ **本番**: 定める必要がある
受け取った入力情報に基づいて、アーキテクチャチームは、このホワイトペーパーに示されている「信頼性に関する考慮事項」セクションの決定木をたどりました。本番環境向け接続の 99.99% という稼働時間目標と、サービスが中断した場合のビジネスへの大きな影響を考慮した結果、2 か所の Direct Connect ロケーションを使用し、各オンプレミスデータセンターから各 Direct Connect ロケーションに 2 つのリンクを設けることにしました (合計 4 リンク)。開発およびテスト環境用 VPN 接続でも、冗長性を高めるために 2 つの VPN 接続を使用します。接続は、「信頼性」セクションで説明したルートエンジニアリング手法を使用して、次のように構成します。
+ 開発およびテスト環境: プライマリデータセンターに向かう 2 つのトンネルで、ECMP によってトラフィックを負荷分散し、スループットを向上させます。セカンダリデータセンターに向かうトンネルは、プライマリトンネルに障害が発生した場合に使用します。
+ 本番環境: オンプレミスのレイテンシーと、いずかの Direct Connect ロケーション経由で AWS に接続するときのレイテンシーは、ほぼ同じです。この事例では、AWS とオンプレミス間のトラフィックをロードバランスすることにしました。ロードバランスは、プライマリデータセンターに向かう 2 つの接続で行い、これらのトラフィックを、プライマリデータセンター内に展開したオンプレミスシステムで使用します。同様に、セカンダリデータセンターで稼働するオンプレミスシステム向けにも、そのデータセンターまでを結ぶ 2 つの接続をロードバランスします。接続上の障害が発生した場合、BGP を利用して自動的にフェイルオーバーさせます。
図 15 は、収集した要件に基づいて決定木をどのようにたどったかを示しています。
