View a markdown version of this page

PERF04-BP04 アクセスパターンに基づいてデータストレージを選択する - AWS Well-Architected Framework
実装のガイダンスリソース

PERF04-BP04 アクセスパターンに基づいてデータストレージを選択する

ワークロードのアクセスパターンとアプリケーションの要件を使用して、使用する最適なデータサービスとテクノロジーを決定します。

期待される成果: 特定および文書化されたデータアクセスパターンを基にデータストレージが選択されます。このデータアクセスパターンには、最も一般的な読み取り、書き込み、削除クエリ、必要に応じた計算および集計の必要性、データの複雑性、データの独立性、必要な一貫性に関するニーズなどが含まれます。

一般的なアンチパターン:

  • 運用管理を簡素化するため、データベースエンジンを 1 社だけ選択する。

  • 時間が経過してもデータアクセスパターンが変わらないと考えている。

  • 複雑なトランザクション、ロールバック、一貫性ロジックをアプリケーションに実装する。

  • データベースがトラフィックの急増に対応できるように設定されており、データベースリソースがほとんどアイドル状態のままになる。

  • トランザクションや分析の用途に共有データベースを使用する。

このベストプラクティスを確立するメリット: アクセスパターンを基にデータストレージを選択および最適化すると、開発の複雑さが軽減し、パフォーマンス改善の機会が最適化します。リードレプリカ、グローバルテーブル、データのパーティショニング、キャッシュをいつ使用するべきかを理解することで、運用上の諸経費を減らし、ワークロードのニーズに応じてスケーリングできるようになります。

このベストプラクティスを確立しない場合のリスクレベル: 中

実装のガイダンス

データアクセスパターンを特定、評価し、適切なストレージ設定を選択します。各データベースソリューションには、ストレージソリューションを設定および最適化するオプションがあります。収集したメトリクスとログを使用し、オプションを試してみることで、最適な設定を特定します。下記の表で、データベースサービスごとのストレージオプションを確認できます。

AWS Services Amazon RDS Amazon Aurora Amazon DynamoDB Amazon DocumentDB Amazon ElastiCache Amazon Neptune Amazon Timestream Amazon Keyspaces Amazon QLDB
Scaling Storage Storage can be scaled up manually or configured to scale automatically to a maximum of 64 TiB based on engine types. Provisioned storage cannot be decreased. Storage scales automatically up to maximum of 128 TiB and decreases when data is removed. Maximum storage size also depends upon specific Aurora MySQL or Aurora Postgres engine versions. Storage automatically scales. Tables are unconstrained in terms of size. Storage scales automatically up to maximum of 64 TiB. Starting Amazon DocumentDB 4.0 storage can decrease by comparable amounts for data removal through dropping a collection or index. With Amazon DocumentDB 3.6 allocated space remains same and free space is reused when data volume increases. Storage is in-memory, tied to instance type or count. Storage scales automatically can grow up to 128 TiB (or 64 TiB in few Regions). Upon data removal from, total allocated space remains same and is reused in the future. Organizes your time series data to optimize query processing and reduce storage costs. Retention period can be configured through in-memory and magnetic tiers. Scales table storage up and down automatically as your application writes, updates, and deletes data. Storage automatically scales. Tables are unconstrained in terms of size.

実装手順:

  1. トランザクション、原子性、一貫性、分離、耐久性 (ACID) コンプライアンス、整合性のある読み込みの要件を理解します。すべてのデータベースがこれらをサポートしているわけではなく、ほとんどの NoSQL データベースは結果整合性モデルを提供しています。

  2. グローバルに分散されているアプリケーションの最適なストレージソリューションを特定するために、トラフィックパターン、レイテンシー、アクセス要件を考慮します。

  3. クエリパターン、ランダムアクセスパターンおよび 1 回限りのクエリを分析します。テキストおよび自然言語の処理、時系列、グラフ向けの高度に専門化されたクエリ機能に関する条件についても考慮する必要があります。

  4. 予想されるデータとトラフィックの増加を特定して文書化します。

    1. Amazon RDS および Aurora は、文書化された制限までのストレージの自動スケーリングをサポートします。この制限を超える場合は、古いデータを Amazon S3 に移しアーカイブするか、過去のデータを集計し分析するか、シャーディングを使って水平にスケーリングすることを検討します。

    2. DynamoDB および Amazon S3 は、ほぼ無限のストレージボリュームに自動的にスケーリングします。

    3. EC2 で実行されている Amazon RDS インスタンスとデータベースは、手動でサイズ変更でき、EC2 インスタンスには追加ストレージ用に新しい EBS ボリュームを後日追加できます。 

    4. インスタンスタイプはアクティビティの変化に応じて変更できます。例えば、テスト中は小さいインスタンスから始め、サービスに本番のトラフィックが入ってくるようになったらインスタンスをスケーリングすることができます。Aurora Serverless V2 は負荷の変化に応じて自動でスケーリングします。 

  5. 通常のパフォーマンスおよびピークパフォーマンスに関する要件 (1 秒あたりのトランザクション数 TPS および 1 秒あたりのクエリ数 QPS) と一貫性に関するベースライン要件 (ACID および結果整合性)。

  6. ソリューションのデプロイに関する側面と、データベースのアクセス要件 (グローバルレプリケーション、マルチ AZ、リードレプリケーション、複数の書き込みノードなど) を文書化します。

実装計画に必要な工数レベル: 低。データ管理ソリューションのログまたはメトリクスがない場合は、データアクセスパターンを特定して文書化する前にそれを準備する必要があります。データアクセスパターンを把握できたら、データストレージの選択および設定に必要な工数レベルは低です。

リソース

関連するドキュメント:

関連動画:

関連する例: