ネットワーキングのベスト プラクティス

このドキュメントでは、AI Hypercomputer ワークロードの安全で復元性に優れたネットワーキング環境を作成するためのベスト プラクティスについて説明します。これらの推奨事項は、AI Hypercomputer で人工知能（AI）と機械学習（ML）のワークロードを構成してデプロイするネットワーク アーキテクト、ネットワーク エンジニア、デベロッパーを対象としています。

明確で制限された IAM ロールを確立する

IAM を正しく構成すると、AI Hypercomputer デプロイのセキュリティと成功を向上させることができます。本番環境では、権限が不十分または誤って構成されていると、デプロイが失敗する可能性があります。AI Hypercomputer デプロイ、特に Cluster Toolkit を使用するデプロイは、デフォルトの Compute Engine サービス アカウントに広範な Editor ロールがない、 セキュリティが強化された環境で失敗することがよくあります。

権限の問題が原因で発生する可能性のあるデプロイの問題を軽減するには、このセクションに記載されているベスト プラクティスに従ってください。

専用のサービス アカウントを使用する

セキュリティと制御を強化するため、デフォルトの Compute Engine サービス アカウントは使用しないでください。代わりに、AI Hypercomputer デプロイ専用のサービス アカウントを作成します。

サービス アカウント トークンを使用する代わりに、マネージド Workload Identity を使用してワークロードを認証および認可できます。詳細については、ワークロードの認証 に mTLS を使用する Compute Engine または Workload Identity を GKE でご覧ください。

必要な IAM ロールを付与する

作成した専用のサービス アカウントに次の IAM ロールを付与します。

  • Compute 管理者 （roles/compute.admin）: Compute Engine リソースを完全に制御できます。
  • サービス アカウント ユーザー （roles/iam.serviceAccountUser）: サービス アカウントを他のリソースに接続できます。これは、カスタム イメージの作成時に Packer などのツールで重要になります。
  • ストレージ管理者 （roles/storage.admin）: Packer イメージやその他のアーティファクトを保存するなど、Cloud Storage バケットへのアクセスと管理が必要です。
  • Logging 管理者 （roles/logging.admin）: サービス アカウントでロギングを構成してログを表示できます。これはデバッグに不可欠です。

デプロイする前に権限を確認する

デプロイを開始する前に、サービス アカウントに必要な権限があることを確認します。gcloud projects get-iam-policy command コマンドを実行します。

gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \ format='table(bindings.role)' \
    --filter="bindings.members:serviceAccount:SERVICE_ACCOUNT_EMAIL"

次のように置き換えます。

  • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
  • SERVICE_ACCOUNT_EMAIL: 確認するサービス アカウントのメールアドレス。

このコマンドを実行すると、指定したプロジェクトのサービス アカウントに付与されたすべてのロールが一覧表示されます。必要な IAM ロールを付与するに記載されているロールが出力に表示されていることを確認します。

公共ネットワークのアクセスを制限し、ファイアウォール構成を強化する

公共ネットワークのアクセスを制限し、ファイアウォール構成を強化してセキュリティを強化します。この基本的なセキュリティ対策により、制限が緩すぎるデフォルトのファイアウォール ルールのリスクを軽減できます。

内部テストでは存在しない制限の厳しいファイアウォール構成が原因で、本番環境で仮想マシン（VM）の設定が失敗することがあります。特定のファイアウォール ルールがわからないと、エンジニアがこれらの障害を診断するのが難しい場合があります。

ファイアウォール ルールを確認し、インターネットへの直接公開が最小限になるように更新します。VPC ファイアウォール ルールの詳細については、 VPC ファイアウォール ルールをご覧ください。

内部ネットワーキングのデフォルト設定を標準化する

内部ネットワーキングのデフォルト設定を標準化して、リスクと構成の課題を軽減します。デフォルトのネットワーキング動作は、複雑な環境やセキュリティが強化された環境でリスクや構成の課題を引き起こす可能性があります。Google では次の構成をおすすめします。

  • ゾーン DNS を使用する: 新しいプロジェクトの場合は、内部ドメイン ネーム システム（DNS）をゾーン DNS のみに設定します。このアプローチは、グローバル DNS の停止による影響を軽減するのに役立ちます。ゾーン DNS の使用の詳細については、 ゾーン DNS の使用の概要をご覧ください。
  • 外部 IP アドレスを無効にする: 可能であれば、外部 IP アドレスを無効にします。IP アドレスを無効にする前に、マネージド インスタンス グループ（MIG）やパブリック ノードを持つ GKE クラスタなど、一部のサービスが IP アドレスに依存しているため、ステージング環境で慎重に計画してテストする必要があります。パブリック IP アドレスの制限の詳細については、Google Cloud でのパブリック IP アドレスの制限をご覧ください。

インフラストラクチャごとにネットワーキングを最適化する

デプロイのネットワーキングのベスト プラクティスは、インフラストラクチャの選択（一般的な GPU またはクラスタ化された GPU）によって異なります。

一般的な GPU のベスト プラクティス

一般的な GPU を使用する場合は、次のネットワーキングのベスト プラクティスに従ってください。

  • コンパクトな配置ポリシーを使用する: 一般的な GPU インスタンスが physicalHost ID を報告しない場合は、コンパクトな配置ポリシー を使用してインスタンス グループを識別し、これらのリソースのパフォーマンスを最適化します。 詳細については、インスタンスの配置を定義するをご覧ください。
  • ホスト通信に Google Virtual NIC（gVNIC）を使用する: 一貫した パフォーマンスを実現するため、すべてのホスト間 通信に gVNIC 経由の標準 TCP/IP を使用します。gVNIC の詳細については、Google Virtual NIC の使用をご覧ください。
  • 単一 VPC アーキテクチャで簡素化する: 分離 要件で別の方法が指定されていない限り、すべての通信に標準の単一 VPC ネットワークを使用します。この単一 VPC の推奨事項は、G2、G4、A2、N1 シリーズに適用されます。A3 Edge は例外で、4 つのデータ VPC と GPUDirect-TCPX が必要です。詳細については、Standard モードのクラスタで GPU ネットワーク帯域幅を最大化するをご覧ください。

クラスタ化された GPU のベスト プラクティス

クラスタ化された GPU を使用する場合は、次のネットワーキングのベスト プラクティスに従ってください。

  • マルチ VPC 環境を実装する: GPU 間 トラフィックを専用の高帯域幅 VPC に分離して、 ホスト トラフィックやストレージ トラフィックが帯域幅を競合しないようにします。詳細については、マルチ VPC 環境をご覧ください。
  • RDMA 最適化ネットワーク プロファイルを適用する: Google マネージド ネットワーク プロファイルを使用して、RDMA over Converged Ethernet（RoCE）に必要な低 レイテンシを実現するように VPC を自動的に構成します。詳細については、特定のユースケース向けのネットワーク プロファイルをご覧ください。
  • インフラストラクチャ タスクをオフロードする: カスタム Titanium NIC を使用して、ネットワーク パケットの処理やストレージの仮想化などのタスクを オフロードし、AI アプリケーション用に CPU サイクルを予約します。

ベスト プラクティスの概要

次の表に、このドキュメントで推奨するベスト プラクティスをまとめます。

トピック タスク
IAM 明確で制限された IAM ロールを確立する
ファイアウォール 公共ネットワークのアクセスを制限し、ファイアウォール構成を強化する
ネットワークのデフォルト 内部ネットワーキングのデフォルト設定を標準化する
インフラストラクチャ インフラストラクチャごとにネットワーキングを最適化する

次のステップ