次の方法で共有

ワークロードを最新のアプリケーション プラットフォームに移行する

  • [アーティクル]

オンプレミスのデータセンターから Azure の Kubernetes クラスターに既存のワークロードを移行することには明確な増加傾向があります。 このアプローチによって、移行後のインフラストラクチャ フットプリントが削減する可能性があります。 さらに重要なことに、コンテナーに移行すると、ポートフォリオの移植性が高まり、パブリック クラウドとプライベート クラウドの間でワークロードを簡単に移動できるようになります。 これは、多数の Web アプリケーションがある組織で最もよく見られる傾向です。

ほとんどの最新のアプリケーション プラットフォーム オプションでは、アプリケーションの再アーキテクチャや再デプロイが必要です。 Azure Kubernetes Service (AKS) のオーケストレーション機能を使用すると、Kubernetes ソリューションを簡単に移行できます。 ただし、コンテナーの移行を標準の移行プロセスに組み込むと、プロセスがさらに効率的になる場合があります。 Azure Migrate は、移行を促進する多くのツールと機能を備えています。 Azure Migrate: App Containerization ツールは、標準の移行プロセス中にコンテナーに移行する最も簡単な方法です。

1 つの移行アプローチ

クラウド導入フレームワークの 1 つの移行シナリオの一環として、AKS に移行してクラウド内のコンテナーを高速化できます。 一般に、Azure への移行では、Azure Migrate とパートナー ツールを使用して、ワークロードの評価、ワークロードの移行、およびクラウドへのワークロードのリリースを行います。 この 3 ステップのプロセスを AKS の移行に適用できますが、移行手順に役立つ他のいくつかのツールが必要になる場合があります。

ワークロードの評価

ワークロードのグループを評価する最初の手順として、クラウド導入計画と初期ポートフォリオ評価を参照する必要があります。 移行中にコンテナー化についてワークロードを評価する際、オペレーティング システムとアプリケーションのプログラミング言語に関する重要な情報を確認して、最も適切なコンテナー化パスを判断する必要があります。

効率的な移行候補

Azure Migrate のコンテナー移行ツールを使用すると、特定のアプリケーションを AKS に移行する速度を上げることができます。 次の一覧に対してワークロードを評価し、Kubernetes の移行候補を判断します。また、この一覧が増えるにつれて、頻繁に確認するようにしてください。

Azure Migrate: App Containerization ツールを使用して、アプリケーションを移行します。 このツールの最初の手順は検出です。これは、互換性の評価に役立ちます。

コンテナー化とその後の移行候補

残りのワークロードは、コンテナー内での動作中に機能し、パフォーマンスが高いことが検証されるまで移行できません。 アプリケーション所有者と協力して、コンテナー化の実行、結果の検証、作業のイメージ構築パイプラインの作成を行うための時間配分を決定します。 Windows 固有の要件 (グループ管理サービス アカウント、ローカル ファイル システムの使用状況、キャッシュ実装の詳細、シングルトン実装、データベースなどの依存関係など) のような一意の依存関係に注意してください。

一元化されたチームが組織全体のコンテナ化の取り組みを主導することはできますが、それはむしろプロジェクト管理機能であり、技術要件の収集と監視のプロセスであると考えると、アプリケーション所有者は深く関与する必要があります。

移行タスク

評価タスクで説明したように、アプリケーションの多くは、Azure Migrate: アプリ コンテナ化ツールを使用して移行できます。 反復可能な移行プロセスのこの手順では、ワークロードのクラウドへの移行に関連するタスクを完了する方法について説明します。

効率的な移行

Azure Migrate: App Containerization ツールと互換性のあるすべてのワークロードについて、ツール自体によってコンテナー イメージが構築され、AKS クラスターがデプロイされ、アプリケーションがコンテナーへデプロイされることで、移行手順が自動化されます。

コンテナーとワークロードの移行

より手動のプロセスでコンテナーとワークロードを移行する場合、コンテナー イメージの検証、クラスターのデプロイ、アプリケーションのデプロイはより複雑になります。 まず、ターゲットの Kubernetes のバージョンが AKS でサポートされている期間内であることを確認します。 古いバージョンを使用すると、サポート範囲外となる可能性があり、AKS でサポートされるようにするためにはアップグレードが必要になります。 詳細については、AKS でサポートされる Kubernetes のバージョンに関するページを参照してください。 可能であれば、常に同じバージョンの Kubernetes に移行します。 つまり、既存のシステムでインプレース アップグレードを実行するか、優先順位に基づいて移行後のアップグレードを計画します。

他の移行と同様に、合意できるメンテナンス期間を決定し、移行の進行状況について、利害関係者全員に対する透明性を確保します。 必要に応じて、移行を追跡し、ダッシュボードに表示します。 ダウンタイム移行について交渉できない場合は、ダウンタイムのない移行に向けた追加の計画、コスト、複雑さを考慮します。 ダウンタイム移行が想定されていない場合に、それが必要であることがわかった場合は、その変更を利害関係者に通知します。 その変更の影響分析を実行し、リスクが文書化され、合意されていることを確認します。

すべての移行 (ダウンタイムの移行でも) で、移行をサポートするために、既存のアプリケーションを変更して柔軟性を高めることが必要な場合があります。 アプリケーション チームが、できるだけ早い段階で、ワークロードの移行計画に全面的に関与するようにします。 たとえば、移行が完了する前に、追加の DNS、接続文字列、設定切り替え機能を現在のワークロードにデプロイすることが必要な場合があります。

現在、Azure へのコンテナーとワークロードのレプリケーションを実行するために、いくつかのオープンソース ツールのいずれかを使用する必要があります。

既存の Kubernetes プラットフォーム (AKS エンジン、ACS、またはその他の Kubernetes 実装) を使用している場合は、移行に役立つオープンソース ツールの使用を検討します。 このような場合、Kubernetes で機能するワークロードが既にあるため、AKS でのホスト変更が簡単になります。 移行を実行する前に、AKS に存在するすべての機能を検証します。

次のステップ: 最新のアプリケーション プラットフォーム ソリューションを使用したイノベーション

次の記事では、クラウド導入過程の特定時点に関するガイダンスを提供しており、クラウド導入シナリオを成功させるのに役立ちます。