PERF04-BP02 使用可能なオプションを評価する - AWS Well-Architected Framework
実装のガイダンス実装計画に必要な工数レベル: リソース

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 のパラメータグループを使用すると、キャッシュに割り当てられたメモリやデータベースのタイムゾーンの調整など、一般的なデータベースエンジンレベルの設定を調整できます。

    2. Amazon RDS、Aurora、Neptune、Amazon DocumentDB などのプロビジョンドデータベースサービスや、Amazon EC2 にデプロイされたデータベースサービスでは、インスタンスタイプ、プロビジョニングされたストレージを変更し、リードレプリカを追加できます。

    3. DynamoDB では、オンデマンドとプロビジョンドの 2 つのキャパシティモードを指定できます。さまざまなワークロードに対応するために、随時モードを切り替えて、プロビジョニングドモードで割り当てられているキャパシティを増やすことができます。

  2. ワークロードでは、読み取りまたは書き込みの負荷が高くなりますか。 

    1. 読み取りをオフロードするためにどのようなソリューションを使用できますか (リードレプリカ、キャッシュなど)。 

      1. DynamoDB テーブルの場合、キャッシュに DAX を使用して読み取りをオフロードできます。

      2. リレーショナルデータベースの場合、ElastiCache for Redis クラスターを作成して、最初にキャッシュから読み取り、リクエストされたアイテムが存在しない場合にデータベースにフォールバックするようにアプリケーションを設定できます。

      3. Amazon RDS および Aurora などのリレーショナルデータベース、Neptune などのプロビジョンド NoSQL データベース、Amazon DocumentDB はすべて、ワークロードの読み取り部分をオフロードするためのリードレプリカの追加をサポートします。

      4. DynamoDB などのサーバーレスデータベースは自動的にスケーリングします。ワークロードを処理するのに十分な読み取りキャパシティユニット (RCU) がプロビジョニングされていることを確認します。

    2. 書き込みのスケーリングにはどのようなソリューションを使用できますか (パーティションキーのシャーディング、キューの導入など)。

      1. リレーショナルデータベースの場合、インスタンスのサイズを増やして増加したワークロードに対応するか、プロビジョンド IOPS を増やして、基盤となるストレージへのスループットを増やせるようにします。

        • また、データベースに直接書き込むのではなく、データベースの前にキューを導入することもできます。このパターンでは、データの取り込みをデータベースから切り離し、フローレートを制御することで、データベースが過負荷になるのを回避できます。 

        • 存続時間の短いトランザクションを大量に作成するのではなく、書き込みリクエストをバッチ処理することで、書き込み量の多いリレーショナルデータベースのスループットを向上させることができます。

      2. DynamoDB のようなサーバーレスデータベースは、キャパシティモードに応じて、自動的に、またはプロビジョニングされた書き込みキャパシティユニット (WCU) を調整することにより、書き込みスループットをスケーリングできます。 

        • ただし、特定のパーティションキーのスループット上限に達すると、引き続き ホット パーティションの問題が発生する可能性があります。これは、より均等に分散されたパーティションキーを選択するか、パーティションキーを書き込みシャーディングすることで緩和できます。 

  3. 現在または予想される 1 秒あたりのピークトランザクション数はどのくらいですか。 このトラフィック量とこの量 +X% を使用してスケーリングの特性を理解します。

    1. PostgreSQL 用の pg_bench などのネイティブツールを使用して、データベースのストレステストを行い、ボトルネックとスケーリングの特性を理解できます。

    2. 合成ワークロードに加えて、実際の条件をシミュレートするために再現できるように、実稼働環境に似たトラフィックをキャプチャする必要があります。

  4. サーバーレスまたは伸縮自在にスケーリングが可能なコンピューティングを使用している場合は、これをスケーリングした場合のデータベースへの影響をテストします。必要に応じて、接続管理またはプーリングを導入し、データベースへの影響を軽減します。 

    1. Amazon RDS および Aurora でデータベースへの接続を管理するには、RDS Proxy を使用できます。 

    2. DynamoDB などのサーバーレスデータベースには関連付けられている接続はありませんが、負荷の急増に対応するためにプロビジョンドキャパシティおよび自動スケーリングのポリシーを検討します。

  5. 負荷は予測可能ですか。負荷の急増やアクティビティのない期間はありますか。

    1. アクティビティのない期間がある場合は、こうした期間中にプロビジョンドキャパシティまたはインスタンスサイズをスケールダウンすることを検討します。Aurora Serverless V2 は、負荷に応じて自動でスケールアップおよびスケールダウンします。

    2. 非本番インスタンスの場合は、業務時間外に一時停止または停止することを検討します。

  6. アクセスパターンやデータの特性に応じてデータモデルをセグメント化および分割する必要がありますか。

    1. データを他のサービスに移動するには、AWS DMS または AWS SCT を使用することを検討します。

実装計画に必要な工数レベル: 

このベストプラクティスを確立するには、現在のデータの特性とメトリクスを把握している必要があります。こうしたメトリクスを収集し、ベースラインを確立した上で、これらのメトリクスを使用して最適なデータベースの設定オプションを特定するには、 低 ～ 中 程度の工数が必要です。これは、負荷テストと実験によって検証するのが最善策です。

リソース

関連ドキュメント:

関連動画:

関連サンプル: