Cell-based Architecture

限定された規模の単一アプリケーションスタックを「セル」という。
下図では、完全に分離された2つのシステムを管理し、それぞれのセルが同一のアーキテクチャであるものの、全く異なるデータセットを保持する。

もし、どちらかのセルのシステムに問題が発生したとしても、影響範囲は上図だと全ユーザの50％となる。
つまり、N個のセルがある場合、影響範囲は 1/N * 100 % になる。

デプロイもセルごとに実施すれば、もしデプロイ後に問題が発生したとしても、最初に展開されたセルが唯一の犠牲で済む。

同じコードを実行する
可能な限りサイロ化する
- 通常、セル間の直接通信は許可されない
分割方法はケースによって異なる
- ユーザごとにセルを分割する（ユーザあたりのリソースの数が管理可能な場合）
- リソースごとにセルを分割する（ユーザあたりのリソースの数が管理できない場合）
セルのサイズは異なっても良い
- 例えば、シングルテナントを考慮して1つのセルは1ユーザのみをホストするが、他のセルはマルチテナントで100ユーザをホストするなど

この影響範囲のことをblast radius(爆風半径)という

各ユーザを適切なセルにルーティングする方法について。

ユーザーからはどのセルに属しているかは意識しないようにしたい。
また、複数のユーザーを他のセルに移行する場合、セル間レイヤーが存在しないと、エンドポイントを新しいセルに変更する必要がある。

そこで、ルーティングレイヤーによって、ユーザーを適切なセルにルーティングできるようにする。

ただし注意点として、ルーティングレイヤーは可能な限り薄く保つのが重要なルール。
ルーティングレイヤーの目的はルーティングだけであるため、実装ははるかに単純になり、各セルよりも拡張性が高くできる。しかし、ルーティングレイヤーは論理的なSPOF（単一障害点）となるため、高可用性の設計が重要である。

ルーティングレイヤー（クロスセルデータプレーン）との大きな違いとして、このセルマイグレーション（クロスセルコントロールプレーン）はセル間でデータを移動させる役割を持つ。

以下の例では、User100をCell-0からCell-1に移行しています。
移行プロセスでは、両方のセルだけではなく、ルーティングレイヤーにも移行内容を反映することにより、リクエストを適切に再ルーティングする。

移行中にデータの一貫性を保つように慎重に設計されるべきワークフローであるため、このセルの移行はセルベースアーキテクチャにおいて最も高度なコンポーネントである。
したがって、メンテナンスウィンドウでセルの移行をするのが良い方法となる。

一部のセルが大きくなりすぎたり、小さくなりすぎた場合は、セルのバランスをとる必要がある。
また、運用しているなかで管理を改善するためにセルを結合／分割したい場合も発生する。

ノイジーネイバーとは、セルに高負荷をもたらすユーザおよびリソースのことを指す。.e.g. DDoS攻撃、有名人など
これらを特定した後に、他のユーザーから隔離するのが良い戦略となる。例えば、DDoS攻撃の場合はその攻撃者を特別なセルに移動させ、通常のユーザーが影響を受けないようにすることができる。