[レポート] SaaS環境におけるマイクロサービスの分離 ARC210-R #reinvent

AWS re:Invent 2019 ARC210-R - [REPEAT] Microservices decomposition for SaaS environmentsのセッションレポートです。SaaS環境においてマイクロサービスアーキテクチャを適用した際にシステムの単位だけでなくテナント毎のデータをどの単位で分離するかなどという考慮事項があります。本セッションでは事前にアプリケーションと満たすべき要件を定義した上で、どのような分離方法があるかを列挙していました。

セッション情報

登壇者

Tod Golding - Principal Partner Solutions Architect, Amazon Web Services

概要

While the rationale for adopting a microservices architecture is well-understood, selecting the right size and scope of your microservices can be challenging—especially in SaaS environments. SaaS microservices must consider your multi-tenant isolation boundaries, your data partitioning requirements, your multi-tenant scaling profile, and your tiering strategy. These services must also be implemented in a model that abstracts away multi-tenant details and accelerates development. In this session, we look at a range of multi-tenant considerations that will directly affect your approach to identifying and implementing services that align with the scale, isolation, cost, and agility profile of your SaaS environment.

動画

レポート

前提となるマイクロサービス

• 自律的
• 単一の責任
• 自身で所有し管理しているデータ
• テストされ、バージョン管理され、別々にデプロイされている
• 独立してスケールする
• チームによって運用と開発がされている

シングルテナントとマルチテナントのマイクロサービスモデル

• シングルテナント
  • 予測可能
  • 他のシステムの負荷に影響を受けない
  • 限定されたスパイク
  • 単純なスケーリングポリシー
• マルチテナント
  • 共有リソース
  • 他のユーザーの影響を受ける
  • 予測できないアクティビティパターン
  • テナント毎に異なるポリシー
  • 複雑のスケーリングポリシー
  • スパイクの影響を受けやすい

ドメインモデルの考慮外の事項

• サーバーリソースの割当の最適化
• フォールトトレラント
• テナント同士の影響
• データ分離
• バッチ処理
• 特定のテナントのボトルネック

SaaSの分離形式における重要エリア

• テナント隔離
• バルク処理
• フォールトトレラント
• データパーティショニング
• テナントの階層とメトリクス

分離形式を決めるために使用するペルソナ

• Richard Roe
  • コンプライアンスとセキュリティ
• Mary Major
  • コストと運用の容易性
• 立場によって構成に与える影響が全く異なる

テナント隔離

• マイクロサービス毎にデータを保持するかどうか
  • テナント毎にデータを分離するかどうか

デプロイモデル

• テナント毎にサービス分離する
• サービスをテナントで共有する

可用性

• テナントごとにインスタンスを用意する
• インスタンスをテナントで共有する

関連リソース

• テナントごとにIAMを用意して各種リソースの制限を実施する
• IAMを共有しアクセスコントロールの仕組みを実装する

バルク操作

• バルク操作はサービスを逼迫する
• 他のテナントに影響が出る
• SLAに影響する
• バルク操作のみ別サービスにする
• 他のテナントに影響する操作を制限する
• テナントごとにストットリング制御を入れる
• データを処理する流量を制御する

フォールトトレラント

• SaaS環境においてフォールトトレラントと回復性は重要
• 分離する箇所ごとにフォールトトレラントについての考慮が必要
• 部分的にシステムがダウンしても稼働できるようにする
• サービス毎に失敗を識別する
• フォールバック戦略を検討する
• 自己回復戦略を検討する
• 非同期処理が好ましい
• サーキットブレーカーの考慮

データパーティショニング

• テナントごとにデータベースを分ける
• データベースを全テナントで共有する
• コンプライアンスとセキュリティ
• マイクロサービス側もテナントごとにするか、共用とするか
• コストとアジリティーへの影響
• バックアップ/リストアの考慮

データ表現の影響

• スキーマとデータ表現の変更をどのようにマイグレートするか

テナント階層

• SLAが異なる
• ワークロードも異なる
• データ隔離が求められることもある
• 階層ごとの要件が分離戦略に直接影響する
• テナント毎のメトリクスを使用する
• テナント毎のアクティビティを可視化する

コンピュートモデル

• 処理を単一のコンテナに入れた場合、リソースが無駄になることある
• 処理毎にLambdaに分けることで最適化できる

逃げ道を用意しておく

• まずは粒度を大きくして、実際のデータに応じて分離する

先回りしすぎない

• リッチで理論上のモデルを開発しないようにする
• 十分に検討しても、うまく行かないことを想定する
• めったに利用されない機能は分割する必要がないかもしれない

まとめ

• デプロイと隔離の要件は分離に影響するかもしれない
• ドメインのデータが強く紐づくと仮定しない
• テナントの階層、SLA、負荷を設計しておく
• フォールトトレラントの影響を過小評価しない
• メトリクスを用いて分離する
• まずは粒度を大きく始めることを考慮する

感想

マイクロサービスを用いてSaaSを提供する際の考慮事項を学べればと思って参加したのですが、期待通りのセッションであったと思います。マイクロサービスに関係なくSaaSで複数の顧客を扱うシステムにける考慮事項が列挙されてると思いますので、そのようなシステムに関わる方は動画も参照することをおすすめします（スライド単体では公開されない模様です）。