Cell-based Architecture
参考記事:https://magazine.opsbr.com/p/ep-4-cell-based-architecture-101?utm_source=profile&utm_medium=reader2
Cellとは
限定された規模の単一アプリケーションスタックを「セル」という。
下図では、完全に分離された2つのシステムを管理し、それぞれのセルが同一のアーキテクチャであるものの、全く異なるデータセットを保持する。
もし、どちらかのセルのシステムに問題が発生したとしても、影響範囲は上図だと全ユーザの50%となる。
つまり、N個のセルがある場合、影響範囲は 1/N * 100 % になる。
デプロイもセルごとに実施すれば、もしデプロイ後に問題が発生したとしても、最初に展開されたセルが唯一の犠牲で済む。
Cellに関する注意事項
- 同じコードを実行する
- 可能な限りサイロ化する
- 通常、セル間の直接通信は許可されない
- 分割方法はケースによって異なる
- ユーザごとにセルを分割する(ユーザあたりのリソースの数が管理可能な場合)
- リソースごとにセルを分割する(ユーザあたりのリソースの数が管理できない場合)
- セルのサイズは異なっても良い
- 例えば、シングルテナントを考慮して1つのセルは1ユーザのみをホストするが、他のセルはマルチテナントで100ユーザをホストするなど
この影響範囲のことをblast radius(爆風半径)という
クロスセルデータプレーン(通称:ルーティングレイヤー)
各ユーザを適切なセルにルーティングする方法について。
ユーザーからはどのセルに属しているかは意識しないようにしたい。
また、複数のユーザーを他のセルに移行する場合、セル間レイヤーが存在しないと、エンドポイントを新しいセルに変更する必要がある。
そこで、ルーティングレイヤーによって、ユーザーを適切なセルにルーティングできるようにする。
ただし注意点として、ルーティングレイヤーは可能な限り薄く保つのが重要なルール。
ルーティングレイヤーの目的はルーティングだけであるため、実装ははるかに単純になり、各セルよりも拡張性が高くできる。しかし、ルーティングレイヤーは論理的なSPOF(単一障害点)となるため、高可用性の設計が重要である。
クロスセルコントロールプレーン(通称:セルマイグレーション)
ルーティングレイヤー(クロスセルデータプレーン)との大きな違いとして、このセルマイグレーション(クロスセルコントロールプレーン)はセル間でデータを移動させる役割を持つ。
以下の例では、User100をCell-0からCell-1に移行しています。
移行プロセスでは、両方のセルだけではなく、ルーティングレイヤーにも移行内容を反映することにより、リクエストを適切に再ルーティングする。
移行中にデータの一貫性を保つように慎重に設計されるべきワークフローであるため、このセルの移行はセルベースアーキテクチャにおいて最も高度なコンポーネントである。
したがって、メンテナンスウィンドウでセルの移行をするのが良い方法となる。
データをセル間で移動する必要性
セルバランシング
一部のセルが大きくなりすぎたり、小さくなりすぎた場合は、セルのバランスをとる必要がある。
また、運用しているなかで管理を改善するためにセルを結合/分割したい場合も発生する。
ノイジーネイバーの隔離
ノイジーネイバーとは、セルに高負荷をもたらすユーザおよびリソースのことを指す。.e.g. DDoS攻撃、有名人など
これらを特定した後に、他のユーザーから隔離するのが良い戦略となる。例えば、DDoS攻撃の場合はその攻撃者を特別なセルに移動させ、通常のユーザーが影響を受けないようにすることができる。