ASP.NET Coreアプリを軽くする！開発者が知らない7つの性能改善のヒント

読者の方にちょっとした注意を。この記事では、さまざまなプロジェクトで見かけたパターンをもとに、アーキテクチャ設計と最適化についていくつかの手法や考え方を紹介している。で、その中に出てくる数字っぽい話はあくまで雰囲気と思ってほしい。現実には環境によって結果が全然違うこともあるから、自分のアプリでちゃんと検証したほうがいいかもしれない。

さて、高速なASP.NET Coreアプリケーションを目指す時、多くの人が細かい部分ばかり気にしがちだ。LINQよりforeach使ったらどうとか、文字列連結を工夫するとちょっとだけ速かったりとか、メモリの扱いを変えてみたり。でも、こういう小さい調整だけで性能が劇的に変わったという話はあまり耳にしない。

むしろ開発初期の構造設計――たとえばクリーンアーキテクチャの採用方法やサービスごとのライフサイクル管理みたいな、大枠で決めること――これらが後々になって響いてくることもあるようだ。どこまで影響するかはケースバイケースだけど、ほんの数割くらい差が生じた例もちらほら聞く。

まあ正直言って構造次第で伸び代は大きかったり小さかったり曖昧なんだけど、それでも「何となく」設計してしまうよりは意識して選んだほうが良い方向に向かいやすい、と感じている人も多そうだ。

要するに細かなコード書き換えよりも、土台になる建て付けこそ優先した方が長期的には役立つ場面も少なくない――そんなところかな。

.NET Coreアプリケーションのパフォーマンスについて、単なる構文の話を超えて、少し奥深い部分――つまり設計そのものに視点を移してみたくなる時がある。クリーンアーキテクチャというもの、聞いたことがある人も多いはず。あれって、保守性とかテストのしやすさに重きを置いてるけど、その分構造が複雑になりやすい印象もある。ただ、それがパフォーマンス面でどう影響するか…実際には結構曖昧なところ。

例えばASP.NET CoreでよくあるAPIの設計――ざっくり言えば、
コントローラー → サービス → リポジトリ → データベース
みたいな階層になるケースが目立つ。各層ごとにモデル（データ構造）が違ったりして、そのたびマッピング処理が発生する仕組みらしい。このへん、ちょっとしたAPIでもレスポンス遅延につながることが観察されているっぽい。

実際、「顧客データを取ってきて返すだけ」みたいなシンプルなエンドポイントですら、一部では百ミリ秒ちょっとくらいかかる例もちらほら見かける。そのうちDBクエリ自体はほんの数十ミリ秒前後で終わっていることも多くて、「え？じゃあ残りは？」と疑問に思う場面も出てきたり。

プロファイリングしてみると、大まかにはこんな感じ：
・オブジェクト間マッピングで何十ミリ秒（七十ミリ秒弱？）
・依存解決処理（DIコンテナ）が約三割くらい消費
・バリデーションやビジネスロジック部分で四分の一程度時間を取られてしまう

このあたり、全部合わせると意外と馬鹿にならない。それでも「もうクリーンアーキテクチャやめよう！」とはならず、むしろ工夫次第で改善余地はいくらでも見つかる印象。捨てなくても大丈夫そう。

対策としては…例えばレイヤーごとの責務整理だったり無駄なマッピング減らしたり、本当に必要な依存だけ注入するなど。大幅な変更じゃなくても、小さめの調整から始めればそれなりに応答速度アップできそうだ――そんな声もちらほら聞こえてくる。

選択的にモデルを隣接レイヤー間で使い回すことで、どうもマッピングの負担がぐっと減ることがあるみたいだ。依存関係を深く重ねず平坦にしたり、読み書きを分けてリード側が無駄な層をすっ飛ばせるようなCQRSの仕組みも、それなりに効果が出やすい手法として語られている。ただ、どれくらい速くなるかはアプリケーションの構造や元々の設計によって幅がありそう。よく例に挙げられるケースではレスポンス時間が三割くらいまで短縮されたとか聞いた覚えがある。たとえば百数十ミリ秒掛かっていた処理が、半分よりもうちょっと下くらいになる感じ。

以前だとサービスメソッドは依存先も多くて、あれこれマッピングしながら進める流れだったんだけど――

// こんな感じで何段階も経由してた

public async Task<CustomerResponseDto> GetCustomerAsync(int id)

{

    var customerEntity = await _customerRepository.GetByIdAsync(id);

    var customerModel = _mapper.Map<CustomerModel>(customerEntity);

    await _validationService.ValidateCustomerAsync(customerModel);

    return _mapper.Map<CustomerResponseDto>(customerModel);

}

最近はクエリーの読み取り専用ハンドラで直接DBからDTOへ射影するパターンも見かける。

// CQRS的なクエリハンドラ

public async Task<CustomerResponseDto> Handle(GetCustomerQuery query)

{

    // 途中を省いて直接返却

    return await _dbContext.Customers

        .Where(c => c.Id == query.CustomerId)

        .Select(c => new CustomerResponseDto { 

            Id = c.Id, 

            Name = c.Name, 

            // 他にもプロパティ色々

        })

        .FirstOrDefaultAsync();

}

---

サービスのライフタイム設定（シングルトン・スコープド・トランジェント）が地味に全体性能へ響く場面って意外と多い気もする。ASP.NET Coreだと、この辺りちゃんと考えないまま実装すると、後から記憶以上にメモリ消費やスループット落ちてたりするケースがちらほら。

ちなみにサービス解決時のオーバーヘッドについてテストするとき、一万件ほど連続でリクエスト投げて同時接続百本くらい走らせたり…そんなベンチマーク例もあるにはある。

// テスト: 1万リクエスト & 100並列コネクション、それぞれ15個ぐらい異なるライフタイムサービス解決して利用

結果を見ると結構大きめの違いになって表れることもある。ただ、その「劇的」と言えるほどなのかどうかは状況次第かなと思う。

サービスのライフタイムを見直してみると、たしかに一部のサービスをシングルトンとして扱うことで、体感としては七割近くスループットが上がったという話も耳にしたことがある。だけど、これって環境やアプリの構造によってけっこう違いそうで、一概には言えないかもしれない。実際、自前のアプリケーションでBenchmarkDotNetみたいなツールを使って計測してみたほうが確実だと思う。

どういうサービスをどんなライフタイムで登録するか、その辺りになると人によって意見は分かれるけど、大まかな指針はいくつか知られている。例えば、多くの場合データベースとのやり取りなんかはスコープドが普通だし、依存関係にスコープドなものがなければ無理せずシングルトンでもいいんじゃないかな、といわれたりもする。トランジェントについては、毎回状態を変えたいような場合だけ必要になるとか聞いたことある。

コード例だと、キャッシュサービスや設定値まわり、それからマッパーとかロガーみたいなのはシングルトンで登録されていたりする。一方でDBコンテキストやユーザー関連のサービスなんかはスコープドになっていて、ファイル処理とか通知ビルダーみたいな一回限りの仕事にはトランジェント…そんなイメージだったと思う。

さてミドルウェアの順番だけど、この順序次第でレスポンス速度に差が出ることもあるらしい。たとえばSaaS系のシステムだと、一日のリクエスト数が膨大になるケースもあって、その中には静的ファイルやヘルスチェック用の通信など、認証なんて全然不要なアクセスも混じっているとか。それなのに認証ミドルウェアを早めに配置しちゃうと、本来通さなくてもいいリクエストまで全部認証処理されてしまい無駄という声も出る。

昔よく見た構成ではHTTPSリダイレクト→認証→認可→静的ファイル→ルーティング…みたいな流れだったんだけど、それだと静的コンテンツにも全部認証フィルターが掛かっちゃう。でも最近では、「静的ファイル配信はもっと前段階」「ヘルスチェックなんてローカルからなら素通し」みたいな書き方に変える事例も増えてきた。

つまりHTTPSリダイレクトした後すぐ静的ファイルへ行くようにして、そのあとで本格的なルーティングや必要ならヘルスチェックへの特別対応を書いておき、そのあとようやく認証・認可処理…こんな順番になっていたりする。これによって一部ケースでは無駄な計算資源消費を抑えられる可能性がありそう。ただし全体への影響度合いは運用条件によるので、一概には言えない部分も残るようだ。

なんかね、ミドルウェアの順番をちょっといじるだけで、アクセスがやたら多いアプリの場合はコスト面とか速度で意外と差が出るって話をどこかで聞いたことがある。実際のところは、自分の環境でApplication Insightsみたいな監視ツールを使って様子を見るほうが確かっぽい。まあ、全部一概には言えないけど。

.NET 6からだったかな？最小API（Minimal API）っていう書き方が目立つようになったんだよね。たいてい「記述量が減る」程度に思われてるけど、パフォーマンス面でも少し注目しても良さそう。細かい数字までは覚えてないけど、人によっては体感できるくらい違うらしい。

例えば似たような機能――天気予報を返すAPI――なんだけど、昔ながらのコントローラー方式と最小API方式、それぞれこんな感じ。

// 伝統的なコントローラー
[ApiController]
[Route("[controller]")]
public class WeatherController : ControllerBase
{
[HttpGet]
public IEnumerable

 Get()

    {

        return GenerateForecasts();

    }

}



// 最小API

app.MapGet("/weather", () => GenerateForecasts());



これだけ見ると、「ただ短く書けるだけじゃ？」って思うかもしれない。でも現場によっては負荷対策とか運用コストとか、その辺りにも関係してくることもあるみたい。もちろん絶対こうなるとは限らないし、ちゃんと計測して判断するのが無難かも。まあ全部鵜呑みにせず、その都度確かめてみるくらいでいいんじゃないかな、と時々考える。