Amazon Timestream for LiveAnalytics に類似した機能をご希望の場合は Amazon Timestream for InfluxDB をご検討ください。リアルタイム分析に適した、シンプルなデータインジェストと 1 桁ミリ秒のクエリ応答時間を特徴としています。詳細については、[こちら](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# DB インスタンスの管理
このセクションでは、最適なパフォーマンス、可用性、モニタリング機能を実現するために必要な、Amazon Timestream for InfluxDB インスタンスのさまざまな管理方法について説明します。データベースインスタンスの設定を更新する方法、マルチ AZ 配置の取り扱い方法、そしてフェイルオーバーのプロセスについて解説します。また、データベースインスタンスを削除し、InfluxDB インスタンスのログ表示を設定する方法についても解説します。
**Topics**
+ [DB インスタンスの更新](timestream-for-influx-managing-modifying-db.md)
+ [DB インスタンスのメンテナンス](timestream-for-influx-managing-maintaining-db.md)
+ [DB インスタンスを削除する](timestream-for-influx-managing-deleting-db.md)
+ [DB インスタンスを再起動する](timestream-for-influx-managing-rebooting-db.md)
+ [マルチAZ DB インスタンスのデプロイ](timestream-for-influx-managing-multi-az-instance-deployments.md)
+ [Timestream InfluxDB インスタンスで InfluxDB ログを表示するための設定](timestream-for-influx-managing-view-influx-logs.md)
+ [InfluxDB 2 の Timestream のモニタリングと設定の最適化](timestream-for-influx-monitoring-configuration-optimization.md)
# DB インスタンスの更新
Timestream for InfluxDB インスタンスでは、ユーザーは次の設定パラメータを更新することができます。
+ インスタンスクラス
+ ストレージタイプ
+ 割り当てられたストレージ (増加のみ)
+ デプロイタイプ
+ パラメータグループ
+ ログ配信設定
**重要**
本番稼働用のインスタンスを変更するとき、とりわけデータベースのバージョンをアップグレードするときは、変更の影響を把握しておくため、事前にテストインスタンスですべての変更をテストしておくことが推奨されます。設定を変更するときは、事前に、データベースとアプリケーションにどのような影響があるかを確認しておきます。場合によっては DB インスタンスの再起動が必要になり、ダウンタイムが発生する可能性があります。
**の使用 AWS マネジメントコンソール**
1. にサインイン AWS マネジメントコンソール し、[Amazon Timestream for InfluxDB コンソール](https://console.aws.amazon.com/timestream/)を開きます。
1. ナビゲーションペインで、**[InfluxDB データベース]** を選択し、次に変更する DB インスタンスを選択します。
1. **[Modify]** (変更) を選択します。
1. **[DB インスタンスを変更]** ページで、必要な変更を行います。
1. [**続行**] を選択して、変更の概要を確認します。
1. [**次へ**] を選択します。
1. 変更内容を確認します。
1. **[インスタンスを変更]** を選択し、変更を適用します。
**注記**
これらの変更は Influx DB インスタンスの再起動を必要とし、場合によっては中断が発生する可能性があります。
**の使用 AWS Command Line Interface**
を使用して DB インスタンスを更新するには AWS Command Line Interface、 `update-db-instance` コマンドを呼び出します。DB インスタンス識別子と、変更するオプションの値を指定します。各オプションの詳細については、「[DB インスタンスの設定](timestream-for-influx-configuring.md#timestream-for-influx-configuring-create-db-settings)」を参照してください。
**Example 例**
以下のコードは、異なる `db-parameter-group-name` を設定することで *my-db-instance* を変更します。各*ユーザー入力プレースホルダー*を独自の情報に置き換えます。変更はすぐに適用されます。
Linux、macOS、Unix の場合:
```
aws timestream-influxdb update-db-instance \
--identifier my-db-instance \
--db-storage-type desired-storage-type \
--allocated-storage desired-allocated-storage \
--db-instance-type desired-instance-type \
--deployment-type desired-deployment-type \
--db-parameter-group-name new-param-group \
--port 8086
```
Windows の場合:
```
aws timestream-influxdb update-db-instance ^
--identifier my-db-instance ^
--db-storage-type desired-storage-type ^
--allocated-storage desired-allocated-storage ^
--db-instance-type desired-instance-type ^
--deployment-type desired-deployment-type ^
--db-parameter-group-name new-param-group
--port 8086
```
# DB インスタンスのメンテナンス
Amazon Timestream for InfluxDB は、Amazon Timestream for InfluxDB リソースに定期的にメンテナンスを実行します。メンテナンスでは、DB インスタンス内の次のリソースが頻繁に更新されます。
+ 基盤となるハードウェア
+ 基盤となるオペレーティングシステム (OS)
+ データベースエンジンのバージョン
通常、オペレーティングシステムのアップデートはセキュリティ問題に関連しています。
いくつかのメンテナンス項目では、Amazon Timestream for InfluxDB により DB インスタンスが短時間オフラインになります。リソースをオフラインにする必要があるメンテナンス項目には、必要なオペレーティングシステムやデータベースのパッチが含まれます。セキュリティやインスタンスの信頼性に関連するパッチのみ、必須のパッチ適用として自動的にスケジューリングされます。そのようなパッチ適用はまれであり、通常は数か月に一度です。メンテナンスウィンドウのごくわずかしか必要としないことがほとんどです。
+ メンテナンスウィンドウは、インスタンスがホストされているリージョンの、現地時刻午前 12 時～午前 4 時の間に毎日実行されるように設定されています。
+ カスタマーリソースには、週の 7 つのメンテナンスウィンドウのいずれかで、毎週パッチが適用される場合があります。
# DB インスタンスを削除する
DB インスタンスを削除すると、インスタンスの復旧可能性とスナップショットの可用性に影響します。以下の問題について考えます。
+ Timestream for InfluxDB のすべてのリソースを削除する場合は、DB インスタンスのリソースに料金が発生することに注意が必要です。
+ DB インスタンスのステータスが「削除中」である場合、その CA 証明書の値は、Timestream for InfluxDB コンソールにも、 AWS Command Line Interface コマンドまたは Timestream API オペレーションの出力にも表示されません。
+ DB インスタンスの削除に必要な時間は、削除するデータの量、および最終スナップショットを作成するか否かに応じて変わってきます。
DB インスタンスは、 AWS マネジメントコンソール、、 AWS Command Line Interfaceまたは Timestream API を使用して削除できます。DB インスタンスの名前を入力する必要があります。
**の使用 AWS マネジメントコンソール**
1. にサインイン AWS マネジメントコンソール し、[Amazon Timestream for InfluxDB コンソール](https://console.aws.amazon.com/timestream/)を開きます。
1. ナビゲーションペインで、**[InfluxDB データベース]** を選択し、削除する DB インスタンスを選択します。
1. **[削除]** を選択します。
1. ボックスに*確認*と入力します。
1. **[削除]** を選択します。
**の使用 AWS Command Line Interface**
アカウント内の DB インスタンスのインスタンス ID を確認するには、`list-db-instances` コマンドを呼び出します。
```
aws timestream-influxdb list-db-instances \
--endpoint-url YOUR_ENDPOINT \
--region YOUR_REGION
```
CLI を使用して DB AWS インスタンスを削除するには、次のオプションを指定して `delete-db-instance` コマンドを呼び出します。
```
aws timestream-influxdb list-db-instances \
--identifier YOUR_DB_INSTANCE \
```
**Example 例**
Linux、macOS、Unix の場合:
```
aws timestream-influxdb delete-db-instance \
--identifier mydbinstance
```
Windows の場合:
```
aws timestream-influxdb delete-db-instance ^
--identifier mydbinstance
```
# DB インスタンスを再起動する
DB インスタンスは、 AWS マネジメントコンソール、、 AWS Command Line Interfaceまたは Timestream API を使用して再起動できます。DB インスタンスの ID を指定する必要があります。
**の使用 AWS マネジメントコンソール**
1. にサインイン AWS マネジメントコンソール し、[Amazon Timestream for InfluxDB コンソール](https://console.aws.amazon.com/timestream/)を開きます。
1. ナビゲーションペインで、**InfluxDB データベース**を選択し、再起動する DB インスタンスを選択します。
1. **データベースを再起動**を選択します。
1. **確認と再起動**を選択します。
**の使用 AWS Command Line Interface**
CLI を使用して DB AWS インスタンスを再起動するには、次のオプションを指定して `reboot-db-instance` コマンドを呼び出します。
**Example コマンド**
Linux、macOS、Unix の場合:
```
aws timestream-influxdb reboot-db-instance \
--region YOUR_REGION \
--identifier YOUR_INSTANCE_ID
```
Windows の場合:
```
aws timestream-influxdb reboot-db-instance ^
--region YOUR_REGION ^
--identifier YOUR_INSTANCE_ID
```
# マルチAZ DB インスタンスのデプロイ
Amazon Timestream for InfluxDB は、単一のスタンバイ DB インスタンスでマルチ AZ デプロイを使用して DB インスタンスの高可用性およびフェイルオーバーサポートを提供します。このタイプのデプロイは、マルチ AZ DB インスタンスのデプロイと呼ばれます。Amazon Timestream for InfluxDB は、Amazon のフェイルオーバー技術を使用しています。
マルチ AZ DB インスタンスのデプロイでは、Amazon Timestream は、異なるアベイラビリティーゾーンで同期スタンバイレプリカを自動的にプロビジョニングおよび維持します。プライマリ DB インスタンスは、同期的にアベイラビリティーゾーン間でスタンバイレプリカにレプリケートされ、データの冗長性が提供されます。高可用性を備えた DB インスタンスを実行すると、DB インスタンスの障害とアベイラビリティーゾーンの中断中に可用性を向上させることができます。の詳細については、「」を参照してください[AWS リージョン およびアベイラビリティーゾーン](timestream-for-influxdb.md#timestream-for-influx-dbi-regions)。
**注記**
高可用性のオプションは、読み取り専用シナリオ向けのスケーリングソリューションではありません。スタンバイレプリカを使用してリードトラフィックを処理することはできません。
Amazon Timestream コンソールを使用すれば、DB インスタンスの作成時に **[可用性と耐久性の設定]** セクションで **[スタンバイインスタンスを作成]** を指定するだけで、マルチ AZ DB インスタンスのデプロイを作成できます。 AWS Command Line Interface または Amazon Timestream API を使用して、マルチ AZ DB インスタンスのデプロイを指定することもできます。`create-db-instance` もしくは CLI コマンド、または `CreateDBInstance` API オペレーションを使用します。
マルチAZ DB デプロイを使用する DBインスタンスは、シングル AZ のデプロイと比較して書き込みとコミットの待ち時間が長くなる可能性があります。これは、同期データレプリケーションが発生しているために起こる可能性があります。デプロイがスタンバイレプリカにフェイルオーバーすると、レイテンシーが変わる可能性がありますが、 AWS は 間の低レイテンシーのネットワーク接続で設計されています。本番ワークロードでは、高速で一貫したパフォーマンスを実現するために、IOPS 込みストレージ 12K または 16K IOPS を使用することが推奨されます。DB インスタンスクラスの詳細については、「[DB インスタンスクラス](timestream-for-influxdb.md#timestream-for-influx-dbi-classes)」を参照してください。
# マルチ AZ 配置の設定と管理
Timestream for InfluxDB のマルチ AZ 配置が持つことのできるスタンバイは 1 つだけです。デプロイにスタンバイ DB インスタンスが 1 つある場合は、マルチ AZ DB インスタンスのデプロイと呼ばれます。マルチ AZ DB インスタンスのデプロイには、フェイルオーバーサポートを提供するスタンバイ DB インスタンスが 1 つありますが、読み取りトラフィックは処理されません。
**重要**
シングル AZ からマルチ AZ に更新するには、インスタンスに 2 つ以上のサブネットが関連付けられている必要があります。インスタンスの作成後は、そのデプロイモードをシングル AZ からマルチ AZ に変更することはできません。
を使用して AWS マネジメントコンソール 、DB インスタンスがシングル AZ デプロイかマルチ AZ デプロイかを決定できます。
**の使用 AWS マネジメントコンソール**
1. にサインイン AWS マネジメントコンソール し、[Amazon Timestream for InfluxDB コンソール](https://console.aws.amazon.com/timestream/)を開きます。
1. ナビゲーションペインで **[InfluxDB データベース]** を選択し、**[DB 識別子]** を選択します。
マルチ AZ DB インスタンス配置には、次の特性があります。
+ DB インスタンスの行は 1 行のみ。
+ [Role] (ロール) の値は [Instance] (インスタンス) または [Primary] (プライマリ)。
+ [Multi-AZ] (マルチ AZ) の値は [Yes] (はい)。
# Amazon Timestream のフェイルオーバープロセス
DB インスタンスの計画的または計画外の停止がインフラストラクチャの欠陥に起因する場合、マルチ AZ を有効にしていると、Amazon Timestream for InfluxDB は別のアベイラビリティーゾーンのスタンバイレプリカに自動的に切り替わります。フェイルオーバーが完了するまでにかかる時間は、プライマリ DB インスタンスが使用できなくなったときのデータベースアクティビティおよびその他の条件によって異なります。フェイルオーバー時間は通常 60～120 秒です。ただし、大規模なトランザクションや長期にわたる復旧プロセスによって、フェイルオーバー時間が増加する場合があります。フェイルオーバーが完了してから、新しいアベイラビリティーゾーンが Timestream コンソールに反映されるまでさらに時間がかかる場合があります。
**注記**
Amazon Timestream はフェイルオーバーを自動的に処理するため、管理者が操作しなくても可能な限りすみやかにデータベース操作を再開できます。次の表に記載されている条件のいずれかが発生した場合、プライマリ DB インスタンスがスタンバイレプリカに自動的に切り替わります。
****
| フェイルオーバーした理由 | 説明 |
| --- | --- |
| Timestream データベースインスタンスの基盤となるオペレーティングシステムには、オフライン操作でパッチが適用されています。 | OS パッチまたはセキュリティ更新プログラムのメンテナンス期間中に、フェイルオーバーがトリガーされました。 |
| Timestream マルチ AZ インスタンスのプライマリホストが異常です。 | マルチ AZ DB インスタンスのデプロイは、障害のあるプライマリ DB インスタンスを検出し、フェイルオーバーしました。 |
| Timestream マルチ AZ インスタンスのプライマリホストで、ネットワーク接続が切断されたため、到達できません。 | Timestream モニタリングは、プライマリ DB インスタンスへのネットワーク到達可能性による障害を検出し、フェイルオーバーをトリガーしました。 |
| Timestream インスタンスはお客様によって変更されました。 | Timesteam for InfluxDB の DB インスタンスの変更により、フェイルオーバーがトリガーされました。詳細については、「[DB インスタンスの更新](timestream-for-influx-managing-modifying-db.md)」を参照してください。 |
| Timestream マルチ AZ プライマリインスタンスはビジーで応答しません。 | プライマリ DB インスタンスが応答しません。以下の実施をお勧めします。\$1 イベントログを調べて、CPU、メモリ、またはスワップ領域の使用量が多すぎるかどうかを調べます。\$1 ワークロードを評価して、適切な DB インスタンスクラスを使用しているかどうかを判断します。詳細については、「」を参照してください。 |
| Timestream マルチ AZ インスタンスのプライマリホストの基盤となるストレージボリュームでエラーが発生しました。 | マルチ AZ DB インスタンスのデプロイは、プライマリ DB インスタンスでストレージの問題を検出し、フェイルオーバーしました。 |
# DNS 名参照用の JVM TTL の設定
フェイルオーバーメカニズムでは、スタンバイ DB インスタンスをポイントするように DB インスタンスのドメインネームシステム (DNS) レコードが自動的に変更されます。したがって、DB インスタンスへの既存の接続の再確立が必要になります。Java 仮想マシン (JVM) 環境では、Java DNS キャッシュ機構がどのように機能するかによって、JVM 設定の再構成が必要になる場合があります。
JVM は DNS 名参照をキャッシュします。JVM がホスト名を IP アドレスに変換するとき、*time-to-live* (TTL) と呼ばれる指定期間 IP アドレスをキャッシュします。
AWS リソースは DNS 名エントリを使用するため、TTL 値を 60 秒以下に設定することをお勧めします。こうすることにより、リソースの IP アドレスが変更されたときに、アプリケーションは DNS に対して再度クエリを実行することで、リソースの新しい IP アドレスを取得して使用できます。
一部の Java 設定では JVM のデフォルトの TTL が設定されるため、JVM が再起動されるまで、DNS エントリが更新されることはありません。したがって、アプリケーションの実行中に AWS リソースの IP アドレスが変更された場合、JVM を手動で再起動し、キャッシュされた IP 情報が更新されるまで、そのリソースを使用することはできません。この場合、キャッシュされた IP 情報が定期的に更新されるように JVM の TTL を設定することがきわめて重要です。
JVM のデフォルト TTL は、`networkaddress.cache.ttl` プロパティ値を取得することで取得できます。
```
String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
```
**注記**
デフォルト TTL は、JVM のバージョンと、セキュリティマネージャーがインストールされているかどうかに応じて変わります。多くの JVM はデフォルト TTL を 60 秒以下にしています。このような JVM を使用しており、セキュリティマネージャーを使用していない場合、このトピックの残り部分は無視してかまいません。
JVM の TTL を変更するには、networkaddress.cache.ttl プロパティの値を設定します。ニーズに応じて、次の方法のいずれかを使用します。
JVM を使用するすべてのアプリケーションのプロパティ値をグローバルに設定するには、`networkaddress.cache.ttl` ファイルで `$JAVA_HOME/jre/lib/security/java.security` を設定します。
```
networkaddress.cache.ttl=60
```
アプリケーションに対してのみプロパティをローカルに設定するには、ネットワーク接続を確立する前に、アプリケーションの初期化コードで `networkaddress.cache.ttl` を設定します。
```
java.security.Security.setProperty("networkaddress.cache.ttl" , "60");
```
# Timestream InfluxDB インスタンスで InfluxDB ログを表示するための設定
デフォルトでは、InfluxDB は stdout に移動するログを生成します。詳細については、「[Manage InfluxDB logs](https://docs.influxdata.com/influxdb/v2/admin/logs)」を参照してください。
Timestream InfluxDB を介して作成したインスタンスから生成される InfluxDB ログを表示するために、ログを 1 時間単位で提供する機能をご用意しました。これらのログは、インスタンスの作成前にユーザーが作成する、指定された S3 バケットに送信されます。
+ インスタンスの作成前に、Timestream InfluxDB のサービスプリンシパルを使用してバケットポリシーを次のように提供することにより、指定された Amazon S3 バケットは Timestream-InfluxDB に、ログをこのバケットに送信するためのアクセス許可も付与します (*\$1BUCKET\$1NAME\$1* は、使用している Amazon S3 バケットの実際の名前に置き換えます)。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "PolicyForInfluxLogs",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "timestream-influxdb.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::{BUCKET_NAME}/InfluxLogs/*"
}
]
}
```
------
+ 指定されたバケットは、ユーザーが作成した Timestream InfluxDB インスタンスと同じアカウントおよび同じリージョンに置かれている必要があります。
こちらは、インスタンスが influx ログを受け取れるようにするためにユーザーが実行するコマンドです。
```
aws timestream-influxdb create-db-instance \
--name myinfluxDbinstance \
--allocated-storage 400 \
--db-instance-type db.influx.4xlarge \
--vpc-subnet-ids subnetid1 subnetid2
--vpc-security-group-ids mysecuritygroup \
--username masterawsuser \
--password \
--db-storage-type InfluxIOIncludedT2
```
このパラメータの形式は次のとおりです。
```
-- log-delivery-configuration
{
"S3Configuration": {
"BucketName": "string",
"Enabled": true|false
}
}
```
+ このフィールドは必須ではなく、ログ記録はデフォルトでは有効にされていません。
+ このフィールドを設定しないことはログを有効にしないことと同じです。
+ ログは、プレフィックスが `InfluxLogs/` である指定されたバケットに送信されます。
+ インスタンスを作成したら、`update-db-instance` API コマンドを使用してログ配信設定を変更できます。
InfluxDB にはさまざまなタイプのログが用意されています。これらは、InfluxDB パラメータを設定することで設定できます。flux-log-enabled パラメータと log-level パラメータを使用して、インスタンスから出力されるログのタイプを設定します。詳細については、「[サポートされるパラメータとパラメータ値](timestream-for-influx-db-connecting.md#timestream-for-influx-parameter-groups-overview-supported-parameters)」を参照してください。
# InfluxDB 2 の Timestream のモニタリングと設定の最適化
## 概要:
Timestream for InfluxDB デプロイで最適なパフォーマンス、信頼性、コスト効率を維持するには、効果的なモニタリングと設定の最適化が不可欠です。このガイドでは、InfluxDB インスタンスをプロアクティブに管理するための CloudWatch メトリクス、パフォーマンスしきい値、および設定調整戦略に関する包括的なガイダンスを提供します。
## CloudWatch メトリクスリファレンス
Amazon CloudWatch は、Timestream for InfluxDB インスタンスをモニタリングするための詳細なメトリクスを提供します。これらのメトリクスとそのしきい値を理解することは、システムのヘルスとパフォーマンスを維持する上で不可欠です。
### リソース使用率メトリクス
| CloudWatch メトリクス名 | ディメンション | 説明 | Unit | 推奨しきい値 |
| --- | --- | --- | --- | --- |
| CPUUtilization | DbInstanceName | 使用中の CPU の割合 | 割合 (%) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| MemoryUtilization | DbInstanceName | 使用されているメモリの割合 | 割合 (%) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| HeapMemoryUsage | DbInstanceName | 使用中のヒープメモリの量 | バイト | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| ActiveMemoryAllocation | DbInstanceName | 現在のアクティブなメモリ割り当て | バイト | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| DiskUtilization | DbInstanceName | 使用されているディスク容量の割合 | 割合 (%) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### I/O オペレーションメトリクス
| CloudWatch メトリクス名 | ディメンション | 説明 | Unit | 推奨しきい値 |
| --- | --- | --- | --- | --- |
| ReadOpsPerSec | DbInstanceName | 1 秒あたりの読み取りオペレーションの数 | Count/Second | プロビジョニングされた IOPS より ≥ 30% ヘッドルームを維持する例: 12K IOPS → 合計 < 8,400 IOPS を維持する |
| WriteOpsPerSec | DbInstanceName | 1 秒あたりの書き込みオペレーションの数 | Count/Second | プロビジョニングされた IOPS より ≥ 30% ヘッドルームを維持する例: 12K IOPS → 合計 < 8,400 IOPS を維持する |
| TotalIOpsPerSec | DbInstanceName | 1 秒あたりの合計 I/O オペレーション (読み取り \$1 書き込み) | Count/Second | プロビジョニングされた IOPS より ≥ 30% ヘッドルームを維持するインスタンスクラスの機能に対するモニタリング |
### スループットメトリクス
| CloudWatch メトリクス名 | ディメンション | 説明 | Unit | 推奨しきい値 |
| --- | --- | --- | --- | --- |
| ReadThroughput | DbInstanceName | データ読み取りスループット | Bytes/Second | ストレージスループット制限に対するモニタリング |
| WriteThroughput | DbInstanceName | データ書き込みスループット | Bytes/Second | ストレージスループット制限に対するモニタリング |
### API パフォーマンスメトリクス
| CloudWatch メトリクス名 | ディメンション | 説明 | Unit | 推奨しきい値 |
| --- | --- | --- | --- | --- |
| APIRequestRate | DbInstanceName、Endpoint、Status | ステータスコード (2xx、4xx、5xx) を持つ特定のエンドポイントへの API リクエストのレート | Count/Second | エラー率: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| QueryResponseVolume | DbInstanceName、Endpoint、Status | エンドポイントとステータスコード別のクエリレスポンスの量 | バイト | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### クエリ実行メトリクス
| CloudWatch メトリクス名 | ディメンション | 説明 | Unit | 推奨しきい値 |
| --- | --- | --- | --- | --- |
| QueryRequestsTotal | DbInstanceName、結果 | 結果タイプ別のクエリリクエストの合計数 (成功、runtime\$1error、 compile\$1error、queue\$1error) | カウント | 成功率: > 99% エラー率: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### データ組織のメトリクス
| CloudWatch メトリクス名 | ディメンション | 説明 | Unit | 重要なしきい値 |
| --- | --- | --- | --- | --- |
| SeriesCardinality | DbInstanceName、バケット | バケット内の一意の時系列の数 | カウント | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
| TotalBuckets | DbInstanceName | インスタンス内のバケットの合計数 | カウント | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/timestream/latest/developerguide/timestream-for-influx-monitoring-configuration-optimization.html) |
### システムヘルスメトリクス
| CloudWatch メトリクス名 | ディメンション | 説明 | Unit | 推奨しきい値 |
| --- | --- | --- | --- | --- |
| EngineUptime | DbInstanceName | InfluxDB エンジンが実行された時刻 | 秒 | 予期しない再起動をモニタリングするアラート: 稼働時間が予期せずリセットされる |
| WriteTimeouts | DbInstanceName | タイムアウトした書き込みオペレーションの数 | カウント | アラート: 書き込みオペレーションの > 0.1%重大: 増加傾向 |
### タスク管理メトリクス
| CloudWatch メトリクス名 | ディメンション | 説明 | Unit | 推奨しきい値 |
| --- | --- | --- | --- | --- |
| ActiveTaskWorkers | DbInstanceName | アクティブなタスクワーカーの数 | カウント | 設定されたタスクワーカーの制限に対してモニタリングするアラート: 一貫して最大 |
| TaskExecutionFailures | DbInstanceName | 失敗したタスク実行の数 | カウント | アラート: タスク実行の > 1%重大: 障害率の増加 |
### 主要なメトリクス関係について
#### IOPS とスループットの関係
**30% ヘッドルームルール:** 1 秒あたりの持続的なオペレーションとプロビジョニングされた IOPS の間で、少なくとも **30% のヘッドルーム**を常に維持します。これにより、以下のバッファが提供されます。
+ 圧縮オペレーション (IOPS を大幅にスパイクできる)
+ スムーズに実行するためのデータベースの再起動
+ ピーク時のクエリバースト
+ バッチ取り込みからの書き込みスパイク
+ インデックスメンテナンスオペレーション
**計算例:**
+ プロビジョンド IOPS: 12,000
+ ターゲット最大持続 IOPS (TotalIOpsPerSec): 8,400 (使用率 70%)
+ リザーブドヘッドルーム: 3,600 IOPS (30%)
TotalIOpsPerSec が一貫して 8,400 を超える場合: → ストレージ階層をアップグレードするか、ワークロードを最適化する
**モニタリング式:**
IOPS 使用率 % = (ReadOpsPerSec \$1 WriteOpsPerSec) / プロビジョンド IOPS × 100
+ ターゲット: IOPS 使用率 < 70% を維持する
+ 警告: IOPS 使用率 > 70%
+ 重大: IOPS 使用率 > 90%
### シリーズカーディナリティのパフォーマンスへの影響について
シリーズ基数には、システムリソースに対する乗算効果があります。
| **シリーズ数** | **メモリへの影響** | **クエリパフォーマンスへの影響** | **インデックスサイズの影響** | **レコメンデーション** |
| --- | --- | --- | --- | --- |
| < 100K | Minimal | ごくわずか | Small | 標準設定 |
| 100K000～1M | 中 | 10～20% 遅い | 中 | キャッシュ設定を調整する |
| 1M 万～5M | 重大 | 30～50% 遅い | 大 | 積極的な最適化が必要 |
| 5M 万～10M | 高 | 50～70% 遅い | 非常に大きい | 最大チューニング、再設計を検討 |
| > 10M | Severe | 70% 以上遅い | 過剰 | InfluxDB 3.0 への移行 |
**10Mが重要なしきい値である理由:**
+ InfluxDB 2.x アーキテクチャがインメモリインデックス作成を使用する
+ 10Mシリーズを超えると、インデックス操作は過度に高価になります
+ メモリ要件が非線形に増加
+ クエリ計画のオーバーヘッドが大幅に増加
+ InfluxDB 3.0 は、高基数用に設計された列指向ストレージエンジンを使用します。
## インスタンスのサイズ設定とパフォーマンスのガイドライン
次の表は、系列のカーディナリティとワークロードの特性に基づいて、適切なインスタンスのサイズ設定に関するガイダンスを示しています。
| **最大シリーズ数** | **書き込み (行/秒)** | **読み取り (クエリ/秒)** | **推奨インスタンス** | **ストレージタイプ** | **ユースケース** |
| --- | --- | --- | --- | --- | --- |
| < 100K | 約 50,000 | < 10 | db.influx.large | Influx IO 込み 3K | 小規模なデプロイ、開発、テスト |
| < 1M | 約 150,000 | < 25 | db.influx.2xlarge | Influx IO 込み 3K | 中小規模の本稼働ワークロード |
| \$1100 万 | 約 200,000 | 約 25 | db.influx.4xlarge | Influx IO 込み 3K | 中規模の本稼働ワークロード |
| < 5M | 約 250,000 | 約 35 | db.influx.4xlarge | Influx IO 込み 12K | 大規模な本稼働ワークロード |
| < 10M | 約 500,000 | 約 50 | db.influx.8xlarge | Influx IO 込み 12K | 非常に大規模な本稼働ワークロード |
| ～1,000 万 | < 750,000 | < 100 | db.influx.12xlarge | Influx IO 込み 12K | InfluxDB 2.x の最大容量 |
| > 10M | 該当なし | 該当なし | InfluxDB 3.0 への移行 | 該当なし | InfluxDB 2.x の最適範囲を超える |
## メトリクスによる設定の最適化
### CPU 使用率が高い (CPUUtilization > 70%)
**症状:**
+ **CPUUtilization** > 70% 持続
+ **QueryRequestsTotal** (大量のクエリまたはスロークエリ)
+ **ActiveTaskWorkers** (タスク負荷が高い)
**設定の調整:**
**優先度 1: クエリの同時実行を制御する**
+ query-concurrency: vCPU 数の 50～75% に設定する
+ 例: 8 vCPU インスタンス → query-concurrency = 4-6
**優先度 2: クエリの複雑さを制限する**
+ influxql-max-select-series: 10000 (無制限クエリの防止)
+ influxql-max-select-point: 100000000
+ query-queue-size: 2048 (キューの蓄積を防止)
**優先度 3: クエリ分析を有効にする**
+ flux-log-enabled: TRUE (一時的にデバッグ用)
+ ログレベル: info (または詳細分析用のデバッグ)
**重要な考慮事項:**
減らす`query-concurrency`と、同時に実行できるクエリの数が制限されるため、キューに入れられたクエリが増加し、ピーク時のクエリレイテンシーが高くなる可能性があります。クエリの需要が同時実行数の制限を超えた場合、ダッシュボードのロードが遅くなったり、タイムアウトが報告されたりすることがあります。
保護制限 (`influxql-max-select-series`、`influxql-max-select-point`) を設定すると、これらのしきい値を超えるクエリは、**QueryRequestsTotal** の **compile\$1error** または **runtime\$1error** で失敗します。これにより、システムはリソースの枯渇から保護されますが、以前に機能していた既存のクエリが破損する可能性があります。
**ベストプラクティス:** これらの変更を適用する前に、**QueryResponseVolume** および **QueryRequestsTotal** メトリクスを使用してクエリパターンを分析します。最も高価なクエリを最初に特定して最適化する - 時間範囲フィルター、高カーディナリティシリーズにまたがるクエリ、過剰なデータポイントを要求するクエリがないクエリを探します。機能を損なう可能性のあるハード制限を適用するよりも、常にアプリケーションレベルでクエリを最適化することをお勧めします。
**ハードウェアアクション:**
+ より多くの vCPUs
+ 最適化の機会のクエリパターンを確認する
### メモリ使用率が高い (MemoryUtilization > 70%)
**症状:**
+ **MemoryUtilization** > 70% 持続
+ **HeapMemoryUsage** が上昇傾向
+ スパイクを示す **ActiveMemoryAllocation**
+ **SeriesCardinality** (カーディナリティが高いとメモリ使用量が増加する)
**設定の調整:**
**優先度 1: キャッシュメモリを減らす**
+ storage-cache-max-memory-size: 合計 RAM の 10～15% に設定
+ 例: 32GB RAM → 3,355,443,200～5,033,164,800 バイト
+ storage-cache-snapshot-memory-size: 26,214,400 (25 MB)
**優先度 2: クエリメモリの制限**
+ query-memory-bytes: 合計 RAM の 60～70% に設定
+ query-max-memory-bytes: query-memory-bytes と同じ
+ query-initial-memory-bytes: query-memory-bytes の 10%
**優先度 3: シリーズキャッシュを最適化する**
+ storage-series-id-set-cache-size: カーディナリティが高い場合は減らす
+ ハイメモリ: 100～200
+ 正常: 500-1000
**重要な考慮事項:**
これらの変更によりメモリ負荷は軽減されますが、アプリケーションのパフォーマンスに直接悪影響を及ぼします。削減`storage-cache-max-memory-size`すると、メモリにキャッシュされるデータが少なくなり、ディスクの読み取りが多くなり、クエリのレイテンシーが増加します。**ReadOpsPerSec** が増加し、**QueryResponseVolume** の応答時間が遅くなる可能性があります。
制限すると、メモリを大量に消費するクエリ`query-memory-bytes`は、**QueryRequestsTotal** の **runtime\$1error** で失敗します。特に、大きなデータセットを集約したり、大量の結果セットを返したりするクエリです。ユーザーは、以前に成功したクエリに対して「メモリ不足」エラーが発生する可能性があります。
削減すると、システムがキャッシュから取得するのではなく、より頻繁に系列結果を再計算する必要があるため、高カーディナリティデータに対するクエリのパフォーマンス`storage-series-id-set-cache-size`が低下します。これは特に、同じ系列の組み合わせを繰り返しクエリするダッシュボードに影響します。
**ベストプラクティス:** これらの制限的な変更を適用する前に、クエリパターンを分析し、最初に最適化します。
+ **QueryResponseVolume** を確認して、過剰なデータを返すクエリを特定する
+ **QueryRequestsTotal** を使用して、最適化の恩恵を受ける可能性のある頻繁に実行されるクエリを検索する
+ 時間範囲フィルターを追加して、ワークロードに必要なデータスキャンを減らす
+ アプリケーションレベルでクエリ結果キャッシュを実装する
+ ダウンサンプリングタスクを使用してデータを事前集約することを検討する
+ **SeriesCardinality** を確認し、データモデルを最適化して不要なタグを減らす
クエリの最適化は常に最初のアプローチである必要があります。最適化が不十分な場合は、設定制限を最後の手段にする必要があります。
**ハードウェアアクション:**
+ インスタンスサイズを増やして RAM を増やす
### ストレージ使用率が高い (DiskUtilization > 70%)
**モニタリングする CloudWatch メトリクス:**
+ **DiskUtilization** > 70%
+ **WriteThroughput** パターン
+ **TotalBuckets** (多くのバケットでオーバーヘッドが増加する)
**設定の調整:**
**優先度 1: ログ記録設定を確認する**
+ ログレベル: 「情報」 (「デバッグ」ではない) に設定されていることを確認します。
+ flux-log-enabled: アクティブにデバッグしない限り FALSE に設定します
**優先度 2: 積極的な保持**
+ storage-retention-check-interval: 15m0s (クリーンアップの頻度が高い)
**優先度 3: 圧縮の最適化**
+ storage-compact-full-write-cold-duration: 2h0m0s (より頻繁)
+ storage-cache-snapshot-write-cold-duration: 5m0s
**優先度 4: インデックスサイズを縮小する**
+ storage-max-index-log-file-size: 524,288 (高速圧縮用に 512 KB)
**重要な考慮事項:**
**重要な最初のステップ - ログ記録設定を確認する:** その他の変更を行う前に、ログ記録設定を確認します。**デバッグログと Flux クエリログは、実際の時系列データと同じかそれ以上のディスク容量を消費**する可能性があります。これは、予期しないストレージの枯渇の最も一般的な原因の 1 つです。
**ログ記録の影響:**
+ `log-level: debug` は、1 時間あたり数百 MB の可能性のある非常に詳細なログを生成します。
+ `flux-log-enabled: TRUE` は、すべての Flux クエリ実行を完全な詳細でログに記録し、大量のログファイルを作成します。
+ これらのログは急速に蓄積され、キャパシティプランニング中に見落とされることがよくあります。
+ ログファイルは、特に小さなインスタンスでは、データインジェストよりも速くディスク容量を埋めることができます。
+ 時系列データとは異なり、ログは削除前に 24 時間ローカルストレージに保持されます。
**ログが大きい場合の即時アクション:**
1. 設定 `log-level: info` (デバッグから)
1. `flux-log-enabled: FALSE` を設定する
1. **DiskUtilization** をモニタリングしてすぐに改善する
**圧縮設定のトレードオフ:**
これらの設定変更は、ディスク使用量が大幅に変動する**取り込みスループットが高く、保持期間が短い**ワークロード向けに特別に設計されています。圧縮エンジンをより積極的に動作させるため、特定のシナリオでのみ有益です。
**重大なトレードオフ: 圧縮頻度**を増やすと、リソースの消費量が大幅に増加します。
+ 圧縮オペレーションが CPU サイクルを消費すると、**CPUUtilization** は増加します
+ **MemoryUtilization** は、データのロードと処理に伴って圧縮中に増加します
+ **WriteOpsPerSec** と **WriteThroughput** は圧縮ウィンドウ中に急増し、30% IOPS ヘッドルームを超える可能性があります
+ 圧縮 I/O がアプリケーションの書き込みと競合すると、**WriteTimeouts** が増加する可能性があります
これらの変更により、積極的な圧縮がクエリおよび書き込みオペレーションに必要なリソースを消費し、ディスク使用量を減らしてもシステム全体のパフォーマンスを低下させる、カスケードパフォーマンスの問題が発生する可能性があります。
**ベストプラクティス:** 圧縮設定を調整する前に、データとログ管理に重点を置いてください。
1. **Check Logging First (Most Common Issue):** Verify log-level is "info" and flux-log-enabled is FALSE
1. **データモデルの確認:** 実際に必要のないデータを記述していますか? 測定またはフィールドの詳細度を減らすことができますか?
1. **保持ポリシーの最適化:** **TotalBuckets** をチェックし、各バケットの保持設定を確認する
1. **圧縮の影響のモニタリング:** 変更前に **CPUUtilization**、**MemoryUtilization**、**WriteOpsPerSec** のベースラインを設定します。
**代替アプローチ:**
+ ストレージ容量を増やす (多くの場合、シンプルでコスト効率が高い)
+ データダウンサンプリングまたは集約戦略を実装する
+ バケットの統合 (**TotalBuckets** の削減) によるオーバーヘッドの削減
+ 保持ポリシーをより厳密に確認して適用する
データ管理を最適化し、増加した負荷を処理するのに十分な CPU、メモリ、IOPS ヘッドルームがインスタンスにあることを確認した場合にのみ、積極的な圧縮設定を適用します。
**ハードウェアアクション:**
+ ストレージ容量を増やす
### 高 IOPS 使用率 (ReadIOPS/WriteIOPS/TotalOperationsPerSecond > プロビジョニングの 70%)
**モニタリングする CloudWatch メトリクス:**
+ **ReadOpsPerSec** \$1 **WriteOpsPerSec** = **TotalIOpsPerSec**
+ **ReadThroughput** と **WriteThroughput**
+ プロビジョニングされた IOPS (3K、12K、または 16K) と比較する
**設定の調整:**
**優先度 1: 圧縮 I/O を制御する**
+ storage-max-concurrent-compactions: 2～3 (同時圧縮の制限)
+ storage-compact-throughput-burst: ディスク機能に基づいて調整する
+ 3K IOPS: 25,165,824 (24 MB/秒)
+ 12K IOPS: 50,331,648 (48 MB/秒)
**優先度 2: 書き込みオペレーションの最適化**
+ storage-wal-max-concurrent-writes: 8～12
+ storage-wal-max-write-delay: 5m0s
**優先度 3: スナップショットのタイミングを調整する**
+ storage-cache-snapshot-write-cold-duration: 15m0s (低頻度)
+ storage-compact-full-write-cold-duration: 6h0m0s (低頻度)
**重要な考慮事項:**
これらの変更により、I/O 使用率とシステムパフォーマンスに大きなトレードオフが生じます。
**圧縮 I/O の制限:**
+ 減らすと圧縮操作`storage-max-concurrent-compactions`が遅くなり、TSM ファイルが蓄積され、**DiskUtilization** がより迅速に増加します。
+ を小さくすると圧縮時間が`storage-compact-throughput-burst`長くなり、コンパクタのアクティブ時間が長くなり、他のオペレーションがブロックされる可能性があります。
+ 圧縮が遅いということは、ストレージエンジンが統合された TSM ファイルではなく、より小さい TSM ファイルから読み取る必要があるため、クエリのパフォーマンスが時間の経過とともに低下することを意味します。
+ I/O の待機中にクエリがタイムアウトすると、**QueryRequestsTotal** runtime\$1error レートが増加することがあります。
**スナップショットの頻度を減らす:**
+ `storage-cache-snapshot-write-cold-duration` と を増やす`storage-compact-full-write-cold-duration`と、データは先行書き込みログ (WAL) に長く保持されます。
+ これにより、ディスクにフラッシュされる前にキャッシュに保持されるデータが増えるため、**MemoryUtilization** が向上します。
+ キャッシュされたデータが保持される前にインスタンスがクラッシュすると、データ損失のリスクがわずかに増加します。
+ より多くの WAL データを再生する必要があるため、再起動後の復旧時間が長くなる
**書き込みオペレーションのチューニング:**
+ 削減`storage-wal-max-concurrent-writes`すると書き込みオペレーションがシリアル化され、高スループット期間中に **WriteTimeouts**が増加する可能性があります。
+ 増加`storage-wal-max-write-delay`は、書き込みが拒否されるまでに時間がかかることを意味します。これにより、容量の問題はマスクされますが、応答が遅いユーザーを苛立たせる可能性があります。
**ベストプラクティス:** IOPS 使用率が高い場合は、通常、設定の問題ではなくストレージ層を超過したことを示します。I/O を制限する前に、I/O パターンを分析し、制限する前に最適化します。
**ハードウェアアクション:**
+ より高い IOPS ストレージ階層へのアップグレード (3K → 12K)
+ 30% IOPS ヘッドルームが維持されていることを確認する
### ハイシリーズカーディナリティ (SeriesCardinality > 1M)
**モニタリングする CloudWatch メトリクス:**
+ バケットあたりの **SeriesCardinality** と合計
+ **MemoryUtilization** (基数の増加)
+ **CPUUtilization** (クエリ計画オーバーヘッド)
+ **QueryRequestsTotal** (runtime\$1error レートが増加する可能性があります)
**設定の調整:**
**優先度 1: シリーズ処理の最適化**
+ storage-series-id-set-cache-size: 1000-2000 (キャッシュを増やす)
+ storage-series-file-max-concurrent-snapshot-compactions: 4～8
**優先度 2: 保護制限を設定する**
+ influxql-max-select-series: 10000 (ランナウェイクエリの防止)
+ influxql-max-select-buckets: 1000
**優先度 3: インデックスオペレーションの最適化**
+ storage-max-index-log-file-size: 2,097,152 (2MB)
**重要な考慮事項:**
高シリーズのカーディナリティは基本的にデータモデリングの問題であり、設定の問題ではありません。設定の変更は症状を軽減することしかできず、根本的な問題を解決することはできません。
**設定のトレードオフ:**
増加する`storage-series-id-set-cache-size`と、シリーズルックアップをキャッシュすることでクエリのパフォーマンスが向上しますが、**MemoryUtilization** の増加が犠牲になります。各キャッシュエントリはメモリを消費し、数百万のシリーズでは、これはかなりの可能性があります。この変更を行った後、**HeapMemoryUsage** と **ActiveMemoryAllocation** をモニタリングします。
保護制限 (`influxql-max-select-series`、`influxql-max-select-buckets`) を設定すると、これらのしきい値を超えると、QueryRequestsTotal の **compile\$1error** で正当なクエリが失敗します。 **QueryRequestsTotal** 以前に機能していたダッシュボードが壊れる可能性があるため、ユーザーはクエリを変更する必要があります。これは、次の場合に特に問題があります。
+ 多くのホスト/サービスに集約されるダッシュボードのモニタリング
+ 複数のエンティティを比較する必要がある分析クエリ
+ フリート全体の条件を評価するアラートクエリ
値を小さく調整`storage-max-index-log-file-size`すると、インデックスの圧縮頻度が増加し、システムがインデックスのメンテナンスをより頻繁に実行するにつれて **CPUUtilization** と **WriteOpsPerSec** が増加します。
**重要な理解:**
**SeriesCardinality** が 5M を超えると、InfluxDB 2.x のアーキテクチャ制限に近づいています。10M以上のシリーズでは、設定に関係なくパフォーマンスが指数関数的に低下します。
+ クエリ計画が過度に高価になる (**CPUUtilization** が高い)
+ メモリ要件が非線形に増加する (**MemoryUtilization** が高い)
+ インデックスオペレーションが I/O を支配する (**ReadOpsPerSec**、**WriteOpsPerSec**)
+ **QueryRequestsTotal** runtime\$1error レートが増加する
**ベストプラクティス:** 設定の変更は一時的なバンドエイドです。根本原因に対処する必要があります。
1. **データモデルを分析する:**
+ バケットあたりの **SeriesCardinality** を確認して問題領域を特定する
+ 一意の値数が多いタグを特定する
+ 無制限のタグ値 (UUIDs、タイムスタンプ、ユーザー IDs、セッション IDsを探す
+ 代わりにフィールドとなるタグを検索する
**データモデルアクション:**
+ タグ設計を確認して不要な基数を減らす
+ 類似シリーズの統合を検討する
+ **> 10M シリーズの場合:** InfluxDB 3.0 への移行を計画する
### クエリパフォーマンスの問題
**モニタリングする CloudWatch メトリクス:**
+ **QueryRequestsTotal** 結果タイプ別 (成功、runtime\$1error、 compile\$1error、queue\$1error)
+ Status=500 または Status=499 の **APIRequestRate**
+ **QueryResponseVolume** (大きなレスポンスは高価なクエリを示す)
**設定の調整:**
**優先度 1: クエリリソースを増やす**
+ クエリ同時実行数: vCPUs の 75% に増加
+ query-memory-bytes: 合計 RAM の 70% を割り当てる
+ query-queue-size: 4096
**優先度 2: クエリ実行の最適化**
+ storage-series-id-set-cache-size: 1000 (キャッシュを改善するために増加)
+ http-read-timeout: 60 秒 (早期タイムアウトの防止)
**優先度 3: 妥当な制限を設定する**
+ influxql-max-select-point: 100000000
+ influxql-max-select-series: 10000
+ influxql-max-select-buckets: 1000
**重要な考慮事項:**
クエリリソースを増やすと、リソースの競合と潜在的なシステムの不安定性が生じます。
**リソース割り当てのトレードオフ:**
増加すると、より多くのクエリを同時に実行`query-concurrency`できますが、各クエリは CPU とメモリで競合します。
+ **CPUUtilization** が増加し、ピーククエリ期間中に飽和に達する可能性があります
+ **MemoryUtilization** は、より多くのクエリがメモリを同時に割り当てると増加します
+ 適切なリソースなしで同時実行数を増やすと、キューイングではなくすべてのクエリが遅くなります。
+ 同時クエリで使用可能なリソースが枯渇した場合のカスケード失敗のリスク
割り当てるメモリを増やす`query-memory-bytes`と、キャッシュやその他のオペレーションで使用できるメモリが少なくなります。
+ **HeapMemoryUsage** が増加
+ `storage-cache-max-memory-size` 補償のために減らす必要がある場合があります
+ キャッシュヒットが少ないほど、**ReadOpsPerSec** が高くなり、クエリのパフォーマンスが遅くなります。
+ クエリが全割り当てを使用する場合、システムはメモリ枯渇に対してより脆弱になる
増加`query-queue-size`しても問題は遅延します。容量の問題は解決されません。
+ クエリがキューで待機時間が長くなり、end-to-endレイテンシーが増加する
+ スループットが変わらない場合でも、ユーザーはシステムを遅く認識する
+ キューが大きいと、基盤となる容量の問題をマスクできる
+ **QueryRequestsTotal** queue\$1error レートは低下しますが、ユーザーエクスペリエンスは向上しない可能性があります
を増やすと、クエリの早期キャンセル`http-read-timeout`は防止されますが、次のようになります。
+ 長時間実行されるクエリはリソースをより長く消費し、他のクエリの容量を削減します。
+ ユーザーがタイムアウトエラーを受信するまで待機時間が長くなる
+ 最適化する必要がある非効率的なクエリを非表示にできる
+ 多くのスロークエリが蓄積されると、リソースが枯渇する可能性があります
**ベストプラクティス:** クエリのパフォーマンスの問題は通常、リソース不足ではなく、非効率的なクエリによって発生します。リソース割り当てを増やす前に:
1. **クエリパターンを分析する:**
+ **QueryResponseVolume** を確認して、過剰なデータを返すクエリを特定する (> 1MB)
+ **QueryRequestsTotal** runtime\$1error パターンを確認する - 障害の原因は何ですか?
+ Status=499 (クライアントのタイムアウト) の **APIRequestRate** を探す - クエリが遅すぎる
+ 頻繁に実行される高価なクエリを特定する
1. **最初にクエリを最適化する:**
一般的なクエリのアンチパターン:
+ 時間範囲フィルターがない → 明示的な時間制限を追加する
+ すべてのシリーズのクエリ → 特定のタグフィルターを追加する
+ 過剰な集計ウィンドウ → 適切な間隔を使用する
+ SELECT の不要なフィールド → 必要なデータのみをリクエストする
+ LIMIT 句なし → 妥当な制限を追加する
1. **アプリケーションレベルのソリューション:**
+ クエリ結果キャッシュを実装する (Redis、Memcached)
+ タスクを使用して一般的なパターンを事前集計する
+ 大きな結果セットのページ分割を追加する
+ ユーザー/ダッシュボードごとにクエリレート制限を実装する
+ 履歴クエリにダウンサンプリングされたデータを使用する
1. **リソースの可用性を検証する:**
+ **CPUUtilization** を確認する - すでに > 70% の場合、同時実行数を増やすと事態が悪化する
+ **MemoryUtilization** を確認する - すでに > 70% の場合、より多くのクエリメモリを割り当てると OOM が発生します
+ クエリ負荷を増やす前に**TotalIOpsPerSec** のヘッドルームが 30% であることを確認します。
**推奨されるアプローチ:**
1. 最もコストの高いクエリの上位 10 件を最適化することから始める (**QueryResponseVolume** による)
1. アプリケーションレベルでクエリ結果キャッシュを実装する
1. クエリが最適化され、メトリクスにヘッドルームが表示される場合にのみ、リソース割り当てを増やす
1. ワークロードの現在の容量が増加した場合に、より大きなインスタンスクラスにスケールする
**ハードウェアアクション:**
+ コンピューティング容量をスケールし、クエリは追加の処理能力 (vCPUsの恩恵を受ける
#### Flux クエリの RegEx パフォーマンスの落とし穴
Flux でデータをフィルタリングするときは、完全一致または単純なパターンマッチングに正規表現を使用しないでください。これにより、パフォーマンスに対する重大なペナルティが発生するためです。Flux の RegEx オペレーションは**シングルスレッドであり**、**基盤となる TSM インデックスを完全にバイパスします**。InfluxDB の最適化されたタグインデックスを高速ルックアップに使用する代わりに、RegEx フィルターはクエリエンジンがストレージから一致するすべてのシリーズを取得し、各値に対してテキスト比較を順番に実行するように強制します。これは、次の場合に特に問題になります。
+ **正確なタグ値のフィルタリング** - のような RegEx パターンの代わりに等価演算子 (`==`) または `contains()`関数を使用します。 `/^exact_value$/`
+ **複数の特定の値の一致** - のような変更パターンではなく、値の配列で `in`演算子を使用します。 `/(value1|value2|value3)/`
+ **単純なプレフィックスまたはサフィックスマッチング** - RegEx アンカーよりも効率的な `strings.hasPrefix()`関数または `strings.hasSuffix()`関数の使用を検討してください。
複数のパターン一致が必要なシナリオでは、複数のフィルター述語を論理演算子と組み合わせて使用するか、より複雑な文字列オペレーションを適用する前にタグの等価性を使用して事前フィルタリングするようにクエリを再構築します。RegEx は、単純な比較演算子では表現できない真のパターンマッチングが必要な場合にのみ予約します。
### パフォーマンスの問題の書き込み
**モニタリングする CloudWatch メトリクス:**
+ **WriteTimeouts** (カウントの増加)
+ **WriteOpsPerSec** と **WriteThroughput**
+ 書き込みエンドポイントのステータスが 500 の **APIRequestRate**
+ 書き込み中の result=runtime\$1error を含む **QueryRequestsTotal**
**設定の調整:**
**優先度 1: WAL 書き込みの最適化**
+ storage-wal-max-concurrent-writes: 12-16
+ storage-wal-max-write-delay: 10m0s
+ http-write-timeout: 60 秒
**優先度 2: キャッシュスナップショットの最適化**
+ storage-cache-snapshot-memory-size: 52,428,800 (50 MB)
+ storage-cache-snapshot-write-cold-duration: 10m0s
**優先度 3: コントロールフィールドの検証**
+ storage-no-validate-field-size: TRUE (データソースが信頼されている場合)
**重要な考慮事項:**
書き込みパフォーマンスの調整には、スループット、信頼性、リソース消費の慎重なトレードオフが含まれます。
**WAL 設定のトレードオフ:**
を増やす`storage-wal-max-concurrent-writes`と、並列書き込みオペレーションが増えますが、次のようになります。
+ **CPUUtilization**は、より多くの書き込みスレッドが CPU と競合するにつれて増加します。
+ **MemoryUtilization** は、WAL フラッシュの前にメモリにバッファされるデータが増えるにつれて増加します
+ **WriteOpsPerSec** が急増し、30% IOPS ヘッドルームを超える可能性があります
+ ディスク I/O の競合が増加すると、実際には個々の書き込みが遅くなる可能性があります
+ ディスク I/O 容量を超えると、**WriteTimeouts** が減少するのではなく増加する可能性があります。
増加は、書き込みがタイムアウトするまでの待機時間が長くなる`storage-wal-max-write-delay`ことを意味します。
+ 書き込みをすぐに失敗させるのではなく待機させることで、容量の問題をマスクします
+ 書き込みが最終的に成功しても、ユーザーの書き込み応答時間が遅くなる
+ 書き込みキューの蓄積とメモリ負荷につながる可能性がある
+ 実際に容量を増やさない - タイムアウトを遅らせるだけ
増加しても`http-write-timeout`同様にタイムアウトエラーが遅延します。
+ より大きなバッチ書き込みの完了を許可する
+ ただし、書き込みが遅いとリソースをより長く消費できます。
+ 基盤となるパフォーマンス問題を非表示にできる
+ 多くのスロー書き込みが蓄積されると、リソースが枯渇する可能性があります
**キャッシュスナップショットのトレードオフ:**
増加する`storage-cache-snapshot-memory-size`と、フラッシュする前により多くのデータがメモリに蓄積されます。
+ **MemoryUtilization** が大幅に増加
+ スナップショットの前にインスタンスがクラッシュすると、データ損失のリスクが増加する
+ スナップショットが大きいほど書き込みに時間がかかり、**WriteOpsPerSec** のスパイクが大きくなります
+ より多くのデータをバッチ処理することで書き込みスループットを向上させることができますが、メモリと信頼性のコストがかかります
`storage-cache-snapshot-write-cold-duration` 遅延スナップショットの増加:
+ データがキャッシュに保持される時間が長くなると、**MemoryUtilization** がさらに増加します
+ データ損失リスクウィンドウを増やす
+ **WriteOpsPerSec** の頻度を減らしますが、スナップショットが発生するとスパイクが大きくなります
+ より多くの WAL を再生する必要があるため、再起動後の復旧時間が長くなる
**フィールド検証のトレードオフ:**
を設定すると、フィールドサイズの検証`storage-no-validate-field-size: TRUE`が無効になります。
+ 検証チェックをスキップして書き込みスループットを改善
+ **重大なリスク:** 不正な形式または悪意のあるデータの書き込みを許可する
+ 書き込みに無効なフィールドサイズが含まれていると、データの破損につながる可能性があります
+ データ問題のデバッグをはるかに困難にする
+ **データソースを完全に制御し、信頼している場合にのみ使用します。**
**ベストプラクティス:** 書き込みパフォーマンスの問題は通常、容量制限または非効率的な書き込みパターンを示します。設定を調整する前に:
1. **書き込みパターンの分析:**
+ **WriteThroughput** と **WriteOpsPerSec** の傾向を確認する
+ **WriteTimeouts** と書き込み負荷の相関を確認する
+ ステータスコードによる書き込みエンドポイントの **APIRequestRate** のモニタリング
+ 書き込みバッチのサイズと頻度を特定する
1. **書き込みオペレーションを最初に最適化します。**
一般的な書き込みアンチパターン:
+ 個々のポイントの書き込み → バッチ書き込み (5,000～10,000 ポイント)
+ 書き込みの頻度が高すぎる → バッファとバッチ
+ 同期書き込み → 非同期書き込みキューを実装する
+ 無制限の書き込みバースト → レート制限を実装する
+ 不要な精度の記述 → タイムスタンプを適切に丸める
1. **I/O 容量の確認:**
+ **TotalIOpsPerSec** を確認する - 既に > 70% の場合、WAL 同時実行数を増やすと事態が悪化する
+ ピーク期間中に **WriteOpsPerSec** を確認する
+ 書き込み設定を調整する前に、30% IOPS ヘッドルームが存在することを確認します。
+ 3K IOPS で十分か、12K IOPS 階層が必要かを検討する
1. **アプリケーションレベルの改善:**
+ 設定可能なバッチサイズで書き込みバッファリングを実装する
+ エクスポネンシャルバックオフを使用して書き込み再試行ロジックを追加する
+ 非同期書き込みオペレーションを使用する
+ ピーク期間中に書き込みレート制限を実装する
+ 書き込みキューの深さをモニタリングし、バックプレッシャーを適用する
**推奨されるアプローチ:**
1. まず、アプリケーションレベルで書き込みバッチサイズを最適化します (バッチあたり 5,000～10,000 ポイントを目指します)
1. 書き込みバッファリングと非同期オペレーションを実装する
1. **TotalIOpsPerSec** に十分なヘッドルームがあることを確認する
1. 使用率が一貫して 70% を超える場合、次のストレージ階層 (3K IOPS → 12K IOPS → 16K IOPS) にアップグレードする
1. 書き込みが最適化され、I/O 容量が十分である場合にのみ WAL 設定を調整する
1. データソースを完全に制御していない限り、フィールド検証を無効に**しないでください**。
**ハードウェアアクション:**
+ より高い IOPS ストレージへのアップグレード (3K → 12K → 16K)
+ I/O ヘッドルームが適切であることを確認する
+ CPU またはメモリに制約がある場合は、より大きなインスタンスクラスにスケールする
## モニタリングのベストプラクティス
### CloudWatch アラーム設定
**重大なアラーム (即時アクションが必要):**
**CPUUtilization:**
+ しきい値: > 90%、5 分間
+ アクション: トラフィック修復対策またはコンピューティングスケーリングを実装する
**MemoryUtilization:**
+ しきい値: > 90%、5 分間
+ アクション: トラフィック修復対策またはコンピューティングスケーリングを実装する
**DiskUtilization:**
+ しきい値: > 85%
+ アクション: 古いバケットの削除、保持設定の更新、または Storage Scaling によるスペースの解放を試みる
**TotalIOpsPerSec:**
+ しきい値: 10 分間にプロビジョニングされた の > 90%
+ アクション: トラフィック修復対策を実装する、または IOPS を増やす
**SeriesCardinality:**
+ しきい値: > 10,000,000
+ アクション: データモデルを確認し、変更できない場合は、InfluxDB 3 への移行またはデータのシャードを検討してください。
**EngineUptime:**
+ しきい値: 予期しないリセット (< 300 秒)
+ アクション: Timestream サポートへのチケットを作成しない場合は、メンテナンスウィンドウと一致するかどうかを確認します。
**警告アラーム (調査が必要):**
**CPUUtilization:**
+ しきい値: > 70%、15 分間
+ アクション: ワークロードまたはトラフィックの変更を確認する
**MemoryUtilization:**
+ しきい値: > 70%、15 分間
+ アクション: ワークロードまたはトラフィックの変更を確認する
**DiskUtilization:**
+ しきい値: > 70%
+ アクション: 保持ポリシーを確認する
**TotalIOpsPerSec:**
+ しきい値: 15 分間にプロビジョニングされた の > 70%
+ アクション: ワークロードまたはトラフィックの変更を確認する
**QueryRequestsTotal (runtime\$1error):**
+ しきい値: 合計クエリの > 1%
+ アクション: ワークロードまたはトラフィックの変更を確認する
**WriteTimeouts:**
+ しきい値: 書き込みオペレーションの > 1%
+ アクション: ワークロードまたはトラフィックの変更を確認する
**SeriesCardinality:**
+ しきい値: > 5,000,000
+ アクション: データモデルの最適化を確認する
### プロアクティブモニタリングチェックリスト
**毎日:**
+ APIRequestRate でエラースパイク (400、404、499、500) を確認する
+ runtime\$1error および queue\$1error レートの QueryRequestsTotal を確認する
+ WriteTimeouts カウントが最小限であることを確認する
+ 重要なアラームがないか確認する
+ EngineUptime を検証する (予期しない再起動なし)
**毎週:**
+ CPUUtilization、MemoryUtilization、および DiskUtilization の傾向を確認する
+ QueryRequestsTotal パターンを結果タイプ別に分析する
+ バケットあたりの SeriesCardinality 増加率を確認する
+ TotalIOpsPerSec 使用率の傾向を確認する
+ 設定パラメータが最適であることを確認する
+ TaskExecutionFailures パターンを確認する
**毎月:**
+ キャパシティプランニングレビュー (3～6 か月前にプロジェクト)
+ 現在のメトリクスをサイジングテーブルと比較する
+ 保持ポリシーの確認と最適化
+ APIRequestRate と QueryResponseVolume からクエリパターンを分析する
+ SeriesCardinality とデータモデルの効率を確認する
+ インスタンスのスケーリングまたは設定変更の必要性を評価する
+ TotalBuckets と統合の機会を確認する
## トラブルシューティングガイド
### シナリオ: 突然のパフォーマンス低下
**調査ステップ:**
**最近の変更を確認する:**
+ AWS マネジメントコンソールの設定パラメータの変更
+ アプリケーションのデプロイの変更
+ クエリパターンの変更
+ データモデルの変更
+ インフラストラクチャの変更 (インスタンスタイプ、ストレージ)
**CloudWatch メトリクスを確認します。**
+ **CPU スパイク?** → CPUUtilization、QueryRequestsTotal を確認する
+ **メモリプレッシャー?** → MemoryUtilization、HeapMemoryUsage、ActiveMemoryAllocation を確認する
+ **IOPS 飽和度** → TotalIOpsPerSec、ReadOpsPerSec、WriteOpsPerSec を確認する
+ **シリーズ基数ジャンプ?** → SeriesCardinality の増加を確認する
+ **エラー率の増加** → QueryRequestsTotal (runtime\$1error)、APIRequestRate (Status=500) を確認する
+ **予期しない再起動ですか?** → EngineUptime を確認する
**詳細ログ記録を有効にする:**
設定の変更:
+ ログレベル: デバッグ
+ flux-log-enabled: TRUE
1～2 時間モニタリングし、ログを確認する
ログレベルに戻る: 調査後の情報
**解決ステップ:**
+ 検出結果に基づいて適切な設定変更を適用する
+ 制限に達した場合のリソースのスケーリング
+ 必要に応じてクエリまたはデータモデルを最適化する
+ 突然負荷が増加する場合はレート制限を実装する
### シナリオ: メモリの枯渇
**症状:**
+ MemoryUtilization > 90%
+ HeapMemoryUsage が最大値に近づいています
+ runtime\$1error (メモリ不足) を示す QueryRequestsTotal
+ Status=500 を示す APIRequestRate
**解決ステップ:**
即時アクション (緊急の場合):
1. インスタンスを再起動してメモリをクリアする (安全である場合)
1. クエリの同時実行数を一時的に減らす
1. 可能な場合は長時間実行されるクエリを排除する
設定の変更:
**優先度 1: キャッシュメモリを減らす**
+ storage-cache-max-memory-size: RAM を 10% に減らす
+ 例: 32GB → 3,355,443,200 バイト
+ storage-cache-snapshot-memory-size: 26,214,400 (25 MB)
**優先度 2: クエリメモリの制限**
+ query-memory-bytes: 合計 RAM の 60% に設定
+ query-max-memory-bytes: query-memory-bytes の一致
+ query-initial-memory-bytes: query-memory-bytes の 10%
**優先度 3: 保護制限を設定する**
+ influxql-max-select-series: 10000
+ influxql-max-select-point: 100000000
+ クエリ同時実行数: vCPUs
**長期ソリューション:**
+ データモデルを最適化して **SeriesCardinality** を減らす
+ アプリケーションレベルでクエリ結果のサイズ制限を実装する
+ クエリタイムアウトの適用を追加する
+ 最も一般的なクエリを確認して、 セクションで説明されているベストプラクティスに従っていることを確認します。 [クエリパフォーマンスの問題](#query-performance-issues)
### シナリオ: ハイシリーズカーディナリティの影響
**CloudWatch メトリクスを確認します。**
+ **SeriesCardinality** > 5M
+ **MemoryUtilization** 高
+ runtime\$1error の増加を示す **QueryRequestsTotal**
+ クエリ計画のオーバーヘッドによる **CPUUtilization**の向上
**調査ステップ:**
**Cardinality Growth を分析する:**
+ SeriesCardinality 成長率 (毎日/毎週)
+ 10Mのしきい値への射影
+ 高基数の原因を特定する
+ タグの設計と使用を確認する
**パフォーマンスへの影響を評価する:**
+ **QueryRequestsTotal**成功率
+ **MemoryUtilization** の相関を確認する
+ **CPUUtilization** パターンを確認する
+ **QueryResponseVolume** の傾向を分析する
**Cardinality ソースを特定する:**
データモデルを確認します。
+ SeriesCardinality が最も高いバケットはどれですか?
+ 一意の値数が多いタグはどれですか?
+ 不要なタグはありますか?
+ タグ値は無制限ですか (UUIDs、タイムスタンプなど)?
**現在の設定を確認する:**
最適化パラメータを確認します。
+ storage-series-id-set-cache-size: 現在の値?
+ influxql-max-select-series: ランナウェイクエリを制限していますか?
+ storage-max-index-log-file-size: 基数に適していますか?
**解決ステップ:**
設定の即時変更:
**優先度 1: シリーズ処理の最適化**
+ storage-series-id-set-cache-size: 1500-2000
+ storage-series-file-max-concurrent-snapshot-compactions: 6～8
+ storage-max-index-log-file-size: 2,097,152 (2MB)
**優先度 2: 保護制限を設定する**
+ influxql-max-select-series: 10000
+ influxql-max-select-buckets: 1000
+ query-concurrency: メモリが制約されている場合は減らす
**優先度 3: リソースを増やす**
+ 次のインスタンス階層にスケールする
+ メモリ割り当てを増やす
+ 12K IOPS ストレージ層を検討する
**移行計画 (> 10Mシリーズの場合):**
+ **InfluxDB 3.0 は優れた高カーディナリティパフォーマンスを提供します**
+ 移行タイムラインを計画する (2～3 か月)
+ 最初にデータのサブセットを使用してテストする
+ 移行用のアプリケーションを準備する
+ InfluxDB 3.0 は、数十億のシリーズに最適化された列指向ストレージを使用します。
### シナリオ: クエリキューのビルドアップ
**CloudWatch メトリクスを確認します。**
+ result=queue\$1error の増加を伴う **QueryRequestsTotal** (クエリは拒否されます)
+ Status=429 または Status=503 の **APIRequestRate** (サービスが利用できない/リクエストが多すぎる)
+ **CPUUtilization** が上昇する (> 70%) 可能性があり、リソースの飽和を示す
+ **MemoryUtilization** が高い (> 70%) クエリ容量を制限する可能性があります
+ 大きなレスポンスサイズを示す **QueryResponseVolume** (クエリに過剰なリソースがかかる)
**調査ステップ:**
**キューと同時実行メトリクスを分析する:**
+ **QueryRequestsTotal**内訳を確認します。
+ queue\$1error 数が多い場合は、クエリが拒否されていることを示します。
+ 成功率をベースラインと比較します - 低下していますか?
+ runtime\$1error の増加を確認する (起動後にクエリが失敗する)
+ **APIRequestRate** パターンをモニタリングします。
+ Status=429 (リクエストが多すぎる) または Status=503 (サービスを利用できない) を探します。
+ 拒否が発生しているエンドポイントを特定する
+ 時間の経過に伴うリクエストレートの傾向を確認する
**リソース使用率の確認:**
+ 高キュー期間中の **CPUUtilization**:
+ > 70% の場合、クエリは CPU バインドされており、より速く実行できない
+ < 50% の場合、キューの制限が制限しすぎる可能性があります
+ **MemoryUtilization** の相関関係:
+ メモリが多いとクエリの同時実行が制限されている可能性があります
+ **HeapMemoryUsage** と **ActiveMemoryAllocation** でメモリ負荷を確認する
+ **TotalIOpsPerSec** パターン:
+ I/O が高いとクエリの実行が遅くなる可能性があります
+ クエリが I/O バインドされているかどうかを確認する
**クエリパターンを特定する:**
+ **QueryResponseVolume** を確認します。
+ クエリは過剰なデータを返していますか (> 1MB)?
+ レスポンスボリュームが最大のエンドポイントを特定する
+ 高価なクエリのパターンを探す
+ **QueryRequestsTotal** レートを分析する:
+ 1 秒あたりのクエリレートはどれくらいですか?
+ バーストパターンや持続的な高負荷はありますか?
+ サイズ表からインスタンス容量と比較する
+ エンドポイント別に **APIRequestRate** を確認します。
+ トラフィックが最も高いクエリエンドポイントはどれですか?
+ 重複または冗長なクエリはありますか?
**リソースの可用性を確認する:**
+ 現在のメトリクスをサイジングテーブルのレコメンデーションと比較します。
+ **SeriesCardinality** とインスタンスクラスの容量
+ クエリレートと 1 秒あたりの推奨クエリ数
+ **CPUUtilization** と **MemoryUtilization** ヘッドルーム
+ IOPS 容量を確認します。
+ **TotalIOpsPerSec** には 30% のヘッドルームが必要です
+ クエリがディスク I/O で待機しているかどうかを確認する
**解決ステップ:**
設定の変更:
**優先度 1: キュー容量を増やす**
+ query-queue-size: 4096 (デフォルト 1024 から)
**優先度 2: 同時実行数を増やす (リソースで許可されている場合)**
+ クエリ同時実行数: vCPUs の 75% に増加
+ 例: 16 vCPU → query-concurrency = 12
+ CPUUtilization が変更後も < 80% のままであることを確認する
+ MemoryUtilization が変更後も < 80% のままであることを確認する
**優先度 3: クエリ実行の最適化**
+ query-memory-bytes: 適切な割り当てを確保する
+ storage-series-id-set-cache-size: 1000-1500
+ http-read-timeout: 120s (早期タイムアウトの防止)
**優先度 4: 保護制限を設定する**
+ influxql-max-select-series: 10000
+ influxql-max-select-point: 100000000
**アプリケーションレベルのソリューション:**
+ **クエリ結果キャッシュを実装する** (Redis、Memcached)
+ 頻繁に実行されるクエリの結果をキャッシュする
+ データ鮮度要件に基づいて適切な TTLs を設定する
+ キャッシュヒットレートをモニタリングする
+ **連続クエリを使用して**一般的なパターンを事前集計する
+ 一般的な集計を事前計算する
+ raw データの代わりに事前集計データをクエリする
+ 大きな結果セットの**ページ分割を追加する**
+ 初期クエリサイズを制限する
+ オンデマンドで追加データをロードする
+ ユーザー/ダッシュボードごとに**クエリレート制限を実装**する
+ シングルユーザーがシステムに負担をかけないようにする
+ 公平使用クォータを設定する
+ 履歴クエリに**ダウンサンプリングされたデータを使用する**
+ 古い時間範囲の低解像度データをクエリする
+ 最近のデータ用にフル解像度クエリを予約する
**スケーリングの決定:**
+ CPUUtilization > 70% が持続する場合: より大きなインスタンスにスケールする
+ MemoryUtilization > 70% が持続している場合: メモリ最適化インスタンスにスケールする
+ クエリレートがインスタンス容量を超える場合: サイジングテーブルごとに次の階層にスケールする