一般的な技術プラットフォーム
組織の移行時には、さまざまなテクノロジ プラットフォーム用に準備する必要があります。 ほとんどの移行は Windows と SQL Server 資産から開始しますが、現在運用されているほとんどのデータセンターには、Windows ベース以外のプラットフォームがいくつか存在しています。
このユニットでは、Microsoft の統合された移行アプローチについて説明します。 このアプローチにより、基盤となるテクノロジ プラットフォームに関係なく、すべてのワークロードをクラウドに移行するための明確なパスが確保されます。
統合された移行の焦点
ほとんどの移行チームは、Windows と SQL Server の資産の移行を容易にするための、Azure Migrate と Azure Migrate ハブの機能を認識しています。 ただし、移行を開始する前に、同じ移行ファクトリ アプローチまたは同じ移行プロセスを使用できる、他のテクノロジ プラットフォームについて理解しておくことが重要です。
以下の図と表は、移行と最新化のための同じ反復的な Migrate の手法を採用するいくつかのシナリオをまとめたものです。 このモジュールの最後にある「まとめ」には、これらの各テクノロジ プラットフォームについて学習を続行するためのリンクが記載されています。
図 1: 移行手法でサポートされるテクノロジ プラットフォーム。
| 仮想マシン | アプリケーション | Data | ハイブリッド | テクノロジ プラットフォーム | その他のシナリオ |
|---|---|---|---|---|---|
| Windows Server を実行するサーバー | ASP.NET | SQL Server | Azure Stack | SAP (クラシックおよび HANA) | ワークロードをセキュリティで保護する |
| Linux サーバー | Java | オープンソース システム (OSS) データベース | VMware | Kubernetes | マルチテナント環境 |
| 仮想デスクトップ | PHP | Analytics | メインフレーム | NetApp |
一般的なテクノロジ プラットフォームの準備
各テクノロジ プラットフォームでは、移行の実行方法がわずかに異なる場合があります。 この Learn モジュールの最後にある「まとめ」では、これらの考慮事項について参照できるよう、リンクをブックマークに登録することができます。 現時点では、このユニットが、テクノロジ プラットフォームが移行にどのように影響するかを大まかに理解するのに役立ちます。
影響を示すいくつかの例を次に示します。
ワークロードを評価する: 各ウェーブのワークロードの評価においては、主に、アーキテクトが Azure の互換性と資産間の依存関係を調べます。 ただし、最新化や最適化の機会との互換性も調べる必要があります。
Tailwind Traders のストーリーでは、データ ホスティング専用のインフラストラクチャの量を最小限に抑えるため、チームが Azure SQL Database との互換性について各データベースを評価します。 Azure SQL Database ではさまざまなデータベース形式がサポートされているため、OSS データベースからはいくつかの最新化の可能性が提供されます。
ワークロードのデプロイ:移行 (またはデプロイ) の際に、チームは Azure Migrate ツールを主に使用して、VM、アプリケーション、データなどの資産を Azure に移行します。 テクノロジ プラットフォームによっては無料のツールが必要になる場合があります。
Tailwind Traders チームは、SAP プラットフォームを移行する際、Azure の SAP HANA へのスムーズな移行を確実にするため、SAP Database Migration Option (DMO) を移行ツールボックスに追加します。
ワークロードをリリースする: 各テクノロジ プラットフォームとワークロードが Azure に移行された後、チームは運用トラフィックをテストして最適化し、新たに移行されたワークロードにリリースする必要があります。 プラットフォームによっては、チームがワークロード操作を明確に把握し、可視化するのに役立つ監視ツールに、多少の多様性が必要になる場合があります。
Tailwind Traders チームは、仮想デスクトップを移行する際、Lakeside ソフトウェアなどの Azure Migrate パートナー ソリューションを使う可能性があります。 このようなパートナー ソリューションを使用すると、パフォーマンスを追跡し、移行のための他のワークロードを識別することで、優れたユーザー エクスペリエンスを提供できます。
スプリント計画でのさまざまなテクノロジ プラットフォームに関する準備
これらの各テクノロジ プラットフォームにも同じ手法が適用されます。 最初のクラウド導入計画の間に、これらの違いに対応するための若干の作業を行います。 通常、個々のテクノロジ プラットフォームがそのレベルの計画に大きな影響を与えることはありません。
ただし、このようなプラットフォームの一部では、成功するために必要な基になるタスクに、微妙な違いがあります。 これらの違いについては、以下の重要な計画アクティビティで対処します。これはスプリント計画に役立ちます。
優先順位の調整: クラウド導入計画全体では、移行するワークロードの順序をビジネスへの影響に基づいてまとめますが、優先順位はチームの実行能力も考慮する必要があります。
移行チームは、スプリントを開始する前に、各ワークロードの移行に必要なテクノロジ プラットフォームを評価する必要があります。 可能であれば、移行の優先順位を調整し、テクノロジ プラットフォームに基づいてワークロードのウェーブをグループ化する必要があります。 たとえば、Windows と SQL Server のインスタンスをスプリント 1 - 3 で移行し、Linux サーバーと OSS データをスプリント 4 - 6 で移行します。
重要
このような優先順位の再調整は、常に適用できるとは限りません。 ワークロードを移行するために、Windows 資産と OSS 資産が混在していることが必要になる場合があります。 そのような状況では、ワークロードを 1 つの成果物にしておくのが最善です。 より複雑なワークロードを後のスプリントに移動して、チームが必要なスキルを習得するための時間を確保することもできます。
モダン化レビュー:移行において、3 つのタスク領域 (評価、デプロイ、リリース) すべてを 1 つの移行チームおよび 1 つの移行スプリントにまとめる場合は、各スプリント計画にモダン化レビューを含める必要があります。
この種のレビューでは、チームは、サービスとしてのプラットフォーム (PaaS) オプションへの最新化に焦点を当てて、移行する資産を評価します。 たとえば、SQL Server または OSS データベースを Azure SQL Database に変換して、インフラストラクチャへの依存を最小限にする必要がありますか? アプリケーションをサービスとしてのインフラストラクチャ (IaaS) サーバーから Web アプリまたはコンテナー インスタンスに移動する必要がありますか? 各決定によって、一般的なテクノロジ プラットフォームのそれぞれをどのように連携させるかが決まります。