Migrate for Anthos によるアプリのモダナイゼーション: Day 2 オペレーションに対応

※この投稿は米国時間 2020 年 4 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

すべてのアプリケーションのモダナイゼーション戦略が同じというわけではありません。最も簡単な方法の 1 つは、既存の仮想マシンを選んでコンテナとして保存することです。しかし、結果として得たコンテナは機能しますが、より洗練されたモダナイゼーション技術のメリットを享受できません。つまり、リソース使用量の点でも、Anthos GKE など高性能なコンテナ管理プラットフォームの実行により可能になる高度な「Day 2 オペレーション」の点でも、メリットがありません。

本日、Anthos の新しい更新について、Migrate for Anthos の最新リリースを含めていくつかの発表を行いました。自動コンテナ化ソリューションに VM からコンテナへの拡張変換機能が含まれることとなり、従来のワークロードを Kubernetes と Anthos にモダナイズする際に役立ちます。また、Anthos Service Mesh と緊密に統合され、オンプレミスで実行される Anthos をサポートし、従来の Windows Server アプリケーションをコンテナに変換することもできます。

イメージでリフト＆シフトよりも便利に

以前のバージョンの Migrate for Anthos は「リフト＆シフト」アプローチでコンテナ化を行っていました。仮想マシンからワークロードを抽出し（同時にオペレーティング システムのカーネルと VM 関連のコンポーネントを除外して）、ステートフルなコンテナに変換していました。また、ワークロードを Kubernetes ストレージ、ネットワーキング、モニタリングと統合するランタイム レイヤも追加しました。

今回の新しいリリースでは、Migrate for Anthos が VM のコンテンツを分析し、そのコンテンツをイメージとデータ コンポーネントに分解するための候補を生成するようになりました。これらは確認やテストが可能で、コンテナ イメージベースの管理を実行するために必要なすべてのアーティファクトを生成します。たとえば、Docker イメージ、Dockerfile、デプロイ YAML、統合されたデータ容量（任意の Kubernetes 対応ストレージに指定可能）などを生成します。モダナイゼーション プロセス自体は、Kubernetes 構成要素（CRD、CLI）とメカニズムによって緻密にオーケストレーションされています。詳しくは、こちらの動画や以下の図をご覧ください。

このイメージベースのアプローチにより、最新の CI / CD パイプライン ツールを利用しアプリケーションを構築、テスト、デプロイするだけでなく、Kubernetes を活用して一貫性のある効果的なデプロイを実現し、クラスタ、マルチクラスタ、複数のクラウドを含む Kubernetes のデプロイ全体で新しいイメージを展開できます。

イメージベースのソリューションは最新のデベロッパー エクスペリエンスを可能にするだけでなく、Kubernetes コントロール プレーンと宣言型 API の機能を発揮して運用効率を高めます。たとえば、事実上ステートレスなアプリケーション コンポーネントを使用すると、アプリケーションを書き直さずに、負荷分散、動的スケーリング、自己回復を実装できます。

つまり、Migrate for Anthos が Anthos Service Mesh と緊密に統合されたため、アプリケーション コードを変更せずに、強化されたオブザーバビリティやセキュリティ、自動化されたネットワーク ポリシー管理のメリットを従来のアプリケーションに適用できるということです。Migrate for Anthos 1.3 のコンテナ化テクノロジーは Google Cloud の Anthos 向けに一般提供されています。ただし、ワークロードを Anthos にモダナイズするものの、Google Cloud に移行する準備がまだ整っていない組織のために、Migrate for Anthos 1.3 にはオンプレミスで実行される Anthos GKE をサポートするプレビューも含まれています。

Google Cloud Partner の Arctiq は Migrate for Anthos を積極的に利用しており、顧客業務を円滑に変革できると述べています。

同社の Kyle Bassett 氏は次のように述べています。「Migrate for Anthos は既存の仮想マシンを Google Kubernetes Engine で実行されているコンテナにモダナイズするのに極めて強力な方法です。従来、こうした VM をコンテナに変換するのは手間がかかり、Kubernetes の詳しい知識が必要でした。そのため、ほとんどのお客様は VM をそのままにしていました。しかし、Migrate for Anthos では、より自動化された信頼性の高いワークフローを利用すれば VM からワークロードを抽出してコンテナで実行できます。当社は Migrate for Anthos によって、お客様がインフラストラクチャと管理のコストを削減しながらワークロードのパフォーマンスを向上させるお手伝いができます。」

Windows サーバーの自動コンテナ化

今年に入って、GKE で Windows Server コンテナを実行できるようになったことを発表しました。とはいえ、まだ新しいテクノロジーゆえにネイティブの Windows コンテナは少なく、Windows アプリケーションを手動でコンテナ化することは困難な場合があります。

Migrate for Anthos を使用すると、従来の Windows サーバーアプリを Windows Server 2019 コンテナに変換し、Google Cloud の GKE で実行できるようになりました。これには、Microsoft によるサポートが最近終了した Windows 2008 R2 が含まれます。この機能はプレビューで利用でき、完全に自動化された検出評価ツールが含まれています。

これにより、Google Compute Engine VM で実行されている IIS や ASP.NET ベースのアプリを自動的に変換できるため、インフラストラクチャとライセンスの費用を削減できます。オンプレミスや他社のクラウドで実行される IIS アプリと ASP.NET アプリの場合は、Migrate for Compute Engine を使用して Compute Engine VM に移行したうえで Migrate for Anthos を使用すると、コンテナに変換できます。IIS と ASP.NET 以外のアプリのサポートも間もなく提供開始される予定です。

また、アプリケーション スタックの一部のみを Windows コンテナに移行することもできます。こうすれば、コンテナに移行しづらい要素を Compute Engine VM で実行しながら、GKE 上でコンテナとの VPC レベルのネットワーク統合を活用することも可能です。

モダナイゼーションを促進する

お話を伺っているお客様からはほぼ一様に、使用するコンテナを増やしたいという声をいただいています。Migrate for Anthos を使用すると、このようなプロセスを促進しやすくなり、これ以外のプロセスに伴う時間と労力を削減できます。上記または今後の Migrate for Anthos のプレビューへの参加に関心をお持ちのお客様は、こちらのフォームにご記入いただき、[プロジェクト] という項目に「Migrate for Anthos」とお書き添えください。

- Google Cloud エンジニアリング ディレクター Issy Ben-Shaul、Google Cloud プロダクト マーケティング Tom Nikl