Database Support Blog

  • Oracle Database
  • AWS
2022.09.13

あなたに最適なOracle Database on AWSは?RDS or EC2徹底比較(後編)

あなたに最適なOracle Database on AWSは? RDS or EC2徹底比較


オンプレミス環境にあるOracle DatabaseをAWSへ移行する場合、Amazon Relational Database Service(以下RDS)かAmazon Elastic Compute Cloud(以下EC2)かの2択でお悩みになっているお客様が非常に多くいらっしゃいます。本記事では、移行を検討されているお客様から実際にご相談いただいた移行要件を例に、RDS、EC2で採用可能なアプローチや、採用する際の注意点についてお伝えします。

前編では、可用性要件までを見てきましたが、後編では性能/サイジング要件、運用要件について、そして最終的な見解について解説します。


2. 性能/サイジング要件


可用性要件に続き、性能/サイジングの観点で検討します。

【移行要件】
・Oracle Database:コスト面を加味しStandard Edition2利用中
・性能要件:CPU:8コア(CPU利用率約40%)/メモリ128GB

現状のCPUが8コア(実質16vCPU)、メモリが128GBで、CPUよりもメモリが必要なシステムではないかと推測できます。ただし、CPU使用率は40%程度なので、SE2利用時の制約でもあるインスタンスあたり8vCPUでも机上の計算では問題なさそうにも思えます。


AWSにおけるインスタンスタイプの考え方


AWSでは、Amazon EC2およびAmazon RDSであらかじめ提供されているインスタンスタイプからスペックを決める必要があります。



Amazon RDSでは、「汎用(一般用途)」、「メモリ最適化」の2種類、Amazon EC2では5種類のインスタンスタイプが提供されています。「メモリ最適化」に関しては、基本的に1vCPUあたり8GBのメモリが用意されています。

データベースはメモリが必要となることが多いため、RDS、EC2ともに「汎用」または「メモリ最適化」が採用されるケースが多いです。


【コラム】コア数を抑えてメモリのみ増強することは可能か


例えば「メモリ最適化」を選択した場合、1vCPUあたり8GBが基本となっていますが、コア数を抑えメモリだけ増強することはできるのかといったご質問もよくいただきます。回答としてはRDSとEC2のどちらも可能です。ただし、それぞれで注意点があります。

Amazon EC2に関しては「CPUオプションの最適化機能を利用することで、インスタンス上で有効化するコア数を抑えメモリを確保できる」とAmazon社のマニュアルに記載があります。一方、Oracle Database側には「Oracle Databaseを利用する場合は該当のインスタンスに搭載されている仮想CPUの最大数をベースとしたライセンス数が必要となる」というルールがあるため、本機能が用意されているのも関わらず、有効に利用するということは難しいのが現状です。

Amazon RDSで「メモリ最適化」を選択した場合は、コア数を抑えメモリだけを増強できるインスタンスタイプが用意されています。今回の要件に適合可能ですが、利用料が変わる点に注意が必要です。

例えば、1番上はコア数8vCPUでメモリが64GB、利用料は1時間あたり約1.1米ドル、2番目は8vCPUでメモリが128GB、利用料は2.2米ドル、一番下は16vCPUで128GB、コア数に大きな差がありますが、同じ2.2米ドルという料金体系です。RDSでは、あくまでもライセンスの料金を抑えるという目的でこれらのメモリタイプが提供されています。クラウドでの課金はコア数が基準ですが、メモリ基準もサービスとして提供されるRDSの方がEC2に比べ柔軟性があります。

コア数、メモリ以外に検討すべき項目


コア数やメモリ以外のスペックとして、ディスク容量、IOPSスペック、インスタンスのネットワーク帯域も実は大きなポイントです。

例えば、読み書きが遅い場合の原因はディスクのIOPSが原因であることや、インスタンスのネットワーク帯域の上限に引っかかっているというケースもあります。後から見直すことも可能ですが、事前に防ぐという意味合いで、PoCの実施が重要なポイントになります。


移行要件を元にした性能/サイジング検討結果


【移行要件】
・Oracle Database:コスト面を加味しStandard Edition2利用中
・性能要件:CPU:8コア(CPU利用率約40%)/メモリ128GB

性能については、RDS(2種類)、EC2(5種類)いずれの場合も、用意されたインスタンスタイプの中から選択する必要があります。

現在の性能要件は、8コア(16vCPU)ですがCPU使用率が40%なので、机上の計算では、8vCPUでも要件を満たせるのでは、と考えることができます。しかし、実際に性能要件を満たせるかどうかは、ストレージやネットワーク性能も関係してくるため、PoCの実施が重要です。また、CPUを抑えメモリを増やす方法については、EC2では実質不可能ですが、RDSの場合は必要なライセンス数を抑えるという要件であれば対応可能です。

性能を検討する場合は、まずメモリ状況などを確認し、是非PoCを実施することをお勧めします。


3. 運用要件


最後に運用の観点で検討します。

【移行要件】
・監視要件 JP1で各種監視を実施。データベース以外の監視も行っている。
・バックアップ/DR要件 RMANで対応中。将来的にはDRも検討したい。

上記の運用要件については以下の3点が気になります。

1. RDSでJP1を利用したい場合、そもそもエージェントが必要なのか、また、エージェントに入れられるのか
2. 運用負荷の軽減については、JP1をそのまま利用した方が楽だと思うが、もっと楽になる方法があるのか
3. RMANでオンラインバックアップを実施しており障害が発生した場合でも直前までは戻せる状態にある。
  このレベルは維持できるのか

これらを念頭に順に解説します。


AWSでの監視の考え方


AWSでは基本的に、以下の二つのツールを利用した監視が可能です。

1. Amazon CloudWatch   AWSのサービス全般の監視が可能
2. Performance Insights(PIs) RDSに特化した監視が可能

Amazon CloudWatchはAWSのサービス全般の監視、Performance Insights(PIs)はRDSに特化した監視サービスとして提供されています。PIsはSQLの実行状況が確認できるだけでなく、その他様々な情報が参照できるツールです。

Amazon CloudWatchの場合、AWSサービス全般の監視はできるのですが、Amazon EC2上に構築したアプリケーションの監視はできません。アプリケーションを監視したい場合は作り込みが必要で工数が膨大にかかります。Amazon EC2ではエージェントを導入できるため、EMCCやZabbix、JP1といったツールを利用した監視を検討した方がよいと考えます。

Amazon RDSの場合は、OSレイヤーにアクセスできないため任意のエージェントは導入できず、既存と同じ仕組み、今回の要件ではJP1での監視は難しいということになります。

そのためAmazon CloudWatchやPerformance Insightsで対応可能な範囲だけを監視対象とするか、別途エージェントレスで監視を行えるソリューションを検討する、といったことがポイントになります。 監視についてはEC2かRDSかの違いが今まで以上に大きいです。


AWSでのバックアップの考え方


RDS、EC2のいずれのサービスでもバックアップの仕組みが提供されています。

サービス 仕組み 遠隔対応
Amazon EC2 EC2/EBSスナップショット形式
Amazon RDS データベーススナップショット形式

EC2の場合は、EC2全体またはEC2向けストレージであるElastic Block Store(EBS)のスナップショットを取得できます。ただし、EC2の場合、クラッシュの整合性は担保されているが、アプリケーションの整合性は担保されていないため、正常にリストアできない可能性がある点に注意が必要です。もしデータベースレイヤーに対して完全なバックアップを取得したいのであれば、これまで通りRMANまたはdatapumpを使用したバックアップが必要です。整合性が担保されない状態でスナップショットを取得するというのもバックアップの観点からは怖いので、オンプレミス同様、RMANでこれまで通りバックアップすることをお勧めします。

一方、RDSではデータベースに対するスナップショット取得機能があり、こちらを使うことによって非常に簡単に取得できます。ただしRPOが最大5分で、5分ごとにトランザクションログをストレージであるSimple Storage Service(S3)に取得するという仕組みが導入されるため、そこが注意点になります。 RPOが最大5分になる点については、お客様にお伺いしても許容範囲、仕様として受け入れていただくケースが多いです。


監視とバックアップ以外に監視すべき項目



監視とバックアップ以外に、検討すべき運用項目として、以下に記載したいわゆるスケールアップについての方針やセキュリティ対策が挙げられます。

1. サーバのスケーリング(コア性能)
2. サーバのスケーリング(ストレージ容量)
3. セキュリティ対策


サーバのスケーリング(コア性能)

EC2、RDSでBYOL(ライセンス持ち込み型)の場合、サーバのスケーリングを検討する以前に、Oracle Databaseの保有ライセンス数を確認しておく必要があります。RDSでBYOL(ライセンス持ち込み型)の場合は、インスタンスの停止が必要ですが、スケーリングについてはかなり柔軟に対応可能(ただし課金については注意が必要)で、リードレプリカ*という選択肢もあります。

*リードレプリカ:
更新用データベース(マスター)からレプリケーションされた参照専用のデータベース。 アプリケーション側で更新用データベースと参照用データベースを使い分けることにより負荷分散を実現。


サーバのスケーリング(ストレージ容量)

RDSの場合、ストレージの自動スケーリング機能が提供されているため、必要に応じて採用を検討します。


セキュリティ対策

EC2/EBSとRDSどちらの場合も暗号化が可能です。ただし設定可能なのは作成時だけなので、後から対応する場合は、サーバやインスタンスの作り直しが必要になる点に注意が必要です。

作り直しとなると影響度が大きいため、最初から設定してしまうことをお勧めします。


移行要件を元にした運用検討結果


【移行要件】
・監視要件 JP1で各種監視を実施。データベース以外の監視も行っている。
・バックアップ/DR要件 RMANで対応中。将来的にはDRも検討したい。

上記の移行要件について、監視、バックアップ、その他について検討しました。

監視については、EC2の場合、これまで通りの運用が可能です。一方、RDSの場合は、エージェントの導入ができないため、JP1を利用するのではなく、他の選択肢を検討する必要があります。

バックアップについては、EC2の場合、これまで通りの運用方法を採用することになります。また、RPOが5分である点を許容できるのであればRDS採用に大きなメリットがあります。

監視やバックアップ以外の運用要件として、スケーリング方法やセキュリティ対策がありますが、これらもAWSの仕組みを生かした検討が必要です。

運用要件についてはRDSにメリットがありそうですが、どちらがよいのかは判断が難しいところです。


移行要件に対する総合判断


前編の冒頭でもお伝えしたとおり、EC2とRDSのどちらか一方が優れている、劣っているという話ではありません。どちらが最適なのかはお客様の要件に依存するため、要件を一つ一つ確認していく必要があります。また、検討にあたっては、「何に重点をおくのか?」「要件の優先度は何か」が大きなポイントになります。

本移行要件において、可用性、性能/サイジング、運用の三つの観点で検討結果をまとめると以下になります。

可用性 EC2
性能/サイジング RDS
運用 強いて言うならRDS

まず、可用性については、要件の中にDRがあります。Oracle DatabaseのエディションがSE2であることから、実現性と容易性の2点からEC2になります。コストをかけることが可能であればEEを利用したRDSも検討可能です。最終的な結論は、お客様がDR要件にどれぐらい強い想いがあるかについてのヒアリングが必須になります。
(参考)Oracle Databaseライセンスの定義とルールを正しく理解する ~第4回:クラウド編~

性能面については、メモリ要件を満たすための選択肢がRDSのみになります。ただし、PoCの実施により、CPUのサイジングの見直しと併せてメモリ要件も見直し可能であれば、EC2の採用を視野に入れることもできます。

お客様の要件にある「運用負荷の軽減」を考慮すると、せっかくクラウドにいくのであればクラウドのサービスで監視できるRDSの採用メリットは大きいと思います。ただし、既存の運用ノウハウを生かしたい場合は、EC2になります。

全体的には、可用性のDR要件がポイントになりそうなので、ここを深掘りし何か妥協できる点があればRDSでいきましょうと堂々と言えるのではないかと思いました。

結論としては、AWS上で最適なOracle Database環境を構築するためには、移行要件や要件の優先度を正しく押さえることが重要だということになります。

アシストではOracle DatabaseのAWSへの移行実績が豊富にあります。お客様の要件に応じてご提案させていただきますので、ぜひご相談ください。

▶ AWS関連のお問い合わせはこちら

この記事で知りたい情報は得られましたか?

Oracle DatabaseをAWSで利用するには、本記事でご紹介した情報の他にも留意いただきたい点があります。ご検討の状況に合わせて以下の記事もお役立てください。




Oracle Databaseに関するお問い合わせはこちら




アマゾン ウェブ サービス(AWS)に関するお問い合わせ





執筆者のご紹介

アシスト 新良 芳郎

新良 芳郎
2010年8月入社。
一貫してデータベース系部署に所属。フィールドSEを経て現在プリセールス部門でデータベース系製品のプリセールス活動を行っている。
趣味は愛猫のご機嫌取り。...show more

アシスト 原田 拓朗

原田 拓朗
2015年入社。 クラウド技術者としてOracle CloudやAWSの製品紹介、技術支援及び新機能検証を担当。 最新情報の収集を得意とし、社内勉強会や社外セミナー登壇等で収集した情報を幅広く発信している。...show more

本記事をご覧いただいている方へのご案内

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。


■本記事の内容について
 本記事に示した定義及び条件は変更される場合があります。あらかじめご了承ください。

■商標に関して
 ・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
 ・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
  文中の社名、商品名等は各社の商標または登録商標である場合があります。

関連している記事

  • Oracle Database
2024.04.08

【Oracle Database】FAQで安定運用に貢献!サポートセンターのナレッジ公開の取り組み

アシストオラクルサポートセンターが公開しているFAQは、仕様に関するQAやエラー発生時の対処方法などはもちろん、不具合情報や障害発生時の情報取得方法といった安定運用に役立つ内容も扱っています。そのFAQをどのように作成しているのか、サポートセンターの取り組みをご紹介します。

  • AWS
2024.03.29

AWS Jr. Championsに選出されて良かったことを振り返ります!

~しまえりの雲を向いて歩こう!シリーズ:第7回目~ 今回のブログ記事ではAWS Jr. Championsとしての一年間の活動を通して「AWS Jr. Championsに選ばれて良かった!」と特に感じたことをご紹介したいと思います。

  • AWS
2024.03.19

今日から使える!AWS re:Invent 2023注目アップデート AWS re:Invent 2023参加レポート#4

今回のAWS re:Inventでも数々の新製品や機能、サービスの発表があり、クラウド技術の進化とその可能性を改めて感じることができました。本記事では「今日から使える!」をテーマに注目すべきアップデートについてお伝えしたいと思います。

ページの先頭へ戻る