このドキュメントでは、 Google Cloudの Compute Engine VM で Oracle Database を使用して Oracle E-Business Suite アプリケーションを実行するインフラストラクチャを構築するためのリファレンス アーキテクチャについて説明します。Oracle E-Business Suite は、財務、人事、サプライ チェーン、顧客関係などのビジネス機能向けのエンタープライズ アプリケーション スイートです。
このドキュメントは、Oracle データベースと Oracle E-Business Suite アプリケーションのクラウド アーキテクトと管理者を対象としています。このドキュメントは、チームが Oracle Database と Oracle E-Business Suite の技術スタックとアーキテクチャに精通していることを前提としています。
Oracle Exadata または Oracle Real Application Clusters（Oracle RAC）を使用する必要がある場合は、アプリケーションを Google Cloud に移行し、Oracle Database@Google Cloud でデータベースを実行できます。詳細については、 Google Cloudでの Oracle E-Business Suite と Oracle Exadata の使用をご覧ください。
アーキテクチャ
ユースケース、可用性と障害復旧（DR）の要件に応じて、次のいずれかの Google Cloudデプロイ アーキタイプを選択して、Oracle E-Business Suite アプリケーションを実行できます。 Google Cloud
- ゾーン: アプリケーションは単一の Google Cloudゾーン内で実行されます。このデプロイ アーキタイプは、開発環境やテスト環境に適しています。また、クリティカルでなく高可用性を必要としないアプリケーションにも適しています。
- リージョン: アプリケーションは、単一の Google Cloudリージョン内の複数のゾーンで独立して実行されます。ミッション クリティカルではないものの、ゾーンの停止に対する堅牢性が必要なアプリケーションには、このデプロイ アーキタイプをおすすめします。
- マルチリージョン: アプリケーションは、2 つ以上の Google Cloud リージョンの複数のゾーンで、アクティブ / アクティブまたはアクティブ / パッシブモードのいずれかで独立して実行されます。このデプロイ アーキタイプは DR シナリオに最適です。リージョンの停止や障害に対する復元力を必要とするミッション クリティカルなアプリケーションには、このアーキタイプをおすすめします。
デプロイ アーキタイプを選択すると、アーキテクチャに必要な Google Cloud プロダクトと機能に関するその後の決定を簡単に行うことができます。
以降のセクションでは、4 つのアーキテクチャ オプションについて説明します。各オプションは、次のいずれかのデプロイ アーキタイプに基づいています。
ゾーン アーキテクチャ
次の図は、Google Cloud リージョン内の単一ゾーンで Oracle Database を実行する Oracle E-Business Suite アプリケーションのアーキテクチャを示しています。このアーキテクチャは、ゾーン デプロイ アーキタイプに対応しています。
上記の図のアーキテクチャには、次のコンポーネントが含まれています。
| コンポーネント | 説明 |
|---|---|
| リージョン外部アプリケーション ロードバランサ | ロードバランサは、ユーザー リクエストを受信して Oracle E-Business Suite アプリケーションに分散します。 |
| Google Cloud Armor セキュリティ ポリシー | Google Cloud Armor セキュリティ ポリシーは、DDoS 攻撃や XSS などの脅威からアプリケーションを保護します。 |
| Oracle E-Business Suite（BYOL） |
Oracle E-Business Suite アプリケーション レイヤ コンポーネント（Oracle HTTP Server、Oracle WebLogic Server、同時処理サーバー）は Compute Engine VM で実行されます。各 VM には、アプリケーション レイヤの独立したインスタンスがホストされます。各 VM のブートディスクは Google Cloud Hyperdisk ボリュームです。 Oracle E-Business Suite のお客様所有ライセンス（BYOL）を使用し、VM とアプリケーションを管理します。 |
| アプリケーション バイナリとデータ | Filestore ゾーン インスタンスには、アプリケーション バイナリとデータが含まれます。Filestore インスタンスは、アプリケーション レイヤ コンポーネントをホストする Compute Engine VM にマウントされます。 |
| Oracle Database（BYOL） |
Oracle E-Business Suite アプリケーションは、Compute Engine VM にデプロイされた Oracle Database インスタンスを使用します。VM のブートディスクとデータディスクは Hyperdisk ボリュームです。 Oracle Database インスタンスのお客様所有ライセンス（BYOL）を使用し、VM とデータベースを管理します。 |
| アプリケーションとデータベースのバックアップ | アプリケーション データとデータベースのバックアップは、Backup and DR サービスを使用して作成、保存、管理されます。 |
| Virtual Private Cloud（VPC）ネットワークとサブネット |
このアーキテクチャ内のすべての Google Cloud リソースは、単一の VPC ネットワークを使用します。アプリケーション レイヤとデータベースをホストする VM は、個別のサブネットを使用します。 要件に応じて、複数の VPC ネットワークを使用するアーキテクチャを構築できます。詳細については、複数の VPC ネットワークを作成するかどうかを決定するをご覧ください。 |
| Public NAT ゲートウェイ | このアーキテクチャでは、内部 IP アドレスのみを持つ Compute Engine VM からの安全なアウトバウンド接続を可能にするため、パブリック Cloud NAT ゲートウェイが存在します。たとえば、VM は Oracle Linux Yum サーバーにアクセスして OS パッケージをダウンロードできます。 |
| Cloud Interconnect と Cloud VPN | オンプレミス ネットワークをGoogle Cloudの VPC ネットワークに接続するには、Cloud Interconnect または Cloud VPN を使用します。各アプローチの相対的な利点については、Network Connectivity プロダクトの選択をご覧ください。 |
DMZ を使用したゾーン アーキテクチャ
次の図は、Compute Engine VM で実行されている 2 つの独立した Oracle E-Business Suite アプリケーション レイヤのアーキテクチャを示しています。アプリケーション レイヤの 1 つは非武装地帯（DMZ）で、Oracle E-Business Suite アプリケーションの外部ユーザーにサービスを提供します。もう 1 つのレイヤは内部ユーザーにサービスを提供します。どちらのアプリケーション レイヤも、 Google Cloud リージョン内の単一ゾーン内で実行され、単一の Oracle Database インスタンスを使用します。前のセクションのアーキテクチャと同様に、このアーキテクチャはゾーン デプロイ アーキタイプに対応しています。
上記の図のアーキテクチャには、次のコンポーネントが含まれています。
| コンポーネント | 説明 |
|---|---|
| リージョン外部アプリケーション ロードバランサ | 外部ロードバランサは、外部ユーザーからのリクエストを受信して、外部向けのアプリケーション レイヤに分散します。 |
| リージョン内部アプリケーション ロードバランサ | 内部ロードバランサは、内部ユーザーからのリクエストを受信して内部向けのアプリケーション レイヤに分散します。 |
| Google Cloud Armor セキュリティ ポリシー | Google Cloud Armor セキュリティ ポリシーは、DDoS 攻撃や XSS などの外部の脅威からアプリケーションを保護します。 |
| Oracle E-Business Suite（BYOL） |
Oracle E-Business Suite アプリケーション レイヤ コンポーネント（Oracle HTTP Server、Oracle WebLogic Server、同時処理サーバー）は Compute Engine VM で実行されます。各 VM には、アプリケーション レイヤの独立したインスタンスがホストされます。内部アプリケーションと外部アプリケーションは、異なる VM セットから提供されます。各 VM のブートディスクは Hyperdisk ボリュームです。 Oracle E-Business Suite のお客様所有ライセンス（BYOL）を使用し、VM とアプリケーションを管理します。 |
| アプリケーション バイナリとデータ | Filestore ゾーン インスタンスには、アプリケーション バイナリとデータが含まれます。Filestore インスタンスは、アプリケーション レイヤ コンポーネントをホストする Compute Engine VM にマウントされます。 |
| Oracle Database（BYOL） |
Oracle E-Business Suite アプリケーションは、Compute Engine VM にデプロイされた Oracle Database インスタンスを使用します。VM のブートディスクとデータディスクは Hyperdisk ボリュームです。 Oracle Database インスタンスのお客様所有ライセンス（BYOL）を使用し、VM とデータベースを管理します。 |
| アプリケーションとデータベースのバックアップ | アプリケーション データとデータベースのバックアップは、Backup and DR を使用して作成、保存、管理されます。 |
| Virtual Private Cloud（VPC）ネットワークとサブネット |
このアーキテクチャ内のすべての Google Cloud リソースは、単一の VPC ネットワークを使用します。アプリケーション レイヤとデータベースをホストする VM は、個別のサブネットを使用します。 要件に応じて、複数の VPC ネットワークを使用するアーキテクチャを構築できます。詳細については、複数の VPC ネットワークを作成するかどうかを決定するをご覧ください。 |
| Public NAT ゲートウェイ | このアーキテクチャでは、内部 IP アドレスのみを持つ Compute Engine VM からの安全なアウトバウンド接続を可能にするため、パブリック Cloud NAT ゲートウェイが存在します。たとえば、VM は Oracle Linux Yum サーバーにアクセスして OS パッケージをダウンロードできます。 |
| Cloud Interconnect と Cloud VPN | オンプレミス ネットワークをGoogle Cloudの VPC ネットワークに接続するには、Cloud Interconnect または Cloud VPN を使用します。管理者と内部アプリケーション ユーザーは、これらの接続を使用して、それぞれリソースとアプリケーションにアクセスします。各アプローチの相対的な利点については、Network Connectivity プロダクトの選択をご覧ください。 |
リージョン アーキテクチャ
次の図は、 Google Cloud リージョン内の 2 つのゾーンに分散された Compute Engine VM で Oracle E-Business Suite アプリケーションがアクティブ / アクティブ モードで実行されるアーキテクチャを示しています。どちらのアプリケーション デプロイでも、いずれかのゾーンの VM でプライマリ Oracle Database インスタンスが実行されます。Oracle Data Guard は、2 番目のゾーンのスタンバイ Oracle Database インスタンスに対するデータベースのレプリケーションとフェイルオーバーを管理します。このアーキテクチャは、リージョン デプロイ アーキタイプに基づいています。
上記の図のアーキテクチャには、次のコンポーネントが含まれています。
| コンポーネント | 説明 |
|---|---|
| リージョン外部アプリケーション ロードバランサ | ロードバランサは、ユーザー リクエストを受信して Oracle E-Business Suite アプリケーションに分散します。 |
| Google Cloud Armor セキュリティ ポリシー | Google Cloud Armor セキュリティ ポリシーは、分散 DDoS 攻撃や XSS などの脅威からアプリケーションを保護します。 |
| Oracle E-Business Suite（BYOL） |
Oracle E-Business Suite アプリケーション レイヤ コンポーネント（Oracle HTTP Server、Oracle WebLogic Server、同時処理サーバー）は、2 つのゾーンに分散された Compute Engine VM で実行されます。各 VM には、アプリケーション レイヤの独立したインスタンスがホストされます。各 VM のブートディスクは Hyperdisk ボリュームです。 Oracle E-Business Suite のお客様所有ライセンス（BYOL）を使用し、VM とアプリケーションを管理します。 |
| アプリケーション バイナリとデータ | Filestore リージョン インスタンスには、アプリケーション バイナリとデータが含まれます。Filestore インスタンスは、両方のゾーンのアプリケーション レイヤ コンポーネントをホストするすべての Compute Engine VM にマウントされます。 |
| Oracle Database（BYOL） |
Oracle E-Business Suite アプリケーションは、個別のゾーンの Compute Engine VM にデプロイされた Oracle Database インスタンスのプライマリ スタンバイ ペアを使用します。VM のブートディスクとデータディスクは Hyperdisk ボリュームです。 Oracle Data Guard は、プライマリ インスタンスからスタンバイ インスタンスへのデータベースのレプリケーションとフェイルオーバーを管理します。 Oracle Database インスタンスのお客様所有ライセンス（BYOL）を使用し、VM とデータベースを管理します。 |
| アプリケーションとデータベースのバックアップ | アプリケーション データとデータベースのバックアップは、Backup and DR を使用して作成、保存、管理されます。 |
| Virtual Private Cloud（VPC）ネットワークとサブネット |
このアーキテクチャ内のすべての Google Cloud リソースは、単一の VPC ネットワークを使用します。アプリケーション レイヤとデータベースをホストする VM は、個別のサブネットを使用します。 要件に応じて、複数の VPC ネットワークを使用するアーキテクチャを構築できます。詳細については、複数の VPC ネットワークを作成するかどうかを決定するをご覧ください。 |
| Public NAT ゲートウェイ | このアーキテクチャでは、内部 IP アドレスのみを持つ Compute Engine VM からの安全なアウトバウンド接続を可能にするため、パブリック Cloud NAT ゲートウェイが存在します。たとえば、VM は Oracle Linux Yum サーバーにアクセスして OS パッケージをダウンロードできます。 |
| Cloud Interconnect と Cloud VPN | オンプレミス ネットワークをGoogle Cloudの VPC ネットワークに接続するには、Cloud Interconnect または Cloud VPN を使用します。各アプローチの相対的な利点については、Network Connectivity プロダクトの選択をご覧ください。 |
マルチリージョン アクティブ / パッシブ（DR）アーキテクチャ
次の図は、 Google Cloud リージョン内の 2 つのゾーンに分散された Compute Engine VM で Oracle E-Business Suite アプリケーションがアクティブ / アクティブ モードで実行されるアーキテクチャを示しています。どちらのアプリケーション デプロイでも、いずれかのゾーンの VM でプライマリ Oracle Database インスタンスが実行されます。Oracle Data Guard は、2 番目のゾーンのスタンバイ Oracle Database インスタンスに対するデータベースのレプリケーションとフェイルオーバーを管理します。このアーキテクチャでは、DR 用のリモート（フェイルオーバー）リージョンにアプリケーション スタックの小規模なレプリカが含まれています。前のセクションのアーキテクチャと同様に、このアーキテクチャはリージョン デプロイ アーキタイプに基づいています。
上記の図のアーキテクチャには、次のコンポーネントが含まれています。
| コンポーネント | 説明 |
|---|---|
| DNS フェイルオーバー ルーティング ポリシー | フェイルオーバー ルーティング ポリシーで構成された Cloud DNS パブリック ゾーンは、現在リクエストを処理しているリージョンのロードバランサにユーザー リクエストを転送します。 |
| リージョン外部アプリケーション ロードバランサ | ロードバランサは、ユーザー リクエストを受信して Oracle E-Business Suite アプリケーションに分散します。 |
| Google Cloud Armor セキュリティ ポリシー | Google Cloud Armor セキュリティ ポリシーは、分散 DDoS 攻撃や XSS などの脅威からアプリケーションを保護します。 |
| Oracle E-Business Suite（BYOL） |
Oracle E-Business Suite アプリケーション レイヤ コンポーネント（Oracle HTTP Server、Oracle WebLogic Server、同時処理サーバー）は、プライマリ リージョンの 2 つのゾーンに分散された Compute Engine VM で実行されます。各 VM には、アプリケーション レイヤの独立したインスタンスがホストされます。各 VM のブートディスクは Hyperdisk ボリュームです。 Oracle E-Business Suite のお客様所有ライセンス（BYOL）を使用し、VM とアプリケーションを管理します。 |
| アプリケーション バイナリとデータ |
プライマリ リージョンの Filestore リージョン インスタンスには、アプリケーション バイナリとデータが含まれています。Filestore インスタンスは、プライマリ リージョンの両方のゾーンのアプリケーション レイヤ コンポーネントをホストするすべての Compute Engine VM にマウントされます。Filestore インスタンスがフェイルオーバー リージョンに複製されます。 |
| Oracle Database（BYOL） |
Oracle E-Business Suite アプリケーションは、プライマリ リージョンの個別のゾーンにある Compute Engine VM にデプロイされた Oracle Database インスタンスのプライマリ スタンバイ ペアを使用します。VM のブートディスクとデータディスクは Hyperdisk ボリュームです。 Oracle Data Guard は、プライマリ インスタンスからスタンバイ インスタンスへのデータベースのレプリケーションとフェイルオーバーを管理します。 Oracle Database インスタンスのお客様所有ライセンス（BYOL）を使用し、VM とデータベースを管理します。 |
| アプリケーションとデータベースのバックアップ | アプリケーション データとデータベースのバックアップは、Backup and DR を使用して作成、保存、管理されます。 |
| Virtual Private Cloud（VPC）ネットワークとサブネット |
このアーキテクチャ内のすべての Google Cloud リソースは、単一の VPC ネットワークを使用します。アプリケーション レイヤとデータベースをホストする VM は、個別のリージョン サブネットを使用します。 要件に応じて、複数の VPC ネットワークを使用するアーキテクチャを構築できます。詳細については、複数の VPC ネットワークを作成するかどうかを決定するをご覧ください。 |
| Public NAT ゲートウェイ | このアーキテクチャでは、内部 IP アドレスのみを持つ Compute Engine VM からの安全なアウトバウンド接続を可能にするため、各リージョンにパブリック Cloud NAT ゲートウェイが存在します。たとえば、VM は Oracle Linux Yum サーバーにアクセスして OS パッケージをダウンロードできます。 |
| Cloud Interconnect と Cloud VPN | オンプレミス ネットワークをGoogle Cloudの VPC ネットワークに接続するには、Cloud Interconnect または Cloud VPN を使用します。各アプローチの相対的な利点については、Network Connectivity プロダクトの選択をご覧ください。 |
使用するプロダクト
これらのリファレンス アーキテクチャでは、次の Google Cloud プロダクトを使用します。
- Compute Engine: Google のインフラストラクチャで VM を作成して実行できる、安全でカスタマイズ可能なコンピューティング サービス。
- Google Cloud Hyperdisk: 構成可能かつ予測可能なパフォーマンスで、ブロック ストレージ ボリュームをプロビジョニングして動的にスケーリングできるネットワーク ストレージ サービス。
- Filestore: さまざまなクライアント タイプに接続できる、 Google Cloud 上の高性能なフルマネージド ファイル ストレージを提供するサービス。
- Backup and DR サービス: Google Cloud ワークロード向けの安全で一元的なバックアップ / 復元サービスで、バックアップ データを悪意のある削除や偶発的な削除から保護します。
- Cloud DNS: Google の世界規模のネットワークから復元力のある低レイテンシの DNS サービスを提供するサービス。
- Cloud Load Balancing: 高パフォーマンスでスケーラブルなグローバル ロードバランサとリージョン ロードバランサのポートフォリオ。
- Google Cloud Armor: ウェブ アプリケーション ファイアウォール（WAF）ルールを提供し、DDoS 攻撃やアプリケーション攻撃から保護するネットワーク セキュリティ サービス。
- Virtual Private Cloud（VPC）: Google Cloud ワークロードにグローバルでスケーラブルなネットワーキング機能を提供する仮想システム。VPC には、VPC ネットワーク ピアリング、Private Service Connect、プライベート サービス アクセス、共有 VPC が含まれます。
- Cloud NAT: Google Cloudが管理する高パフォーマンスのネットワーク アドレス変換を提供するサービス。
- Cloud Interconnect: 高可用性で低レイテンシの接続を通じて、外部ネットワークを Google ネットワークに拡張するサービス。
- Cloud VPN: IPsec VPN トンネルを介してピア ネットワークを Google のネットワークに安全に拡張するサービス。
これらのリファレンス アーキテクチャでは、次の Oracle 製品を使用します。
- Oracle E-Business Suite: 財務、人事、サプライ チェーンなどのビジネス運営向けのアプリケーション スイート。
- Oracle Database: リレーショナル モデルをオブジェクト リレーショナル モデルに拡張するリレーショナル データベース管理システム（RDBMS）。
- Oracle Data Guard: 1 つ以上のスタンバイ データベースの作成、維持、管理、モニタリングを行う一連のサービス。
Google Cloudにデプロイする Oracle 製品のライセンスの調達と Oracle ライセンスの利用規約への準拠は、お客様の責任となります。
設計上の考慮事項
このセクションでは、これらのリファレンス アーキテクチャを使用して、セキュリティ、信頼性、運用効率、費用、パフォーマンスに関する特定の要件を満たすトポロジを開発する際に考慮すべき設計要素、ベスト プラクティス、設計に関する推奨事項について説明します。
システム設計
このセクションでは、デプロイに使用する Google Cloud リージョンの選択と、適切な Google Cloud サービスの選択に役立つガイダンスを示します。
リージョンの選択
アプリケーションをデプロイする Google Cloud リージョンを選択する場合は、次の要素と要件を考慮してください。
- 各リージョンでの Google Cloud サービスの可用性。詳細については、ロケーション別のプロダクト提供状況をご覧ください。
- 各リージョンで使用できる Compute Engine マシンタイプ。詳細については、リージョンとゾーンをご覧ください。
- エンドユーザーのレイテンシ要件。
- Google Cloud リソースの費用。
- リージョン間でのデータ転送の費用。
- 規制要件。
これらの要素や要件の中には、トレードオフを伴うものもあります。たとえば、費用対効果の最も高いリージョンが、温室効果ガス排出量が最も少ないリージョンとは限りません。詳細については、Compute Engine のリージョン選択に関するベスト プラクティスをご覧ください。
コンピューティング インフラストラクチャ
このドキュメントのリファレンス アーキテクチャでは、アプリケーションの特定の階層に Compute Engine VM を使用しています。アプリケーションの要件に応じて、他の Google Cloud コンピューティング サービスを選択できます。
- コンテナ: Google Kubernetes Engine（GKE）クラスタでは、コンテナ化されたアプリケーションを実行できます。GKE は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するコンテナ オーケストレーション エンジンです。
- サーバーレス: インフラストラクチャ リソースの設定や運用ではなく、データとアプリケーションに IT の労力を集中させたい場合は、Cloud Run などのサーバーレス サービスを使用します。
VM、コンテナ、サーバーレス サービスのどれを使用するかの決定には、構成の柔軟性と管理上の労力とのトレードオフが伴います。VM とコンテナは比較的柔軟に構成できますが、リソースの管理責任はユーザーにあります。サーバーレス アーキテクチャでは、必要となる管理作業が最も少ない事前構成されたプラットフォームにワークロードをデプロイします。Google Cloudのワークロードに適したコンピューティング サービスの選択の詳細については、 Google Cloudでのアプリケーションのホスティングをご覧ください。
データベースの移行
オンプレミスの Oracle Database デプロイをGoogle Cloudに移行する場合は、Database Migration Assessment（DMA）ツールを使用して、現在のデータベース環境を評価し、構成とサイズの推奨事項を取得します。
オンプレミス データをGoogle Cloudの Oracle データベース デプロイに移行するには、Oracle GoldenGate などの標準の Oracle ツールを使用できます。
ストレージ オプション
このドキュメントで説明するアーキテクチャでは、すべての Compute Engine VM のブートディスクと、Oracle Database インスタンスをホストする VM のデータディスクに Hyperdisk ボリュームを使用します。Hyperdisk ボリュームは、Persistent Disk よりもパフォーマンス、柔軟性、効率が向上します。Hyperdisk のタイプと機能については、Hyperdisk についてをご覧ください。
アプリケーション データとバイナリの場合、このドキュメントのすべてのアーキテクチャで Filestore が使用されます。Filestore リージョン インスタンスに保存されたデータは、リージョン内の 3 つのゾーン間で同期してレプリケートされます。このレプリケーションにより、ゾーンの停止に対する高可用性と堅牢性が確保されます。また、Filestore インスタンスには、共有構成ファイル、一般的なツールとユーティリティ、一元化されたログを保存し、そのインスタンスを複数の VM にマウントできます。
ワークロード用のストレージを設計する場合は、ワークロードの機能特性、復元力に関する要件、パフォーマンスの期待値、費用目標を検討します。詳細については、クラウド ワークロードに最適なストレージ戦略の設計をご覧ください。
ネットワーク設計
マルチティア アプリケーション スタック用のインフラストラクチャを構築する場合は、ビジネス要件と技術要件を満たすネットワーク設計を選択する必要があります。このドキュメントに示すアーキテクチャでは、単一の VPC ネットワークを使用するシンプルなネットワーク トポロジを使用しています。要件に応じて、複数の VPC ネットワークを使用するように選択できます。詳細については、以下のドキュメントをご覧ください。
データ分析
高度な分析を行う場合は、Google Cloud Cortex Framework を使用して Oracle E-Business Suite アプリケーションから BigQuery にデータを取り込むことができます。詳細については、Cortex Framework: Oracle E-Business Suite との統合をご覧ください。
セキュリティ、プライバシー、コンプライアンス
このセクションでは、これらのリファレンス アーキテクチャを使用して、ワークロードのセキュリティとコンプライアンスの要件を満たす Google Cloud のトポロジを設計する際に考慮すべき要素について説明します。
外部の脅威からの保護
分散型サービス拒否（DDoS）攻撃やクロスサイト スクリプティング（XSS）などの脅威からアプリケーションを保護するために、Google Cloud Armor セキュリティ ポリシーを使用できます。個々のポリシーは、評価すべき特定の条件と、その条件が満たされた場合に実行するアクションを指定する一連のルールです。たとえば、受信トラフィックの送信元 IP アドレスが特定の IP アドレスまたは CIDR 範囲と一致する場合に、このトラフィックを拒否するようにルールで指定できます。事前に構成されたウェブ アプリケーション ファイアウォール（WAF）ルールを適用することもできます。詳細については、セキュリティ ポリシーの制限をご覧ください。
VM に対する外部アクセス
このドキュメントで説明するリファレンス アーキテクチャでは、Compute Engine VM にインターネットからのインバウンド アクセスは必要ありません。VM に外部 IP アドレスを割り当てないでください。プライベートの内部 IP アドレスしか持たない Google Cloud リソースは、Private Service Connect またはプライベート Google アクセスを使用して、特定の Google API やサービスにアクセスできます。詳細については、サービスのプライベート アクセス オプションをご覧ください。
このリファレンス アーキテクチャの Compute Engine VM など、プライベート IP アドレスのみを持つ Google Cloud リソースからの安全なアウトバウンド接続を可能にするには、Secure Web Proxy または Cloud NAT を使用します。
サービス アカウントの権限
アーキテクチャの Compute Engine VM では、デフォルトのサービス アカウントを使用するのではなく、専用のサービス アカウントを作成して、サービス アカウントがアクセスできるリソースを指定することをおすすめします。デフォルトのサービス アカウントには、このインスタンスで必要のない幅広い権限が含まれていますが、専用のサービス アカウントは、必要な権限のみを持つように調整できます。詳細については、サービス アカウントの権限を制限するをご覧ください。
SSH セキュリティ
このアーキテクチャの Compute Engine VM への SSH 接続のセキュリティを強化するには、Cloud OS Login API を使用して Identity-Aware Proxy（IAP）転送を実装します。IAP を使用すると、ユーザー ID と Identity and Access Management（IAM）ポリシーに基づいてネットワーク アクセスを制御できます。Cloud OS Login API を使用すると、ユーザー ID と IAM ポリシーに基づいて Linux SSH アクセスを制御できます。ネットワーク アクセスの管理の詳細については、SSH ログイン アクセスを制御する際のベスト プラクティスをご覧ください。
ディスクの暗号化
デフォルトでは、Hyperdisk ボリュームと Filestore に保存されるデータはGoogle-owned and Google-managed encryption keysを使用して暗号化されます。追加の保護レイヤとして、Cloud Key Management Service（Cloud KMS）により、所有して管理する鍵で Google-owned and managed key を暗号化することもできます。詳細については、Hyperdisk ボリュームのディスク暗号化についてと Filestore の顧客管理の暗号鍵でデータを暗号化するをご覧ください。
ネットワーク セキュリティ
アーキテクチャのリソース間のネットワーク トラフィックを制御するには、適切な Cloud Next Generation Firewall（NGFW）ポリシーを構成する必要があります。
セキュリティ上のその他の考慮事項
ワークロードのアーキテクチャを構築する際は、エンタープライズ基盤のブループリントと Google Cloud Well-Architected Framework: セキュリティ、プライバシー、コンプライアンスで提供されているプラットフォーム レベルのセキュリティのベスト プラクティスと推奨事項を検討してください。
信頼性
このセクションでは、これらのリファレンス アーキテクチャを使用して、 Google Cloudのデプロイ用に信頼性の高いインフラストラクチャを構築して運用する際に考慮すべき設計要素について説明します。
VM の障害に対するアプリケーション レイヤの堅牢性
このドキュメントのすべてのアーキテクチャ オプションでは、アプリケーション VM の一部（すべてではない）で障害が発生しても、ロードバランサがリクエストを他のアプリケーション VM に転送するため、アプリケーションを継続して使用できます。
アプリケーション VM が実行されていて使用可能な状態でも、アプリケーション自体に問題があることもあります。アプリケーションでフリーズやクラッシュが発生したり、メモリ不足になることがあります。このような場合、VM はロードバランサのヘルスチェックに応答せず、ロードバランサは応答しない VM にトラフィックを転送しません。
VM の障害に対するデータベースの堅牢性
ゾーン アーキテクチャでは、データベース VM に障害が発生した場合、Backup and DR に保存されているバックアップを使用して、本番環境の新しい VM にデータベースを復元できます。データベースを復元したら、アプリケーションを新しいデータベース インスタンスに接続する必要があります。
データの整合性を優先する場合は、プライマリ データベース インスタンスとスタンバイ データベース インスタンスを設定します。可能であれば、リージョン アーキテクチャに示されているように、異なるゾーンにある VM 上に設定します。スタンバイ データベース インスタンスへのレプリケーションとフェイルオーバーには、Data Guard を使用します。Data Guard は、プライマリ インスタンスでトランザクションを承認する前に、スタンバイ インスタンスにトランザクションをレプリケートすることで、整合性を確保します。プライマリ スタンバイ データベース アーキテクチャには、インフラストラクチャとライセンスの追加費用がかかります。
リージョンまたはマルチリージョン アーキテクチャで、プライマリ データベースをホストする VM に障害が発生すると、Oracle Data Guard はスタンバイ Oracle Database インスタンスへのフェイルオーバーを開始します。フェイルオーバー プロセスが完了するまで、アプリケーションはデータベースにアクセスできません。
ゾーンの停止に対する堅牢性
ゾーン アーキテクチャでは、デプロイメントをホストするゾーンが停止すると、アプリケーションとデータベースが停止します。Backup and DR に保存されているバックアップを使用して、アプリケーションとデータベースを別のゾーンまたはリージョンの本番環境に復元できます。
リージョン アーキテクチャでは、いずれかのゾーンが停止すると、ロードバランサはリクエストをもう一方のゾーンで実行されているアプリケーションのインスタンスに転送します。このアーキテクチャでは Filestore リージョン サービス階層が使用されているため、Filestore を継続して使用できます。
単一ゾーン停止時の Hyperdisk ボリュームのデータの高可用性を確保するには、Hyperdisk Balanced High Availability を使用します。データが Hyperdisk Balanced High Availability ボリュームに書き込まれると、データは同じリージョン内の 2 つのゾーン間で同期的に複製されます。
リージョンの停止に対する堅牢性
リージョンが停止した場合、アプリケーションとデータベースは使用できなくなります。Backup and DR に保存されているバックアップを使用して、アプリケーションとデータベースを別のリージョンの本番環境に復元できます。ダウンタイムを短縮するには、マルチリージョン アクティブ / パッシブ（DR）アーキテクチャを使用します。アプリケーションとデータベースを起動したら、DNS ルーティング ポリシーを更新して、フェイルオーバー リージョンのロードバランサにトラフィックを転送する必要があります。
リージョンが停止したときのダウンタイムを許容できないクリティカルなビジネス アプリケーションの場合は、マルチリージョン アクティブ / アクティブのデプロイ アーキタイプを使用します。
VM のキャパシティ プランニング
VM をプロビジョニングする必要があるときに Compute Engine VM の容量を使用できるようにするには、予約を作成します。予約することで、選択したマシンタイプの指定した数の VM に対して、特定のゾーンでの容量が保証されます。予約は、プロジェクトに固有のものにすることも、複数のプロジェクトで共有することもできます。予約の詳細については、予約タイプを選択するをご覧ください。
データの耐久性
このドキュメントのアーキテクチャでは、Backup and DR を使用して Compute Engine VM のバックアップを作成、保存、管理します。Backup and DR は、アプリケーションで読み取り可能な元の形式でバックアップ データを保存します。必要に応じて、長期バックアップ ストレージのデータを直接使用することで、ワークロードを本番環境に復元し、データの準備や移動を回避できます。
Backup and DR は、次の 2 つの方法でバックアップを作成できます。
- Backup Vault ストレージ: バックアップ データはソースデータと同じリージョンに保存されます。データの変更や削除はできません。
- セルフマネージド ストレージ: 承認済みユーザーはバックアップ データを変更または削除できます。また、複数のリージョンにデータを保存できます。
詳細については、以下のドキュメントをご覧ください。
- Backup and DR の概要
- Backup and DR による Compute Engine インスタンスのバックアップ
- Filestore とファイル システムでの Backup and DR
- Backup and DR（Oracle 向け）
信頼性に関するその他の考慮事項
ご自身のワークロード用のクラウド アーキテクチャを構築する際には、次のドキュメントに記載されている信頼性関連のベスト プラクティスと推奨事項を確認してください。
- Google Cloud インフラストラクチャ信頼性ガイド
- スケーラブルで復元性の高いアプリのためのパターン
- 復元性に優れたシステムの設計
- Google Cloud Well-Architected Framework: 信頼性
費用の最適化
このセクションでは、これらのリファレンス アーキテクチャを使用して構築した Google Cloud トポロジの設定と運用の費用を最適化するためのガイダンスを示します。
VM マシンタイプ
VM インスタンスのリソース使用率を最適化できるように、Compute Engine には推奨のマシンタイプが用意されています。この推奨事項を参照して、ワークロードのコンピューティング要件と一致するマシンタイプを選択します。リソース要件を予測できるワークロードの場合は、ニーズに合わせてマシンタイプをカスタマイズし、カスタム マシンタイプを使用することで費用を節約できます。
Oracle 製品ライセンス
Compute Engine にデプロイする Oracle 製品のライセンスの調達と Oracle ライセンスの利用規約への準拠は、お客様の責任となります。ライセンス費用を計算する際は、Oracle 製品をホストする Compute Engine VM に選択したマシンタイプに基づいて、必要な Oracle プロセッサ ライセンス数を考慮してください。詳細については、クラウド コンピューティング環境における Oracle ソフトウェアのライセンスをご覧ください。
費用に関するその他の考慮事項
ワークロードのアーキテクチャを構築する際には、Google Cloud Well-Architected Framework: Cost optimization に記載されている一般的なベスト プラクティスと推奨事項も検討してください。
業務の効率化
このセクションでは、これらのリファレンス アーキテクチャを使用して、効率的に運用可能な Google Cloud トポロジを設計する際に考慮すべき要素について説明します。
VM イメージ
VM には、Compute Engine で利用可能な Oracle Linux イメージを使用できます。また、ビルドして維持する Oracle Linux イメージをインポートすることもできます。アプリケーションに必要な構成とソフトウェアを含むカスタム OS イメージを作成して使用することもできます。カスタム イメージは、カスタム イメージ ファミリーにまとめることができます。イメージ ファミリーは、そのファミリー内の最新のイメージを指すため、特定のイメージ バージョンへの参照を手動で更新しなくても、インスタンス テンプレートやスクリプトでそのイメージを使用できます。カスタム イメージを定期的に更新して、OS ベンダーから提供されるセキュリティ アップデートとパッチを含める必要があります。
アプリケーション サーバーからデータベースへの接続
アプリケーションから Oracle Database への接続では、IP アドレスではなく、データベース VM のゾーン内部 DNS 名を使用することをおすすめします。 Google Cloud は、DNS 名を VM のプライマリ内部 IP アドレスに自動的に解決します。データベース VM の静的内部 IP アドレスを予約して割り当てる必要がないことも、このアプローチの利点となります。
Oracle のドキュメントとサポート
Compute Engine VM で実行される Oracle 製品には、オンプレミスで実行される Oracle 製品と同様の運用上の懸念事項があります。ただし、基盤となるコンピューティング、ネットワーキング、ストレージ インフラストラクチャを管理する必要はありません。
- Oracle 製品の運用と管理に関するガイダンスについては、関連する製品に関して Oracle 提供のドキュメントをご覧ください。
- Google Cloudにデプロイする Oracle Database インスタンスに関する Oracle サポート ポリシーについては、Oracle Database サポート（Oracle 以外のパブリック クラウド環境）（Doc ID 2688277.1）をご覧ください。
- Oracle E-Business Suite の Oracle サポート ポリシーの概要については、EBS 認定をご覧ください。
オブザーバビリティ
Google Cloudに Oracle E-Business Suite デプロイのオブザーバビリティを実装するには、Google Cloud Observability サービスまたは Oracle Enterprise Manager を使用します。要件と制約に応じて、適切なモニタリング戦略を選択します。たとえば、 Google Cloud で Oracle E-Business Suite アプリケーションに加えて他のワークロードを実行している場合は、Google Cloud Observability サービスを使用して、すべてのワークロード用に統合されたオペレーション ダッシュボードを構築できます。
運用上のその他の考慮事項
ワークロードのアーキテクチャを構築する際には、Google Cloud Well-Architected Framework: Operational excellence で説明されている運用効率に関する一般的なベスト プラクティスと推奨事項を検討してください。
パフォーマンスの最適化
このセクションでは、これらのリファレンス アーキテクチャを使用して、ワークロードのパフォーマンス要件を満たす Google Cloud のトポロジを設計する際に考慮すべき要素について説明します。
コンピューティング パフォーマンス
Compute Engine には、ワークロードのパフォーマンス要件に応じて選択できる、事前定義済みでカスタマイズ可能なマシンタイプが幅広く用意されています。
- アプリケーションとデータベースをホストする VM の場合は、パフォーマンス要件に基づいて適切なマシンタイプを選択します。Hyperdisk ボリュームをサポートし、パフォーマンスなどの要件を満たす使用可能なマシンタイプのリストを取得するには、マシンシリーズの比較の表を使用します。
- Oracle Database インスタンスをホストする VM には、汎用マシン ファミリーの C4 マシンシリーズのマシンタイプを使用することをおすすめします。C4 マシンタイプは、データベース ワークロードに対して一貫して高いパフォーマンスを提供します。
ネットワーク パフォーマンス
Compute Engine には、下り（外向き）ネットワーク帯域幅の VM ごとの上限があります。この上限は、VM のマシンタイプと、トラフィックがソース VM と同じ VPC ネットワーク経由でルーティングされるかどうかによって異なります。特定のマシンタイプを使用する VM の場合、ネットワーク パフォーマンスを向上させるために、Tier_1 ネットワーキングを有効にして下り（外向き）の最大帯域幅を増やすことができます。詳細については、VM ごとの Tier_1 ネットワーキング パフォーマンスを構成するをご覧ください。
Hyperdisk ストレージのパフォーマンス
このドキュメントで説明するアーキテクチャでは、VM のすべてのブートディスクとデータベース VM のデータディスクに Hyperdisk ボリュームを使用します。Hyperdisk を使用すると、パフォーマンスと容量を動的にスケーリングできます。ワークロードのストレージのパフォーマンスと容量のニーズに合わせて、プロビジョニングされた IOPS、スループット、各ボリュームのサイズを調整できます。Hyperdisk ボリュームのパフォーマンスは、Hyperdisk のタイプと、ボリュームがアタッチされている VM のマシンタイプによって異なります。Hyperdisk のパフォーマンスの上限と調整の詳細については、次のドキュメントをご覧ください。
パフォーマンスに関するその他の考慮事項
ワークロードのアーキテクチャを構築する際には、Google Cloud Well-Architected Framework: Performance optimization に記載されている一般的なベスト プラクティスと推奨事項も検討してください。
次のステップ
- Google Cloud と Oracle によるクラウド トランスフォーメーション
- Oracle MAA リファレンス アーキテクチャ
- Google Cloudで Oracle Exadata を使用する Compute Engine VM のエンタープライズ アプリケーション
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者:
- Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
- Samantha He | テクニカル ライター
その他の寄稿者:
- Andy Colvin | Database Black Belt エンジニア、Oracle on Google Cloud
- Balazs Pinter | パートナー ソリューション アーキテクト
- Celia Antonio | データベース カスタマー エンジニア
- Majed Al-Halaseh | カスタマー エンジニア、インフラストラクチャ モダナイゼーション
- Marc Fielding | データ インフラストラクチャ アーキテクト
- Mark Schlagenhauf | テクニカル ライター、ネットワーキング
- Michelle Burtoft | シニア プロダクト マネージャー
- Sean Derrington | グループ アウトバウンド プロダクト マネージャー、ストレージ
- Sekou Page | アウトバウンド プロダクト マネージャー
- Souji Madhurapantula | グループ プロダクト マネージャー
- Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング