移行アプローチの決定

移行アプローチを決定するには、前のフェーズで既存のパターンに対して実行した分析を使用します。組織の将来のデータと分析のニーズも同様に重要な考慮事項です。従来のオンプレミス ETL ツールは、リレーショナルデータモデルと構造化データを扱います。半構造化データと非構造化データを処理する場合は、移行に AWS Glue や Amazon EMR などのサービスを使用できます AWS 。移行アプローチに影響を与える可能性のあるその他の要因は次のとおりです。

• グラフィカルインターフェイス (AWS Glue Studio など) を使用するか、カスタムフレームワーク (Spark/Python ライブラリなど) を使用するか

• オンプレミスのソースと AWS ターゲットに安全にアクセスできるかどうか

• チームに必要なスキルとトレーニング

• 監査とコンプライアンスの要件

移行アプローチは、ビッグバン、フェーズド、リフトアンドシフトの 3 つから選択できます。次の表は、これら 3 つのアプローチを比較したものです。

アプローチ	説明	ユースケース	利点と欠点
ビッグバング	特定の期間内にすべての SSIS パッケージを移行します。	複雑さ、範囲、ターゲットアーキテクチャは明確です。 チームに必要なスキルがあるか、学習曲線が浅い。	高リスク。 段階的アプローチよりも時間がかかります。 AWS Glue、Amazon EMR、またはカスタムフレームワークを使用できます。
段階的	個別のパターンと複雑さごとに 1 つの SSIS パッケージを特定します。パッケージを既存のアーキテクチャに移行し、 AWSテストして、結果を比較します。	時間は制約ではありません。 ETL パターンごとに異なる設計が必要です。	ビッグバングアプローチよりもリスクは低くなりますが、時間と労力がかかります。 AWS Glue、Amazon EMR、またはカスタムフレームワークを使用できます。
リフトアンドシフト	現在のアーキテクチャをそのまま移行します AWS。	オンプレミスハードウェアはサポートされなくなりました。 移行をすぐに計画するためのリソースがない。	移行にかかる時間と労力が最も少ない。 既存のソリューションの問題は引き続き発生します AWS。 SSIS パッケージはそのまま実行されます。他の ETL ツールやフレームワークは必要ありません。

移行を成功させるには、ソースシステムとターゲットシステム上のデータの比較が不可欠です。既存の本稼働システムはソースシステムから定期的に更新されるため、この比較はわかりにくい場合があります。このため、移行アプローチを決定するときは、データ検証戦略も決定することをお勧めします。

• ソースシステムの本番環境から、該当するすべてのデータベースとファイルのバックアップを特定の日時で取得します。

• バックアップされたソースデータからすべてのジョブが正常にデータをロードした後、ターゲットシステムの本番稼働環境からすべてのデータベースのバックアップを作成します。

• テスト環境でソースデータを復元し、新しいジョブを実行します。

• ソースデータベースとターゲットデータベース (古いデータベースと新しいデータベース) の有効な違いの割合について合意します。例えば、1% 未満の差は許容できると判断できます。

• 対象となるすべての検証ルールを一覧表示します。

• 比較を可能な限り自動化し、すべてのルールをカバーします。