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

SaaS on AWS を成功に導くためのポイントとは ? 第 6 回

2021-10-05
ビジネス x クラウド

櫻谷 広人

皆様こんにちは、三度の飯より SaaS が大好き、SaaS パートナーソリューションアーキテクトの櫻谷です。

この SaaS 連載も第 6 回目を迎えるということで、過去の記事を参考にすでに SaaS を作り始めているという方もきっといらっしゃるのではないでしょうか。

今回のテーマはデータパーティショニング、つまりデータストアの設計に関するお話になります。どんなサービス / アプリケーションであっても、それが提供する機能は詰まるところすべてデータの保存や参照に関わるものであり、どこにどのような形でデータを保存するか、どうやって読み出すかといった考慮点は設計の要です。これは、データストアの選定からスキーマのモデリング、API の実装まで影響するスコープが広く、後から変更することが難しい部分も多いため、より一層入念な検討が必要な作業でもあります。

そして SaaS においては、さらに 1 つの重要な課題が追加されます。それはマルチテナンシーに関するものです。第 2 回のテナント分離の記事 で複数のデプロイメントモデルの説明をしましたが、データストアに関しても同様に、専用にするか共有にするかといった選択肢が存在します。まずは、このテナンシーに関して、どのように決めていけばよいのか、その指針となるポイントを整理していきます。

この連載記事のその他の記事はこちら

↓ SaaS on AWS を成功に導くためのポイントとは バックナンバー ↓
  • ↓ SaaS on AWS を成功に導くためのポイントとは バックナンバー ↓
  • 第 1 回 SaaS on AWS を成功に導くためのポイントとは ?
  • 第 2 回 SaaS ビジネスの成否を分けるテナント分離戦略
  • 第 3 回 動的なポリシー生成を使ったテナント分離
  • 第 4 回 SaaS on AWS における認証認可の実装パターンとは ?
  • 第 5 回 SaaS におけるオンボーディングとは ?
  • 第 6 回 SaaS におけるデータパーティショニング設計の勘所
  • 第 7 回 SaaS におけるメトリクスの取得と可視化

ビジネス要件の整理

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

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

コンプライアンス

データのレジデンシーに関する要件です。これは提供するサービスのドメイン / 顧客のニーズ / データの性質などによって、どこまで厳格に求められるかが大きく変わってきます。

レジデンシーとはつまり、どこにデータが保存されているかということですが、国内 or 海外、オンプレミス or クラウド、専用ハードウェア or 共有ハードウェアなど、いくつか観点があるかと思います。オンプレミスと一言で言っても、自社のサーバールームなのか、共有 DC のコロケーションなのか、そういった違いも場合によっては重要かもしれません。また、個人情報を取り扱うワークロードの場合、データ保護を目的として制定されている法令は各国で異なるため、どの国でサービスを提供するのか、データが置かれているサーバーがどの国に存在するのかといった点も無視できません。

あるいは、HIPPA、PCI DSS、3 省 2 ガイドラインといった業界標準への準拠も、データストアの設計に大きな制限を課します。

コンプライアンスについては、トレードオフというよりも取り得る方法が強制される条件になるため、まずはサービス提供にあたってどのようなコンプライアンス要件があるのかから考え始めてみるのがよいのではないでしょうか。

パフォーマンス

テナント分離の回 でも述べましたが、基盤となるインフラストラクチャを共有するプールモデルでは、しばしばノイジーネイバーと呼ばれる問題が発生します。大規模顧客の利用量が突出して多い場合などにおいて、システムリソースの大半がそのテナントの処理に消費され、他のユーザーのレスポンスに影響が出てしまうようなことが起こりえます。全てのユーザーに平等に、または契約しているプランに沿った異なるレベルのパフォーマンスを一貫して実現するためには、適切にシステムリソースを配分する必要があります。ノイジーネイバー問題はデータベースにおいても同様に発生し得るので、各テナントのデータ量、クエリパターンなどに応じて適切な対策を講じましょう。

コスト

そもそもマルチテナンシーを採用する主な理由は、効率性のためです。マルチテナント SaaS においては、リソースを集約することによるサーバーコストの節約、単一の共有環境を中央管理することによる運用効率の最適化などを図ることができます。ただし、これはコンプライアンスやパフォーマンスとのトレードオフになります。先に述べたようなノイジーネイバー問題のリスクを許容してコスト最適化の方を取るのか、パフォーマンスを最優先として各テナントに専用リソースをそれぞれ提供するのか、どちらに重きを置くかはビジネス要件に応じて決めるべきものです。


データストアの整理

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

img_saas-data-partitioning_01

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


リレーショナルデータベースの設計パターン

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

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

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

クリックすると拡大します

img_saas-data-partitioning_03

クリックすると拡大します

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

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

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

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


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 フレームワーク を活用して定期的にワークロードの状態を評価したり、利用できる最新技術のキャッチアップも怠らずに、常により良いアーキテクチャを目指していきましょう !

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

この連載記事のその他の記事はこちら

↓ SaaS on AWS を成功に導くためのポイントとは バックナンバー ↓
  • ↓ SaaS on AWS を成功に導くためのポイントとは バックナンバー ↓
  • 第 1 回 SaaS on AWS を成功に導くためのポイントとは ?
  • 第 2 回 SaaS ビジネスの成否を分けるテナント分離戦略
  • 第 3 回 動的なポリシー生成を使ったテナント分離
  • 第 4 回 SaaS on AWS における認証認可の実装パターンとは ?
  • 第 5 回 SaaS におけるオンボーディングとは ?
  • 第 6 回 SaaS におけるデータパーティショニング設計の勘所
  • 第 7 回 SaaS におけるメトリクスの取得と可視化

builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

プロフィール

photo_sakuraya-hiroto

櫻谷 広人
アマゾン ウェブ サービス ジャパン合同会社
パートナーソリューションアーキテクト

大学 4 年から独学でプログラミングを習得。新卒で SIer に入社して Web アプリケーションの受託開発案件を中心にバックエンドエンジニアとして働いた後、フリーランスとして複数のスタートアップで開発を支援。その後、toC 向けのアプリを提供するスタートアップで執行役員 CTO を務める。現在は SaaS 担当のパートナーソリューションアーキテクトとして、主に ISV のお客様の SaaS 移行を支援。

AWS のベストプラクティスを毎月無料でお試しいただけます

さらに最新記事・デベロッパー向けイベントを検索

下記の項目で絞り込む
絞り込みを解除 ≫
1

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する