VMware Cloud on AWS で Oracle Database の移行を成功させるための戦略

お客様は、既存のデータセンターのインフラストラクチャを強化し、ワークロードをクラウドに移行する効果的な方法を求めています。また、vSphere 環境で Oracle Database を稼働させている組織では、データベースの移行パスと、その最適なパスを探しています。

VMware Cloud on AWS を使用すると、お客様は VMware の Software-Defined Data Center (SDDC) をデプロイし、アマゾンウェブサービス (AWS) のグローバルインフラストラクチャ上で vSphere ワークロードをマネージドサービスとして使用できます。これにより、お客様はマシンイメージ形式を変換したり、プラットフォームを再構築したりすることなく、オンプレミスのデータセンターを拡張し、ワークロードを簡単に移行できます。

本稿では、オンプレミスの vSphere 環境から AWS へのデータベースの移行パス、及び VMware Cloud on AWS と AWS のデータベースサービスを統合することの利点について説明します。また、それぞれの移行パスがお客様の業務の合理化、コスト削減、全体的なビジネスアジリティの向上にどのように役立つかについても説明します。

データベース移行パス

AWS は、「7 R」とも呼ばれるアプリケーションをクラウドに移行するための 7 つの戦略を定義しました。オンプレミスの vSphere 環境から Oracle Database への移行を検討する場合、AWS には 4 つのパス（本稿では「4 R」と呼びます）があります。

図 1 — AWS へのデータベース移行パス (4 R)

Relocate

Relocate は、データベース仮想マシンを含む仮想マシン (VM) 全体を VMware Cloud on AWS SDDC に移行するために使用されます。

このパスは、進行中のオペレーションに影響を与えたり、アプリケーションを書き直したりすることなく、Oracle Database を移行する最も簡単な方法です。限られた時間内に移行する必要があるデータベースが多数ある場合は、出発点として適しています。

VMware Cloud on AWS のホストタイプを確認して、利用可能な最新の導入オプションとデータベース VM のリソース使用量を確認し、最適な構成を決定してください。また、移行を完了するために必要なライセンス数を決定するために、Oracle ライセンス契約を確認する必要があります。

Rehost

Rehost は、Relocate と同様に他のワークロードを VMware Cloud on AWS SDDC に移行する一方で、データベース VM を Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに変換するため、変更が最小限で済みます。

Amazon EC2 では、お客様の Oracle ワークロードのニーズに合う幅広いインスタンスタイプを提供しており、既存の Oracle Database ライセンス (BYOL) を使用して Oracle Database を EC2 上で実行できます。Amazon EC2 でデータベースを実行するのに必要なライセンス数については、クラウドでの Oracle ソフトウェアのライセンスに関する Oracle のポリシーを参照してください。この情報は、ライセンスの購入やコンプライアンスに関するガイダンスとして使用してはならないことに注意してください。教育のみを目的としているため、お客様は各自の Oracle ライセンス契約で詳細を確認する必要があります。

Replatform

Replatform は、データベース VM を Amazon Relational Database Service (Amazon RDS) for Oracle に移行する場合に使用します。他のワークロードは VMware Cloud on AWS SDDC に移行します。Amazon RDS は、クラウドでリレーショナルデータベースを簡単に設定、運用、およびスケーリングできるようにすることで、重要なトランザクションアプリケーションをサポートする複雑さを軽減します。

Amazon RDS は、コスト効率と拡張性に優れたキャパシティを提供しながら、ハードウェアのプロビジョニング、データベースのセットアップ、パッチ適用、バックアップといった時間のかかる管理作業を自動化します。これにより、アプリケーションに必要なパフォーマンス、高可用性、セキュリティ、互換性を実現することに集中できます。

RDS は、メモリ、パフォーマンス、または I/O に最適化された複数のデータベースインスタンスタイプで使用でき、Oracle Database を含む 6 つの使い慣れたデータベースエンジンを提供します。Amazon RDS では、Oracle Database のライセンスを持ち込むことができます。また、Standard Edition 2 (SE2) のライセンス込み (LI) モデルも提供されており、コンピューティング性能に対して、時間単位で支払うことができます。この為、長期的なコミットメントなしにデータベースインスタンスを実行する事ができます。

Refactor

Refactor は、ワークロードを再設計し、データベースエンジンを Oracle Database から変更し、Amazon RDS、Amazon Aurora、または Amazon Redshift に移行するために使用されます。PostgreSQL や MySQL などの異なるデータベースエンジンを使用するようにアプリケーションコードを変更し、データを新しいエンジンに移行します。その他のすべてのワークロードは、VMware Cloud on AWS SDDC に移行できます。

この戦略には多大な労力とリソースが必要ですが、最も将来を見据えた移行アプローチと考えられています。Amazon Aurora は、ハイエンドの商用データベースの速度と信頼性に、オープンソースデータベースのシンプルさと費用対効果を組み合わせたリレーショナルデータベースサービスです。Aurora は MySQL および PostgreSQL と完全な互換性を持ちながら、標準的なインストールと比較して、より高いスループットと低いレイテンシーを実現し、総所有コスト (TCO) が、より低くなるように設計されています。

AWS データベースサービスとの統合

VMware Cloud on AWS のお客様は、SDDC をネイティブ AWS サービスとシームレスに統合できます。SDDC のオンボーディングプロセスにおいて、お客様が指定した Virtual Private Cloud (VPC) に広帯域で低レイテンシーの接続を確立できます。この接続先は、Connected VPC とよく呼ばれます。この接続は、VMware によって管理されているアカウント内にある NSX Edge アプライアンスと、お客様管理アカウントの Connected VPC 内のサブネットとの間で、クロスアカウントの Elastic Network Interface (ENI) を使用して確立されます。

SDDC と宛先のネイティブサービスが同じアベイラビリティーゾーン (AZ) にある限り、SDDC と Connected VPC 間のデータ転送料金は発生しません。図 2 は、SDDC 内の VM から NSX Edge と ENI を経由して、Connected VPC 内のネイティブ AWS サービスにアクセスするデータを示しています。

図 2 — VMware Cloud on AWS とネイティブ AWS サービスの統合

データベース移行に関するお客様の懸念と回避策

お客様は、vSphere 環境上の Oracle Databaseから Amazon RDS に移行する際、潜在的なパフォーマンスの低下や可用性要件への対応について懸念されるかもしれません。これらの懸念事項に対処する際に確認および考慮すべき点は以下のとおりです。

パフォーマンス

Amazon EC2 または Amazon RDS に Oracle Database を移行検討する場合、基盤となるデータベースメカニズムは、AWS 上で実行されている場合でも、vSphere 環境と同じであることを忘れないでください。データベースがどのように動作しているかを正確に把握する必要があります。

稼働中の Oracle Database の Automatic Workload Repository (AWR) または Statspack レポートを生成すると、次の基準に基づいてインスタンスのサイズの決定に役立てる事ができます。

DB time と Top 5 待機イベント
vCPU (DB time)
メモリ使用量、キャッシュヒット率
I/O 帯域使用量、IOPS

コストとパフォーマンスを最適化するには、サーバーに搭載されているコアや RAM ではなく、実ワークロードで利用している CPU コア数とメモリ量を確認することが不可欠です。AWS では、様々なユースケースに最適化されたインスタンスタイプを提供しており、上記のサイジング結果に基づいて、最適なインスタンスタイプとストレージを選択してください。

EC2 上に Oracle Database の移行を計画している場合、1) 既存のライセンスに適合し、2) Amazon Elastic Block Store (Amazon EBS) 最適化インスタンスタイプがサポートされ、3) 大容量のメモリを搭載している、最適なインスタンスタイプを選択してください。

可用性

オンプレミスの vSphere 環境で Oracle Real Application Clusters（RAC）を使用しているお客様にとって、移行を計画する際に可用性が懸念される要因となる場合があります。必要なレベルの可用性を確保するために適切な投資を行うには、必要な目標復旧時間（RTO）と目標復旧時点（RPO）のレベルを決定し、確認することが重要です。以下の表は、各データベース移行パスの RTO の例を示しています。

図 3 — 各オプションの RTO 比較

図 3 は、AWS へのデータベース移行パスのいずれかを選択することで、データ破損やデータセンター障害からの復旧時間を短縮できることを示しています。要件に合った移行パスを選択することで、コストを最適化し、希望するレベルの可用性を実現できます。

AWS へのデータベースの移行

移行するデータベースを特定したら、ディスカバリー、設計、変換、移行、運用、最適化のフェーズに進みます。

ディスカバリー: このフェーズでは、ディスカッションや Proof of Concept (PoC) を通じて、データベースの移行が可能かどうかを判断します。移行が技術的に可能か、ビジネス要件を満たしているか、費用対効果が高いかを評価する必要があります。
設計: このフェーズでは、移行方法と移行後の環境を設計します。これには、適切なデータベースエンジンの選択、ネットワークインフラストラクチャの構成、およびセキュリティ要件の決定が含まれます。
変換: SQL の抽出と書き換えを行い、単体テスト、結合テスト、総合性能試験を実施します。これにより、移行後のデータベースが期待通りに動作する事を確認し、移行前に潜在的な問題を特定して対処します。
移行: このフェーズでは、移行テスト、データ移行、および新しい環境への切り替えを行います。
運用: データベースの監視、バックアップの実行、問題が発生した場合の対処などを行い、移行したデータベースがカットオーバー後もスムーズに稼働するようにします。
最適化: キャパシティレビューやコスト最適化など、継続的な運用改善を行います。このフェーズでは、移行したデータベースが引き続き良好なパフォーマンスを発揮し、費用対効果が最適化されていることを確認します。

ディスカバリーフェーズでは、現在の環境に関する情報を収集・分析し、移行先のエンジン／プラットフォームを選択し、移行方法を決定することが第一の目標となります。対象となるデータベースの移行パスは要件によって異なりますが、下図を参考にしてください。

図 4 — データベース移行パスの選択チャート

Oracle Database から Amazon Aurora に移行すると TCO を大幅に削減できますが、データベースエンジンを変更する際には 3 つの要素を考慮してください。

まず、アーキテクチャや機能の違いにより、アプリケーションを新しいエンジンに適応させるのにコストがかかる場合があります。AWS Schema Conversion Tool は、エンジン変更の影響を評価し、変換プロセスの一部を自動化するのに役立ちます。移行プロセス、よく見られるアプリケーションの非互換性、およびそれらの回避策のステップバイステップのガイドについては、Oracle-to-Aurora migration playbook を参照してください。

次に、移行コストに影響する可能性のある、アプリケーションに統合されたデータベース固有の機能を変更するための追加コストを検討します。最後に、Amazon Aurora への移行がビジネス上の課題を解決できるかどうかを評価します。Aurora には利点がありますが、データウェアハウスや NoSQL データベースなどの代替ソリューションがニーズに適している場合もあります。

Oracle Database を Amazon RDS に移行する場合、「ノックアウト条件」とは Amazon RDS for Oracle でサポートされていないデータベース機能または設定を指し、それらが移行の成功を妨げる可能性があります。図 5 は、Amazon RDS for Oracle への移行の代表的なノックアウト条件を示しています。

図 5 — Amazon RDS for Oracle への移行のノックアウト条件

Amazon RDS Custom for Oracle を活用することで、マネージドデータベースのメリットを享受しながら、OS へのフルアクセス、Database Vault の要件、RMAN によるバックアップなど、いくつかのノックアウト条件を克服することができます。Amazon RDS Custom for Oracle は、Amazon RDS ではサポートされていない特定のカスタム設定や機能を使用できるため、移行プロセスがよりスムーズになり、いくつかのノックアウト条件を管理しやすくなります。

Amazon RDS Custom for Oracle で解決できないノックアウト条件がある場合は、Amazon EC2 または VMware Cloud on AWS への移行を検討してください。

データ移行のアプローチ

移行のターゲット環境を特定したら、次のアクションは、現在の本番環境の Oracle Database からデータを移行する方法を決定することです。AWS では、このプロセスを簡素化するためのさまざまなサービスと機能を提供しています。その中には、データベースとアナリティクスのワークロードを最小限のダウンタイムで AWS に安全に移行できる AWS Database Migration Service (AWS DMS) が含まれます。

データベースエンジンが移行元と移行先で変わらない場合、ある程度のダウンタイムが許容できると仮定すると、Oracle Data Pump などのネイティブツールを使用する方が、よりシンプルなオプションであることに注意してください。このアプローチにより、複雑なデータ変換プロセスを必要とせずに、効率的で信頼性の高い方法でデータを転送できます。

どの方法を選択した場合でも、転送されるデータの量と移行中に許容されるダウンタイムを考慮して、アプリケーションに最も適したアプローチを特定することが重要です。技術的なアドバイス、移行サポート、資金援助を通じて AWS への移行を支援するために設計された独自のプログラムであるDatabase Freedom プログラムを利用することができます。

AWS は、Database Freedom パートナー、AWS プロフェッショナルサービス、 Amazon Database Migration Accelerator のネットワークを通じて、アプリケーションの評価、移行パスの推奨、および移行の実行を支援します。

まとめ

本稿では、オンプレミスの vSphere 環境から AWS への Oracle Databaseの移行パスを詳しく解説いたしました。AWS ではデータベース移行のさまざまな選択肢を提供しており、要件に基づいて最適なオプションを選択できます。

VMware Cloud on AWS では、ネイティブ AWS サービスと広帯域、低レイテンシーの接続が可能なため、SDDC 上の仮想マシンを AWS マネージドのデータベースサービスにシームレスに接続できます。

Amazon Aurora への移行は、Oracle Database に関連するライセンスコストを削減するのに役立ちます。一方、Amazon RDS for Oracle への移行は、アプリケーションの変更を最小限に抑えながら、クラウドへの迅速な移行を可能にします。どちらのマネージドデータベースサービスでも、時間がかかり差別化に繋がらない管理タスクから解放されます。

最後に、データベースを AWS に移行する主な利点の 1 つは、上記のいずれかのオプションへの移行が完了すると、AWS が提供するネイティブな分析や機械学習サービスを利用して、データを活用し、ビジネスにさらなる価値をもたらすことができることです。

VMware Cloud on AWS のデータウェアハウスとビジネスインテリジェンスについては、こちらの AWS ブログ記事を参照ください。Amazon Redshift と Amazon QuickSight を使用して VMware Cloud on AWS で実行されているデータベースからインサイトを引き出す方法を順を追って説明しています。

さらに詳しくお知りになりたい方は、以下の追加リソースを確認することをお勧めします。

翻訳は Partner SA 豊田が担当しました。原文はこちらです。

Amazon Web Services ブログ