Zenn
NTT DATA TECH
📗

AWS Well-Architected Frameworkに基づくハイブリッドネットワーキング要点ガイド（後編）

Taishi Yamamoto
に公開
AWS
network
VPN
Direct Connect
hybridnetworking
tech

はじめに

本シリーズでは、Amazon Web Services (AWS) が提供しているAWS Well-Architected Frameworkのハイブリッドネットワーキングレンズを取り上げ、実際にどのような観点でチェックすべきか、そのポイントを前編と後編の2回にわたってご紹介します。本記事では、後編の信頼性、パフォーマンス効率、コスト最適化のチェックポイントについてご紹介します。

AWS Well-Architected Frameworkおよびハイブリッドネットワーキングレンズの概要については、前編の記事をご覧下さい。
https://zenn.dev/nttdata_tech/articles/a1497b549b3a7c

本記事で得られるメリット

ハイブリッドネットワーキングレンズは関連する追加のベストプラクティスが提供されていますが、「どのような時に何をすればよいか」が一目で分かりづらいことがあります。そこで、本記事はベストプラクティスをシンプルかつ明解なチェックポイントに要約し、それぞれのポイントをイメージしやすくするためにネットワーク構成上に表現しています。

上記のハイブリッドネットワーキングのベストプラクティスは下記サイトより引用しています。
(https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/hybrid-networking-lens/)

本記事をご覧いただくことで、ハイブリッドネットワークアーキテクチャの評価における効率と品質の向上に加えて、チーム間での円滑なコミュニケーションツールとしても役立つと考えています。自身が担当するプロジェクトでも、チーム内でハイブリッドネットワーキングデザインの基本方針やレビューの観点としてチェックポイントを活用し、大きな効果が確認できています。

以上を踏まえて、各チェックポイントを見ていきましょう。

信頼性

システムが停止した場合における影響を最小化し、迅速に検知し回復するためのプラクティスが含まれます。ポイントとしては、如何に本番で機能するかを検証するために、定期的なテストを通じた評価・改善が重要です。

(HN_REL1) どのようにサービスクォータは管理しますか？
  1. CloudWatch、SNS (Simple Notification Service) を用い、リソースのメトリクスをモニタリングし、クォータ引き上げのトリガーとなる閾値を超過した場合に通知しましょう。メトリクスが提供されていない場合、カスタムメトリクスとして送信するなどの代替策検討が必要です。
(HN_REL2) どのようにDirect Connectの定期メンテナンスやイベントに備えますか？
(HN_REL3) どのようにDirect Connectの帯域幅を調整し変更しますか？
(HN_REL4) どのようにDirect ConnectとSite-to-Site VPNをモニタリングしますか？
  1. CloudWatchでDirect ConnectやSite-to-Site VPNのログやメトリクスをモニタリングし、トラフィックの閾値超過や異常なイベント検知があった場合にSNSで通知しましょう。
  2. Direct Connectはメンテナンスで数分から数時間切断する可能性があるため、バックアップとしてDirect Connect、Site-to-Site VPNなどで冗長化しましょう。
  3. Direct Connect接続の帯域幅が不足する場合、LAGを検討しましょう。既存のDirect Connect接続をLAGに追加する場合、ダウンタイムが発生する場合があるためご注意下さい。
(HN_REL5) どのようにシステムは部品の故障に耐えますか？
(HN_REL6) どのように回復力をテストしますか？
(HN_REL7) どのように災害復旧を計画しますか？
  1. Direct Connectの接続 (ロケーション、ハードウェア、通信プロバイダ) やSite-to-Site VPNのトンネルは、メンテナンス時や故障時に備えて冗長化しましょう。
  2. Direct Connectの接続やSite-to-Site VPNのトンネルはアクティブ/アクティブ構成とし、十分な帯域を確保しましょう。故障時におけるパフォーマンス低下にご注意下さい。
  3. Direct ConnectのBGPフェイルオーバーテスト機能を用い、定期的に動作確認をしましょう。

パフォーマンス効率

要件に対して最適なリソースを選定し、モニタリングを通じてパフォーマンスを維持するためのプラクティスが含まれます。ポイントとしては、アーキテクチャやサービスの特性やトレードオフを理解し、ただ新しいものが良いというわけではなく、その時々で最適なものを選択できるかが重要です。

(HN_PERF1) どのようにDirect ConnectとSite-to-Site VPNを決定しますか？
(HN_PERF2) どのように帯域幅、レイテンシー、ジッターからパフォーマンス要件を定義しますか？
  1. 本番環境で高いパフォーマンス (高帯域、低レイテンシー、低ジッター) が求められる場合、Direct Connectを選択しましょう。パフォーマンスの要件を確認する方法として、既存データからの想定、システムオーナーへのヒアリングなどを実施しましょう。
  2. 開発環境でパフォーマンスよりもリードタイムやコストが求められる場合、Site-to-Site VPNを選択しましょう。ただし、Site-to-Site VPNのレイテンシーとジッターについては、Global Acceleratorで改善できる可能性があります。
(HN_PERF3) どのようにVPN接続されたアーキテクチャを選択しますか？
  1. 最大1.25Gbpsの帯域が必要となる場合、VGW (Virtual Private Gateway) およびSite-to-Site VPNでVPN接続することを検討しましょう。VGWは、複数VPNトンネル間でロードバランシングを実行することができません。
  2. 最大2.5Gbpsの帯域が必要となる場合、TGW (Transit Gateway) およびSite-to-Site VPNでVPN接続することを検討しましょう。TGWは、複数VPNトンネル間でロードバランシングをすることが可能です。
  3. 2.5Gbpsより大きい帯域が必要となる場合、仮想アプライアンスでVPN接続することを検討しましょう。ただし、EC2 (Elastic Compute Cloud) インスタンスのタイプ/サイズやVPNソフトウェアの仕様やライセンスなども考慮する必要があります。
(HN_PERF4) どのようにDirect Connectを活用したアーキテクチャを選択しますか？
  1. Direct Connectロケーションは、AWSリージョンやオンプレミスとの間でレイテンシーが最小化されるように選択しましょう。ただし、Direct Connectロケーションが冗長化される場合、地理的に離れた場所を選択することで可用性が高まるため、バランスを考慮しましょう。
  2. 50Gbpsより大きい帯域が必要な場合はPrivate VIF (Virtual Interface) を選択し、さらに極めて低いレイテンシーが必要な場合はローカルゾーンに接続しましょう。それ以外の場合は複数VPCへ接続できるTransit VIFを選択しましょう。
  3. Direct Connectの帯域幅を増加する場合、LAGもしくはECMPを検討しましょう。LAGは、100Gbps接続を最大2つ、10Gbps接続を最大4つ束ね、論理接続を1つ作ります。ECMPは、同じAS_PATH・BGPコミュニティを用い、複数の接続に等コストロードバランシングを行います。
  4. CloudWatchを用い、Direct ConnectやSite-to-Site VPNのメトリクスをモニタリングしましょう。パフォーマンスが想定通りでない場合、AWSサービスに関する問題はサービスチケットを開くことができます。
(HN_PERF5) どのようにローンチ後のパフォーマンスをモニタリングしスケーリングしますか？
  1. アプリケーションをローンチする前に帯域幅要件を確認し、ローンチした後にCloudWatchでトラフィックを追跡しましょう。
  2. Site-to-Site VPNでインターネットが輻輳し、レイテンシーやジッターが増加する場合、Global Accelerator有効化やDirect Connect移行を検討しましょう。
  3. Site-to-Site VPNで帯域幅が出ない場合、故障疑いであればVPNエンドポイントを交換し、帯域不足であればECMPロードバランシングによる増速を検討しましょう。
  4. Direct Connectの帯域幅を増加する場合、LAGもしくはECMPを検討しましょう。LAGおよびECMPは、HN_PERF4のチェックポイントと同様のため詳細を省略させていただきます。
  5. Direct Connectのアクティブ/アクティブ構成の場合は両系で帯域幅要件を50%ずつ充足し、アクティブ/パッシブ構成の場合は片系で帯域幅要件を100%充足するように構成しましょう。テストを通じて、アプリケーションのエクスペリエンスが低下しないことを確認することも重要です。
(HN_PERF6) どのようにパフォーマンスを向上させるためのトレードオフを利用しますか？
  1. ハイブリッド接続でコスト、リードタイムが求められる場合、Site-to-Site VPNを選択しましょう。
  2. ハイブリッド接続でパフォーマンスが求められる場合、Direct Connectを選択しましょう。
  3. VPN接続でコスト、構築と運用のシンプルさ、スケーラビリティとパフォーマンスが求められる場合、TGWおよびSite-to-Site VPNを選択しましょう。
  4. VPN接続でサードパーティ機能が求められる場合、仮想アプライアンスを選択しましょう。例えば、サードパーティ機能としてCISCOのDMVPN機能などが挙げられます。

コスト最適化

時間の経過に伴うコスト状況を管理し、適切なリソース選択とスケーリングを行うためのプラクティスが含まれます。ポイントとしては、継続的なモニタリングで可視化し、コスト削減のためのプロアクティブな改善活動へ繋げられることが重要です。

(HN_COST1) どのように利用状況をモニタリングしていますか？
(HN_COST2) どのように共有リソースのデータ転送コストを特定していますか？
  1. ハイブリッドネットワークに関わるデータ転送コストは、Cost & Usage ReportやVPC (Virtual Private Cloud) フローログで追跡しましょう。さらに、AthenaやQuick Sightで分析し可視化しましょう。
(HN_COST3) どのように最も費用対効果の高い接続要件を決定しますか？
  1. 高いコスト効率が求められる場合はSite-to-Site VPNを選択し、一貫性と広帯域が求められる場合はDirect Connectを選択しましょう。
  2. ワークロードのテスト時にSite-to-Site VPNを構築し、テストを通じて帯域幅要件が確認できた後にDirect Connectに移行するなど、費用対効果の高い段階的移行を検討しましょう。
  3. 接続先VPCが少ない場合、コストが抑えられるVGWを用いてハイブリッドネットワークを構築しましょう。TGWは利便性が高いものの、利用料が膨らむ可能性があるためご注意下さい。
(HN_COST4) どのようにリソースの供給と需要をマッチングさせますか？
(HN_COST5) どのようにトラフィックを優先順位付けしていますか？
  1. Direct Connect接続の増速は数週間以上のリードタイムが必要のため、早期に着手しましょう。
  2. 過少もしくは過剰のプロビジョニングを防ぐため、アプリケーションの需要情報を収集しましょう。それが難しい場合、変更または終了しやすいSite-to-Site VPNを検討しましょう。
  3. 接続拠点数によって、MPLSなどの多拠点接続を可能にするネットワークを検討しましょう。帯域幅を増やす場合、LAGやECMPを検討しましょう。
  4. ハイブリッドネットワークに流入するトラフィックが帯域幅を超える場合、オンプレミスルータなどでQoSや最低保証帯域を設定しましょう。
(HN_COST6) どのようにアーキテクチャを設計していますか？
(HN_COST7) どのようにアーキテクチャを最適化していますか？
  1. Site-to-Site VPNは、データ転送料としてEC2料金がアウトバンド方向のみ発生することを理解し、コストを試算しましょう。Global Acceleratorを有効化した場合、プレミアムデータ転送料としてEC2料金が別途発生しますのでご注意下さい。[1][2][3]
  2. Direct Connectは、データ転送料としてDirect Connect料金がアウトバンド方向のみ発生することを理解し、コストを試算しましょう。[4]
  3. VGW/TGWともデータ転送料が発生しないものの、TGWはデータ処理料としてTGW料金が発生することを理解し、コストを試算しましょう。[5]

まとめ

本記事では、AWS Well-Architected ハイブリッドネットワーキングレンズの信頼性、パフォーマンス効率、コスト最適化のチェックポイントについてご紹介しました。本記事をもって、AWS Well-Architected ハイブリッドネットワーキングレンズのシリーズはすべて終了となります。

AWSサービスの進化は急速であり、短期間でベストプラクティスがアンチパターンに転じることもあります。定期的なアーキテクチャ見直しの際には、本記事で紹介した内容を思い出していただき、効率的かつ高品質なチェックに活かしていただけると幸いです。

脚注

  1. Site-to-Site VPN料金
    (https://aws.amazon.com/jp/vpn/pricing/) ↩︎

  2. Global Accelerator料金
    (https://aws.amazon.com/jp/global-accelerator/pricing/) ↩︎

  3. EC2料金
    (https://aws.amazon.com/jp/ec2/pricing/) ↩︎

  4. Direct Connect料金
    (https://aws.amazon.com/jp/directconnect/pricing/) ↩︎

  5. TGW料金
    (https://aws.amazon.com/jp/transit-gateway/pricing/) ↩︎

NTT DATA TECH
NTT DATA TECH

NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。

Discussion