SaaS におけるデータパーティショニング設計の勘所

データストアの設計においても、どんな場合でもこれがベストであるといった銀の弾丸は存在しません。様々なビジネス要件に応じてあらゆる角度から検討を重ねていくわけですが、ではどういった観点が考えられるでしょうか ?

本記事では、「コンプライアンス」、「パフォーマンス」、「コスト」の 3 点に着目して話を進めていきます。

次に、データストアについても整理しておきましょう。SaaS に限らず、システムで使うデータストアは一つに限定する必要はありません。AWS ではさまざまな種類のデータベース / ストレージサービスが提供されており、データの特性や目的に応じて最適なものを組み合わせてアーキテクチャを構成していく考え方を推奨しています。例えば、トランザクション管理が必要ならリレーショナルデータベースで Amazon Relational Database Service (Amazon RDS) 、高スループット・低レイテンシが求められる場所ではキーバリュー型の NoSQL データベースの Amazon DynamoDB、画像コンテンツやバックアップにはオブジェクトストレージの Amazon Simple Storage Service (Amazon S3) といった使い分けが有効です。

サービスごとに使える機能や設計思想が異なるため、どのデータストア/ AWS サービスを使うかによって、データパーティショニングのパターンは様々です。今回は代表的なリレーショナルデータベースと NoSQL データベースのパターンをご紹介します。

考慮すべき観点とトレードオフ、そしてデータストアの種類を理解したところで、設計パターンの紹介に入っていきます。マルチテナントといっても、その共有度合いにはいくつかバリエーションがあります。そして、その共有度合いに応じたパーティショニングの設計が存在するわけですが、これらは使用するデータストア / サービス / ソフトウェアごとに様々なので、まずはリレーショナルデータベースにおける考え方を見ていきます。

例として、データベースエンジンとして PostgreSQL を、AWS のサービスとして Amazon RDS を利用するケースを検討してみます。この場合、取り得るパーティショニングのパターンは大きく 4 つあります。

1. テナントごとにそれぞれ RDS インスタンスを用意し、それぞれのインスタンス内にテナント固有のデータベースを作成する (サイロモデル)
2. 共有 RDS インスタンスを用意し、その中にテナント固有のデータベースをそれぞれ作成する (インスタンス共有プールモデル)
3. 共有 RDS インスタンスおよび共有データベースを用意し、その中にテナント固有のスキーマをそれぞれ作成する (データベース共有プールモデル)
4. RDS インスタンス、データベース、スキーマ全てを複数テナントで共有する (スキーマ共有プールモデル)
   

下に行くにつれて共有度合いが高まっていきます。コストを最優先とするのであれば、4 のテーブル共有を目指すべきですが、その場合パフォーマンスをある程度犠牲にする必要があるかもしれません。また、第 3 回の動的なポリシー生成を使ったテナント分離 の記事で紹介したような、クロステナントアクセスを防ぐためのテナント分離の仕組みを適切に実装してデータを保護する必要があります。

パフォーマンスについては、実は 2-4 の全てのパターンで同様の課題があります。RDS インスタンスを共有する場合、そのインスタンスに割り当てられている CPU / メモリなどは完全に共有されたプールリソースです。例えば 2 のパターンにおいて、「特定のデータベースに関する処理のためにメモリを 2 GB 確保しておく」といった割り当てを行うことはできません。あるデータベースに対して大量の処理が発生した場合は、処理できる分だけ空きリソースを最大限消費しようとします。何らかのリソース割り当てや優先度付きキューのような仕組みはないため、このあたりがネックになるような場合はインスタンスを分ける必要があります。

データパーティショニングの設計はとても複雑な作業です。ノイジーネイバーに対してどのような対策ができるのか、個別の専用環境を用意するコストはどれくらいか、クロステナントアクセスを防ぐために取り得る方法はどんなものがあるかといった多方面からの検討を行い、慎重にトレードオフを検討していく必要があります。

これは Amazon RDS for PostgreSQL を前提とした例ですが、データベースエンジンやデータストアの種類が変われば見るべきポイントも変わります。また、利用できる AWS のサービスの機能も異なります。次に、DynamoDB における考え方を見ていきます。

AWS が提供するマネージド NoSQL データベースの一つ、Amazon DynamoDB についてですが、テナント分離に関しては 動的なポリシー生成を使ったテナント分離 で紹介した IAM ポリシーの条件キー dynamodb:LeadingKeys を活用する方法で比較的簡単に実装することができます。パフォーマンスに関しては、 DynamoDB 特有のスループットの考え方を知っておく必要があります。その核となるキャパシティーの仕様に関する詳細は AWS ドキュメント をご覧ください。

プロビジョニングモードの場合、テーブルに設定されているキャパシティーユニットの数が秒間のスループットを決定します。例えば、1 つの読み込みキャパシティーユニットは最大 4KB の項目を 1 秒あたり 2 回の結果整合性のある読み込みを実行できます。このキャパシティーユニットはテーブル単位での設定となるため、複数テナントから使用される共有テーブルモデルを採用する場合は、ノイジーネイバー問題の影響を受ける可能性があります。

では、テーブルをテナントごとに作成して独立したキャパシティを割り当てるモデルが最適なのでしょうか ? こちらの場合も注意が必要なポイントがあります。AWS が定める サービスクォータ では、一つのリージョンで作成できる DynamoDB テーブルの数はデフォルトで 256 個までとなっています (※本記事公開時点)。テナント数が少なければテーブル単位でのパーティショニングも採用可能かもしれませんが、そうでない場合は上限緩和申請や複数リージョンの併用も考える必要が出てくるでしょう。AWS のサービスを使用する際は、このサービスクォータという観点も設計に組み込んでおくことをおすすめします。

全て紹介することはできませんが、このように各サービスごとに利用できる機能やサービスクォータによって様々なパターンが存在します。例えばデータウェアハウスとして Amazon Redshift を使う場合は ワークロード管理 の機能を使って上位ティアのテナントのクエリを優先的に処理するメカニズムを構築することができます。また、メッセージキューの設計では、Amazon SQS の通常キューと FIFO キュー を組み合わせて、テナントの優先順位やスループット、コストを考慮した複雑なワークフローを作り込むこともできるでしょう。繰り返しになりますが、サービスクォータの制限に関しては全てのサービスで気をつけておく必要があります。

各サービスで利用できる機能は、お客様からの要望に基づいて日々アップデートされています。SaaS を開発する上で何かお困りごとがあればぜひフィードバックをお寄せください。

設計の正解は一つだけではありません。それぞれのビジネス要件に応じた最適解を模索して、時にはトレードオフを受け入れる必要があります。また、今日の正解が明日の正解である保証もありません。

ストック型のビジネスである SaaS では、順調にサービスが成長を続けていけば、利用ユーザーやデータ量は増え続けていきますし、ユーザーの利用パターンも不変ではありません。日頃からメトリクスを監視し、微調整を繰り返して最適な構成を育てていく必要があります。AWS Well-Architected フレームワーク を活用して定期的にワークロードの状態を評価したり、利用できる最新技術のキャッチアップも怠らずに、常により良いアーキテクチャを目指していきましょう !

次回の連載もお楽しみに !