翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
SaaS アプリケーションのデータベースの選択
多くのマルチテナント SaaS アプリケーションでは、運用データベースの選択をリレーショナルデータベースと非リレーショナルデータベースのどちらにするか、またはこれら 2 つの組み合わせに分割できます。意思決定を行うには、以下の高レベルのアプリケーションデータ要件と特性を考慮してください。
-
アプリケーションのデータモデル
-
データのアクセスパターン
-
データベースのレイテンシー要件
-
データ整合性とトランザクション整合性の要件 (アトミック性、整合性、分離性、耐久性、ACID)
-
リージョン間の可用性と復旧の要件
次の表は、アプリケーションデータの要件と特性を一覧表示し、 AWS データベース提供のコンテキストでそれらについて説明します。Aurora PostgreSQL -Compatible および Amazon RDS for PostgreSQL (リレーショナル) および Amazon DynamoDB (非リレーショナル)。このマトリックスは、リレーショナル運用データベースと非リレーショナル運用データベースのどちらを提供するかを決定しようとしているときに参照できます。
データベース | SaaS アプリケーションデータの要件と特性 | ||||
---|---|---|---|---|---|
データモデル | アクセスパターン | レイテンシー要件 | データおよびトランザクションの整合性 | リージョン間の可用性とリカバリ | |
リレーショナル (Aurora PostgreSQL - 互換および Amazon RDS for PostgreSQL ) |
リレーショナルまたは高度に正規化されている。 | 事前に徹底的に計画する必要はありません。 | はレイテンシー耐性を高めます。Aurora ではデフォルトで、リードレプリカ、キャッシュ、および同様の機能を実装することで、レイテンシーを低く抑えることができます。 | デフォルトでは、高いデータとトランザクションの整合性が維持されます。 | Amazon RDS では、クロスリージョンスケーリングとフェイルオーバー用のリードレプリカを作成できます。Aurora は主にこのプロセスを自動化します |
非リレーショナル (Amazon DynamoDB ) |
通常、非正規化されています。これらのデータベースは、関係 、大きな項目 many-to-many 、時系列データ をモデル化するためのパターンを活用します。 | データモデルを生成する前に、データのすべてのアクセスパターン (クエリ) を完全に理解する必要があります。 | Amazon DynamoDB Accelerator (DAX) などのオプションにより、レイテンシーが非常に低く、パフォーマンスをさらに向上させることができます。 | パフォーマンスを犠牲にしたオプションのトランザクション整合性。データ整合性に関する懸念はアプリケーションに移行されます。 | グローバルテーブルによるクロスリージョンリカバリとアクティブ/アクティブ設定が容易。(ACID コンプライアンスは 1 つの AWS リージョンでのみ実現可能です。) |
一部のマルチテナント SaaS アプリケーションには、前の表に含まれていないデータベースによってより適切に機能する一意のデータモデルや特殊な状況がある場合があります。例えば、時系列データセット、高度に接続されたデータセット、集中型トランザクション台帳の維持には、異なるタイプのデータベースの使用が必要になる場合があります。すべての可能性を分析することは、このガイドの範囲外です。 AWS データベース提供の包括的なリストと、さまざまなユースケースを大まかに満たす方法については、Amazon Web Services の概要ホワイトペーパーの「データベース」セクションを参照してください。
このガイドの残りの部分では、PostgreSQL をサポートする AWS リレーショナルデータベースサービス、Amazon RDS および Aurora PostgreSQL 互換に焦点を当てています。DynamoDB では、SaaS アプリケーションの最適化に異なるアプローチが必要ですが、これはこのガイドの範囲外です。DynamoDB の詳細については、 AWS ブログ記事「Partitioning Pooled Multi-Tenant SaaS Data with Amazon DynamoDB
Amazon RDS と Aurora の選択
ほとんどの場合、Amazon RDS for PostgreSQL よりも Aurora PostgreSQL -Compatible を使用することをお勧めします。次の表は、これら 2 つのオプションのどちらを選択するかを決める際に考慮すべき要素を示しています。
DBMS コンポーネント | Amazon RDS for PostgreSQL | Aurora PostgreSQL 互換 |
---|---|---|
スケーラビリティ | レプリケーションラグは分、最大 5 リードレプリカ | 1 分未満のレプリケーションラグ (通常はグローバルデータベースでは 1 秒未満)、最大 15 個のリードレプリカ |
クラッシュリカバリ | チェックポイントを 5 分間隔で (デフォルトで)、データベースのパフォーマンスが低下することがある | 高速リカバリのための並列スレッドによる非同期リカバリ |
フェイルオーバー | クラッシュ復旧時間に加えて 60~120 秒 | 通常、約 30 秒 (クラッシュリカバリを含む) |
[Storage (ストレージ)] | 最大 IOPS は 256,000 です | Aurora インスタンスのサイズと容量によってのみ制約される IOPS |
高可用性とディザスタリカバリ | スタンバイインスタンスを持つ 2 つのアベイラビリティーゾーン、リードレプリカまたはコピーされたバックアップへのクロスリージョンフェイルオーバー | デフォルトでは 3 つのアベイラビリティーゾーン、Aurora グローバルデータベースによるクロスリージョンフェイルオーバー、アクティブ/アクティブ設定 AWS リージョン の 間での書き込み転送 |
バックアップ | バックアップウィンドウ中、 はパフォーマンスに影響を与える可能性があります | 自動増分バックアップ、パフォーマンスへの影響なし |
データベースインスタンスクラス | Amazon RDS インスタンスクラスのリストを参照 | Aurora インスタンスクラスのリストを参照 |
前の表で説明したすべてのカテゴリでは、Aurora PostgreSQL -Compatible が通常、より良いオプションです。ただし、Amazon RDS for PostgreSQL は、Aurora のより堅牢な機能セットを犠牲にして、よりコスト効率の高いオプションを提供する可能性のあるインスタンスクラスの選択が多いため、小規模から中規模のワークロードでも意味がある場合があります。