ワークロードを検証する

データベースに最適な移行戦略を決定するには、現在のデータベースワークロードを把握することが重要です。現在使用しているデータベースを分析し、どのような機能を使用しているのか、また Amazon Aurora PostgreSQL のような他のクラウドネイティブデータベースエンジンへの移行には何が必要なのかを判断する必要があります。

AWS は、AWS 作業負荷検証フレームワーク（AWS WQF）と呼ばれる作業負荷検証ツールを提供しています。このツールは、データベーススキーマとコードオブジェクト、アプリケーションコード、依存関係、パフォーマンス特性、および同様の入力情報を分析することにより、Oracle および Microsoft SQL Server のデータベース移行の複雑さを特定するのに役立ちます。WQF はターゲットデータベースエンジンに関する推奨事項を提供します。また、関連する作業の種類と必要な作業のレベルも予測します。

WQF はお客様の移行ワークロードを評価し、以下の表にまとめられた 5 つのワークロードカテゴリのいずれかに分類します。

• Cカテゴリ1：データベースへの接続に、専用ドライバの代わりにODBC（Open Database Connectivity）またはJDBC（Java Database Connectivity）を使用するワークロード。このカテゴリには通常、アクセス制御に使われる単純なストアドプロシージャがあります。変換に必要な手動変更は 50 回未満です。

• カテゴリ2：独自の機能を軽く使用し、高度な SQL 言語機能を使用しないワークロード。この種のワークロードでは、手動での変更は 200 回未満で済みます。

• カテゴリ3：独自機能を多用するワークロード。このカテゴリのワークロードは、高度なストアドプロシージャロジックまたは独自の機能によって完全に左右されます。この種のワークロードでは、データベースに常駐するコードや機能を含む 200 件以上の手動変更が必要です。

• カテゴリ4：エンジン固有のワークロード このカテゴリのワークロードは、特定の商用データベースエンジンでしか機能しないフレームワークを使用します。たとえば、Oracle Forms、Oracle Reports、Oracle Application Development Framework（ADF）、Oracle Application Express（APEX）、あるいは .NET ActiveRecord を多用するアプリケーションなどのフレームワークです。

• カテゴリ 5：移動できない、許容できないリスク、または「リフトアンドシフト」ワークロード。このカテゴリのワークロードは、クラウドベース同等の機能を持たないデータベースエンジンに実装される可能性があります。カスタマーがこれらのプログラムのソースコードを持っていない場合もあります。

この分類は、「フェーズ2：計画」のセクションで説明するように、アプリケーションの移行パスを決定するのに役立ちます。

AWS は現時点、ダウンロード用の AWS WQF は提供されていません。AWS WQFを利用した AWS への移行の評価についてサポートが必要な場合は、サポートチケットの発行をお勧めします。AWS が直接対応し、プロセスを円滑に進めるお手伝いをします。