Azure Data Explorer (ADX) は、大規模なテレメトリとログ データをリアルタイムで分析するためのフル マネージド分析プラットフォームです。 この記事では、Azure Data Explorer で取り込まれた GB あたりのコストの計算方法、それを推進する要因、およびコスト効率のためにクラスターを最適化する方法について説明します。 ビッグ データ分析プラットフォームでは、さまざまな価格モデルが使用されます。 多くのプラットフォームは、クエリの量、データ インジェスト、ストレージ期間、コンピューティング リソースなどの要因に基づいて価格を設定します。 この複雑さにより、製品間で価格を比較することが困難になります。
この記事では、Azure Data Explorer の使用コストを理解するために、 取り込まれた GB あたりのメトリック コストを使用します。 このメトリックは、 クラスター の合計コスト (コンピューティング、ストレージ、ネットワーク、サービス マークアップ) を、その期間中に 取り込まれた元のサイズのデータの合計 で割った値です。
2025 年 6 月の ADX クラスターの代表的なスナップショットを使用して、サンプル分析を作成します。 次のセクションでは、 分析の主な結果、コストの変動の 原因 、およびユーザーがパフォーマンスを損なうことなく 取り込まれた GB あたりのコストを最適化 する方法について説明します。
注
- この記事のすべてのコスト数値には定価が表示され、割引やコミットメントベースの節約は含まれません。
- この例の分析では、GB あたりのコストは サンプル コスト ユニット (SKU) で表されます。各 SCU は一般的なコスト単位 (たとえば、1 US セント) を表します。
- 定価とその計算方法については、 Azure Data Explorer 料金計算ツールを参照してください。
GB 単位での取り込みコスト分析
次のグラフは、元のサイズ (Y 軸) で 取り込まれた 1 日の GB の 中央値と、各コスト グループの取り込まれた GB あたりの中央値 (X 軸) を示しています。 バブル サイズは、サービスに取り込まれた合計データのグループの共有を表します。
取り込まれる GB あたりのコストはクラスターによって異なりますが、いくつかのパターンが目立ちます。
ほとんどのデータ (>75%) は、 GB あたり 2 から 10 個の SKU ( 割引前) のコストで取り込まれます。
データのうち 5% 未満の部分 が、 GB あたり 2 SCU 未満で取り込まれます。
同じ使用カテゴリ (または "バブル" 内) でも、大きなバリエーションが表示されます。 たとえば、最大のバブルでは、1 つのクラスターが 1 GB あたり 2 つの SKU で取り込まれるのに対し、もう 1 つは GB あたり 10 SKU に達します。 これは 5 倍の違いです。 次のセクションでは、このバリエーションの主な理由について説明します。
GB あたりのコストが高いクラスターは一般的な方法が少なく、通常はインジェスト ボリュームが少なくなります。 一般に、データ ボリュームが小さいと、GB あたりのコストが高くなります。
Von Bedeutung
バブル グラフは、取り込まれた GB あたりのコストがクラスターによって異なっていることを示しています。 このバリエーションは、良い習慣や悪い習慣を示すわけではありません。 これは、サービスのさまざまなシナリオ、構成、および使用パターンを反映しています。
たとえば、1 つのクラスターがコンプライアンスのためにデータを保持する時間が長くなり、ストレージ コストが増加する場合があります。 もう 1 つは、インジェスト中にデータを処理する更新ポリシーを使用して、コンピューティング使用量を高める場合があります。 これらのシナリオは、特定の目標に合わせた意図的な設計の選択肢であり、GB あたりのコストに自然に影響します。
GBあたりの取り込みコストを決定する要因は何か
これらの重要な要因は、クラスターごとに取り込まれた GB あたりのコストの変動の背後にある。
ストレージ期間: データの格納時間が長いほど、コストが高くなります。 保持ポリシーを参照してください。
CPU 使用率が高い: 大量のクエリ、データ処理、変換などのアクションにより、CPU 使用率が高くなります。
キャッシュ設定: より多くのデータをキャッシュするとパフォーマンスが向上しますが、コストが増加する可能性があります。 キャッシュ ポリシーを参照してください。
コールド データの使用: コールド データにアクセスするクエリは、読み取りトランザクションをトリガーし、コストを増やします。 ホット キャッシュとコールド キャッシュを参照してください。
データ変換と最適化: 更新ポリシー、具体化されたビュー、パーティション分割などの機能は CPU リソースを消費し、コストを上げることができます。 更新ポリシー、具体化されたビュー、およびパーティションを参照してください。
インジェストボリューム:クラスターは、より高いインジェストボリュームでよりコスト効率の高い動作をします。
ストリーミングインジェストとキューインジェスト: ユース ケースに応じて、それぞれ異なるコスト プロファイルがあります。 ストリーミングとキューを参照。
スキーマ設計: 多数の列を持つワイド テーブルでは、より多くのコンピューティング リソースとストレージ リソースが必要になり、コストが高くなります。
高度な機能: フォロワー、プライベート エンドポイント、Python サンドボックスなどのオプションは、より多くのリソースを消費し、コストを増やすことができます。
データ パイプラインの選択: 一部のインジェスト パスのコストは低くなります。 たとえば、 Event Grid のインジェストは通常、 Event Hubs よりも低コストです。
自動スケール: 多くの場合、自動スケーリングのないクラスターでは、需要に基づいてサイズが調整されないため、コストが高くなります。
これらの要因のほとんどは、パフォーマンスとコストの両方を最適化するように構成できます。
主要なコスト 要因を詳しく見る
このセクションでは、Azure Data Explorer に取り込まれた GB あたりのコストに影響を与える主な要因について説明し、これらのコストを管理および最適化する方法に関する分析情報を提供します。
コストに対するデータ保持の影響
ADX では、取り込まれたデータはすべて永続ストレージに格納されます。 各テーブルと具体化されたビューには、データの保持期間を定義する 保持ポリシー があります。 データが保持される時間が長いほど、Azure Storage の価格に基づいてコストが高くなります。 コンプライアンスなどの長期的なストレージが必要な場合は、継続的なストレージコストが含まれるため、取り込まれた GB あたりのコストが増加します。
クラスターによって報告されるエクステント サイズに加えて、次の 2 つの追加コスト ドライバーがあります。
- 保持バッファー: 偶発的なデータ損失から保護するために、既定で 7 日間の追加のデータが格納されます。
- 回復性のオーバーヘッド: 回復性設定 が有効になっているテーブル (既定) の場合、データは追加の 14 日間保持されます。 これには、マージ操作と再構築操作中に生成される中間 BLOB が含まれます。
クラスター サイズ
クラスター サイズは、クラスター内のマシン (ノード) の数です。 各マシンは、その種類 (SKU) に応じてコストを追加します。 自動スケール では、CPU 使用率に基づいてクラスター サイズが調整されるため、システムはアイドル状態または冗長なリソースを回避することでコストとパフォーマンスを最適化できます。
自動スケールでは、キャッシュされたデータが使用可能な SSD 領域内に収まるようにクラスター サイズが調整されます。 その結果、キャッシュが大きくなるとクラスター サイズが大きくなる可能性があり、CPU 使用率が低い場合は、GB あたりのコストが高くなる可能性があります。 キャッシュ サイズの最適化の詳細については、[キャッシュ] タブの [クラスター分析情報] ツールを参照してください。
多くのクエリを実行するクラスターや、具体化されたビュー、更新ポリシー、パーティション分割などの CPU 負荷の高いタスクを実行するクラスターは、クラスターをスケーリングして、GB あたりのコストを引き上げる可能性があります。 これらの機能により、クエリのパフォーマンスが大幅に向上し、クエリの CPU 使用率が低下し、全体的な効率が向上する可能性があることに注意してください。
取り込まれたデータの量
クラスターが大きくなると、ノードが追加され、合計コストが増加します。 そのコストはすべての取り込まれたデータに分散されるため、取り込むデータが多いほど、GB あたりのコストが低くなります。
コールドデータの利用
クエリがディスクに格納されているコールド データに頻繁にアクセスすると、読み取りトランザクションが発生し、リソースが多くなり、クラスター全体のコストが増加する可能性があります。
ストリーミング インジェストとキューによるインジェスト
各インジェスト方法には異なるコスト、待機時間、機能の特性があるため、それぞれ異なるシナリオに適しています。 コストの高いストリーミング インジェスト は、トリクリング データを含む多数の小さなテーブルを取り込むと低コストになりますが、 キューに置かれたインジェスト は大規模なテーブルの方がコスト効率が高くなります。
ヒント
取り込まれた GB あたりのコストを最適化する
主要なコスト ドライバーの構成を確認して、クラスターのニーズとサービス要件に合わせて効率を高めます。 具体的には次のとおりです。
- コールド データに対するクエリを最小限に抑えて、読み取りトランザクションを減らします。
- 自動スケーリングを有効にして、必要に応じてクラスター のサイズを動的に一致させます。