View a markdown version of this page

移行計画の変換評価レポートの使用 - AWS データベース移行サービス
合計労力の計算アクション項目の優先順位付けリスクと範囲の評価

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

移行計画の変換評価レポートの使用

変換評価レポートは、データベース移行ジャーニーの最初のステップです。組織は、このレポートを使用して移行の複雑さを評価し、本格的な移行プロジェクトにコミットする前に、情報に基づいた意思決定を行います。

移行の合計労力の計算

Action_Items_Summary CSV ファイルには、労力の見積もりに使用するアクション項目タイプごとに 3 つの値があります。

  • 学習曲線の労力 — 非互換性を理解し、このアクション項目タイプの変換アプローチを設計するための 1 回限りのコスト。このコストは、影響を受けるデータベースオブジェクトの数に関係なく、アクション項目タイプごとに 1 回発生します。

  • 出現を変換する労力 — 変換アプローチを既に設計した後で、このアクション項目の単一の出現を解決するためのコスト。

  • 出現回数 — このアクション項目タイプの影響を受ける個々のデータベースオブジェクトの数。

注記

CSV のエフォート値は、加重スケールの相対単位であり、時間ではありません。人時または人日に変換するには、同様の移行作業におけるチームの過去の速度から算出されたキャリブレーション係数を掛けます。

保守的な上限見積り

最も簡単な見積もりでは、すべての出現を同様に困難として扱います。この式を最悪の場合の上限として使用します。

Effort for one action item type =
    Learning curve effort + (Effort per occurrence × Number of occurrences)

これをすべてのアクション項目タイプに合計して、合計上限見積りを取得します。

Total effort (upper bound) =
    Sum of [ Learning curve effort + (Effort per occurrence × Occurrences) ]
    for every action item type

例えば、Oracle-to-PostgreSQL評価のアクション項目 5028 の学習曲線の労力は 40、1 回あたりの労力は 8、12 回です。上限の合計は 40 + (8 × 12) = 136 です。

現実的なシナリオベースの見積り

上限数式は、すべての出現が同じ量の作業を必要とすると仮定するため、労力を過剰に表現します。実際には、チームがアクション項目タイプの最初の数回の出現を解決すると、その後の出現が速くなります。解決策はわかっており、変換はルーチンです。より現実的なモデルでは、ほとんどの出現が割引されます。

発生を 2 つのグループに分割します。1 つはソリューションの確立中に全力で作業する先導グループで、もう 1 つはパターンが確立されたら半力で解決するグループです。チームの信頼度に基づいて分割を選択します。

Realistic effort for one action item type =
    (Leading% × Occurrences × Effort per occurrence)
  + (Remaining% × Occurrences × (Effort per occurrence ÷ 2))

次の表は、移行チームが選択できる 3 つのシナリオを示しています。

労力推定シナリオ
シナリオ 先頭グループ 残りのグループ どのようなときに使うか
オプティミスティック 10% 90% 経験豊富なチーム、十分に理解されたターゲットエンジン、ほとんどの非互換性は機械的で非常に反復的です。
中 30% 70% 経験レベルが混在しており、一部のアクションアイテムタイプはチームにとって新しい一般的な移行プロジェクトです。
保守的 50% 50% 新しいチーム、このターゲットエンジンへの最初の移行、またはアクション項目は、さまざまなデータベースオブジェクトタイプにまたがります。

例えば、アクション項目 5127 (PostgreSQL で CROSS JOIN を使用するとパフォーマンスが低下する可能性があります」) は 8 回発生し、1 回あたりの労力は 160 です。上限推定値は 16 + (160 × 8) = 1,296 です。中程度のシナリオ (30/70 分割): (0.30 × 8 × 160) + (0.70 × 8 × 80) = 384 + 448 = 832 — 36% の削減。楽観的なシナリオ (10/90 分割): (0.10 × 8 × 160) + (0.90 × 8 × 80) = 128 + 576 = 704 — 46% の削減。

注記

CSV の学習曲線の労力は固定の 1 回限りのコストであり、繰り返しで減少することはありません。シナリオベースの出現コストに加えて、アクション項目タイプごとに 1 回追加します。シナリオ割引は、学習曲線の労力ではなく、発生ごとの労力にのみ適用されます。

現実的な移行作業の合計を計算するには、選択したシナリオをすべてのアクション項目タイプに適用し、結果を合計します。

Total realistic effort =
    Sum of [ Learning curve effort
             + (Leading% × Occurrences × Effort per occurrence)
             + (Remaining% × Occurrences × (Effort per occurrence ÷ 2)) ]
    for every action item type

アクション項目の優先順位付け

各アクション項目の複雑さカテゴリと出現数を使用して、それらを解決する順序を決定します。この方法でアクション項目に優先順位を付けると、移行タイムラインに最も大きな影響を与える作業に最初に対処できます。

  1. 発生数が多い複雑なアクション — 最初にこれらのアクション項目に対処します。発生ごとに最も手動の労力が必要であり、発生数が多いとスキーマ全体でその労力が倍増します。

  2. 中程度の複雑さのアクション — 次のアクション項目に対処します。通常、複雑なアクションよりも変換アプローチを設計するのに必要な労力は少なくなりますが、手動による変換作業も必要になります。

  3. シンプルなアクション — これらのアクション項目に、手動作業を必要とするアクション項目の中で最も低い優先度を与えます。通常、解決に必要な労力は最小限です。

  4. 自動的に変換されたデータベースオブジェクト — これらのデータベースオブジェクトにはアクションは必要ありません。DMS Schema Conversion は、手動操作なしで変換します。

アクション項目の複雑さカテゴリを確認するには、 AWS DMS コンソールでアクション項目タブを表示するか、サマリー CSV ファイルで Objects with simple actions、Objects with medium-complexity actions、および Objects with complex actions列を表示します。アクション項目タイプの出現数を確認するには、CSV ファイルの Action_Items_Summary Number of occurrences列を参照してください。

移行のリスクと範囲の評価

労力の計算と個々のアクション項目の優先順位付けを行うだけでなく、変換評価レポートを使用して移行プロジェクトの全体的なリスクと範囲を評価します。

  • 高リスクのデータベースオブジェクトを特定する — DMS Schema Conversion が中程度の複雑さまたは複雑なアクションで分類するデータベースオブジェクトは、手動変換が必要であり、移行タイムラインに対する最大のリスクを表します。DMS Schema Conversion が自動的に変換されるデータベースオブジェクト、または単純なアクションのみを持つデータベースオブジェクトは、比較的リスクが低くなります。DMS Schema Conversion がこれらのカテゴリを割り当てる方法の詳細については、「」を参照してください複雑さのカテゴリ。

  • 移行の全体的な範囲とタイムラインの見積もり — 概要タブまたは概要 CSV ファイルでデータベースオブジェクト数を使用して、スキーマの手動変換に必要な量を見積もります。中程度の複雑さと複雑なアクションを持つデータベースオブジェクトの数をデータベースオブジェクトの合計数と比較して、移行の全体的な範囲を測定します。このスコープを、計算した移行作業の合計 (「」を参照合計労力の計算) とチームの利用可能なキャパシティと組み合わせて、手動変換作業を完了するためのタイムラインを射影します。

  • 手動変換タスクのシーケンスを計画する — アクション項目タブとアクション項目 CSV ファイルは、各アクション項目タイプに推奨されるアクションを提供します。これらの推奨事項と設定した優先順位 (「」を参照アクション項目の優先順位付け) を使用して、チームがアクション項目を解決する順序を計画します。相互に依存する同じスキーマ内のオブジェクトやデータベースオブジェクトなど、関連するデータベースオブジェクトに影響を与えるアクション項目をグループ化して、チームが関連する問題を一緒に解決できるようにします。