Azure Data Explorer を使用して高いコンカレンシーを実現するために最適化する

  • [アーティクル]

大規模なユーザーベースのシナリオでは、アプリケーションは低遅延かつ高スループットで、多くの要求を同時に処理するため、コンカレンシーの高いアプリケーションが必要です。

ユース ケースには、大規模な監視とアラートのダッシュボードが含まれます。 例として、Azure Monitor、Azure Time Series Insights、Playfab などの Microsoft 製品やサービスなどが含まれています。 これらサービスはすべて、コンカレンシーの高いワークロードを提供するために Azure Data Explorer を使用しています。 Azure Data Explorer は、アプリケーション、Web サイト、IoT デバイスなどからの大量のデータ ストリーミングをリアルタイムに分析するための、高速かつフル マネージドのビッグ データ分析サービスです。

Note

クラスターで同時に実行できるクエリの実際の数は、クラスター SKU、データ ボリューム、クエリの複雑さ、使用パターンなどの要因によって異なります。

コンカレンシーの高いアプリケーションを設定するには、次のようにバックエンド アーキテクチャを設計します。

この記事では、上記の各項目について、最適かつ費用対効果の高い方法で高いコンカレンシーを実現するために実装できる推奨事項を紹介します。 これらの機能は単独で使用することも、組み合わせて使用することもできます。

データの最適化

コンカレンシーを高めるには、クエリによって消費される CPU リソースの量を最小限に抑える必要があります。 次のいずれかまたはすべての方法を使用できます。

テーブル スキーマ設計のベスト プラクティスを使用する

テーブル スキーマ設計に関する次の推奨事項を使用して、使用される CPU リソースを最小限に抑えます。

  • ID 列は、値が数値であるかどうかに関係なく、文字列データ型として定義する必要があります。 文字列列のインデックス作成は、数値列よりも高度であり、フィルター処理のパフォーマンスが向上します。
  • 列のデータ型を、これらの列に格納されている実際のデータに最適に一致させます。 たとえば、datetime 値は文字列の列に格納しないでください。
  • 多くの列を含む大規模なスパース テーブルを避け、動的な列を使用してスパース プロパティを格納します。
  • 頻繁に使用するプロパティは、非動的データ型の独自の列に格納します。
  • 比較的大きな CPU リソースを必要とする結合を避けるために、データを非正規化します。

データのパーティション分割

データは、エクステント (データ シャード) の形式で格納され、既定では取り込み時間によってパーティション分割されます。 パーティション分割ポリシーを使用して、バックグラウンド プロセスで単一の文字列の列または単一の datetime 列に基づいてエクステントを再パーティション分割できます。 フィルター処理、集計、またはその両方を行うために大部分のクエリがパーティション キーを使用する場合、パーティション分割によってパフォーマンスが大幅に向上します。

Note

パーティション分割プロセス自体は CPU リソースを使用します。 ただし、クエリ実行時の CPU の削減量は、パーティション分割に使用される CPU の量を上回るはずです。

具体化されたビューを使用してデータを事前集計する

データを事前に集計して、クエリ実行時の CPU リソースを大幅に削減します。 シナリオの例としては、時間ビンの数を減らしてデータ ポイントを要約する、特定のレコードの最新のレコードを保持する、データセットを重複除去するなどがあります。 具体化されたビューを使用すると、ソース テーブルに対して構成が容易な集計ビューが得られます。 この機能を使用すると、これらの集計ビューを作成および管理する作業が簡略化されます。

Note

バックグラウンドの集計プロセスでは、CPU リソースが使用されます。 ただし、クエリ実行時の CPU の削減量は、集計に使用される CPU の消費量を上回るはずです。

キャッシュ ポリシーを構成する

ホット ストレージ (ディスク キャッシュとも呼ばれます) に格納されているデータでクエリが実行されるように、キャッシュ ポリシーを構成します。 コールド ストレージ (外部) のテーブルでは、限定され、慎重に設計されたシナリオだけを実行します。

リーダー/フォロワー アーキテクチャ パターンを設定する

フォロワー データベースは、同じリージョンに存在する別のクラスターのデータベースまたはデータベース内のテーブルのセットをフォローする機能です。 この機能は、Azure Data Share、Azure Resource Manager API、一連のクラスター コマンドによって公開されています。

リーダー/フォロワー パターンを使用して、さまざまなワークロードのコンピューティング リソースを設定します。 たとえば、インジェスト用のクラスター、ダッシュボードやアプリケーションに対するクエリやサービスを提供するクラスター、データ サイエンス ワークロードに対するサービスを提供するクラスターを設定します。 この場合の各ワークロードは、個別にスケーリングできる専用のコンピューティング リソースと、さまざまなキャッシュとセキュリティ構成を持つことになります。 すべてのクラスターは同じデータを使用します。リーダーはデータを書き込み、フォロワーは読み取り専用モードでそれを使用します。

Note

フォロワー データベースには、リーダーから、通常は数秒の遅延があります。 ご自身のソリューションで待機時間なしの最新のデータを必要とする場合は、このソリューションが役立つ場合があります。 リーダーおよびフォロワーからのデータを結合し、リーダーからの最新のデータとフォロワーからの残りのデータに対してクエリを実行する、フォロワー クラスターのビューを使用します。

フォロワー クラスターに対するクエリのパフォーマンスを向上させるために、prefetch extents の構成を有効にすることができます。 この構成はフォロワー データベースのデータの鮮度に影響を与える可能性があるため、慎重に使用してください。

クエリの最適化

次の方法を使用して、高いコンカレンシーを実現するためにクエリを最適化します。

クエリをできるだけ効率的に実行できるように、クエリのベスト プラクティスに従ってください。

クエリ結果のキャッシュを使用する

複数のユーザーが同じダッシュボードを同じような時間に読み込む場合、2 番目以降のユーザーのダッシュボードはキャッシュから提供できます。 この設定により、CPU をほとんど使用せずにハイ パフォーマンスを実現できます。 クエリ結果のキャッシュ機能を使用し、set ステートメントを使用してクエリ結果のキャッシュの構成をクエリと共に送信します。

Grafana には、データ ソース レベルでのクエリ結果のキャッシュの構成設定が含まれています。そのため、すべてのダッシュボードで、既定でこの設定が使用され、クエリを変更する必要はありません。

クエリの整合性の構成

既定のクエリ整合性モードは strong です。 このモードでは、"管理" ノードがクラスターのメタデータとインジェストを管理するだけでなく、クエリ プランと他のノードへの実行の委任も管理します。

コンカレンシーの高いアプリケーションでは、クエリの管理によって "管理" ノードの CPU 使用率が高くなることがありますが、他のノードのビジー状態は低くなります。 これにより、同時実行クエリの数を増やすことができないというボトルネックが発生する可能性があります。 ただし、クラスターの平均 CPU 使用率を示すクラスターの CPU レポート (Azure portal > {お使いのクラスター} > [メトリック] > [CPUメトリック]) では、このことが明らかでない場合があります。

このシナリオでは、weak 整合性モードを使用することをお勧めします。 このモードでは、より多くのノードでクエリを管理できます。これにより、同時実行クエリの数を "水平方向にスケーリング" することが可能になります。 このモードのノードは、メタデータと新しく取り込まれたされたデータのコピーを定期的に更新します。これにより、データが同期されるときに通常は 1 分未満の待機時間が発生します。 ただし、この短い待機時間は、strong 整合性モードを使用した場合に発生する可能性のあるボトルネックの状況よりも好ましいと言えます。

整合性モードは、 ワークロード グループ クエリ整合性ポリシー、 クライアント要求プロパティ、または Grafana データ ソース構成で設定できます。

クラスター ポリシーの設定

同時要求数は既定で制限されており、クラスターが過負荷にならないように要求レート制限ポリシーによって制御されます。 このポリシーは、コンカレンシーの高い状況に合わせて調整できます。 このポリシーは、厳密なテストの後にのみ、できれば運用環境に近い使用パターンやデータセットに対して調整する必要があります。 テストを行うことで、変更された値がクラスターによって確実に保持されます。 この制限は、アプリケーションのニーズに基づいて構成できます。

Azure Data Explorer クラスターの監視

クラスター リソースの正常性を監視すると、前述のセクションで提案されている機能を使用して最適化計画を作成するのに役立ちます。 Azure Monitor for Azure Data Explorer は、クラスターのパフォーマンス、操作、使用状況、エラーの包括的なビューを提供します。 クエリのパフォーマンス、同時クエリ、スロットルされたクエリ、その他のさまざまなメトリックについての分析情報を得るには、Azure portal 上の Azure Data Explorer クラスターの [監視] セクションにある [分析情報 (プレビュー)] タブをクリックします。

クラスターの監視の詳細については、「Azure Monitor for Azure Data Explorer」を参照してください。 個々のメトリックの詳細については、Azure Data Explorer メトリックに関する記事を参照してください。