🔰

【Oracle】RATとRACの機能解説/AWS移行方法

2023/06/18に公開

OracleのRATとは

Oracle Real Application Testing(リアルアプリケーションテスト)のこと。
RATは、システムの変更がアプリケーションのパフォーマンスにどのように影響するかを確認するための強力なツールです。RATは主に2つのコンポーネントからなります:データベースリプレイ(Database Replay)とSQLパフォーマンスアナライザ(SQL Performance Analyzer, SPA)。

1. データベースリプレイ: これは、プロダクションデータベースのワークロードをキャプチャし、それをテストシステムで再現することで、データベースの変更が実際のワークロードにどのように影響するかを評価できます。これにより、プロダクションシステムで発生する可能性のある問題を早期に検出し、対処することができます。

2. SQLパフォーマンスアナライザ: これは、システムの変更が個々のSQLクエリのパフォーマンスにどのように影響するかを評価するためのツールです。SQLのチューニングセットを使用して、SQLのワークロードをキャプチャし、その後の環境変更(例えば、データベースのアップグレードやパラメータの変更など)後のパフォーマンスを予測します。

なお、AWS RDS for OracleではOracle RATはサポートされていません。したがって、RATの機能を必要とする場合は、EC2上に自己管理のOracleデータベースをセットアップすることを検討するか、あるいはAWSが提供する他のパフォーマンステストやモニタリングツールを利用する必要があります。

Oracle Real Application Clusters(RAC)の概要

RACOracle Databaseのオプションの一つで、複数のサーバー上で一つのデータベースを同時に稼働させることができる。これにより、高可用性、スケーラビリティ、および耐障害性が向上する。

以下に、RACの主な特性について説明する:

  1. 高可用性: RACは複数のサーバーでデータベースを稼働させるため、一つのサーバーに問題が発生した場合でも他のサーバーが稼働を続けます。これにより、システム全体のダウンタイムを大幅に減らすことができます。

  2. スケーラビリティ: RACでは、データベースワークロードを複数のサーバーに分散させることができます。これにより、システムの処理能力を簡単に増やすことが可能で、大量のデータや高負荷のクエリに対応する能力が向上します。

  3. 耐障害性: RACは共有ディスクアーキテクチャを使用しており、全てのサーバーが全てのデータを共有します。これにより、一つのサーバーがダウンした場合でもデータベースは正常に稼働し続けます。

ただし、RACを使用するためには、適切なハードウェア、ネットワーク設定、およびソフトウェア設定が必要です。また、RACを最大限に活用するためには、アプリケーションがRACの特性を理解し、それに応じて設計されていることが重要です。

AWSのRDSではOracle RACはサポートされていません。RACを活用したい場合は、Amazon EC2上にOracleデータベースを自己管理でセットアップする必要があります。もしくは、AWSのマルチAZ展開や他の高可用性ソリューションを利用することで、RACの提供するような高可用性を得ることが可能です。

AWS Auroraは、Oracleデータベースからの移行を支援するために、AWS Schema Conversion Tool (SCT)とAWS Database Migration Service (DMS)を提供しています。

移行方法

1. AWS Schema Conversion Tool (SCT): このツールは、ソースデータベースのスキーマ(テーブル、インデックス、ビューなど)をターゲットデータベースの形式に変換します。OracleからAuroraへの移行の場合、SCTはOracleのスキーマをAurora MySQLまたはAurora PostgreSQLに適合するように変換します。SCTはまた、Oracleのストアドプロシージャ、関数、トリガーなどのデータベースコードも変換します。変換できないオブジェクトやコードについては、手動で対応するための詳細な報告を提供します。

2. AWS Database Migration Service (DMS): このサービスは、ソースデータベースのデータをターゲットデータベースに移行します。OracleからAuroraへの移行の場合、DMSはOracleデータベースのデータをAuroraに移行します。このプロセスは通常、最小限のダウンタイムで実行され、ソースデータベースが移行中も稼働を続けます。

ただし、これらのツールが大部分の作業を自動化してくれますが、移行プロセス全体を完全に自動化するわけではありません。特に、アプリケーションコードの変更(特に、データベース固有のSQLクエリや関数を使用している場合)やパフォーマンスチューニングなどの調整が必要となる場合があります。また、移行前には、ターゲットのAuroraデータベースが期待通りのパフォーマンスと互換性を提供することを確認するために、テストや検証も必要となるでしょう。

Discussion