翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

タスク 2: メタデータを識別、収集、保存するためのプロセスを定義する

前のタスクでは、最初の検出データ、移行戦略、大規模な移行の移行パターンを検証しました。このタスクでは、必要なメタデータを特定し、どのように収集するかを決定します。このタスクは、次のステップで構成されます。

このセクションのステップを完了するときは、メタデータの観点から移行サイクル全体を考慮してください。ポートフォリオ評価、ウェーブプランニング、移行、テスト、カットオーバー後のアクティビティを検討し、考えられるすべてのユースケースと関連するユースケースを分析します。完全な移行プロセスを完了するために必要な情報について考えると、そのパターンのすべてのメタデータを識別するのに役立ちます。

ステップ 1: 必要なメタデータを定義する

必要なメタデータ属性を決定する前に、移行パターンを理解する必要があります。たとえば、サーバーを Amazon EC2 に移行したり、データベースを Amazon RDS に移行したりするには、異なるメタデータが必要です。ほとんどのパターンは、多くの小さなタスクで構成されています。移行パターンを実行するには、必要なメタデータ属性を確認してから、そのアプリケーションのメタデータを収集する必要があります。実装段階で移行を効率的かつ遅滞なく実行できるように、初期化段階で必要なメタデータを決定して収集する必要があります。

メタデータ属性を定義する人またはチームは、移行パターンの実行に必要なステップとタスクを定義することから始めます。タスクは必要なメタデータを決定するため、各タスクを操作すると、必要なメタデータの包括的なコレクションが構築されます。通常、必要なメタデータを決定する担当者は、移行パターンを完了する方法を包括的に理解する必要があります。移行ランブックの作成者との調整が必要になる場合があります。詳細については、AWS 「大規模な移行の移行プレイブック」を参照してください。

大規模な移行中、メタデータに依存するすべてのワークストリームにまたがる多くのプロセスがあります。タイムリーで正確なメタデータを持つことは、大規模な移行の成功に幅広く大きな影響を与えます。

このステップでは、パターンまたはタスクを定義し、その定義を使用して必要なメタデータを識別します。

移行パターンとサポートタスクの主要なコンポーネントを特定する

このステップでは、移行パターンまたはサポートタスクごとに、アクション、ソースオブジェクト、ターゲットオブジェクト、使用するツールなどの主要なコンポーネントを定義します。次に、回答に基づいてパターンまたはタスクに名前を付けます。

サポートタスクには、ウェーブプランニング、アプリケーションの優先順位付け、依存関係分析、ガバナンス、ディザスタリカバリ、パフォーマンステスト、ユーザー受け入れテストなど、ポートフォリオと移行ワークストリームが移行中に実行する必要がある運用アクティビティが含まれます。これらのタスクをサポートするにはメタデータが必要なため、移行パターンとサポートタスクの両方に対してこれらのステップを実行します。

以下は、移行パターンテーブルから Application Migration Service または Cloud Migration Factory を使用してパターン 1: Amazon EC2 へのリホストを記録する方法の例です。

各パターンまたはタスクに必要なメタデータを決定する

パターンまたはタスクを定義したら、ソースオブジェクト、ターゲットオブジェクト、ツール、およびその他のビジネス情報に必要なメタデータを決定します。このプロセスを説明するために、このプレイブックでは、例として、移行パターンテーブルから Application Migration Service または Cloud Migration Factory を使用してパターン 1: Amazon EC2 にリホストします。一部のパターンやタスクでは、一部のステップが適用されない場合があります。

ステップ 2: メタデータストレージとコレクションプロセスを構築する

前のステップでは、移行のサポートに必要なメタデータを定義しました。このステップでは、メタデータを収集して保存するプロセスを構築します。このステップは 2 つのタスクで構成されます。

メタデータソースを分析する

一般的なメタデータソースは多数あります。通常、最初にアクセスできるのは高レベルのアセットインベントリで、通常は設定管理データベース (CMDB) または別の既存のツールからエクスポートされます。ただし、自動プロセスと手動プロセスの両方を使用して、他のソースからもメタデータを収集する必要があります。

次の表に、一般的なソース、そのソースの標準収集プロセス、そのソースから検索できる一般的なメタデータタイプを示します。

メタデータのすべてのソースを一覧表示したら、メタデータタイプを分析し、各ソースを前のステップで特定したメタデータ属性にマッピングします。

1 つのメタデータストアを定義する

各メタデータ属性をソースにマッピングした後、メタデータを保存する場所を定義します。メタデータの保存方法と保存場所にかかわらず、選択する必要があるリポジトリは 1 つだけです。これにより、信頼できる情報源が 1 つになります。メタデータを複数の場所に保存することは、大規模な移行でよくある間違いです。

オプション 1: 共有リポジトリのスプレッドシートにメタデータを保存する

このオプションは非常に手動のプロセスのように聞こえるかもしれませんが、大規模な移行では最も一般的なデータストアです。また、スプレッドシートを Microsoft SharePoint サイトなどの共有リポジトリに保存することも一般的です。

Microsoft Excel スプレッドシートはカスタマイズが簡単で、構築に時間がかかることはありません。欠点は、メタデータが多いと非常に複雑になり、サーバー、アプリケーション、データベースなどのアセット間の関係を管理するのが困難な場合があることです。もう 1 つの課題はバージョン管理です。書き込みアクセスを数人に制限するか、自動化されたプロセスを使用してスプレッドシートを更新する必要があります。

ポートフォリオプレイブックテンプレートでは、独自のデータストアスプレッドシートを構築するための出発点として、ウェーブプランニングと移行用の Dashboard テンプレート (Excel 形式) を使用できます。

オプション 2: 専用ツールにメタデータを保存する

TDS Transition Manager (TDS ウェブサイト) などの構築済みのツールを使用してデータを保存するか、独自のツールを構築できます。独自のツールを構築する場合、オプション 1 の Excel スプレッドシートタブと同様にデータベーステーブルが必要です。例えば、次のようになります。

メタデータ収集プロセスを定義する

前のステップでは、メタデータをソースにマッピングし、メタデータを収集するデータストアを定義しました。このステップでは、メタデータを効果的に収集するプロセスを構築します。手動copy-and-pasteプロセスを最小限に抑え、自動化を使用して各ソースからメタデータを収集する必要があります。次の 3 つのステップがあります。

次の表は、各 ETL スクリプトによって収集されたメタデータ属性の例です。メタデータは、スプレッドシートや専用ツールなど、前のセクションで定義した場所に保存されます。

ステップ 3: ランブックにメタデータ要件と収集プロセスを文書化する

このタスクでは、決定事項をメタデータ管理ランブックに文書化します。移行中、ポートフォリオワークストリームは、メタデータを収集して保存するための標準手順として、このランブックに従います。

タスク終了条件

次のタスクを完了したら、次のタスクに進みます。