Cassandraは、高可用性とスケーラビリティを重視した分散データベースとして知られています。しかし、高負荷環境下でのパフォーマンスやクラスタの安定性を確保するためには、佇列深度（Queue Depth）、背圧（Backpressure）、**デッドライン（Deadlines）**といった概念の理解と適切な設計が不可欠です。本記事では、これらの技術要素がどのように負荷分散を実現し、クラスタの安定性と公平性を向上させるかを解説します。
Cassandraでは、すべてのリクエストが**ネイティブリクエストプロセッサ（native request CU）**によって先進先出（FIFO）の順序で処理されます。この設計はシンプルですが、高負荷時に以下の課題を引き起こします：
負荷分散は通常、データベースのフロントエンドに位置するロードバランサーに依存しますが、Cassandra內部ではこのメカニズムが不十分です。これにより、ワークロードの不公平性が生じ、一部のクライアントが過剰なリソースを佔有する可能性があります。
現在の協調器は**無限のキュー（unbounded queue）**を採用しており、リクエストがローカルトランスポートキューに蓄積します。これにより、高負荷時にリクエストがキューに數秒滯在し、タイムアウトを超過する可能性があります。
背圧メカニズムが不十分なため、クライアントとサーバー側のタイムアウト定義が一致しません。サーバー側のタイムアウト計時器は、協調器がレプリカにリクエストを送信する時點から開始され、キューでの待機時間を無視します。これにより、実際の遅延が過小評価され、システムの不安定化が進みます。
クラスタが過負荷になると、レプリカの応答遅延が増加し、協調器のクエリタイムアウト（例：12秒）が発生します。クライアントはタイムアウト後にリクエストを再試行または終了するため、問題が悪化します。
**ネイティブリクエストデッドライン（native request deadline）**を導入し、リクエストがシステム內で最大でどのくらい滯在できるかを制限します。これにより、協調器が無駄な処理を迴避し、成功応答率を向上させます。
クライアント側のタイムアウト（例：Java Driverのread timeout）は、ソケット読み取りタイムアウトを指す一方、サーバー側のタイムアウト計時器は協調器がレプリカにリクエストを送信する時點から開始されます。これにより、キューでの待機時間が無視され、実際の遅延が過小評価されます。
リクエスト遅延には、協調器キュー、レプリカキュー、フェーズキューなど、複數の待機時間が含まれます。キュー時間の無視は、サーバー側のタイムアウト判斷を誤らせる原因となります。
Max native transport request設定はCassandra 1.5503以降削除され、キューが無限に拡張される可能性があります。デフォルト値（例：32スレッド）は、読み取り/書き込みなどのフェーズごとに區別されていないため、リソース利用率が不均一になります。
システムの強度は、最も弱い部分に依存します。キュー管理などの要素を無視すると、全體のパフォーマンスに悪影響を及ぼします。
| 主題 | 內容 |
|---|---|
| 佇列深度 | クライアント、協調器、レプリカ側の待機時間は、遅延計算の核心 |
| 背圧メカニズム | システム過負荷を迴避し、キュー深度の監視とリソースの動的調整 |
| デッドライン | クライアントが明示的に設定し、サーバーがデッドラインに基づいてタイムアウトを判斷 |
| 公平性戦略 | リクエストタイプやクライアントソース、ワークロードタイプに応じて優先順位を調整 |
| 健康指標 | 遅延トレンド、ノードリソース使用率、処理能力などにより動的調整 |
| 負荷分散 | キュー分離、優先順位戦略、リソース配分メカニズムにより公平性を実現 |
| システム安定性 | 自動化戦略と健康指標により手動介入を減らし、運用簡易性を向上 |
Cassandraの安定性と負荷分散は、佇列深度の監視、背圧メカニズム、デッドライン設定、公平性戦略、健康指標の動的調整によって実現されます。今後の改善方向は、クライアントとの協調、リソース配分メカニズムの最適化、自動化戦略の強化です。これらの技術要素を理解し、適切に設計することで、高負荷環境でも安定したパフォーマンスを維持できます。