Portfolio AssessmentとDependency分析

前の段階では、

Application Inventory

Infrastructure Inventory

Dependency

Business Requirement

などからCurrent Environmentを把握しました。

しかし、大規模なMigrationでは、

Applicationが100個ある

Serverが800台ある

と分かっただけでは十分ではありません。

必要なのは、

どのApplicationが

どのInfrastructureを使い

どのような利用状況で

何に依存し

Business上どれほど重要なのか

を関連付けることです。

これによって、

単なる資産一覧
↓
Application Portfolio
↓
Migration Candidate

へ情報を変えていきます。

ゴール

このページでは、

Application Portfolio
↓
ApplicationとInfrastructureを関連付ける
↓
Usage Patternを確認
↓
Dependencyを確認
↓
Business Criticalityを確認
↓
Data Gapを把握
↓
Initial Migration Candidateを識別
↓
必要に応じて追加Discovery

というPortfolio Assessmentの流れを理解します。

ここではまだ、

どの7Rを選ぶか

TCOはいくらか

どのWaveで移行するか

までは決定しません。

1. Application PortfolioはApplication名の一覧ではない

Application Portfolioを、

Application A
Application B
Application C

という名前の一覧だけで考えてはいけません。

Portfolio Assessmentで必要なのは、

Application
+
Infrastructure
+
利用状況
+
Dependency
+
Business Context

を関連付けた情報です。

例えば、

販売管理Application

Owner
→ 営業システム部

Environment
→ Production

Infrastructure
→ Web 2台 / App 2台 / DB 1台

Usage
→ 月末高負荷

Dependency
→ 認証 / 会計連携

Business Criticality
→ High

という形です。

これによって初めて、

ApplicationをMigrationの単位として評価しやすくなります。

2. Portfolio Assessmentでは情報を段階的に高精度化する

最初からすべての情報が完全にそろっているとは限りません。

例えば既存CMDBに、

Server名
OS
CPU
Memory

はあっても、

どのApplicationが利用しているか

現在も利用されているか

どのSystemと通信しているか

が不明な場合があります。

そのためPortfolio Assessmentでは、

既存Inventory
↓
Data Gapを確認
↓
追加Discovery
↓
情報を更新
↓
Portfolioを高精度化

という反復的な進め方をします。

重要なのは、

CMDBに値がある
=
現在も正しい

と決めつけないことです。

3. ApplicationとInfrastructureを正しくMappingする

Infrastructure Inventoryは、単独のServer一覧として使うだけではありません。

例えば、

srv001
srv002
srv003
db001

という情報だけでは、

何のApplicationを構成するResourceなのか

が分かりません。

そこで、

Application A
├─ srv001
├─ srv002
└─ db001

Application B
└─ srv003

のように、

InfrastructureをApplicationへMapping

します。

このMappingによって、

Applicationを移行するときに
どのInfrastructureが対象になるか

を把握できます。

4. Shared Infrastructureにも注意する

単純に、

1 Application
=
専用Serverだけ

とは限りません。

例えば、

Application A ─┐
               ├→ Shared Database
Application B ─┘

や、

Application A ─┐
Application B ─┼→ 共通認証System
Application C ─┘

のような構成があります。

この場合、

Application AのServerだけ把握

していても、Migration Scopeを正しく理解できません。

Portfolio Assessmentでは、

専用ResourceとShared Resourceの両方をApplicationとの関係として把握する

必要があります。

5. Usage Patternは割当Capacityだけでは分からない

Infrastructure Inventoryに、

vCPU
Memory
Storage

が記録されていても、

それだけではResourceの実際の使われ方は分かりません。

例えば、

16 vCPU
64 GB Memory

のServerでも、

ほぼ常時低負荷

なのか、

毎月末だけ高負荷

なのかで状況が異なります。

したがって、

Configuration
+
Actual Usage

を分けて確認します。

6. Averageだけを見るとUsage Patternを誤解することがある

例えば、

平均CPU
15%

というServerがあったとします。

これだけを見ると、

あまり使われていない

ように見えるかもしれません。

しかし実際には、

通常日
5〜10%

月末Batch
80〜90%

という可能性があります。

したがってUsage Patternを見るときは、

Average

Peak

時間帯

曜日

月末

Seasonality

など、

代表的な期間の変動

を確認します。

7. 短期間のSnapshotだけで判断しない

例えば3日間だけ測定して、

CPU 10%

Network低負荷

だったとしても、

その3日間が通常期間とは限りません。

月末処理

四半期処理

キャンペーン

繁忙期

などが存在するApplicationでは、

短いSnapshotだけでは実際の利用状況を捉えられない場合があります。

したがって、

Migration Assessmentに使うUsage Dataが代表的な利用状況を含んでいるか

を確認します。

8. Dependencyは「一緒に動いているもの」を明らかにする

Applicationを単独で評価できるとは限りません。

例えば、

Order Application
↓
Customer Database
↓
Authentication
↓
External Payment API

という関係がある場合、

Order Applicationだけを見ても全体は理解できません。

Dependency分析では、

Upstream

Downstream

Internal System

External System

との関係を確認します。

9. Network CommunicationはDependencyを発見する手掛かりになる

既存資料ではDependencyが分からなくても、

実際の通信情報から関係を発見できる場合があります。

例えば、

Server A
→ Server B : TCP/443

Server A
→ Server C : TCP/1521

という通信が継続的に存在すれば、

Application間
または
ApplicationとDatabase間

にDependencyがある可能性があります。

したがって、

Documented Dependency
+
Observed Communication

を照合することが有効です。

10. Technical Dependencyだけではない

Dependencyには、

Network通信
Database接続
File連携
API連携

のようなTechnical Dependencyだけではありません。

例えば、

毎月同じMaintenance Windowで停止する

同じBusiness Processで連続利用される

同じOwnerの承認が必要

といったOperational / Business上のDependencyもあります。

したがってPortfolio Assessmentでは、

通信だけを見てDependency分析が完了したとは考えません。

11. Dependencyが不明ならStandalone Applicationと決めつけない

例えば、

Application A

CPU使用率
低い

構成
単純

だったとしても、

Dependency
未確認

なら、

簡単に単独Migrationできる

とはまだ判断できません。

Dependencyを確認する前にApplicationを独立した単位として扱うと、

共有Databaseを残してしまう

認証連携を切断する

低Latency通信を分離する

などの問題につながる可能性があります。

12. Business CriticalityをPortfolioへ追加する

Technical Dataだけでは、

ApplicationのBusiness上の重要度は分かりません。

例えば、

Application A

小規模
低負荷
構成も単純

ただし
売上決済を担当

Application B

Server多数
高負荷

ただし
社内検証環境

の場合、

Infrastructure規模だけではBusiness Impactを判断できません。

そこで、

Revenueへの影響

Customerへの影響

重要業務か

利用部門

停止許容度

Compliance上の重要性

などからBusiness Criticalityを把握します。

13. Business CriticalityはMigration Strategyそのものではない

ここは重要です。

Business Criticality
=
High

だからといって、

必ず最初にMigration

必ず最後にMigration

必ずRetain

とは決まりません。

Business Criticalityは、

Applicationを評価するための重要な属性の1つ

です。

後続のMigration Planningでは、

Dependency

Migration Complexity

Risk

Business Requirement

など他の条件と組み合わせて使用します。

この段階では、

Criticalityを正しくPortfolioへ記録する

ところまでを扱います。

14. Portfolio全体を同じ深さで最初から分析する必要はない

例えばApplicationが500個ある場合、

最初から500個すべてについて、

詳細Architecture

全通信Flow

詳細Cutover Procedure

まで作成すると、Assessmentだけで大きな時間がかかります。

Portfolio Assessmentでは、

まずPortfolio全体を広く把握
↓
高レベルの属性から候補を絞る
↓
不足Dataを追加Discovery
↓
対象Applicationを
より詳細にAssessment

という進め方ができます。

つまり、

Portfolio Level
=
Breadth

Detailed Application Assessment
=
Depth

という違いがあります。

15. Migration Candidateは「十分な情報がすべてそろったApplication」ではない

Portfolio Assessmentでは、最初から完全なDatasetを待つ必要はありません。

例えば、

Business Driver

Application Owner

Business Criticality

Infrastructure概要

既知のDependency

利用状況

Migration上のConstraint

など、利用可能な高レベル情報から、

次に詳しく評価する価値があるApplication

をInitial Migration Candidateとして識別できます。

したがって、

すべてのDataが完成
↓
初めてCandidate

ではありません。

重要なのは、

Business Driverと利用可能なTechnical / Business属性を使って、初期Candidateを絞り込むこと

です。

16. Data GapはCandidate判断のConfidenceへ影響する

Candidateとして注目すべきApplicationでも、

Dependencyの一部が不明

Owner情報が古い

Usage Dataの期間が短い

といったData Gapが残る場合があります。

このとき、

Data Gapがある
=
Candidateではない

とは判断しません。

代わりに、

Initial Migration Candidate
+
Data Gap
↓
判断Confidenceが低い
↓
追加Discovery
↓
Confidenceを高める

と考えます。

Data completenessは、

Candidateになれるかどうかの絶対条件ではなく、判断の確度を左右する要素

です。

17. Initial Candidateは反復的に見直す

初期Portfolio AssessmentでCandidateを選んでも、その後のDiscoveryで新しい情報が見つかる場合があります。

例えば、

初期Assessment
↓
Application A
Candidate

追加Discovery
↓
重要なShared Database Dependencyを発見

という場合です。

このとき、

最初にCandidateにしたから
そのまま確定

とはしません。

新しい情報
↓
Portfolio更新
↓
Candidate判断を再評価

します。

つまりPortfolio Assessmentは、

Candidateを一度決めて終わる処理ではなく、Data Fidelityの向上に合わせて更新する反復的な活動

です。

18. Migration Candidateだけで7RsやWaveを確定しない

Initial Migration Candidateが識別できても、

Rehost

Replatform

Refactor

Retire

などの最終Strategyが自動的に決まるわけではありません。

また、

Migration Candidate
=
Wave 1

でもありません。

Candidateは、

Initial Migration Candidate
↓
Detailed Assessment
↓
Migration Strategy評価
↓
Migration Planning

へ進める対象です。

7RsやMigration Sequenceは後続の責任として扱います。

19. Current AWSでのDiscovery

現在のAWSでは、新規のDiscovery / AssessmentではAWS TransformのDiscovery Toolを利用できます。

Discoveryによって、

Server Inventory

Configuration

Utilization

Database

Network Connection

などを収集し、Portfolio Assessmentに利用できます。

また、既存のCMDBやDiscovery Toolから取得したInventoryをAssessmentへ取り込む方法もあります。

重要なのは特定Toolの操作ではなく、

既存Data
+
Programmatic Discovery
↓
Data Gapを減らす
↓
Application Portfolioを高精度化

という使い方です。

20. Portfolio Assessmentの全体フロー

全体をまとめると、

既存Inventory
↓
Application Portfolioを作成
↓
Application
↕
Infrastructure Mapping
↓
Usage Pattern
↓
Dependency
↓
Business Criticality
↓
Business Driverと
高レベル属性から
Initial Migration Candidateを識別
↓
Data Gap / Confidenceを確認
↓
必要に応じて追加Discovery
↓
PortfolioとCandidateを再評価
↓
Detailed Assessmentへ

となります。

混同ポイント

SAP-C02での判断

Portfolio AssessmentのScenarioでは、

Application Portfolioはある？
↓
InfrastructureとMappingされている？
↓
Usage Patternは代表的？
↓
Dependencyは把握できている？
↓
Business Criticalityは分かっている？
↓
Business Driverは？
↓
Initial Migration Candidateは？
↓
Data Gap / Confidenceは？
↓
追加Discoveryが必要？

と考えます。

決定打は、

Applicationを単なるServer一覧として扱わず、Technical / Business属性を関連付け、完全なDatasetを待たずにInitial Migration Candidateを識別し、Data Gapを追加Discoveryで段階的に減らすこと

です。

まとめ

Portfolio Assessmentでは、

Application
+
Infrastructure
+
Usage
+
Dependency
+
Business Criticality

を関連付けます。

Infrastructure Inventoryは、

Serverが存在する

ことを確認するだけではなく、

どのApplicationを構成しているか

までMappingします。

Usage Patternでは、

Averageだけ

ではなく、

Peak

時間変動

周期的変動

を確認します。

Dependencyでは、

Technical Dependency
+
Operational / Business Dependency

を考えます。

そのうえで、

Business Driver
+
高レベルのTechnical / Business属性
↓
Initial Migration Candidate
↓
Data Gap / Confidence
↓
追加Discovery
↓
Detailed Assessment

へ進みます。

Migration Candidateは最終的な7RsやMigration Waveを意味しません。

また、すべての情報が完成するまでCandidateを選べないわけでもありません。

初期Candidateを識別し、PortfolioのData Fidelity向上に合わせて判断を継続的に更新する

ことがPortfolio Assessmentの役割です。