AWS移行 - OracleのAWS移行時の検討ポイント

1. はじめに

オンプレミスからクラウドへのシステム移行を計画する場合、「データベースの移行」は重要な検討項目の１つになります。この記事では、データベースをAWSへ移行する際に検討すべき以下のポイントについて、主にOracle Databaseの移行を想定して記載してみます。

• 検討ポイント1：DBMSの選定
• 検討ポイント2：マネージド型サービスの利用可否
• 検討ポイント3：サイジング
• 検討ポイント4：コスト

検討項目は移行対象システムによって様々なので、すべてを網羅できているわけではないですが、検討の参考にしていただければと思います。

2. AWSでのRDBの利用

検討ポイントの前に、AWSでRDBを利用する場合に利用可能な構成をまとめます。

(1) EC2にDBMSを導入する構成（IaaS型）

仮想サーバサービスのEC2（OSはWindows, Linuxから選択）に、利用者がライセンス調達したDBMSを導入して利用します。自由度は高く、オンプレミスとほぼ同等の構成を実現することが可能ですが、OSやDBMSの設計・構築や管理・運用は利用者自身が実施する必要があります。

(2) RDS（マネージド型のDBサービス）を利用する構成

RDSは、AWSが提供するOSとDBMSが導入済みのDBサーバを利用できるサービスです。RDBMSとして商用DB（Oracle Database, SQL Server）、OSS DB（MySQL, PostgreSQL, MariaDB）、およびクラウドに最適化されたAurora（MySQL互換, PostgreSQL互換）を利用することができます。商用DBのいくつかのエディションでは、AWSが提供するライセンスを使用することも可能です。

RDSでは、OSの管理やDBMSの製品管理（パッチ適用など）をAWSが実施し、利用者はDBのスキーマ以上のレイヤを管理・運用します。高可用化構成やバックアップ/リストアなどで、AWS提供の機能を利用することで容易に構成することができます。

ただし、RDSではOSへのアクセス不可や非サポートのDBMS機能があるなど、様々な制限があります。詳細はRDSのマニュアルを確認してください。

(3) サードパーティが提供するDBMSサービスを利用する構成（PaaS型）

サードパーティがAWS内に構築したDBサーバをPaaS型で提供するサービスを利用します。例えば（手前味噌ですが）日立製作所のHiRDB Cloud Serviceのように、RDSには含まれないDBMSをPaaS型で利用することも可能です。

3. AWSへのDB移行での検討ポイント

以下では、データベースをAWSへ移行する際の検討ポイントを挙げてみます。

検討ポイント1：DBMSの選定

クラウドへのDB移行でも、DBMSは変更せず、同一DBMSの最新バージョンへのバージョンアップのみ実施することがほとんどと思います。ただ、長期的なコスト低減を目的に商用DBからOSS DBへ変更するなど、DBMSの変更を希望するケースもあります。

DBMSを変更する場合、アプリケーションの改修が必要になります。開発・テストフェーズにおいて、必要な機能がなかったり、SQLが想定通りに動作しないなどのトラブルが発生するリスクもありますので、計画時に十分な検討を行う必要があります。

例として、Oracle Database / MySQL / PostgreSQLの主な機能差異について、下の表にまとめてみました。これら以外にも、組み込み関数などDBMS間には多くの差異がありますので、使用する機能については各DBMSのマニュアルをご確認ください。また、Oracle DatabaseからPostgreSQLへの移行について、よく発生する課題とその対応方法がAWSのブログ記事にまとめられており、こちらも参考になります。

比較項目	Oracle Database	MySQL (InnoDB)	PostgreSQL
アーキテクチャ（*1）	更新型	更新型	追記型
チェック制約	あり	あり（*2）	あり
シーケンス	あり	なし（自動インクリメント等で代替）	あり
シノニム	あり	なし	なし
マテリアライズドビュー	あり	なし	あり
NULL/空文字の区別	区別なし	区別あり	区別あり
利用可能なJOINアルゴリズム	Nested Loop, Sort Marge, Hash Join	Nested Loop, Hash Join（*3）	Nested Loop, Sort Marge, Hash Join
トランザクション	commit/rollback必須、エラー時は対象SQLのみ自動rollback	デフォルトはSQL 1文でトランザクション確定。start transactionで複数文に対応。エラー時は対象SQLのみ自動rollback	デフォルトはSQL 1文でトランザクション確定。start transactionで複数文に対応。エラー時は対象トランザクション全体が自動rollback

（*1）追記型アーキテクチャは、UPDATE実行時に元のレコードは更新せず、更新後データを別レコードに挿入します。DELETEでも同様に元レコードは保持します。トランザクションごとに対象レコードの参照先を切り替え、元レコードを参照するトランザクションがなくなったら、vacuum処理により元レコードを削除します。
（*2）MySQLでのチェック制約は、MySQL 8.0.16以降のバージョンで利用可能です。それ以前はトリガーなどで代替する必要があります。
（*3）MySQLでのHash Joinは、MySQL 8.0.18以降のバージョンで利用可能です。Aurora MySQL互換でのHash Joinの利用は、マニュアルを参照してください。

検討ポイント2：マネージド型サービスの利用可否

「2. AWSでのDBの利用」に記載したように、DBサーバの構成として、利用者が管理を行う構成とAWS/サードパーティが管理を行うマネージド型のサービスを利用する構成から選択できます。基本的には、構築・運用にかかるコストを低減できるマネージド型サービスの利用が推奨されますが、制約事項もありますので、要件に合致するかを事前に確認する必要があります。

以下に、Oracle Databaseを例として、2種類の構成の特徴や注意事項をまとめます。

• Oracle Database on EC2

  • OSとそのバージョンを指定してEC2を作成した後、Oracle Databaseの導入の前提となる各種設定を実施したうえで、Oracle DatabaseのインストールやDB作成を実施します。
  • OS・DBMSの管理・運用は利用者が実施します。
  • オンプレミスとほぼ同等の構成が可能ですが、以下の点は注意が必要です。
    • Oracle Real Application Clustersは、AWSではサポートされません。
    • マルチAZのクラスタを構成する場合、EBSを共有ディスクとして使用できません。代替の方式として、サードパーティのノード間ミラーディスク製品やNFS/CIFSなどの利用の検討が必要です。
    • オンプレミスでストレージのディスクコピー機能（例：日立ストレージのShadowImage）を使用したバックアップ/リストアを実施している場合、AWSでは同様の方式は実現できません。RPO, RTOなどの要件に応じた方式の再設計が必要です。

• RDS for Oracle

  • RDS for Oracleは、Oracle Databaseのバージョン・エディションを指定して作成します。
  • RDS for Oracleでは、Oracle Real Application ClustersやAutomatic Storage Managementなどサポートされない機能があります。また、Data Guardのように一部の機能のみサポートされるケースもあります。移行元DBで使用している機能がRDS for Oracleでも使用できるかはマニュアルを参照していただき、サポートされない場合は代替方式の検討が必要です。
  • Oracle Databaseのパッチ適用は、AWSが動作確認したパッチセットを指定したメンテナンス時間帯に自動適用させることが可能です。個別パッチの適用はできません。また、必須のパッチがある場合は、期限を過ぎると強制的に適用されます。
  • 高可用化（別AZでのスタンバイDB/リードレプリカの作成）、バックアップ/リストアなどの運用機能は数クリックで実装可能です。
  • RDS for Oracleのディスク（データファイルやログを格納する領域）は、インスタンスを作成したAZ内で2重化されて保存されます。また、ディスク容量は最大64TiBです。
  • RDSのOSへはアクセスできません。既存システムでDBサーバ上で実行していた運用スクリプトは別サーバからリモート実行するなどの対応が必要です。
  • Oracle Databaseのビルドインの管理者アカウント（sys, system）は使用することはできません。代替の管理者アカウントを作成し、RDS向けの管理コマンドを使用する必要があります。

検討ポイント3：サイジング

(1) CPU・メモリのサイジング

EC2, RDSともに、AWS提供のインスタンスタイプからCPUタイプおよびCPU・メモリサイズの組み合わせを選択します。サイジングでは移行元DBサーバでのリソース割当量・使用率を元に必要リソースを見積ります。移行元で稼働統計情報を取得し（Oracle DatabaseではAWRで取得可能）、使用状況を確認してください。また、事前に性能テスト（性能検証PoC）を行い、リソース見直しを実施してください。

EC2では汎用・メモリ最適化・コンピューティング最適化などすべてのタイプ選択可能です。RDSでは、DBMSによっても異なりますが、DB用途に適した以下の3種類のインスタンスクラスから選択します。（EC2はインスタンスタイプで、RDSはインスタンスクラスという呼び方なんですね。）

RDSのインスタンスクラス	説明
汎用クラス（mクラス）	vCPU数とメモリ容量(GB)が1:4の比率の組み合わせの構成
メモリ最適化クラス（r, x, zクラス）	vCPU数とメモリ容量(GB)が1:8の比率の組み合わせの構成
バースト可能クラス（tクラス）	vCPUの数%～数10%を上限とするベースライン性能を使用可能。CPU使用率がベースライン以下なら、その差分をクレジットとして蓄積し、必要な場合にベースラインを越えてCPU性能を利用可能（バースト利用）な構成

インスタンスタイプを選択・変更する場合は、以下の点に注意が必要です。

• デフォルトではCPUのハイパースレッドが有効のため、vCPU=2コアは物理CPU=1コアに相当します。既存サーバのCPU割当量を元にサイジングする場合は注意してください。
• バースト可能クラスは、クレジットの蓄積状況によって最大性能が変動します。利用条件に合致する場合を除き、本番環境では使用しないことを推奨します。
• Graviton2などのARMプロセッサでは他のプロセッサと単純な性能比較はできませんので、本番環境で使用する場合は必ず性能テストを実施してください。
• リソースをスケールアップ/ダウンする場合は、DBの再起動が必要です。

(2) ディスクのサイジング

ディスクは、容量要件と性能要件に合わせて設定してください。EC2では、複数の種別・性能のディスクを柔軟に併用することが可能です。RDSやAuroraでは、以下の表から1つの種別のディスクを選択して使用します。

サービス	ディスク種別	説明
RDS（Aurora以外）	マグネティック	HDDディスクで、容量自動拡張は非サポートです。最大3TiB、1000 IOPSの制限があります。下位互換性のために存在しており非推奨です。
	汎用SSD	SSDディスクで、容量自動拡張をサポートします。ベースライン性能は1GiBあたり3 IOPSで、最小1,000 IOPS～最大16,000 IOPSです。容量1TiB未満では、クレジットの蓄積により最大3,000 IOPSのバーストが可能です。
	プロビジョンドIOPS	SSDディスクで、容量自動拡張をサポートします。I/O性能値としてIOPSを指定可能です。最大IOPSはDBMSやインスタンスクラスによって異なるのでマニュアルを参照してください。プロビジョンドIOPSのコストは割当容量に加え、指定したIOPS値に応じたコストが発生します。
Aurora	-	SSDディスクで、容量自動拡張をサポートします。容量・性能値は事前に設定せず、実データの格納容量・I/O量によりコストが発生します。 Auroraではディスク仕様は決まっており設定項目はありません。

ディスクサイジングする場合は、以下の点に注意が必要です。

• RDSでの最大ディスク容量（マグネティックを除く）はSQL Serverで16TiB、SQL Server以外では64TiBです。Auroraでの最大ディスク容量は128TiBです。
• RDSでディスク種別はオンラインで変更することが可能です。ただし、変更処理中は性能に影響があります。

検討ポイント4：コスト

DB移行に関係するコストは以下の3種類に分類できます。

• DBのリソース、ライセンスにかかるコスト
• DBの構築・テストおよび稼働後の運用にかかるコスト
• DBを利用するアプリケーションの改修・テストにかかるコスト

2, 3点目のコストは、移行対象システムごとに大きく異なりますので、個別に見積もってください。

1点目のコストについて、商用DBではオンプレミスとクラウドでライセンスの考え方が異なることがあるため、注意が必要です。例として、Oracle Databaseのプロセッサライセンスの場合、AWSでは「コア係数」の考え方がないなどの差異があり、AWSへの移行によりコスト増となるケースがあります。正式にはAWSの「Oracle のよくある質問」や、Oracleの「クラウド・コンピューティング環境における Oracle ソフトウェアのライセンス」に記載の内容を確認していただいたり、購入元に確認して見積もりを行ってください。

4. 最後に

データベースをAWSへ移行する際の検討すべきポイントを4点あげてみました。これらのポイントに加え、各システムに固有の要件に応じた検討を実施してください。

これらの検討によりDBサーバの構成を決定し、その後にDBの環境設計・運用設計・移行設計を行って、詳細を詰めていくことになります。DBの移行方式については別の記事にまとめますので、こちらも参考にしていただければと思います。