# PERF 4 データベースソリューションはどのように選択すればよいですか? システムにとって最適なデータベースソリューションは、可用性、整合性、分断耐性、レイテンシー、耐久性、スケーラビリティ、クエリ機能などの要件に応じて異なります。多くのシステムでは、各種サブシステムに異なるデータベースソリューションを使用しているため、パフォーマンスを向上させるために活用する機能も異なります。システムに対して適切でないデータベースソリューションや機能を選択すると、パフォーマンス効率が低下する場合があります。 **Topics** + [PERF04-BP01 データの特性を理解する](perf_right_database_solution_understand_char.md) + [PERF04-BP02 使用可能なオプションを評価する](perf_right_database_solution_evaluate_options.md) + [PERF04-BP03 データベースのパフォーマンスメトリクスを収集して記録する](perf_right_database_solution_collect_metrics.md) + [PERF04-BP04 アクセスパターンに基づいてデータストレージを選択する](perf_right_database_solution_access_patterns.md) + [PERF04-BP05 アクセスパターンとメトリクスに基づいてデータストレージを最適化する](perf_right_database_solution_optimize_metrics.md) # PERF04-BP01 データの特性を理解する ワークロードのデータセットの特性、アクセスパターン、要件に最適なデータ管理ソリューションを選択します。データ管理ソリューションの選択および実装には、クエリ、スケーリング、ストレージの特性がワークロードのデータの要件をサポートしていることを確認する必要があります。さまざまなデータベースオプションがデータモデルにどのように適合するか、またユースケースに最適な構成オプションについて学びます。  AWS では、リレーショナル、key-value、ドキュメント、インメモリ、グラフ、時系列、台帳データベースなど多数のデータベースエンジンを提供しています。各データ管理ソリューションには、ユースケースとデータモデルをサポートするために使用できるオプションと設定があります。ワークロードでは、データの特性に応じて、いくつかの異なるデータベースソリューションを使用できる場合があります。特定の問題に最適なデータベースソリューションを選択することで、限定的な画一的アプローチのモノリシックなデータベースから脱却し、顧客のニーズに合わせたデータ管理に専念できます。 **期待される成果:** ワークロードのデータ特性が文書化され、サポートするデータベースソリューションの選択と設定を容易にし、考えられる代替手段についての洞察を得るのに十分な詳細が提供されます。 **一般的なアンチパターン:** + 大規模なデータセットを同様の特性を持つ小さなデータコレクションにセグメント化する方法を考慮していないため、データと成長の特性により適した、目的に特化したデータベースを使用する機会が失われている。 + データアクセスパターンを前もって特定せず、複雑でコストのかかる作業をやり直すことになる。 + 必要に応じて迅速にスケールしないデータストレージ戦略を使用することで成長を制限している。 + すべてのワークロードに対して 1 つのデータベースタイプとベンダーを選択する。 + 特定のタイプのデータベースソリューションに関する社内知識と経験があるため、1 つのデータベースソリューションに固執する。 + オンプレミス環境でうまく機能したことを理由にデータベースソリューションをキープする。 **このベストプラクティスを活用するメリット:** さまざまなワークロードに適したデータベースソリューションを決定できるように、すべての AWS データベースソリューションについての知識を身に付けておきます。ワークロードに適したデータベースソリューションを選択したら、各データベースサービスを簡単に試し、ワークロードのニーズを満たし続けているかどうかを判断できます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 + 実現可能なコスト削減が特定できない可能性がある。 + データを適切なレベルでセキュリティ保護できない可能性がある。 + データアクセスおよびストレージパフォーマンスが最適でない可能性がある。 ## 実装のガイダンス ワークロードのデータの特性とアクセスパターンを定義します。利用できるデータベースソリューションを確認し、どのソリューションがデータ要件をサポートするかを特定します。1 つのワークロードに対して、複数のデータベースを選択できます。各サービスまたはサービスのグループを審査し、個別に評価します。代替として利用可能なデータ管理ソリューションがデータの一部またはすべてに対して特定された場合は、コスト、セキュリティ、パフォーマンス、信頼性における利点を引き出す可能性のある代替の実装を試してみます。新しいデータ管理のアプローチを導入する場合は、既存のドキュメントを更新します。 | **タイプ** | **AWS のサービス** | **主な特徴** | **一般的なユースケース** | | --- | --- | --- | --- | | リレーショナル | Amazon RDS、Amazon Aurora | 参照整合性、ACID トランザクション、Schema-On-Write | ERP、CRM、市販のソフトウェア | | key-value | Amazon DynamoDB | 高スループット、低レイテンシー、ほぼ無限のスケーラビリティ | ショッピングカート (e コマース)、製品カタログ、チャットアプリケーション | | ドキュメント | Amazon DocumentDB | JSON ドキュメントを保存し任意の属性でクエリを実行する | コンテンツ管理 (CMS)、顧客プロファイル、モバイルアプリケーション | | インメモリ | Amazon ElastiCache、Amazon MemoryDB | ミリ秒のレイテンシー | キャッシュ、ゲームのリーダーボード | | グラフ | Amazon Neptune | データ間のリレーションに意味がある関係性の高いデータ | ソーシャルネットワーク、パーソナライゼーションエンジン、不正検出 | | 時系列 | Amazon Timestream | プライマリディメンションが時刻のデータ | DevOps、IoT、モニタリング | | ワイドカラム | Amazon Keyspaces | Cassandra ワークロード | 産業機器のメンテナンス、ルートの最適化 | | 台帳 | Amazon QLDB | 不変で暗号的に検証可能な変更の台帳 | 記録システム、医療、サプライチェーン、金融機関 | **実装手順** 1. データはどのように構造化されていますか (非構造化、key-value、半構造化、リレーショナルなど)。 1. データが構造化されていない場合は、 [Amazon S3](https://aws.amazon.com/products/storage/data-lake-storage/) などのオブジェクトストアか、 [Amazon DocumentDB などの NoSQL データベースを検討します。](https://aws.amazon.com/documentdb/) 1. key-value データの場合は、 [DynamoDB](https://aws.amazon.com/documentdb/)、 [ElastiCache for Redis](https://aws.amazon.com/elasticache/redis/) または [MemoryDB を検討します。](https://aws.amazon.com/memorydb/) 1. データがリレーショナル構造を持っている場合、どのレベルの参照整合性が必要ですか。 1. 外部キー制約の場合は、 [Amazon RDS](https://aws.amazon.com/rds/) および [Aurora](https://aws.amazon.com/rds/aurora/) などのリレーショナルデータベースがこのレベルの整合性を提供できます。 1. 通常、NoSQL データモデル内では、データをドキュメントまたはテーブルをまたいで結合するのではなく、単一のドキュメントまたはドキュメントのコレクションに非正規化して、単一のリクエストで取得します。  1. ACID (atomicity、consistency、isolation、durability) への準拠は必要ですか。 1. リレーショナルデータベースに関連付けられている ACID プロパティが必要な場合は、 [Amazon RDS](https://aws.amazon.com/rds/) および [Aurora などのリレーショナルデータベースを検討します。](https://aws.amazon.com/rds/aurora/) 1. どのような一貫性モデルが必要ですか。 1. アプリケーションが結果整合性を許容できる場合は、NoSQL の実装を検討します。他の特性を確認して、最適な [NoSQL データベース](https://aws.amazon.com/nosql/) を選びます。 1. 強整合性が必要な場合は、 [DynamoDB](https://aws.amazon.com/documentdb/) または [Amazon RDS](https://aws.amazon.com/rds/)などのリレーショナルデータベースで強力な整合性のある読み込みを使用できます。 1. どのような形式のクエリと結果をサポートする必要がありますか (SQL、CSV、Parque、Avro、JSON など)。 1. どのようなデータ型、フィールドサイズ、および全体の量が存在しますか (テキスト、数値、空間、時系列計算、バイナリまたはブロブ、ドキュメントなど)。 1. ストレージ要件は時間の経過とともにどのように変化しますか。 これにより、スケーラビリティにどのような影響がありますか。 1. サーバーレスデータベース ( [DynamoDB](https://aws.amazon.com/documentdb/) および [Amazon Quantum Ledger Database](https://aws.amazon.com/qldb/) など) は、ほぼ無制限のストレージまで動的にスケールアップします。 1. リレーショナルデータベースには、プロビジョニングされたストレージに上限があり、多くの場合、この上限に達すると、シャーディングなどのメカニズムを介して水平方向に分割する必要があります。 1. 書き込みクエリに対する読み取りクエリの割合はどのくらいですか。 キャッシングによってパフォーマンスが向上する可能性はありますか。 1. 読み取り負荷の高いワークロードでは、キャッシングレイヤーを使用することでメリットが得られます。これには、 [ElastiCache](https://aws.amazon.com/elasticache/) または [DAX](https://aws.amazon.com/dynamodb/dax/) (データベースが DynamoDB の場合) などがあります。 1. 読み取りは、 [Amazon RDS](https://aws.amazon.com/rds/)などのリレーショナルデータベースを使用して読み取りレプリカにオフロードすることもできます。 1. ストレージや変更 (OLTP - オンライントランザクション処理) または取得やレポート (OLAP - オンライン分析処理) のどちらが優先されますか。 1. 高スループットのトランザクション処理については、DynamoDB や Amazon DocumentDB などの NoSQL データベースを検討します。 1. 分析クエリの場合は、 [Amazon Redshift](https://aws.amazon.com/redshift/) などの列指向データベースを検討するか、データを Amazon S3 にエクスポートして [Athena](https://aws.amazon.com/athena/) または [QuickSight を使用して分析を実行することを検討します。](https://aws.amazon.com/quicksight/) 1. このデータの機密性はどの程度で、どのようなレベルの保護と暗号化が必要ですか。 1. すべての Amazon RDS および Aurora エンジンは、AWS KMS を使用した保管時のデータ暗号化をサポートしています。Microsoft SQL Server と Oracle では、Amazon RDS を使用する場合、ネイティブの Transparent Data Encryption (TDE) もサポートします。 1. DynamoDB の場合、 [IAM](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/access-control-overview.html) できめ細かなアクセス制御 (FGAC) を使用し、誰がどのデータにアクセスできるかをキーレベルで制御できます。 1. データにはどのレベルの耐久性が必要ですか。 1. Aurora は、リージョン内の 3 つのアベイラビリティーゾーンにわたってデータを自動的に複製します。これはつまり、データの耐久性が高く、データ損失の可能性が低くなることを意味します。 1. DynamoDB は、複数のアベイラビリティーゾーンに自動的に複製され、高可用性とデータ耐久性を提供します。 1. Amazon S3 は、99.9999999% (イレブンナイン) の耐久性を提供します。Amazon RDS や DynamoDB などの多くのデータベースサービスでは、長期的な保持とアーカイブの目的で、Amazon S3 へのデータのエクスポートをサポートしています。 1. すべきこと [目標復旧時間 (RTO) または目標復旧時点 (RPO)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) の要件はソリューションに影響しますか。 1. Amazon RDS、Aurora、DynamoDB、Amazon DocumentDB、Neptune はすべて、ポイントインタイムリカバリとオンデマンドのバックアップと復元をサポートしています。  1. 高可用性の要件については、DynamoDB テーブルを [グローバルテーブル](https://aws.amazon.com/dynamodb/global-tables/) 機能を使用してグローバルに複製でき、Aurora クラスターを Global Database 機能を使用して複数のリージョンでレプリケートできます。さらに、S3 バケットは、クロスリージョンレプリケーションを使用して AWS リージョン 間で複製できます。  1. 商用データベースエンジンやライセンスコストから離れたいという希望はありますか。 1. Amazon RDS または Aurora で PostgreSQL や MySQL などのオープンソースのエンジンを検討します。 1. 商用データベースエンジンからオープンソースへの移行を行うには、 [AWS DMS](https://aws.amazon.com/dms/) および [AWS SCT](https://aws.amazon.com/dms/schema-conversion-tool/) を利用します。 1. データベースには運用上どのようなことが期待されますか。 マネージドサービスへの移行は主な懸念事項ですか。 1. Amazon EC2 の代わりに Amazon RDS を利用し、NoSQL データベースをセルフホスティングする代わりに DynamoDB または Amazon DocumentDB を利用することで、運用上の諸経費を削減できます。 1. データベースへのアクセスは現在どのように行われていますか。 アプリケーションアクセスのみですか、それともビジネスインテリジェンス (BI) ユーザーやその他の接続された既製アプリケーションが存在しますか。 1. 外部ツールに依存している場合は、ツールがサポートするデータベースとの互換性を維持することが必要になる場合があります。Amazon RDS は Microsoft SQL Server、Oracle、MySQL、PostgreSQL など、サポートするさまざまなエンジンバージョンとの完全な互換性があります。 1. 以下は、利用可能なデータ管理サービスのリストと、その最適な使用場所です。 1. リレーショナルデータベースは、定義済みのスキーマとそれらの関係を使用してデータを格納します。これらのデータベースは、ACID (atomicity、consistency、isolation、durability) トランザクションをサポートし、参照整合性と強固なデータ整合性を維持するように設計されています。従来のアプリケーション、エンタープライズリソースプランニング (ERP)、顧客関係管理 (CRM)、e コマースの多くは、リレーショナルデータベースを使用してデータを保存します。これらのデータベースエンジンの多くは Amazon EC2 で実行することも、AWS のマネージド [データベースサービス](https://aws.amazon.com/products/databases/)( [Amazon Aurora](https://aws.amazon.com/rds/aurora)、 [Amazon RDS](https://aws.amazon.com/rds)、または [Amazon Redshift](https://aws.amazon.com/redshift)) から選ぶこともできます。 1. キー値データベースは、一般的に大量のデータを保存および取得するために、一般的なアクセスパターン用に最適化されています。これらのデータベースは、極端な量の同時リクエストでさえも、迅速な応答時間を実現します。高トラフィックのウェブアプリケーション、e コマースシステム、ゲーミングアプリケーションは、key-value データベースの典型的なユースケースです。AWS では、 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/)を利用することができます。これはマルチリージョンとマルチマスターに対応し、耐久性に優れたフルマネージドデータベースで、インターネットスケールのアプリケーションに対応した、組み込みのセキュリティ、バックアップと復元の機能、インメモリキャッシュを備えています 1. インメモリデータベースは、データへのリアルタイムアクセス、最小のレイテンシー、最大のスループットが必要なアプリケーションに使用されます。これらのデータベースは、データをメモリ内に直接保存することにより、ミリ秒単位のレイテンシーでは不十分なアプリケーションにマイクロ秒単位のレイテンシーを提供します。インメモリデータベースは、アプリケーションキャッシング、セッション管理、ゲームのリーダーボード、および地理空間アプリケーションに使用できます。 [Amazon ElastiCache](https://aws.amazon.com/elasticache/) は、フルマネージド型のインメモリデータストアで、 [Redis](https://aws.amazon.com/elasticache/redis/) または [Memcached](https://aws.amazon.com/elasticache/memcached)と互換性があります。アプリケーションの耐久性要件も高い場合、超高速パフォーマンス用の耐久性のあるインメモリデータベースサービスである [Amazon MemoryDB for Redis ](https://aws.amazon.com/memorydb/) がこれを組み合わせて提供します。 1. ドキュメントデータベースは、半構造化データを JSON 型のドキュメントとしとして保存するように設計されています。これらのデータベースは、開発者がコンテンツ管理、カタログ、およびユーザープロファイルなどのアプリケーションをすばやく構築し、更新するために役立ちます。 [Amazon DocumentDB](https://aws.amazon.com/documentdb/)  は、高速で、スケーラブル、かつ高可用性の完全マネージド型ドキュメントデータベースサービスで、MongoDB ワークロードに対応しています。 1. ワイドカラムデータストアは NoSQL データベースの一種です。テーブル、行、および列を使用しますが、リレーショナルデータベースとは異なり、同じテーブル内でも列の名前と形式が行ごとに異なる場合があります。ワイドカラムデータストアは通常、設備保全、フリート管理、およびルート最適化のための大規模な産業アプリケーションでの使用が見られます。 [Amazon Keyspaces (Apache Cassandra 向け)](https://aws.amazon.com/mcs/)  は、ワイドカラムにスケールできる、可用性に優れたマネージド型の Apache Cassandra 互換データベースサービスです。 1. グラフデータベースは、関連性が高いグラフデータセット間における何百万もの関係を、大規模に、かつミリ秒単位のレイテンシーでナビゲートし、クエリする必要があるアプリケーション向けのデータベースです。多くの企業が、不正行為検出、ソーシャルネットワーキング、およびレコメンデーションエンジン向けにグラフデータベースを使用しています。 [Amazon Neptune](https://aws.amazon.com/neptune/) は、高速で信頼性に優れたフルマネージド型のグラフデータベースサービスで、関連性が高いデータセットを処理するアプリケーションの構築と実行を容易にします。 1. 時系列データベースは、時間の経過と共に変化するデータを効率的に収集、合成し、それらからインサイトを導き出します。時系列データベースは、IoT アプリケーション、DevOps、および産業用テレメトリに利用できます。 [Amazon Timestream](https://aws.amazon.com/timestream/) は、IoT および運用アプリケーション向けの高速でスケーラブルなフルマネージド型の時系列データベースサービスで、1 日あたり数兆件のイベントの保存と分析を容易にします。 1. 台帳データベースは、あらゆるアプリケーションについて、トランザクションのスケーラブルでイミュータブル、かつ暗号的な検証が可能なレコードを維持する信頼された中央機関を提供します。台帳データベースは、SoR、サプライチェーン、登録、および銀行取引にも使用されています。 [Amazon Quantum Ledger Database (Amazon QLDB)](https://aws.amazon.com/qldb/) はフルマネージド型の台帳データベースで、信頼された中央機関によって所有される、透過的でイミュータブル、かつ暗号的な検証が可能なトランザクションログを提供します。Amazon QLDB は、すべてのアプリケーションのデータ変更を追跡し、経時的な変更の完全で検証可能な履歴を維持します。 **実装計画に必要な工数レベル: **ワークロードがあるデータベースソリューションから別のデータベースソリューションに移行する場合は、アプリケーションのリファクタリングに *高* 程度の工数が必要になる可能性があります。   ## リソース **関連ドキュメント:** + [AWS でのクラウドデータベース ](https://aws.amazon.com/products/databases/?ref=wellarchitected) + [AWS Database Caching ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected) + [Amazon DynamoDB Accelerator ](https://aws.amazon.com/dynamodb/dax/?ref=wellarchitected) + [Amazon Aurora を使用する際のベストプラクティス ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html?ref=wellarchitected) + [Amazon Redshift performance ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html?ref=wellarchitected) + [Amazon Athena top 10 performance tips ](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/?ref=wellarchitected) + [Amazon Redshift Spectrum ベストプラクティス ](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/?ref=wellarchitected) + [Amazon DynamoDB ベストプラクティス](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html?ref=wellarchitected) + [Choose between EC2 and Amazon RDS](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/comparison.html) + [Best Practices for Implementing Amazon ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/BestPractices.html) **関連動画:** + [AWS purpose-built databases (DAT209-L) ](https://www.youtube.com/watch?v=q81TVuV5u28) + [Amazon Aurora storage demystified: How it all works (DAT309-R) ](https://www.youtube.com/watch?v=uaQEGLKtw54) + [Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1) ](https://www.youtube.com/watch?v=6yqfmXiZTlM) **関連サンプル:** + [Optimize Data Pattern using Amazon Redshift Data Sharing](https://wellarchitectedlabs.com/sustainability/300_labs/300_optimize_data_pattern_using_redshift_data_sharing/) + [データベースの移行](https://github.com/aws-samples/aws-database-migration-samples) + [MS SQL Server - AWS Database Migration Service (DMS) Replication Demo](https://github.com/aws-samples/aws-dms-sql-server) + [Database Modernization Hands On Workshop](https://github.com/aws-samples/amazon-rds-purpose-built-workshop) + [Amazon Neptune サンプル](https://github.com/aws-samples/amazon-neptune-samples) # PERF04-BP02 使用可能なオプションを評価する データ管理ソリューションを選択する前に、利用可能なデータベースのオプションと、それぞれがどのようにパフォーマンスを最適化するかを理解します。負荷テストを使用して、ワークロードにとって重要なデータベースメトリクスを特定します。データベースのオプションを検討する際は、パラメータグループ、ストレージオプション、メモリ、コンピューティング、リードレプリカ、結果整合性、接続プーリング、キャッシュオプションなど、さまざまな側面を考慮します。メトリクスを改善するために、こうしたさまざまな設定オプションを試します。 **期待される成果:** ワークロードでは、データ型によって、1 つまたは複数のデータベースソリューションを使用できます。データベースの機能と利点が、データの特性、アクセスパターン、ワークロードの要件に最適に合致します。データベースのパフォーマンスとコストを最適化するには、データアクセスパターンを評価して適切なデータベースオプションを決定する必要があります。許容可能なクエリ時間を評価し、選択したデータベースオプションが要件を満たすことを確認します。 **一般的なアンチパターン:** + データアクセスパターンを特定しない。 + 選択したデータ管理ソリューションの設定オプションを把握していない。 + 使用できる設定オプションを確認せずに、インスタンスサイズを増やすことのみに頼っている。 + 選んだソリューションのスケーリングに関する特性をテストしない。 **このベストプラクティスを活用するメリット:** データベースオプションを確認し、試してみることで、インフラストラクチャのコストを削減し、パフォーマンスとスケーラビリティを高め、ワークロードの維持に必要な労力を軽減できる場合があります。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 + 1 つのサイズで *すべてに対応するよう* データベースを最適化する必要があると、不必要な妥協をすることになる。 + データベースソリューションがトラフィックパターンに合わせて設定されていないため、コストが高くなる。 + スケーリングの問題から運用上の問題が発生する可能性がある。 + データを適切なレベルでセキュリティ保護できない可能性がある。 ## 実装のガイダンス データベースオプションを設定できるように、ワークロードデータの特性を理解します。負荷テストを行い、主要なパフォーマンスメトリクスとボトルネックを特定します。こうした特性およびメトリクスを使用して、データベースオプションを評価し、さまざまな設定を試します。 | AWS のサービス | Amazon RDS、Amazon Aurora | Amazon DynamoDB | Amazon DocumentDB | Amazon ElastiCache | Amazon Neptune | Amazon Timestream | Amazon Keyspaces | Amazon QLDB | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | コンピューティングのスケーリング | インスタンスサイズを増やす、Aurora サーバーレスインスタンスは負荷の変化に応じて自動スケーリングする | オンデマンドキャパシティモードによる自動の読み取り/書き込みスケーリング、またはプロビジョンドキャパシティモードでプロビジョニングされた読み取り/書き込みキャパシティの自動スケーリング | インスタンスサイズを増やす | インスタンスサイズを増やす、クラスターにノードを追加する | インスタンスサイズを増やす | 自動的にスケーリングしてキャパシティを調整する | オンデマンドキャパシティモードによる自動の読み取り/書き込みスケーリング、またはプロビジョンドキャパシティモードでプロビジョニングされた読み取り/書き込みキャパシティの自動スケーリング | 自動的にスケーリングしてキャパシティを調整する | | 読み取りのスケールアウト | すべてのエンジンでリードレプリカをサポート。Aurora はリードレプリカインスタンスの自動スケーリングをサポートする | プロビジョニングされた読み取りキャパシティユニットを増やす | リードレプリカ | リードレプリカ | リードレプリカ。リードレプリカインスタンスの自動スケーリングをサポート | 自動的にスケーリングする | プロビジョニングされた読み取りキャパシティユニットを増やす | 文書化された同時実行制限まで自動的にスケールアップ | | 書き込みのスケールアウト | インスタンスサイズを増やす、アプリケーション内の書き込みをバッチ処理する、またはデータベースの前にキューを追加する複数のインスタンスにまたがるアプリケーションレベルのシャーディングで水平スケーリング | プロビジョニングされた書き込みキャパシティユニットを増やす最適なパーティションキーを確保し、パーティションレベルでの書き込みのスロットリングを防ぐ | プライマリインスタンスサイズを増やす | Redis をクラスターモードで使用して書き込みを複数のシャードに分散する | インスタンスサイズを増やす | 書き込みリクエストがスケーリング中にスロットリングされる可能性がある。スロットリング例外が発生した場合は、同じ (またはそれ以上の) スループットでデータを送信し続け、自動的にスケーリングする。書き込みをバッチ処理して同時実行される書き込みリクエストを減らす | プロビジョニングされた書き込みキャパシティユニットを増やす最適なパーティションキーを確保し、パーティションレベルでの書き込みのスロットリングを防ぐ | 文書化された同時実行制限まで自動的にスケールアップ | | エンジンの設定 | パラメータグループ | 該当しない | パラメータグループ | パラメータグループ | パラメータグループ | 該当しない | 該当しない | 該当しない | | キャッシング | インメモリキャッシュ、パラメータグループを介して設定可能。ElastiCache for Redis などの専用キャッシュと組み合わせて、よくアクセスされるアイテムに対するリクエストをオフロードする | DAX (DAX) 完全マネージド型キャッシュが利用可能 | インメモリキャッシュ。必要に応じて、ElastiCache for Redis などの専用キャッシュと組み合わせて、よくアクセスされるアイテムに対するリクエストをオフロードすることも可能。 | キャッシュが主な機能 | クエリ結果キャッシュを使用して読み取り専用クエリの結果をキャッシュする | Timestream には 2 つのストレージ層があり、そのうち 1 つはハイパフォーマンスのインメモリ層 | ElastiCache for Redis などの専用キャッシュを別にデプロイし、よくアクセスされるアイテムに対するリクエストをオフロードする | 該当しない | | 高可用性 / ディザスタリカバリ | 本番ワークロードで推奨される設定は、2 つ目のアベイラビリティーゾーンでスタンバイインスタンスを実行して、リージョン内で回復力を提供すること。  リージョン間の回復力については、Aurora Global Database を使用可能 | 1 つのリージョン内で可用性が高い。テーブルは DynamoDB グローバルテーブルを使用してリージョン間で複製できる | 複数のインスタンスをアベイラビリティゾーンをまたいで作成して可用性を向上。  スナップショットはリージョンをまたいで共有でき、クラスタは DMS を使用して複製可能。これによりクロスリージョンレプリケーションやディザスタリカバリが提供される | 本番クラスタで推奨される設定は 2 つ目のアベイラビリティゾーンに少なくとも 1 つのノードを作成すること。  リージョン間でのクラスタの複製には ElastiCache Global Datastore を使用できる。 | 他のアベイラビリティゾーンのリードレプリカはフェイルオーバーターゲットとして機能する。  スナップショットはリージョンをまたいで共有でき、クラスタは Neptune ストリームを使用して複製可能。これにより、2 つの異なるリージョンの 2 つのクラスター間でデータを複製できる。 | 1 つのリージョンで可用性が高い。クロスリージョンレプリケーションには Timestream SDK を使用したカスタムアプリケーション開発が必要。 | 1 つのリージョン内で可用性が高い。  クロスリージョンレプリケーションにはカスタムアプリケーションロジックまたはサードパーティ製ツールが必要 | 1 つのリージョン内で可用性が高い。  リージョン間で複製するには、Amazon QLDB ジャーナルのコンテンツを S3 バケットにエクスポートし、クロスリージョンレプリケーション用にバケットを設定する。 | **実装手順** 1. 選択したデータベースで使用できる設定オプションは何ですか。 1. Amazon RDS および Aurora のパラメータグループを使用すると、キャッシュに割り当てられたメモリやデータベースのタイムゾーンの調整など、一般的なデータベースエンジンレベルの設定を調整できます。 1. Amazon RDS、Aurora、Neptune、Amazon DocumentDB などのプロビジョンドデータベースサービスや、Amazon EC2 にデプロイされたデータベースサービスでは、インスタンスタイプ、プロビジョニングされたストレージを変更し、リードレプリカを追加できます。 1. DynamoDB では、オンデマンドとプロビジョンドの 2 つのキャパシティモードを指定できます。さまざまなワークロードに対応するために、随時モードを切り替えて、プロビジョニングドモードで割り当てられているキャパシティを増やすことができます。 1. ワークロードでは、読み取りまたは書き込みの負荷が高くなりますか。  1. 読み取りをオフロードするためにどのようなソリューションを使用できますか (リードレプリカ、キャッシュなど)。  1. DynamoDB テーブルの場合、キャッシュに DAX を使用して読み取りをオフロードできます。 1. リレーショナルデータベースの場合、ElastiCache for Redis クラスターを作成して、最初にキャッシュから読み取り、リクエストされたアイテムが存在しない場合にデータベースにフォールバックするようにアプリケーションを設定できます。 1. Amazon RDS および Aurora などのリレーショナルデータベース、Neptune などのプロビジョンド NoSQL データベース、Amazon DocumentDB はすべて、ワークロードの読み取り部分をオフロードするためのリードレプリカの追加をサポートします。 1. DynamoDB などのサーバーレスデータベースは自動的にスケーリングします。ワークロードを処理するのに十分な読み取りキャパシティユニット (RCU) がプロビジョニングされていることを確認します。 1. 書き込みのスケーリングにはどのようなソリューションを使用できますか (パーティションキーのシャーディング、キューの導入など)。 1. リレーショナルデータベースの場合、インスタンスのサイズを増やして増加したワークロードに対応するか、プロビジョンド IOPS を増やして、基盤となるストレージへのスループットを増やせるようにします。 + また、データベースに直接書き込むのではなく、データベースの前にキューを導入することもできます。このパターンでは、データの取り込みをデータベースから切り離し、フローレートを制御することで、データベースが過負荷になるのを回避できます。  + 存続時間の短いトランザクションを大量に作成するのではなく、書き込みリクエストをバッチ処理することで、書き込み量の多いリレーショナルデータベースのスループットを向上させることができます。 1. DynamoDB のようなサーバーレスデータベースは、キャパシティモードに応じて、自動的に、またはプロビジョニングされた書き込みキャパシティユニット (WCU) を調整することにより、書き込みスループットをスケーリングできます。  + ただし、特定のパーティションキーのスループット上限に達すると、引き続き *ホット* パーティションの問題が発生する可能性があります。これは、より均等に分散されたパーティションキーを選択するか、パーティションキーを書き込みシャーディングすることで緩和できます。  1. 現在または予想される 1 秒あたりのピークトランザクション数はどのくらいですか。 このトラフィック量とこの量 \$1X% を使用してスケーリングの特性を理解します。 1. PostgreSQL 用の pg\$1bench などのネイティブツールを使用して、データベースのストレステストを行い、ボトルネックとスケーリングの特性を理解できます。 1. 合成ワークロードに加えて、実際の条件をシミュレートするために再現できるように、実稼働環境に似たトラフィックをキャプチャする必要があります。 1. サーバーレスまたは伸縮自在にスケーリングが可能なコンピューティングを使用している場合は、これをスケーリングした場合のデータベースへの影響をテストします。必要に応じて、接続管理またはプーリングを導入し、データベースへの影響を軽減します。  1. Amazon RDS および Aurora でデータベースへの接続を管理するには、RDS Proxy を使用できます。  1. DynamoDB などのサーバーレスデータベースには関連付けられている接続はありませんが、負荷の急増に対応するためにプロビジョンドキャパシティおよび自動スケーリングのポリシーを検討します。 1. 負荷は予測可能ですか。負荷の急増やアクティビティのない期間はありますか。 1. アクティビティのない期間がある場合は、こうした期間中にプロビジョンドキャパシティまたはインスタンスサイズをスケールダウンすることを検討します。Aurora Serverless V2 は、負荷に応じて自動でスケールアップおよびスケールダウンします。 1. 非本番インスタンスの場合は、業務時間外に一時停止または停止することを検討します。 1. アクセスパターンやデータの特性に応じてデータモデルをセグメント化および分割する必要がありますか。 1. データを他のサービスに移動するには、AWS DMS または AWS SCT を使用することを検討します。 ## 実装計画に必要な工数レベル:  このベストプラクティスを確立するには、現在のデータの特性とメトリクスを把握している必要があります。こうしたメトリクスを収集し、ベースラインを確立した上で、これらのメトリクスを使用して最適なデータベースの設定オプションを特定するには、 *低* ～ *中* 程度の工数が必要です。これは、負荷テストと実験によって検証するのが最善策です。 ## リソース **関連ドキュメント:** + [AWS でのクラウドデータベース ](https://aws.amazon.com/products/databases/?ref=wellarchitected) + [AWS Database Caching ](https://aws.amazon.com/caching/database-caching/?ref=wellarchitected) + [Amazon DynamoDB Accelerator ](https://aws.amazon.com/dynamodb/dax/?ref=wellarchitected) + [Amazon Aurora を使用する際のベストプラクティス ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html?ref=wellarchitected) + [Amazon Redshift performance ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html?ref=wellarchitected) + [Amazon Athena top 10 performance tips ](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/?ref=wellarchitected) + [Amazon Redshift Spectrum ベストプラクティス ](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/?ref=wellarchitected) + [Amazon DynamoDB ベストプラクティス](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html?ref=wellarchitected) **関連動画:** + [AWS purpose-built databases (DAT209-L) ](https://www.youtube.com/watch?v=q81TVuV5u28) + [Amazon Aurora storage demystified: How it all works (DAT309-R) ](https://www.youtube.com/watch?v=uaQEGLKtw54) + [Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1) ](https://www.youtube.com/watch?v=6yqfmXiZTlM) **関連サンプル:** + [Amazon DynamoDB サンプル](https://github.com/aws-samples/aws-dynamodb-examples) + [AWS データベース移行サンプル](https://github.com/aws-samples/aws-database-migration-samples) + [Database Modernization Workshop](https://github.com/aws-samples/amazon-rds-purpose-built-workshop) + [Working with parameters on your Amazon RDS for Postgress DB](https://github.com/awsdocs/amazon-rds-user-guide/blob/main/doc_source/Appendix.PostgreSQL.CommonDBATasks.Parameters.md) # PERF04-BP03 データベースのパフォーマンスメトリクスを収集して記録する データ管理システムのパフォーマンスを把握するには、関連性のあるメトリクスを追跡することが重要です。このようなメトリクスは、データ管理リソースを最適化し、ワークロード要件が満たされていることを確かめ、ワークロードのパフォーマンスの概要を明確に把握するのに役立ちます。データベースのパフォーマンスに関連するパフォーマンスの測定値を記録するツール、ライブラリ、システムを使用します。 メトリクスには、データベースがホストされているシステムに関連するメトリクス (CPU、ストレージ、メモリ、IOPS など) と、データ自体にアクセスするためのメトリクス (1 秒あたりのトランザクション数、クエリレート、応答時間、エラーなど) があります。これらのメトリクスは、すべてのサポートスタッフまたは運用スタッフが簡単にアクセスできる必要があります。また、傾向、異常、ボトルネックを特定できる十分な過去の記録が必要です。 **期待される成果:** データベースのワークロードのパフォーマンスをモニタリングするには、一定期間にわたって複数のパフォーマンスメトリクスを記録する必要があります。これにより、異常を検出し、ビジネスメトリクスに照らしてパフォーマンスを測定して、ワークロードのニーズを確実に満たすことができます。 **一般的なアンチパターン:** + メトリクスの検索に手動ログファイルのみを使用している。 + チームが使用する内部ツールにのみメトリクスを発行しており、ワークロードの全体像を把握できていない。 + 一部のモニタリングソフトウェアで記録されるデフォルトのメトリクスのみを使用している。 + 問題が発生したときにだけメトリクスを確認している。 + システムレベルのメトリクスのみをモニタリングし、データアクセスや使用状況に関するメトリクスを把握していない。 **このベストプラクティスを活用するメリット:** パフォーマンスのベースラインを確立すると、ワークロードの通常の動作とワークロードの要件を理解するのに役立ちます。異常なパターンをより迅速に特定してデバッグできるため、データベースのパフォーマンスと信頼性が向上します。データベースのキャパシティは、パフォーマンスを犠牲にすることなくコストを最適化するように設定できます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 + 異常なパフォーマンスレベルと通常のパフォーマンスレベルを区別できなければ、問題の特定とそれに伴う意思決定が困難になる。 + 実現可能なコスト削減が特定できない可能性がある。 + 成長パターンが特定されないため、信頼性やパフォーマンスの低下につながる可能性がある。 ## 実装のガイダンス データベースグ関連のメトリクスを特定、収集、集計し、関連付けを行います。メトリクスは、データベースをサポートする基盤となるシステムとデータベース自体の両方のメトリクスが含まれている必要があります。基盤となるシステムのメトリクスには、CPU 使用率、メモリ、使用可能なディスク容量、ディスク I/O、ネットワークのインバウンドとアウトバウンドに関するメトリクスなどがあり、データベースのメトリクスには 1 秒あたりのトランザクション数、上位のクエリ、平均クエリレート、応答時間、インデックス使用率、テーブルロック、クエリのタイムアウトの数、開いている接続の数などがあります。このデータは、ワークロードのパフォーマンスやデータベースソリューションの使用状況を理解するために不可欠です。これらのメトリクスをデータ駆動型アプローチの一部として使用し、ワークロードのリソースを調整および最適化します。  **実装手順:** 1. 追跡するべき重要なデータベースメトリクスはどれですか。 1. [Amazon RDS のメトリクスのモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html) 1. [Performance Insights を使用したモニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.html) 1. [拡張モニタリング](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.overview.html) 1. [DynamoDB メトリクス](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/metrics-dimensions.html) 1. [DynamoDB DAX のモニタリング](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.Monitoring.html) 1. [MemoryDB のモニタリング](https://docs.aws.amazon.com/memorydb/latest/devguide/monitoring-cloudwatch.html) 1. [Amazon Redshift のモニタリング](https://docs.aws.amazon.com/redshift/latest/mgmt/metrics.html) 1. [時系列のメトリクスとディメンション](https://docs.aws.amazon.com/timestream/latest/developerguide/metrics-dimensions.html) 1. [Aurora のクラスターレベルのメトリクス](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.Monitoring.Metrics.html) 1. [Amazon Keyspaces のモニタリング](https://docs.aws.amazon.com/keyspaces/latest/devguide/monitoring.html) 1. [Amazon Neptune のモニタリング](https://docs.aws.amazon.com/neptune/latest/userguide/monitoring.html) 1. 運用上の異常なパフォーマンスの問題を検出する機械学習ソリューションは、データベースのモニタリングに役立ちますか。 1. [Amazon DevOps Guru for Amazon RDS](https://docs.aws.amazon.com/devops-guru/latest/userguide/working-with-rds.overview.how-it-works.html) は、パフォーマンス上の問題を可視化し、是正措置についての推奨事項を提供します。 1. SQL の使用状況についてアプリケーションレベルの詳細が必要ですか。 1. [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-api-segmentdocuments.html#api-segmentdocuments-sql) をアプリケーションに組み込むと、洞察を得て、単一のクエリのすべてのデータポイントをカプセル化できます。 1. 現在、承認済みのロギングおよび監視ソリューションがありますか。 1. [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) では、アーキテクチャ内のリソース全体のメトリクスを収集できます。また、カスタムメトリクスを収集および発行して、ビジネスメトリクスまたは導出メトリクスを表面化することも可能です。CloudWatch またはサードパーティーのソリューションを使用して、しきい値を超過したことを示すアラームを設定します。 1. セキュリティおよび運用の目標に合ったデータ保持ポリシーを特定、構成しましたか。 1. [CloudWatch メトリクスのデフォルトのデータ保持](https://aws.amazon.com/cloudwatch/faqs/#AWS_resource_.26_custom_metrics_monitoring) 1. [CloudWatch Logs のデフォルトのデータ保持](https://aws.amazon.com/cloudwatch/faqs/#Log_management) **実装計画に必要な工数レベル: **すべてのデータベースリソースからのメトリクスを特定、追跡、収集、集約し、関連付けるには、 *中* 程度の労力が必要です。 ## リソース **関連ドキュメント:** + [AWS Database Caching ](https://aws.amazon.com/caching/database-caching/) + [ Amazon Athena top 10 performance tips ](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) + [ Amazon Aurora を使用する際のベストプラクティス ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html) + [Amazon DynamoDB Accelerator ](https://aws.amazon.com/dynamodb/dax/) + [Amazon DynamoDB ベストプラクティス ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html) + [Amazon Redshift Spectrum ベストプラクティス ](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/) + [Amazon Redshift performance ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html) + [AWS でのクラウドデータベース ](https://aws.amazon.com/products/databases/) + [Amazon RDS Performance Insights](https://aws.amazon.com/rds/performance-insights/) **関連動画:** + [AWS purpose-built databases (DAT209-L) ](https://www.youtube.com/watch?v=q81TVuV5u28) + [Amazon Aurora storage demystified: How it all works (DAT309-R) ](https://www.youtube.com/watch?v=uaQEGLKtw54) + [Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1) ](https://www.youtube.com/watch?v=6yqfmXiZTlM) **関連サンプル:** + [Level 100: Monitoring with CloudWatch Dashboards](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/) + [AWS Dataset Ingestion Metrics Collection Framework](https://github.com/awslabs/aws-dataset-ingestion-metrics-collection-framework) + [Amazon RDS Monitoring Workshop](https://www.workshops.aws/?tag=Enhanced%20Monitoring) # 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 に移してアーカイブして過去のデータを集計するか、シャーディングを使って水平にスケーリングすることを検討します。 1. DynamoDB および Amazon S3 は、ほぼ無限のストレージボリュームに自動的にスケーリングします。 1. EC2 で実行されている Amazon RDS インスタンスとデータベースは、手動でサイズ変更でき、EC2 インスタンスには追加ストレージ用に新しい EBS ボリュームを後日追加できます。  1. インスタンスタイプはアクティビティの変化に応じて変更できます。例えば、テスト中は小さいインスタンスから始め、サービスに本番のトラフィックが入ってくるようになったらインスタンスをスケーリングすることができます。Aurora Serverless V2 は負荷の変化に応じて自動でスケーリングします。  1. 通常のパフォーマンスおよびピークパフォーマンスに関する要件 (1 秒あたりのトランザクション数 TPS および 1 秒あたりのクエリ数 QPS) と一貫性に関する要件 (ACID および結果整合性) を文書化します。 1. ソリューションのデプロイに関する側面と、データベースのアクセス要件 (グローバル、マルチ AZ、リードレプリケーション、複数の書き込みノード) を文書化します。 **実装計画に必要な工数レベル: **データ管理ソリューションのログまたはメトリクスがない場合は、データアクセスパターンを特定して文書化する前にそれを準備する必要があります。データアクセスパターンを把握できたら、データストレージの選択および設定には *低* 程度の工数が必要です。 ## リソース **関連ドキュメント:** + [AWS Database Caching ](https://aws.amazon.com/caching/database-caching/) + [Amazon Athena top 10 performance tips ](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) + [Amazon Aurora を使用する際のベストプラクティス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html) + [Amazon DynamoDB Accelerator ](https://aws.amazon.com/dynamodb/dax/) + [Amazon DynamoDB ベストプラクティス ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html) + [Amazon Redshift Spectrum ベストプラクティス ](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/) + [Amazon Redshift performance ](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html) + [AWS でのクラウドデータベース ](https://aws.amazon.com/products/databases/) + [Amazon RDS のストレージタイプ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) **関連動画:** + [AWS purpose-built databases (DAT209-L)](https://www.youtube.com/watch?v=q81TVuV5u28) + [Amazon Aurora storage demystified: How it all works (DAT309-R) ](https://www.youtube.com/watch?v=uaQEGLKtw54) + [ Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1) ](https://www.youtube.com/watch?v=6yqfmXiZTlM) **関連サンプル:** + [AWS での分散負荷テスト](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) # PERF04-BP05 アクセスパターンとメトリクスに基づいてデータストレージを最適化する データの保存方法とクエリ方法を最適化して可能な限り最高のパフォーマンスを達成するパフォーマンス特性とアクセスパターンを使用します。インデックス作成、キー分散、データウェアハウス設計、またはキャッシング戦略などの最適化が、システムのパフォーマンスまたは全体的な効率性にどのように影響するかを測定してください。 **一般的なアンチパターン:** + メトリクスの検索に手動ログファイルのみを使用している。 + 内部ツールにのみメトリクスを発行している。 **このベストプラクティスを確立するメリット:** ワークロードに必要なメトリクスを確実に満たすためには、読み取りと書き込みの両方に関連するデータベースパフォーマンスメトリクスをモニタリングする必要があります。このデータを使用して、データストレージレイヤーへの読み取りと書き込みの両方の新しい最適化を追加できます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス メトリクスとパターンに基づいてデータストレージを最適化する: レポートされたメトリクスを使用して、ワークロードのパフォーマンス不足の領域を特定し、データベースコンポーネントを最適化します。データのインデックス作成方法、キャッシュ方法、複数のシステム間での分散方法など、評価するパフォーマンス関連の特性は、データデータベースシステムごとに異なります。最適化の影響を測定します。 ## リソース **関連ドキュメント:** + [AWS Database Caching (AWS データベースキャッシング)](https://aws.amazon.com/caching/database-caching/) + [Amazon Athena top 10 performance tips](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) + [Amazon Aurora を使用する際のベストプラクティス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.BestPractices.html) + [Amazon DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/) + [Amazon DynamoDB ベストプラクティス](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BestPractices.html) + [Amazon Redshift Spectrum ベストプラクティス](https://aws.amazon.com/blogs/big-data/10-best-practices-for-amazon-redshift-spectrum/) + [Amazon Redshift performance](https://docs.aws.amazon.com/redshift/latest/dg/c_challenges_achieving_high_performance_queries.html) + [AWS でのクラウドデータベース](https://aws.amazon.com/products/databases/) + [DevOps Guru for RDS でパフォーマンスの異常を分析する](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/devops-guru-for-rds.html) + [DynamoDB の読み取り/書き込みキャパシティモード](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html) **関連動画:** + [AWS purpose-built databases (DAT209-L) (AWS 目的別データベース)](https://www.youtube.com/watch?v=q81TVuV5u28) + [Amazon Aurora storage demystified: How it all works (DAT309-R) (Amazon Aurora ストレージの秘密: その仕組み)](https://www.youtube.com/watch?v=uaQEGLKtw54) + [Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1)](https://www.youtube.com/watch?v=6yqfmXiZTlM) **関連サンプル:** + [Hands-on Labs for Amazon DynamoDB (Amazon DynamoDB 向けのハンズオンラボ)](https://amazon-dynamodb-labs.workshop.aws/hands-on-labs.html)