この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
概要
SaaS presents developers with a unique blend of architectural challenges. While the concepts of multi-tenancy are straightforward, the reality of making all the moving part work together can be daunting. For this session, we’ll move beyond the conceptual bits of SaaS and look under the hood of a SaaS application. The goal here is to examine the fundamentals of identity, data partitioning, and tenant isolation through the lens of a working solution and highlight the challenges and strategies associated with building a next-generation SaaS application on AWS. We’ll look at the full lifecycle of registering new tenants, applying security policies to prevent cross-tenant access, and leveraging tenant profiles to effectively distribute and partition tenant data. The goal here is to connect many of the conceptual dots of a SaaS implementation, highlighting the tradeoffs and considerations that will shape your approach to SaaS architecture.
SaaSをAWSで構成するために必要なアーキテクチャや中身の実装についての詳細をセッション。ユーザーアイデンティティの基本、データパーティションの設計、そしてTenantの独立について調べていきます。SaaS設計の基本的なコンセプトと実装をつなぎ、SaaSアーキテクチャへのアプローチと必要不可欠な要素を確認します。
内容
SaaSはPoolModel, Sharing Resourceモデルに基づきます。SaaSで必要な要素は以下になります。
- Onboarding: ユーザー登録・管理
- Authentication: ユーザー認証。そのユーザーがどのTenantに属しているか？などを判断する必要
- Application Services: アプリケーション（ロジック）。ContextでTenant情報を共有するため、Multi-tenant用に準備する必要はない
- Storage Partitioning: データストレージの分離
- Metrics/Analytics: 監視メトリクス及び監視
- Management: システム全体の管理
- Billing: SaaSのAPIに関わる課金
このうち Onboarding, Authentication, Application Services, Storage Partitioningはこちらのワークショップ で体験しました。
SaaSコンセプトアーキテクチャ
- フロントのWebサイトはAngular JS Client。S3バケットにて静的Webホスティングで公開
- アプリケーションサービスはECS。いくつかのサービスはデータストアにDynamoDB Tableを利用。
- APIエンドポイントはAPI Gateway。アプリケーションへのRoutingを行い、単一のドメインで複数のサービスを呼び出す。
- 認証にはCognitoを利用します。
Provisioning Environment
VPC, AZ, ネットワーク, 使用サービスの概要はこちら。
SaaSで提供するアプリケーションサービスはすべてECSで稼働しています。データストアに関しては前述してあるので省いていますが、実際にはDynamoDBがあり、それぞれアプリケーションサービスからテーブルを参照しています。このあたりはMutli-tenant独自のものはなく、一般的なアプリケーション環境と言えそうです。
Tenant Onboarding
ここではユーザーの登録によって認証情報の生成やRoleの作成等を行い、管理するための機能という意味のようです。ユーザーOnboarding機能の要素は以下。
- LoginページにRegisterリンクを配置
- Registerページで登録情報を入力してPOST
- ユーザーIDと仮パスワードが記載されたEmailを受信 （到達可能な正しいメールアドレスかを確認。Validation Email Address）
- 仮パスワードをリセットし本番パスワードへの強制変更
Tenant Onboardingの実装
Cognitoは認証と共にそのTenantに紐づくRole Policyを返却する役割を担っています。
Provisioning custom attributes
Cognitoにカスタム属性を追加します。OIDC標準の項目以外に独自の項目を属性で追加します。
- tenant_id
- tier
- company_name
- role
- account_name
それぞれCognitoに用意されている属性には存在しないため、カスタム属性として追加します。これらはそのユーザーの権限等を評価する際に利用されます。
Billing Account
SaaSでは利用料金を管理する必要があります。
Tenant登録時にSQSキューを通して非同期でそのTenant用のBilling用アカウントが作成されます。
Authentication with SaaS Context
Cognitoでの認証後に取得できるJWT ID TokenをContextに利用します。このTokenはAuthorizationヘッダに Bearer と共にRequestに付与されてくるため、Requester側が明示的に情報を付与する必要はありません。RequestのContextとして共有されるため、ユーザーの認証状態やRoleなどはこちらのJWT ID Tokenをサービスとして実装されているToken Managerへ問い合わせることで必要な情報を返します。
例えばTenantIDとか知りたければToken Managerへ問い合わせを行います。Token ManagerはJWT ID Tokenを紐解いてこの場合はカスタム属性である tenant_id を取り出して返却します。
IAM Role PolicyとのMappingはCognitoの機能を利用
カスタム属性の値にマッチしたPolicyを返却する。
Connecting identity and isolation
認証と同時にTenantが紐づくIAM Role PolicyをCognitoがマッピングして返却します。これによりデータストアに格納されているデータの独立性が担保されます。データはIAM Role Policyによって保護されているため、異なるPolicyのTenantからのアクセスは許可されません。
Metering Consumption
SaaSで重要な各Tenantがどれだけリソースを利用したかを計測し、集計します。
Binding custom roles to users
Cognitoに追加したカスタム属性を利用してRoleのマッピングを行います。
Microserviceの管理
システムの正常性を確認するための管理コンソールを作成します。それぞれのサービスが正常に動作しているか、それぞれのサービスのメトリクスを閲覧、監視し問題がないかを確認します。
まとめ
- 認証はSaaSアプリケーション設計で基本中の基本ですよ
- IAMを使いこなすことでSaaSのTenantごとの独立性に強力な力を発揮するよ
- Security/Tenant Contextによって開発を制限することができるよ
- システムとTenantのRoleに関しては影響を十分に考えよう
- SaaSの利用量の計測と解析は優先順位をつけておきましょう
- 稼働しているSaaSシステムの障害は往々にしてEnd-to-Endが原因
聴講してみて
ちょうど前日に受けたWorkshopと同じSaaSについての解説だったので、とても良い復習になりました。特にWorkshopでは触れることができなかった、Billing周りの構成についてや管理、監視といった項目についても触れていたため、色々と知識が補間される部分が多かったです。
Workshopでも触れていましたが、SaaSを構築する上で必要なエッセンス（コアコンセプトやキーワード）を改めて確認することができました。たまたまですが、Workshopと同時に受けることができてとても良かったセッションでした。
2
