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

パフォーマンス効率の柱

AWS Well-Architected フレームワークのパフォーマンス効率の柱は、データの取り込みまたはクエリ中にパフォーマンスを最適化する方法に焦点を当てています。パフォーマンスの最適化は、以下の段階的かつ継続的なプロセスです。

パフォーマンス効率の柱は、高パフォーマンスのデータモデルを選択するのに役立つガイドラインを提供します。パフォーマンス効率の柱には、クエリと書き込みの最適化のベストプラクティスが含まれます。

パフォーマンス効率の柱は、次の主要分野に焦点を当てています。

流入データモデリングとクエリの最適化

InfluxDB の時系列データのパフォーマンスとクエリ機能を最適化するには、効果的なスキーマの設計が不可欠です。まず、適切なタグとフィールドを選択します。InfluxDB はタグをインデックス化するため、クエリエンジンは測定値内のすべてのレコードをスキャンしてタグ値を見つける必要はありません。つまり、タグのクエリは、フィールドのクエリよりも効率的です。データを圧縮して保存するために、ストレージエンジンはフィールド値を系列キーでグループ化し、それらのフィールド値を時間順に並べます。シリーズキーは、測定、タグキーと値、およびフィールドキーによって定義されます。データ設計の詳細については、InfluxDB ドキュメントを参照してください。

ストレージエンジンは、時間構造化マージツリー (TSM) データ形式を使用します。TSM データ形式の詳細については、InfluxDB ドキュメントを参照してください。

DevOps ユースケースの一部としてデータを収集するとします (timestamp、host_id、region、cpu、memorynetwork_in_bytesnetwork_out_bytes、、disk_io）。レコードのタイムスタンプを含むタグは、レコードのユーザー、内容、日時、場所を識別するのに役立つコンテキストを提供します。タグは、データを整理および分類し、クエリの一部としてデータをフィルタリングするために使用されます。

host_id および region タグは、DevOps ユースケースの整理と分類に最適なタグです。これらの列は、特定のホストのデータをフィルタリングしたり、リージョン列に基づいて分析を実行したりするのに役立ちます。

メジャーは、データに対して数学的計算 (合計、平均、変化率の差の計算など) と定量的分析を実行するための基盤を提供します。したがって、、cpu、memorynetwork_in_bytes、、および はnetwork_out_bytes、時間の経過とともに変化する DevOps に関連する重要なメトリクスをdisk_ioキャプチャします。これらのメトリクスを使用して、異なるホスト間で CPU とメモリを計算するなど、さまざまな分析を実行できます。これらのメトリクス値を使用して、本番稼働停止の回避やインフラストラクチャ計画の実行に役立つデータ駆動型の意思決定を行うことができます。

Cardinality は一意のタグ値の組み合わせです。カーディナリティをできるだけ低く維持することを目指します。アプリケーションでデータポイントごとに一意の識別子が必要な場合は、タグ値の代わりにフィールド値を使用します。これにより、クエリのレイテンシーが大幅に向上します。スキーマを適切に設計すると、系列のカーディナリティが高くなり、クエリの実行が向上します。データの読み取りと書き込みが遅くなることに気付いた場合、またはカーディナリティがパフォーマンスにどのように影響するかを確認するには、「Timestream for InfluxDB ドキュメント」を参照してください。

アプリケーションが JSON オブジェクトを出力する場合は、それらを個々の列 (タグまたはフィールド) に変換し、列を InfluxDB にロードします。InfluxDB は時系列データ用に設計されているため、個々の列でデータを整理することが、サービスの機能を最大限に活用するためのベストプラクティスです。

1 つの InfluxDB v2.7 OSS インスタンスは、すべての組織間でアクティブに書き込みまたはクエリされている約 20 個の InfluxDB バケットをサポートします。20 を超えるバケットがパフォーマンスに悪影響を及ぼす可能性があります。InfluxDB の設定オプションには制限があり、ユースケースに基づいて設定できるオプションもあります。テストフェーズでアプリケーションワークロードに基づいて設定を検証します。データ保持はバケットレベルで設定されるため、異なるデータ保持要件を持つデータは異なるバケットに保存する必要があります。設定オプションの詳細については、「Timestream for InfluxDB ドキュメント」を参照してください。

データは、タグキー、フィールドキー、測定値ではなく、タグ値またはフィールド値に保存します。タグ値とフィールド値にデータを保存するようにスキーマを設計すると、クエリの書き込みが容易になり、効率が向上します。データモデリングのベストプラクティスの詳細については、「パフォーマンスのための設計」を参照してください。

InfluxDB タスクを使用して、データを事前集計し、データをさまざまな測定値またはバケットにロードし、そこからダッシュボードとビジュアライゼーションのデータを生成します。

InfluxDB OSS は、Prometheus プレーンテキスト表示形式でフォーマットされたパフォーマンス、リソース、使用状況メトリクスを返す/metricsエンドポイントを公開します。InfluxDB テンプレートを使用してモニタリングとアラートを設定し、高いクエリレイテンシー、書き込みスループットの低下、リソース使用量の急増などの問題を事前に検出します。

InfluxDB の Timestream は、Influx IO 込みストレージを提供します。適切な IOPS サイズを選択すると、クエリの実行が大幅に高速化されます。これは、大量のデータをスキャンしたり、幅広いリクエストを処理する必要があるクエリに特に役立ちます。状況によっては、必要なパフォーマンスの向上を実現するために、インスタンスのスケールアップと IOPS の強化の組み合わせが必要になる場合があります。

dev 環境と prod 環境 (インスタンスクラス、ストレージタイプ、設定) を一致させることをお勧めします。本番環境に移行する前に、リリースごとに下位環境の変更をテストします。Influx IO 搭載ストレージボリュームでは、Timestream for InfluxDB は、さまざまなタイプのワークロードに必要な最適な IOPS (3,000、12,000、16,000) とスループットで事前設定された 3 つのストレージ層を提供します。ほとんどのユースケースでは、必要な IOPS は 3,000 未満です。パフォーマンステストで高い IOPS の必要性が示されている場合にのみ、12,000 または 16,000 を選択します。詳細については、「Timestream for InfluxDB ドキュメント」の「セットアップ」セクションを参照してください。

書き込みの最適化

InfluxDB への書き込みを最適化するには、ネットワークオーバーヘッドを最小限に抑えるために、リクエストごとに 5,000 行のラインプロトコルのバッチでデータを書き込むことをお勧めします。パフォーマンスを向上させるには、データポイントを書き込む前に、キーで辞書順にタグをソートします。ナノ秒ではなく、タイムスタンプに可能な限り粗い時間精度を使用すると、パフォーマンスも向上します。gzip 圧縮を有効にすることは、書き込みを高速化し、ネットワーク帯域幅を減らすもう 1 つの方法です。telegraf.conf ファイルのinfluxdb_v2出力プラグイン設定で、 content_encodingオプションを に設定しますgzip。これらの最適化を実装すると、InfluxDB にデータを書き込むパフォーマンスと効率が大幅に向上します。InfluxDB 書き込みのベストプラクティスの詳細については、「InfluxDB への書き込みの最適化」を参照してください。

InfluxDB の書き込みパフォーマンスは、多くの場合、使用可能な IOPS と密接に関連しています。データを書き込む場合、InfluxDB は大量の I/O オペレーションを実行してデータを保存する必要があります。IOPS を増やすと、InfluxDB は 1 秒あたりの書き込み数を増やすことができます。