問題と適用シナリオ
ある分散Key-Valueストアが3つのアベイラビリティゾーン（AZ）にまたがって稼働しています。120台の物理ノード、24 TiBの論理データ、3つのレプリカを持ち、 毎秒200万回のキー配置ルックアップを処理します。クライアントまたはストレージプロキシは、プライマリと2つのレプリカをローカルで 検索できなければなりません。リクエストパスがルックアップのたびに中央サービスへ問い合わせることは許容されません。スケーリング、 メンテナンス、障害によってノードの参加や離脱が発生します。メンバーシップの変更時には、キャッシュのほぼ完全なコールドスタートや データ移行を引き起こすのではなく、影響を受けるキーのみを移動させる必要があります。
対象範囲は、keyから物理ノードへの配置レイヤーと、メンバーシップ変更時の安全な所有権の移行です。 読み書きの一貫性、コンフリクト解消、ディスクエンジン、クロスリージョンレプリケーションはメイン設計の対象外ですが、優れた回答では コンシステントハッシュ法がこれらを提供するわけではないことを明記する必要があります。安定的で均等に分散される64ビットハッシュを前提とします。 データサイズ、スループット、SLOは面接上の前提条件であり、実在する企業の公開規模ではありません。
2026年時点の英語および中国語のシステムデザイン面接資料では、コンシステントハッシュ法、仮想ノード、スケーリングが明確に扱われています。 Amazon Dynamoの論文は、パーティションとレプリカ配置のためのコンシステントハッシュ法の一次資料となる実例を提供しています。この質問は、 「移動するデータを減らす」という課題を、証明可能な所有権ルール、バージョン管理されたメンバーシップビュー、テスト可能な移行プロトコルへと 昇華させるため、シニアバックエンド、インフラストラクチャ、分散システムエンジニアの職種に適しています。
面接官が見ているポイント
第1に、単に円を描くだけでなく、Nが変化したときにhash(key) % Nが破綻する理由を説明できるか。優れた回答では、 再マッピング比率を導出し、固定論理パーティションと稼働ノード数に対する剰余演算を明確に区別します。
第2に、均等なキー数と均等なリクエスト負荷を切り分けて考えられるか。仮想ノードは多数の小さな範囲を物理ノードに分散させ、 キャパシティの重み付けを近似できます。しかし、極端な単一のホットキーに対するプライマリオーナーは依然として1つであり、 仮想ノードを追加してもそのキー自体が分割されるわけではありません。
第3に、データプレーンとコントロールプレーンを分離できるか。データプレーンは、ローカルのイミュータブルなリングスナップショットに 対してルックアップを実行する必要があります。コントロールプレーンはノードのID、ヘルス状態、重み、スナップショットバージョン、移行状態を 管理します。各クライアントが自身のヘルスチェックに基づいて即座にノードを削除すると、同一のキーに対して競合するオーナーが発生する可能性があります。
第4に、コンシステントハッシュ法が提供するのは配置のみであることを理解しているか。レプリカの多様性、データコピーの完了、障害復旧、 安全な削除にはすべて追加のプロトコルが必要です。「時計回りに3つのノードをたどる」だけでは、完全な可用性設計とは言えません。
最後に、固定論理パーティション、ランデブーハッシュ法、Jump Consistent Hashを比較し、実際のキー分布、メンバーシップのフラッピング、 スナップショットの不一致に対してその選択を検証できるか。暗記した仮想ノード数は、根拠の代わりにはなりません。
回答前の確認質問
- これはキャッシュですか、それとも永続ストレージですか？ キャッシュならスケーリング後に再投入できます。永続データは、所有権が
変更される前にコピーと追いつき処理（catch-up）を完了する必要があります。
- 任意のメンバーが参加・離脱しますか、それとも番号付きバケットが末尾に追加されるだけですか？ 任意のメンバーシップ変更にはリングまたは
ランデブーハッシュ法が適しています。主に末尾へ追加される連番バケットの場合は、Jump Consistent Hashを検討する価値があります。
- 負荷はキー数、バイト数、QPSのどれで測定されますか？ キー数が等しいからといって、キャパシティやトラフィックが等しいとは限りません。
重み付けとリバランスの指標は、実際のボトルネックに一致させる必要があります。
- ノードのキャパシティは均一ですか？ 異種ノードには重み付けが必要です。トークン数は重みを近似するに過ぎないため、固定シードの
シミュレーションと本番メトリクスで実際のシェアを検証する必要があります。
- レプリカにはどのような障害ドメインのルールが適用されますか？ 同一AZ内の3つのコピーは同時に障害を受ける可能性があります。レプリカ選択では、
同一物理ノードをスキップし、ゾーンの多様性を強制する必要があります。
- マイグレーションに許容される時間はどれくらいですか？ ダウンタイムなしの切り替えには、スナップショットのバージョン管理、一括コピー、
増分追いつき、および短期間の二重読み込みやフォワーディングが必要です。コールドスタートが許容されるなら、より単純な構成にできます。
- メンバーシップは誰が発行しますか？ クライアントには、エポックとチェックサムを備えた信頼できる（authoritative）スナップショットが必要です。
個別推論によるメンバーシップ判定は所有権の分裂（スプリット）を引き起こします。
- 範囲スキャン（Range Scan）は重要ですか？ ハッシュ化によりビジネスキーの局所性は失われます。範囲操作が多いワークロードでは、
レンジパーティショニングや固定論理パーティション層を先に導入する必要がある場合があります。
30秒の回答フレームワーク
「120台の稼働ノードに対する剰余演算は採用しません。クラスタが121台に増過した際、ハッシュが均等でバケットIDが固定されていると、 約120/121のキーでバケットが変更されます。私はキーと仮想ノードトークンを固定の64ビットハッシュ空間に配置し、 時計回りで最初のトークンをそのキーのオーナーとします。ソートされたトークンテーブルにより二分探索が可能となり、ルックアップはO(log V)となります。 各物理ノードは多数の小さな範囲を保持し、キャパシティの大きいノードにはより多くのトークンを割り当てます。レプリカ選択は時計回りに進めますが、 同一物理ノードの重複をスキップし、AZの多様性を強制します。コントロールプレーンは、エポックでバージョン管理されたイミュータブルな リングスナップショットを発行します。永続ストレージでは、データのコピーと追いつき処理が完了して初めて所有権を変更します。データ移動量、負荷の分散、 重み付け、障害ドメインを固定シードシミュレーションで検証し、仮想ノードでは単一キーの偏りを解決できないためホットキーは個別に処理します。」
ステップごとの詳細解説
ステップ1：剰余ハッシュによる再マッピングコストの定量化
直接マッピングの計算式は次のとおりです。
owner = nodes[hash(key) % N]固定バケットIDがNからN + 1に増加した際、キーが同じ数値バケットを維持できるのは、 hash % N = hash % (N + 1)の場合のみです。連続する整数は互いに素です。1つの完全な N × (N + 1)の剰余周期において、この等式を満たすハッシュ値は正確にN個です。したがって、維持される割合は 1 / (N + 1)であり、再マッピングされる割合はN / (N + 1)となります。
このクラスタを120台から121台に拡張すると、キーの約120/121 = 99.17%で予想オーナーが変更されます。24 TiBの論理データセットのうち 約23.8 TiBが新たな配置先へ割り当てられます。キャッシュであれば物理的なバイトコピーは発生しないかもしれませんが、ほぼ完全なコールドミスが 発生します。この導出は、ハッシュの均等性、バケットIDの安定性、および稼働ノード数による剰余を前提としています。キーをまず固定数の 論理パーティションにマッピングし、コントロールプレーンが選択されたパーティションのみを移動させる設計であれば、稼働メンバーシップの変動が 最初のマッピング式に影響を与えることはありません。
ステップ2：リング、トークン、ローカルルックアップの定義
固定の64ビットハッシュ関数とエンコーディングを選択します。キーと仮想ノードトークンの両方をそのハッシュ空間にマッピングします。 トークンを符号なし整数としてソートし、最大値からゼロへラップアラウンドさせます。時計回りで最初のトークンがキーを所有し、配列の末尾を 超える二分探索は先頭のトークンを返します。
locate(key, snapshot):
h = stableHash64(key)
i = lowerBound(snapshot.sortedTokens, h)
if i == snapshot.sortedTokens.length:
i = 0
return snapshot.sortedTokens[i].physicalNodeId合計V個のトークンがある場合、ルックアップの計算量はO(log V)、スナップショットのメモリ消費量はO(V)です。トークンの衝突には (token, physicalNodeId, vnodeIndex)のような決定論的な順序付けが必要です。マップの上書き順序に依存するのはプロトコルとは言えません。ノード識別子には 永続的なUUIDまたは固定のデプロイIDを使用します。エフェメラルなIPアドレスを使用すると、ノードの再起動で新しいアドレスが割り当てられるたびに 不要なメンバーシップ変更が発生します。
理想的なバランシングのもとでは、121台目に追加された同容量のノードは約1/121のキーを受け取ります。24 TiBの論理データの場合、 予想移動量は24/121 TiB ≈ 203 GiBであり、これは新しいノードが取得する多数の小さな範囲から集約されます。これはキャパシティプランニングの ための期待値であり、絶対的な制限ではありません。有限のトークン数、値サイズのばらつき、アクセスの偏りにより、実際の結果は203 GiBから乖離する 可能性があります。
ステップ3：範囲の均等化と容量重み付けのための仮想ノードの利用
物理ノードあたり1トークンのみの場合、ランダムな間隔の差が大きくなり、離脱するノードはその全範囲を1台の後続ノードに引き渡すことになります。 仮想ノードによって各物理ノードに多数の分散トークンを割り当てることで、大きな範囲を小さな移行単位に分割できます。 これにより、障害が発生した物理ノードの範囲は1台のマシンに集中せず、複数の後続ノードへ分散して引き継がれます。
面接対策本にあるような固定のトークン数を鵜呑みにしてはいけません。実際の、あるいは代表的なキー、値サイズ、QPS分布を用いて、 ノードあたりのトークン数を増やしながらリプレイ検証を行います。次の指標を測定します。
key_count_share, byte_share, qps_share
max_load / mean_load
coefficient_of_variation
snapshot_bytes and lookup_latencyトークンを追加してもバランシングの改善がわずかになり、スナップショットサイズ、更新コスト、二分探索のオーバーヘッドが許容範囲内に 収まるポイントで停止します。不均一なキャパシティを持つノードに対しては、目標トークン数をノードの重みにおよそ比例させます。 ランダムトークンは統計的な近似にとどまるため、システムが厳密な重み付けを必要とする場合は、固定論理パーティションの明示的割り当ての方が 運用しやすくなります。
仮想ノードは集約された範囲の所有権を平滑化します。リクエストの20%を占める単一のキーは、依然として1つのプライマリにマッピングされます。 これには、リードレプリカ、リクエストの結合（Coalescing）、ニアキャッシュ、ビジネスロジックに応じたキー分割、あるいはレート制限で対処します。 仮想ノードを100から1,000に増やしても、この事実は変わりません。
ステップ4：レプリカ選択とスナップショットモデルの設計
プライマリを特定した後、時計回りに進み、3つのレプリカが揃うまで異なる物理ノードを収集します。すでに選択されている物理ノードに 属する別の仮想トークンはスキップします。AZの多様性は、隣接する3つのオーナーがたまたま別ゾーンであることに期待するのではなく、 必須の制約条件として適用しなければなりません。
RingSnapshot {
epoch,
hashAlgorithm,
tokens: [{ token, physicalNodeId, weight, zone, state }],
checksum,
activatedAt
}
Placement {
keyHash,
epoch,
owners: [{ physicalNodeId, zone, role }]
}データプレーンはイミュータブルなスナップショットをアトミックに切り替えます。リクエストはそのepochを記録または保持します。 古いバージョンを検出したサーバーは、バージョンのヒントを返すか、現在のオーナーへリクエストを転送します。コントロールプレーンは、 すべてのレプリカセットに対して物理ノードの一意性と障害ドメインを検証します。健全なノードが不足している場合、同じマシンを2回選択して 3コピーあるかのように見せかけるのではなく、アンダーレプリケーション（レプリカ不足）状態を報告します。
コンシステントハッシュ法は配置場所を提案するだけであり、書き込みの承認（Acknowledgment）方法は定義しません。永続ストレージは、 書き込みを承認するレプリカ数、読み込み時のバージョン調整方法、リペアによるデータ検証、およびネットワーク分断時に一貫性と可用性の どちらを優先するかを別途決定する必要があります。
ステップ5：メンバーシップ変更をバージョン管理されたマイグレーションにする
計画的なノード追加では、次のステートマシンを使用できます。
joining -> copying -> catching_up -> active
active -> draining -> removedコントロールプレーンは、現在のエポックからの所有権の差分を計算します。joining状態のノードはプライマリトラフィックを 受け取りません。バックグラウンドジョブが古いオーナーから影響を受ける範囲をコピーし、キーのバージョンまたはログ位置によって検証します。 コピー中に発生した書き込みは、増分ログまたは二重書き込みパスに入ります。一括コピーの後、新しいノードが追いつき処理を行います。 チェックサムとレプリカの健全性ゲートを通過した後にのみ、コントロールプレーンは新しいエポックを発行し、ルーティングをアトミックに切り替えます。 古いオーナーは、古いスナップショットによるリクエストを処理しロールバックをサポートするため、一定の猶予期間データを保持した後に削除します。
ドレイン（安全な離脱）も同じ順序に従います。新しいオーナーへのコピーと追いつき処理を行い、当該ノードを除外したスナップショットを発行して 停止し、最後に古い範囲を回収します。リングの計算は影響を受ける範囲を特定するだけであり、コピー、帯域制限（スロットリング）、 検証、ロールバックのプロセスを代替するものではありません。マイグレーションワーカーは同時実行バイト数も制限し、想定される203 GiBの移動が フォアグラウンドの読み書き帯域を圧迫しないようにします。
ステップ6：障害処理とメンバーシップ合意の分離
ノードが突然ダウンした場合、そのノードから事前にコピーすることはできません。データプレーンは既存のレプリカからリクエストを処理し、 リペアワーカーが信頼できるメンバーシップエポックに従って健全なノード上に不足しているレプリカを再構築します。短時間のタイムアウトで 即座にリングを書き換えるべきではありません。さもないと、フラッピングによってマイグレーションが繰り返されます。ヘルス管理機能は、 連続障害数、リース、またはコントロールプレーンの合意を用いてノードを利用不可としてマークし、一時的な転送と恒久的な削除を区別します。
すべてのクライアントは、バージョン管理された単一のメンバーシップシーケンスを認識しなければなりません。クライアントAがノードXを削除した一方で、 クライアントBが依然としてXをプライマリとして扱っている場合、同一キーへの書き込みが異なる場所に送信される可能性があります。合意形成に基づく コントロールプレーンがリング構成を維持し、エポックとチェックサムを含むスナップショットを配布します。一時的なバージョン不一致の期間中、 クライアントはサーバーによる転送、二重読み込み、または明示的なリトライプロトコルを使用します。「全員がいずれ設定を受け取る」こと自体は、 正しさを保証するメカニズムではありません。
コントロールプレーンが利用できなくなった場合、データプレーンは検証済みの最後のスナップショットを使用して処理を継続します。 読み書きをどこまで継続できるかは、レプリカの一貫性と障害モデルに依存します。信頼できるメンバーシップビューが利用できない間に、 個々のノードが独自にリングを恒久的に書き換えてはなりません。
ステップ7：実際の制約下での代替案の比較
| アプローチ | 最適なユースケース | ルックアップと状態 | 主なコスト |
|---|---|---|---|
| 仮想ノード付きリング | 任意のメンバーシップ変更、可視化された範囲と重み付け | ソート済みトークン、O(log V)のルックアップ | スナップショットとトークンの調整、マイグレーションプロトコルが必須 |
| ランデブーハッシュ法 | ノード数が比較的少ない構成、上位1台または上位k台の直接選択 | キーごとの単純なO(N)のスコアリング | ノード数が多い場合の計算負荷増大（ただしリング不要で直感的なレプリカ選択が可能） |
| Jump Consistent Hash | 主に末尾追加される連番バケット | 定数メモリと高速なバケットマッピング | 任意ノードの削除が困難、通常はバケットからノードへの間接参照が必要 |
| 固定論理パーティション | 制御された移動、正確な重み付け、運用時の可視性 | キーからパーティション、その後コントロールプレーンによる配置 | パーティションメタデータと独立したリバランサー |
ステートレスなノードが任意のリクエストを処理できる構成であれば、通常のロードバランシングの方がシンプルです。コンシステントハッシュ法は、 キーがオーナーを保持し続ける必要がある場合に価値を発揮します。ワークロードが範囲スキャン主体である場合、キーの順序を崩すことによる デメリットが、データ移動削減のメリットを上回る可能性があります。まず配置の抽象化を選択し、アルゴリズムは後から決定してください。
ステップ8：特性、負荷、障害挙動の検証
オフラインテストでは、ハッシュアルゴリズムとシードを固定し、数百万のテスト用キーを生成してベースラインスナップショットを保存した上で、 ノードの参加、ドレイン、障害をシミュレートします。
moved_keys / total_keysを測定し、所有権の差分範囲外にあるキーが移動しないことを証明する。- キーのヒストグラムだけでなく、キー数、バイト数、QPSごとに
max/meanと変動係数を算出する。 1:2:4の重みを割り当て、長期的なシェアが目標値に近づくことを確認し、トークン増加による収穫逓減を記録する。- すべてのキーの3つのレプリカが異なる物理ノードおよび3つすべてのAZを使用していることを確認する。
- 2つのエポックを同時に稼働させ、スナップショットの欠落やチェックサムの破損を発生させて、転送、リトライ、古いバージョンの破棄をテストする。
- コピー処理の途中で新旧ノードを停止させ、不完全なマイグレーションによって唯一の健全なコピーが削除されないことを確認する。
- 単一のホットキーと継続的なメンバーシップのフラッピングを注入し、ホットスポット保護とメンバーシップのデバウンス処理がそれぞれ独立して機能することを検証する。
本番監視項目には、エポックごとの適用状況、キー/バイト/QPSの偏り、マイグレーションのバックログと速度、古いバージョンのリクエスト数、 転送率、アンダーレプリケーション状態の範囲、ホットキー、ハッシュ計算のレイテンシを含めます。スケーリング操作の完了は、 単に新しいノードがリング上に現れたときではなく、これらのシグナルが正常基準を満たしたときとみなします。
優れた回答例
「まず対象範囲をキー配置に限定して考えます。120台の稼働ノードに対する剰余演算では、121台への拡張によって約120/121のキーで バケットが変更され、24 TiBのほぼ全域で再マッピングが発生します。固定論理パーティションを用いればこの問題を回避できますが、 コンシステントハッシュ法を採用する場合は、キーとノードトークンを固定の64ビット空間に配置し、各キーを時計回りで最初のトークンに割り当てます。 クライアントはソートされたイミュータブルなスナップショットを保持し二分探索を行うため、ホットパスに中央呼び出しはなく、コストはO(log V)です。
各物理ノードには複数の仮想トークンを割り当て、範囲と障害時の移動を分散させます。容量の異なる異種ノードには、キャパシティに応じた異なる 目標トークン数を設定します。根拠なくノードあたり100トークンと決めるのではなく、実際のキーサイズやQPSをリプレイして、最大/平均負荷比、 変動係数、スナップショットサイズ、ルックアップレイテンシを比較して決定します。仮想ノードは範囲を平滑化しますが、単一のホットキーには 依然としてリードレプリカ、リクエストの結合、キー分割、またはレート制限が必要です。
レプリカ配置は時計回りに3台の異なる物理ノードを選択し、3つすべてのAZを含むよう強制します。合意形成に基づくコントロールプレーンが、 エポックとチェックサムを含むリングスナップショットを発行します。計画的なスケールアウトでは、新しいノードがまず担当範囲をコピーし、 増分書き込みに追いつきます。検証が完了した後にのみ新しいエポックが有効化され、古いオーナーは猶予期間の経過後にデータを削除します。 急な障害に対しては、健全なレプリカから処理を継続しつつ不足レプリカを再構築します。リングを描くだけでは復旧プロトコルにならないためです。
最後に、固定シードによる数百万のキーを用いて、移動量、キー/バイト/QPSの偏り、重み付け、レプリカの障害ドメインをテストし、 デュアルエポック、移行の中断、メンバーシップのフラッピング、ホットキーを注入して検証します。ターゲットが連番バケットであれば Jump Consistent Hashを比較検討します。オペレーターによる正確な移動制御を重視するなら、固定論理パーティションを選択します。」
よくある間違い
- リングを描くだけで終わる → 剰余が破綻する理由や移動量が説明されない → 再マッピング比率を導出し、データセットに適用して計算する。
- 物理ノードあたり1つのポイントしか配置しない → ランダムな間隔により範囲が偏り、1台の後続ノードが障害負荷を抱え込む → 複数のトークンを使用し、リプレイ検証によってトークン数を決定する。
- 仮想ノードをホットキー対策として扱う → 1つのキーに対するプライマリは依然として1台のみである → レプリカ、リクエスト結合、キー分割、レート制限を使用する。
- 次の3つのトークンをそのまま3つのレプリカとする → 同一マシンや同一ゾーンに属する可能性がある → 物理ノードの重複を排除し、障害ドメインの制約を強制する。
- 参加したノードへ即座にルーティングする → 永続データがまだ到達していない → コピー、追いつき、検証、エポック発行の順に進め、その後に古いコピーを削除する。
- クライアントが障害ノードを個別に除外する → メンバーシップの不一致により所有権が分裂する → 信頼できるコントロールプレーンからバージョン付きスナップショットを発行する。
- ノード追加による移動量が厳密に
1/Nになると主張する → 有限のトークンと重みにより範囲は不均一になる → 均等性の仮定に基づく期待値として述べ、実際の分布を測定する。 - 「ノードあたり200 vnodes」を固定値として暗記する → 値サイズ、QPS、スナップショットサイズ、ルックアップコストを無視している → ワークロードをリプレイし、収穫逓減のポイントを見つける。
- ハッシュ関数のバージョンを無視する → エンコーディングや実装の違いがすべてのキーを再マッピングしてしまう → アルゴリズム、エンコーディング、エポック、チェックサムをスナップショットに含める。
- あらゆるシャーディング問題にコンシステントハッシュ法を適用する → 範囲クエリや精密な運用には別のアプローチが適している場合がある → 固定パーティション、ランデブー、Jump Consistent Hashと比較する。
フォローアップ質問と回答
フォローアップ1：リングノードの追加時に移動するキーが厳密に1/(N+1)にならないのはなぜですか？
この割合は、キーとノードが均等に分散され、容量が同一で、十分なトークンがあることを前提としています。有限のランダムトークンセットは 不均等な区間を生み出し、値サイズやQPSも偏る可能性があります。これはあくまで期待値です。ローンチ前に実際のキー、バイト数、トラフィックを リプレイし、期待値以上のマイグレーション帯域を確保してください。すべての操作において厳密に制限された移動単位が必要な場合は、 固定論理パーティションの方が適しています。
フォローアップ2：レプリカが3つのゾーンに分散している場合でも、メンバーシップ管理のコントロールプレーンが必要なのはなぜですか？
レプリカ配置は、参加者が同一のエポックに合意している場合にのみ意味を持ちます。異なるリングを持つ2つのクライアントが異なるレプリカセットへ 新規書き込みを送信し、双方が3コピーを達成したと誤認する可能性があります。コントロールプレーンはメンバーシップ変更を線形化し、 バージョンを発行します。バージョン不一致の間は、転送、二重読み込み、または古い書き込みの拒否によって収束を促します。障害ドメインの多様性は メンバーシップの順序付けを代替するものではありません。
フォローアップ3：あるテナントが単一のキーで全QPSの40%を生成しています。vnodeを増やせば解決しますか？
いいえ。仮想ノードは範囲の分散方法を変更するだけであり、1つのハッシュ値を複数のプライマリに割り当てるわけではありません。読み込み主体の キーには、複数のリードレプリカとリクエスト結合を利用できます。書き込み主体のキーには、ビジネスロジックに応じた分割、シャーディングされた マージ可能状態、またはテナントごとのレート制限が必要です。書き込みの直列化が必須である場合、単一キーの一貫性要件がスループットの 限界となるため、それを明確に指摘すべきです。
フォローアップ4：スケールアウトのコピー中も書き込みが継続します。増分変更の喪失をどのように防ぎますか？
コピー処理はログ位置またはバージョンのウォーターマークを記録します。まずそのウォーターマークまでの範囲をコピーし、その後に発生した 変更を取り込みます。短期間の二重書き込みウィンドウを設けることも選択肢の1つです。新しいノードが切り替えウォーターマークに到達し、 検証を通過してレプリカが健全になった後にのみ新しいエポックが発行されます。古いオーナーは遅延リクエストのために猶予期間を保持し、 削除前にアンダーレプリケーションの範囲がないことを確認します。
フォローアップ5：コントロールプレーンがダウンしている間、読み書きを継続できますか？
データプレーンは有効なチェックサムを持つ最後のイミュータブルなスナップショットを使用し続けるため、個々のルックアップは継続します。 ノード障害発生後の安全な書き込みは、残存するレプリカと書き込み一貫性ルールに依存します。クライアントが独自にリングを恒久変更することは できません。スナップショットの経過時間を公開し、安全ウィンドウや必要なレプリカ数を満たせなくなった場合は書き込みをデグレードまたは停止します。 読み込みが継続できているからといって、書き込みが安全であることの証明にはなりません。
フォローアップ6：Jump Consistent Hashを選択するのはどのような場合ですか？
定数メモリによる高速なマッピングが重視され、主に末尾に追加される連番の論理バケットを扱う場合に選択します。任意のノード削除や 固有のIDを持つ物理ノードの扱いは難しいため、通常はキーをまず論理バケットにマッピングし、コントロールプレーンがバケットをマシンに配置します。 この間接参照により、ストレージはキーとバケット間のアルゴリズムを変更することなくバケットを移動できるようになります。
フォローアップ7：データセット全体に対する誤ったルーティングを引き起こさずにハッシュ関数をアップグレードするにはどうすればよいですか？
関数名、シード、キーのエンコーディングはスナップショットプロトコルの一部です。新しいエポックを作成し、新旧の所有権の差分をオフラインで 計算した上で、通常のマイグレーションプロセスを通じてデータのコピーと追いつき処理を行います。切り替え期間中、リクエストはアルゴリズムの バージョンを保持し、サーバーは新しいオーナーへ転送できます。一部のクライアントのみに新関数を適用すると、ほぼ完全な所有権の分裂が 発生するため、アップグレードは制御された完全な再パーティショニングとして処理する必要があります。