こんにちは、ネクストモード株式会社の平林です。
こんにちは、ホワイトバードです。
先週ラスベガスで開催されているAWS re:Inventに参加していました。
参加レポートをまとめています。
今回は、セッション「Transforming monoliths with cell based architecture (MAM301)」レポートとなります。
Cell-Based Architectureと呼ばれる高可用性設計に関するChalkTalkとなります。
セッション説明
原文
Explore how to transform a monolithic application into cell-based architecture using AWS services. Learn proven strategies for decomposing single-instance-per-tenant applications that face cascading failures, performance bottlenecks, and scaling limitations. In this interactive session, we'll examine architectural patterns for incremental migration while maintaining business continuity. Through collaborative discussion and architectural diagrams, we'll cover decoupling storage, database, and compute components, implementing request routing, and cell sharding. Drawing from real-world implementations, we'll demonstrate deploying your first migrated cell and share best practices to avoid common pitfalls.
翻訳
モノリシックなアプリケーションをAWSのサービスを使ってCell-Based Architectureに変えていくやり方を知りましょう。連鎖的な障害やパフォーマンスのボトルネック、スケーリングの限界があるテナントごとの単一のインスタンスで構成されたアプリケーションを分解していくための戦略を学びます。このインタラクティブなセッションでは、ビジネス継続性を維持しながら段階的に移行するためのアーキテクチャパターンを検証します。ディスカッションとアーキテクチャ図を見ながら、ストレージ・データベースとコンピューティングコンポーネントの分離、リクエストルーティングの実装、セルシャーディングについて学びます。よくある実装例をもとに、最初の移行時の落とし穴を回避するためのベストプラクティスを共有します。
セッション形式：Chalk Talk
セッション時間：1時間
セッションレベル：300
セッションレポート
Cell-Based Architectureとは？
- Cell-Based Architectureは高度な回復性のデザインパターンで、システム障害における影響範囲（リージョン、AZ、ユーザ単位など）をコントロールするための設計
- システムがどれだけ優れた設計であっても障害は起きる、”Everything fails, all the time.”の思想に基づいている
- コンテナ船の考え方に似ていて、ある一部分が浸水しても、船は動き続けるようにできているものに近い
- 主な目標：もし障害が起きたときにユーザ全体ではなく、ユーザの一部のみが影響を受けるようにする
- 影響範囲のことをCellと呼び、Cell内の高可用性ではなくCell間の分離が重要
Cell-Based Arhitectureのコンポーネント
- Cell:独立してアプリケーションが起動するために必要なものがそろった一式（ALB+ECS+EBSなど）
- Cell Router:リクエストを適切にCellに振り分ける役割を持ったもの
- Control Plane:Cellのプロビジョニングや削除などの管理を担当
Cell-Based Architectureとは？（公式ドキュメント）
https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/what-is-a-cell-based-architecture.html
Cell-Based Architcutureの構築方法
- 既にあるアプリケーションから始める（例：ロードバランサーとデータベースがあるモノリシックなアプリケーション）
- ユーザトラフィックの制御を決定するCell Routerを設置する
- アプリケーションスタックをCell単位に分割するよう、コピーを行う
- 特定のユーザ属性（HTTPヘッダなど）に基づいて、トラフィックを分離するようCell Routerを設定する
- 結果：一つのCellに障害が起きたとしても、そのCellに振り分けられたユーザのみが影響を受けるようになる
Cell Routingの戦略
- Cell RouterはリクエストごとのCellの振り分けにおいて最も重要な役割を持つ
- Cell Routingには3つの方法がある
- DNSベースのルーティング
- API GatewayやLambdaによるユーザ属性の確認
- その他のService Discoveryによる方法
- Cell Routerはシャーディングキーを必要とする（ユーザーID/オーガニゼーションID/認証トークン）
- Cell Routerはできるだけレイテンシーと障害の可能性を小さくするように設計する（Amazon S3の例：S3ではDNS経由でシャーディングを行い、LambdaはアカウントIDを使いシャーディングキーを特定する）
Cellの設計単位
- Cellのサイジングは影響範囲の決定とアーキテクチャの複雑性の間でのトレードオフで重要
- 小さなCellに分割すると、影響範囲は小さくなるが、アーキテクチャ管理の煩雑性が増す
- 最大のCellサイズを設定する必要がある（リージョンなど）が、継続的に変動する
- 影響範囲の制限のため、Cell間は完全に分離する
- 共有リソースはCellごとに複製するか、外部リソースを使うようにする
- ストレージレイヤーを外部のCellにする設計をしているお客様もいる
モノリシックからCell-Based Architectureへの移行戦略
- 移行を後回しにせず、早期に設計と自動化を行う
- 一般的なアプローチ
- 既存のユーザをもとのデプロイメントに配置（Cell 0）し新規ユーザーを新しいCellにルーティングする
- ユーザの使用パターンが時間とともに経過するため、Cellのバランスをとることも大事
- データモデルを理解し、ユーザーやアカウントをどのように分割するかを選択することも大切。ここで生成AIを活用して、データモデルを分析し、ガイダンスを得ることも戦略の一つ
- ストレージのようなCellは分割することも可能
- 外部システムとして扱えるものは外部システムとして扱い分離する
- 設定変更などすべてにプッシュする必要がある場合は、デプロイの一部として段階的に実装する。
管理・運用と自動化
- Cellが増えるにつれて複雑性が増すため、アプリケーションと並行して自己管理システムを構築する
- 必要に応じてCell間でリソースを自動的に移動できるコンポーネントを作成する
- 一般的な問題に対しては自動修復機能を実装するが、広範囲にわたる場合は自動修復が行われないよう閾値を設定する
- 一度実装して終わりではなく、定期的にアーキテクチャをレビューする
コストと複雑性のトレードオフ
-
Cell-Based Architectureはリソースの重複と管理の複雑さによってコストを増加させる
- すべてのアプリケーションに適しているわけではなく、ダウンタイムがビジネスに重要な影響を与えるシステムに向いている
- アプリケーションの最も重要な部分にのみCell-Based Architectureを適用することも可能
- すべてはトレードオフ
大切なこと
- ルーティングレイヤーはシンプルかつ高可用性を保つ（ここがSPOFになるので）
- Cellのトラフィックのバランスを保つ、バランスが崩れることで影響範囲のコントロールが崩れることがある
- 早期にCell-Based Architectureに移行し、自動化とカナリアテストを試していく
- Cellの管理、Observability、自動化に投資する
- ワークロードの特性に応じてCellのサイジングを検討する
- 複雑性とコストと回復性とスケーラビリティのメリットを比較検討する
まとめ・感想
参加者の質問に答えていきながら、実は結構なスライドが用意されてました、というさすがのセッションでした。私のようなNon Nativeが質問できるように手上げの口頭質問だけではなくSli.doが用意されていたり、Chalk Talkが活発になるような工夫もされておりました。（私もいくつか質問して拾われたのですが、どれかは内緒にしておきます）
