リングが抑えるもの

コンシステントハッシュでは、キーとサーバーを同じハッシュ空間に置き、キーから一定方向に進んで最初に出会うサーバーを担当先にします。メンバー変更時の再配置を、固定の剰余ハッシュより少なくできる場合があります。ただし「常にキーの正確に1/Nだけ移動する」という一般則はありません。実際の割合はトークン配置、ノード数、重み、キー分布、障害時の復旧規則に左右されます。

仮想ノードと運用上の交換条件

Dynamo論文では、1台の物理ノードに複数のリング位置を持たせる仮想ノードを使います。位置を複数にすると統計的な偏りを抑えやすく、サーバーごとに割り当て数を変えて容量差を表せます。一方、位置を増やすほどリング情報や移動・修復の作業も増えます。キー数が均等でも、人気キーや処理コストが偏ればCPU、通信量、ストレージ負荷は均等になりません。

複製は別の設計判断

Dynamoはリング上の担当範囲に加えて後続ノードへの複製や可用性回復を説明しますが、ハッシュ規則だけで複製、合意、強い一貫性が得られるわけではありません。複製数、読み書きクォーラム、障害中の一時保存、修復方法はデータモデルと運用目標に応じて決めます。キャッシュには期限切れやミス集中への対策が別途必要で、永続ストアでは複製同期と安全な再配置を設計します。

基本方式でも負荷は偏り得る

Google Researchの研究者Vahab MirrokniとMorteza Zadimoghaddamは、基本方式が動的な割り当てで移動を抑える一方、最悪時の負荷均衡はランダム割り当てを上回らない場合があると分析しました。両氏はサーバー負荷に上限を設ける別方式を提案し、Google Cloud Pub/Subでの適用も報告しています。これは通常のリングが自動的に同じ上限を持つという意味ではありません。追加の割り当て規則を使い、移動の柔軟性と過負荷防止を調整する設計です。

導入時の測定

サーバー数だけから均衡や移動率を推測せず、実際に近いキー人気度と処理コストで測定します。トークン数、異なる容量の重み付け、ノード障害、修復帯域、再配置の速度制限も試験対象です。ここでいう専門家の見解は、Google研究者による負荷上限制約の分析と適用報告であり、他の実装やワークロードへの保証ではありません。

参考資料