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

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

ワークロードのアクセスパターンを使用して、使用するサービスとテクノロジーを決定します。パフォーマンスやスケールなどの機能以外の要件に加えて、アクセスパターンは、データベースおよびストレージのソリューションの選択に大きく影響します。まず重要な側面は、トランザクション、ACID コンプライアンス、一貫した読み取りの必要性です。すべてのデータベースがこれらをサポートしているわけではなく、ほとんどの NoSQL データベースは結果整合性モデルを提供しています。2 番目に重要な側面は、書き込みと読み取りの時間と空間における分散です。グローバルに分散されているアプリケーションでは、最適なストレージソリューションを特定するために、トラフィックパターン、レイテンシー、アクセス要件を考慮する必要があります。選択すべき 3 つ目の重要な側面は、クエリパターンの柔軟性、ランダムアクセスパターン、1 回限りのクエリです。テキストおよび自然言語の処理、時系列、グラフ向けの高度に専門化されたクエリ機能に関する条件についても考慮する必要があります。

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

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

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

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

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

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

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

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

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

実装のガイダンス

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

AWS のサービス Amazon RDS、Amazon Aurora Amazon DynamoDB Amazon DocumentDB Amazon ElastiCache Amazon Neptune Amazon Timestream Amazon Keyspaces Amazon QLDB
スケーリングするストレージ ストレージの自動スケーリングオプションを使用して、プロビジョンされたストレージを自動的にスケーリングできる。プロビジョンド IOPS のストレージタイプを使用する場合は、プロビジョンされたストレージに関係なく IOPS をスケーリングすることもできる 自動的にスケーリングする。テーブルはサイズに関して制約がない。 ストレージの自動スケーリングオプションを使用して、プロビジョンされたストレージをスケーリングできる ストレージはインメモリで、インスタンスタイプまたはインスタンス数に関連付けられている ストレージの自動スケーリングオプションを使用して、プロビジョンされたストレージを自動的にスケーリングできる インメモリ層と磁気層の保持期間を日数で設定する。 テーブルのストレージを自動的にスケールアップまたはスケールダウンする 自動的にスケーリングする。テーブルはサイズに関して制約がない。

実装手順:

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

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

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

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

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

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

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

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

リソース

関連ドキュメント:

関連動画:

関連サンプル: