コロナ禍に伴うテレワーク導入やDX推進の取り組みが拡がるなか、オンプレミスからクラウドへのシステム移行が加速している。データベースにおいても例外ではなく、マネージドサービスとして提供されるDBaaS（Database as a Service）市場の急成長もあり両者の市場規模は拮抗しており、もはやクラウドがオンプレミスを上回るのは時間の問題とも言われている。そこで本コラムでは、国内外で圧倒的シェアを誇るOracle Database（Oracle DB）にフォーカスし、自社に最適な移行パスの選び方や、それぞれにおいて注意すべきポイントなどについて、国内IaaS/DBaaS市場をリードする、アマゾン ウェブ サービス ジャパン合同会社の ISVパートナー本部 シニア パートナー ソリューション アーキテクト 吉田成利氏にお話を伺った。（聞き手：サイオステクノロジー株式会社 Marketing Representative 石部智則）
Oracle DatabaseのAWSへの移行パスは3つ
——本日はよろしくお願いします。早速ですが、最近弊社のお客様から「Oracle DatabaseをAWSに移行したいが、Amazon RDSとAmazon EC2でどう違ってくるのか、そもそもOracle をAWSに移行するのにどんな方法があるのか」といった質問をよくいただきます。そこで吉田さまにお聞きしたいのですが、オンプレミスで運用するOracle DBのクラウド移行について、AWSの場合どのような選択肢がありますか
吉田氏：まず、AWS移行の考え方としては、ホストのみAmazon EC2（以下EC2）に変更して既存のOracle DBを稼働させるリホスト、マネージドサービスのAmazon RDS for Oracle（以下RDS for Oracle）に移行するリプラットフォーム、データベースのエンジンも変更して、Amazon Aurora をはじめとした OSS 互換のデータベースサービスに移行するリアーキテクチャの3つがあります。よりシステム最適化が図れ、クラウド移行のメリットを享受できるリアーキテクチャですが、アプリケーション改修が必要になるなどコストや工数のハードルが高いため、まずはリホストやリプラットフォームでクラウド化したうえで、次のフェーズでリアーキテクチャに進む段階的移行が現実的だと考えています。
実際、サーバのEOLなど時間的制約があるなかでクラウド移行を検討されるケースも多く、AWSの場合、リプラットフォームが1番で、残りはリホストとリアーキテクチャが同数程度という感じです。リプラットフォームが多いのは、やはり、マネージドデータベースならではのメリットが大きいからでしょう。RDSの場合、EC2に比べ管理負荷が少なく、1クリックで迅速にスケールでき、マルチAZやリージョン間自動バックアップで高可用性を実現できるといったメリットが広く理解され、最近は金融業などかなりクリティカルなシステムを運用しているケースでも導入事例が増えています。
Oracle Databaseで考えられる3つのAWS移行パス
RDS or EC2の2択から、RDS Customを含む3択へ
——ありがとうございます。リプラットフォームがデフォルトの選択肢となりそうですね。それでもリホストが選択肢になるということは何か制限などがあるのだと思いますが、リプラットフォームにするか、リホストにするかはどのように判断すればよいでしょうか
吉田氏：AWS側でハードウェアインフラはもちろん、スケーリングやパッチ適用、高可用性やバックアップなどについてもマネージしてくれて導入企業の負担を軽減するRDSですが、DBサーバのOSにログインできない、DBの管理者アカウントを使用できない、個別パッチ適用ができないといった制限があります。ERPパッケージなどソフトウェアによっては、Oracle DBへの個別パッチ適用を求める場合がありますが、RDS for Oracleではこうしたシナリオに対応できません。このため、管理者権限でOSにログインしたい、利用するソフトウェアの関係で個別パッチ適用が必要というお客様は、EC2によるリホストを選ぶしかありませんでした。
こうした状況に対し、2021年10月に追加投入されたのがAmazon RDS Custom for Oracleです。ざっくり言うと、EC2とRDS for Oracleの中間に位置し、パッチ運用やバックアップ、高可用性についてAWSとユーザが共有して管理することで、インスタンス/OSに対するフルコントロールや、ユーザ管理のパッチ適用が可能になっています。その分責任範囲は増えますが、EC2ほどではなく、OSやDBの管理者権限を必要とするアプリケーションやパッケージソフトを利用している企業にとって新たな選択肢となります。
少しまとめると、オンプレミスのOracle DBをAWSに移行したいが、既存のOracleライセンスの有効活用もあるのでDBエンジンは変えないで…というお客様の場合、選択肢は3つということになります。そのうえで、管理負荷の低減などクラウド移行のメリットを優先するのであれば、利用するアプリケーションやパッケージソフトの要件や、要求する性能などノックアウトファクターを踏まえ、RDS for Oracle ⇒ RDS Custom for Oracle ⇒ EC2の順で検討することをお勧めします。
AWS稼働環境の選びかた（フローチャート）
EC2移行時のサイジングと可用性をどうするべきか
——RDS for Oracleがダメでも、第2・第3の選択肢が残されているということですね。では自社の要件を踏まえEC2への移行を検討する場合の注意点などあれば教えてください
吉田氏：EC2は自由度が高い分、Oracle DBの移行を検討する企業にとってのハードルは大きく2つあると思います。ひとつはサイジングです。よく、EC2移行を検討しているお客様から“パフォーマンスが低下しないようにするには（サイジングを）どうしたらいいか”相談を受けることがありますが、それに対して我々は「実ワークロードを見て適切にサイジングしましょう」とお答えしています。既存のサーバのCPUやメモリを見るのではなく、例えばOracleの場合であれば、AWR（自動ワークロードリポジトリ）やStatspackのレポートで、実際のCPU/メモリ使用率などを見て必要なI/O性能を導き出し、適正なインスタンスタイプを選ぶというのが正しいアプローチです。そのたありのノウハウやスキルに自信がないというお客様は、弊社でもサポートできる体制を組んでいますし、Oracle DBに精通していて豊富な移行実績を有するAWSパートナーも多いので、是非お気軽に相談いただければと思います。
そして、もうひとつが可用性です。確かに、Oracle RAC（Oracle Real Application Clusters）を導入しているお客様などで、可用性のレベルを落としたくないというケースはあるでしょう。だからと言って既存の構成ありきで検討することはお勧めできません。“Oracle RACの可用性レベルが難しいなら、今（オンプレミス）のままでいいや…”という本末転倒な結論になりかねないからです。“実際のところRTO/RPOはどの程度許容されるのか（逆に、本当に必要なのはどのレベルか）”を、アプリケーションやパッケージソフトウェアを利用するビジネスサイドとしっかり再確認することで、AWS移行に踏み切れるかも知れません。
ちなみに、下図は複数のイベントシナリオで、オンプレミス（Oracle RAC）とAWS（EC2シングルおよびRDS for Oracle＋マルチAZ構成）のRTOを比較したものですが、実際のところ、オンブレミスのOracle RACがAWSよりもすぐれているのは「サーバ（インスタンス）障害」のシナリオのみで、「単一ディスク障害」では3つとも同レベル、「複数ディスク障害によるデータ破損」や「データセンター規模の障害」に至ってはAWSの2つの方が短時間で済みます。要するに、サーバ（インスタンス）障害で1～2分のRTOが許容できるのであれば、AWSに移行した方がBCP強化につながるということです。特に注目していただきたいのは、マルチAZ構成のRDS for Oracleには若干劣るものの、Oracle on EC2においても、かなり優秀なRTOが期待できる点です。インスタンス障害ではAmazon EBS をアタッチしたインスタンスを新規作成することで数分程度、「複数ディスク障害によるデータ破損」や「データセンター規模の障害」ではEBS スナップショットからのリカバリにより数分から数時間程度での復旧が可能です。“数分から数時間”という幅のあるRTOですが、Enterprise Editionの場合は、データレプリケーション機能を提供するOracle Data Guardで実現できますし、Standard EditionをEC2に移行する場合は、サイオステクノロジーの LifeKeeper / DataKeeper など、サードパーティ製品を導入し、異なるAZのEC2間でデータレプリケーション＆自動フェイルオーバー環境を構築することで、同等の高可用性を実現できます。
3つの移行パスのRTO比較
※ディスク障害（複数のディスクで冗⻑化されている環境で、1本のディスクが物理的に完全に壊れた状況）、インスタンス障害（CPU故障などで、1台のコンピュータが物理的に完全に壊れた状況）、データ破損（複数のディスクで冗⻑化されている環境で、複数のディスクが同時に物理的に完全に壊れ、そのストレージから回復不能なデータが発⽣した状況）、データセンター障害（電⼒、空調、ネットワーク障害などで、データセンター規模で障害が発⽣した場合）
※⼀般的な傾向であり約束されたものではありません
※Oracle RAC に関する値は、Oracle Corporation が発⾏する『Oracle MAA リファレンス・アーキテクチャ』ホワイトペーパー（https://www.oracle.com/assets/maa-reference-architectures-2244929-ja.pdf）を参照（AWS調べ）
まとめ：DXを推進するためにも、今こそクラウド移行を
今回のインタビューで重要なポイントは、ERPパッケージなどソフトウェアの要件でRDS for Oracleへの移行が難しい場合も、RDS Custom for OracleやEC2上で運用するという選択肢があり、クラウドへの移行を諦める必要はないということだ。オンプレミスのOracle DBをクラウドに移行すれば、インフラの運用・管理から解放され、その分のリソースをほかの業務に振り向けられる。企業の間でDXの取り組みが加速するなか、限られたリソースをAI導入やデータ活用など“攻めの施策”に投入できるメリットは大きい。是非、柔軟かつ大胆な発想でAWSへのクラウド移行を検討いただきたい。なお、弊社製品「LifeKeeper」「Datakeeper」を用いたOracle on EC2のHAクラスタ構成についてはLifeKeeperのプロダクトサイトも是非ご参考にしてください。
