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

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

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

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

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

.NET アプリケーションのコンテキストにおいて、レガシーおよびモダンとは何でしょうか?この質問に対して完全に答えることは簡単ではありません。どのアプリケーションにもレガシーとモダナイゼーションの異なるニーズがあります。ただし、レガシー アプリケーションはいくつかの一般的な制限を共有しています。

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

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

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

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

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

  • マネージド サービスと統合することで管理オーバーヘッドを最小限に抑えます。
  • .NET Core とコンテナによる完全なモビリティが実現され、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 には、IIS、SQL Express、ASP.NET を含む Windows Server VM を取得する ASP.NET Framework ソリューションなど、Compute Engine にデプロイする準備ができているソリューションもあります。

同様に、SQL Server インスタンスをSQL Server イメージから開始できます。または優れたマネージド ソリューションであるCloud SQL for SQL Serverに直接アクセスできます。

Google Cloud には、オンプレミスの VMware VM を Google Cloud の VMware 環境に移行するのに役立つ Migrate for Compute EngineVMware 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)により変わりました。

.NET Framework アプリケーションを .NET Core に移行せずに、コンテナのメリット(アジリティ、ポータビリティ、制御など)を得るには、Windows コンテナを使用する方法もあります。.NET Framework のバージョンに応じて、対象とする適切な OS を選択する必要があります。また、Windows コンテナの一部の Windows スタックはサポートされないことを覚えておく必要があります。このアプローチの制限と代替方法については、このドキュメントの後半の .NET Core と Linux のコンテナをご覧ください。

.NET Framework アプリケーションを Windows コンテナにコンテナ化した後、Kubernetes クラスタで実行することをおすすめします。Kubernetes は、コンテナ Pod がダウンしたときの検出と再作成、Pod の自動スケーリング、自動ロールアウトまたはロールバック、ヘルスチェックなどの標準機能を提供します。GKE は、クラスタの自動スケーリング、リージョン クラスタ、高可用性コントロール プレーン、Anthos を使用したハイブリッドおよびマルチクラウドのサポートなどの機能を追加します。GKE または Anthos を使用する場合は、Migrate for Anthos and GKE を使用して Windows VM のコンテナへの移行を簡略化し、加速できます。Migrate for Anthos and GKE では、アプリケーションの書き換えや再設計を行わずに、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 に移行するため、価値ある投資といえます。これらのサービスと統合しながら、Google Cloud .NET クライアント ライブラリTools for Visual StudioCloud Code for Visual Studio Code により、.NET エコシステムとツールの維持が可能です。

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

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

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

.NET Core は、.NET Framework の最新のモジュール式バージョンです。Microsoft のガイダンスでは、.NET Core が .NET の今後のビジョンであることを示しています。Microsoft は .NET Framework をサポートする予定ですが、新しい機能は .NET Core(最終的には .NET 5)にのみ追加されます。引き続き Windows で稼働する場合でも、新しい開発はすべて .NET Core で行われる必要があります。

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

.NET Framework アプリケーションを .NET Core に移行する

.NET Core への移行を開始するには、.NET Framework から .NET Core への移行の概要を確認することをおすすめします。.NET Portability Analyzer.NET API Analyzer などのツールを使用すると、アセンブリと API が移行可能かどうかを特定するのに役立ちます。dotnet try-convert などの他の移行ツールも役に立ちます。

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

文化の変革

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

モノリスの分割

.NET Framework から .NET Core へ移行する際には、次のようないくつかの質問が寄せられます。

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

これらの質問にどのように回答するかに関しては、各アプローチに関連する利点、時間、費用を考慮する必要があります。一度にすべてを書き換えない、バランスの高いアプローチを採用することは良いことです。また、新しいサービスを .NET Core で作成してから、機会がある場合に、既存のモノリスを .NET Core の小さなサービスに分割することもできます。計画にあたっては、次のホワイトペーパーを参考にしてください。

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

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

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

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

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

原則として、HTTP リクエストを処理するマイクロサービスを作成する場合は、可能ならば Cloud Run にデプロイし、Kubernetes エコシステムを維持する、またはより多くのカスタム オプションが必要な場合に GKE にフォールバックする必要があります。また、キューをリッスンするプロセスや、HTTP(S) 以外のプロトコルを使用するアプリケーションなど、長時間実行されるプロセスがある場合も、GKE がデフォルトになります。App Engine フレキシブル環境は、WebSocket のサポートや VPC ネットワークへの接続など、いくつかの制限により Cloud Run を使用できない場合、またはアプリケーションが Kubernetes の複雑さを正当化しない場合のみ使用することをおすすめします。

App Engine スタンダード環境と Cloud Functions も、サーバーレス デプロイのオプションとして優れていますが、現在 .NET Core をサポートしていないため、ここでは説明しません。

App Engine フレキシブル環境

App Engine フレキシブル環境は、.NET Core など、さまざまな言語で書かれたウェブ アプリケーションを直接実行するためのプラットフォームです。App Engine は、.NET ランタイムを持つ Docker コンテナ内に .NET Core アプリケーションをインストールして実行します。このランタイムをカスタマイズする場合、App Engine に独自の Dockerfile を組み込むことができます。App Engine は引き続き VM ベースの Compute Engine インスタンスを使用しますが、App Engine がこれらの VM を管理します。フレキシブル環境には、自動スケーリング、リビジョン、トラフィック分割などの機能があります。フレキシブル環境では、単一のアプリケーションで複数のサービスを実行できるため、マイクロサービスのアーキテクチャで役立ちます。

ウェブ フロントエンドまたは少数の類似したコンテナをデプロイする場合、App Engine はオプションです。ただし、App Engine では、通常はデプロイ時間が他のオプションよりも遅くなり、アプリケーションを使用しない場合でも、VM ごとに課金されます。

Kubernetes と GKE

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

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

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

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

Knative と Cloud Run

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

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

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

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

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

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

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

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

Google Cloud のオペレーション スイート(旧称 Stackdriver)には、アプリケーションのオブザーバビリティをモダナイズできるサービスがいくつか用意されています。

Google.Cloud.Diagnostics.AspNetCore ライブラリを使用すると、Google Cloud のオペレーション スイートを ASP.NET Core アプリケーションに簡単に統合できます。OpenTelemetry 指標をオペレーション スイートにエクスポートするには、OpenTelemetry.Exporter.Google Cloud のオペレーション スイート ライブラリを使用できます。

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

次のステップ