クラウド移行評価ツール：インフラストラクチャの検出が作業の半分に過ぎない理由

ほとんどのクラウド移行プログラムは、インフラストラクチャのスキャンから始まります。Azure Migrateが仮想マシンを検出し、AWS Application Discovery Serviceがサーバーをマッピングし、Google Migration Centerがワークロードをインベントリします。数日のうちに、チームは各サーバー、そのCPU使用率、メモリ使用量、およびターゲットクラウドで同等の構成を実行するための推定コストを記載したスプレッドシートを入手します。インフラストラクチャの評価は完了です。計画を開始できます。

しかし、それは不可能です。インフラストラクチャインベントリは、アプリケーションがどのハードウェアで実行されているかを示すものであり、それらのアプリケーションがクラウドで実行できるかどうか、クラウドで実行できるように変更するのにどれくらいの費用がかかるか、移行時に依存関係が壊れるアプリケーションはどれか、クラウドプラットフォームがサポートしていない非推奨のAPIに対して記述されているアプリケーションはどれか、あるいは変換を検証する前に理解する必要がある10年間文書化されていないビジネスロジックが含まれているアプリケーションはどれかを示すものではないからです。インフラストラクチャの検出は、クラウド移行評価の前提条件であり、評価そのものではありません。

クラウド移行アセスメントとは何ですか？

クラウド移行評価とは、一連のワークロードをクラウドに移行できるかどうか、どのように移行できるか、そしてどのくらいのコストがかかるかを判断するための構造化された分析です。この評価によって、次の3つの決定を下すための根拠が得られます。各ワークロードにどの移行戦略を適用するか、移行にかかる労力とクラウド費用は実際にどのくらいかかるか、そして依存関係のリスクを管理するためにワークロードをどのような順序で移行すべきか、ということです。

クラウド移行の包括的な評価は、5つの異なる側面から構成されます。インフラストラクチャ検出ツールは、そのうちの1つに対応します。残りの4つについては、それぞれ異なるツール、手法、専門知識が必要です。

評価の次元	回答内容	主なツール
インフラ	どのようなサーバー、仮想マシン、サービスが存在しますか？それらの利用状況はどうなっていますか？	Azure Migrate、AWS Application Discovery、Google Migration Center
アプリケーションコード	このコードはクラウドターゲットと互換性がありますか？変更が必要な箇所は何ですか？	キャストハイライト、 SMART TS XLCloudPilot、GitHub Copilotアプリの近代化
Rescale データ	データ量はどのくらいか？データはどこに保存されているか？データ移行の複雑さとコンプライアンス上の制約は何か？	AWS Database Migration Service、Azure Database Migration Service、Striim
セキュリティとコンプライアンス	どのような規制要件が適用されますか？どのようなセキュリティ上の脆弱性がありますか？どのようなIAM（アイデンティティおよびアクセス管理）および暗号化の変更が必要ですか？	AWS Security Hub、Microsoft Defender for Cloud、Prisma Cloud
コストとTCO	移行にかかる総費用と、移行後の所有にかかる総費用はいくらですか？	AWS料金計算ツール、Azure TCO計算ツール、インフラコスト、Apptio Cloudability

インフラストラクチャの側面のみを運営する組織は、範囲が不明確な移行計画を作成します。そして、アプリケーション、データ、セキュリティ、コストに関する予期せぬ問題が移行中に発覚し、その対応コストが最も高くなるのです。

クラウド移行評価の5つの側面

インフラストラクチャの評価

インフラストラクチャ評価は出発点です。これは、ソース環境、つまりすべてのサーバー、仮想マシン、コンテナ、サービス、それらの構成、利用状況データ、および他のインフラストラクチャコンポーネントとの依存関係を一覧化します。

Azure Migrateなどのツールやその他の製品は、ワークロードのコンポーネントと構成の検出を自動化します。これらのツールは手作業を削減し、環境全体で一貫したデータ収集を実現しますが、文書化されていない依存関係を見落とす可能性があります。

Azure Migrateは、Azureへの移行を検討している組織にとって標準的なツールです。VMware vSphere、Hyper-V、および物理サーバー環境をエージェントレスで検出し、ワークロードの移行を開始する前に、準備状況の評価、パフォーマンスに基づいた適切なサイジングの推奨事項、およびコスト見積もりを提供します。

AWS Application Migration Service (MGN)とAWS Application Discovery Service は、 AWS ターゲットに対して同等の機能を提供します。Discovery Service は、エージェントレス収集またはローカルにインストールされたエージェントを通じて、オンプレミスの構成データとパフォーマンスデータを収集します。

Google Migration Centerは、Google Cloudへの移行に関する統合的な検出と評価を提供し、資産インベントリ、依存関係分析、TCOモデリングを単一のコンソールに統合します。

インフラストラクチャツールが生成するもの：サーバーインベントリ、利用率のベースライン、インフラストラクチャコンポーネント間のネットワーク依存関係マップ、およびターゲットクラウドティアの適切なサイジングに関する推奨事項。これらのツールが生成しないもの：それらのサーバー上で実行されているアプリケーションがクラウドと互換性があるかどうか、コードの変更にかかるコスト、またはそれらのアプリケーション内のデータがどのように移行されるかについての洞察。

アプリケーションコード評価

アプリケーションコードの評価では、移行の成功に影響を与える可能性のある互換性の問題や最新化の機会を特定します。この評価は、アプリケーションが Azure で確実に動作し、移行の段階を効果的に計画するために不可欠です。アプリケーションコードを評価することで、障害を早期に検出し、移行失敗のリスクを軽減し、ターゲットアーキテクチャの決定に役立てることができます。

アプリケーションコードの評価では、インフラストラクチャスキャンでは検出できない4つのカテゴリの問題が見つかりました。

互換性を阻害する要因、つまり、ターゲットのクラウド環境に存在しない、または動作が異なるAPI、フレームワーク、またはランタイム機能。ターゲットのPaaSサービスで利用できないJava EEアプリケーションサーバー向けに構築されたJavaアプリケーションは、デプロイ前にコードの変更が必要です。Windows固有のファイルパス規則を使用するアプリケーションは、変更なしではLinuxベースのクラウドインスタンス上で実行できません。

コードにハードコーディングされたインフラストラクチャに関する前提条件、IPアドレス、ファイルシステムパス、サーバー名、ポート番号などは、クラウド環境では無効になります。これらはアプリケーションコード内にあり、インフラストラクチャ構成には含まれていないため、インフラストラクチャスキャンでは検出できない移行の阻害要因となります。

非推奨のAPIの使用とは、対象となるクラウド環境がサポートしていない、または既に廃止されているAPI、ライブラリ、またはプラットフォーム機能への呼び出しを指します。クラウドプラットフォームプロバイダーは定期的に古いAPIバージョンを非推奨にしており、それらを使用するアプリケーションは、現在正しく動作していても、新しいプラットフォームでは動作しなくなります。

依存関係の複雑さとは、アプリケーションの内部構造であり、移行の難易度や、独立してデプロイ可能なサービスに分割できるかどうかを決定します。インフラストラクチャのインベントリの内容に関わらず、内部結合度の高いモノリシックなアプリケーションは、疎結合なアプリケーションよりも移行が難しく、コストも高くなります。

CAST Highlightは、ポートフォリオレベルのアプリケーションコード評価を自動化し、複数の言語にわたるソースコードをスキャンして、クラウド対応スコア、阻害要因の特定、オープンソースリスク分析を生成します。MicrosoftのAzureクラウド導入フレームワークでは、.NETおよびJava以外のワークロード向けに推奨されるツールとして参照されています。

CloudPilotは、JavaScript、Python、Node.js、Goにおける互換性スコアリングと移行ロードマップ生成を含む、詳細なクラウド対応状況評価を専門としています。

GitHub Copilot App Modernizationは、 CASTのAppCAT評価機能と、.NETおよびJavaワークロードに特化したAI支援によるコード修復機能を組み合わせたものです。

COBOL、JCL、PL/I、RPGなどのメインフレーム言語と最新のスタックが混在するエンタープライズ環境では、これらのツールは対応していません。レガシーシステムのアプリケーションコード評価には、全く異なる種類のツールが必要です。

データ評価

データ評価では、対象となるすべてのデータストアについて、複雑さ、データ量、コンプライアンス要件、および移行方法を決定します。データベースを移動し、データを移動するだけで済むように見えるため、実際の複雑さが明らかになるまで、データ評価の重要性が過小評価されがちです。

データ評価が答えなければならない重要な質問：

ボリュームとスループット：データ量はどれくらいか？変化率はどのくらいか？ダウンタイムなしで移行できるか、それともダウンタイムをほぼゼロに抑えるために継続的なレプリケーションを使用する必要があるか？

スキーマの互換性：移行先のデータベースサービスは、ソースと同じスキーマ機能、データ型、ストアドプロシージャをサポートしていますか？Oracle固有のPL/SQL構文は、PostgreSQLまたはクラウドネイティブの代替サービスに移行する前に変換する必要があります。

データ主権とコンプライアンス：データは法律上どこに保存されるべきか？GDPR、HIPAA、PCI-DSS、および業界固有の規制により、特定のデータカテゴリをホストできるクラウドリージョンが制限される場合があります。

アプリケーションの結合度：アプリケーションコードは、特定のデータベーススキーマにどの程度密接に結合しているか？技術的には単純なスキーマ変更であっても、それに対応するためにアプリケーションコードの大幅な変更が必要になる場合がある。

AWS Database Migration ServiceとAzure Database Migration Serviceは、同種移行（OracleからOracle、SQL ServerからSQL Server）における最小限のダウンタイムでの継続的なレプリケーションと、異種移行（OracleからPostgreSQL、SQL ServerからAurora）におけるスキーマ変換をサポートしています。

StriimとAttunityは、データベースのダウンタイムが許容されない高可用性移行シナリオ向けに、リアルタイムのデータストリーミングとレプリケーションを提供します。

セキュリティおよびコンプライアンス評価

セキュリティ評価では、各ワークロードの現在のセキュリティ状況を把握し、クラウドセキュリティ標準、コンプライアンスフレームワーク、およびゼロトラストアーキテクチャの原則を満たすために必要な変更点を特定します。

セキュリティ評価で網羅すべき事項は以下のとおりです。

IDおよびアクセス管理（IAM）：オンプレミスアプリケーションでは、多くの場合、広範な権限を持つサービスアカウントとパスワード認証が使用されます。クラウド環境では、ロールベースのアクセス制御、最小権限のサービスID、証明書またはトークンベースの認証が必要です。現状のIAMと必要なIAMとのギャップを埋めるには、インフラストラクチャのインベントリとは無関係な移行作業が必要となります。

暗号化：保存データと転送データの暗号化要件は、オンプレミス環境とクラウド環境で異なります。アプリケーション層で独自の暗号化を管理するアプリケーションは、クラウド鍵管理サービスと統合する必要があります。プライベートネットワークでは許容される暗号化されていないデータストアは、クラウドホスト型サービスに移行する前に暗号化する必要があります。

ネットワークセキュリティ：オンプレミスのネットワークハードウェアで実装されていたファイアウォールルール、ネットワークセグメンテーション、トラフィック検査は、クラウドセキュリティグループ、仮想ネットワーク構成、クラウドネイティブファイアウォールルールとして再構築する必要があります。

コンプライアンスフレームワークとの整合性：規制対象となる各業界には、特定のクラウド構成に対応する固有のコンプライアンス要件があります。HIPAAワークロードでは、ストレージ、アクセスログ、暗号化に関して特定の構成選択が必要です。PCI-DSSではネットワークセグメンテーションが求められますが、これは物理ネットワークインフラストラクチャとは異なる方法でクラウドVPCに実装する必要があります。

Microsoft Defender for Cloudは、Azureワークロードに対して、CISベンチマーク、NIST、PCI-DSS、およびその他のフレームワークに準拠したセキュリティ態勢評価とコンプライアンス評価を提供します。

Prisma Cloud（Palo Alto Networks）とAWS Security Hubは、同等のマルチクラウドセキュリティ評価およびコンプライアンス監視機能を提供します。

コストとTCOの評価

コスト評価は、ビジネス関係者にとって最も目に見える移行成果物であると同時に、最も頻繁に誤って作成されるものでもあります。よくある間違いは、現在のオンプレミスハードウェアのコストとクラウドコンピューティングおよびストレージのコストを比較することです。これは不完全で、通常は誤解を招く比較となります。

包括的なTCO評価には以下が含まれます。

クラウドインフラストラクチャのコスト：対象となるクラウド構成におけるコンピューティング、ストレージ、ネットワーク、およびマネージドサービスのコスト。実際の利用データ（プロビジョニングされた容量ではなく）に基づいて適切なサイジングを行うことが、正確な見積もりと過大な見積もりの​​違いを生み出します。

移行作業コスト：アプリケーションコードの変更、データ移行、セキュリティ再構成、およびテストを完了するために必要なエンジニアリング時間。インフラストラクチャのみの評価では、アプリケーションの複雑さが把握できないため、このコストを過小評価する傾向があります。

ライセンスの変更：永続的なオンプレミスライセンスからクラウドベースのライセンスモデルへの移行、あるいはベンダー固有のソフトウェアからクラウドネイティブな代替製品への移行は、ライセンスのコスト構造を根本的に変化させます。

運用モデルの変更：物理ハードウェアを管理するオンプレミス運用チームが、クラウドサービスを管理するクラウド運用チームに置き換えられます。必要なスキル、ツール、人員構成も変化します。

トレーニングと移行にかかる費用：新しいクラウドプラットフォーム、新しい導入モデル、新しい運用手順を習得するチームは、移行期間中に生産性低下によるコストを負担する。

AWS 料金計算ツール、Azure TCO 計算ツール、Google Cloud 料金計算ツールは、クラウドインフラストラクチャのコスト面に対応しています。Infracostは、IaC パイプラインに統合されたコスト見積もりを提供し、CI/CD プロセスの一部としてコスト見積もりを生成します。Apptio Cloudabilityや同様の FinOps ツールは、移行後の継続的なコスト可視化を実現します。

7つの移住戦略：評価によってどの戦略が適用されるかを判断する方法

「7つのR」フレームワークは、ワークロード移行ごとに利用可能な戦略を説明するものです。評価によって適切な戦略が決定されますが、評価を誤ると誤った戦略が適用されることになり、これが移行コスト超過の根本原因となります。

Strategy	その意味	評価シグナルが示唆する
再ホスト （リフトアンドシフト）	コード変更なしでクラウドへ移行	アプリケーションの複雑性が低く、互換性の阻害要因がなく、インフラストラクチャとの互換性がある
リプラットフォーム	クラウドサービスを活用するための軽微な変更（例：マネージドデータベースへの移行）	適度な結合、特定のプラットフォームのアップグレード機会、許容可能なコード変更範囲
リファクタリング	クラウドネイティブパターン（マイクロサービス、コンテナ）に対応したアーキテクチャの再設計	高いモノリシック結合度、高い拡張性要件、予想されるトラフィック増加によって正当化される
再設計	アプリケーションアーキテクチャの大幅な再設計	アプリケーションはクラウドと根本的に互換性がないが、新しいアーキテクチャは大きなビジネス上のメリットをもたらす
復興	ゼロから書き直す	塗布箇所は経済的に修復不可能な状態であり、修復よりも交換の方が安価である。
交換する	カスタムアプリケーションを廃止し、SaaSの代替ソリューションを採用する	このアプリケーションは、既存のクラウドサービスでより適切に提供される汎用的な機能を提供します。
引退	廃止されたため、アプリケーションは不要になりました。	評価中に、アプリケーションが無効、重複、または廃止されたと判断されました。

インフラストラクチャインベントリでは、リホスト、リプラットフォーム、リファクタリング、リビルドの候補を区別することはできません。インフラストラクチャ層では、これらはすべて同じように見えます。この区別を可能にするのは、アプリケーションコードの評価です。

レガシーシステムおよびメインフレームシステムのクラウド移行評価

標準的なクラウド移行評価ツールは、仮想マシン、コンテナ、マイクロサービス、クラウドネイティブアプリケーションといった最新のインフラストラクチャ向けに設計されています。そのため、メインフレームのワークロード、IBM z/OS上で動作するCOBOLプログラム、バッチ処理を管理するJCLジョブストリーム、金融取引を処理するPL/Iアプリケーション、AS/400システムに組み込まれたRPGプログラムなどに対しては、性能が低下したり、全く機能しなかったりします。

メインフレームのクラウド移行評価には、根本的に異なるアプローチが必要です。なぜなら、制約となるのはインフラストラクチャ層ではなく、アプリケーションコード、数十年にわたって蓄積されたビジネスロジック、共有データセットやコピーブックを介した暗黙の依存関係、そしてインフラストラクチャのスキャンでは明らかにできないランタイム動作だからです。

メインフレーム移行を責任を持って計画する前に必要な8つの分析、すなわちプログラムインベントリ、依存関係マッピング、ビジネスロジック抽出、デッドコード特定、複雑性分類、バッチスケジューリング分析、データ品質評価、および統合マッピングについては、メインフレーム移行のリスク低減という観点から詳細に説明されています。これらはそれぞれコードレベルの評価活動であり、インフラストラクチャの評価活動ではありません。

クラウド移行評価ツールの比較

以下の表は、主要なクラウド移行評価ツールと、それらが対象とする評価項目、および最適なシナリオを対応付けたものです。

ツール	評価レイヤー	クラウド ターゲット	以下のためにベスト
Azure 移行	インフラ	Azure	VMとサーバーの検出、適切なサイジング、Azureのコスト見積もり
AWS アプリケーション検出サービス	インフラ	AWS	AWS移行のためのオンプレミスサーバーの検出
Google移行センター	インフラ	GCP	GCP移行における資産インベントリとTCO
キャストハイライト	アプリケーションコード		ポートフォリオ規模での言語横断的なコード準備状況評価
クラウドパイロット	アプリケーションコード		Python、JS、Node.js、Goの詳細な互換性分析
SMART TS XL	アプリケーションコード + 依存関係マッピング		COBOL、JCL、メインフレーム、および多言語ポートフォリオ分析
AWS DMS	Rescale データ	AWS	スキーマ変換を伴うデータベース移行
Azureデータベース移行サービス	Rescale データ	Azure	SQL Server、MySQL、PostgreSQLのAzureへの移行
ストライム	Rescale データ		ダウンタイムゼロのデータ移行を実現するリアルタイムレプリケーション
クラウド向け Microsoft Defender	セキュリティ	Azure / マルチクラウド	セキュリティ体制とコンプライアンス評価
プリズマクラウド	セキュリティ		AWS、Azure、GCPにおけるCSPMとコンプライアンス
インフラコスト	費用		CI/CDパイプラインにおけるIaC統合型コスト見積もり
Apptio のクラウド機能	費用		FinOpsと継続的なクラウドコスト管理
Corent SurPaaS	インフラストラクチャ＋アプリケーション		AIを活用した発見、評価、および移行のオーケストレーション

認定条件 SMART TS XL クラウド移行のためのアプリケーションコード評価を実施する

SMART TS XL インフラストラクチャツールでは到達できないアプリケーションコード評価レイヤーに対応し、特にアプリケーションポートフォリオが複数の言語、プラットフォーム、およびテクノロジー世代にまたがるエンタープライズ環境やレガシー環境を対象としています。

COBOL プログラム、JCL ジョブ ストリーム、Java サービス、Python パイプライン、SQL スキーマを含む移行プログラムの場合、 SMART TS XL それらすべてに同時に統一された依存関係モデルを構築します。移行チームが何を再ホストするか、何をリファクタリングするか、何を廃止するかを決定する前に、 SMART TS XL 提供：

完全なプログラムインベントリ：環境内のすべての言語のすべてのソースプログラム、コピーブック、プロシージャ、スキーマ。これは実際のインベントリであり、文書化されたインベントリではありません。レガシー環境では、通常、文書化されたインベントリと実際のインベントリの差は20～30%になります。

言語間依存関係マッピング：アプリケーション依存関係マッピング機能は、COBOLプログラムがDB2スキーマに接続し、そのスキーマからJavaサービスがクエリを実行し、Pythonパイプラインにデータが供給され、最新のReactフロントエンドが使用する出力が生成されるまでを追跡します。この言語間依存関係チェーンによって移行の順序が決定され、多くの依存関係を持つコンポーネントは、依存するコンポーネントの準備が整ってから移行する必要があります。

デッドコードの特定：本番環境で実行時に呼び出されることのないプログラムやプロシージャは、移行対象から完全に除外できます。大規模なレガシー環境では、これは通常、インベントリ全体の10～25%に相当し、評価段階で大幅なコスト削減を実現できます。

複雑性分類：静的コード解析機能は、循環的複雑度、コピーブックの依存関係数、呼び出し元数、および移行の難易度を決定するその他の指標に基づいて各プログラムを分類します。呼び出し元が多い高複雑度プログラムは、リファクタリングまたは再構築の対象となります。低複雑度で依存関係の少ないプログラムは、リホストの対象となります。

変更前の影響分析：影響分析機能は、移行作業を開始する前に「このプログラムが変更された場合、何が影響を受けるか？」という問いに答え、未知のリスクを構造化された列挙可能な範囲に変換します。

メインフレームからクラウドへの移行プログラムを計画している組織にとって、 SMART TS XLさん レガシーの近代化 分析によって、移行ベンダーが変換作業を開始する前に必要とする移行前評価（完全な構造インベントリ、依存関係グラフ、複雑性分類、およびデッドコード除外レポート）が作成されます。

完全なクラウド移行評価で得られるべきもの

評価の価値は、それがもたらす意思決定によって決まります。包括的なクラウド移行評価では、移行プログラムを定義する以下の5つの成果物を作成する必要があります。

移行戦略の割り当てを含むアプリケーションポートフォリオインベントリ：対象となるすべてのアプリケーションを、リホスト、リプラットフォーム、リファクタリング、リアーキテクチャ、再構築、置換、または廃止のいずれかに分類し、それぞれの分類を裏付ける評価証拠を示します。

依存関係に基づく移行ウェーブ計画：アプリケーションの移行順序は、恣意的なグループ分けではなく、依存関係グラフに基づいて決定されます。対象範囲内の他のアプリケーションからのインバウンド依存関係がないアプリケーションは、早期のウェーブで移行できます。多くのアプリケーションが依存しているアプリケーションは、依存するアプリケーションの準備が整った後、後のウェーブで移行します。

移行にかかる総コストの見積もり：インフラストラクチャのコスト差だけでなく、エンジニアリング作業、移行ツールのコスト、一時的な並行運用コスト、トレーニングコストも含まれます。

移行後のTCOモデル：適切な規模の構成と実際の利用データに基づいて予測されるクラウド支出を、ライセンス変更や運用モデルの移行に関する現実的な仮定に基づき、現在のオンプレミス運用コストと比較します。

リスク登録簿：特定されたリスク、互換性阻害要因、複雑なデータ移行、文書化されていない依存関係、コンプライアンス上の制約、それぞれの発生確率、影響、および提案された軽減策。

移行開始前にこれら5つの成果物をすべて作成する組織は、プログラムを成功させるために必要な情報をすべて把握できます。アプリケーションコード評価、データ評価、セキュリティ評価を省略する組織は、これらの成果物の不完全なバージョンしか作成できず、移行中に不足している部分を発見することになります。そして、発見された問題に対処するには、より多くのコストがかかります。