2022-10-03: Experimental WebTransport over HTTP/3 support, .NET 6 Migration Journeys

トピックス

Experimental WebTransport over HTTP/3 support in Kestrel - .NET Blog

https://devblogs.microsoft.com/dotnet/experimental-webtransport-over-http-3-support-in-kestrel/

Kestrel での WebTransport over HTTP/3 の実験的サポートについての記事。

.NET 7 RC 1 の Kestrel で WebTransport over HTTP/3 の実験的サポートが導入された。WebTransport は UDP を使用する QUIC と HTTP/3 に基づいたストリーミング接続で、従来までの HTTP/2 での一つの接続による WebSocket の複数ストリームと異なり、あるストリームがパケットドロップ等の理由でブロックされた場合でも他のストリームがブロックされるといったことを避けられるといったメリットがある。

WebTransport を有効にするにはプロジェクトファイル (.csproj) で実験的機能の設定を有効化と、WebHost で HTTP/3 をリッスンする必要がある。

Microsoft Teams’ Infrastructure and Azure Communication Services’ Journey to .NET 6 - .NET Blog

https://devblogs.microsoft.com/dotnet/microsoft-teams-infrastructure-and-azure-communication-services-journey-to-dotnet-6/

Microsoft Teams と Intelligent Conversation and Communications Cloud (IC3) と呼ばれるリアルタイム通信会話の基盤を .NET Framework から .NET 6 へと移行した事例の紹介。

動機として Azure のコスト削減、パフォーマンス向上、サービスとネットワークのモダナイゼーション、エンジニアリングの生産性の向上をあげている。

IC3 は200を超えるマイクロサービスで構成され、現在は1/3以上のサービスが .NET 6 で実行されている。以降のアプローチとして2つのマイクロサービスでアプローチの構築と検証、基盤のサポートとライブラリーの更新を行い、前提と移行手順を検証したのち、残りのサービスに展開した。

その際効率の向上の測定のため Q-Factor 分析を行ったとのこと。Q-Factor とは Q=(合計作業量)/(合計使用率) で導き出される値で、インスタンスが一定期間の使用率あたりに可能な仕事量を表すもので、ここでは CPU を使用率として、リクエスト数を作業量として定義して計測している(つまり 1,000 reqs を CPU 50% で処理した場合は Q = 2,000 で、2,000 reqs を CPU 50% で処理できれば Q = 4,000 となる、といった形で比較できる)。

記事ではマイクロサービスのいくつかのドメインでの結果を紹介している。

メッセージングドメインの API サービスを .NET 6 に移行した際の結果としては大きくは CPU 使用率の削減、Azure の支出の削減、Azure のコンピューティングのコストの削減の効果があった。現在 Dynamic PGO を適用してさらなるコスト削減を目指しているところ。

次に通話ドメインのブローカーサービスを .NET 6 に移行した結果の紹介で同様に CPU コアの削減と Azure の支出の削減、API レイテンシーの向上の効果があった。CPU 使用率の削減は当初は .NET Core 3.1 と .NET Framework でのベンチマークの結果、.NET Core のほうが高かったがいくつかの最適化を行うことで .NET Core でより良いパフォーマンスが得られ、.NET 6 へ移行しボトルネックを特定できる仕組みなどを用意した結果、最終的に大幅な改善が得られた。レイテンシーは API によっては 10ms 前後から 5ms 前後へと平均 55% の改善が得られたとのこと。

最後は会議ドメインについて。会議仮想アシスタントと会議自動応答サービスが .NET 6 へと移行され、会議自動応答サービスでの結果を紹介している。ここでも CPU コアの大きな削減 (98%) や Azure の支出の削減、CPU 使用率の削減や応答時間の短縮といった効果があったとのこと。

Microsoft Commerce's .NET 6 Migration Journey - .NET Blog

https://devblogs.microsoft.com/dotnet/microsoft-commerce-dotnet-6-migration-journey/

Microsoft Commerce という製品やサービスのカタログからライセンス情報の保持、税額の計算などビジネス、コンシューマー問わず Microsoft の取引にかかわるサービスのセットで .NET 6 の移行を行った事例紹介。

記事では Microsoft Commerce のグローバルルックアップサービス (GLS)と呼ばれる、サービスを分割し、ユーザーのデータの場所を近さに応じてマッピングするサービスを移行した例を紹介している。

移行には .NET Framework から .NET Core に加え、実行プラットフォームを Windows から Linux (Kubernetes) へ移す必要になった。

Windows から Linux
.NET Framework から .NET Core (3.1 あるいは .NET 5、現在は .NET 6)
コンテナーと Kubernetes へのプラットフォームシフト (VM からの脱却)
ビルドとリリースシステムの変更によりセキュリティーおよびコンプライアンスの向上、コンテナー化されたアプリケーションをサポート
移行に伴うプラットフォームと .NET の拡張と改善の利用とパートナーの依存関係を含むメリットの享受

移行の結果として大きなコストの削減と CPU コアの削減といったコストの削減があったが、.NET 以外の様々な変更も含むため、より具体的な .NET Framework から .NET Core への移行による効果例を探した結果、サービスの待ち時間の大幅な短縮といった効果が見られたとしている。

さらに .NET 5 から 6 への移行も行われ、スレッドプールの改善、接続管理の改善、ランタイム内部の例外の削減といった効果が見られたとのこと。

記事では移行に関する知見がいくつか紹介されている。

依存関係のマッピングと移行経路の評価(.NET 機能への置き換え、新しい依存関係への置き換え、依存関係を使用しての移行、独自の実装への置き換え)には広範囲の作業が必要となり時間をかけている。

また移行時に独自ソリューションを .NET のベストプラクティスへの置き換えを試みたこと。例えばオブジェクトプーリングの機構は ObjectPool クラスを使用する、RecyclableMemoryStream ライブラリーを使用するといった形で独自実装からの置き換えを、APM ベースの非同期モデルは TAP へと変換するといった形での対応を行った。

サービスは .NET Core へと移行して、Windows から Linux に移行することで Linux で動作させるために必要な対応が必要となった。"Windows 前提" であることはビルド、ツール、監視やトラブルシューティングといった部分でもぐりこむことがある。例えばフォルダーのスラッシュ(/ と \) や COM の依存、Windows API の使用といった様々であり、これらはプラットフォーム依存しない形に変更する必要がある。サービスを複数のプラットフォームで End-to-End で早期にテストすることで見つけ出すことが重要であること。

HTTP.sys から Kestrel への移行により Linux と Kubernetes での動作とクリーンなコードへと代わり、インメモリーキャッシュのために Win32 ファイル API を使用してファイルシステムへの読み書きを行っていたコードを UnmanagedMemoryStream へと置き換えるといったことをしている。

最後にクロスプラットフォームによるツーリングについて。使い慣れた Windows のデバッグや調査のためのツールが .NET Core や Linux でも動作するわけではないことから、 .NET の標準ツール (dotnet counters, dotnet dump, dotnet trace など) に関する知識を溜めたとのこと。新しく使えるようになったツールとして .NET メトリクスサイドカーがあり、.NET 6 移行の dotnet monitor を Docker イメージに含めサイドカーとして動作させることで稼働中のプロセスのメトリクスやダンプ、トレースの取得が可能となった。

Fall 2022 Updates for Xamarin, Hello iOS 16 and Android 13 - Xamarin Blog

https://devblogs.microsoft.com/xamarin/xamarin-ios-16-android-13-updates/

Xamarin の2022年秋のアップデートのアナウンス。

Visual Studio 2022 17.3.5 と Visual Studio for Mac 2022 17.3.6 で Xamarin が iOS 16 と Android 13 に対応した。

Xamarin SDK は2024年5月1日までのサポートとなり、最終的なプラットフォームバージョンは iOS 16 と Android 13 となる。これ以降のバージョンについては .NET の一部として提供されるため移行が必要となる。

記事では .NET 6 へのアップグレードについてとロードマップを改めて紹介している。

Visual Studio for Mac 17.4 Preview 2.1 is now available - Visual Studio Blog

https://devblogs.microsoft.com/visualstudio/visual-studio-for-mac-17-4-preview-2-1-is-now-available/

Visual Studio for Mac 17.4 Preview 2.1 がリリースされた。

このリリースではデバッグ中のワンクリックでのリスタート、エディターのドラッグアンドドロップによるサイドバイサイドのようなシェル体験の改善、エディターの C# 11 に関する機能のサポートやハイライティング、行間設定といった改善のほか、Apple Silicon 環境へのインストールに Rosetta が不要となった。