Google Cloud における .NET フレームワーク アプリケーションのモダナイゼーションへの移行

Last reviewed 2023-07-13 UTC

このドキュメントでは、モノリシック アプリケーションの一般的な制限を示し、モダナイズするための段階的な構造化プロセスについて説明します。

このドキュメントは、Windows と .NET エコシステムを理解しており、モダナイゼーションの内容について知識を深めたいクラウド アーキテクト、システム管理者、CTO を対象としています。このドキュメントでは、カスタム開発されたサーバー アプリケーション（ASP.NET や Windows Services アプリケーションなど）に焦点を当てていますが、ここでの内容は他のユースケースにも適用できます。

レガシー アプリケーションとモダン アプリケーション: モダナイズする理由

レガシー アプリケーションのモダナイズは 1 つの行程です。その行程の始点と終了点、得られるメリットは、アプリケーションの状態と、モダナイズに充てることができる時間と労力に大きく依存します。

.NET Framework アプリケーションのコンテキストでは、レガシーとモダンのコンセプトは明確ではありません。どのアプリケーションにもレガシーとモダナイゼーションの異なるニーズがあります。ただし、レガシー アプリケーションはいくつかの一般的な制限を共有しています。

次の図は、レガシー アプリケーションとクラウドベースのモダン アプリケーションの特徴をまとめたものです。

モノリシックとクラウドベースのモダン アプリケーションの違い

レガシー .NET フレームワーク アプリケーションは、通常 .NET Framework で構築され、オンプレミスの Microsoft Windows サーバーでホストされ、Microsoft SQL Server を実行しているオンプレミス サーバーに接続されるモノリシックです。アーキテクチャの細かい点は、こうした一般的な特性とは異なる場合がありますが、ほとんどのモノリシック アプリケーションには次の制限があります。

  • Windows と SQL Server を実行するオンプレミス サーバーを管理する必要性。
  • 制限されたデプロイ環境と Windows への依存に関連するライセンス費用。
  • モノリシック アーキテクチャで構築されたレガシー アプリケーションをアップグレードする難しさ。
  • オンプレミス リソースで計画、予算配分、スケーリングを行うためのアジリティの低さ。

クラウドベースのアーキテクチャ向けに構築されたアプリケーションには、次のような利点があります。

  • マネージド サービスと統合することで管理のオーバーヘッドが最小限に抑えられること。
  • .NET とコンテナによる完全なモビリティの実現と、Windows への依存関係やライセンス費用がなくなること。
  • 個別にデプロイ可能なマイクロサービスに基づく高速なアップグレード パス。
  • サーバーレス アーキテクチャにより、スケーリングと予算配分を行うための完全なアジリティ。

クラウド アーキテクチャでは、従来のオンプレミス アプローチよりも費用対効果に優れ、効率的で、復元性の高い方法でアプリケーションを実行できます。クラウドベースのアプローチでは、アプリケーションをデプロイする場所とタイミングをより柔軟に選択できます。

モダナイゼーションの行程

クラウドベース アーキテクチャのメリットはわかりやすいものですが、クラウドへの移行はそうでない場合があります。レガシー .NET フレームワーク アーキテクチャからクラウドベースのアーキテクチャへのモダナイゼーションは、単一の汎用パターンに当てはまりません。次の図に示すように、モダナイゼーションには一連のステップがあります。各ステップで制限が取り除かれ、アプリケーションの機能が強化され、モダナイゼーションに関する後のフェーズへの機会を開きます。

モダナイゼーション プロセスに関連するプロセス、テクノロジー、サービス

モダナイゼーションへのステップは、次の 3 つのフェーズにグループ化されます。

  1. クラウドでの再ホスト（リフト＆シフトとも呼ばれます）
  2. プラットフォームの再構築
  3. 再設計と再構築

モダナイゼーション前の評価と学習

モダナイズする前に準備が必要になります。最初のステップとして、アプリケーションとその依存関係を評価し、モダナイズに適しているアプリケーション、変更または移行ができないアプリケーション（一般的にはレガシー関連または規制上の理由によるもの）を特定します。詳細については、Google Cloud への移行: ワークロードの評価と調査をご覧ください。

この評価と並行して、チームでクラウドの機能について学ぶ必要があります。Google Cloud では、認定資格、技術ガイド、Windows や .NET 専用の Codelab を提供しており、学習プロセスをスピードアップするために活用できます。

モダナイズするアプリケーションを特定したら、既存のアプリケーションをクラウドにそのまま移行するか、アプリケーション コードまたは、構成の変更を最小限にして移行できます。

フェーズ 1: クラウドでの再ホスト

この最初のフェーズの主な目標は、サーバー管理の負担をオンプレミス リソースからクラウド インフラストラクチャに移行することです。このフェーズでは、インフラストラクチャをクラウド対応に変え、後のフェーズでクラウド用に最適化できるようにします。

手動による移行とツールベースの移行

通常、Windows ベースの .NET フレームワーク アプリケーションのリフト＆シフトは、オンプレミスの Windows Server インスタンスと SQL Server インスタンスを Compute Engine 仮想マシン（VM）インスタンスに移動することから始まります。この処理は、手動で実行することも、移行ツールを利用して自動化することもできます。

手動で移行する場合は、Compute Engine の Windows Server イメージを使用してインスタンスを立ち上げることができます。Google Cloud Marketplace には、ASP.NET Framework ソリューションなど、Compute Engine にデプロイする準備が済んでいるソリューションもあり、IIS、SQL Express、ASP.NET を含む Windows Server VM を確保できます。

同様に、SQL Server イメージから SQL Server インスタンスを開始するか、さらに手がかからないマネージド ソリューションのCloud SQL for SQL Serverに直接アクセスできます。

Google Cloud には、オンプレミスの VMware VM を Google Cloud の VMware 環境に移行する際に役立つ Migrate to Virtual Machines や VMware Engine などの移行ツールも用意されています。

通常は、VM の構成後にカスタム VM イメージを作成して、オンデマンドで新しいインスタンスを再作成できるようにします。この手順は、このドキュメントで後述するインスタンス テンプレートのためにも重要です。

クラウドでドメイン サービスが必要な場合は、Virtual Private Cloud（VPC）を使用するか、直接 Managed Service for Microsoft Active Directory に移動して、フォールト トレラントな Microsoft Active Directory 環境を Compute Engine にデプロイできます。

オンプレミス接続とクラウド接続

VM をクラウドに移行するとき、一部のワークロードをオンプレミスに保持することは珍しくありません。たとえば、レガシー ハードウェアまたはソフトウェアを必要とするアプリケーションがある場合、コンプライアンスや現地の規制要件を満たす必要がある場合などです。オンプレミス リソースとクラウド リソースを安全に接続するには、VPN か相互接続ソリューションが必要です。この接続を作成、管理する方法や、ハイブリッド クラウドとオンプレミス ワークロードを実行するための他の影響については、Google Cloud への移行: 基盤の構築をご覧ください。

最初のメリット

フェーズ 1 が終了すると、クラウドで稼働する基本的なインフラストラクチャが揃い、次のようなメリットが得られます。

  • コストの最適化。カスタム マシンタイプ（CPU、メモリ、ストレージ）を作成して、使用分だけの支払いにできます。VM と障害復旧の環境を自由に起動および停止して、稼働時のみの支払いにできます。また、移行前には、サイズの適正化に関する推奨事項を取得できます。
  • 運用の効率化。永続ディスクを VM にアタッチし、スナップショットを作成してバックアップと復元を簡素化できます。
  • 信頼性の向上。ライブ マイグレーション機能により、メンテナンスの時間枠をスケジュールする必要がなくなります。

これらの最初のメリットは有用ですが、クラウドへの最適化を開始すると、より多くのメリットを得ることができます。

フェーズ 2: プラットフォームの再構築

プラットフォームを再構築する際には、アプリケーションのアーキテクチャを変更せずに、コードベースへの変更を最小限に抑え、アプリケーションのコンポーネントの一部（データベース、キャッシュ レイヤ、ストレージ システムなど）をアップグレードすることで、アプリケーションを最適化します。フェーズ 2 の目標は、アプリケーションを大幅に再構成することや、VM 環境から移動することなく、アプリケーションの管理、復元性、スケーラビリティ、柔軟性を高めるためのクラウド機能を使用し始めることです。

Compute Engine を活用する

Compute Engine には、探索に役立ついくつかの標準機能が用意されています。たとえば、Compute Engine のインスタンス テンプレートを使用して、既存の VM 構成からテンプレートを作成できます。インスタンス グループは、同じ VM のフリートで、これによって効率的にアプリケーションのパフォーマンスを向上させ、冗長性を高めるスケーリングが可能になります。マネージド インスタンス グループには、単純な負荷分散と冗長性に加えて、自動スケーリングなどのスケーラビリティ機能、自動修復、リージョン デプロイなどの高可用性機能、自動更新などのセキュリティ機能があります。

これらの機能により、VM 環境を維持しながら、アプリケーションを完全に再構築しなくてもアプリケーションの復元性、冗長性、可用性を向上させることができます。

インプレースでの置き換えを模索する

アプリケーションをクラウドに移行する際は、以下を含む Cloud Marketplace で、ホストされたインフラストラクチャを Google とサードパーティのパートナーが提供するマネージド クラウド オプションと置き換える機会を模索する必要があります。

  • セルフホストの SQL Server、MySQL、Postgres ではなく Cloud SQL。Cloud SQL を使用すると、インフラストラクチャを管理する（セキュリティのためにデータベース VM にパッチ適用する、バックアップの管理など）のではなく、データベースを管理することに集中できます。さらに、Windows ライセンスの要件がなくなるメリットがあります。
  • セルフホストの Active Directory ではなく、Managed Service for Microsoft Active Directory。
  • セルフホストの Redis インスタンスではなく、Memorystore。

これらの置き換えではコード変更が必要なく、また構成の変更も最小限に抑えられるため、管理が最小化され、強化されたセキュリティ、スケーラビリティのメリットを得られます。

Windows コンテナでの最初のステップ

クラウドの基本的な機能を最適化したら、VM からコンテナへの移行を開始できます。

コンテナは、アプリケーションとそのすべての依存関係を含む軽量なパッケージです。アプリケーションを VM で直接実行する場合と比較して、コンテナを使用すると、さまざまな環境で、より一貫性があり、予測可能で、効率的な方法でアプリケーションを実行できます（特に、同じホストで複数のコンテナを実行する場合）。コンテナ（Kubernetes、Istio、Knative など）を取り巻くエコシステムでは、アプリケーションの単一のモノリスから集中的なマイクロサービスへの変換をさらに加速できる、多くの管理機能、復元機能、モニタリング機能も提供されます。

これまで、コンテナ化は Linux のみの機能でした。Windows アプリケーションでは、コンテナ化によるメリットを享受できませんでした。そのような状況が、Windows コンテナとそれに続く Kubernetesと、Google Kubernetes Engine（GKE）でのサポートにより変わりました。

Windows コンテナは、.NET フレームワーク アプリケーションを .NET に移行せずに、コンテナのメリット（アジリティ、ポータビリティ、制御など）を享受する場合の選択肢の一つです。.NET Framework のバージョンに応じて、対象とする適切な OS を選択する必要があります。また、Windows コンテナがサポートされない Windows スタックがあることを知っておく必要もあります。このアプローチの制限と代替方法については、このドキュメントの後半の .NET と Linux のコンテナをご覧ください。

.NET Framework アプリケーションを Windows コンテナにコンテナ化した後は、それを Kubernetes クラスタで実行することをおすすめします。Kubernetes では、コンテナ Pod がダウンしたときの検出と再作成、Pod の自動スケーリング、自動ロールアウトや自動ロールバック、ヘルスチェックなどの標準機能が提供されます。GKE では、クラスタの自動スケーリング、リージョン クラスタ、高可用性コントロール プレーン、GKE Enterprise を使用したハイブリッドおよびマルチクラウドのサポートなどの機能が追加されます。GKE または GKE Enterprise を使用する場合は、Migrate to Containers を使用して Windows VM のコンテナへの移行を簡略化し、移行を早められます。Migrate to Containers では、アプリケーションの書き換えや再設計を行わずに、VM からコンテナへのアプリケーションの抽出を自動化できます。

Compute Engine の適切な機能を使用することで多くのメリットが得られますが、コンテナと GKE に移行すると複数の Pod を同じ VM にパッキングすることで、VM を最大限に活用できます。この方法によって、VM の数が減り、Windows ライセンス コストが削減される可能性があります。

また、Kubernetes と GKE では、Windows コンテナと Linux コンテナの両方を宣言的に管理することで、インフラストラクチャの管理を効率化できます。チームでコンテナ化の準備ができたら、モダナイゼーションの次のフェーズに進めます。

フェーズ 3: 再設計と再構築

再プラットフォーム化は、クラウドを最大限に活用するための出発点にすぎません。アーキテクチャをクラウドベースのプラットフォームに変えると、次のようなメリットが得られます。

マネージド サービスへの移行

アプリケーションの一部を書き換える際には、ホストされたサービスからマネージド サービスへの移行を始めることをおすすめします。たとえば次のようにします。

  • ネットワーク接続ストレージ（NAS）ではなく、Cloud Storage を使用します。
  • セルフホスティングの MSMQ、RabbitMQ、Kafka ではなく、Pub/Sub を使用します。
  • アプリケーションに認証レイヤをコーディングするのではなく、Identity-Aware Proxy（IAP）を使用します。
  • シークレットと暗号鍵をアプリケーションと一緒にローカルに保存するのではなく、Cloud Key Management Service（Cloud KMS）と Secret Managerを使用します。

アプリケーションをこうしたサービスと統合するには追加のコードが必要ですが、プラットフォーム管理の負担が Google Cloud に移るため、価値のある投資といえます。これらのサービスと統合しながら、.NET 向け Google Cloud ライブラリ、Tools for Visual Studio、Cloud Code for Visual Studio Code により、.NET エコシステムとツールは引き続き使用できます。

マネージド サービスでは、アプリケーションの運用もサポートできます。アプリケーション ログを Cloud Logging に保存し、アプリケーション指標を Cloud Monitoring に送信できます。また、Cloud Monitoring では、サーバーとアプリケーションの指標を使用してダッシュボードを構築できます。Google Cloud には、Cloud Logging、Cloud Monitoring、Cloud Trace の .NET クライアント ライブラリが用意されています。

.NET コンテナと Linux コンテナ

アプリケーションが Windows 上のみで稼働する以前の .NET Framework アプリケーションの場合は、Compute Engine の Windows サーバーか、GKE の Windows Server コンテナでの実行を維持したいと思うかもしれません。このアプローチは短期的に有効な場合がありますが、長期的には大幅に制限される可能性があります。Windows にはライセンス料と、Linux より総じて大きなリソースを使用するため、これらの要因により長期的には所有コストが高くなる可能性があります。

.NET の最も重要な側面は、マルチプラットフォームであることです。.NET アプリケーションは Linux コンテナにコンテナ化できます。Linux コンテナは Windows コンテナよりも軽量で、より多くのプラットフォームでより効率的に動作します。これにより、.NET アプリケーションのデプロイの選択肢が作られるため、Windows への依存やそれに関連するライセンス費用から解放されます。

.NET フレームワーク アプリケーションを .NET に移植する

.NET への移行を開始するには、.NET Framework から .NET への移植の概要を確認することをおすすめします。.NET Portability Analyzer や Platform Compatibility Analyzer などのツールを使用すると、アセンブリと API が移植可能かどうかを判断できます。dotnet try-convert などの他の移植ツールも有用です。

外部ツールは、互換性の問題を特定し、最初に移行するコンポーネントを決定する際に役立ちます。最終的には、.NET プロジェクトを作成し、徐々に .NET Framework コードを新しいプロジェクトに移植して、その過程で非互換な部分を修正する必要があります。コードを移植する前に、テストを準備して、移植後に機能をテストすることが重要です。古いコードと新しいコードを A/B テストでテストすることをおすすめします。A/B テストでは、一部のユーザーを新しいアプリケーションに誘導しながら、以前のアプリケーションを実行し続けることができます。この方法では、新しいアプリケーションの出力、スケーラビリティ、復元性をテストできます。A/B テストをサポートするため、Google Cloud にはグローバル外部アプリケーション ロードバランサなどのロード バランシング ソリューションが用意されています。

文化の変革

.NET フレームワークと Windows サーバーから .NET と Linux コンテナへの変更は、単なる技術的なことだけではありません。この移行では、組織での文化を変革する必要があります。Windows のみの環境に慣れている可能性があるスタッフは、マルチプラットフォーム環境に適応する必要があります。この文化の変革には、.NET、Linux、およびコンテナツール（Docker、Kubernetes など）を使用するトレーニングのための時間と予算が必要です。しかし、Windows のみの組織からマルチプラットフォーム組織へ変革することで、より幅広いツールとスキルが得られます。

モノリスの解体

.NET フレームワークから .NET へ移行する際には、次のようないくつかの疑問が持ち上がります。

  • .NET でアプリケーションの全体を書き換えるのか？
  • アプリケーションを小さなサービスに分割して .NET で記述するのか？
  • 新しいサービスを .NET で記述するだけなのか？

これらの質問について検討するときは、各アプローチに関連する利点、時間、費用を考慮する必要があります。一度にすべてを書き換えない、バランスがとれた方法を採用することは良いことです。代わりに、.NET で新しいサービスを記述し、機会に応じて既存のモノリスを .NET の小さなサービスに分割できます。計画には次のドキュメントが役立ちます。

.NET コンテナのデプロイ オプション

Google Cloud に .NET アプリをデプロイしている状態にある場合、Google Cloud に .NET コンテナをデプロイするさまざまな選択肢があります。モノリシック アプリケーションをマイクロサービスに解体する際には、マイクロサービスのアーキテクチャと設計に応じて複数のホスティング ソリューションを使用できます。

次の質問に答えることで、最適なホスティング方法を判断できます。

  • アプリケーションは何でトリガーしますか？すべてのホスティング ソリューションは、標準の HTTP(S) に適していますが、ご利用のプロトコルが TCP / UDP か独自のプロトコルの場合、GKE が唯一の選択肢になると考えられます。
  • アプリケーションには特定のハードウェアが必要ですか？Cloud Run では、リクエストごとに適切ながら、限られた数の RAM と CPU を提供します。Cloud Run for Anthos には、GPU、多くのメモリ、ディスク容量など、より多くのカスタマイズ オプションが用意されています。
  • スケーリングの想定値はどのくらいですか？アプリケーションに非アクティブな期間がある場合、Cloud Run などのサーバーレス ソリューションでは、ゼロまでスケールダウンする選択肢を提供できます。
  • レイテンシはどの程度重要ですか。また、コールド スタートに対するアプリケーションの許容度はどのくらいですか？コールド スタートに対する許容度が低い場合は、次のいずれかのオプションを検討する必要があります。

各ホスティング環境に関するドキュメントを確認して、その機能、強み、弱み、料金モデルについて十分理解することをおすすめします。

原則として、HTTP リクエストを処理するマイクロサービスを作成する場合は、可能ならば Cloud Run にデプロイし、Kubernetes エコシステムを維持する、またはより多くのカスタム オプションが必要な場合に GKE にフォールバックする必要があります。また、キューをリッスンするプロセスや、HTTP(S) 以外のプロトコルを使用するアプリケーションなど、長時間実行されるプロセスがある場合も、GKE がデフォルトの選択肢になります。

Cloud Functions も優れたサーバーレス デプロイ オプションですが、Cloud Run では Cloud Functions で提供されるほとんどの機能が提供され、Cloud Functions では .NET のすべてのバージョンをサポートしているとは限らないため、ここでは説明しません。

Kubernetes と GKE

コンテナに最適化した環境で実行する場合、その手段には Kubernetes とそのマネージド バージョンである GKE を使用する可能性が高くなります。要件が異なる多数のコンテナをデプロイする予定があり、各コンテナのデプロイと管理を細かく制御する必要がある場合は、Kubernetes と GKE が特に役立ちます。

Kubernetes はコンテナを大規模に実行するよう設計されており、Pod、Service、Deployment、レプリカセットなどの構成要素が用意されています。これらの構造を適切に理解して使用することには困難が伴いますが、コンテナの管理負担のほとんどを Kubernetes に移行できます。また、マイクロサービスが Service の背後で負荷分散された一連の Pod を持つ Deployment となるマイクロサービス アーキテクチャにも適しています。

Kubernetes に加えて、GKE には、Kubernetes 管理とセキュリティ機能（コンテナの分離やプライベート レジストリなど）を簡略化するためのクラスタの自動スケーリング、自動修復、自動アップグレードなどの機能があります。GKE では、クラスタのノードごとに課金されますが、GKE はコストを削減するための Spot VM をサポートしています。

GKE では、Windows コンテナと Linux コンテナの両方を管理できます。この機能は、Windows ベースのアプリケーションと最新の Linux ベースのアプリケーションの両方で単一のハイブリッド環境を維持したい場合に有用です。

Knative と Cloud Run

ステートレス .NET コンテナ、Knative、そのマネージド バージョンである Cloud Run には、サーバーレス コンテナ環境が用意されています。サーバーレス コンテナには、インフラストラクチャの管理オーバーヘッドなしでプロビジョニング、自動スケーリング、ロード バランシングなどを行えるメリットがあります。

Kubernetes クラスタにコンテナをデプロイするために、Knative には Kubernetes より上位で小規模な API サーフェスが用意されています。Knative を使用することで Kubernetes の複雑さを回避でき、コンテナのデプロイが容易になります。

Cloud Run は Knative API に従いますが、Google インフラストラクチャで実行されるため、Kubernetes クラスタは必要なくなります。Cloud Run によってコンテナのサーバーレス オプションが提供されます。Cloud Run のデフォルトでは、コンテナは自動スケーリングされ、リクエストの期間に対して課金されます。デプロイ時間は秒単位です。Cloud Run には、リビジョンやトラフィック分割などの便利な機能も用意されています。

Cloud Run for Anthos は、Knative のシンプルさと Kubernetes 運用の柔軟性を持つ Cloud Run を必要とするお客様向けの柔軟性の高いバージョンの Cloud Run です。たとえば、Cloud Run on GKE Enterprise では、コンテナを実行している基盤となるインスタンスに GPU を追加できます。また、同じ VPC 内の他の VM や GKE クラスタにアクセスすることもできます。

Cloud Run は、Pub/Sub、Cloud Scheduler、Cloud Tasks などの他のサービス、および Cloud SQL などのバックエンドと統合されています。自動スケーリングされたウェブ フロントエンドや、イベントがトリガーする内部マイクロサービスの両方で使用できます。

運用のモダナイゼーション

モダナイゼーションとは、アプリケーション コードのみに関することではありません。モダナイゼーションは、アプリケーションのライフサイクル全体（ビルド、テスト、デプロイ、モニタリング）に適用されます。そのため、モダナイゼーションについて考える際には、運用について検討する必要があります。

Cloud Build を使用すると、アプリケーションのビルド、テスト、デプロイのサイクルをモダナイズおよび自動化できます。Cloud Build は、.NET のビルダーを提供するだけでなく、Artifact Registry の脆弱性スキャナおよび Binary Authorization と統合され、不明なソースコードや安全でないリポジトリからビルドされたイメージがデプロイ環境で実行されないようにします。

Google Cloud Observability（旧称 Stackdriver）には、アプリケーションのオブザーバビリティをモダナイズできるさまざまなサービスが用意されています。

  • アプリケーション ログとシステムログ用の Cloud Logging
  • パフォーマンス モニタリング用の Cloud Monitoring
  • アプリケーション パフォーマンス管理用の Cloud Trace

Google.Cloud.Diagnostics.AspNetCore ライブラリを使用すると、ASP.NET アプリケーションのログ、指標、トレースを Google Cloud にエクスポートできます。OpenTelemetry 指標を Google Cloud にエクスポートするには、OpenTelemetry.Exporter.Stackdriver ライブラリを使用します。

チームのプロセスと文化にモダナイゼーションがどのように適用されるかの詳細については、DevOps 用の Google Cloud ソリューションをご覧ください。

次のステップ