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

# タスク 2: メタデータを識別、収集、保存するためのプロセスを定義する
<a name="metadata"></a>

前のタスクでは、最初の検出データ、移行戦略、大規模な移行の移行パターンを検証しました。このタスクでは、必要なメタデータを特定し、どのように収集するかを決定します。このタスクは、次のステップで構成されます。
+ [ステップ 1: 必要なメタデータを定義する](#metadata-1)
+ [ステップ 2: メタデータストレージとコレクションプロセスを構築する](#metadata-2)
+ [ステップ 3: ランブックにメタデータ要件と収集プロセスを文書化する](#metadata-3)

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

## ステップ 1: 必要なメタデータを定義する
<a name="metadata-1"></a>

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

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

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

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

### 移行パターンとサポートタスクの主要なコンポーネントを特定する
<a name="metadata-1-components"></a>

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

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

1. **アクション** – 移行戦略またはサポートタスクを特定します。1 つのアクションには、他のアクションが関連付けられている可能性があることに注意してください。たとえば、移行のオペレーションを定義できます。アクションの例は次のとおりです。
   + リホスト、リプラットフォーム、再配置などの移行戦略
   + ウェーブプランニング
   + アプリケーションの優先順位付けと依存関係の分析
   + 運用
   + ガバナンス
   + ディザスタリカバリ
   + パフォーマンステストやユーザー受け入れテスト (UAT) などのテスト

1. **ソースオブジェクト** – アクションを実行するソースオブジェクトを特定します。ソースオブジェクトの例は次のとおりです。
   + ウェーブ
   + サーバー
   + データベース
   + ファイル共有
   + アプリケーション

1. **ツール** – アクションを実行するために使用されるサービスまたはツールを特定します。複数のツールまたはサービスを使用できます。ツールの例は次のとおりです。
   + AWS Application Migration Service
   + AWS DataSync
   + AWS Database Migration Service (AWS DMS)
   + AWS Backup
   + パフォーマンスモニタリングツール

1. **ターゲットオブジェクト** – アクションの完了時にソースが存在するターゲットオブジェクト、サービス、または場所を特定します。オブジェクト、サービス、または場所の例は次のとおりです。
   + Amazon Elastic Compute Cloud (Amazon EC2)
   + Amazon Relational Database Service (Amazon RDS)
   + Amazon Elastic File System (Amazon EFS)
   + Amazon Elastic Container Service (Amazon ECS)
   + ウェーブプラン

1. **パターン名** – 次のように前のステップに対する回答を結合します。

   <tool> を使用した <action> <source object> on/to <target object>

   次に例を示します。
   + Application Migration Service または Cloud Migration Factory (ツール) を使用して、ウェーブ、アプリケーション、またはサーバー (ソースオブジェクト) を Amazon EC2 (ターゲットオブジェクト) にリホスト (アクション) する 
   + DataSync (ツール) を使用して (アクション) ファイル共有 (ソースオブジェクト) を Amazon EFS (ターゲットオブジェクト) にリプラットフォームする
   + (ツール) を使用して (アクション) データベース (ソースオブジェクト) を Amazon RDS (ターゲットオブジェクト) にリプラットフォーム AWS DMS する
   + Amazon CloudWatch (ツール) を使用した Amazon EC2 (ターゲットオブジェクト) 上のアプリケーション (ソースオブジェクト) のパフォーマンスモニタリング (アクション)
   + 移行後に (ツール) を使用して AWS Backup Amazon EC2 (ターゲットオブジェクト) で (アクション) サーバー (ソースオブジェクト) をバックアップする
   + ウェーブプランを作成するためのウェーブプランニング (アクション) ウェーブ、アプリケーション、またはサーバー (ソースオブジェクト) (ターゲットオブジェクト)

以下は、移行*パターンテーブルから Application Migration Service または Cloud Migration Factory を使用してパターン 1: Amazon EC2 へのリホスト*を記録する方法の例です。 [](discovery.md#migration-patterns)


****  

|  |  | 
| --- |--- |
| **Pattern ID** | 1 | 
| **Pattern name** | Application Migration Service または Cloud Migration Factory を使用して Amazon EC2 にリホストする | 
| **Action** | リホスト移行 | 
| **Source object** | ウェーブ、アプリケーション、またはサーバー | 
| **Tools** | Application Migration Service または Cloud Migration Factory | 
| **Target object** | Amazon EC2 | 

### 各パターンまたはタスクに必要なメタデータを決定する
<a name="metadata-1-determine"></a>

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

1. **ターゲットオブジェクトを分析する** – ターゲットオブジェクトから逆算し、オブジェクトを手動で作成して、オブジェクトをサポートするために必要なメタデータを特定します。次の表に示すように、メタデータをキャプチャします。

   たとえば、EC2 インスタンスを作成するときは、インスタンスタイプ、ストレージタイプ、ストレージサイズ、サブネット、セキュリティグループ、タグを選択する必要があります。次の表に、ターゲットオブジェクトが EC2 インスタンスの場合に必要なメタデータ属性の例を示します。  
****    
[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/metadata.html)

1. **ツールを分析する** – ツールを使用してターゲットオブジェクトを作成し、違いをチェックします。次の表に示すように、ツール固有のメタデータをキャプチャし、移行ツールでサポートされていない場合は前の表から属性を削除します。たとえば、リホスト移行ツールはlike-for-likeしているため、Application Migration Service の OS タイプとストレージサイズをカスタマイズすることはできません。したがって、これらの属性が前の表に含まれている場合は、ターゲット OS とターゲットディスクサイズを削除します。前の例の表では、すべての属性がツールでサポートされているため、アクションは必要ありません。

   次の表に、ツールに必要なメタデータの例を示します。  
****    
[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/metadata.html)

1. **ソースオブジェクトを分析する** – 次のようにアクションを評価して、ソースオブジェクトに必要なメタデータを決定します。
   + サーバーを移行するには、サーバーに接続するために、ソースサーバー名と完全修飾ドメイン名 (FQDN) を知る必要があります。
   + サーバーとともにアプリケーションを移行するには、アプリケーション名、アプリケーション環境、およびapplication-to-server間のマッピングを知る必要があります。
   + ポートフォリオ評価の実行、アプリケーションの優先順位付け、または移動グループの定義を行うには、application-to-server間のマッピング、application-to-databaseマッピング、およびapplication-to-application依存関係を把握しておく必要があります。
   + ウェーブを管理するには、ウェーブ ID とウェーブの開始時刻と終了時刻を知る必要があります。

   次の表に、ソースオブジェクトに必要なメタデータの例を示します。  
****    
[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/metadata.html)

1. **他の属性を検討する** – プライマリアクションに加えて、ターゲットオブジェクトまたはアプリケーションに関連する他のアクションや属性も考慮します。サンプルパターンの*パターン 1: Application Migration Service または Cloud Migration Factory を使用して Amazon EC2 にリホスト*すると、アクションはリホストされ、ターゲットオブジェクトは Amazon EC2 です。このターゲットオブジェクトのその他の関連アクションには、Amazon EC2 へのバックアップ、移行後の EC2 インスタンスのモニタリング、EC2 インスタンスに関連するコストの管理のためのタグの使用などがあります。また、アプリケーション所有者など、移行の管理に役立つ他のアプリケーション属性を検討することもできます。アプリケーション所有者は、質問やカットオーバーの目的で問い合わせる必要があります。

   次の表に、一般的に使用される追加のメタデータの例を示します。このテーブルには、ターゲット EC2 インスタンスのタグが含まれています。タグとその使用方法の詳細については、[Amazon EC2 ドキュメントの「Amazon EC2 リソースのタグ付け](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)」を参照してください。 Amazon EC2   
****    
[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/metadata.html)

1. **テーブルの作成** – 前のステップで特定したすべてのメタデータを 1 つのテーブルに結合します。  
****    
[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/metadata.html)

1. **Repeat** – 各パターンに必要なメタデータを記録するまで、このプロセスを繰り返します。

## ステップ 2: メタデータストレージとコレクションプロセスを構築する
<a name="metadata-2"></a>

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

1. 前のステップの必要なメタデータを分析し、ソースを特定します。

1. メタデータを効率的に保存および収集するプロセスを定義します。

### メタデータソースを分析する
<a name="metadata-2-source"></a>

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

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


****  

| メタデータソース | コレクションタイプ | メタデータタイプ | 
| --- | --- | --- | 
| Discovery tools | 自動 | ソースサーバー | 
| CMDB | 自動 | ソースサーバー | 
| の [RVTools](https://www.robware.net/) など、他のツールからのインベントリ VMware vSphere | 自動 | ソースサーバー | 
| アプリケーション所有者アンケート | 手動 | ソースサーバー、ターゲットサーバー、ウェーブ | 
| アプリケーション所有者のインタビュー | 手動 | ソースサーバー、ターゲットサーバー、ウェーブ | 
| アプリケーション設計ドキュメント | 手動 | ターゲットサーバー | 
| ランディングゾーン設計ドキュメント | 手動 | ターゲットサーバー、ツール | 

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

1. からメタデータ属性の完全なリストを取得します[ステップ 1: 必要なメタデータを定義する](#metadata-1)。

1. 各メタデータタイプを分析し、自動プロセスを使用して取得できないタイプを特定します。これは通常、**ターゲットサーバーメタデータ**と**ウェーブメタデータ**タイプです。アプリケーション所有者の決定が必要なためです。たとえば、ターゲット EC2 インスタンスにはどのサブネットとセキュリティグループを使用しますか?

1. 各メタデータ属性を分析し、前の表のメタデータソースにマッピングします。複数のソースの組み合わせを持つことが一般的です。検出ツールを使用して、一部のソースサーバーメタデータを収集できます。検出ツールを使用してメタデータを収集する方法については、 AWS 「 規範ガイダンス」ウェブサイト[の「自動ポートフォリオ検出の開始方法](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/get-started-with-automated-portfolio-discovery.html)」を参照してください。

1. メタデータ属性をタイプとソースにマッピングするテーブルを作成します。次の表は例です。  
****    
[See the AWS documentation website for more details](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/large-migration-portfolio-playbook/metadata.html)

### 1 つのメタデータストアを定義する
<a name="metadata-2-store"></a>

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

#### オプション 1: 共有リポジトリのスプレッドシートにメタデータを保存する
<a name="metadata-2-store-1"></a>

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

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

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

#### オプション 2: 専用ツールにメタデータを保存する
<a name="metadata-2-store-2"></a>

[TDS Transition Manager](https://www.transitionaldata.com/software/) (TDS ウェブサイト) などの構築済みのツールを使用してデータを保存するか、独自のツールを構築できます。独自のツールを構築する場合、オプション 1 の Excel スプレッドシートタブと同様にデータベーステーブルが必要です。例えば、次のようになります。
+ サーバーテーブル
+ アプリケーションテーブル
+ データベーステーブル
+ Application-to-server および application-to-database マッピングテーブル
+ Wave-planning テーブル
+ アプリケーション所有者アンケートテーブル

### メタデータ収集プロセスを定義する
<a name="metadata-2-collection"></a>

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

1. メタデータマッピングテーブルに基づいて、各メタデータソースの抽出、変換、ロード (ETL) スクリプトを構築します。

1. 各ソースからメタデータを自動的にインポートするスケジュールされたタスクを定期的に構築します。

1. エクスポートプロセスを構築するか、リポジトリに保存されているメタデータへのアプリケーションプログラミングインターフェイス (API) アクセスを提供します。

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


****  

| Metadata 属性 | メタデータタイプ | メタデータソース | 収集プロセス | 
| --- | --- | --- | --- | 
| `app_name` | ソースアプリケーション | CMDB | ETL スクリプト – CMDB | 
| `app_owner` | ソースアプリケーション | CMDB | ETL スクリプト – CMDB | 
| `app_to_server_mapping` | ソースアプリケーション | CMDB | ETL スクリプト – CMDB | 
| `app_to_DB_mapping` | ソースアプリケーション | CMDB | ETL スクリプト – CMDB | 
| `app_to_app_dependencies` | ソースアプリケーション | 検出ツール | ETL スクリプト – 検出ツール | 
| `server_name` | ソースサーバー | CMDB | ETL スクリプト – CMDB | 
| `server_FQDN` | ソースサーバー | CMDB | ETL スクリプト – CMDB | 
| `server_OS_family` | ソースサーバー | CMDB | ETL スクリプト – CMDB | 
| `server_OS_version` | ソースサーバー | CMDB | ETL スクリプト – CMDB | 
| `disk_size` | ソースサーバー | 検出ツール | ETL スクリプト – 検出ツール | 
| `instance_type` | ターゲットサーバー | 検出ツール | ETL スクリプト – 検出ツール | 
| `target_subnet` | ターゲットサーバー | アプリケーション所有者アンケート | ETL スクリプト – アプリケーション所有者 | 
| `target_security_group` | ターゲットサーバー | アプリケーション所有者アンケート | ETL スクリプト – アプリケーション所有者 | 
| `AWS_Region` | ターゲットサーバー | アプリケーション所有者アンケート | ETL スクリプト – アプリケーション所有者 | 
| `AWS_account_ID` | ターゲットサーバー | アプリケーション所有者アンケート | ETL スクリプト – アプリケーション所有者 | 
| `Name` | ターゲットサーバー (タグ) | アプリケーション所有者アンケート | ETL スクリプト – アプリケーション所有者 | 
| `business_unit` | ターゲットサーバー (タグ) | アプリケーション所有者アンケート | ETL スクリプト – アプリケーション所有者 | 
| `cost_center` | ターゲットサーバー (タグ) | アプリケーション所有者アンケート | ETL スクリプト – アプリケーション所有者 | 
| `wave_ID` | ウェーブプランニング | アプリケーション所有者アンケート | ETL スクリプト – アプリケーション所有者 | 
| `wave_start_date` | ウェーブプランニング | アプリケーション所有者アンケート | ETL スクリプト – アプリケーション所有者 | 
| `wave_cutover_date` | ウェーブプランニング | アプリケーション所有者アンケート | ETL スクリプト – アプリケーション所有者 | 

## ステップ 3: ランブックにメタデータ要件と収集プロセスを文書化する
<a name="metadata-3"></a>

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

1. [ポートフォリオプレイブックテンプレート](samples/portfolio-playbook-templates.zip)で、*メタデータ管理用のランブックテンプレート* (Microsoft Word 形式) を開きます。これは、独自のランブックを構築するための出発点として機能します。

1. *メタデータ属性*セクションで、各移行パターンのメタデータ属性テーブルを作成し、 で識別されるメタデータ属性をテーブルに入力します[ステップ 1: 必要なメタデータを定義する](#metadata-1)。

1. *「ソースの場所*」セクションで、 で識別したソースを文書化します[メタデータソースを分析する](#metadata-2-source)。

1. *「ソースロケーションアクセス手順*」セクションで、メタデータソースロケーションにアクセスするためにユーザーが従う必要があるステップを文書化します。

1. *メタデータストア*セクションで、 で作成したメタデータストアにアクセスするためにユーザーが従う必要があるステップを文書化します[1 つのメタデータストアを定義する](#metadata-2-store)。

1. *「データ収集タイプ*」セクションで、各メタデータソースに使用するデータ収集プロセスを特定します。理想的には、自動化スクリプトを使用してすべてのメタデータ収集を自動化する必要があります。

1. *メタデータ属性によるデータ収集*セクションで、メタデータ属性ごとに、「」の指示に従って以下を特定します[メタデータ収集プロセスを定義する](#metadata-2-collection)。

   1. メタデータタイプ

   1. メタデータソース

   1. メタデータストア

   1. コレクションタイプ

1. *「メタデータの収集*」セクションで、ユースケースに応じてプロセスを更新します。これは、ポートフォリオワークストリームがウェーブのメタデータを収集する際に実装段階で従うプロセスです。

1. ランブックが完全で正確であることを確認します。このランブックは、移行中の信頼できるソースである必要があります。

1. レビューのためにメタデータ管理ランブックをチームと共有します。

## タスク終了条件
<a name="metadata-exit-criteria"></a>

次のタスクを完了したら、次のタスクに進みます。
+ 収集されたメタデータを保存するための 1 つのリポジトリを準備しました。
+ メタデータ管理ランブックでは、以下を定義して文書化しています。
  + 各移行パターンに必要なメタデータ属性
  + メタデータソースと各ソースへのアクセス方法の詳細な手順
  + メタデータストアとそのアクセス方法の詳細な手順
  + メタデータの収集に使用されるプロセス
  + メタデータ属性をメタデータソースとコレクションプロセスにマッピングするマッピングテーブル