View a markdown version of this page

タスク 2: メタデータを識別、収集、保存するためのプロセスを定義する - AWS 規範ガイダンス

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

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

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

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

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

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

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

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

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

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

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

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

  1. アクション – 移行戦略またはサポートタスクを特定します。1 つのアクションには、他のアクションが関連付けられている可能性があることに注意してください。たとえば、移行のオペレーションを定義できます。アクションの例は次のとおりです。

    • リホスト、リプラットフォーム、再配置などの移行戦略

    • ウェーブプランニング

    • アプリケーションの優先順位付けと依存関係の分析

    • 運用

    • ガバナンス

    • ディザスタリカバリ

    • パフォーマンステストやユーザー受け入れテスト (UAT) などのテスト

  2. ソースオブジェクト – アクションが実行されるソースオブジェクトを識別します。ソースオブジェクトの例は次のとおりです。

    • ウェーブ

    • サーバー

    • データベース

    • ファイル共有

    • アプリケーション

  3. ツール – アクションを実行するために使用されるサービスまたはツールを特定します。複数のツールまたはサービスを使用できます。ツールの例は次のとおりです。

    • AWS Transform MGN

    • AWS DataSync

    • AWS Database Migration Service (AWS DMS)

    • AWS Backup

    • パフォーマンスモニタリングツール

  4. ターゲットオブジェクト – アクションの完了時にソースが存在するターゲットオブジェクト、サービス、または場所を特定します。オブジェクト、サービス、または場所の例は次のとおりです。

    • Amazon Elastic Compute Cloud (Amazon EC2)

    • Amazon Relational Database Service (Amazon RDS)

    • Amazon Elastic File System (Amazon EFS)

    • Amazon Elastic Container Service (Amazon ECS)

    • ウェーブプラン

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

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

    次に例を示します。

    • MGN または Cloud Migration Factory (ツール) を使用して Amazon EC2 (ターゲットオブジェクト) にウェーブ、アプリケーション、またはサーバー (ソースオブジェクト) をリホスト (アクション) する

    • DataSync (ツール) を使用して Amazon EFS (ターゲットオブジェクト) にファイル共有 (アクション) をリプラットフォームする

    • (ツール) を使用して (アクション) データベース (ソースオブジェクト) を Amazon RDS (ターゲットオブジェクト) にリプラットフォーム AWS DMS する

    • Amazon CloudWatch (ツール) を使用した Amazon EC2 (ターゲットオブジェクト) 上のアプリケーション (ソースオブジェクト) のパフォーマンスモニタリング (アクション)

    • 移行後に (ツール) を使用して AWS Backup Amazon EC2 (ターゲットオブジェクト) で (アクション) サーバー (ソースオブジェクト) をバックアップする

    • ウェーブプランを作成するためのウェーブプランニング (アクション) ウェーブ、アプリケーション、またはサーバー (ソースオブジェクト) (ターゲットオブジェクト)

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

Pattern ID

1

Pattern name

MGN または Cloud Migration Factory を使用して Amazon EC2 にリホストする

Action

リホスト移行

Source object

ウェーブ、アプリケーション、またはサーバー

Tools

MGN または Cloud Migration Factory

Target object

Amazon EC2

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

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

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

    たとえば、EC2 インスタンスを作成するときは、インスタンスタイプ、ストレージタイプ、ストレージサイズ、サブネット、セキュリティグループ、タグを選択する必要があります。次の表に、ターゲットオブジェクトが EC2 インスタンスの場合に必要なメタデータ属性の例を示します。

    属性名 オブジェクトの種類 説明または目的

    target_subnet

    ターゲット EC2 インスタンス

    ターゲット EC2 インスタンスのサブネット

    target_subnet_test

    ターゲット EC2 インスタンス

    ターゲット EC2 インスタンスのテストサブネット

    target_security_group

    ターゲット EC2 インスタンス

    ターゲット EC2 インスタンスのセキュリティグループ

    target_security_group_test

    ターゲット EC2 インスタンス

    ターゲット EC2 インスタンスのセキュリティグループをテストする

    IAM_role

    ターゲット EC2 インスタンス

    AWS Identity and Access Management ターゲット EC2 インスタンスの (IAM) ロール

    instance_type

    ターゲット EC2 インスタンス

    ターゲット EC2 インスタンスのインスタンスタイプ

    AWS_account_ID

    ターゲット EC2 インスタンス

    AWS ターゲット EC2 インスタンスをホストする アカウント

    AWS_Region

    ターゲット EC2 インスタンス

    AWS ターゲット EC2 インスタンスをホストするリージョン

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

    次の表に、ツールに必要なメタデータの例を示します。

    属性名 オブジェクトの種類 説明または目的

    AWS_account_ID

    ツール (MGN)

    AWS の アカウント ID AWS Transform MGN

    AWS_Region

    ツール (MGN)

    AWS MGN のリージョン

    replication_server_subnet

    ツール (MGN)

    MGN レプリケーションサーバーのサブネット

    replication_server_security_group

    ツール (MGN)

    MGN レプリケーションサーバーのセキュリティグループ

  3. ソースオブジェクトを分析する – 次のようにアクションを評価して、ソースオブジェクトに必要なメタデータを決定します。

    • サーバーを移行するには、サーバーに接続するために、ソースサーバー名と完全修飾ドメイン名 (FQDN) を知る必要があります。

    • サーバーとともにアプリケーションを移行するには、アプリケーション名、アプリケーション環境、およびapplication-to-server間のマッピングを知る必要があります。

    • ポートフォリオ評価の実行、アプリケーションの優先順位付け、または移動グループの定義を行うには、application-to-server間のマッピング、application-to-databaseマッピング、およびapplication-to-application依存関係を把握しておく必要があります。

    • ウェーブを管理するには、ウェーブ ID とウェーブの開始時刻と終了時刻を知る必要があります。

    次の表に、ソースオブジェクトに必要なメタデータの例を示します。

    属性名 オブジェクトの種類 説明または目的

    wave_ID

    ソースウェーブ

    ウェーブの ID (ウェーブ 10 など)

    wave_start_date

    ソースウェーブ

    ウェーブの開始日

    wave_cutover_date

    ソースウェーブ

    ウェーブのカットオーバー日

    wave_owner

    ソースウェーブ

    ウェーブの所有者

    app_name

    ソースアプリケーション

    ソースアプリケーション名

    app_to_server_mapping

    ソースアプリケーション

    Application-to-server関係

    app_to_DB_mapping

    ソースアプリケーション

    Application-to-database関係

    app_to_app_dependencies

    ソースアプリケーション

    アプリケーションの外部依存関係

    server_name

    ソースサーバー

    ソースサーバー名

    server_FQDN

    ソースサーバー

    ソースサーバーの完全修飾ドメイン名

    server_OS_family

    ソースサーバー

    ソースサーバーのオペレーティングシステム (OS) ファミリー (Windows や Linux など)

    server_OS_version

    ソースサーバー

    ソースサーバーの OS バージョン (Windows Server 2003 など)

    server_environment

    ソースサーバー

    ソースサーバーの環境 (開発、本番稼働、テストなど)

    server_tier

    ソースサーバー

    ソースサーバーの階層 (ウェブ、データベース、アプリケーションなど)

    CPU

    ソースサーバー

    ソースサーバー内の CPUs の数

    RAM

    ソースサーバー

    ソースサーバーの RAM サイズ

    disk_size

    ソースサーバー

    ソースサーバーのディスクサイズ

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

    次の表に、一般的に使用される追加のメタデータの例を示します。このテーブルには、ターゲット EC2 インスタンスのタグが含まれています。タグとその使用方法の詳細については、Amazon EC2 ドキュメントの「Amazon EC2 リソースのタグ付け」を参照してください。 Amazon EC2

    属性名 オブジェクトの種類 説明または目的

    Name

    ターゲット EC2 インスタンス (タグ)

    ターゲット EC2 インスタンスの名前を定義するタグ

    app_owner

    ソースアプリケーション

    ソースアプリケーションの所有者

    business_unit

    ターゲット EC2 インスタンス (タグ)

    ターゲット EC2 インスタンスのビジネスユニットを識別するタグ (人事、財務、IT など)

    cost_center

    ターゲット EC2 インスタンス (タグ)

    ターゲット EC2 インスタンスのコストセンターを識別するタグ

  5. テーブルの作成 – 前のステップで特定したすべてのメタデータを 1 つのテーブルに結合します。

    属性名 オブジェクトの種類 説明または目的

    wave_ID

    ソースウェーブ

    ウェーブの ID (ウェーブ 10 など)

    wave_start_date

    ソースウェーブ

    ウェーブの開始日

    wave_cutover_date

    ソースウェーブ

    ウェーブのカットオーバー日

    wave_owner

    ソースウェーブ

    ウェーブの所有者

    app_name

    ソースアプリケーション

    ソースアプリケーション名

    app_to_server_mapping

    ソースアプリケーション

    Application-to-server関係

    app_to_DB_mapping

    ソースアプリケーション

    Application-to-database関係

    app_to_app_dependencies

    ソースアプリケーション

    アプリケーションの外部依存関係

    AWS_account_ID

    ツール (MGN)

    AWS ターゲット EC2 インスタンスをホストする アカウント

    AWS_Region

    ツール (MGN)

    AWS ターゲット EC2 インスタンスをホストするリージョン

    replication_server_subnet

    ツール (MGN)

    MGN レプリケーションサーバーのサブネット

    replication_server_security_group

    ツール (MGN)

    MGN レプリケーションサーバーのセキュリティグループ

    server_name

    ソースサーバー

    ソースサーバー名

    server_FQDN

    ソースサーバー

    ソースサーバーの完全修飾ドメイン名

    server_OS_family

    ソースサーバー

    ソースサーバーのオペレーティングシステム (OS) ファミリー (Windows や Linux など)

    server_OS_version

    ソースサーバー

    ソースサーバーの OS バージョン (Windows Server 2003 など)

    server_environment

    ソースサーバー

    ソースサーバーの環境 (開発、本番稼働、テストなど)

    server_tier

    ソースサーバー

    ソースサーバーの階層 (ウェブ、データベース、アプリケーションなど)

    CPU

    ソースサーバー

    ソースサーバー内の CPUs の数

    RAM

    ソースサーバー

    ソースサーバーの RAM サイズ

    disk_size

    ソースサーバー

    ソースサーバーのディスクサイズ

    target_subnet

    ターゲットサーバー

    ターゲット EC2 インスタンスのサブネット

    target_subnet_test

    ターゲットサーバー

    ターゲット EC2 インスタンスのテストサブネット

    target_security_group

    ターゲットサーバー

    ターゲット EC2 インスタンスのセキュリティグループ

    target_security_group_test

    ターゲットサーバー

    ターゲット EC2 インスタンスのセキュリティグループをテストする

    instance_type

    ターゲットサーバー

    ターゲット EC2 インスタンスのインスタンスタイプ

    IAM_role

    ターゲットサーバー

    AWS Identity and Access Management ターゲット EC2 インスタンスの (IAM) ロール

    Name

    ターゲットサーバー (タグ)

    ターゲット EC2 インスタンスの名前を定義するタグ

    app_owner

    ソースアプリケーション

    ソースアプリケーションの所有者

    business_unit

    ターゲットサーバー (タグ)

    ターゲット EC2 インスタンスのビジネスユニットを識別するタグ (人事、財務、IT など)

    cost_center

    ターゲットサーバー (タグ)

    ターゲット EC2 インスタンスのコストセンターを識別するタグ

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

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

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

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

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

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

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

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

メタデータソース コレクションタイプ メタデータタイプ

Discovery tools

自動

ソースサーバー

CMDB

自動

ソースサーバー

RVTools など、他のツールからのインベントリ VMware vSphere

自動

ソースサーバー

アプリケーション所有者アンケート

手動

ソースサーバー、ターゲットサーバー、ウェーブ

アプリケーション所有者のインタビュー

手動

ソースサーバー、ターゲットサーバー、ウェーブ

アプリケーション設計ドキュメント

手動

ターゲットサーバー

ランディングゾーン設計ドキュメント

手動

ターゲットサーバー、ツール

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

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

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

  3. 各メタデータ属性を分析し、前の表のメタデータソースにマッピングします。複数のソースの組み合わせを持つことが一般的です。検出ツールを使用して、ソースサーバーメタデータを収集できます。検出ツールを使用してメタデータを収集する方法については、 AWS 「 規範ガイダンス」ウェブサイトの「自動ポートフォリオ検出の開始方法」を参照してください。

  4. メタデータ属性をタイプとソースにマッピングするテーブルを作成します。次の表は例です。

    Metadata 属性 メタデータタイプ メタデータソース

    app_name

    ソースアプリケーション

    CMDB

    app_owner

    ソースアプリケーション

    CMDB

    app_to_server_mapping

    ソースアプリケーション

    CMDB、検出ツール、またはアプリケーション所有者アンケート

    app_to_DB_mapping

    ソースアプリケーション

    CMDB、検出ツール、またはアプリケーション所有者アンケート

    app_to_app_dependencies

    ソースアプリケーション

    CMDB、検出ツール、またはアプリケーション所有者アンケート

    server_name

    ソースサーバー

    CMDB

    server_FQDN

    ソースサーバー

    CMDB

    server_OS_family

    ソースサーバー

    CMDB

    server_IP

    ソースサーバー

    Discovery tools

    disk_size

    ソースサーバー

    Discovery tools

    instance_type

    ターゲットサーバー

    Discovery tools

    target_subnet

    ターゲットサーバー

    アプリケーション所有者アンケート

    target_security_group

    ターゲットサーバー

    アプリケーション所有者アンケート

    AWS_Region

    ターゲットサーバー

    アプリケーション所有者アンケート

    AWS_account_ID

    ターゲットサーバー

    アプリケーション所有者アンケート

    replication_server_subnet

    ツール (MGN)

    ランディングゾーン設計ドキュメント

    replication_server_security_group

    ツール (MGN)

    ランディングゾーン設計ドキュメント

    Name

    ターゲットサーバー (タグ)

    アプリケーション所有者アンケート

    business_unit

    ターゲットサーバー (タグ)

    アプリケーション所有者アンケート

    cost_center

    ターゲットサーバー (タグ)

    アプリケーション所有者アンケート

    wave_ID

    ウェーブプランニング

    アプリケーション所有者のインタビュー

    wave_start_date

    ウェーブプランニング

    アプリケーション所有者のインタビュー

    wave_cutover_date

    ウェーブプランニング

    アプリケーション所有者のインタビュー

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

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

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

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

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

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

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

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

  • サーバーテーブル

  • アプリケーションテーブル

  • データベーステーブル

  • Application-to-server および application-to-database マッピングテーブル

  • Wave-planning テーブル

  • アプリケーション所有者アンケートテーブル

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

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

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

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

  3. エクスポートプロセスを構築するか、リポジトリに保存されているメタデータへのアプリケーションプログラミングインターフェイス (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: メタデータ要件と収集プロセスをランブックに記録する

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

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

  2. メタデータ属性セクションで、移行パターンごとにメタデータ属性テーブルを作成し、 で識別されるメタデータ属性をテーブルに入力しますステップ 1: 必要なメタデータを定義する

  3. 「ソースの場所」セクションで、 で特定したソースを文書化しますメタデータソースを分析する

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

  5. メタデータストアセクションで、 で作成したメタデータストアにアクセスするためにユーザーが従う必要があるステップを文書化します1 つのメタデータストアを定義する

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

  7. メタデータ属性によるデータ収集セクションで、メタデータ属性ごとに、「」の指示に従って以下を特定しますメタデータ収集プロセスを定義する

    1. メタデータタイプ

    2. メタデータソース

    3. メタデータストア

    4. コレクションタイプ

  8. 「メタデータの収集」セクションで、ユースケースに応じてプロセスを更新します。これは、ポートフォリオワークストリームがウェーブのメタデータを収集するときに実装ステージで実行するプロセスです。

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

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

タスク終了条件

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

  • 収集されたメタデータを保存するための 1 つのリポジトリを準備しました。

  • メタデータ管理ランブックでは、以下を定義して文書化しています。

    • 各移行パターンに必要なメタデータ属性

    • メタデータソースと各ソースへのアクセス方法の詳細な手順

    • メタデータストアとそのアクセス方法の詳細な手順

    • メタデータの収集に使用されるプロセス

    • メタデータ属性をメタデータソースとコレクションプロセスにマッピングするマッピングテーブル