ワークロードを適格化する

データベースに最適な移行戦略を決定するには、現在のデータベースのワークロードを理解することが重要です。データベースを分析して、現在使用している機能と、Amazon Aurora PostgreSQL のような別のクラウドネイティブデータベースエンジンへの移行に関係しているものを特定する必要があります。

AWS は、AWS ワークロード資格フレームワーク (AWSWQF) というワークロード認定ツールを提供します。このツールは、データベーススキーマとコードオブジェクト、アプリケーションコード、依存関係、パフォーマンス特性、および類似の入力を分析することで、Oracle および Microsoft SQL Server データベース移行の複雑さを特定するのに役立ちます。WQF は、ターゲットデータベースエンジンに関するレコメンデーションを提供します。また、関連する作業の種類と必要な作業のレベルも予測します。

WQF は移行ワークロードを評価し、次の表に示す 5 つのワークロードカテゴリのいずれかに配置します。

• カテゴリ 1: データベースに接続するワークロード独自のドライバーではなく、Open Database Connectivity (ODBC) または Java Database Connectivity (JDBC) を使用するワークロード。このカテゴリには通常、アクセス制御に使用される単純なストアドプロシージャがあります。変換に必要な手動変更は 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 は、お客様と直接関わって、お客様のプロセスをお手伝いいたします。