翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# コスト最適化の柱
AWS Well-Architected フレームワークの[コスト最適化の柱](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost-optimization.html)は、不要なコストを回避し、コスト最適化の方法でアーキテクチャを構築することに重点を置いています。以下の推奨事項は、Amazon Timestream for InfluxDB のコスト最適化設計原則とアーキテクチャのベストプラクティスを満たすのに役立ちます。
コスト最適化の柱は、次の主要分野に焦点を当てています。
+ ユースケースの要件とコストを理解する
+ コストに留意したリソースの選択
+ 過剰な支出なしでスケールし、ビジネスニーズを満たす
+ データストレージと転送の適切なサイズ設定
## ユースケースの要件とコストを理解する
以下のユースケースでは、InfluxDB に Timestream を使用しないことをお勧めします。
+ データモデルにリレーショナルデータがある場合、Timestream for InfluxDB は適切なソリューションではありません。
+ クエリで時間フィルターを使用できない場合、Influx はすべてのシリーズをスキャンします。これは非効率です。
## コストに留意したリソースの選択
[InfluxDB インスタンス](https://aws.amazon.com/timestream/pricing/)のコストは、インスタンスが実行される時間の時間単位のレートに基づきます。インスタンスは、データベースの実行にかかる総コストの平均 85% を占めるため AWS、適切なサイジングはコストに大きな影響を与える可能性があります。インスタンスのサイズを適正化する最善の方法は、アプリケーションのパフォーマンスをテストすることです。
+ `CPUUtilization` と は常に`MemoryUtilization`高いか低いか。
+ 価格とパフォーマンスのバランスはどれくらいですか?
インスタンスのコストは直線的にスケールされます。`db.influx.2xlarge` インスタンスの時間単位のコストは`db.influx.xlarge`インスタンスの 2 倍ですが、リソース割り当ても 2 倍です。`db.influx.16xlarge` インスタンスは、`db.influx.xlarge`インスタンスの時間単位のコストの 16 倍です。
特定の時間枠 (秒、分、時間、または日) におけるワークロードの書き込みと読み取りの数を推定します。InfluxDB インスタンスの Timestream は、インスタンスタイプに基づいて 1 秒あたり 50,000～500,000 回の書き込みと 1 秒あたり 10～100 回のクエリ (QPS) をサポートします。たとえば、 `db.influx.2xlarge`は通常、1 秒あたり最大 150,000 回の書き込みと約 25 QPS をサポートします。効率的なデータモデルと効率的なクエリにより、そのパフォーマンスを超える可能性があります。要件が時刻、週、または月によって異なる場合は、以下を実行してスケールアップとスケールダウンをスケジュールできます。
+ [AWS Lambda 関数を作成してスケジュールします](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-run-lambda-schedule.html)。
+ カスタムスケジューラを使用して API または SDK を実行し、バッファ時間で[スケールアップおよびスケールダウン](https://docs.aws.amazon.com/timestream/latest/developerguide/timestream-for-influx-managing-modifying-db.html)します。
## 過剰な支出なしでスケールし、ビジネスニーズを満たす
Timestream for InfluxDB のエントリレベルの実験では、 `db.influx.medium`と を使用できます`db.influx.large`。これらのインスタンスは、大規模なインスタンスに投資する前に、Timestream for InfluxDB の使用経験を積むのに十分な大きさです。
`db.influx.medium` および `db.influx.large`インスタンスは、低コストの開発環境に適しています。ただし、RAM (8 GiB と 16 GiB) は小さくvCPUs (1 vCPU と 2 vCPUs) は少なく、ネットワークパフォーマンスは最大 10 GB です。すべてのワークロードがこれらのインスタンスクラスに適しているわけではありません。`CPUUtilization` と をモニタリングし`MemoryUtilization`、必要に応じてスケールアップまたはスケールダウンします。通常、メモリと vCPU の比率は一定です。db.influx インスタンスクラスは、Amazon EC2 r7g インスタンスクラスとメモリmemory-to-vCPU の比率が似ています。本番稼働を開始する前にend-to-endのパフォーマンステストまたは負荷テストを実行することを強くお勧めします。
効率的なデータモデリング、バッチ書き込み、最適化されたクエリでは、メモリとコンピューティングの使用量が少なくて済みます。必要なリソースが少ない場合は、使用するインスタンスが小さくなる可能性があります。
## データストレージと転送の適切なサイズ設定
データを保存するには、次のベストプラクティスを使用します。
+ InfluxDB の Timestream には時系列データのみを保存します。
+ InfluxDB バケットに適切な保持を設定し、保持期間より古いデータが削除され、シャードが定期的に自動的に圧縮されるようにします。詳細については、[InfluxDB ドキュメント](https://docs.influxdata.com/influxdb/v2/reference/internals/shards/#shard-compaction)を参照してください。
+ 将来の書き込み用にディスク使用量を最適化します。
+ ワークロードに必要のない InfluxDB バケットを削除します。InfluxDB は削除をサポートしています。ユースケースに合った場合は、スケジュールされたクリーンアップを実行できます。
データ転送では、クロスリージョンネットワークオーバーヘッドを避けるため、Timestream for InfluxDB データベースインスタンス AWS リージョン と同じ にアプリケーションをデプロイすることをお勧めします。データ転送料金が発生する場合もあります。データ転送の詳細については、[「 料金表」ページ](https://aws.amazon.com/timestream/pricing/)を参照してください。