概要

---

ここでは、スタンドアロンの Insights とAutomation Suite デプロイ モデルの両方について、パフォーマンスとスケーラビリティのメトリックを説明します。この情報は管理者向けです。パフォーマンスでは、ダッシュボードの読み込み時間とハードウェア要件に加え、データをバックグラウンドで取り込んで処理する方法も調査されます。

Insights が動作可能な最大規模

---

The assumption of the total events that are supported over a two year period, with the current hardware requirements is the following:

• 最大 1 億個のジョブ
• 最大 10 億件のジョブ イベント
• 最大 1 億個のキュー アイテム
• 最大 5 億個のキュー アイテム イベント
• 最大 10 億件のロボット ログ

パフォーマンス テストのデータ セット

---

パフォーマンス テストの実施に使用した構成は次のとおりです。

• 1 億個のジョブ、10 億個のジョブ イベント、10 億件のロボット ログ、1 億個のキュー アイテム、5 億個のキュー アイテム イベント。各ジョブに、10 個の関連ジョブ イベント、10 件のロボット ログ、1 つのキュー アイテム、および 5 つのキュー アイテム イベントがあります。
• 平均して、生のロボット ログのサイズは 4 KB であるのに対し、キュー アイテム ([分析]、[出力]、[固有データ] 経由のカスタム データを含む) は 9 KB です。
• 400 個のプロセスがあり、その 1 つのプロセスが 20% のデータを生成します。
• Azure SQL のディスク使用量の合計は約 5.7 TB です。

データの初期サイズ

バックフィル後のデータのサイズ (dbo 内の生のストアから列ストア読み取りにデータを移動)

🚧

重要

最適なパフォーマンスを得るために、読み取りスキーマ内のテーブルでは列ストア インデックスが使用されます。つまり、データが圧縮されるため、dbo スキーマと比べて消費サイズが少なくなります。

ハードウェア要件

Azure SQL 構成 (40 コア、200 GB のメモリ、7 TB のディスク、vCore 購入モデル - Azure SQL Database) を使用して、次のようにパフォーマンス テストを実行しました。

• Insights DB、Azure SQL Hyperscale、40 コア、0 レプリカ
• Azure SQL Hyperscale を Insights データベースとして使用し、5 TB 以上のディスクをサポートしています。
• MAX DOP の設定は 16 です:
  ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 16;
• Insights 仮想マシン、Insights 22.10、Standard D8s v4 (8 v-CPU、32 GiB メモリ)
• Looker 仮想マシン、Looker 22.10、Standard D4s v3 (4 v-CPU、16 GiB メモリ)
• Orchestrator 仮想マシン、22.10、Standard D4s v3 (4 v-CPU、16 GiB メモリ)
• Orchestrator DB 仮想マシン、Standard D8s v3 (8 v-CPU, 32 GiB メモリ)

パフォーマンス テスト

以下のパフォーマンス特性について評価を行いました。

• 「読み取りパス」のパフォーマンス: ダッシュボードが情報をレンダリングする速度。
• 「書き込みパス」のパフォーマンス: システムへのデータ取り込み速度、およびデータを処理してから使用できるようになるまでの速度。これはバックグラウンドで動作し、バッチで定期的に実行されます。このバックグラウンド処理の実行時には、サーバー リソースが消費され、「読み取りパス」のリソースが減ります。このため、取り込みまたはデータ処理の実行中はダッシュボードの読み込みが遅くなります。このテストではさらに、ロボット ログとキューからカスタム変数を設定してダッシュボードで使用できるようにしました。

Insights のバックグラウンド プロセス

Insights は、以下のバックグラウンド プロセスを SQL Server 上で実行します。

• 既定では、Orchestrator データベースから Insights データベースへの取り込みは 15 分ごとに実行されます。
• 変換パイプラインでデータを読み取りスキーマに移動し、ジョブ、キュー アイテム、ロボット ログを準備し、10 分ごとにダッシュボードで使用します。
• カスタム フィールドの設定が変更された場合、変換パイプラインは、ダッシュボードで使用されるカスタム変数をロボット ログとキューから抽出します。パフォーマンス テストでは、この変更を 6 時間ごとに行って最悪のシナリオをシミュレートします。製品の通常使用時には、カスタム フィールドの設定が変更されることはあまりありません。
  平均では、ジョブ イベント、キュー アイテム イベント、ロボット ログによって毎秒 1 ～ 10 個の新しいアイテムが生成されます (例: 毎秒 5 個の新しいキュー アイテム)。

📘

注

バックグラウンド ジョブが実行されていると、ダッシュボードの読み込み時間に影響が出る場合があります。

テンプレートの読み込み時間

テストでは、既製のテンプレートの読み込み時間を測定しました。ダッシュボードの読み込み時間を測定する際に、次の 2 つのメトリックを記録しました。

• p90 (90 パーセンタイル) の読み込み時間。ここでは、ユーザーがカスタム フィールドを再設定したことでコストのかかるバックグラウンド ジョブが開始され、サーバー リソースが消費されるような最悪の状況を考慮しています。
• 平均読み込み時間。

各ダッシュボードには複数のウィジェットがあります。一部のダッシュボードでは、ほとんどのウィジェットは外れ値のウィジェットよりも大幅に高速に読み込まれます。これは [ビジネス ROI] ダッシュボードと [ビジネス ROI (キュー)] ダッシュボードに該当します。

すべてのダッシュボードは、フィルターで指定した既定の時間で読み込まれます。

* 既定では、各ダッシュボードで処理されるのはデータ セット全体の一部のみです (例: 2 年間にわたるデータのうち過去 30 日分のみ)。各ダッシュボードで処理される行数を、既定で選択されるフィルターを使用して推定します。

** [ビジネス ROI] および [ビジネス ROI (キュー)] には低速なウィジェットが 1 つあります ([節約できた時間 (月次)] ウィジェット)。この低速なウィジェットがあるために、[ビジネス ROI] の読み込み時間は p90 で 399 秒、平均で 324 秒です。[ビジネス ROI (キュー)] は p90 で 193 秒、平均で 145 秒です。