.NET Core に向けた Microsoft Teams のジャーニー

Microsoft Teams "MiddleTier" は、Microsoft Teams のさまざまなシナリオを強化する内部サービスです。Microsoft の 10 以上のチームによって維持管理されている 700 を超える API からなる最大級のサービスです。過去 2 年間で、このサービスの 50 以上のプロジェクト (ライブラリ、テスト、アプリケーション) が .NET Standard 2.0 および .NET Core 3.1 に変換され、同等 (またはそれ以上) の機能とパフォーマンスを発揮し、現在は運用環境の .NET Core 3.1 でほぼ完全に実行され、次に .NET 6 に移行することを検討しています。この移行前は、ASP.NET Core 2.2 MVC パイプラインを使用して、.NET Framework 4.6.2 でサービスが実行されていました。これは、35 の Azure データセンターでデプロイされた Azure Service Fabricで実行されます。

MiddleTier は、毎日数百人の開発者が作業を行う機能の最大級のサービスであるため、今回の移行範囲は幅広いものでした。

移行の動機

チームが .NET Core 3.1 に移行する動機は、次のような理由からでした。

• パフォーマンスとコスト効率の向上
• .NET Framework 4.6.2 がまもなくライフサイクルを終了する可能性があります
• クロスプラットフォームのサポート
• モダン フレームワークに移行し、開発者エクスペリエンスを向上させる

.NET Core 3.1 への移行後の特典

.NET Core 3.1 への移行後、チームは次の改善点に気付きました。

• CPU が 25% 向上
• インフラストラクチャ コストを約 25% 削減
• スレッド プールの使用状況が向上しました
• .NET の年次リリースへの移行における技術的な負債と努力の削減

次のグラフは、.NET Framework と .NET Core の比較を示しています。今後、.NET 6 では、さらに改善される予定です。

アプローチ

移行全体は次の 3 段階に分けて行われました。

また、アプリケーションを .NET Framework と .NET Core にマルチターゲット化することで、両方のバイナリを用意し、.NET Core を少しずつ展開し続けることを選択しました。

学習

OData と他の REST API はルート プレフィックスを共有できません

そのサービスには、いくつかの OData エンドポイントと多くの REST エンドポイントがあります。これら 2 つは、エンドポイントに対して同じルーティング プレフィックスを共有していました。これは、.NET Framework で正常に動作するために使用されましたが、ルーティングの変更により、.NET Core では動作を停止しました。これを解決するには、OData API を別のルート プレフィックスに移動する必要がありました。

OData クライアント ライブラリのパフォーマンスに関する問題

ダウンストリーム OData API に対する呼び出しを行う OData クライアントとの HttpWebRequest パターンは、.NET Framework と比較して待機時間が長くなります。これは、フレームワークが接続をキャッシュしない .NET Core の回帰によるものです。これは、新しいバージョンの .NET で既に解決されています。

Azure Service Bus SDK に関する問題

Azure Service Bus SDK は、以前のバージョンが .NET Standard と互換性がなかったため、この移行の一環としてアップグレードする必要がありました。最新バージョンの Azure Service Bus SDK は、要求ペイロードを JSON 形式で送信しますが、以前の SDK はペイロードを XML 形式で送信します。XML ペイロードを引き続き使用するには、DataContractSerializer を使用する必要がありました。

マルチターゲット向け Service Fabric プロジェクトの問題

Service Fabric プロジェクト (sfproj) は、マルチターゲットを本質的にサポートしていません。両方のターゲット フレームワークの Service Fabric パッケージを生成するには、ビルド パイプラインで回避策を実行する必要がありました。

以前のバージョンの MimeKit NuGet に関する問題

以前のバージョンの MimeKit では、2 バイト文字に問題があるため、このシナリオでは言語固有の検証を行うことをお勧めします。アジア地域にあるデプロイにロールアウトした場合に、同様の問題が見つかりました。

クラシック ASP.NET のクセ

• .NET Core で内部とマークされた一部の.NET Framework クラスの使用を削除する必要がありました。
• バージョン 3.0 および 3.1 での ASP.NET Core の破壊的変更の記事に記載されているとおり、アクション名から MVC 非同期サフィックスが削除されました。アクション名に依存しているコード パスがある場合、動作に変化が生じる可能性があります。
• dotnet/aspnetcore#7644 GitHub の問題に記載されているように、.NET Core 3.0 以降のすべてのサーバーで同期 IO 操作が既定でオフになっています。
• StreamContent を HTTP 要求コンテンツとして送信する場合に Content.Headers に Content-Length ヘッダーが設定されていません。ダウンストリーム呼び出しからエラーが発生する可能性があります。
• .NET Framework は文字列に対して安定したハッシュ コードを生成しますが、.NET Core は生成しません。
• System.ComponentModel.DataAnnotations 名前空間の Required の動作の属性は、.NET Core では異なります。.NET Framework では、この属性は null 以外のフィールドのモデル検証を行いませんが、.NET Core では検証を行います。

将来

.NET の新しいリリースでは、生産性とパフォーマンスが大幅に向上し、回復性、拡張性、パフォーマンス、安全性なサービスを構築する Microsoft の目標の達成に引き続き貢献しています。チームは、次に .NET 6 にアップグレードすることで、.NET で行われた改善を引き続き活用する予定です。