セルベースアーキテクチャ(Cell-Based Architecture)とブラスト半径の隔離

1. 概要

定義: セルベースアーキテクチャとは、システム全体を互いに独立して自己完結した複数のセル(Cell) — それぞれがコンピュート・データ・キュー・キャッシュをすべて備えた自己充足的(self-contained)なデプロイ単位 — に分割し、リクエストをセルルーター(Cell Router)がパーティションキーに応じて特定のセルへ固定ルーティングすることで、いかなる障害・欠陥デプロイ・過負荷が発生してもその影響を一つのセルに格納(contain)する、可用性中心のアーキテクチャパターンである。

クラウドとマイクロサービスが普及するにつれ、システムは数千のサービスと巨大なインフラの上で動作するようになり、逆説的に単一の欠陥が全体へ伝播する「無限ブラスト半径(unlimited blast radius)」という問題が深刻化した。一つの共有データベースが飽和したり、誤った設定が全域にデプロイされたり、特定テナントの異常トラフィック(poison pill)が共用リソースを枯渇させたりすると、いくらサービスが細かく分割されていても障害はすべての顧客へ同時に広がる。2010年代後半以降、Slack・DoorDash・Roblox のような大規模サービスが可用性ゾーン(AZ)単位の障害や全域障害を経験するなかで、「失敗を防ぐこと」ではなく「失敗が広がる範囲を最初から物理的に制限すること」へ設計思想が移行し、その具体的な解としてセルベースアーキテクチャが台頭した。

セルベースアーキテクチャの核心的な洞察は、可用性は確率の積ではなく隔離された単位の和として管理すべきであるという点である。単一の巨大システムでは障害確率 p がそのまま全体影響へ直結するが、システムを N 個の独立したセルに分けると、一つのセルの障害は原則として全顧客の 1/N にしか影響しない。すなわちセル数を増やすことはブラスト半径を算術的に縮小する行為であり、ここに後述するシャッフルシャーディング(Shuffle Sharding)を組み合わせれば、隔離度を組合せ論的に最大化できる。AWS はこの思考を Well-Architected Framework 信頼性の柱のバルクヘッド(bulkhead)アーキテクチャ(REL10)として定式化し、「障害の影響範囲を制限せよ」というベストプラクティスとして提示している。

ここで留意すべきは、セルベースアーキテクチャが単純な冗長化(redundancy)とは異なる点である。従来の冗長化は同一システムの複製を置き、一方が死ねば他方へ切り替える「可用性」戦略であるが、複製同士が同じコード・同じ設定・同じ欠陥を共有するため、欠陥デプロイやソフトウェアバグのような相関障害(correlated failure)には無力である。セルは複製を置きつつも変更をセルごとに時間差を設けて(decorrelated)展開することで、冗長化が防げない「すべての複製が同時に同じ理由で死ぬ」事故までも格納するという点で本質的に異なる。この相関障害の格納こそ、セルアーキテクチャが提供する固有の価値である。

特徴を要約すると次のとおりである。第一に、完結性 — 各セルは他セルのリソースを共有せず独立してリクエストを最後まで処理する。第二に、固定ルーティング — 同一パーティションキーは常に同一セルへマッピングされ、状態の一貫性とデバッグの容易さを保証する。第三に、水平複製可能性 — セルは同一構成の複製であるため、容量が不足すればセルを「増し刷りする」方式で拡張する。第四に、独立デプロイ — 変更をセル単位で段階的に展開し、欠陥デプロイの全域拡散を遮断する。第五に、予測可能な容量 — セルの最大スループットを事前に測定しておけば、全体容量を「セル容量 × セル数」という線形モデルで計画でき、非線形な性能の崖を避け、成長に合わせた増設時期を数値で予測できる。

総合すると、セルベースアーキテクチャは「障害は必ず起こる」という前提の上で被害の最大範囲を設計であらかじめ上限づけるアプローチであり、可用性・拡張性・デプロイ安全性を一つの分割戦略で同時に引き上げる点で、大規模分散システムの中核的な信頼性パターンと評価される。

2. 全体構造と構成要素

セルベースアーキテクチャは外から見れば単一のサービスのように見えるが、内部的には薄いルーティング層と多数の独立したセル、そしてそれらを調整するコントロールプレーンで構成される。全体構造を俯瞰すると次のとおりである。

graph TD
    U["ユーザー・テナント要求"] --> R["セルルーター(Cell Router)"]
    R -->|"パーティションキーのハッシュ"| C1
    R --> C2
    R --> C3
    subgraph C1["セル 1"]
      A1["API・コンピュート"] --> B1["専用DB・キャッシュ・キュー"]
    end
    subgraph C2["セル 2"]
      A2["API・コンピュート"] --> B2["専用DB・キャッシュ・キュー"]
    end
    subgraph C3["セル N"]
      A3["API・コンピュート"] --> B3["専用DB・キャッシュ・キュー"]
    end
    CP["コントロールプレーン(Control Plane)"] -.->|"マッピング・デプロイ・容量管理"| R
    CP -.-> C1
    CP -.-> C2
    CP -.-> C3

A. セル(Cell) — 自己充足的な障害ドメイン

セルはこのアーキテクチャの基本単位であり、サービスがリクエストを最後まで処理するのに必要なすべての構成要素を収めた完結型スタックである。一つのセルの中には API ゲートウェイ、アプリケーションコンピュート、専用データストア、メッセージキュー、キャッシュがすべて入り、原則として他のセルといかなる状態も共有しない。この「無共有(share-nothing)」原則が隔離の物理的根拠である。あるセルのデータベースがロック競合で停止しても、他のセルのデータベースはまったく影響を受けない。

セルのサイズ(cell size)は設計の中核的なトレードオフを決める。セルを小さく多く置けばブラスト半径は減るが、セルごとに重複する固定インフラコストと運用の複雑度が増す。逆にセルを大きく少なく置けばコスト効率は良いが、一つのセル障害の影響が大きくなる。実務では「一つのセルが担える最大テナント数」と「一つのセル障害時に許容できる顧客比率」を併せて定めて上限を置き、セルがその上限に達したら新しいセルを追加する方式で運用する。

さらにセルはテストと検証が可能な最小運用単位でもある。セルの最大処理容量を事前に負荷テストで測定しておけば、全体システムの容量計画を「セル容量 × セル数」という線形モデルで単純化できる。これは巨大な単一システムで非線形に現れる容量限界を予測可能にするという実務的利点を与える。

B. セルルーター(Cell Router) — 薄いが最も重要な層

セルルーターは、入ってきたリクエストのパーティションキー(例: 顧客ID、テナントID、口座番号)を見てどのセルへ送るかを決める層である。ルーターは必ずきわめて単純かつきわめて安定でなければならない。なぜなら、ルーター自体が複雑であったりセルに依存する状態を持ったりすると、それが新たな単一障害点(SPOF)かつ共有ブラスト半径となり、セル隔離の意味を崩してしまうからである。したがってルーターは無状態(stateless)なハッシュマッピング、あるいは変更頻度が低く高可用に複製されたマッピングテーブル(パーティションキー → セルID)のみを用いるよう設計する。

ルーターの可用性が全体可用性の上限を決めるため、ルーターはセルよりはるかに保守的に運用する。多くの実装は DNS(例: Route 53)、L7 ロードバランサー、あるいは軽量ルーティングサービスでルーターを構成し、ルーターロジックにはビジネスルールを入れない。ルーターがセルのヘルスを参照して障害セルを迂回すれば可用性は上がるが、その分ルーターがセル状態に結合して複雑度が増すため、「ルーターは単純に、復旧はコントロールプレーンが」という役割分担が推奨される。

パーティションキーの選択はアーキテクチャの成否を左右する。キーはリクエストが一つのセルで完結できるようデータ局所性(locality)を保証しつつ、同時に特定のセルへ負荷が偏らないよう均等な分布を作らねばならない。たとえば電子商取引で「注文ID」をキーにすれば注文処理は一つのセルで終わるが、顧客の全注文照会が複数のセルに散らばってクロスセル照会が発生しうる。逆に「顧客ID」をキーにすれば顧客中心の照会は一つのセルで終わるが、超大型顧客が特定のセルを飽和させるホットセル(hot cell)問題が生じうる。したがってドメイン特性と照会パターンを分析してキーを選定し、ホットセル再分配戦略も併せて設計せねばならない。

具体的な例として、AWS Well-Architected の説明では Route 53 が顧客を特定のシャード(2つ以上のセルで構成)へ割り当てる方式でルーティングを行う。このときルーティング規則を変えること(セル再配置)はデータマイグレーションを伴うため、ルーター設計の時点でパーティションキーの選択と再配置戦略を併せて定めねばならない。

C. コントロールプレーン(Control Plane)とデータプレーン(Data Plane)の分離

セルベースアーキテクチャは、リクエストを処理するデータプレーン(ルーター + セル群)と、システムを管理するコントロールプレーン(セルの生成・削除、マッピング更新、デプロイのオーケストレーション、容量再分配)を明確に分離する。この分離が重要な理由は、コントロールプレーンは相対的に複雑で変更が頻繁なため障害可能性が高い一方、データプレーンは単純・安定が生命だからである。コントロールプレーンが一時的に停止しても、すでにルーティングされたリクエストは各セルで正常に処理されねばならない(静的安定性、static stability)。

静的安定性とは「コントロールプレーンなしでもデータプレーンが最後に知られた正常状態で動作し続ける」性質である。たとえば新しいセルを追加したりマッピングを変えたりする作業はコントロールプレーンの責務だが、その作業が失敗しても既存のセル群は影響なくサービスを継続する。この原則は、大規模障害がしばしば「コントロールプレーンがデータプレーンを引きずり下ろす」形で広がるのを防ぐ。

コントロールプレーンはまた観測(Observability)の集約点である。セルごとのエラー率・遅延・飽和度を収集してどのセルが異常かを判断し、デプロイを次のセルへ拡大するかロールバックするかを決める。ただし、この観測経路がデータプレーンの正常動作に必須とならないよう、観測の失敗がサービスの失敗につながらないよう設計せねばならない。

D. シャッフルシャーディング(Shuffle Sharding) — 隔離の組合せ論的最大化

単純に顧客を各セルへ1:1で分ける方式はブラスト半径を 1/N に減らすが、依然として一つのセルに集まった顧客はそのセル障害時に全員被害を受ける。シャッフルシャーディングは、各顧客(またはワークロード)を一つのセルではなく互いに異なる組合せの複数セルへ割り当て、二つの顧客が完全に同一のセル組合せを共有する確率を劇的に下げる技法である。

AWS の例が直感的である。8個のセルがあり、一つのシャードを2個のセルで構成するとしよう。一般的な規則型シャーディングではシャードが4個しかないため、一つのシャードが問題を起こすと全顧客の25%(1/4)が影響を受ける。しかしシャッフルシャーディングは8個のセルから2個を選ぶ組合せ C(8,2) = 28 通りの固有の組合せを作れるため、一つの問題の影響が約1/28に減る — 規則型に比べ約7倍狭いブラスト半径である。セル数とシャードサイズを大きくするほど組合せ数が急増し、隔離度は指数関数的に良くなる。

組合せ数の増加は規模が大きくなるほどさらに劇的である。セルが多くなるほど、そしてシャードを構成するセル数を少し増やすだけでも、組合せ数は爆発的に大きくなる。たとえば100個のセルから5個を選ぶ組合せは約7,500万通りに達し、二つのワークロードが完全に同一のセル集合を共有する確率は事実上0に収束する。これが AWS Route 53 や大規模マルチテナントサービスが「ごく少数の異常テナント(noisy/poison tenant)が全体を引きずり下ろす」状況をシャッフルシャーディングで防御する数学的根拠である。ただし隔離度が高まるほどシャードごとの容量余裕分(redundancy)がより必要になるため、隔離とコストの均衡点を組合せサイズで調整する。

ただし AWS のセルベースアーキテクチャ指針は、シャッフルシャーディングはセル「内部」で適用し、セル境界を越えて状態を共有し境界を曖昧にしてはならないと警告する。すなわちシャッフルシャーディングで隔離を細分化しても、セル間の無共有原則はそのまま守らねばならない。この制約を守らなければ、組合せ論的な利点はかえってクロス依存による共有ブラスト半径で相殺される。

3. リクエスト処理と段階的デプロイのプロセス

セルベースアーキテクチャの価値は、平時のルーティングよりも障害・デプロイ時の格納で現れる。とりわけ「欠陥デプロイが全域へ広がる」という最も一般的な大規模障害の類型を、セル単位の段階的デプロイ(wave deployment)で遮断する。デプロイの流れを図示すると次のとおりである。

graph LR
    S["変更・デプロイ開始"] --> W1["第1波: 単一セル(カナリア)"]
    W1 --> H{"エラー率・遅延は正常か?"}
    H -->|"はい"| W2["第2波: 一部セルへ拡大"]
    H -->|"いいえ"| RB["当該セルのみロールバック<br/>ブラスト半径 = 1セル"]
    W2 --> W3["第3波: 全セルへ順次拡大"]
    W3 --> DONE["全区間へ反映完了"]

デプロイは常に一つのセル(または少数の低リスクセル)から始める。この第1セルでエラー率・遅延・飽和度を観測して健全だと判断されれば次の波へ拡大し、異常が検知されれば当該セルのみロールバックする。この構造の核心は、たとえ欠陥のあるデプロイでもその被害が1個のセルの顧客だけに限られる点である — 全域同時デプロイであれば全顧客が被害を受けたはずの事故が、セル単位デプロイでは 1/N の事故に縮小される。

具体的な数値で感覚をつかんでみよう。全顧客が1,000万人でシステムが50個のセルで構成されていれば、欠陥デプロイが第1のカナリアセルで食い止められる場合、影響顧客は約20万人(1/50)にとどまる。もし全域同時デプロイであれば、同じ欠陥が1,000万人全体へ即座に広がっていただろう。さらに第1セルを「社内従業員・低リスクテナント」で構成すれば、実際の外部顧客影響は0に近づけられる。このようにセルは「障害は起こりうるが、起こったときの最大被害規模を設計時点で上限として打ち込む」構造を提供する。

障害対応(failover)の観点でもセルは強力である。特定のセルや可用性ゾーンに問題が生じると、コントロールプレーンが当該セルのトラフィックを健全なセルへドレイン(drain)するか、ルーティングから除外する。たとえば Slack は可用性ゾーン単位のセル構成を導入した後、問題が生じた AZ のトラフィックを約5分以内に段階的にすべて抜き出せるようになったと報告している。これは「障害を直す時間」ではなく「障害を迂回する時間」へ復旧目標を変えた事例である。

構成要素	役割	設計原則	失敗時の影響
セルルーター	パーティションキー → セルのマッピング	単純・無状態・超高可用	全体影響(最も危険)
セル	自己充足的なリクエスト処理	無共有・複製可能	1/N 顧客に限定
コントロールプレーン	デプロイ・マッピング・容量管理	データプレーンと分離・静的安定性	管理機能の低下(サービス継続)
シャッフルシャーディング	組合せベースの隔離	セル内部で適用・境界維持	隔離度の低下

上の表は補助的な整理にすぎず、各構成要素の「なぜそう設計すべきか」は前節の散文による説明が本質である。とりわけルーターの失敗影響が「全体」である点がセルアーキテクチャのアキレス腱であり、だからこそルーターを最も単純に置くことが逆説的に最も重要な設計判断となる。

4. 類似パターンとの比較

セルベースアーキテクチャはバルクヘッド・マイクロサービス・マルチテナンシー・シャーディングとしばしば混同されるが、隔離の「範囲」と「層位」が異なる。バルクヘッドパターンは主に一つのサービス内部でスレッドプールやコネクションプールのようなリソースを分離し、一つの依存の飽和が他の機能へ広がらないようにする。一方、セルベースアーキテクチャはシステム全体をフルスタック単位で複製・分割する点ではるかに大きな層位の隔離である。すなわちバルクヘッドが「船の隔壁」なら、セルは「独立して航海する何隻もの同じ船」に近い。

マイクロサービスとの違いも重要である。マイクロサービスはシステムを機能(垂直)で分けるが、サービス群は依然として共有インフラ・共有DB・全域デプロイパイプラインの上で動作するため、ブラスト半径が全域に残りうる。実際 InfoQ は「大規模マイクロサービスアーキテクチャが共有インフラの無限ブラスト半径のために深刻な障害を経験してきた」と指摘する。セルベースアーキテクチャは、このマイクロサービスの束を再び顧客・ワークロード(水平)で分割して隔離を追加する、相互補完的なパターンである。

データベースシャーディングとも比較される。シャーディングはデータ層のみを分割するが、セルはデータだけでなくコンピュート・キュー・キャッシュまで含めた全層を併せて分割する。だからセルは「リクエスト全経路の隔離」を提供する一方、シャーディングだけでは共有アプリケーション層が依然として共通障害点として残る。この違いが「データだけ分ければ済みそうなのに、なぜセルまで行くのか」への答えである — 障害はデータ層だけでなくどこでも発生するからである。

マルチテナンシーアーキテクチャとの関係も押さえておく価値がある。マルチテナンシーは複数テナントがリソースを共有(pooled)するか分離(siloed)するかを扱うスペクトラムだが、セルベースアーキテクチャはこのスペクトラム上で「セル単位でテナントを束ねて分離する」中間戦略と見なせる。すなわち全テナントを一つのプールに入れればコストは最低だがブラスト半径は最大であり、テナントごとに専用スタックを与えれば隔離は完璧だがコストが爆発する。セルは「N個のテナントを一つのセルにまとめつつセル同士は完全に分離する」ことで、その間の実用的な妥協点を提供する。このように各パターンは代替材ではなく隔離層位が異なる補完材であり、実務ではバルクヘッド(サービス内部) → マイクロサービス(機能) → セル(顧客・ワークロード) → リージョン(地理)の多層隔離として組み合わせ、多層防御を構成する。

5. 深掘り — 産業適用事例と最新動向

近年セルベースアーキテクチャは超大型サービスの可用性戦略として急速に広がっており、複数企業の公開事例が具体的な設計選択を示している。

Slack は AZ 単位のネットワーク障害を経験した後、大部分の中核的なユーザー対面サービスをセルへ移行した。各 AZ が完全に隔離されたバックエンドデプロイを収めるよう構成し、コンポーネントを単一 AZ に閉じ込めてクロス AZ 依存を除去した。その結果、問題が生じた AZ のトラフィックを約5分以内にすべてドレインできるようになった。これは「隔離 + 速いトラフィック移動」が組み合わさるときセルアーキテクチャの効果が最大化されることを示す。

DoorDash は Envoy ベースのサービスメッシュのゾーン認識ルーティング(zone-aware routing)を活用し、AZ ベースのセル設計へ移行した。各セルは複数の Kubernetes クラスターで構成され、各マイクロサービスは一つのセル内の一つのクラスターにのみデプロイされる。興味深い副次効果として、クロス AZ トラフィックが減りデータ転送コストまで削減された — 可用性とコストという相反しやすい二つの目標を同時に改善した事例である。

Roblox は拡張の過程でインフラをセルへ再編し、効率性と復元力を高め、異常なセルを全体システムへ影響なく無効化できるようにしている。共通する動機はいずれも「共有インフラの無限ブラスト半径の除去」である。標準化の面では、AWS が Well-Architected 信頼性の柱(REL10: 障害隔離境界の使用)と多数のホワイトペーパーを通じてセルベース設計をベストプラクティスとして体系化しており、想定される出題方向としては「大規模な公共・金融システムで全域障害を防ぐためのアーキテクチャ戦略」「AZ・リージョン障害の格納設計」「シャッフルシャーディングを用いたテナント隔離」が論述素材として有力である。

6. 考慮事項および示唆点

セルベースアーキテクチャは「障害をなくす」のではなく「障害の範囲を設計で制限する」という発想の転換であるため、技術士の観点では次の点をバランスよく考慮せねばならない。

セルサイズ・個数のトレードオフ戦略: セルを細かく分けるほどブラスト半径は減るが、セルごとに重複する固定インフラ・モニタリング・ルーティングのコストと運用の複雑度が線形以上に増す。「許容可能な最大顧客影響比率」を SLA から逆算してセル上限を定め、コストに対する隔離効果が飽和する点を見つけることが中核的な意思決定である。コスト(redundant infrastructure)と復元力の均衡点を定量的に提示できねばならない。
ルーターとコントロールプレーンの可用性上限の管理: セルをいくらうまく隔離しても、ルーターやコントロールプレーンが共有単一障害点として残れば、全体可用性はその弱い環に縛られる。ルーターを極端に単純・無状態に置き、コントロールプレーンとデータプレーンを分離して静的安定性を確保し、コントロールプレーン障害がサービス停止へ広がらないよう設計することが前提条件である。
クロスセル依存の統制: セル間のデータ・呼び出し依存が生じた瞬間に隔離は崩れ、共有ブラスト半径がよみがえる。したがってパーティションキー設計の段階で「一つのリクエストが一つのセルで完結するか」を検証せねばならず、不可避なクロスセル相互作用(例: 全域集計、課金)は非同期・補償トランザクション・読み取り専用レプリカへ分離して可用性低下を最小化する。
データマイグレーション・再配置の運用性: セル追加、ホットセル(hot cell)の負荷再分配、テナント移動はデータマイグレーションを伴う高難度の運用である。マッピング変更を無停止で行う手順、マイグレーション中の一貫性保証、ロールバック計画を事前に自動化しておかなければ、隔離の利点が運用リスクで相殺される。
観測性・カオスエンジニアリングとの連携: セルごとの指標(エラー率・飽和度・遅延)を独立して収集し、セル単位の障害注入(chaos engineering)で「一つのセルを殺しても全体が耐えるか」を常時検証してこそ、実際の障害時の格納が保証される。展望としては、サービスメッシュのゾーン認識ルーティング、マルチ AZ・マルチリージョンのセルトポロジー、プラットフォームエンジニアリングによるセルプロビジョニングの自動化が組み合わさり、セルアーキテクチャが大規模システムの標準的な信頼性パターンとして定着すると展望される。

参考資料

AWS Well-Architected Framework, REL10-BP03 Use bulkhead architectures to limit scope of impact — https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_fault_isolation_use_bulkhead.html
InfoQ, How Cell-Based Architecture Enhances Modern Distributed Systems — https://www.infoq.com/articles/cell-based-architecture-distributed-systems
InfoQ, Slack's Migration to a Cellular Architecture — https://www.infoq.com/news/2024/01/slack-cell-based-architecture
Rackspace, Cell-Based Architecture on AWS — https://www.rackspace.com/blog/cell-based-architecture-aws

一言まとめ: セルベースアーキテクチャは、システムを無共有の自己完結型セルへ分割し、単純・高可用なルーターでパーティションキーを固定ルーティングして、障害・欠陥デプロイ・過負荷のブラスト半径を 1/N(シャッフルシャーディング時は組合せ論的にさらに小さく)へ格納する可用性中心のパターンである。