SaaS 向けリレーショナルデータベースのスケーリング (Part 1: 一般的なスケーリングパターン)

ビジネスが成長するにつれて、SaaS (Software as a Service) プロバイダーが直面する課題の 1 つは、テナントのエクスペリエンスをどのように維持するかです。これには、テナントベースが拡大するにつれて、許容できるパフォーマンスとレスポンスタイムを確保することが含まれます。Amazon Relational Database Service (Amazon RDS) や Amazon Aurora などのリレーショナルデータベースは、一般的に SaaS プロバイダーによって使用されています。ビジネスが成長するにつれて、データベースのスケーリング方法も決定する必要があります。

SaaS ビルダーとしての課題は、SaaS ジャーニーの段階に応じて、どのスケーリングメカニズムが適切かを決定することです。アプリケーションが成長するにつれて、既存のソリューションがニーズを満たさなくなった場合、データベースアーキテクチャを変更する必要が生じる可能性があります。新しいテクノロジーやアーキテクチャパターンを実装すると、成長の推進やコア事業への投資から注力が逸れてしまうことがあります。新しいテクノロジーやアーキテクチャに移行するよりも、チームの知識を維持するために既存のアーキテクチャを最適化する方が有益な場合もあります。

このシリーズでは、既存のリレーショナルデータベースを持つ SaaS プロバイダーに対し、効果的にスケーリングする方法のガイダンスを提供します。Part 1 では、SaaS の観点から一般的なリレーショナルデータベースのスケーリングパターンの利点を探り、SaaS ソリューションに適したスケーリングアプローチを選択し、さらなる検討の出発点とするための情報を提供します。Part 2 では、シャーディングとテナントルーティングについて説明します。

データベーススケーリングと SaaS パーティショニングモデル

データベースのスケーリングの説明に入る前に、SaaS のデータ分割モデルを理解することが重要です。利用できる 3 つの高レベルなSaaS 分割モデルは、サイロ、ブリッジ、プールです。

サイロモデル – 各テナントが物理リソース (テナントごとのデータベースインスタンスなど) を個別に持っています
ブリッジモデル – テナントは物理リソースを共有しますが、論理的に分離されています (テナントごとのテーブルやスキーマなど)
プールモデル – テナントは物理リソースと論理リソースを共有します。たとえば、シングルな共有テーブルです

SaaS ソリューションは多くのテナントとそのユーザーのデータをサポートし、ビジネスが成長するにつれてデータも拡張する必要があります。シングルデータベースは最終的にパフォーマンスのボトルネックになる可能性があるため、どのようなスケーリングオプションがあるかを理解しておく必要があります。

リレーショナルデータベースのスケーリングは、大まかに次の 3 つのカテゴリに分類できます。

物理リソース – まず、リードレプリカやシャーディング (このシリーズの Part 2 で解説) によってスケールアウトすることで、データセットの物理リソースを増やすことができます。
データベース操作 – 次に、より適切なインデックス作成やデータモデルの変更などの手法で、データベース操作を最適化できます。
データベースアーキテクチャ – 最後に、データセット全体または一部のデータベースアーキテクチャを変更することができます。これには、purpose-built データベースの利用、キャッシングメカニズムの追加、または非同期プロセスの作成や Command Query Responsibility Separation (CQRS) パターンの実装などの大規模なアーキテクチャ変更が含まれます。このアプローチについては、「Modernize legacy databases using event sourcing and CQRS with AWS DMS」でより詳しく説明されています。

スケーリングメカニズムを組み合わせることで、最良の結果が得られることが多く、特定のパーティション分割モデルや使用パターンに適したスケーリングパターンがあります。このシリーズを通して、これらの違いを検討していきます。

物理リソースの追加による既存アーキテクチャのスケーリング

SaaS プロバイダーがリレーショナルデータベースをスケーリングする際の最初のアプローチは、通常、物理リソースを増やすことです。物理リソースをどこまで拡張できるかには上限がありますが、それまでは、インフラストラクチャのコストが高くなる一方で、コアビジネス目標からリソースを奪うようなアーキテクチャの変更を行わずに、データベースを拡張する効果的な方法です。

垂直スケーリング

SaaS プロバイダーは、最初のスケーリングアプローチとして一般的に垂直スケーリングを選択します。より多くの物理リソース (CPU、メモリ、ネットワーク) を提供することで、より多くの同時接続をサポートできるようになります。既存のパーティション分割モデルを維持したまま、接続設定を変更せずにデータベースをインプレースでスケーリングできます。Amazon RDS では、新しいインスタンスタイプを選択することで、利用可能なあらゆるインスタンスサイズにリソースを垂直にスケーリングできます。これによりインスタンスが再起動され、わずかなダウンタイムが発生しますが、Amazon Aurora Serverless v2では、サービス中断なしでスケールアップとスケールダウンができるため、可変のデータベースワークロードを持つ SaaS プロバイダーに適しています。

サイロモデルでは、SaaS 以外のアプリケーションのスケーリングと比べて、SaaS 固有の違いはありません。ただし、ブリッジモデルとプールモデルでは、スケーリングの要因を評価し、潜在的なリスクを検討する必要があります。より多くのテナントを追加するためにスケーリングすると、ノイジーネイバーやインフラストラクチャの障害など、パフォーマンスに影響を与えるイベントの影響範囲が広がります。同様に、シングルテナントが他のテナントの可用性に影響を与えるためにスケーリングが必要な場合は、テナントのパフォーマンスをスロットリングするか、そのようなテナントをサイロデータベースに移行することで、サービスと運用体験が向上するかどうかを検討してください。

リードレプリカによる水平スケーリング

読み取りの負荷問題を解決する必要がある場合、リードレプリカを使用することで、データ分割モデルを変更することなく、パフォーマンスを向上させることができます。これには他の利点もあります。例えば、RDS リードレプリカをスタンドアロンインスタンスに昇格したり、Aurora ストレージボリュームを新しいクラスターにクローンしたりすることで、可用性を高めたり、データベースのシャーディングを容易にしたりできます。Aurora クラスターには、ボタンをクリックするだけで最大 15 のリードレプリカを設定できます。さらに、Aurora リードレプリカはストレージ層のレプリケーションを使用するため、従来のレプリケーションアプローチと比べて、プライマリへのパフォーマンス影響が少なくなります。

目的に応じて複数のリードレプリカを作成することができます。プライマリインスタンスを使用するサービスに影響を与えることなく、読み取り操作に基づく追加のサービス機能を SaaS 製品に導入できます。これらのアクティビティを様々なインスタンスタイプで実行することで、運用コストを削減できる可能性があります。

リードレプリカの追加や削除は、ダウンタイムを必要としません。Aurora で Aurora レプリカでの Auto Scaling を有効にすれば、リードレプリカのスケーリングを自動的に管理できるため、運用の複雑さを軽減できます。

既存アーキテクチャの最適化

データベースのパフォーマンスを拡張する別の方法は、パーティショニングモデルを変更せずに、既存アーキテクチャを最適化してデータベース効率を改善することです。これにより、スケーリングの必要性を遅らせたり、パフォーマンスの向上によりテナントのサービス体験を改善できます。各最適化アプローチは特定のユースケースに対応しているため、製品にどのアプローチが適用できるかを理解することが重要です。

マイクロバッチ処理

データベースリクエストには、それぞれパフォーマンスのオーバーヘッドが伴います。多くのユーザーが頻繁にリクエストを行う SaaS アプリケーションの場合、同時に多数のリクエストを処理するオーバーヘッドの累積によって、データベースのパフォーマンスが低下する可能性があります。類似のリクエストを マイクロバッチ と呼ばれるパターンでまとめることで、このインパクトを軽減できます。

この手法は、多くのユーザーが頻繁に小さなリクエストを行う場合、すべてのパーティション分割モデルで効果的です。特にプールモデルでは、データベースインスタンスあたりのテナントをさらに多く収容できるため、運用効率がさらに向上します。

運用の複雑さが高まるマイクロバッチ処理を扱うソリューションを作成する必要がある場合があります。次の例では、アプリケーションがデータベースに直接書き込むのではなく、Amazon Simple Queue Service (Amazon SQS) キューに書き込みます。その後、AWS Lambda 関数がこの SQS キューをポーリングし、メッセージバッチを消費して、結果整合性というコストを払って、データベースに原子的に書き込みます。

データベーステーブルのパーティショニング

ほとんどのリレーショナルデータベースでは、論理的に大きなデータベーステーブルを小さな物理的なパーティションに分割するテーブルパーティショニングがサポートされています。パーティション内のデータにアクセスする際、探しているデータを見つけるために親テーブル全体を検索する必要はありません。これは、SaaS アプリケーションが大規模なマルチテナントデータセットを使用するプールモデルにおいて有益です。

テーブルパーティショニングは、日付やテナント ID などのパーティションキーを使ってテーブルを分割します。データベースエンジンによって、パーティションキーに対するレンジ、指定されたキーのリスト、ハッシュ値を使ってテーブルパーティショニングを行えます。ルートテーブルはそのままアクセス可能で、テーブルパーティショニングを活用するためにクエリを再設計する必要はありません。

tenant_id をプールモデルのパーティションキーとして使用することで、アプリケーションコードを再設計することなく、テナント固有のクエリのパフォーマンスを向上させることができます。実装例を次の図に示します。

テーブルのパーティショニングを tenant_id でシングルな物理リソースを超えてスケールさせるには、データベースシャーディングの概念を拡張する必要があります。このシリーズの Part 2 でこの点を詳しく説明します。

データベーステーブルのパーティショニングでは、シングルパーティションがパフォーマンスのボトルネックになり、再調整が必要になるホットスポットが発生する可能性があります。また、パーティションを管理するための運用オーバーヘッドも発生します。Amazon RDS for PostgreSQLまたはAmazon Aurora PostgreSQL-Compatible Editionを使用している場合は、PostgreSQL のpg_partman拡張機能を使用してテーブルパーティションの作成と管理を自動化できます。選択したデータベースエンジンのパーティション制限と、メンテナンス操作を実行する際のロック動作を考慮する必要があります。なぜなら、多くのテナントが同じデータベースを共有している場合に適さない可能性があるからです。環境に変更を加える場合と同様に、期待した結果が得られていることを監視し、変化に応じて適宜調整してください。

データの集約

SaaS プロバイダーは、多くの場合、テナントに分析的な洞察を提供するために、データセット上でユーザーごとまたはテナントごとの集計を行います。メトリクスやメータリングのため、またはデータセットのマルチテナントパフォーマンスを向上させるために、テナントごとまたはテナント間の集計を行うことができます。これにより、データベースが OLTP (オンライントランザクション処理) と OLAP (オンライン分析処理) の両方のクエリに対応する必要が生じる可能性があります。

データセット全体で集計を行う読み取りクエリを実行すると、コストがかかり、テナントに影響を与える可能性があります。このアクティビティが予測できない場合、テナントのパフォーマンスを一定レベルに維持することが難しくなり、サービス体験が低下する可能性があります。この影響は、ブリッジモデルとプールモデルの方が大きく、複数のテナントが同じ物理データベースリソースを共有し、集計アクティビティの競合が発生する可能性があります。

サービス提供に、これらの集計アクティビティからのリアルタイムデータが不要な場合は、結果を事前に計算しておくことができます。たとえば、テナントデータの生成と分析を、オンデマンドで計算するのではなく 3 時間ごとに行うことができます。これにより、データベースのパフォーマンスが均一になり、結果が即座に利用できるようになるため、テナントのサービス体験が向上します。RDS for PostgreSQL または Aurora PostgreSQL データベース上で pg_cron を使用して、このアクティビティを自動化することもできます。これらの結果を配信するためにリードレプリカを使用すれば、さらにパフォーマンスが向上します。

さらに、Amazon Redshift などのデータウェアハウスに分析クエリをオフロードすることができます。Aurora と Amazon Redshift 間のZero-ETL integration により、トランザクションデータベースと分析データベース間でデータをニアリアルタイムに自動的に同期できるため、複雑なデータパイプラインを開発する必要がありません。

ユースケースを評価して、計算前のプロセスを維持することによるオーバーヘッドに見合う価値があるかどうかを検証する必要があります。データアクセスパターンがそのような集計を実行することがほとんどない場合、作業に見合う恩恵は得られない可能性が高いです。

データベース接続のスケーリング

データベースには、利用可能な同時接続数に制限があり、テナントの数に応じて接続数が増加するため、ブリッジまたはプールのデプロイメントモデルを使用すると、この制限に達する可能性があります。これにより、タイムアウトやパフォーマンスの不安定化が発生する可能性があります。

Amazon RDS Proxy などのデータベースプロキシを実装すると、データベース接続をプールして共有できるため、データベースをさらにスケーリングできます。RDS Proxy のパフォーマンス特性の詳細については、Build and load test a multi-tenant SaaS database proxy solution with Amazon RDS Proxy を参照してください。または、RDS Data API のようなデータベースへの接続レスインターフェイスを検討してください。

Purpose-built データベースの導入

成長に合わせてデータベースのパフォーマンスを維持するには、特定のユースケースに最適化するためにデータベースアーキテクチャを変更する必要がある場合があります。この課題に対処する 1 つの方法は、同じデータベース内に個別の論理スキーマを使用し、それぞれを別のユースケースに最適化することです。

SaaS アプリケーションの機能が発展するにつれて、1 つのデータセットを複数に分割することが有益な場合があります。個々のアクセスパターンを分離し、purpose-built データベースに移行できます。複数の異なるアクセスパターンを最適化しようとして、最小公倍数に落ち着くのではなく、代わりにアクセスパターンをデータベース技術に合わせ、そのアクセスパターン専用に最適化することで、適切な作業に適したツールを選択するのです。

例えば、高スループットのトランザクションデータ用に対してや、テナント管理用のキーバリューストアとして Amazon DynamoDB のような NoSQL データベースを使用します。集計アクティビティで使用されるデータを分離するために Amazon Redshift のようなデータウェアハウスを使用し、より高いパフォーマンスレベルが必要なテナントに新しいサービス層を導入できます。既存のリレーショナルデータベースでは実装が難しい、Amazon Neptune を使った不正検知などの新機能を導入し、既存の SaaS 製品に新しい市場を獲得することもできます。

Purpose-built データベースを導入すると、テナント分離の実装方法が変わり、パーティション分割モデルを再評価する必要が生じる可能性があります。パーティション分割モデルを維持できる場合でも、テナント分離の実装方法は異なる可能性があります。新しいデータベース技術を評価する際は、この点を考慮する必要があります。

詳細については、AWS Well-Architected フレームワーク、特にパフォーマンスの柱におけるデータベースアーキテクチャの選択、およびデータ分析レンズの指針に従うことをお勧めします。

データベーススケーリングアプローチの検証

スケーリングアプローチがあなたの期待に沿っているかどうかを十分にテストおよび検証する必要があります。メトリクスは、これらの判断のためのデータを提供する上で重要な役割を果たします。たとえば、Amazon RDS Performance Insights を使用して、簡単で自動化された方法でデータベースのパフォーマンスメトリクスを監視したり、Enhanced Monitoring を有効にして、Amazon RDS コンソールから RDS データベースインスタンスのすべてのシステムメトリクスを表示することができます。スケーリングが期待どおりに機能していないときや、新しいスケーリングメカニズムが必要なときを特定するために、運用管理タスクにパフォーマンスメトリクスを実装することを目指してください。

結論

SaaS アプリケーションの成長に伴い、データベースアーキテクチャも進化していきます。SaaS ジャーニーの中で、既存のアーキテクチャを拡張するか、要件の増大に合わせてアーキテクチャを変更するかを決める必要があります。判断の根拠にはメトリクスを用い、スケーリングアプローチが効果的であることを検証し、さらなるスケーリング手法が必要になったタイミングを把握できるようにしてください。

この投稿では、リレーショナルデータベースのスケーリングアプローチをいくつか取り上げ、SaaS アプリケーションとの関係を説明しました。これにより、リレーショナルデータベースのスケーリング方法を適切に判断できるようになります。Part 2 では、データベースのシャーディングと、テナントをそれぞれのデータセットにルーティングする方法について調査します。

AWS SaaS ファクトリーについて

AWS SaaS Factory は、SaaS ジャーニーのあらゆる段階にある組織を支援します。新製品の構築、既存アプリケーションの移行、または AWS 上での SaaS ソリューションの最適化を検討している場合でも、お手伝いできます。AWS SaaS Factory Insights Hub にアクセスして、さらに多くの技術的およびビジネス的なコンテンツとベストプラクティスを見つけてください。

AWS SaaS Factory チームと協力し、エンゲージメントモデルについてお問い合わせいただくよう、アカウント担当者にご連絡いただくことをお勧めします。

著者について

aaaaaaaaaaaaaa	Dave Roberts は、シニアソリューションアーキテクトであり、AWS SaaS Factory チームのメンバーです。AWS 上で SaaS 製品を構築する AWS パートナーを支援しています。SaaS について話していないときは、ギターエフェクトペダルを作ったり、家族と森で時間を過ごすことを楽しんでいます。
	Josh Hart は、Amazon Web Services のプリンシパルソリューションアーキテクトです。彼は英国の ISV 顧客と協力し、AWS 上で SaaS アプリケーションを構築およびモダナイズするのを支援しています。

翻訳はソリューションアーキテクトの「藤川貞信」が担当しました。原文はこちらです。

Amazon Web Services ブログ