オライリー出版のマルチテナントSaaSアーキテクチャの構築を読んで、大事なポイントや気づいた点を個人的にまとめたいと思う。
とはいえ、全体で17章もあるボリュームの書籍であるため、このブログでも何回かに分けて取り扱いたい。（最終的な総括も記事にする予定）
あくまで読者メモなのでかなり内容を間引いている。
より深く情報を得たい人は実際に書籍を手にとって読んで欲しい。
文鳥と暮らす在宅エンジニア yassan です。効率よく働きながら生活の質を高めるアイデアを共有しています。
はじめに
- はじめに
- SaaSは登場してから長いがベストプラクティスは未だにない。
- SaaSの定義が曖昧すぎる。
- SaaSのアーキテクチャ・ビジネスをより具体的にする必要がある。
- SaaSの主要な要素をエンドツーエンドに1冊にまとめた。
- SaaSアーキテクチャは運用上のビジネス目標（俊敏性、イノベーション、コスト効率）に大きく左右される。
- 俊敏性：
- イノベーション：
- コスト効率
- 進化する状況
- クラウド登場以前：顧客がコンピューティングクラスタを共有し、DBを分けるモデルが多い。
- クラウド登場以後：クラウドの利点を活かして要件に合わせた展開が可能になった。
- クラウドの利点：マネージドサービス、動的な拡張性、従量課金制など
- このクラウド構造をSaaSアーキテクチャにどう活用するかの重要性が高まった。
- 対象読者
- SaaSに関わる全ての人
1章 SaaSマインドセット
- 出発点
- 従来は「インストール型ソフトウェア」が主流だった。
- ISV（ソフトウェアベンダー）はデリバリーと設定の詳細に関与せず、機能的な能力を継続的に強化することに注力する。
- 特定の顧客に専用のチームを作ってサポートする場合もある。
- 俊敏性、拡張性、運用効率よりも、長期での販売を前提に契約締結が優先される。
- 前者を引き換えに顧客が必要なものを何でも販売できることに重点を置いている。
- 顧客環境のばらつきから、新機能のリリースは遅い傾向があり、ベンダーは4半期や半年ごとのリリースになる。
- このモデルでは経済的にも業務的にも拡張性がない。
- 統合モデルへの移行
- 顧客ごとのサポートモデルをやめて、統合された体験を提供するモデルが登場した。
- 1つのリソースセットを「テナント」が共有して占有する。
- リリース機会をうみ、追加の運用コストなく、テナントを増やすことができる。
- 新しい課題も登場する。
- セキュリティ、パフォーマンス、拡張性、可用性、回復力など。
- SaaSアプリを一元的に管理、運用、デプロイするための機能、横断的なコンポーネント群の導入が必要。
- SaaS開発は、アプリケーションよりも、共有に必要なコンポーネントから取り組むことを推奨する。
- コンポーネント：オンボーディング、アイデンティティ、メトリクスと分析、請求とメータリング、管理と監視、DevOpsとデプロイ
- これらが基盤になって、アプリケーションアーキテクチャを最適化する。
- マルチテナントの最定義
- 様々なパターンの「マルチテナント」が存在する。
- インフラ共有の有無、マイクロサービスの分離など。
- MSP ≠ SaaS。MSPは顧客別に異なるバージョンを提供するのが大きな違い。
- 様々なパターンの「マルチテナント」が存在する。
- SaaSの本質はビジネスモデル
- 少数のニーズより多数のニーズを優先すべき。
- 1回鍵ちのサポートを必要とする単発的な対応をせず、サービスの長期的な成功を犠牲にしない。
- SaaSのビジネス戦略を左右する5つの重大テーマ。
- 俊敏性、運用効率、イノベーション、スムーズなオンボーディング、成長。
- これらはSaaS企業においてトップダウンに推進されるべき。
- ビジネスビジョンをもとに構築するソリューションのアーキテクチャ、運用、管理方法に影響する。
- ビジネスビジョンから導くもの：ターゲットとなるテナントのペルソナ、パッケージング、プライシング、コストモデルなど。
- 製品ではなくサービスを構築する
- 製品価値だけでなくサービスの質も重要になっている。
- 簡単に導入できるか、価値を実感できるか、フィードバックの提供が早いか、システムダウンの頻度など。
- 製品価値だけでなくサービスの質も重要になっている。
- SaaSの定義
- 下記を満たすビジネスとソフトウェアのデリバリーモデル
- 顧客とプロバイダーの両方に最大の価値をもたらす。
- 摩擦の少ないサービス中心のモデルでソリューションを提供できる。
- 成長、市場拡大、イノベーションを促進するビジネス戦略の柱とする。
- 俊敏性と運用構築に重点を置く。
- 下記を満たすビジネスとソフトウェアのデリバリーモデル
2章 マルチテナントアーキテクチャの基礎
- 導入
- SaaS環境の土台、最優先に定義する必要があるもの。
- テナントの概念と、テナントコンテキストがどのようにアーキテクチャに導入するか。
- マルチテナントアーキテクチャのどのレイヤーにテナントが関わるか。
- マルチテナントアーキテクチャの様々な要素のグルーピング。
- 共通要素の特定、オンボーディング、認証、運用、管理を実現する。
- テナントの概念と、テナントコンテキストがどのようにアーキテクチャに導入するか。
- SaaS環境の土台、最優先に定義する必要があるもの。
- テナントを追加したアーキテクチャ
- 従来のアーキテクチャのマインドセットは、ソフトウェアを所有しており、ソフトウェアのコピーを顧客ごとに作成する。
- テナントの要素を追加したことで、認証、ルーティング、拡張性、パフォーマンス、ストレージの実現方法、アプリケーションのビジネスロジックが一部変更される。
- システムがどのように利用されているかを観測する必要性が出てくる。
- あらゆるSaaSアーキテクチャの2つの要素（アプリケーションプレーン・コントロールプレーン）
- アプリケーションプレーン：SaaSアプリケーション、サービス、テナントプロビジョニング
- シングルペインオブグラス。
- アプリケーションプレーンは、SaaS製品の機能を具体化したもの。
- コントロールプレーン：プロバイダー管理アプリケーション、オンボーディング、テナント、請求、アイデンティティ、メトリクス、管理者ユーザー管理
- 全てのテナントにまたがる。
- SaaSアーキテクチャの議論は、コントロールプレーンから始まる。
- バージョン管理、更新、デプロイに関する独自のプロセスを持つ。
- それぞれ技術要件を個別に検討する必要があり、必ず使用技術が一致する必要はない。
- アプリケーションプレーン：SaaSアプリケーション、サービス、テナントプロビジョニング
- コントロールプレーンの内部
- オンボーディング
- SaaS製品にサインアップし、コントロールプレーンを介してプロセスを開始する。
- 最初のリクエストの後、コントロールプレーンが残りのオンボーディングフローを処理し、テナントに必要な情報を入力する。
- アイデンティティ
- ユーザーアイデンティティとテナントアイデンティティを持つ。
- アーキテクトやビルダーは、全体的な認証モデルの要件を満たしながら、2つの概念を結びつける戦略が必要。
- フェデレーションを混ぜ出すとさらに複雑になる。
- メトリクス
- テナントのアクティビティを収集・集約するための統合ハブを構築して、個々のテナントの用途や利用状況を監視及び分析できるようにする。
- メトリクスは、運用状況の把握、システムの健全性、トラブルシューティングなどに利用する。
- プロダクトオーナーもカスタマーサクセスも利用する。
- 請求
- テナントのアクティビティを計測して、課金する。
- テナントのアクティビティ：帯域幅の使用量、リクエスト数、ストレージの使用量など。
- 請求システム自体は専用のサービスとなるおこともある。統合は必要。
- テナントのアクティビティを計測して、課金する。
- テナント管理
- テナントの作成と状態の管理に必要な機能をもつ。
- テナントに関連づける一意の識別子、請求プラン、セキュリティポリシー、アイデンティティ設定、アクティブ/非アクティブの状況といった主要な属性のトラッキング。
- 他の要素を組み合わせず、一元化されたサービスであることが大事。
- テナントの作成と状態の管理に必要な機能をもつ。
- オンボーディング
- アプリケーションプレーンの内部
- テナントコンテキスト
- 多くの場合、トークンやその他の要素として表現され、テナントという属性をパッケージ化する。
- 例えばJWTで、ユーザー情報とテナント情報1つの構造としてまとめられる。
- SaaSアーキテクトは、テナントコンテキストがシステム全体にどのように適用されるか常に意識する。
- 多くの場合、トークンやその他の要素として表現され、テナントという属性をパッケージ化する。
- テナント分離
- 共通のインフラストラクチャ環境で共有したり、近い場所に配置する。
- 他のテナントのリソースへのアクセスを防ぐには、テナント間のアクセスを防ぐ仕組みが必要。
- データパーティショニング
- データをどこにどのように保存するかは、様々な要素によって決まる。
- データの種類、コンプライアンス要件、利用パターン、データサイズ、使用する技術など。
- ストレージモデルの設計をデータパーティショニングと呼んでいる。
- 専用の構造に保存されている場合もある、共有の構造に保存される場合がある。
- データをどこにどのように保存するかは、様々な要素によって決まる。
- テナントのルーティング
- 全てのテナントからリクエストを受け入れ、テナントコンテキストを使用してルーティングする。
- デプロイ
- 初期バージョンとそれ以降の更新をデプロイできるDevOpsが必要。
- 専用・共有が混在する場合、マルチテナント構成が可視化できるデプロイ自動化コードが必要。
- IaCにおいても場合によって、マイクロサービスの構成とセキュリティ設定にテナントコンテキストを適用する必要がある。
- テナントコンテキスト
- グレーエリア
- ティアリング
- ベーシック、アドバンスド、プレミアムのような価格帯の異なる製品を提供する。
- パフォーマンス、ユーザー数、機能、SLAなどに制約をつける。
- ティアリングはテナントコンテキストに含まれる。
- テナント、テナント管理者、システム管理者
- 「ユーザー」という用語は誤解を招きやすいので避けるべき。
- テナント管理者：システムにオンボーディングされたテナントの初期ユーザー。管理者権限を持つ。
- テナントユーザー：管理機能なしでアプリケーションを利用するユーザー。アプリベースの役割が割り当てられる。
- システム管理者：SaaSプロバイダーに紐づけられており、コントロールプレーンを操作する。管理コンソールを介する場合もある。コントロールプレーンに属する。
- SaaSアーキテクトは、これらの役割を考慮する必要がある。
- 「ユーザー」という用語は誤解を招きやすいので避けるべき。
- テナントのプロビジョニング
- オンボーティングがコントロールプレーンが把握するかどうかで分ける。
- ティアリング
3章 マルチテナントのデプロイモデル
- デプロイモデルとは何か？
- アプリケーションプレーン内でリソースとインフラをどのようにデプロイするかを指す。
- デプロイモデルの選択、サイロモデルとプールモデルの紹介
- リソースが特定のテナントに専用に割り当てられているモデルを「サイロ」と呼ぶ。
- 1つまたは複数のテナントがリソースを共有するモデルを「プール」と呼ぶ。
- コンピューティングはプール化し、ストレージはサイロ化など複合する場合がある。
- フルスタックのサイロデプロイ
- テナントごとに全てのリソースが完全にサイロ化された環境。
- 例えば、AWSアカウント単位でテナントを分ける。
- アプリケーションプレーンの全てがサイロになっており、外部へ共有リソースを配置することは趣旨に反する。
- たとえフルスタックのサイロを最初の出発点としていても、ソリューションはフルスタックのプールモデルになるかのように構築すべき
- このモデルは、アンチパターンというわけではない。
- 効率性の課題はあるが、SaaSの価値は提供できる。
- 選択肢に入るケース。
- 特定のコンプライアンス要件に対応する場合。
- レガシーソリューションをSaaSに移行する場合。
- ディアリング戦略で個別の環境を提供する場合。かつ1回限りの場合。
- テナント数が限られている場合。
- 長所
- 問題発生した時に、テナント単位で分離して対応できる。
- コスト集計が簡単。
- 個別のカスタマイズ要求に対応することができる。（SaaSの体験価値は失う）
- 短所
- コントロールプレーンが複雑になる。
- 完全なプロビジョニング作業の発生。
- 監視の複雑化。
- アクセス間の複雑化。
- インフラリソースの管理・運用ツールの大規模化。
- 更新デプロイが各テナントのサイロに配信する。
- 拡張性に限界があり、規模が膨大になるB2C環境には不向き。
- コスト効率が悪い。
- 利用していないインフラリソースのコスト発生のリスクがある。
- インフラリソースの全体最適化ができず、サイロ内で過剰なプロビジョニングが行われるリスクがある。
- コントロールプレーンが複雑になる。
- パターン１：テナントごとのアカウントモデル（AWSアカウントレベルでサイロ化する）。
- クォータの制約により、オンボーディングの自動化が難しい。
- 何百、何千レベルでの拡張性を持てない。
- パターン２：テナントごとのVPCモデル（VPCレベルでサイロ化する）。
- サーバーレスでは実現できない。
- オンボーディングの自動化は可能。
- VPCにも数にも限界がある。
- テナントごとに全てのリソースが完全にサイロ化された環境。
- フルスタックのプールモデル
- テナントのアプリケーションプレーンのリソースすべてが共有インフラストラクチャモデルで稼働する。
- テナントコンテキストの役割が大幅に向上。
- テナントコンテキストを常にマッピングする必要がある。
- プール化されたリソースは、複数のテナントに割り当てられることを原則とする。
- 長所・短所は基本的にフルスタックのサイロモデルの逆。
- ダウンタイムゼロに重点的に取り組む。
- フォールトトレランス戦略に重点的に取り組む。
- ノイジーネイバー問題への対処が求められる。
- テナントのアプリケーションプレーンのリソースすべてが共有インフラストラクチャモデルで稼働する。
- ハイブリッドなフルスタックデプロイモデル
- 要件やティアリング戦略によってはフルスタックのサイロモデル/プールモデルが共存しても良い。
- サイロモデル側のテナントが多くならないように注意。
- ポッドのデプロイモデル
- プールとテナントをまとめた単位をポッドとする。
- ポッド単位でデプロイをする戦略。（推奨）
- プールモデルの場合、インフラリソースに限界が来た時に対応できる。
- ノイジーネイバー問題への対処、セキュリティ、可用性が向上する。
- テナントの属性に合わせた最適なポッドへの割り当てができる。
（この記事ではここまで）
