オンプレミス環境にあるOracle DatabaseをAWSへ移行する場合、Amazon Relational Database Service(以下RDS)かAmazon Elastic Compute Cloud(以下EC2)かの2択でお悩みになっているお客様が非常に多くいらっしゃいます。本記事では、移行を検討されているお客様から実際にご相談いただいた移行要件を例に、RDS、EC2で採用可能なアプローチや、採用する際の注意点について前編・後編に分けてお伝えします。
前編となる今回は、実際にご相談があった移行要件と、その一つである可用性要件についてご紹介します。
※後編では、性能/サイジング要件、運用要件、そして結論としてどちらを採用するかについてのご紹介します。
RDSとEC2、どちらか一方が優れているというわけではない
AWSでOracle Databaseを利用したい場合、以下の二つの方法があります。
(1)Amazon RDS for Oracle(PaaS)
(2)Oracle Database on Amazon EC2(IaaS)
Amazon RDS for Oracleはマネージドサービスとして提供されており、数クリックでセットアップ、運用、スケーリングなどが実行されるため、構築までの期間を短縮したり、運用コストを削減できる点が最大の特徴となっています。Oracle Database以外のデータベース・エンジンも複数提供されています。また、Amazon RDS for Oracleには「Licence Included」(ライセンス込み。Oracle DatabaseはAWS側が提供)および「Bring–Your–Own–License(BYOL)」(顧客企業がライセンスを持ち込み)という二つのライセンスモデルがあります。
一方、Oracle Database on Amazon EC2は、Amazon EC2で提供されているコンピュートサービス上に、ユーザーがOracle Databaseを導入して利用する形になります。自社のオンプレミス環境と同様に、ユーザー自身がインスタンス、ストレージ、スケーラビリティ、セキュリティなどを設定、管理、チューニング可能なため、操作性という意味でやりやすく、PaaSでは実現が難しい自由度の高さが大きな特徴です。
今回の記事のテーマでもある、「Oracle Databaseをオンプレミス環境からAWSへ移行する際、RDSとEC2のどちらがよいのか?」というお客様からのご質問への回答としては、方法には上記の二つがあるということだけで、どちらか一方が優れているとか劣るということではありません。どちらがよいかを決める要素について、以降で見ていきましょう。
ご相談実績のあるシステム要件を例に、二つを比較して解説
ここからは、お客様から実際にご相談のあった移行要件を例に、RDS採用時とEC2採用時の違いや選定ポイントをご紹介していきます。
移行要件の例
基本情報および現行のデータベース構成などは下記を参照してください。
このお客様のように、現在はオンプレミス環境でOracle Databaseを稼働中で、今後クラウド化を検討されているお客様は増えてきています。お使いのOracle Databaseのエディションについては、Enterprise Edition(EE)ライセンスの方が実現できることが多く、アシストからご提案する機会も多いのですが、コスト面を考慮しStandard Edition2(SE2)ライセンスを利用中で、リプレース時にはコストを極力抑制したいというご要望はよくお伺いします。
今回は、現状オンプレミス上で実現できている「可用性の担保」「性能要件の維持」「運用負荷の削減」の3点に焦点をあてて見ていきましょう。
可用性の担保
現在はクラスタウェアを使ったアクティブスタンバイ型のHA構成を採用し、障害発生時に切り替わるようにしています。可用性については、クラウド移行後も同レベルを維持したいというご要望です。
性能要件の維持
オンプレミス環境のスペックとして、CPUは8コアサーバ、メモリは128GB、CPU自体の使用率は40%程度と、全体的にCPUに余裕がありメモリが多いという状況です。
運用負荷の軽減
現在は統合運用管理ツール「JP1」で監視を行い、バックアップはOracleのRecovery Manager(RMAN)で対応しています。また、昨今の災害状況などを考慮して、今後は災害対策(DR)を検討したいというご要望です。
このような要件を踏まえ、「可用性」「性能」「運用」の3点について、Amazon EC2、Amazon RDSを採用した場合のポイントや注意点を見ていきましょう。
1. 可用性要件
一般的に、データベースサーバの可用性は、クラウド、オンプレという環境に関係なく、一番重要なポイントになります。
【移行要件】
・Oracle Database:コスト面も加味しStandard Edition2利用中
・可用性要件:現在はHA構成であるため、同レベルでの維持が必要
・DR要件:将来的には災害対策(DR)も検討したい
上記の要件について、AWSリージョン内、リージョン間の2点で解説します。
AWSリージョン内で採用可能な構成
AWS のリージョンに閉じた中で採用できる構成には以下の三つがあります。
| サービス |
ソリューション |
Oracle Database
ライセンス |
構成 |
| Amazon RDS |
RDSマルチAZ構成 |
SE2/EE |
マネージドサービスのアクティブスタンバイ構成 |
| Amazon EC2 |
DataGuard |
EE |
Oracle Database機能を利用したアクティブスタンバイ構成 |
|
サードパーティ製品を利用したHA構成
|
SE2/EE |
サードパーティ製品を利用したアクティブスタンバイ型のHA構成 |
Amazon RDSの場合は、マネージドサービスのため簡単に利用が可能であり、Amazon EC2の場合はユーザー側で構築する必要があります。また、共通する注意事項としては2点あります。
1. RDS、EC2ともにOracle Real Application Clusters(Oracle RAC)構成は利用できない
2. オンプレミスとAWSではOracle Databaseのライセンス数のカウント方法に違いがあるため、
事前に必要ライセンス数の確認が必要
Amazon RDS ー RDSマルチAZ構成
マネージドサービスとして提供されるため、1クリックで簡単に構成を構築できる点が大きなメリットです。EE、SE2ライセンスともに利用可能です。
先ほどオンプレミスとはライセンス数のカウント方法に違いがあるとお伝えしましたが、BYOL(顧客企業持ち込み型)の場合は、アクティブスタンバイ構成のスタンバイ側にもライセンスが必要になる点に注意が必要です。また、SE2ライセンスの場合は、最大8vCPUまでという制約があるので、今回の想定要件では注意が必要です。
Amazon EC2 ー DataGuard
Oracle Databaseで用意されている機能を利用できるアクティブスタンバイ構成です。DataGuardに関してはオンプレミス環境での採用実績が豊富にあり安心して利用できますが、EEライセンスが必要です。
Amazon EC2 ー サードパーティ製品を利用したHA構成
サードパーティ製品を利用したアクティブスタンバイ型のHA構成です。オンプレミス環境でも利用ケースが多く、EE、SE2ライセンスともに利用可能ということもあり、AWSでも採用実績が多い選択肢です。今回の想定に最も近いパターンとなります。
ただしこの構成の場合、ストレージを共有できない点に注意が必要です。現行でストレージ共有型のアクティブスタンバイ構成なら、同じ構成にできないということになるため、構成ではなく可用性要件をどこまで満たせるかを検討する必要があります。
AWSリージョン間で採用可能な構成(DR対策)
DR対策となる、リージョン間構成(リージョンをまたいだ場合の構成)には以下の三つの選択肢があります。
| サービス |
ソリューション |
Oracle Database
ライセンス |
構成 |
| Amazon RDS |
フィジカルスタンバイDB |
EE |
マネージドサービスのアクティブスタンバイ構成 |
| Amazon EC2 |
DataGuard |
EE |
Oracle Database機能を利用したアクティブスタンバイ構成 |
| サードパーティ製品でのHA構成 |
SE2/EE |
サードパーティ製品を利用したアクティブスタンバイ型のHA構成 |
Amazon RDS
マネージドサービスのため簡単に構築可能です。リージョン内でサポートされていたマルチAZ構成とは異なり、内部的にはOracle DataGuardの機能を利用したアクティブスタンバイ構成となっているため、EEライセンスの場合のみ利用可能です。
また、RDSでEEライセンスを利用する場合、BYOL(顧客企業持ち込み型)が必須となり、Licence Included(AWSがOracle Databaseを用意)ではEEライセンスが利用できない点にも注意が必要です。つまり、ライセンス自体が必要になるため、現在SE2ライセンスを利用されている場合はコスト面での考慮も必要になります。以下の記事も合わせてご確認ください。
AWS関連のお問い合わせはこちら
Amazon EC2 ー Oracle DataGuard
Oracle Databaseとして用意されている機能を利用したアクティブスタンバイ型の構成です。EEライセンスの場合のみ利用可能であり、オンプレミスでの採用実績も豊富であり、安心して利用できます。アシストのお客様ではこの採用パターンが多いです。
Amazon EC2 ー サードパーティ製品でのHA構成
サードパーティ製品を利用したアクティブスタンバイ型のHA構成です。ストレージ共有はできませんが、SE2ライセンスでも利用できるため、今回の想定要件にも適用可能です。
可用性構成は何をポイントに決めるか
お客様からも「結局、可用性構成はどのようなポイントで決めればよいのか」というご質問をいただきます。可用性構成を決めるポイントには以下の三つがあります。
1. 想定する障害レベル
2. システムで求められる目標復旧時点(RPO)*
*該当のシステムにおいて障害発生時にどこまでのデータを復旧したいかの指標
3. システムで求められる目標復旧時間(RTO)**
**該当のシステムにおいて障害発生から復旧までにどのぐらいの時間が許容されるかの指標
障害には、大規模な災害やAWSのAZ(アベイラビリティーゾーン)障害、OSの障害、EC2のデータベースであればインスタンス単体の障害など、様々なレベルが想定されます。そのため、どのレベルの障害を考慮した可用性構成にするかが一番大きなポイントになります。
また、障害発生時のRPOやRTOがある場合は、障害レベルに応じてそれぞれ分けて検討する必要があります。クラウド環境では方法が異なるだけで、可用性構成のポイントについては、基本的にオンプレミス、クラウド環境どちらも場合も同じです。
移行要件を元にした可用性検討結果
【移行要件】
・Oracle Database:コスト面も加味しStandard Edition2利用中
・可用性要件:現在はHA構成であるため、同レベルでの維持が必要
・DR要件:将来的には災害対策(DR)も検討したい
上記の要件について、各構成を検討した結果、次のような結論になります。
まず、HA構成と同レベルの可用性要件に対しては、RDS、EC2いずれも満たすことができます。RAC構成の場合はAWSでは対応できません。
また、リージョン内構成では構築の手間やスピード感という点でRDS採用に分がある一方で、リージョンをまたぐDRを検討する上で、RDSではEEライセンスが必要となる点が大きな障壁となります。
EC2を採用した場合、構築の手軽さではRDSに劣りますが、災害対策という将来的な要件にも対応可能なため、柔軟な検討を行えます。 ここは、DRについてもう少し実施を含め詳細に検討しないと、結論が出しにくいところです。
この記事で知りたい情報は得られましたか?
Oracle DatabaseをAWSで利用するには、本記事でご紹介した情報の他にも留意いただきたい点があります。ご検討の状況に合わせて以下の記事もお役立てください。
Oracle Databaseに関するお問い合わせはこちら
アマゾン ウェブ サービス(AWS)に関するお問い合わせ
執筆者のご紹介
本記事をご覧いただいている方へのご案内
最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。