Google Cloud 上の SAP: シームレスなデプロイのためのネットワーク設定
Google Cloud Japan Team
※この投稿は米国時間 2021 年 9 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。
SAP は非常に多くの企業の重要なバックボーンを形成し、財務、サプライ チェーン、倉庫管理などの重要なビジネス機能をサポートしています。Google Cloud はそのようなワークロードを実行するためのスケーラビリティと復元性の高いインフラストラクチャを提供し、またスマート アナリティクスや機械学習などのツールを提供することで、組織のデジタル トランスフォーメーションを促進します。
Forrester が実施した最近の調査では、Google Cloud 上で SAP を実行することで、既存インフラストラクチャの費用節約、ダウンタイムの回避、生産性の向上によって 160% の投資収益率と 6 か月以下の投資回収期間が実現することがわかっています。
SAP システムをどのようにネットワーク全体にデプロイするかは、可用性、復元性、パフォーマンスに非常に大きく影響します。個別の本番環境と高可用性（HA）環境に加えて、SAP のデプロイには、一般的に、サンドボックス、開発、品質保証（QA）、障害復旧の環境も含まれます。
Google ネットワークの大部分は仮想であるため、SAP 管理者は組織の SAP デプロイと組織構造に適合した複雑な環境を簡単に設計し、同時にセキュリティとオペレーションの要件を満たすことができます。
Google Cloud 上の SAP を開始する際、さまざまな SAP システムの可用性とパフォーマンスを確保するにはネットワーキングをどのように構成するかを決定する必要があります。以下に説明するオプションをご確認ください。
VPC と共有 VPC
Virtual Private Cloud（VPC）は、Google Cloud 内でホストされる安全で隔離されたプライベート ネットワークです。VPC は Google Cloud 内でグローバルであり、単一の VPC が、公共のインターネットを経由することなく複数のリージョンにまたがった通信を実現できます。同様に、サブネットはリージョン内の複数のゾーンにまたがって機能できます。1 つのゾーンは 1 つの障害発生ドメインを表すため、一般的な SAP デプロイでは、本番環境用システムと HA システムを別のゾーンに設置して復元性を確保します。本番環境用システムと HA システムの両方を含むサブネットは複数のゾーンにまたがっていることがあるため、Google Cloud はこのタイプのデプロイを簡素化します。
この機能は SAP のクラスタリングも簡素化します。クラスタの仮想 IP（VIP）アドレスは、本番環境用システムと HA システムの範囲と同じ範囲にある場合があるためです。この構成は Google の内部ロードバランサを使用してフローティング IP を保護し、アプリケーション レイヤ（ASCS と ERS）と HANA データベース レイヤ（HANA プライマリとセカンダリ）の HA クラスタリングに適用できます。
共有 VPC は Google Cloud 独自の機能で、組織が複数のプロジェクトのリソースを共通の VPC ネットワークに接続できるようにします。この機能により、リソースは内部 IP を使用して安全かつ効率的に相互通信ができます。また、ホスト プロジェクトのすべての SAP プロジェクト（サービス）のためのネットワークを一元的にコントロールでき、同時にファイアウォールを使用して同じサブネット内の Compute Engine 間、異なるサブネット内の Compute Engine 間の通信を検査できます（ベスト プラクティスはこれらのシステム間の通信を必要なポートのみに制限することです。一般的に、これはレイヤ 4 で SAP のリモート関数呼び出し（RFC）通信経由で行います）。
ネットワークを設計するときは、まず 1 つ以上の共有 VPC ネットワークを含むホスト プロジェクトから始めます。ホスト プロジェクトに追加のサービス プロジェクトを接続することで、それらの追加プロジェクトが共有 VPC に参加できます。組織内の異なる部門やチームが別々のサービス プロジェクトを運営管理するのはよくあることです。
ニーズによって、SAP を単一または複数の共有 VPC にデプロイできます。これらの 2 つのシナリオは、ネットワーク コントロール、SAP 環境分離、ネットワーク検査において異なります。これらの違いについて詳しく見てみましょう。
シナリオ 1: SAP を単一の共有 VPC にデプロイする
1 つのネットワークの検査のみが必要な場合は、SAP を単一の共有 VPC にデプロイするほうが、シンプルさという利点があり、また、管理オーバーヘッドを減らすことができます。
ネットワーク コントロール: 共有 VPC はネットワーク ハブとして機能し、本番環境と非本番環境の両方で、ネットワーク チームの Identity Access Management（IAM）ロールに基づいて、一元的なネットワーク管理を可能にします。
SAP 環境分離: 各 SAP 環境に、プロジェクトとサブネットを作成できます。プロジェクトはリソースのグループ化を支援し、より細かい IAM コントロールと請求の可視化を実現できるようにします。同時に、サブネットが個々の SAP 環境のネットワーク分離を提供します。サービス プロジェクトでは、デフォルトで Compute Engine が通信可能ですが、シンプルなファイアウォールのルールを導入して、1 つのサブネット内にある、または別個のサブネット内にある Compute Engine 間の通信をブロックすることができます。
ネットワーク検査: Google Cloud ファイアウォールを使用して、必要なポートのみに SAP システム間の通信を許可することができます。ネットワーク タグとサービス アカウントを利用して、North-South トラフィックと East-West トラフィックの両方をきめ細かく制御できます。
シナリオ 2: 複数の共有 VPC での SAP のデプロイ
追加のネットワーク検査を必要とするシナリオでは、複数の共有 VPC を作成できます（一般的に環境ごとに 1 つずつ作成）。これらの共有 VPC 間でピアリングを使用して、SAP 環境、QA、本番環境用システムの間で RFC 通信を有効にできます。
ネットワーク分離: 複数の共有 VPC は、Google Cloud ファイアウォールで開かれている特定のポートを除いて、互いに完全に分離されています。これにより、Google Cloud ネットワーク内でネットワーク仮想アプライアンス（NVA）による East-West のトラフィック検査が可能になります。
ネットワーク コントロール: 共有 VPC の数が増えると、ピアリングなどのアクティビティやファイアウォール ポリシーも増えます。これは、共有 VPC が提供する一元的なネットワーク コントロールの効果を減少させるため、ネットワーク チームは各 VPC で個別にポリシーを管理する計画を立てる必要があります。
「本番環境に 1 つの共有 VPC があり、すべての非本番環境用システムに 1 つの共有 VPC がある」といった複数のシナリオの融合も可能です。このような組み合わせは、本番環境用システムと非本番環境用システムの間のネットワーク検査を可能にし、一元的ネットワーク管理レイヤの数を 2 つに制限します。
複数の SAP システムのためのネットワーキング環境を構成することは、複雑なプロセスとなる場合があります。Google Cloud の共有仮想クラウドとその他のツールによって、SAP 管理者は、クラウドのデプロイにロジック、復元力、可視性をもたらす、スケーラブルで安全なネットワークを作成できます。
これらのネットワーキング機能と SAP のお客様向けの Google のサービスについて、詳細をご覧ください。
-Google Cloud カスタマー エンジニア Tinu Anand Chandrasekar
