1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@iccb1013(Xusheng Cao)

GCの揺らぎから安定した低レイテンシへ：ShenDeskにおけるSpanとMemoryの高性能最適化実践

1
Posted at

背景

ShenDesk は、企業向けのリアルタイム・オンラインカスタマーサポートおよび訪問者行動トラッキングシステムであり、SaaSとオンプレミス双方のデプロイに対応しています。.NETをベースに構築されており、その核となるのは高コンカレンシーなWebSocketチャネル、リアルタイムメッセージ処理、ビジター・トラッキングのデータフロー解析、そして拡張性の高いOpen API群です。

私はShenDeskの開発者です。システムが初期の「とりあえず動く」フェーズから、現在の商用環境を安定して支えるレベルに到達するまでには、数多くのパフォーマンス・ボトルネックやアーキテクチャの再構築を経験してきました。

こうした実際の現場におけるエンジニアリング課題に直面する中で、私は.NETのメモリモデルやハイパフォーマンス・プログラミング技術の深掘りを進めることになったのです。

はじめに

高コンカレンシーと低レイテンシが当然の要求（Default requirement）となった今日、現代の .NET アプリケーションにおいて「無意識なメモリ確保（Allocation）」はもはや許容されがたいものとなっています。特にビッグデータ処理、ファイル解析、ネットワーク通信、そしてリアルタイムシステムにおいて、頻繁な配列コピーや文字列の生成こそが、パフォーマンス・ボトルネックの真の正体であることが少なくありません。

私たちは ShenDesk のサーバーアプリケーションを開発する際、ある典型的な課題に直面しました。
高頻度な WebSocket メッセージ処理と Visitor Tracking のデータストリーム解析において、ピーク時に大量の短寿命オブジェクトが発生していたのです。その結果、GC（ガベージコレクション）への負荷が高まり、顕著なレイテンシのスパイク（ジッター）が発生、スループットが制限されるという事態に陥りました。

従来の「配列 ＋ 文字列結合」というパターンを踏襲し続けていては、最適化の余地は極めて限定的です。

これこそが、C# に Span<T> と Memory<T> が導入された真の意義です。

これらの型を使用することで、追加のヒープ割り当てを発生させることなく、メモリの切り出し（スライス）や操作が可能になります。スタック割り当てと制御されたメモリ参照メカニズムを通じて、以下のメリットを享受できます：

  • 不必要な配列コピーの回避
  • GC 発生頻度の抑制
  • レイテンシ・スパイクの低減
  • スループットの安定化

ShenDesk のリアルタイムメッセージチャネルとプロトコル解析レイヤーにおいて、Span<T> の導入は一時的なメモリ確保量を劇的に削減し、高負荷環境下でのシステムの安定性を飛躍的に向上させました。

本記事では、実際のエンジニアリング現場のシナリオに基づき、以下について深掘りします：

  • Span<T> と Memory<T> の低レイヤーにおける動作原理
  • これらがいかにしてメモリ確保を回避するのか
  • Web API / WebSocket / I/O 処理における正しい活用方法
  • 本番システムにおける具体的なパフォーマンス改善効果

もしあなたがハイパフォーマンスな .NET システムを構築している、あるいは GC ジッターや異常なレイテンシに悩まされているのであれば、これら 2 つの型を理解することはもはや「応用テクニック」ではなく、エンジニアとしての「必須科目」と言えるでしょう。

Spanとは何か？

Span<T> は、連続したメモリ領域を表す軽量な**値型（Value Type）**です。従来の配列操作とは異なり、Span を利用することで、データのコピーを発生させることなくメモリ上のデータに直接アクセスし、操作することが可能になります。

Span は、以下のような多様なメモリソースを指し示すことができます：

  • 配列（Array）
  • スタックメモリ（Stack memory）
  • ネイティブメモリ（非管理メモリ / Unmanaged memory）
  • 文字列（String）

Span の最大の利点は、不必要なメモリ確保（Allocation）を回避できる点にあります。従来の配列や文字列操作では、新しいオブジェクトを生成してデータをコピーするのが一般的でしたが、Span は既存のメモリ上で直接動作するため、アプリケーションの効率を劇的に向上させます。

// 例：Span を使用した配列操作
int[] array = new int[100];
Span<int> span = array.AsSpan();

// 元の配列を直接書き換える
span[0] = 10;
span.Slice(10, 20).Fill(1); // スライス機能で範囲を指定して値をフィル

Span の重要性

従来のサブ文字列（Substring）の取得や配列のコピーといった操作は、通常、メモリ上に新しいオブジェクトを生成します。こうした過剰なメモリ確保（アロケーション）は、ガベージコレクター（GC）の負荷を増大させるだけでなく、アプリケーション全体のパフォーマンス低下を招く要因となります。

Span は、データをコピーするのではなく、既存のメモリに対する「ビュー（View）」を作成することでこの問題を解決し、以下のメリットをもたらします：

  • 実行速度の向上
  • メモリ使用量の削減
  • 全体的なシステムパフォーマンスの底上げ
  • GC（ガベージコレクション）発生頻度の抑制

Span は、特に以下のようなハイパフォーマンスが要求されるシナリオで真価を発揮します：

  • Web サーバー
  • データパーサー（解析器）
  • リアルタイムシステム
  • 大規模データ処理

Span の主な特徴

Span は、高効率なメモリ処理を実現するための理想的な機能を備えています：

  • 非ヒープ割り当て：Span 自体はヒープ上に割り当てられないため、オーバーヘッドが極めて小さい。
  • スライス（Slicing）のサポート：データをコピーすることなく、配列の特定範囲を直接操作可能。
  • 型安全性とメモリ安全性：安全なアクセス手法を提供し、バッファオーバーフローなどのリスクを防止。
  • GC 負荷の軽減：アロケーションを抑えることで、ガベージコレクターのワークロードを削減。
  • 大規模データへの最適化：膨大なデータセットを扱う処理において、極めて高いパフォーマンスを発揮。
// 例：Span によるスライス操作
byte[] buffer = new byte[1024];
Span<byte> bufferSpan = buffer.AsSpan();

// 前半 512 バイトを処理
ProcessData(bufferSpan.Slice(0, 512));

// 後半 512 バイトを処理
ProcessData(bufferSpan.Slice(512));

Memoryとは何か？

Memory<T> は Span<T> と似た性質を持ちますが、より幅広いシナリオ、特に非同期プログラミング（Async programming）での利用を想定して設計されています。主な違いは以下の通りです：

  • 同期と非同期：Span は同期メソッド内でのみ利用可能（スタック割り当て制限）ですが、Memory は非同期メソッド内でも利用でき、フィールドとして保持することも可能です。
  • ライフサイクル：Memory はヒープ上に存在するメモリを表現できるため、非同期操作をまたいでデータを渡すことができます。
  • パフォーマンスと柔軟性：Memory は Span に比べるとわずかにオーバーヘッドがありますが、高いパフォーマンスを維持しつつ、優れた柔軟性を提供します。
// 例：非同期メソッドでの Memory の使用
async Task ProcessDataAsync(Memory<byte> dataMemory)
{
    // 非同期でデータを処理（.Span プロパティで Span として操作可能）
    await Task.Run(() => ProcessData(dataMemory.Span));
    
    // 後続の処理のために Memory をフィールドに保存することも可能
    _storedMemory = dataMemory;
}

Span を使用すべきシーン

以下のようなシナリオでは、Span が最適な選択肢となります：

  • 同期コードにおける配列、バッファ、または文字列の処理
  • データ解析（パース）：プロトコル、ファイルフォーマット、シリアライズデータの解析など
  • ファイル操作：大容量ファイルの効率的な読み書き
  • 大規模データセット：極めて高いスループットが要求される処理
  • パフォーマンス・クリティカルな箇所：メモリ最適化がシステムの成否を分ける重要なパス
// 例：Span を使用した文字列のパース
string s = "127.0.0.1:8080";
// 文字列から ReadOnlySpan を作成（新たなアロケーションは発生しない）
ReadOnlySpan<char> span = s.AsSpan();

int colonPos = span.IndexOf(':');
if (colonPos > 0)
{
    // Slice を使用して、コピーを作成せずに特定範囲の参照を取得
    var ipSpan = span.Slice(0, colonPos);
    var portSpan = span.Slice(colonPos + 1);
    
    // IPとポートに対する処理
}

Memory を使用すべきシーン

以下のようなシナリオでは、Memory を選択するのが最適です：

  • **非同期メソッド（async/await）**内でメモリデータを扱う場合
  • メモリへの参照をフィールドに保持したり、メソッド間で受け渡したりする必要がある場合
  • 非同期 I/O 操作：バックグラウンドでのファイル処理など
  • パイプライン処理：データストリームやパイプラインの構築
  • バックグラウンド処理：データを長時間保持（リテイン）して処理する場合
// 例：Memory を使用した非同期ファイル処理
async Task<Memory<byte>> ReadFileAsync(string path)
{
    // 非同期でバイト配列を読み取り、Memory としてラップして返す
    // （Memory は非同期操作の境界を越えて受け渡しが可能）
    byte[] buffer = await File.ReadAllBytesAsync(path);
    return new Memory<byte>(buffer);
}

実践的な活用シーン

Span と Memory は、すでに多種多様なハイパフォーマンス・シナリオで広く活用されています：

  • 高性能 Web API：ASP.NET Core の内部実装におけるパフォーマンス向上
  • ファイル処理システム：大容量ファイルの効率的な処理
  • ネットワークアプリケーション：プロトコル解析およびパケット処理
  • リアルタイムシステム：低レイテンシなデータ処理
  • ゲーム開発：効率的なメモリ操作
  • パーサーとシリアライザー：高速なデータ変換

例えば、ASP.NET Core はその内部パイプラインにおいて、リクエスト処理のパフォーマンスを最適化するために Span を徹底的に活用しています。特に以下の処理でその真価を発揮しています：

  • リクエストヘッダーの解析（パース）
  • URL デコード
  • JSON のシリアライズ / デシリアライズ
  • レスポンスの書き込み

パフォーマンス上のメリット

Span と Memory の導入は、システムに劇的なパフォーマンス向上をもたらします：

  • メモリ確保（アロケーション）の削減：不必要なオブジェクト生成やデータのコピーを徹底的に回避します。
  • 実行速度の向上：メモリを直接操作することで、中間処理のオーバーヘッドを最小限に抑えます。
  • GC 負荷の軽減：ガベージコレクションの発生頻度と停止時間（ポーズタイム）を短縮します。
  • リソース利用の効率化：高負荷なアプリケーションにおいて、より安定した動作を実現します。

ベンチマークデータによると、特定のシナリオで Span を適用した場合、以下のような効果が得られています：

  • メモリ割り当てを 90% 以上削減
  • 実行速度が 2 〜 5 倍向上
  • GC による停止時間を大幅に短縮
// パフォーマンス比較例：文字列処理
// 従来の手法 - 新しい文字列が生成（Alloc）される
string substring = bigString.Substring(start, length);

// Span を使用 - 追加のアロケーションはゼロ
ReadOnlySpan<char> span = bigString.AsSpan().Slice(start, length);

おわりに

ハイパフォーマンスの追求は、単なる「テクニックの誇示」ではなく、一つのエンジニアリングとしての姿勢です。

Span<T> と Memory<T> が本質的に解決するのは、単なるメモリ確保の問題ではありません。それは、システム内におけるデータの流れ方——「データは本当にコピーが必要か？」「ヒープ割り当ては不可避か？」「GCの負荷を源流から断てるのではないか？」——を再考させてくれるものです。

「メモリのライフサイクル」と「アロケーションコスト」の視点でコードを見つめ直したとき、多くの「パフォーマンス・ボトルネック」と呼ばれていたものの正体は、実は無意識なプログラミング習慣の積み重ねであったことに気づくはずです。

ShenDesk の継続的な進化において、こうしたマインドセットの転換がもたらした収益（ベネフィット）は、単なるマイクロ・最適化を遥かに凌駕するものでした。高コンカレンシーな環境下での安定性は増し、レイテンシの曲線はより平滑になり、リソースの利用効率はより制御可能なものとなったのです。

もし、あなたが現実のユーザーを支える .NET システムを構築しているのであれば、私のアドバイスは非常にシンプルです。
パフォーマンス問題が顕在化してから手を打つのではなく、早い段階でこれらの低レイヤーの能力を理解し、「不必要なアロケーションの回避」をデフォルトの原則とすることです。

エンジニアリングの品質は、リリースした瞬間に決まるのではありません。コードを書くたびに行う、日々の「選択」の積み重ねこそが、その品質を決定づけるのです。

👋 最後に

現在も ShenDesk は進化を続けています。
もしあなたがライブチャットシステムを開発・導入した経験があるなら、
リアルタイム更新、負荷分散、柔軟なデプロイをどのように実現したか、ぜひ教えてください。

一緒に語りましょう。

🚀 ぜひお試しください

🌐 公式サイト：https://shendesk.com
📘 ドキュメント：https://docs.shendesk.com

オンラインでも、自分のサーバーでも、無料で体験できます。
セルフホストやリアルタイム通信、カスタマーエクスペリエンス改善に関心のある開発者からのフィードバックをお待ちしています。

UI スクリーンショット

ビジター側：高速読み込み＆メッセージロスなし

ビジター側

オペレーター側：信頼性が高く、機能も充実

オペレーター側

Web管理画面

Web管理画面

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?