イベントサービス要件

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

全般的な要件

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

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

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

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

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

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

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

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

• 「Understanding EUM and Events Service concepts」（プロファイルを作成するために必要な概念について説明します）
• 「Build the Analytics traffic profile」
• 「Size the Events Service and EUM using the profile」（「Analytics Recipe Book for on-premises configuration」も含まれています）
• 「Limit EUM and Analytics usage」（分析をオンプレミスで展開するときに分析のトレードオフを実施するルールを設定する方法について説明します）

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

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

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

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

• 平均的なログイベントのサイズ（バイト）：350
• ビジネストランザクションイベントの平均サイズ：1 KB
• ビジネストランザクションでのティア数：3

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

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

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

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

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

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

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

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

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

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

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