翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# フェーズ 1： 準備
データベース移行プロセスの最初の段階は準備です。準備中に、アプリケーションとデータベース間の相互依存関係を特定します。また、データベースのワークロードを分析し、単純なリホスト (同種移行) からリアーキテクト (異種移行) まで、移行のカテゴリーを決定します。このフェーズを完了しないと、移行のスケジュールが遅れるリスクがあります。
これらのタスクについては、以下のセクションで説明します。
+ [依存関係の特定](id-dependencies.md)
+ [対象ワークロード](qualify-workloads.md)
# 依存関係の識別
まず、次のような質問をして、アプリケーションとデータベースの依存関係を特定します。
+ このデータベースには他のアプリケーションから直接アクセスされていますか?
その場合は、データベースの移行がそのアプリケーションにどのような影響を与えるかを判断する必要があります。データベースをリホストする場合でも、アプリケーションが許容できるパフォーマンスでデータベースにアクセスできることを確認する必要があります。
+ アプリケーションは他のデータベースに直接アクセスしていますか？
その場合は、他のデータベースの移行計画を決定します。これも移行中の場合は、それに応じてアプリケーションを更新する必要があります。移行しない場合は、アプリケーションが許容できるレイテンシーで引き続き接続できることを確認する必要があります。
+ データベースリンクを使って他のデータベースからデータを取得していますか？
前のポイントと同様に、他のデータベースの移行プランを決め、それに応じてリンクを処理します。
+ アプリケーションはオンプレミスソフトウェアに依存していますか?
その場合は、そのソフトウェアの移行計画を決定する必要があります。もし移行するのであれば、それに応じてアプリケーションをアップデートする必要があります。そうでない場合は、アプリケーションがソフトウェアへの接続を継続でき、レイテンシが許容範囲内であることを確認します。
+ ハードウェアの依存関係はありますか?
もしそうなら、それらに対処する計画を立てます。
+ 帯域幅やネットワークに関する厳しい要件はありますか?
その場合は、これらの条件を満たすことができる AWS サービスを選択します。
+ アプリケーションは特別なデータベースエンジンオプションや機能を使用していますか?
別のデータベースエンジンに移行する場合は、それに応じてアプリケーションを更新する必要があります。
これらの質問に対する答えが複雑な場合は、マイクロサービスを使用してデータベースをアプリケーションから切り離す方がよいでしょう。この方法では、アプリケーションはデータベースに直接接続する代わりに、マイクロサービスを呼び出すことでデータを取得できます。
# ワークロードを検証する
データベースに最適な移行戦略を決定するには、現在のデータベースワークロードを把握することが重要です。現在使用しているデータベースを分析し、どのような機能を使用しているのか、また [Amazon Aurora PostgreSQL](https://aws.amazon.com/rds/aurora/) のような他のクラウドネイティブデータベースエンジンへの移行には何が必要なのかを判断する必要があります。
AWS は、AWS 作業負荷検証フレームワーク (AWS WQF) と呼ばれる作業負荷検証ツールを提供しています。このツールは、データベーススキーマとコードオブジェクト、アプリケーションコード、依存関係、パフォーマンス特性、および同様の入力情報を分析することにより、Oracle および Microsoft SQL Server のデータベース移行の複雑さを特定するのに役立ちます。WQF はターゲットデータベースエンジンに関する推奨事項を提供します。また、関連する作業の種類と必要な作業のレベルも予測します。
WQF はお客様の移行ワークロードを評価し、以下の表にまとめられた 5 つのワークロードカテゴリのいずれかに分類します。
![\[Five migration workload categories reported by WQF\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/strategy-database-migration/images/wqf-categories.png)
+ **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：計画](planning-phase.md)」のセクションで説明するように、アプリケーションの移行パスを決定するのに役立ちます。
AWS は現時点、ダウンロード用の AWS WQF は提供されていません。AWS WQFを利用した AWS への移行の評価についてサポートが必要な場合は、サポートチケットの発行をお勧めします。AWS が直接対応し、プロセスを円滑に進めるお手伝いをします。