コンテンツに移動
デベロッパー

クラウド ネットワークの設計に有用な 10 の考慮事項

2022年5月6日
https://storage.googleapis.com/gweb-cloudblog-publish/images/10tips.max-2600x2600.png
Google Cloud Japan Team

※この投稿は米国時間 2022 年 4 月 26 日に、Google Cloud blog に投稿されたものの抄訳です。

クラウド ネットワークの設計は、クラウド導入において非常に重要な部分となる場合があります。最終的にどのような設計になるかは、ユースケースによって異なりますが、前もって考察しておくことで、時間を節約し、今後発生し得る問題を回避できます。以下の 10 個のヒントでは、より優れたクラウド ネットワーク アーキテクチャを一から設計するための有用な情報をご紹介しています。

#1 - 自動モード ネットワークまたはカスタム ネットワーク

VPC ネットワークを作成する場合、現在、自動モードとカスタムモードの 2 つのオプションがあります。自動モード ネットワークは、10.128.0.0/9 の IPv4 アドレス範囲から各リージョンにサブネットを自動的に生成します。このタイプのネットワークは、他の自動モード VPC ネットワークに直接接続しない分離 VPC として使用できます。

VPC 同士を接続する際に、それらが同じ IP アドレスを持っている場合、アドレスが重複するという問題に直面します。これは、2 つの自動モード VPC ネットワークを一緒に接続した場合に発生する可能性があります。VPC ネットワークを他の環境に接続する予定がある場合、本番環境ではカスタムモード ネットワークの使用をおすすめします。これにより、IP アドレスとファイアウォール ルールを計画して制御できます。

#2 - 共有 VPC または VPC ネットワーク ピアリング

Google Cloud では、共有 VPC または VPC ネットワーク ピアリングの設計を使用して、プラットフォーム上でさまざまな VPC ネットワークを相互に接続できます。最初にどのオプションが最適か検討する必要があります。

共有 VPC では、ホスト プロジェクトを設定し、そこにサービス プロジェクトを接続できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_a89QjK3.max-800x800.max-800x800.png

セキュリティ基盤のブループリントでは、共有 VPC ネットワーク アーキテクチャをサンプル アーキテクチャとして使用しています。管理が一元化され、責任はサービス プロジェクトに委任できます。この機能により、ネットワーク管理者は、環境の IP アドレス、ファイアウォール ルール、その他のルーティング構成を管理できるようになります。

VPC ネットワーク ピアリングを使用すると、2 つの VPC ネットワーク間で接続できます。この機能は、Google Cloud のさまざまな組織やプロジェクトをサポートしています。ピアリングは 1-1 であり、推移的ではありません。動作の例としては、VPC B が VPC A と C に接続されている場合、VPC C と A は直接接続されていないため、VPC B を介して相互に通信することはできません。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_btureS8.max-700x700.max-700x700.png

また、VPC ネットワーク ピアリングには、VPC ネットワークへのピアリング最大数が 25 までであるなど、いくつかの制限事項があります。

VPC ネットワーク ピアリングを利用したサンプル アーキテクチャには、ハブ アンド スポーク ネットワーク アーキテクチャや、一元管理されたネットワーク アプライアンスを利用したアーキテクチャがあります。

#3 - VPN を利用するか、利用しないか

要件に応じて、バーチャル プライベート ネットワーク(VPN)を内部または外部のどちらで使用するか選択できます。Cloud VPN は設定が簡単で、その他の外部相互接続オプションよりも低コストです。また、高可用性(HA)構成にすることも可能です。トンネルごとに利用可能な帯域幅は 3 Gbit/秒ですが、複数のトンネルを組み合わせるとより高い帯域幅に達することができます。

#4 - 専用接続(Dedicated)かサービス プロバイダ接続(Partner)か

いずれの場合でも、社内チームとサービス プロバイダ チームによる作業が必要です。この作業には、納期に影響を及ぼす時限 SLA が定められているケースがあり、実際に相互接続が機能しなければならないタイミングを検討する必要があります。それに加えて、選択する際に考慮すべき点がいくつかあります。

  • 一般的な考慮事項

    • コロケーション施設内の設備の有無

    • 必要な帯域幅

    • SLA の必要性

    • VPC 内の接続を終了させる場所。例: 相互接続専用のプロジェクトで終了させるか、本番環境 VPC で直接終了させるか。これは、すぐに消失するプロジェクトがあり、その都度新しい接続を再プロビジョニングしないですむようにしたい場合に検討することをおすすめします。

  • その他の注意すべき考慮事項

    • 総費用。例: Google の費用、サービス プロバイダの費用。

こちらのドキュメントの Cloud Interconnect ソリューションを比較するセクションで、大まかな比較を確認できます。また、他のクラウド サービス プロバイダを Google Cloud に接続するためのパターンも確認できます。

#5 - 組織のポリシーと VPC Service Controls

組織のポリシーは、クラウド ネットワーク内のアクティビティを管理する非常に有効な方法です。組織のポリシー サービスを使用すると、組織のポリシー管理者はリソース階層のすべてのレベルで制約を構成できます。Compute Engine とネットワーキングに適用される制約があり、セキュリティと管理がより簡単になります。このような制約の一例として constraints/compute.vmExternalIpAccess があります。この制約では、外部 IP を使用できる VM を指定できます。

VPC Service Controls を使用すると、サービス境界を確立して BigQuery や Cloud Storage といったクラウド サービスのリソースへのアクセスを制御できます。これにより、特定のアクションが制限され、VPC のセキュリティが強化されます。

#6 - お客様所有 IP アドレスの使用(BYOIP)

この機能を使用すると、すでに所有している外部 IP アドレスを Google Cloud のサービスに使用できます。このオプションを利用する場合は、IP が必要になったタイミングで使用できるように、IP の転送にかかる時間を考慮してください。デプロイの計画セクションで、さらに詳しい情報をご確認ください。

#7 - DNS

DNS もネットワーク設計における主要な要素の一つです。DNS の設定方法によっては、クラウド環境やオンプレミス環境のクエリを解決するときに追加構成が必要になる場合があります。Cloud DNS は非常に柔軟で、利用環境でのニーズをサポートするように構成可能な、さまざまなゾーン転送オプションに対応しています。また、Google Cloud では DNS のベスト プラクティスも複数用意しています。設計の際にぜひ検討してください。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_8U4bMf0.max-1100x1100.max-700x700.png

#8 - 外部 IP アドレスの使用制限

外部 IP アドレスはインターネット ルーティングでき、リソースへの直接接続を可能にします。セキュリティ強化の観点から、外部 IP アドレスの使用を制限することを検討する必要があります。インターネットからプライベート ネットワークに接続できる複数のサービスがありますが、ここではその一部をご紹介します。

  • Cloud NAT。内部リソースが NAT ゲートウェイを経由してインターネットにアクセスできるようになります。

  • ロードバランサ。外部公開のエニーキャスト IP アドレスを持ち、接続されたバックエンド リソースにトラフィックを転送します。

  • Identity-Aware Proxy(IAP)。承認済みユーザーのみが許可されたリソースにアクセスできます。

#9 - IP アドレス管理

IP アドレスは、接続されたネットワーク上で一意である必要があります。VPC、オンプレミス、他のクラウドと接続する場合、IP 範囲を管理する必要があります。IP 管理には、追加の作業や IP アドレス管理 (IPAM)ツールが必要になる場合があります。IPAM ツールを使用することで、スケーリングの際の IP 管理が容易になります。

大規模な Kubernetes のデプロイには多くの IP が必要になります。このような環境では、IP アドレスの管理が非常に重要です。GKE で検討可能な IP アドレス管理戦略はこちらからご確認ください。

#10 - 利用している環境下での障害の見え方

組織の可用性の要件と BPC 要件は何でしょうか。サービスの性質によっては、高可用性(HA)が重要な要素になる場合があります。

障害がどのように見えるかという疑問を持つことで、ビジネス要件に基づいて予測される障害に合わせた設計方法を決定できます。高可用性が問題にならない場合、HA が最重要要件である環境とは大きく異なる設計になります。

これらのニーズを満たすために、Cloud DNS、マルチリージョン設計、自動スケーリング オプションを使用して追加構成の実施を要する場合があります。その場合には費用が発生しますが、HA 設計アーキテクチャで制御できます。審査に有用な障害復旧(DR)計画ガイドもあります。

https://storage.googleapis.com/gweb-cloudblog-publish/original_images/4_LE5QPTu_PkurpYn.gif

その他のヒント

上述の 10 のヒントに加えて、将来的なジネスの拡大も視野に入れることが賢明です。たとえば、企業買収、現環境のスケーリング、新製品のリリース、オンプレミスや他のクラウドへの接続などが挙げられます。ネットワークを拡張する際には、IP アドレス指定とルーティングが必須です。  この場合、次のような質問を検討する必要があります。

  • 新しい VPC ネットワーク、オンプレミス、他のネットワーク間で通信する必要があるか。

  • サービスに必要な IP アドレスは足りているか。

  • 外部に公開予定のシステムはいくつあるか。

  • 自身の無料メールアドレスの見え方を把握しているか。

  • Cloud Router が BGP 経由でいくつのルートをサポートできるか。

ほとんどの企業には戦略的な計画があり、それによって企業が取るべき行動や成長目標を決定しているはずです。これらのヒントは、将来の拡張計画に関する情報を得るための良い出発点になるでしょう。

Google Cloud での設計の詳細については、以下をご確認ください。


- Developer Relations エンジニア Ammett Williams
- Cloud ソリューション アーキテクト Jens Kuehlers
投稿先