はじめに

カミナシでID管理・認証基盤を開発しているmanatyです。ラスベガスで開催されているAWS re:Invent 2024に初めて参加しています。今回はワークショップセッションとして開催された「Scaling multi-tenant SaaS with a cell-based architecture」に参加したレポートをお届けします。

Cell-based Architectureとは

Cell-based architectureはスケーラビリティと耐障害性を高めるために考えられたシステムアーキテクチャです。一般にマルチテナントアーキテクチャはインスタンスやコンテナが複数存在するとしても論理的には単一のアプリケーションとデータベースで構成されています。したがって、本質的にアプリケーションやデータベースはそれぞれが論理的な単位での単一障害点となるほか、特定のテナントの過度な呼び出しによって他の全てのテナントの性能に影響するといったノイジーネイバーと呼ばれる問題があります。

そこで、1つ以上のテナントをセルと呼ばれる独立したアプリケーションおよびデータベースに隔離することで、他のセルの障害や他のセルに隔離されたテナントの過度な呼び出しによる影響から守るのがCell-based Architectureです。

本アーキテクチャはセルルータ、セル、コントロールプレーンの3つの要素で構成されています。セルルータはリクエストに含まれるテナント情報からセルへリクエストをプロキシする役割を担っており、セルはアプリケーションとデータベースを隔離します。最後にコントロールプレーンはセルの作成や削除、テナントの開設などの管理的役割を担います。

このアーキテクチャについてはAWSの公式ドキュメントやAWS Summit 2024でも説明されており、実際にAWS自身が本アーキテクチャで動いていると説明されています。

ワークショップ体験

今回のワークショップでは、あらかじめcell-based Architectureで作られたマルチテナントアプリケーションがデプロイされているAWSアカウントを使って、セルの作成、テナントの作成、アクティベーション、障害の注入と監視といった内容を実施しながらcell-based Architectureを学びました。手順に従ってコントロールプレーンにHTTPリクエストを投げるとStepFunctionsが起動してCloudFormationによって新たなセル（ECSサービスやRDSインスタンス）が起動したり、テナントの作成によってRDSインスタンスにテナントデータが入っていくといったことを体験することで、これまでセッションを聞いて概念だけは知っていた本アーキテクチャを具体的に理解していくことができました。

Cell-based architecture適用の難しいポイント

ワークショップでcell-based architectureを実際に触って理解が深まるとともに、自分の開発している認証基盤含めて実際にこのアーキテクチャを適用する場合にいくつかの難しいポイントが出てくることもわかってきました。

例えば、cell-based architectureの利点の一つにテナントごとに性能要件を変更できることが紹介されていました。これは、無料枠のテナント群には小さいインスタンスを割り当て、VIPなテナントには大きなインスタンスで構成されたセルを専有するといった内容です。確かに、セルによってアプリケーションを隔離することでセルごとの性能も自由に変更してテナントの要件に合わせることができます。一方で、例えば無料枠のセルに含まれるテナントを利用している顧客が、ある日、大きな契約を結んでVIPにアップグレードすることになるとどうなるでしょうか。データベースに含まれるデータを別のセルに移動しつつ、セルルータのルーティングも切り替えて新しいセルに切り替える必要があります。カミナシでも過去にデータベース移行を実施したことがありますが、かなりシビアに検討しないといけないことを顧客の契約変更によって行う必要が出てくるのは運用が非常に難しいと感じました。

もう一つ疑問に思ったのは、セルをまたぐ一貫性担保についてです。例えば、私のチームが開発しているID管理基盤では、全てのユーザーの識別子をシステム全体としてユニークにする必要があります。OpenID Connect Core 1.0でも、IDトークンに含まれるsubクレームは発行者（私たちの場合はID管理基盤全体）で一意であることを要求しています。従って、一般的にはデータベーステーブルのユニーク制約などを利用して担保していることが多いのではないでしょうか。一方で、cell-based architectureではデータベースもセルごとに分離しているため、テーブルの制約で一意性を保証することはできません。セルを跨いだグローバルなID発行サービスを作ると、そこが単一障害点となりこのアーキテクチャの利点が失われてしまいます。セッションを運営していたSAの方と10分ほどディスカッションしましたが、テナントごとにサブドメインを分けたり、AWSコンソールのようにログイン画面でテナントIDを入れてもらう必要があり、cell-based architectureで実現できるユーザー体験に制約がありそうです。

おわりに

今回はAWS re:Invent 2024で開催されたcell-based architectureに関するワークショップのレポートを書きました。cell-based architectureはセルと呼ばれる空間にアプリケーションとデータベースを論理的に隔離し、1つ以上のテナントを各セルに割り当てることでマルチテナントアプリケーションにおけるスケーラビリティと耐障害性を高めることができます。一方で、実運用を考えると難しいことも多く、世の中に存在するほとんどのアプリケーションにとっては過剰な構成です。ただし、特定のセルに先行して機能をデプロイすることでアプリケーションのフィーチャーフラグなしでA/Bテストやカナリアリリースのようなことができたりと活用の可能性も大きいと感じました。コントロールプレーン含めた構築や運用が洗練されてくると、このようなアーキテクチャも利用されるシーンが増えるかもしれません。

明日は弊社CTOの原トリの登壇が、明後日は弊社セキュリティエンジニア西川の登壇もあります！

カミナシではスケーラビリティや耐障害性を考えたID管理・認証基盤を開発するソフトウェアエンジニアを募集しています。今回のようなおもしろアーキテクチャ談義がしたい方はぜひご応募ください。