# DAX のモニタリング
キャッシュヒットレートなどの主要な[メトリクス](dax-metrics-dimensions-dax.md#dax-metrics-dimensions)をモニタリングして、最適な DAX クラスターのパフォーマンスを確保し、問題を診断して、クラスターのスケールが必要なタイミングを決定します。主要なメトリクスを定期的にチェックすることで、ワークロードの要件に合わせてクラスターをスケールすることで、パフォーマンス、安定性、コスト効率を維持できます。DAX のモニタリングの詳細については、「[本番モニタリング](dax-production-monitoring.md)」を参照してください。
次のリストは、モニタリングが必要な主要なメトリクスの一部を示しています。
+ **キャッシュヒットレート** — キャッシュされたデータを DAX がどの程度効果的に処理しているかを示し、基盤となる DynamoDB テーブルにアクセスする必要性を減らします。クラスターのキャッシュミスが少ないほど、キャッシュ効率が高いことを示します。キャッシュヒットが少ない場合、キャッシュの TTL 設定を再確認する必要があるか、ワークロードがキャッシュに適していないことを示します。
Amazon CloudWatch を使用して、DAX クラスターのキャッシュヒットレートを計算します。`ItemCacheHits`、`ItemCacheMisses`、`QueryCacheHits`、および `QueryCacheMisses` の各メトリクスを比較して、この比率を取得します。次の式は、キャッシュヒットレートの計算方法を示します。この式を使用してヒット率を計算するには、キャッシュヒットをキャッシュヒットとキャッシュミスの合計で割ります。
```
Cache hit ratio = Cache hits / (Cache hits + Cache misses)
```
キャッシュヒットレートは 0～1 の数値になり、パーセンテージで表されます。パーセンテージが高いほど、全体的なキャッシュ使用率が高いことを示します。
+ **ErrorRequestCount** – ノードまたはクラスターによって報告されたユーザーエラーの原因となったリクエストの数。`ErrorRequestCount` には、ノードまたはクラスターによってスロットリングされたリクエストが含まれます。ユーザーエラーのモニタリングは、アプリケーションのスケーリング設定ミスやホットアイテム/パーティションパターンを特定するのに役立ちます。
+ **オペレーションのレイテンシー** — DAX クラスターとの間で送受信されるオペレーションのレイテンシーをモニタリングすることで、パフォーマンスのボトルネックの特定に役立ちます。レイテンシーの増加は、DAX クラスターの設定、ネットワーク、またはスケールの必要性に問題がある可能性を示します。
+ **ネットワーク消費** — `NetworkBytesIn` および `NetworkBytesOut` メトリクスに注目して、DAX クラスターのネットワークトラフィックをモニタリングします。ネットワークスループットが予期せず増加すると、クライアントリクエストが増えたり、クエリパターンが非効率になり、より多くのデータが転送される可能性があります。
ネットワーク消費量のモニタリングは、DAX クラスターのコスト管理に役立ちます。また、ネットワークがクラスターのパフォーマンスのボトルネックにならないようにします。
+ **エビクション率** — 新しい項目を格納するためにキャッシュから項目が削除される頻度を示します。時間の経過に伴うエビクション率の増加は、キャッシュが小さすぎるか、キャッシュ戦略が有効でない可能性を示します。
CloudWatch で `EvictedSize` メトリクスをモニタリングして、キャッシュサイズがワークロードに適しているかどうかを判断します。合計エビクションサイズが増加し続ける場合は、より大きなキャッシュに対応するために DAX クラスターをスケールアップする必要がある場合があります。
+ **CPU 使用率** - ノードまたはクラスターの CPU 使用率の割合を示します。これは、データベースまたはキャッシュシステムをモニタリングするための重要なメトリクスです。CPU 使用率が高いと、DAX クラスターが過負荷になり、需要の増加に対応するためにスケーリングが必要になる可能性があります。
DAX クラスターの `CPUUtilization` メトリクスのモニタリング。CPU 使用率が常に 70～80% に近づいている場合は、次のセクションで説明するように [DAX クラスターをスケールアップ](#dax-cluster-scale-monitoring-data)することを検討してください。
DAX に送信されたリクエストの数がノードのキャパシティを超える場合、DAX は 追加のリクエストの受け入れ率を制限します。これは、ThrottlingException を返すことによって行われます。DAX はクラスターの CPU 使用率を継続的に評価し、正常なクラスター状態を維持しながら処理できるリクエスト量を決定します。
DAX が CloudWatch に公開する `ThrottledRequestCount` メトリクスをモニタリングできます。これらの例外が定期的に発生する場合は、クラスターをスケールアップすることを検討してください。
## モニタリングデータを使用した DAX クラスターのスケール
パフォーマンスメトリクスをモニタリングすることで、DAX クラスターをスケールアップまたはスケールダウンする必要があるかどうかを判断できます。
+ **スケールアップまたはスケールアウト** — DAX クラスターの CPU 使用率が高い場合、(キャッシュ戦略の最適化後に) キャッシュヒットが低い場合、またはオペレーションのレイテンシーが高い場合は、クラスターをスケールアップする必要があります。ノードをさらに追加すると (スケールアウトとも呼ばれる)、負荷をより均等に分散できます。1 秒あたりの書き込み数が増加するワークロードでは、より強力なノードを選択する必要がある場合があります (スケールアップ)。
+ **スケールダウン** — CPU 使用率とオペレーションのレイテンシーが常にしきい値を下回る場合は、リソースが過剰にプロビジョニングされている可能性があります。このような場合は、ノードをスケールダウンしてコストを削減します。使用率が低い時間帯にノードの数を 1 に減らすことができますが、クラスターを完全にシャットダウンすることはできません。