ベストプラクティス

クラスター内のすべてのシャードにデータを分散するには、均等分散型のハッシュキーを使用する (ホットキーの使用は避ける)。

スキャッターギャザークエリを回避するには、読み取り/更新/削除リクエストでシャードキーを使用する。

読み取り/更新/削除操作では、入れ子型のシャードキーの使用を避ける。

バッチ操作では、すべてのシャードが並列実行され、レイテンシーが改善されるよう ordered を false に設定する。

接続数、および、新しい接続の開閉の頻度をモニタリングする。

アプリケーションの設定のすべてのサブネットに接続を分散する。複数のサブネットにクラスターを設定しているにもかかわらず、サブネットの一部しか使用されないと、最大接続数でボトルネックが発生する可能性があります。

非シャード型コレクションで負荷を分散するには、使用率の高い非シャード型コレクションを複数のデータベースに保存するようにする。Amazon DocumentDB のエラスティッククラスターは、データベースを複数のシャードに配置します。この時、同じデータベースの非シャード型コレクションは、同じシャードに配置されます。

スケーリング操作によって、データベースエラーやネットワークエラーが短時間断続的に発生する場合があります。可能な限り、ピーク時間帯のスケーリングは避けてください。スケーリングは、メンテナンスウィンドウ中に行うようにしてください。

シャード容量をスケールアップまたはスケールダウン (シャードごとの vCPU 数の変更) してコンピューティングを増やすことは、シャード数を増減するよりも、より高速で、断続的なデータベースエラーやネットワークエラーの期間が短いため、推奨されます。

成長が見込まれる場合は、シャード容量をスケールするではなく、シャード数を増やすことをお勧めします。シャード容量を増やしてクラスターをスケールすることで、迅速なスケーリングが必要とされる状況に対応できます。

クライアント側の再試行ポリシーをモニタリングして、エクスポネンシャルバックオフとジッターを試し、スケーリング中にエラーが発生したときにデータベースが過負荷にならないようにしてください。

シャードごとのメトリクス peak-to-average の比率を追跡して、不均等なトラフィックを運転している (ホットキー/ホットスポットがある) かどうかを判断します。 peak-to-average 比率を追跡するための主要なメトリクスは次のとおりです。