このページでは、イベントサービスノードをホストするマシンでのハードウェアとソフトウェアの全般的な要件について説明します。

全般的な要件

  • 他のプラットフォーム コンポーネントと互換性のあるイベントサービスバージョンを確認します
  • プラットフォームでサポートされているサポート対象 Windows 64 ビットまたは Linux 64 ビットベースのオペレーティングシステムを使用します「プラットフォームの要件」を参照してください。

  • ソリッドステートドライブ(SSD)は、ハードディスクドライブ(HDD)に比べてパフォーマンスが大幅に優れているため、実稼働デプロイでは SSD を使用することをお勧めします。1 TB 以上のディスクサイズが理想的です。 
  • イベントサービスは、ディレクトリ構造、ユーザーアカウントプロファイル、およびハードウェアプロファイルが同一である、専用のマシンで実行する必要があります。
  • ヒープスペースの割り当てについて、AppDynamics では、利用可能な RAM の半分をイベントサービスのプロセスに割り当てることを推奨しています(7 GB~31 GB の範囲)。  
  • ご使用の環境でイベント取り込み率をテストする場合、イベントが一括処理されることを理解しておくことが重要です。1 ~ 2 分の時間で観測される取り込み率は、全体的な取り込み率を反映していないことがあります。最善の結果を得るには、より長い時間(数日以上)にわたって取り込み率を観測します。 
  • イベントサービス 4.5.2 以前では Java 8u172 が必要です。イベントサービス 23.2.0 以降では Java 17 が必要です。Java 17 は、イベントサービス 23.2.0 以降でバンドルされています。
  • アプリケーション、コントローラ、およびイベントサービスのノードでクロックの同期を保って、AppDynamics の展開全体でイベントレポートの時刻が整合するようにします。
  • イベントサービスの REST API ポート 9080 がファイアウォールでブロックされないようにする必要があります。そうしないと、Enterprise Console がリモートでイベントサービスに到達できません。

ハードウェアキャパシティとリソースプランニング

ハードウェア要件を予測する際は、まずイベントの取り込み率(トランザクション分析の場合)またはインデックス付けされるデータ量(ログ分析の場合)を決定します。これにより、必要となる分析ライセンスユニット数を判断できます。

ライセンスユニット数の要件を決定したら、イベントサービスに対して実行されるクエリの処理負荷や使用する実際のハードウェアタイプなど、ハードウェアキャパシティに影響するその他の要因を考慮することが大切です。物理サーバーは、仮想マシンより優れたパフォーマンスを発揮する傾向があります。モニタリング対象環境でのアクティビティの季節要因によるスパイクや日々のスパイクも考慮する必要があります。 

イベントとは、イベントサービスにおけるデータの基本単位です。アプリケーション パフォーマンス管理では、1 つのトランザクション分析イベントは 1 つの階層で受信された 1 つのコールに対応しています。そのため、3つのティアにまたがる1つのビジネストランザクションインスタンスに対して、3つのイベントが生成されます。アプリケーションパフォーマンス管理のメトリックでは、ビジネストランザクションインスタンスの数は、そのアプリケーション全体のコールメトリック数を反映しています。エンドユーザモニタリングでは、各ページビューは 1 つのイベントに相当し、各 Ajax リクエスト、ネットワークリクエスト、またはクラッシュレポートも同様です。 

ライセンスユニット数に基づくイベントサービスノードのサイズ指定

このセクションのデータを使用して、ハードウェア要件を計画できます。ログ分析とトランザクション分析のライセンス資格ユニット数に対応する(Amazon EC2 インスタンスタイプのコンテキストでの)推奨ハードウェア構成を示しています。ログ分析とトランザクション分析のライセンスユニットの詳細については、「ライセンスの付与および制限事項」を参照してください。 

その他のイベントサービスのサイズ情報については、次の AppDynamics コミュニティサイト記事を参照してください。

各ライセンス数に対して示されるハードウェアは、トランザクション分析とログ分析の両方のイベントの負荷が理論上一緒になった場合のハードウェアキャパシティを表しています。使用されている数字は、それぞれの負荷で実行された実際のテストから得られたもので、そこから以下の数字が推定されました。テスト条件にはクエリの負荷は含まれていないため、実稼働の分析環境を表していないことがあります。

次の表は、推奨サイズと、テストに使用したクラスタのサイズを示しています。これは、イベントサービスが7ノードに制限されているということではありません。7ノードを超えるイベントサービスを必要とする場合は、AppDynamicsアカウントの担当者に連絡して、特定の環境に適切なサイズを確認してください。

保持期間は 8、30、60、または 90 日間であり、ストレージ要件に直接影響することに注意してください。

イベントタイプAWSマシンインスタンスタイプ
i2.2xlarge(61 GB RAM、8 vCPU、1600 GB SSD)i2.4xlarge(122 GB RAM、16 vCPU、3200 GB SSD)i2.8xlarge(244 GB RAM、32 vCPU、6400 GB SSD)
1 ノード3 ノード5 ノード7 ノード1 ノード3 ノード5 ノード7 ノード1 ノード3 ノード5 ノード

トランザクション分析のライセンスユニット数

203744632241841135394120
ログ分析のライセンスユニット数71017191619324439116270

以下の項目は、上記の表のライセンスユニット数とハードウェアプロファイルのマッピングが生成されたテスト条件について説明しています。

  • ログイベントの平均サイズ(バイト単位):350
  • ビジネストランザクションイベントの平均サイズ:1 KB
  • ビジネストランザクションでのティア数:3

これらのテストは、仮想ハードウェアおよびプログラムによって生成されたワークロードに対して実施します。実際のワークロードはこれとは異なる場合があります。ハードウェアのサイズ指定要件をできるだけ正確に見積もるには、アプリケーションでのトラフィックパターンをしっかり検討し、使用する実稼働アプリケーションとユーザアクティビティに近いテスト環境でイベントサービスをテストします。

イベントサービスノードの最小サイジング

イベントサービスを設定するには、3 ノード以上が必要です。

データベースの可視性イベントサービスのサイズ指定

データベースの可視性機能では、ストレージ用にイベントサービスが使用されます。データベースの可視性の分析イベントの取り込み容量とサイズ指定プロファイルは、ログ分析のものと同じであり、Raw イベントサイズは平均で約 2 KB です。

エンドユーザーモニタリングのイベントサービスのサイズ指定

エンドユーザモニタリングには、イベントサービスにデータを送信する分析関連の機能が含まれています。

エンドユーザモニタリングでは、各ページビューは 1 つのイベントに相当し、各 Ajax リクエスト、ネットワークリクエスト、またはクラッシュレポートも同様です。各ページロードで数十個の Ajax リクエストがあることもあります。通常、EUM またはデータベースの可視性の分析イベントの取り込み容量とサイズ指定プロファイルはログ分析のものと同じであり、Raw イベントサイズは平均で約 2 KB です。

EUMのサイズ指定を計算するには、ブラウザレコード数の1日間のピーク値に12 KBを掛けます。ピーク容量に達した場合、イベントサービスはトラフィックをドロップし始めます。

次の表は、さまざまなタイプのブラウザレコードのメモリとストレージに関する詳細を示しています。デフォルトの保持期間は構成可能です。

ブラウザレコードのタイプイベント別のメモリ要件オプションデフォルトの保持期間
ベースページ、iFrame、仮想ページ1 KB/1.5 KB(セッション有効時)なし8日間
Ajaxリクエスト1 KBあり

デフォルトでは、Ajax リクエストはイベントサービスに保存されません。