Compute Engine 上の Oracle Database を使用したエンタープライズ アプリケーション

Last reviewed 2025-05-27 UTC

このドキュメントでは、Oracle データベースを使用する高可用性エンタープライズ アプリケーションをホストするインフラストラクチャを構築するためのリファレンス アーキテクチャについて説明します。このスタック全体は Compute Engine VM にデプロイされます。このリファレンス アーキテクチャを使用すると、Oracle データベースを使用するオンプレミス アプリケーションを Google Cloudに効率的に再ホスト（リフト＆シフト）できます。このドキュメントには、Oracle Maximum Availability Architecture（MAA）の要件を満たすGoogle Cloud に Oracle Database トポロジを構築するためのガイダンスも記載されています。このドキュメントは、クラウド アーキテクトと Oracle データベース管理者を対象としています。このドキュメントは、Compute Engine と Oracle Database に精通していることを前提としています。

Oracle Exadata または Oracle Real Application Clusters（Oracle RAC）を使用して Oracle データベースをオンプレミスで実行している場合は、アプリケーションを Google Cloud に効率的に移行し、Oracle Database@Google Cloud でデータベースを実行できます。詳細については、 Google Cloudで Oracle Exadata を使用する Compute Engine VM 上のエンタープライズ アプリケーションをご覧ください。

アーキテクチャ

次の図は、Oracle Database を使用する多層エンタープライズ アプリケーションのインフラストラクチャを示しています。ウェブ階層、アプリケーション階層、Oracle Database インスタンスは Compute Engine VM にホストされます。ウェブ階層とアプリケーション階層は、 Google Cloudリージョン内の 2 つのゾーンに分散された VM で、アクティブ / アクティブ モードで実行されます。プライマリ データベース インスタンスとスタンバイ データベース インスタンスは別々のゾーンにデプロイされます。このアーキテクチャは、リージョン デプロイ アーキタイプに沿ったものになっており、 Google Cloud トポロジが単一ゾーンの停止に対して堅牢であることを保証します1。

多層エンタープライズ アプリケーションは、Compute Engine VM で Oracle Database を使用します。

上記の図に示すアーキテクチャには、次のコンポーネントが含まれています。

コンポーネント 目的
リージョン外部アプリケーション ロードバランサ リージョン外部アプリケーション ロードバランサは、ユーザーのリクエストを受信してウェブ階層の 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 には、アプリケーション サーバーの独立したインスタンスがホストされます。
Compute Engine VM にデプロイされた Oracle Database インスタンス このアーキテクチャのアプリケーションは、個別のゾーンの Compute Engine VM にデプロイされた Oracle Database インスタンスのプライマリ スタンバイ ペアを使用します。これらの Oracle Database インスタンスにはお客様所有のライセンス（BYOL）を使用し、VM とデータベース インスタンスを管理します。
Hyperdisk ストレージ プール 各ゾーン（アプリケーション スタックのすべての階層）の VM は、Hyperdisk ストレージ プールから Hyperdisk Balanced ボリュームを使用します。単一のストレージ プールですべてのディスクを作成して管理すると、VM に必要なストレージ容量とパフォーマンスを維持しながら、容量使用率を改善し、運用の複雑さを軽減できます。
Oracle Data Guard FSFO オブザーバー Oracle Data Guard Fast-Start Failover（FSFO）オブザーバーは、プライマリ インスタンスが使用できなくなったときに、スタンバイ Oracle Database インスタンスへの自動フェイルオーバーを開始する軽量のプログラムです。オブザーバーは、プライマリ データベース インスタンスとスタンバイ データベース インスタンスがデプロイされているゾーンとは異なるゾーンの Compute Engine VM で実行されます。
Cloud Storage バケット このアーキテクチャでは、Oracle Database インスタンスのバックアップを保存するために Cloud Storage バケットを使用します。リージョンの停止中にデータベースの復元を容易にするため、バックアップをデュアルリージョンまたはマルチリージョン バケットに保存し、地理的な冗長性を確保できます。
Virtual Private Cloud（VPC）ネットワークとサブネット。 このアーキテクチャ内のすべての Google Cloud リソースは、単一の VPC ネットワークとサブネットを使用します。要件に応じて、複数の VPC ネットワークまたは複数のサブネットを使用するアーキテクチャを構築できます。詳細については、複数の VPC ネットワークを作成するかどうかを決定するをご覧ください。
パブリック Cloud NAT ゲートウェイ このアーキテクチャには、Compute Engine VM からの安全なアウトバウンド接続を可能にするパブリック Cloud NAT ゲートウェイが含まれています。この VM は内部 IP アドレスのみを持ちます。
Cloud Interconnect と Cloud VPN オンプレミス ネットワークを Google Cloudの VPC ネットワークに接続するには、Cloud Interconnect または Cloud VPN を使用します。各アプローチの相対的な利点については、Network Connectivity プロダクトの選択をご覧ください。
Cloud Monitoring と Cloud Logging Cloud Monitoring を使用すると、アプリケーションと Google Cloud リソースの動作、健全性、パフォーマンスをモニタリングできます。Ops エージェントは、Oracle Database インスタンスをホストする VM など、Compute Engine VM から指標とログを収集します。エージェントはログを Cloud Logging に送信し、指標を Cloud Monitoring に送信します。

使用するプロダクト

このリファレンス アーキテクチャでは、次の Google Cloud プロダクトを使用します。

  • Compute Engine: Google のインフラストラクチャで VM を作成して実行できる、安全でカスタマイズ可能なコンピューティング サービス。
  • Google Cloud Hyperdisk: 構成可能かつ予測可能なパフォーマンスで、ブロック ストレージ ボリュームをプロビジョニングして動的にスケーリングできるネットワーク ストレージ サービス。
  • Cloud Load Balancing: 高パフォーマンスでスケーラブルなグローバル ロードバランサとリージョン ロードバランサのポートフォリオ。
  • Cloud Storage: 低コストで無制限のオブジェクト ストア。さまざまなデータ型に対応しています。データには Google Cloudの内部および外部からアクセスでき、冗長性を確保するために複数のロケーションに複製されます。
  • Virtual Private Cloud（VPC）: Google Cloud ワークロードにグローバルでスケーラブルなネットワーキング機能を提供する仮想システム。VPC には、VPC ネットワーク ピアリング、Private Service Connect、プライベート サービス アクセス、共有 VPC が含まれます。
  • Google Cloud Armor: ウェブ アプリケーション ファイアウォール（WAF）ルールを提供し、DDoS 攻撃やアプリケーション攻撃から保護するネットワーク セキュリティ サービス。
  • Cloud NAT: Google Cloudが管理する高パフォーマンスのネットワーク アドレス変換を提供するサービス。
  • Cloud Monitoring: アプリケーションとインフラストラクチャのパフォーマンス、可用性、動作状況を可視化するサービス。
  • Cloud Logging: ストレージ、検索、分析、アラート機能を備えたリアルタイムのログ管理システム。
  • Cloud Interconnect: 高可用性で低レイテンシの接続を通じて、外部ネットワークを Google ネットワークに拡張するサービス。
  • Cloud VPN: IPsec VPN トンネルを介してピア ネットワークを Google のネットワークに安全に拡張するサービス。

このリファレンス アーキテクチャでは、次の Oracle 製品を使用します。

  • Oracle Database: リレーショナル モデルをオブジェクト リレーショナル モデルに拡張するリレーショナル データベース管理システム（RDBMS）。
  • Oracle Data Guard: 1 つ以上のスタンバイ データベースの作成、維持、管理、モニタリングを行う一連のサービス。

Google Cloudにデプロイする Oracle 製品のライセンスの調達と Oracle ライセンスの利用規約への準拠は、お客様の責任となります。

設計上の考慮事項

このセクションでは、このリファレンス アーキテクチャを使用して、セキュリティ、信頼性、運用効率、費用、パフォーマンスに関する特定の要件を満たすトポロジを開発する際に考慮すべき設計要素、ベスト プラクティス、設計に関する推奨事項について説明します。

このセクションのガイダンスはすべてを網羅しているわけではありません。アプリケーションの特定の要件と、使用する Google Cloud およびサードパーティのプロダクトや機能によっては、考慮すべき追加の設計要素やトレードオフが存在する可能性があります。

システム設計

このセクションでは、デプロイに使用する Google Cloud リージョンの選択と、適切な Google Cloud サービスの選択に役立つガイダンスを示します。

リージョンの選択

アプリケーションをデプロイする Google Cloud リージョンを選択する場合は、次の要素と要件を考慮してください。

これらの要素や要件の中には、トレードオフを伴うものもあります。たとえば、費用対効果の最も高いリージョンが、温室効果ガス排出量が最も少ないリージョンとは限りません。詳細については、Compute Engine のリージョン選択に関するベスト プラクティスをご覧ください。

コンピューティング インフラストラクチャ

このドキュメントのリファレンス アーキテクチャでは、アプリケーションの特定の階層に Compute Engine VM を使用しています。アプリケーションの要件に応じて、他の Google Cloud コンピューティング サービスを選択できます。

  • コンテナ: Google Kubernetes Engine（GKE）クラスタでは、コンテナ化されたアプリケーションを実行できます。GKE は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するコンテナ オーケストレーション エンジンです。
  • サーバーレス: インフラストラクチャ リソースの設定や運用ではなく、データとアプリケーションに IT の労力を集中させたい場合は、Cloud Run などのサーバーレス サービスを使用します。

VM、コンテナ、サーバーレス サービスのどれを使用するかの決定には、構成の柔軟性と管理上の労力とのトレードオフが伴います。VM とコンテナは比較的柔軟に構成できますが、リソースの管理責任はユーザーにあります。サーバーレス アーキテクチャでは、必要となる管理作業が最も少ない事前構成されたプラットフォームにワークロードをデプロイします。Google Cloudのワークロードに適したコンピューティング サービスの選択の詳細については、 Google Cloudでのアプリケーションのホスティングをご覧ください。

ストレージ オプション

このドキュメントに示すアーキテクチャでは、各ゾーンに Hyperdisk ストレージ プールを使用し、すべての階層の VM に Hyperdisk Balanced ボリュームを使用します。Hyperdisk ボリュームは、Persistent Disk よりもパフォーマンス、柔軟性、効率性に優れています。Hyperdisk のタイプと機能については、Hyperdisk Balanced についてをご覧ください。

リージョン内の複数の VM（ウェブ階層のすべての VM の構成ファイルなど）で共有されるデータを保存するには、Filestore リージョン インスタンスを使用します。Filestore リージョン インスタンスに保存されたデータは、リージョン内の 3 つのゾーン間で同期してレプリケートされます。このレプリケーションにより、ゾーンの停止に対する高可用性と堅牢性が確保されます。Filestore インスタンスには、共有構成ファイル、一般的なツールとユーティリティ、一元化されたログを保存し、そのインスタンスを複数の VM にマウントできます。

ワークロード用のストレージを設計する場合は、ワークロードの機能特性、復元力に関する要件、パフォーマンスの期待値、費用目標を検討します。詳細については、クラウド ワークロードに最適なストレージ戦略の設計をご覧ください。

ネットワーク設計

マルチティア アプリケーション スタック用のインフラストラクチャを構築する場合は、ビジネス要件と技術要件を満たすネットワーク設計を選択する必要があります。このドキュメントに示すアーキテクチャでは、単一の VPC ネットワークとサブネットを使用するシンプルなネットワーク トポロジを使用しています。要件に応じて、複数の VPC ネットワークまたは複数のサブネットを使用するように選択できます。詳細については、以下のドキュメントをご覧ください。

セキュリティ、プライバシー、コンプライアンス

このセクションでは、このリファレンス アーキテクチャを使用して、ワークロードのセキュリティとコンプライアンスの要件を満たす 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 ボリュームに保存されるデータは Google-owned and Google-managed encryption keysを使用して暗号化されます。保護レイヤを追加するには、Cloud Key Management Service（Cloud KMS）で所有、管理する鍵を使用して、Google 所有のデータ暗号鍵を暗号化できます。詳細については、ディスクの暗号化についてをご覧ください。

ネットワーク セキュリティ

アーキテクチャのリソース間のネットワーク トラフィックを制御するには、適切な Cloud Next Generation Firewall（NGFW）ポリシーを構成する必要があります。

セキュリティ上のその他の考慮事項

ワークロードのアーキテクチャを構築する際は、エンタープライズ基盤のブループリントと Google Cloud Well-Architected Framework: セキュリティ、プライバシー、コンプライアンスで提供されているプラットフォーム レベルのセキュリティのベスト プラクティスと推奨事項を検討してください。

信頼性

このセクションでは、このリファレンス アーキテクチャを使用して、Google Cloudのデプロイ用に信頼性の高いインフラストラクチャを構築して運用する際に考慮すべき設計要素について説明します。

VM 障害に対する堅牢性

このドキュメントで説明するアーキテクチャでは、いずれかの階層の Compute Engine VM で障害が発生しても、アプリケーションはリクエストの処理を続行できます。

  • ウェブ階層またはアプリケーション階層の VM がクラッシュすると、関連する MIG が VM を自動的に再作成します。ロードバランサは、現在使用可能なウェブサーバー インスタンスとアプリケーション サーバー インスタンスにのみリクエストを転送します。
  • プライマリ Oracle Database インスタンスをホストする VM で障害が発生すると、Oracle Data Guard FSFO オブザーバーはスタンバイ Oracle Database インスタンスへの自動フェイルオーバーを開始します。

VM の自動修復

アプリケーションをホストする VM が動作しており利用可能な場合でも、アプリケーション自体に問題がある場合があります。アプリケーションでフリーズやクラッシュが発生したり、メモリ不足になることがあります。アプリケーションが期待どおりに応答しているかどうかを確認するには、MIG の自動修復ポリシーの一部としてアプリケーション ベースのヘルスチェックを構成します。特定の VM 上のアプリケーションが応答しない場合、MIG はその VM を自動修復します。自動修復の構成の詳細については、高可用性のための VM の修復についてをご覧ください。

ゾーンの停止に対する堅牢性

ゾーンが停止しても、アプリケーションは引き続き使用できます。

  • VM はリージョン MIG 内にあるため、ウェブ階層とアプリケーション階層は使用可能であり、応答も可能です。リージョン MIG により、他のゾーンに新しい VM が自動的に作成され、最小構成の VM 数が維持されます。ロードバランサは、使用可能なウェブサーバー VM とアプリケーション サーバー VM にリクエストを転送します。
  • プライマリ Oracle Database インスタンスがあるゾーンにも停止の影響が及ぶ場合、Oracle Data Guard FSFO オブザーバーはスタンバイ Oracle Database インスタンスへの自動フェイルオーバーを開始します。FSFO オブザーバーは、プライマリ データベース インスタンスとスタンバイ データベース インスタンスがあるゾーンとは異なるゾーンの VM で実行されます。
  • 単一ゾーン停止時の Hyperdisk ボリュームのデータの高可用性を確保するには、Hyperdisk Balanced High Availability を使用します。データがボリュームに書き込まれると、同じリージョン内の 2 つのゾーン間でデータが同期的に複製されます。

リージョンの停止に対する堅牢性

このアーキテクチャの両方のゾーンが停止した場合や、リージョンが停止した場合、アプリケーションは使用不能になります。マルチゾーンまたはリージョンの停止によるダウンタイムを短縮するには、次のアプローチを実装します。

  • 別の Google Cloud リージョンにインフラストラクチャ スタックのパッシブ（フェイルオーバー）レプリカを維持します。

  • デュアルリージョンまたはマルチリージョンの Cloud Storage バケットを使用して、Oracle Database のバックアップを保存します。バックアップは、少なくとも 2 つの地理的位置に非同期で複製されます。アーキテクチャは、複製されたデータベース バックアップを使用して、Oracle Maximum Availability Architecture（MAA）Silver ティアにマッピングされます。

    デュアルリージョン バケットに保存されているバックアップのレプリケーションを高速化するには、ターボ レプリケーションを使用します。詳細については、データの可用性と耐久性をご覧ください。

  • プライマリ リージョンでサービスが停止した場合は、データベースのバックアップを使用してデータベースを復元し、フェイルオーバー リージョンでアプリケーションを有効にします。DNS ルーティング ポリシーを使用して、フェイルオーバー リージョンのロードバランサにトラフィックを転送します。

リージョンの停止が発生しても引き続き使用できるようにするビジネス クリティカル アプリケーションの場合は、マルチリージョン デプロイ アーキタイプの使用を検討してください。データベース階層では、Oracle Active Data Guard FSFO を使用して、フェイルオーバー リージョンのスタンバイ Oracle Database インスタンスに自動的にフェイルオーバーできます。このアプローチは、Oracle MAA Gold ティアにマッピングされます。

MIG の自動スケーリング

ステートレス MIG の自動スケーリングの動作を制御するには、CPU の平均使用率などの目標使用率の指標を指定します。ステートレス MIG にスケジュール ベースの自動スケーリングを構成することもできます。ステートフル MIG は自動スケーリングできません。詳細については、インスタンスのグループの自動スケーリングをご覧ください。

MIG サイズの上限

MIG のサイズを決める際は、MIG で作成できる VM の数のデフォルトと上限を考慮してください。詳細については、MIG の VM を追加または削除するをご覧ください。

VM の配置

アーキテクチャの堅牢性を向上させるには、スプレッド プレースメント ポリシーを作成して MIG テンプレートに適用します。MIG は VM を作成する際、異なる物理サーバー（ホスト）の各ゾーンに VM を配置するため、VM は個々のホストの障害に対する耐性が強化されます。詳細については、スプレッド プレースメント ポリシーを作成して VM に適用するをご覧ください。

VM のキャパシティ プランニング

VM をプロビジョニングする必要があるときに Compute Engine VM の容量を使用できるようにするには、予約を作成します。予約することで、選択したマシンタイプの指定した数の VM に対して、特定のゾーンでの容量が保証されます。予約は、プロジェクトに固有のものにすることも、複数のプロジェクトで共有することもできます。予約の詳細については、予約タイプを選択するをご覧ください。

ブロック ストレージの可用性

このドキュメントのアーキテクチャでは、各ゾーンの Hyperdisk ストレージ プールを使用して、Compute Engine VM にブロック ストレージを提供します。ゾーンにブロック ストレージ容量のプールを作成します。次に、ストレージ プールに Hyperdisk ボリュームを作成し、ボリュームをゾーンの VM にアタッチします。ストレージ プールは、使用率がプールのプロビジョニング容量の 80% を超えないように、容量を自動的に追加しようとします。このアプローチにより、必要に応じてブロック ストレージ容量を確保できます。詳細については、Hyperdisk ストレージ プールの仕組みをご覧ください。

ステートフル ストレージ

アプリケーション設計におけるベスト プラクティスは、ステートフルなローカル ディスクを必要としないようにすることです。ただし、要件が存在する場合は、VM の修復または再作成時にデータが保持されるように、永続ディスクをステートフルに構成できます。ただし、ブートディスクはステートレスのままにし、新しいバージョンとセキュリティ パッチで最新のイメージに更新できるようにすることをおすすめします。詳細については、MIG でのステートフル永続ディスクの構成をご覧ください。

バックアップとリカバリ

このドキュメントのアーキテクチャでは、Cloud Storage を使用してデータベース バックアップを保存します。Cloud Storage バケットのデュアルリージョンまたはマルチリージョンのロケーション タイプを選択すると、バックアップは 2 つ以上の地理的位置に非同期で複製されます。リージョンが停止した場合は、バックアップを使用して別のリージョンにデータベースを復元できます。デュアルリージョン バケットでは、ターボ レプリケーション オプションを有効にしてレプリケーションを高速化できます。詳細については、データの可用性と耐久性をご覧ください。

Backup and DR サービスを使用して、Compute Engine VM のバックアップを作成、保存、管理できます。Backup and DR サービスは、アプリケーションで読み取り可能な元の形式でバックアップ データを保存します。必要であれば、長期バックアップのストレージから直接データを取得することで、データの移動や準備作業に時間をかけずにワークロードを本番環境に復元できます。詳細については、以下のドキュメントをご覧ください。

信頼性に関するその他の考慮事項

ご自身のワークロード用のクラウド アーキテクチャを構築する際には、次のドキュメントに記載されている信頼性関連のベスト プラクティスと推奨事項を確認してください。

費用の最適化

このセクションでは、このリファレンス アーキテクチャを使用して構築した Google Cloud トポロジの設定と運用の費用を最適化するためのガイダンスを示します。

VM マシンタイプ

VM インスタンスのリソース使用率を最適化できるように、Compute Engine には推奨のマシンタイプが用意されています。この推奨事項を参照して、ワークロードのコンピューティング要件と一致するマシンタイプを選択します。リソース要件を予測できるワークロードの場合は、ニーズに合わせてマシンタイプをカスタマイズし、カスタム マシンタイプを使用することで費用を節約できます。

VM プロビジョニング モデル

アプリケーションがフォールト トレラントである場合、Spot VM を使用すると、アプリケーション階層とウェブ階層で VM の Compute Engine にかかる費用を削減できます。Spot VM の費用は、通常の VM よりも大幅に低くなります。ただし、Compute Engine は処理能力を調整するため、Spot VM をプリエンプティブに停止または削除する場合があります。

Spot VM は、プリエンプションを許容でき、高可用性の要件がないバッチジョブに適しています。Spot VM は、通常の VM と同じマシンタイプ、オプション、パフォーマンスを提供します。ただし、ゾーンのリソース容量が制限されている場合は、必要な容量が再び使用可能になるまで、MIG が指定のターゲット サイズに自動的にスケールアウトできない可能性があります（つまり、VM を作成できない可能性があります）。

VM リソースの使用率

ステートレス MIG の自動スケーリング機能により、アプリケーションはトラフィックの増加を適切に処理でき、リソースの必要性が低いときに費用を削減できます。ステートフル MIG は自動スケーリングできません。

Oracle Database のライセンス

Compute Engine にデプロイする Oracle 製品のライセンスの調達と Oracle ライセンスの利用規約への準拠は、お客様の責任となります。Oracle Database のライセンス費用を計算する場合は、Oracle Database インスタンスをホストする Compute Engine VM に選択したマシンタイプに基づいて、必要な Oracle プロセッサ ライセンス数を考慮してください。詳細については、クラウド コンピューティング環境における Oracle ソフトウェアのライセンスをご覧ください。

ブロック ストレージのリソース使用率

このドキュメントのアーキテクチャでは、各ゾーンの Hyperdisk ストレージ プールを使用して、Compute Engine VM にブロック ストレージを提供します。大容量ストレージ プールを使用すると、ブロック ストレージ容量の全体的な使用率を改善し、コストを削減できます。大容量ストレージ プールは、シン プロビジョニングとデータ削減技術を使用してストレージの効率を高めます。

費用に関するその他の考慮事項

ワークロードのアーキテクチャを構築する際には、Google Cloud Well-Architected Framework: Cost optimization に記載されている一般的なベスト プラクティスと推奨事項も検討してください。

業務の効率化

このセクションでは、このリファレンス アーキテクチャを使用して、効率的に運用できる Google Cloud トポロジを設計する際に考慮すべき要素について説明します。

VM 構成の更新

MIG 内の VM の構成（マシンタイプやブートディスク イメージなど）を更新するには、必要な構成を持つ新しいインスタンス テンプレートを作成し、そのテンプレートを MIG に適用します。MIG は、選択した更新方法（自動または選択）を使用して VM を更新します。可用性と業務の効率化の要件に基づいて、適切な方法を選択してください。これらの MIG の更新方法について詳しくは、MIG で新しい VM 構成を適用するをご覧ください。

VM イメージ

VM では、Google 提供の公開イメージを使用するのではなく、アプリケーションに必要な構成とソフトウェアを含むカスタム OS イメージを作成して使用することをおすすめします。カスタム イメージは、カスタム イメージ ファミリーにまとめることができます。イメージ ファミリーは、そのファミリー内の最新のイメージを指すため、特定のイメージ バージョンへの参照を手動で更新しなくても、インスタンス テンプレートやスクリプトでそのイメージを使用できます。カスタム イメージを定期的に更新して、OS ベンダーから提供されるセキュリティ アップデートとパッチを含める必要があります。

確定的なインスタンス テンプレート

MIG に使用するインスタンス テンプレートに、サードパーティ ソフトウェアをインストールする起動スクリプトが含まれている場合は、そのスクリプトでソフトウェア バージョンなどのソフトウェア インストール パラメータを明示的に指定します。そうしないと、MIG が VM を作成するときに、VM にインストールされるソフトウェアに一貫性がなくなる可能性があります。たとえば、インスタンス テンプレートに Apache HTTP Server 2.0（apache2 パッケージ）をインストールする起動スクリプトが含まれている場合は、このスクリプトで、インストールする apache2 バージョン（バージョン 2.4.53 など）を正確に指定してください。詳細については、確定的なインスタンス テンプレートをご覧ください。

ブロック ストレージ管理

このドキュメントのアーキテクチャでは、各ゾーンの Hyperdisk ストレージ プールを使用して、Compute Engine VM にブロック ストレージを提供します。Hyperdisk ストレージ プールは、ストレージ管理を簡素化します。多数のディスクに容量を個別に割り当てて管理するのではなく、ゾーン内の複数のワークロード間で共有できる容量のプールを定義します。次に、ストレージ プールに Hyperdisk ボリュームを作成し、そのボリュームをゾーンの VM にアタッチします。ストレージ プールは、使用率がプールのプロビジョニング容量の 80% を超えないように、容量を自動的に追加しようとします。

アプリケーション サーバーからデータベースへの接続

アプリケーションから Oracle Database への接続では、IP アドレスではなく、データベース VM のゾーン内部 DNS 名を使用することをおすすめします。 Google Cloud は、DNS 名を VM のプライマリ内部 IP アドレスに自動的に解決します。データベース VM の静的内部 IP アドレスを予約して割り当てる必要がないことも、このアプローチの利点となります。

Oracle Database の管理とサポート

Compute Engine VM でセルフマネージド Oracle Database インスタンスを実行する場合、Oracle Database をオンプレミスで実行する場合と同様の運用上の懸念事項があります。ただし、Compute Engine VM を使用すると、基盤となるコンピューティング、ネットワーキング、ストレージ インフラストラクチャを管理する必要がなくなります。

運用上のその他の考慮事項

ワークロードのアーキテクチャを構築する際には、Google Cloud Well-Architected Framework: Operational excellence で説明されている運用効率に関する一般的なベスト プラクティスと推奨事項を検討してください。

パフォーマンスの最適化

このセクションでは、このリファレンス アーキテクチャを使用して、ワークロードのパフォーマンス要件を満たす Google Cloud のトポロジを設計する際に考慮すべき要素について説明します。

コンピューティング パフォーマンス

Compute Engine には、ワークロードのパフォーマンス要件に応じて選択できる、事前定義済みでカスタマイズ可能なマシンタイプが幅広く用意されています。

  • ウェブ階層とアプリケーション階層をホストする VM の場合は、これらの階層のパフォーマンス要件に基づいて適切なマシンタイプを選択します。Hyperdisk ボリュームをサポートし、パフォーマンスなどの要件を満たす使用可能なマシンタイプのリストを取得するには、マシンシリーズの比較の表を使用します。
  • Oracle Database インスタンスをホストする VM には、汎用マシン ファミリーの C4 マシンシリーズのマシンタイプを使用することをおすすめします。C4 マシンタイプは、データベース ワークロードに対して一貫して高いパフォーマンスを提供します。

VM のマルチスレッディング

Compute Engine VM に割り当てる各仮想 CPU（vCPU）は、単一のハードウェア マルチスレッドとして実装されます。デフォルトでは、2 つの vCPU が 1 つの物理 CPU コアを共有します。高度な並列演算や浮動小数点計算を実行するアプリケーション（遺伝子配列分析や財務リスク モデリングなど）では、各物理 CPU コアで実行されるスレッド数を減らすことでパフォーマンスを改善できます。詳細については、コアあたりのスレッド数を設定するをご覧ください。

VM のマルチスレッディングは、サードパーティ ソフトウェア（データベースなど）のライセンスに影響する場合があります。詳細については、サードパーティ ソフトウェアのライセンスに関するドキュメントをご覧ください。

ネットワーク パフォーマンス

アプリケーション階層とウェブ階層内で VM 間のネットワーク レイテンシを低くする必要があるワークロードの場合は、コンパクト プレースメント ポリシーを作成して、これらの階層に使用される MIG テンプレートに適用できます。MIG は VM を作成すると、互いに近くにある物理サーバーに VM を配置します。コンパクト プレースメント ポリシーは VM 間のネットワーク パフォーマンスの向上に役立ちます。スプレッド プレースメント ポリシーは、前述のように VM の可用性の向上に役立ちます。ネットワーク パフォーマンスと可用性のバランスを最適にするために、コンパクト プレースメント ポリシーを作成するときに、VM を配置する距離を指定できます。詳細については、プレースメント ポリシーの概要をご覧ください。

Compute Engine には、下り（外向き）ネットワーク帯域幅の VM ごとの上限があります。この上限は、VM のマシンタイプと、トラフィックがソース VM と同じ VPC ネットワーク経由でルーティングされるかどうかによって異なります。特定のマシンタイプを使用する VM の場合、ネットワーク パフォーマンスを向上させるために、Tier_1 ネットワーキングを有効にして下り（外向き）の最大帯域幅を増やすことができます。

Hyperdisk ストレージのパフォーマンス

このドキュメントで説明するアーキテクチャでは、すべての階層の VM に Hyperdisk ボリュームを使用します。Hyperdisk を使用すると、パフォーマンスと容量を動的にスケーリングできます。ワークロードのストレージのパフォーマンスと容量のニーズに合わせて、プロビジョニングされた IOPS、スループット、各ボリュームのサイズを調整できます。Hyperdisk ボリュームのパフォーマンスは、Hyperdisk のタイプと、ボリュームがアタッチされている VM のマシンタイプによって異なります。Hyperdisk のパフォーマンスの上限と調整の詳細については、次のドキュメントをご覧ください。

パフォーマンスに関するその他の考慮事項

ワークロードのアーキテクチャを構築する際には、Google Cloud Well-Architected Framework: Performance optimization に記載されている一般的なベスト プラクティスと推奨事項も検討してください。

次のステップ

寄稿者

著者:

その他の寄稿者:

  • Andy Colvin | Database Black Belt エンジニア、Oracle on Google Cloud
  • Jeff Welsch | プロダクト管理担当ディレクター
  • Lee Gates | グループ プロダクト マネージャー
  • Marc Fielding | データ インフラストラクチャ アーキテクト
  • Mark Schlagenhauf | テクニカル ライター、ネットワーキング
  • Michelle Burtoft | シニア プロダクト マネージャー
  • Rajesh Kasanagottu | エンジニアリング マネージャー
  • Sekou Page | アウトバウンド プロダクト マネージャー
  • Souji Madhurapantula | グループ プロダクト マネージャー
  • Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング
  • Yeonsoo Kim | プロダクト マネージャー

  1. リージョン固有の考慮事項の詳細については、地域とリージョンをご覧ください。 ↩