このドキュメントでは、Compute Engine 仮想マシン（VM）でホストされ、Google Cloud で実行される Oracle Cloud Infrastructure（OCI）Exadata データベースへの低レイテンシ接続を備えた高可用性エンタープライズ アプリケーションのリファレンス アーキテクチャについて説明します。このドキュメントは、クラウド アーキテクトと Oracle データベース管理者を対象としています。このドキュメントは、Compute Engine と Oracle Exadata Database Service に精通していることを前提としています。
Oracle Exadata または Oracle Real Application Clusters（Oracle RAC）を使用して Oracle データベースをオンプレミスで実行している場合は、アプリケーションを Google Cloud に効率的に移行し、Oracle Database@Google Cloud でデータベースを実行できます。Oracle Database@Google Cloud は、Google Cloud 内で Oracle Exadata Database Service と Oracle Autonomous Database を直接実行できる Google Cloud Marketplace サービスです。
Oracle RAC 機能が不要な場合や、19c や 23ai 以外の Oracle Database バージョンが必要な場合は、Compute Engine VM でセルフマネージド Oracle データベースを実行できます。詳細については、Compute Engine 上の Oracle Database を使用したエンタープライズ アプリケーションをご覧ください。
アーキテクチャ
次の図は、アーキテクチャの概要を示しています。
上の図では、外部ロードバランサが公開アプリケーションのユーザーからリクエストを受信し、フロントエンド ウェブサーバーにリクエストを分散しています。ウェブサーバーは、内部ロードバランサを介してユーザー リクエストをアプリケーション サーバーに転送します。アプリケーション サーバーは、Oracle Database@Google Cloud のデータベースからデータを読み取り、データベースに書き込みます。管理者と OCI サービスは、Oracle データベースに接続して操作できます。
次の図は、アーキテクチャの詳細を示しています。
このアーキテクチャでは、Google Cloud リージョン内の 2 つのゾーンに分散された Compute Engine VM でウェブ階層とアプリケーション階層がアクティブ / アクティブ モードで実行されます。アプリケーションは、同じ Google Cloud リージョンの Oracle Exadata データベースを使用します。
このアーキテクチャのすべてのコンポーネントは、単一の Google Cloud リージョンにあります。このアーキテクチャは、リージョン デプロイ アーキタイプに対応しています。このアーキテクチャを採用すると、マルチリージョン デプロイ アーキタイプを使用して、リージョンの停止に対して堅牢なトポロジを構築できます。詳細については、Compute Engine でのマルチリージョン デプロイと、このドキュメントの後半の信頼性に関するガイダンスをご覧ください。
上記の図に示すアーキテクチャには、次のコンポーネントが含まれています。
| コンポーネント | 目的 |
|---|---|
| リージョン外部アプリケーション ロードバランサ | リージョン外部アプリケーション ロードバランサは、ユーザー リクエストを受信してウェブ階層 VM に分散します。 |
| Google Cloud Armor セキュリティ ポリシー | Google Cloud Armor セキュリティ ポリシーは、分散型サービス拒否（DDoS）攻撃やクロスサイト スクリプティング（XSS）などの脅威からアプリケーション スタックを保護します。 |
| ウェブ階層のリージョン マネージド インスタンス グループ（MIG） | アプリケーションのウェブ階層は、リージョン MIG の一部である Compute Engine VM にデプロイされます。この MIG は、外部アプリケーション ロードバランサのバックエンドです。MIG には、2 つのゾーンの Compute Engine VM が含まれています。これらの VM には、アプリケーションのウェブ階層の独立したインスタンスがホストされます。 |
| リージョン内部アプリケーション ロードバランサ | リージョン内部アプリケーション ロードバランサは、ウェブ階層の VM からアプリケーション階層の VM へのトラフィックを分散します。 |
| アプリケーション階層のリージョン MIG | アプリケーション階層（Oracle WebLogic Server クラスタなど）は、リージョン MIG の一部である Compute Engine VM にデプロイされます。この MIG は、内部アプリケーション ロードバランサのバックエンドです。MIG には、2 つのゾーンの Compute Engine VM が含まれています。各 VM には、アプリケーション サーバーの独立したインスタンスがホストされます。 |
| Virtual Private Cloud（VPC）ネットワークとサブネット。 | このアーキテクチャ内のすべての Google Cloud リソースは、単一の VPC ネットワークを使用します。要件に応じて、複数のネットワークを使用するアーキテクチャを構築できます。詳細については、複数の VPC ネットワークを作成するかどうかを決定するをご覧ください。 |
| Oracle Database@Google Cloud |
アプリケーション サーバーは、Oracle Exadata Database Service の Oracle データベースからデータを読み取り、Oracle データベースに書き込みます。Oracle Exadata Database Service は Oracle Database@Google Cloud を使用してプロビジョニングします。これは、Google Cloud データセンター内の Oracle マネージド ハードウェアで Oracle データベースを実行できる Cloud Marketplace サービスです。 Exadata Infrastructure インスタンスを作成するには、Google Cloud コンソール、Google Cloud CLI、API などの Google Cloud インターフェースを使用します。Oracle は、プロジェクト専用のハードウェア上に、Google Cloud リージョン内のデータセンターに必要なコンピューティング、ストレージ、ネットワーキング インフラストラクチャをセットアップして管理します。 |
| Exadata Infrastructure インスタンス | 各 Exadata Infrastructure インスタンスには、2 つ以上の物理データベース サーバーと 3 つ以上のストレージ サーバーが含まれています。これらのサーバーは図には示されていませんが、低レイテンシのネットワーク ファブリックを使用して相互に接続されています。Exadata Infrastructure インスタンスを作成するときに、プロビジョニングするデータベース サーバーとストレージ サーバーの数を指定します。 |
| Exadata VM クラスタ |
Exadata Infrastructure インスタンス内に 1 つ以上の Exadata VM クラスタを作成します。たとえば、個別の Exadata VM クラスタを作成して使用し、各ビジネス ユニットに必要なデータベースをホストできます。各 Exadata VM クラスタには、Oracle Database インスタンスをホストする 1 つ以上の Oracle Linux VM が含まれています。 Exadata VM クラスタを作成するときに、次のものを指定します。
Exadata VM クラスタ内の VM は Compute Engine VM ではありません。 |
| Oracle Database インスタンス | Oracle データベースの作成と管理は、OCI コンソールやその他の OCI インターフェースで行います。Oracle Database ソフトウェアは、Exadata VM クラスタ内の VM で実行されます。Exadata VM クラスタを作成するときに、Oracle Grid Infrastructure のバージョンを指定します。また、ライセンスの種類（お客様所有ライセンス（BYOL）またはライセンスを含むモデル）を選択します。 |
| OCI VCN とサブネット | Exadata VM クラスタを作成すると、OCI 仮想クラウド ネットワーク（VCN）が自動的に作成されます。VCN には、クライアント サブネットと、指定した IP アドレス範囲を持つバックアップ サブネットがあります。クライアント サブネットは、VPC ネットワークから Oracle データベースへの接続に使用されます。バックアップ サブネットは、データベースのバックアップを OCI Object Storage に送信するために使用されます。 |
| Cloud Router、Partner Interconnect、OCI DRG | VPC ネットワークと VCN 間のトラフィックは、VPC に接続されている Cloud Router と、VCN に接続されている動的ルーティング ゲートウェイ（DRG）を介してルーティングされます。トラフィックは、Google が Partner Interconnect を使用して設定する低レイテンシ接続を経由します。 |
| 限定公開 Cloud DNS ゾーン | Exadata VM クラスタを作成すると、Cloud DNS プライベート ゾーンが自動的に作成されます。アプリケーション サーバーが Oracle データベースに読み取り / 書き込みリクエストを送信すると、Cloud DNS はデータベースのホスト名を対応する IP アドレスに解決します。 |
| OCI Object Storage と OCI Service Gateway | デフォルトでは、Oracle Exadata データベースのバックアップは OCI Object Storage に保存されます。データベースのバックアップは、Service Gateway を介して OCI Object Storage に転送されます。 |
| パブリック Cloud NAT ゲートウェイ | このアーキテクチャには、Compute Engine VM からの安全なアウトバウンド接続を可能にするパブリック Cloud NAT ゲートウェイが含まれています。このゲートウェイは内部 IP アドレスのみを持ちます。 |
| Cloud Interconnect と Cloud VPN | オンプレミス ネットワークを Google Cloud の VPC ネットワークに接続するには、Cloud Interconnect または Cloud VPN を使用します。各アプローチの相対的な利点については、Network Connectivity プロダクトの選択をご覧ください。 |
| Cloud Monitoring | Cloud Monitoring を使用すると、アプリケーションと Google Cloud リソース（Oracle Exadata リソースを含む）の動作、健全性、パフォーマンスをモニタリングできます。OCI Monitoring サービスを使用して、Oracle Exadata リソースのリソースをモニタリングすることもできます。 |
使用するプロダクト
このリファレンス アーキテクチャでは、次の Google Cloud プロダクトを使用します。
- Compute Engine: Google のインフラストラクチャで VM を作成して実行できる、安全でカスタマイズ可能なコンピューティング サービス。
- Cloud Load Balancing: 高パフォーマンスでスケーラブルなグローバル ロードバランサとリージョン ロードバランサのポートフォリオ。
- Virtual Private Cloud（VPC）: Google Cloud ワークロードにグローバルでスケーラブルなネットワーキング機能を提供する仮想システム。
- Google Cloud Armor: ウェブ アプリケーション ファイアウォール（WAF）ルールを提供し、DDoS 攻撃やアプリケーション攻撃から保護するネットワーク セキュリティ サービス。
- Cloud NAT: Google Cloud が管理する高パフォーマンスのネットワーク アドレス変換を提供するサービス。
- Cloud Monitoring: アプリケーションとインフラストラクチャのパフォーマンス、可用性、動作状況を可視化するサービス。
- Cloud Interconnect: 高可用性で低レイテンシの接続を通じて、外部ネットワークを Google ネットワークに拡張するサービス。
- Partner Interconnect: サポートされているサービス プロバイダを介して、オンプレミス ネットワークと Virtual Private Cloud ネットワークや他のネットワークを接続するサービス。
- Cloud VPN: IPsec VPN トンネルを介してピア ネットワークを Google のネットワークに安全に拡張するサービス。
このリファレンス アーキテクチャでは、次の OCI プロダクトを使用します。
- 専用インフラストラクチャ上の Exadata Database Service: 専用の Exadata ハードウェアで Oracle Database インスタンスを実行できるサービス。
- Object Storage: 大量の構造化データと非構造化データをオブジェクトとして保存するサービス。
- VCN とサブネット: VCN は、OCI リージョン内のリソース用の仮想プライベート ネットワークです。サブネットは、VCN 内の連続した IP アドレス範囲です。
- 動的ルーティング ゲートウェイ: VCN と外部ネットワーク間のトラフィック用の仮想ルーター。
- Service Gateway: VCN 内のリソースが特定の Oracle サービスに非公開でアクセスできるようにするゲートウェイ。
設計上の考慮事項
このセクションでは、このリファレンス アーキテクチャを使用して、セキュリティ、信頼性、運用効率、費用、パフォーマンスに関する特定の要件を満たすトポロジを開発する際に考慮すべき設計要素、ベスト プラクティス、設計に関する推奨事項について説明します。
このセクションのガイダンスはすべてを網羅しているわけではありません。アプリケーションの特定の要件と、使用する Google Cloud およびサードパーティのプロダクトや機能によっては、考慮すべき追加の設計要素やトレードオフが存在する可能性があります。
システム設計
このセクションでは、デプロイのための Google Cloud リージョンの選択と、適切な Google Cloud サービスの選択に役立つガイダンスを示します。
リージョンの選択
デプロイに使用する Google Cloud リージョンを選択する場合は、次の要素と要件を考慮してください。
- 各リージョンでの Google Cloud サービスの可用性。詳細については、ロケーション別のプロダクト提供状況をご覧ください。
- 各リージョンで使用できる Compute Engine マシンタイプ。詳細については、リージョンとゾーンをご覧ください。
- 各リージョンでの Oracle Database@Google Cloud の可用性。詳細については、使用可能な構成をご覧ください。
- エンドユーザーのレイテンシ要件。
- Google Cloud リソースの費用
- 規制要件
これらの要素や要件の中には、トレードオフが伴うものもあります。たとえば、費用対効果の最も高いリージョンが、温室効果ガス排出量が最も少ないリージョンとは限りません。詳細については、Compute Engine のリージョン選択に関するベスト プラクティスをご覧ください。
コンピューティング インフラストラクチャ
このドキュメントのリファレンス アーキテクチャでは、Compute Engine VM を使用してウェブ階層とアプリケーション階層をホストします。アプリケーションの要件によっては、以下に示す他の Google Cloud コンピューティング サービスも選択できます。
- コンテナ: Google Kubernetes Engine（GKE）クラスタでは、コンテナ化されたアプリケーションを実行できます。GKE は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するコンテナ オーケストレーション エンジンです。
- サーバーレス: インフラストラクチャ リソースの設定や運用ではなく、データとアプリケーションに IT の労力を集中させたい場合は、Cloud Run や Cloud Run functions などのサーバーレス サービスを使用します。
VM、コンテナ、サーバーレス サービスのどれを使用するかの決定には、構成の柔軟性と管理上の労力とのトレードオフが伴います。VM とコンテナは比較的柔軟に構成できますが、リソースの管理責任はユーザーにあります。サーバーレス アーキテクチャでは、必要となる管理作業が最も少ない事前構成されたプラットフォームにワークロードをデプロイします。これらのサービスの設計ガイダンスは、このドキュメントでは扱いません。サービス オプションの詳細については、Google Cloud でのアプリケーションのホスティングをご覧ください。
ストレージ オプション
ウェブ階層とアプリケーション階層の Compute Engine VM に永続ストレージを提供するには、アプリケーションの容量、スケーリング、可用性、パフォーマンスの要件に基づいて、適切な Persistent Disk または Google Cloud Hyperdisk のタイプを選択します。詳しくは、ストレージ オプションをご覧ください。
リージョン内のゾーン間で冗長な低コストのストレージが必要な場合は、Cloud Storage リージョン バケットを使用します。
リージョン内の複数の VM（ウェブ階層のすべての VM の構成ファイルなど）で共有されるデータを保存するには、Filestore Regional インスタンスを使用します。Filestore Regional インスタンスに保存されたデータは、リージョン内の 3 つのゾーン間で同期してレプリケートされます。このレプリケーションにより、Filestore に保存するデータの高可用性とゾーンの停止に対する堅牢性が確保されます。Filestore インスタンスには、共有構成ファイル、一般的なツールとユーティリティ、一元化されたログを保存し、そのインスタンスを複数の VM にマウントできます。
ワークロード用のストレージを設計する場合は、ワークロードの機能特性、復元力に関する要件、パフォーマンスの期待値、費用目標を検討します。詳細については、クラウド ワークロードに最適なストレージ戦略の設計をご覧ください。
ネットワーク設計
マルチティア アプリケーション スタック用のインフラストラクチャを構築する場合は、ビジネス要件と技術要件を満たすネットワーク設計を選択する必要があります。このドキュメントに示すアーキテクチャでは、単一の VPC ネットワークを使用するシンプルなネットワーク トポロジを使用しています。要件に応じて、複数のネットワークを使用するように選択できます。詳細については、以下のドキュメントをご覧ください。
Exadata VM クラスタに使用するクライアント サブネットとバックアップ サブネットの IP アドレス範囲を割り当てる場合は、サブネットの最小サイズ要件を考慮してください。詳細については、Oracle Database@Google Cloud の IP アドレス空間の計画をご覧ください。
データベースの移行
オンプレミス データベースを Oracle Database@Google Cloud に移行する場合は、Database Migration Assessment（DMA）ツールを使用して、現在のデータベース環境を評価し、構成とサイズの推奨事項を取得します。
オンプレミス データを Google Cloud の Oracle データベース デプロイに移行するには、Oracle GoldenGate などの標準の Oracle ツールを使用できます。
移行したデータベースを本番環境で使用する前に、アプリケーションからデータベースへの接続を確認します。
セキュリティ
このセクションでは、このリファレンス アーキテクチャを使用して、ワークロードのセキュリティとコンプライアンスの要件を満たす Google Cloud のトポロジを設計する際に考慮すべき要素について説明します。
外部の脅威からの保護
DDoS 攻撃や XSS などの外部の脅威からアプリケーションを保護するには、要件に基づいて適切な Google Cloud Armor セキュリティ ポリシーを定義します。ポリシーは、評価する条件と、その条件が満たされたときに実行するアクションを指定する一連のルールです。たとえば、受信トラフィックの送信元 IP アドレスが特定の IP アドレスまたは CIDR 範囲と一致する場合は、トラフィックを拒否しなければならないと、ルールで指定できます。事前構成された WAF ルールを適用することもできます。詳細については、セキュリティ ポリシーの制限をご覧ください。
VM に対する外部アクセス
このドキュメントで説明するリファレンス アーキテクチャでは、ウェブ階層とアプリケーション階層をホストする VM に、インターネットから直接インバウンド アクセスを行う必要はありません。これらの VM には、外部 IP アドレスを割り当てないでください。プライベートの内部 IP アドレスしか持たない Google Cloud リソースは、Private Service Connect または限定公開の Google アクセスを使用して、特定の Google API やサービスにアクセスできます。詳細については、サービスのプライベート アクセス オプションをご覧ください。
このリファレンス アーキテクチャの Compute Engine VM など、プライベート IP アドレスのみを持つ Google Cloud リソースからのアウトバウンド接続を保護するには、上のアーキテクチャ図に示すように Cloud NAT を使用するか、Secure Web Proxy を使用します。
Exadata VM で使用されるサブネットには、プライベート IP アドレス範囲を割り当てることをおすすめします。
VM イメージのセキュリティ
承認済みイメージとは、ポリシーまたはセキュリティ要件を満たすソフトウェアを含むイメージです。ウェブ階層とアプリケーション階層の VM が承認済みのイメージのみを使用するようにするには、特定の公開イメージ プロジェクトでのイメージの使用を制限する組織のポリシーを定義します。詳細については、信頼できるイメージのポリシーの設定をご覧ください。
サービス アカウントの権限
Compute Engine API が有効になっている Google Cloud プロジェクトでは、デフォルトのサービス アカウントが自動的に作成されます。2024 年 5 月 3 日より前に作成された Google Cloud 組織の場合、このデフォルトのサービス アカウントには編集者（roles/editor）の IAM ロールが付与されます（この動作が無効になっている場合を除きます）。
デフォルトでは、デフォルトのサービス アカウントは、gcloud CLI または Google Cloud コンソールを使用して作成するすべての Compute Engine VM に関連付けられます。編集者ロールには幅広い権限が含まれているため、デフォルトのサービス アカウントを VM に関連付けると、セキュリティ リスクが発生します。このリスクを回避するには、アプリケーション スタックの各階層に専用のサービス アカウントを作成して使用します。サービス アカウントがアクセスできるリソースを指定するには、詳細なポリシーを使用します。詳細については、サービス アカウントの権限を制限するをご覧ください。
ネットワーク セキュリティ
アーキテクチャのウェブ階層とアプリケーション階層のリソース間のネットワーク トラフィックを制御するには、適切な Cloud Next Generation Firewall（NGFW）ポリシーを構成する必要があります。
データベースのセキュリティとコンプライアンス
Exadata Database サービスには、Oracle データベースのセキュリティとコンプライアンスの要件を管理する際に役立つ Oracle Data Safe が含まれています。Oracle Data Safe を使用すると、セキュリティ制御の評価、ユーザー アクティビティのモニタリング、機密データのマスキングを行うことができます。詳細については、Oracle Data Safe でデータベースのセキュリティを管理するをご覧ください。
セキュリティ上のその他の考慮事項
ワークロードのアーキテクチャを構築する場合は、エンタープライズ基盤のブループリントで提供されているプラットフォーム レベルのセキュリティのベスト プラクティスと推奨事項を検討してください。
信頼性
このセクションでは、このリファレンス アーキテクチャを使用して、Google Cloud のデプロイ用に信頼性の高いインフラストラクチャを構築して運用する際に考慮すべき設計要素について説明します。
VM 障害に対する堅牢性
このドキュメントで説明するアーキテクチャでは、ウェブ階層またはアプリケーション階層の Compute Engine VM がクラッシュすると、関連する MIG が VM を自動的に再作成します。ロードバランサは、現在使用可能なウェブサーバー インスタンスとアプリケーション サーバー インスタンスにのみリクエストを転送します。
VM の自動修復
ウェブ階層とアプリケーション階層をホストする VM が実行されていて使用可能な場合でも、アプリケーション自体に問題がある場合があります。アプリケーションのフリーズやクラッシュが発生したり、メモリ不足になることがあります。このシナリオでは、VM はロードバランサのヘルスチェックに応答せず、ロードバランサは応答しない VM にトラフィックを転送しません。アプリケーションが期待どおりに応答するように、MIG の自動修復ポリシーの一部としてアプリケーション ベースのヘルスチェックを構成できます。特定の VM 上のアプリケーションが応答しない場合、MIG はその VM を自動修復します。自動修復の構成の詳細については、高可用性のための VM の修復についてをご覧ください。
リージョンの停止に対する堅牢性
リージョンが停止した場合、アプリケーションは使用できなくなります。リージョンの停止によるダウンタイムを短縮するには、次のアプローチを実装します。
- 別の Google Cloud リージョンにウェブ階層とアプリケーション階層のパッシブ（フェイルオーバー）レプリカを維持します。
- アプリケーション スタックのパッシブ レプリカがあるリージョンに、必要な Exadata VM クラスタを使用してスタンバイ Exadata Infrastructure インスタンスを作成します。データ レプリケーションとスタンバイ Exadata データベースへの自動フェイルオーバーには、Oracle Data Guard を使用します。アプリケーションで目標復旧時点（RPO）を短縮する必要がある場合は、Oracle Autonomous Recovery Service を使用してデータベースをバックアップして復元できます。
- プライマリ リージョンでサービスが停止した場合は、データベース レプリカまたはバックアップを使用してデータベースを本番環境に復元し、フェイルオーバー リージョンでアプリケーションを有効にします。
- DNS ルーティング ポリシーを使用して、フェイルオーバー リージョンの外部ロードバランサにトラフィックを転送します。
リージョンの停止が発生しても引き続き使用できるようにするビジネス クリティカル アプリケーションの場合は、マルチリージョン デプロイ アーキタイプの使用を検討してください。Oracle Active Data Guard を使用して、フェイルオーバー リージョンに読み取り専用スタンバイ データベースを提供できます。
Oracle Database@Google Cloud のインフラストラクチャは Oracle が管理します。Dedicated Infrastructure 上の Oracle Exadata Database Service のサービスレベル目標（SLO）については、Oracle PaaS と IaaS のパブリック クラウド サービスのサービスレベル目標をご覧ください。
MIG の自動スケーリング
このドキュメントのアーキテクチャでは、ウェブ階層とアプリケーション階層にリージョン MIG を使用しています。ステートレス MIG の自動スケーリング機能により、ウェブ階層とアプリケーション階層をホストする Compute Engine VM が単一ゾーンの停止の影響を受けなくなります。ステートフル MIG は自動スケーリングできません。
MIG の自動スケーリングの動作を制御するには、平均 CPU 使用率などの目標使用率の指標を指定します。また、スケジュールに基づく自動スケーリングを構成することもできます。詳細については、インスタンスのグループの自動スケーリングをご覧ください。
VM の配置
このドキュメントで説明するアーキテクチャでは、アプリケーション階層とウェブ階層は、複数のゾーンに分散された Compute Engine VM で実行されます。この分散により、ウェブ階層とアプリケーション階層の単一ゾーンの停止に対する耐性が確保されます。この堅牢性をさらに改善するには、スプレッド プレースメント ポリシーを作成して MIG テンプレートに適用します。スプレッド プレースメント ポリシーを使用すると、MIG は VM を作成するときに、各ゾーンの異なる物理サーバー（ホスト）に VM を配置するため、VM は個々のホストの障害に対して堅牢になります。ただし、このアプローチのトレードオフとして、VM 間のネットワーク トラフィックのレイテンシが増加する可能性があります。詳細については、プレースメント ポリシーの概要をご覧ください。
VM のキャパシティ プランニング
MIG の自動スケーリングに必要なときに Compute Engine VM の容量を使用できるようにするには、予約を作成します。予約により、選択したマシンタイプの指定された数の VM に対して、特定のゾーンでの容量が保証されます。予約は、プロジェクトに固有のものにすることも、複数のプロジェクトで共有することもできます。予約済みリソースがプロビジョニングまたは使用されていない場合でも、予約済みのリソースには料金が発生します。課金に関する考慮事項など、予約の詳細については、Compute Engine ゾーンリソースの予約をご覧ください。
ステートフル ストレージ
アプリケーション設計におけるベスト プラクティスは、ステートフルなローカル ディスクを必要としないようにすることです。ただし、要件がある場合は、VM の修復や再作成時にデータが保持されるように、ディスクをステートフルに構成できますが、ブートディスクをステートレスのままにして、新しいバージョンやセキュリティ パッチを使用して最新のイメージに簡単に更新できるようにすることをおすすめします。詳細については、MIG でのステートフル永続ディスクの構成をご覧ください。
データベースの容量
Exadata Infrastructure は、必要に応じてデータベース サーバーとストレージ サーバーを追加することでスケーリングできます。必要なデータベース サーバーまたはストレージ サーバーを Exadata Infrastructure に追加したら、追加の CPU またはストレージ リソースを使用できるように、関連する Exadata VM クラスタに容量を追加する必要があります。詳細については、Exadata のコンピューティングとストレージのスケーリングをご覧ください。
バックアップとリカバリ
Backup and DR サービスを使用して、Compute Engine VM のバックアップを作成、保存、管理できます。Backup and DR サービスは、アプリケーションで読み取り可能な元の形式でバックアップ データを保存します。必要であれば、長期バックアップのストレージから直接データを取得することで、データの移動や準備作業に時間をかけずにワークロードを本番環境に復元できます。詳細については、Compute Engine インスタンスのバックアップ用の Backup and DR サービスをご覧ください。
デフォルトでは、専用インフラストラクチャ上の Oracle Exadata Database Service のデータベースのバックアップは OCI Object Storage に保存されます。RPO を短縮するには、Oracle Autonomous Recovery Service を使用してデータベースをバックアップして復元します。
信頼性に関するその他の考慮事項
ご自身のワークロード用のクラウド アーキテクチャを構築する際には、次のドキュメントに記載されている信頼性関連のベスト プラクティスと推奨事項を確認してください。
費用の最適化
このセクションでは、このリファレンス アーキテクチャを使用して構築した Google Cloud トポロジの設定と運用の費用を最適化するためのガイダンスを示します。
VM マシンタイプ
VM の使用率を最適化できるように、Compute Engine には推奨のマシンタイプが用意されています。この推奨事項を使用して、ウェブ階層とアプリケーション階層の VM のコンピューティング要件に一致するマシンタイプを選択します。リソース要件を予測できるワークロードの場合は、ニーズに合わせてマシンタイプをカスタマイズし、カスタム マシンタイプを使用することで費用を節約できます。
VM プロビジョニング モデル
アプリケーションがフォールト トレラントである場合、Spot VM を使用すると、ウェブ階層とアプリケーション階層で VM の Compute Engine にかかる費用を削減できます。Spot VM の費用は、通常の VM よりも大幅に低くなります。ただし、Compute Engine は処理能力を調整するため、Spot VM をプリエンプティブに停止または削除する場合があります。
Spot VM は、プリエンプションを許容でき、高可用性の要件がないバッチジョブに適しています。Spot VM は、通常の VM と同じマシンタイプ、オプション、パフォーマンスを提供します。ただし、ゾーンのリソース容量が制限されている場合は、必要な容量が再び使用可能になるまで、MIG が指定のターゲット サイズに自動的にスケールアウトできない（つまり、VM を作成できない）可能性があります。
VM リソースの使用率
ステートレス MIG の自動スケーリング機能により、アプリケーションはウェブ階層とアプリケーション階層へのトラフィックの増加を適切に処理できます。また、自動スケーリングにより、リソースの必要性が低いときに費用を削減することもできます。ステートフル MIG は自動スケーリングできません。
データベースの費用
Exadata VM クラスタを作成するときに、BYOL を選択するか、ライセンス付きの Oracle データベースをプロビジョニングできます。
同じリージョン内のアプリケーションと Oracle Exadata データベース間のデータ転送のネットワーク料金は、Oracle Database@Google Cloud サービス料金に含まれています。
費用に関するその他の考慮事項
ご自身のワークロード用のアーキテクチャを構築する際には、Google Cloud Architecture Framework: 費用の最適化に記載されている一般的なベスト プラクティスと推奨事項も検討してください。
運用効率
このセクションでは、このリファレンス アーキテクチャを使用して、効率的に運用できる Google Cloud トポロジを設計する際に考慮すべき要素について説明します。
VM 構成の更新
MIG 内の VM の構成（マシンタイプやブートディスク イメージなど）を更新するには、必要な構成を持つ新しいインスタンス テンプレートを作成し、そのテンプレートを MIG に適用します。MIG は、指定した更新方法（自動または選択）を使用して VM を更新します。可用性と業務の効率化の要件に基づいて、適切な方法を選択してください。これらの MIG の更新方法について詳しくは、MIG で新しい VM 構成を適用するをご覧ください。
VM イメージ
MIG インスタンス テンプレートでは、Google 提供の公開イメージを使用するのではなく、アプリケーションに必要な構成とソフトウェアを含むカスタム OS イメージを作成して使用することをおすすめします。カスタム イメージは、カスタム イメージ ファミリーにまとめることができます。イメージ ファミリーは、そのファミリー内の最新のイメージを指すため、特定のイメージ バージョンへの参照を手動で更新しなくても、インスタンス テンプレートやスクリプトでそのイメージを使用できます。カスタム イメージを定期的に更新して、OS ベンダーから提供されるセキュリティ アップデートとパッチを含める必要があります。
確定的なインスタンス テンプレート
MIG に使用するインスタンス テンプレートに起動スクリプトが含まれている場合（サードパーティ ソフトウェアをインストールする場合など）は、そのスクリプトでソフトウェア バージョンなどのソフトウェア インストール パラメータを明示的に指定します。そうしないと、MIG が VM を作成するときに、VM にインストールされるソフトウェアに一貫性がなくなる可能性があります。たとえば、インスタンス テンプレートに Apache HTTP Server 2.0（apache2 パッケージ）をインストールする起動スクリプトが含まれている場合は、このスクリプトで、インストールする apache2 バージョン（バージョン 2.4.53 など）を正確に指定してください。詳細については、確定的なインスタンス テンプレートをご覧ください。
データベース管理
専用インフラストラクチャ上の Oracle Exadata Database Service では、物理データベース サーバー、ストレージ サーバー、ネットワーキング ハードウェアが Oracle によって管理されます。Exadata Infrastructure インスタンスと Exadata VM クラスタは、OCI または Google Cloud インターフェースで管理できます。データベースの作成と管理は OCI インターフェースで行います。Oracle Database@Google Cloud の Google Cloud コンソール ページには、OCI コンソールの関連ページに直接移動できるリンクが含まれています。OCI に再度ログインしなくても済むようにするには、OCI と Google Cloud の間でID 連携を構成します。
運用上のその他の考慮事項
ご自身のワークロード用のアーキテクチャを構築する際には、Google Cloud アーキテクチャ フレームワーク: オペレーショナル エクセレンスで説明されている運用効率に関する一般的なベスト プラクティスと推奨事項を検討してください。
パフォーマンスの最適化
このセクションでは、このリファレンス アーキテクチャを使用して、ワークロードのパフォーマンス要件を満たす Google Cloud のトポロジを設計する際に考慮すべき要素について説明します。
コンピューティング パフォーマンス
Compute Engine には、ワークロードのパフォーマンス要件に応じて選択できる、事前定義済みのカスタマイズ可能なマシンタイプが幅広く用意されています。ウェブ階層とアプリケーション階層をホストする VM の場合は、これらの階層のパフォーマンス要件に基づいて適切なマシンタイプを選択します。詳細については、マシンシリーズの比較をご覧ください。
ネットワーク パフォーマンス
アプリケーション階層とウェブ階層内で VM 間のネットワーク レイテンシを低くする必要があるワークロードの場合は、コンパクト プレースメント ポリシーを作成して、これらの階層に使用される MIG テンプレートに適用できます。MIG は VM を作成すると、互いに近くにある物理サーバーに VM を配置します。コンパクト プレースメント ポリシーは VM 間のネットワーク パフォーマンスの向上に役立ちます。スプレッド プレースメント ポリシーは、前述のように VM の可用性の向上に役立ちます。ネットワーク パフォーマンスと可用性のバランスを最適にするために、コンパクト プレースメント ポリシーを作成するときに、VM を配置する距離を指定できます。詳細については、プレースメント ポリシーの概要をご覧ください。
Compute Engine には、下り（外向き）ネットワーク帯域幅の VM ごとの上限があります。この上限は、VM のマシンタイプと、トラフィックがソース VM と同じ VPC ネットワーク経由でルーティングされるかどうかによって異なります。特定のマシンタイプを使用する VM の場合、ネットワーク パフォーマンスを向上させるために、Tier_1 ネットワーキングを有効にして下り（外向き）の最大帯域幅を増やすことができます。詳細については、VM ごとの Tier_1 ネットワーキング パフォーマンスを構成するをご覧ください。
アプリケーション階層の VM と Oracle Exadata ネットワーク間のネットワーク トラフィックは、Google が設定する低レイテンシの Partner Interconnect 接続を介してルーティングされます。
Exadata Infrastructure は、データベース サーバー間とストレージ サーバー間の高帯域幅で低レイテンシのネットワーキングに RDMA over Converged Ethernet（RoCE）を使用します。サーバーは、プロセッサ、キャッシュ、オペレーティング システムを介さずに、メインメモリでデータを直接交換します。
パフォーマンスに関するその他の考慮事項
ご自身のワークロード用のアーキテクチャを構築する場合は、Google Cloud アーキテクチャ フレームワーク: パフォーマンスの最適化に記載されている一般的なベスト プラクティスと推奨事項を検討してください。
次のステップ
- Google Cloud と Oracle によるクラウド トランスフォーメーションの加速
- Oracle のドキュメント
- Google ドキュメント
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
協力者
著者: Kumar Dhanagopal | クロスプロダクト ソリューション デベロッパー
その他の寄稿者:
- Andy Colvin | Database Black Belt エンジニア（Oracle on Google Cloud）
- Jeff Welsch | プロダクト管理担当ディレクター
- Lee Gates | グループ プロダクト マネージャー
- Marc Fielding | データ インフラストラクチャ アーキテクト
- Mark Schlagenhauf | テクニカル ライター、ネットワーキング
- Michelle Burtoft | シニア プロダクト マネージャー
- Rajesh Kasanagottu | エンジニアリング マネージャー
- Roberto Mendez | スタッフ ネットワーク実装エンジニア
- Sekou Page | アウトバウンド プロダクト マネージャー
- Souji Madhurapantula | グループ プロダクト マネージャー
- Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング