

Amazon Timestream for LiveAnalytics に類似した機能をご希望の場合は Amazon Timestream for InfluxDB をご検討ください。リアルタイム分析に適した、シンプルなデータインジェストと 1 桁ミリ秒のクエリ応答時間を特徴としています。詳細については、[こちら](https://docs.aws.amazon.com//timestream/latest/developerguide/timestream-for-influxdb.html)を参照してください。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Timestream コンピューティングユニット (TCU)
<a name="tcu"></a>

Amazon Timestream for LiveAnalytics は、Timestream コンピューティングユニット (TCU) のクエリニーズに合わせて割り当てられたコンピューティング容量を測定します。1 TCU は、4 基の vCPU と 16 GB のメモリで構成されます。Timestream for LiveAnalytics でクエリを実行すると、サービスはクエリの複雑さと処理されるデータ量に基づいて TCU をオンデマンドで割り当てます。クエリが消費 TCU の数によって、関連するコストが決まります。

**注記**  
2024 年 4 月 29 日以降にサービスにオンボード AWS アカウント されるすべての は、デフォルトでクエリ料金に TCUsを使用します。

**Topics**
+ [プロビジョンド Timestream コンピューティングユニット](provisioned-tcu.md)
+ [MaxQuery TCU](#maxquery-tcu)
+ [TCU の請求](#billing-tcus)
+ [TCU の設定](#config-tcus)
+ [必要なコンピューティングユニットの見積もり](#estimate-compute-units)
+ [MaxQueryTCU を増やすタイミング](#increase-maxquery-tcu)
+ [MaxQueryTCU を減らすタイミング](#decrease-maxquery-tcu)
+ [CloudWatch メトリクスの使用状況のモニタリング](#cw-metrics-monitor-usage)
+ [コンピューティングユニットの使用状況のバリエーションを理解する](#variations-compute-units-usage)

## MaxQuery TCU
<a name="maxquery-tcu"></a>

この設定は、サービスがクエリを処理するために任意の時点で使用するコンピューティングユニットの最大数を指定します。クエリを実行するには、最小容量を 4 TCU に設定する必要があります。TCU の最大数は、4、8、16、32 など、4 の倍数で設定できます。ワークロードに使用するコンピューティングリソースに対してのみ課金されます。例えば、最大 TCU を 128 に設定しても、8 TCU のみを一貫して使用する場合、8 TCU を使用した期間に対してのみ課金されます。アカウントのデフォルト `MaxQueryTCU` は 200 に設定されています。 AWS SDK または で AWS マネジメントコンソール または [UpdateAccountSettings](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_UpdateAccountSettings.html) API オペレーションを使用して、4 `MaxQueryTCU`から 1000 に調整できます AWS CLI。

アカウントの `MaxQueryTCU` を設定することをお勧めします。TCU の上限を設定すると、サービスがクエリワークロードに使用できるコンピューティングユニットの数を制限して、コストを制御できます。これにより、クエリのコストをより正確に予測および管理できます。

## TCU の請求
<a name="billing-tcus"></a>

各 TCU の料金は、1 秒あたりの詳細度を使用して時間単位で請求されます (最低は 30 秒間)。これらのコンピューティングユニットの使用単位は TCU 時間です。

クエリを実行すると、クエリの実行時に使用された TCU に対して課金され、TCU 時間単位で課金されます。例えば、次のようになります。
+ ワークロードは 20 TCU を 3 時間使用します。60 TCU 時間 (20 TCU x 3 時間) の料金が発生します。
+ ワークロードでは、30 分間に 10 TCU を使用し、次の 30 分間に 20 TCU を使用します。15 TCU 時間 (10 TCU x 0.5 時間 \$1 20 TCU x 0.5 時間) の料金が発生します。

TCU 時間あたりの料金は、 によって異なります AWS リージョン。詳細については、「[Amazon Timestream pricing](https://aws.amazon.com/timestream/pricing/)」を参照してください。ワークロードが増加すると、サービスは指定された最大 TCU 制限 (`MaxQueryTCU`) までコンピューティング容量を自動的にスケールして、一貫したパフォーマンスを維持します。`MaxQueryTCU` 設定は、サービスがスケールできるコンピューティング容量の上限として機能します。この設定は、コンピューティングリソースの数とその結果のコストを管理するために役立ちます。

## TCU の設定
<a name="config-tcus"></a>

サービスをオンボードする場合、各 のデフォルト`MaxQueryTCU`制限 AWS アカウント は 200 です。この制限は、 AWS SDK または で AWS マネジメントコンソール または [UpdateAccountSettings](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_UpdateAccountSettings.html) API オペレーションを使用して、いつでも必要に応じて更新できます AWS CLI。

設定する値が不明な場合は、アカウントの `QueryTCU` メトリクスをモニタリングします。このメトリクスは、 AWS マネジメントコンソール および Amazon CloudWatch で使用できます。このメトリクスは、使用される TCU の最大数に関するインサイトを 1 分単位の詳細度で提供します。履歴データと将来の成長の推定に基づいて、使用量の急増に対応するように `MaxQueryTCU` を設定します。ピーク使用量よりも少なくとも 4～16 TCU のヘッドルームを用意することをお勧めします。例えば、過去 30 日間のピーク `QueryTCU` が 128 であった場合、`MaxQueryTCU` を 132～144 に設定することをお勧めします。

## 必要なコンピューティングユニットの見積もり
<a name="estimate-compute-units"></a>

コンピューティングユニットはクエリを同時に処理できます。必要なコンピューティングユニットの数を決定するには、次の表の一般的なガイドラインを考慮してください。


| 同時クエリ | TCU | 
| --- | --- | 
| 7 | 4 | 
| 14 | 8 | 
| 21 | 12 | 

**注記**  
これらは一般的なガイドラインであり、必要なコンピューティングユニットの実際の数は、次のようないくつかの要因によって異なります。  
クエリの有効な同時実行数。
クエリパターン。
スキャンされるパーティション数。
上記以外のワークロード固有の特性。
このガイドラインは、過去数分～1 時間のデータをスキャンし、[Timestream クエリのベストプラクティス](queries-bp.md)と[データモデリングガイドライン](data-modeling.md)に準拠するクエリに関するものです。
必要に応じて、アプリケーションのパフォーマンスと `QueryTCU` メトリクスをモニタリングして、コンピューティングユニットを調整します。

## MaxQueryTCU を増やすタイミング
<a name="increase-maxquery-tcu"></a>

以下のシナリオでは、`MaxQueryTCU` を増やすことを検討する必要があります。
+ クエリのピーク消費量が、現在設定されている最大クエリ TCU に近づいている場合。最大クエリ TCU は、ピーク消費量よりも 4～16 TCU 以上高く設定することをお勧めします。
+ クエリが MaxQueryTCU を超えたというメッセージとともに 4xx エラーを返す場合。ワークロードの計画的な増加が予想される場合は、それに応じて設定された最大クエリ TCU を再検討して調整します。

## MaxQueryTCU を減らすタイミング
<a name="decrease-maxquery-tcu"></a>

以下のシナリオでは、`MaxQueryTCU` を減らすことを検討してください。
+ ワークロードに予測可能で安定した使用パターンがあり、コンピューティングの使用要件をよく把握している場合。最大クエリ TCU をピーク消費量よりも 4～16 TCU 多い数まで減らすと、意図しない使用量やコストを防ぐことができます。この値を更新するには、[UpdateAccountSettings](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_UpdateAccountSettings.html) API オペレーションを使用します。
+ アプリケーションの動作パターンやユーザーの行動パターンの変化により、ワークロードのピーク使用量が時間の経過とともに減少した場合。最大 TCU を下げると、意図しないコストを削減できます。

**注記**  
現在の使用状況によっては、最大 TCU 制限の削減が反映されるまでに最大 24 時間かかります。クエリが実際に消費する TCU に対してのみ課金されます。最大クエリ TCU 制限を高くしても、ワークロードでそれらの TCU が使用されない限り、コストには影響しません。

## CloudWatch メトリクスの使用状況のモニタリング
<a name="cw-metrics-monitor-usage"></a>

TCU の使用状況をモニタリングするために、Timestream for LiveAnalytics は CloudWatch メトリクス `QueryTCU` を提供します。このメトリクスは、1 分間に使用されるコンピューティングユニットの数を指定し、毎分出力されます。1 分間に使用される最大および最小 TCU を選択してモニタリングできます。このメトリクスにアラームを設定して、クエリコストをリアルタイムで追跡することもできます。

## コンピューティングユニットの使用状況のバリエーションを理解する
<a name="variations-compute-units-usage"></a>

クエリに必要なコンピューティングリソースの数は、複数のパラメータに基づいて増減できます。例えば、データ量、データインジェストパターン、クエリレイテンシー、クエリシェイプ、クエリ効率、リアルタイムクエリと分析クエリを使用するクエリの組み合わせなどです。これらのパラメータにより、ワークロードに必要な TCU が増減する可能性があります。これらのパラメータが変更されない安定状態では、ワークロードに必要なコンピューティングユニットの数が減少することが確認できるかもしれません。その結果、毎月のコストを削減できます。

さらに、ワークロードまたはデータにおけるこれらのパラメータのいずれかが変更された場合、必要なコンピューティングユニットの数が増加する可能性があります。Timestream がクエリを受信すると、クエリがアクセスするデータパーティションに応じて、Timestream はクエリに対応して実行するコンピューティングリソースの数を決定します。

Timestream は、インジェストとクエリのアクセスパターンに基づいて定期的にデータレイアウトを最適化します。Timestream は、アクセス頻度の低いパーティションを単一のパーティションにまとめるか、ホットパーティションを複数のパーティションに分割してパフォーマンスを向上させることで、最適化を実行します。したがって、同じクエリで使用されるコンピューティング容量は、特定の時点でわずかに異なる場合があります。

**クエリに TCU 料金を使用するようにオプトインする**  
既存のユーザーとして 1 回限りのオプトインで TCU を使用すれば、クエリごとの測定されるバイト数の下限に基づく請求から切り替えて、より適切にコストを管理できます。 AWS SDK AWS マネジメントコンソール または で または [UpdateAccountSettings](https://docs.aws.amazon.com/timestream/latest/developerguide/API_query_UpdateAccountSettings.html) API オペレーションを使用してオプトインできます AWS CLI。API オペレーションで `QueryPricingModel` パラメータを `COMPUTE_UNITS` に設定します。  
コンピューティングベースの料金モデルのオプトインは、元に戻せない変更です。