あなたに最適なOracle Database on AWSは？RDS or EC2徹底比較（後編）

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

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

データベースはメモリが必要となることが多いため、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を実施することをお勧めします。

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かの違いが今まで以上に大きいです。

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

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

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

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

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

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

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

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

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

前編の冒頭でもお伝えしたとおり、EC2と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で利用するには、本記事でご紹介した情報の他にも留意いただきたい点があります。ご検討の状況に合わせて以下の記事もお役立てください。

Oracle Databaseライセンスの定義とルールを正しく理解する～クラウド編～
本記事中でもご紹介しているとおりOracle DatabaseをAWSで利用する際には、ライセンスの検討も欠かせません。クラウド移行時のライセンスに関する注意点や考え方をまとめたこちらの記事もあわせてご確認ください。
 

Oracle DB 12cのサポート終了でRDSが自動アップグレード！取るべき対応のまとめ
Oracle Database 12c R2のサポート終了に伴い、Amazon RDS for Oracleも影響を受けます。本記事では、Amazon RDSならではの注意点など管理者が取るべき対応についてまとめまています。
 

Oracle Cloudを使いこなそう
既にAWSを全社システム基盤として使われている企業も多いかと思いますが、Oracle Databaseの基盤としては、既存のナレッジがそのまま使えることやOracleライセンスの優遇措置があるなど、Oracle Cloudにも多くのメリットがあります。AWS以外の選択肢も検討中の方には本記事もオススメです。
 

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