分散ログ（Kafka系）のパーティションと順序保証

追記専用ログ：そもそも何を保存しているのか

Kafka系の分散ログ（commit log）の中核は、驚くほど単純なデータ構造です。末尾にしか書けず、書いたものは書き換えも削除もしない不変の列——追記専用ログ（append-only log）です。各レコードは書き込まれた順に連続した整数の オフセット（offset） を割り当てられます。0, 1, 2, … と単調増加し、欠番も飛びもありません。

パーティション0:  [off=0][off=1][off=2][off=3][off=4] ← ここに追記
                   古い                          新しい

この「不変・追記のみ・連番オフセット」という制約こそが、性能と順序保証の源泉です。ランダム書き込みが無いのでディスクへはシーケンシャル書き込みになり、HDDでも高スループットが出ます。読み出しもオフセットを起点にした連続読みなのでページキャッシュと相性がよく、ブローカは多くの場合データをユーザー空間にコピーせず sendfile でネットワークへ流せます。そして順序はオフセットの大小そのものなので、別途ソートやタイムスタンプ比較を要しません。オフセットが小さいレコードは必ず先に書かれた、という事実が順序の定義になります。

パーティション：全順序が保たれる単位

単一ログでは1台のブローカの容量と帯域が上限になります。これを破るのが パーティション（partition） です。1つのトピックを複数のパーティションに水平分割し、それぞれを別ブローカに置く。これでスループットと容量はパーティション数に比例してスケールします。

ここで順序保証の最重要原則が出ます。オフセットはパーティション単位で振られ、全順序（total order）が保証されるのは1つのパーティション内だけです。トピック全体としての順序は存在しません。

トピック T（3パーティション）
  P0: [a0][a1][a2]
  P1: [b0][b1]
  P2: [c0][c1][c2][c3]

P0内では a0 → a1 → a2 の順序が厳密に保証されます。しかし P0 の a1 と P1 の b0 のどちらが先に起きたかは、ログ構造としては定義されていません。複数パーティションにまたがるイベント間の前後関係を知りたければ、論理クロックなど別の仕組みが要ります（/devops/logical-clocks/）。「分散ログは順序を保証する」という言い方は不正確で、正しくは「パーティション内の全順序を保証する」です。

キーによる分配：順序を守りたい単位を設計する

では、順序を守りたいレコード群を確実に同じパーティションへ集めるにはどうするか。鍵は メッセージキー（partition key） です。プロデューサがレコードにキーを付けると、ブローカ（実際にはプロデューサ側のパーティショナ）が次のように分配先を決めます。

partition = hash(key) mod パーティション数      # キー有り：決定的
partition = ラウンドロビン or sticky             # キー無し：負荷分散優先

キーのハッシュをパーティション数で割った余りで宛先が決まるため、同じキーは（パーティション数が変わらない限り）常に同じパーティションに行きます。したがって「順序を保ちたい単位」をキーにするのが設計の要諦です。

• 口座残高を順に適用したい → キー = 口座ID
• 同一ユーザーのイベントを順序通りに処理したい → キー = ユーザーID
• 同一デバイスのテレメトリを時系列で並べたい → キー = デバイスID

こうすれば、その口座／ユーザー／デバイスに属するレコードは1パーティションに集まり、その単位内では厳密な順序が保証されます。異なる口座どうしの順序は不要なので、それらは別パーティションに散って並列処理できる——「グローバルな順序は要らない、ローカルな順序だけ要る」という業務の性質を、キー設計でそのままパーティション構造に写すわけです。

キーを付けない場合、ブローカは負荷分散を優先してレコードを各パーティションへ散らします（ラウンドロビンや、バッチ効率を上げる sticky 戦略）。この場合、順序保証は一切ありません。順序が要るかどうかでキーの有無を決める、というのが第一の分岐点です。

コンシューマグループとリバランス：並列度はパーティション数で頭打ち

読み手側の単位が コンシューマグループ（consumer group） です。同じ group.id を持つコンシューマ群がグループを成し、1つのパーティションはグループ内のちょうど1コンシューマだけに割り当てられます。この「1パーティション＝1消費者」という排他割り当てが、コンシューマ側でも順序を守る仕掛けです。複数の消費者が同一パーティションを同時に読むと順序処理が崩れるため、それを禁じています。

グループG（3コンシューマ）, トピックT（4パーティション）
  C1 ← P0, P3
  C2 ← P1
  C3 ← P2

この割り当てから重要な帰結が出ます。グループ内の有効な並列度はパーティション数で上限が決まるということです。パーティションが4つなら、5人目のコンシューマを足しても割り当てるパーティションが無く、遊休します。スループットを上げるための消費者の増設は、パーティション数までしか効きません。並列度を上げたければ、まずパーティションを増やす必要があります。

コンシューマの増減・離脱・障害が起きると、割り当てを組み直す リバランス（rebalance） が走ります。グループコーディネータ（ブローカの1つ）が新しい割り当てを計算し、各コンシューマへ配ります。

オフセットコミット：どこまで読んだかの記録が再処理と欠落を分ける

コンシューマは「自分がどこまで処理したか」を コミット済みオフセット（committed offset） としてブローカ（内部トピック __consumer_offsets）に記録します。次回の読み出しやリバランス後の引き継ぎは、この記録された地点から再開します。ここでコミットの順序が、障害時に重複（再処理）か欠落（取りこぼし）かを決定づけます。

パターンA（at-least-once）: 処理 → 成功 → オフセットをコミット
  処理後・コミット前に落ちると、再開時に同じレコードを再処理（重複）。欠落はしない。

パターンB（at-most-once）: オフセットをコミット → 処理
  コミット後・処理前に落ちると、そのレコードは二度と読まれない（欠落）。重複はしない。

業務系の多くは欠落が致命的なので、処理を確定してからコミットする（パターンA、at-least-once） を選び、そこで生じる重複を受信側のべき等処理で吸収します。「自動コミット（一定間隔で勝手にコミット）」は実装が楽ですが、処理の完了とコミットのタイミングがずれ、落ち方によって重複も欠落も起こりうるため、順序と正確性が要る系では手動コミットで処理境界に揃えるのが定石です。

ISRとレプリケーション：書いたものが消えない仕組み

最後が耐久性です。各パーティションは複数のブローカに複製され、そのうち1つが リーダー（leader）、残りが フォロワー（follower） になります。プロデューサとコンシューマはリーダーとだけやり取りし、フォロワーはリーダーのログを追いかけてコピーします。リーダーが載るブローカが落ちたら、フォロワーの中から新リーダーを選びます（リーダー選出の原理と分断時の注意は /devops/leader-election-split-brain/）。

ここで核になるのが ISR（In-Sync Replicas：同期レプリカ集合） です。ISRとは「リーダーに十分追いついている（遅延が一定以内の）レプリカの集合」で、リーダー自身も含みます。追従が遅れたフォロワーはISRから外れ、追いつけば戻ります。

パーティションP0:  leader=B1,  followers=B2,B3
  B2 が追従中・B3 が遅延 →  ISR = {B1, B2}      ← B3 は同期外れ

耐久性の保証はこのISRと2つのパラメータで決まります。

• acks=all：プロデューサは「ISR内の全レプリカが書き込み終えた」ことを確認してから成功とみなす。acks=1（リーダーだけ）なら、リーダーが書いた直後・複製前に落ちるとそのレコードは失われうる。acks=0 は確認すらしない。
• min.insync.replicas：書き込みを受け付けるためにISRに最低限必要なレプリカ数。例えば3レプリカでこれを2に設定すると、ISRが2未満（＝1台しか同期していない）になった時点で、acks=all の書き込みは拒否されます（エラーを返す）。

acks=all と min.insync.replicas を組み合わせる狙いは明快です。コミット済みと認めるレコードは、必ず複数台に書かれている状態を保証する。だから1台が落ちても、そのレコードを持つレプリカが他に残っており、データは失われません。逆に min.insync.replicas を満たせないほどレプリカが減ったら、書き込みを止めてでも耐久性の不変条件を守る——可用性より一貫性・耐久性を優先する選択です。これはCAP的なトレードオフそのもので、整合性モデルの議論（/devops/consistency-models/）と地続きです。

そしてコンシューマが読めるのはコミット済み（high watermark まで）のレコードだけです。high watermark は「ISR全員が複製し終えた最大オフセット」を指し、ここを超えた未複製のレコードはまだ読めません。これにより、後でリーダーが落ちて新リーダーに切り替わっても、一度読めたレコードが「無かったこと」にならない——読み手から見た順序と内容の一貫性が保たれます。

まとめ

• 分散ログは不変・追記専用・連番オフセットのログで、オフセットの大小がそのまま順序の定義になる。読んでも消えず、複数の読み手が各自のオフセットで独立に読める。
• 全順序が保証されるのはパーティション内だけ。トピック全体の順序は存在しない。順序を守りたい単位をキーにすると、同じキーが同一パーティションに集まりその単位内の順序が守られる。
• コンシューマグループでは1パーティション＝1消費者。よって並列度はパーティション数で頭打ち。リバランスは消費停止と重複処理を伴うため、消費はべき等が前提。
• オフセットコミットの順序が、処理→コミットなら重複（at-least-once）、コミット→処理なら欠落（at-most-once）を決める。
• 耐久性は ISRへの複製＋acks=all＋min.insync.replicas で「複数台に書かれたものだけコミット済み」を保証し、コンシューマは high watermark までしか読めない。レプリカが足りなければ書き込みを止めてでも耐久性を守る。