Oracle ベース アプリケーションを Google Cloud に移行し、運用を簡素化する

※この投稿は米国時間 2025 年 1 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

昨年、Google Cloud と Oracle は、企業のクラウド トランスフォーメーションを加速させる戦略的パートナーシップを結び、Google Cloud 環境に Oracle の堅牢なデータベース機能を統合できるようにしました。

このパートナーシップは、Oracle データベースだけでなく、Oracle データベースを使用して実行するアプリケーションにも適用されます。つまり、お客様は既存の Oracle データベース アプリケーションを Google Cloud に移行することで、Google Cloud のパフォーマンス、安定性、セキュリティという利点を享受できます。また、Oracle はデータベース以外にも、移行したいと思うようなエンタープライズ アプリケーションやミドルウェア アプリケーションも多数提供しています。Google Cloud のサービスとインフラストラクチャ上で Oracle のデータベースとサービスを使用して、新しいクラウドネイティブ アプリケーションを構築し、デプロイすることももちろんできます。

このブログ投稿では、Oracle アプリケーションとデータベースを Google Cloud に移行する方法をご紹介します。コンテナ化と GraalVM がパフォーマンスとスケーラビリティの最適化にどのように役立つかに重点を置きながら、フルマネージド サービスからカスタマイズされたオプションまで、さまざまな移行パスについて詳しくご説明します。

Google Cloud における Oracle データベース

Google Cloud では、フルマネージドから高度にカスタマイズされたものまで、Oracle ワークロード向けの移行パスが複数用意されているため、ニーズに応じて柔軟に対応できます。

高パフォーマンス: 

• Google Cloud における Exadata Cloud Service: Oracle の高パフォーマンス ハードウェアである Exadata を、Google のデータセンター内で直接稼働させることができます。可能な限り最高の処理速度と処理性能を必要とする、要求の厳しいワークロードに最適です。

フルマネージド:

• Google Cloud 上の自律型データベース: Google Cloud がすべてを処理するため、Oracle の運用が非常に簡単になります。プロビジョニング、パッチ適用、スケーリング、バックアップ、復元など、必要不可欠な管理タスクがすべて自動化されるため、企業にとって最も重要なことに集中できます。

上記の移行パスはいずれも高度なマネージド サービスであるため、Oracle データベース インスタンスに変更を加える必要が（あったとしても）ほとんどなく、物理的な移行自体も Google のサポートチームが実施できます。

柔軟なオプション:

ただし、こうした柔軟なオプションのいずれかを選択する場合でも、新しいクラウドベースの環境から可能な限り最高のパフォーマンスを得るには、検討すべきことがいくつかあります。

• Compute Engine: 仮想マシン上で Oracle を実行し、制御を可能にして柔軟性を提供します。既存システムの「リフト＆シフト」の移行に適しています。

• Google Kubernetes Engine（GKE）: Oracle の Kubernetes 向けデータベース オペレーターである OraOperator を使用すると、Oracle のプラグイン可能なデータベースをデプロイできます。このユースケースについては、以下で詳しくご紹介します。

Oracle ベース アプリケーションのコンテナ化

このパートナーシップは、Google Cloud での Oracle アプリケーションのデプロイと管理に必要な柔軟性を企業に提供し、移行、モダナイゼーション、イノベーションを加速させることを目指しています。その鍵となるのがコンテナ化のサポートです。これにより、開発チームに高いレベルのアジリティとスケーラビリティがもたらされます。Oracle ベース アプリケーションが Java、Python、.NET で構築されているか、WebLogic で実行されているかにかかわらず、コンテナは整合性のある隔離された環境を提供し、プログラミング言語やフレームワークが持つ根本的な複雑さを取り除きます。

Google Cloud にはコンテナベースのランタイムが幅広く用意されており、その中から選択できます。

Google Kubernetes Engine（GKE）は、Google Cloud 上で多様なワークロードのデプロイと管理を簡素化する、汎用性の高い強力なコンテナ オーケストレーション プラットフォームです。複雑なセットアップやマイクロサービス アーキテクチャを実行する企業向けに設計された GKE は、Google のグローバル ネットワークと高パフォーマンスな VM を活用して、コンテナをスムーズかつ確実に実行できるよう最適化されたインフラストラクチャを提供します。自動スケーリングとノード自動プロビジョニングにより、コストとパフォーマンスの両方を最適化し、リアルタイムの需要に合わせてリソースを自動的に調整します。さらに、GKE はコンテナ ランタイムを幅広くサポートし、高度なネットワーキング機能を備えているため、基本的なウェブ アプリケーションからあらゆる言語で記述された要求の厳しい ML ワークロードまで、すべてを効率的に処理できるよう支援します。

次に、コンテナ化されたアプリケーションをデプロイするための、フルマネージド サーバーレス プラットフォームの Cloud Run があります。需要に応じて自動的にスケールする必要のあるアプリケーション向けに設計されているため、コードまたはコンテナ イメージを提供するだけで、後は Cloud Run が処理します。Cloud Run はトラフィックに応じてリソースを自動的にスケールアップ / スケールダウンするため、アプリケーションがアクティブにリクエストを処理しているときにしか料金は発生しません。Cloud Run を活用してプロビジョニングやスケーリングのようなサーバー管理作業をなくすことにより、ユーザーはアプリケーションの構築やデプロイに集中できます。これは、マイクロサービス、API、ウェブアプリ、イベント ドリブン関数に適しています。さらに、Cloud Run のベースイメージの自動更新により、コンテナに最新のセキュリティ パッチやオペレーティング システムのアップグレードの恩恵がもたらされるため、脆弱性を最小限に抑えてメンテナンスのオーバーヘッドを大幅に削減できます。

何より、Oracle ベースのアプリケーションをオープン スタンダードでコンテナ化するということは、前もってパスを選ぶ必要がないということです。Kubernetes を管理したくなければ、Cloud Run を使って始めましょう。後でさらに柔軟性が必要となったら、GKE に簡単に移行できます。どちらのサービスも標準的な OCI コンテナを活用し、CNCF によってサポートされているため、現在も今後も、コンテナ化されたアプリの完全な相互運用性とデプロイ選択の自由を得られます。

コンテナ化した Oracle データベースの実行

Google Cloud 内の Exadata 上で Oracle ワークロードを実行することが基本ですが、それが不可能である場合は、GKE 上での Oracle の実行を検討することをおすすめします。

• GKE 上での Oracle データベースの実行は、ワークロードが非 RAC および非 Exadata である場合や、特定のリージョンで Exadata がサポートされていない場合に適しています。

• これは、DBaaS 戦略を採用し、OraOperator を使用してライフサイクル（デプロイ、更新、削除）を実現できる多数の Oracle データベースを所有している企業にとって、効果的なソリューションとなります。

• 最新の DevOps ワークフローと継続的デプロイ戦略への統合を目的に設計されたこのアプローチは、データベースを迅速にスピンアップまたは破棄する必要がある場合に便利です。

このような背景から、前述の OraOperator はマルチテナンシーをサポートしています。これは、GKE 上で Oracle データベースを実行する際に役立つ機能です。隔離された複数のデータベースを同一の GKE クラスタ上で実行できるため、リソース使用率の向上とコスト削減に貢献します。

Java アプリケーションの強化

Oracle アプリケーションの多くは Java で記述されています。Oracle GraalVM は、ネイティブ Java アプリケーションを作成します。このツールは事前（AOT）コンパイルを使用して、Java バイトコードをネイティブ実行可能ファイルに直接変換します。実行時に Java 仮想マシン（JVM）に依存しないようにすることで、これらのアプリケーションははるかに高速に起動し、リソース（CPU とメモリ）の消費量は減少します。基本的に GraalVM は、Java が C や C++ といった言語のように動作できるようにし、クラウドネイティブなデプロイにおけるマイクロサービスやサーバーレス関数のような、リソースに制約のある環境に最適なスタンドアロン実行可能ファイルを生成します。

GKE 上で Oracle アプリケーションを実行する場合は、Java ネイティブ イメージを使用することを強くおすすめします。Java ネイティブ イメージを使用すると、VM 内から Java アプリケーションを実行する場合と比較して、リソース使用率を高度に最適化できます。その理由は、ネイティブ イメージはフットプリントが小さいからです。これにより、ワーカーノードごとにより多くの Pod を実行し、GKE クラスタ リソースを最大限に活用できるため、コストを削減できる可能性があります。Pod の起動レイテンシの短縮は、デプロイの展開時間と復元時間の短縮にも貢献し、アプリケーションのアジリティの向上につながります。

最後に、Java ネイティブ イメージを使用すると、以下のような機能によって GKE クラスタ内のコンテナのセキュリティ ポスチャーを強化できます。

• Binary Authorization によるイメージの署名と検証

• 実行中のコンテナの Java、Go、JavaScript、Python の言語パッケージのスキャンと脆弱性検出を提供する、Advanced Vulnerability Insights

• サンドボックス環境を使用して Java ネイティブ イメージに安全かつ隔離された環境を提供する、Artifact Registry に組み込まれた脆弱性スキャン

• 潜在的な攻撃対象領域を縮小し、脆弱性のリスクを最小限に抑える、Java ネイティブ イメージに必要な依存関係のみを含んだ最小限のベースイメージ

その一方、Java ネイティブ アプリケーションを Cloud Run 上で実行するとほぼ瞬時に起動するため、最初のリクエストのレイテンシを最小限に抑え、全体的な応答性を向上させることができます。Cloud Run の起動時 CPU ブースト機能は、インスタンスの起動時と起動後の 10 秒間、追加の CPU を提供します。

さらに、Cloud Run は、イベントによって関数がトリガーされるイベント ドリブン アプリケーションにも適しています。これは、ネイティブ Java イメージの一般的なユースケースです。Java Runtime Environment がなくても、イベントに迅速に応答できます。

最後に、多くの組織が Java 21 への移行を希望しています。Java 21 を採用する主な理由は、継続的な更新、セキュリティ パッチ、向上したランタイム パフォーマンス、新機能、テクニカル サポートを長期間保証することが LTS（長期サポート）で定められているという利点にあります。古い Oracle アプリケーションを GKE または Cloud Run に移行することは、同時に Java 21 にモダナイズする良い機会でもあります。

パートナーによるサポート

Oracle データベースとアプリケーションを Google Cloud に移行することは大変なタスクですが、単独で行う必要はありません。Google Cloud は、経験豊富な Oracle のエキスパートと連携して、移行をスムーズに成功へと導きます。こうしたパートナーは、Oracle のテクノロジーに関する深い知識と実績ある方法論を提供し、プロセスを通じて企業を支援します。Google のパートナー エコシステムにご連絡ください。Google Cloud 上での Oracle ワークロードの成功を加速させるお手伝いをいたします。

-アプリケーション プラットフォーム担当 EMEA プラクティス ソリューション リード Darren Evans