コントローラシステム要件

このページでは、AppDynamics のデプロイ準備をサポートするため、プライベートクラウドまたはパブリッククラウドにホストされているコントローラに関するハードウェアおよびソフトウェアの要件について説明します。

注意

コントローラの要件には、Enterprise Console とイベントサービスは含まれません。これらのコンポーネントごとにメモリを準備する必要があります。

コントローラのサイズ指定情報について

デプロイは、それぞれが異なります。アプリケーションの種類、ワークロード、AppDynamics 構成などの要素が、すべて各シナリオで必要なリソースに影響する可能性があります。AppDynamics を実稼働環境にデプロイする前に要件を完全に把握できるよう、必ずステージング環境でシステムのパフォーマンスをテストしてください。 

通常、インストールの前に、ノード数に基づいてデプロイのサイズを予測するのが最も容易な方法です。たとえば、Javaでは、1つのノードが1つのJVMに対応します。ただし、コントローラに対する実際のワークロードをもっとも正確に示す指標は、メトリックの取得率です。

初期インストール後、メトリックアップロードレートを使用してコントローラのサイズ指定を確認する必要があります。そのため引き続き、モニターリング対象アプリケーション、その使用パターン、またはAppDynamics構成における変更が原因で発生するワークロードの変化について、コントローラをモニターリングする必要があります。

一般ハードウェア要件 

コントローラをインストールするマシンに適用される一般要件：

• コントローラは、専用マシンで実行する必要があります。また、実稼働コントローラも専用マシンで実行する必要があります。ここの要件は、コントローラがインストールされているマシンで、別のコントローラを含む主要なプロセスが他に実行されていないことを想定しています。 
• コントローラは、PowerPCプロセッサなどのPowerアーキテクチャプロセッサを使用するマシンではサポートされていません。コントローラは、amd64 / x86-64 アーキテクチャでサポートされています。
• コントローラホストで、システムの一時ディレクトリにおよそ 200 MB の空き容量があることを確認してください。 
• ディスクI/Oは、特に待機時間の面でコントローラのパフォーマンスに大きく影響します。詳細は、「ディスク I/O 要件」を参照してください。 

コントローラのサイズ指定

下の表は、コントローラインストールプロファイルをメトリックの取得率およびノードカウント別に示しています。前述のとおり、ノードで生成される実際のメトリックは、ノードのアプリケーションの種類やAppDynamics構成によって大きく異なる可能性があります。実稼働環境にデプロイする前に、メトリックの取得率と比較して必ずサイジングを検証してください。 

オンプレミスの一般的なサイジング

オンプレミスの Amazon Web Services（AWS）のサイジング

* 指定されたディスク容量は、コントローラで使用可能である必要があります。仕様には、オペレーティングシステム、ファイルシステムなどによるオーバーヘッドは含まれていません。

Elastic Network Interface（ENI）

ENI 番号は、2018 年 2 月 28 日に更新されました。

AWS の場合、各コントローラホストの ENI をプロビジョニングし、ENI の MAC アドレスにライセンスをリンクします。ENI の詳細については、次のリンク先にある AWS のドキュメントを参照してください。

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html。

サイズ指定に関するその他の考慮事項

以下の追加要件を確認してください。

• 大プロファイルのインストールは、ネットワーク アタッチト ストレージを使用する仮想マシンまたはシステムではサポートされていません。 
• RAM の推奨事項では、オペレーティング システム プロセスのための容量を残しています。ただし、メモリ使用量の大きい他のアプリケーションを同じマシンで実行していないことが想定されています。小またはデモプロファイルのコントローラの場合は Enterprise Console をコントローラと同じホストで実行できますが、中より大きいプロファイルまたは高可用性デプロイの場合は、これが推奨されません。Enterprise Console がコントローラと同じホストにある場合は、「Enterprise Consoleの要件」を参照してください。
• サイズ指定表に表示されているディスクサイズ指定は、メトリックのおよその消費容量を示しています。各メトリックで、1分あたり約7 MBとなっています。
• マザーボードのソケットは 2 つ以内にする必要があります。 
• .NET 環境のサイズ指定に関する情報は、「.NET 環境におけるノードカウントの計算」を参照してください。 

• エージェントカウントには、EUMまたはデータベースの可視性に関する追加の要件は反映されていません。詳細は、以下のセクションを参照してください。

ディスクI/O要件

マシンが実稼働環境でコントローラのパフォーマンス要件を満たせるかどうかを決める重要な要素となるのが、マシンのディスク I/O パフォーマンスです。 

I/O待機時間に関して、2つの要件があります。

• このディスク I/O は、コントローラに継続的に負荷がかかっている状態で、コントローラのプライマリストレージの最大書き込み待機時間が 3 ミリ秒以下になるパフォーマンスを達成する必要があります。AppDynamics では、過剰なディスク待機時間が原因で発生するコントローラの問題について、サポートを提供できません。 
• コントローラのセルフモニターリングを設定する必要があります。セルフモニターリングには、コントローラホストにおけるデータパーティションの待機時間を計測する SIM エージェントが含まれます。構成には、ダッシュボードと、最大待機時間が 3 ms を超えた場合にトリガーする正常性ルールアラートを含める必要があります。コントローラのセルフモニターリングの詳細は、AppDynamics のアカウント担当者にお問い合わせください。 

ディスクI/Oオペレーション

AppDynamicsコントローラでは、コントローラパフォーマンスに対して重要な意味を持つ2つのタイプのI/Oオペレーションが実行されます。

• MySQLインテントログは待機時間に対して非常に敏感であり、MySQLではさまざまなブロックサイズを使用して書き込みが実行されます。
• MySQL の InnoDB ストレージエンジンでは、ランダムな非同期の 16Kb 読み込みおよび書き込みを使用して、ストレージおよびキャッシュ間でデータベースページを移動します。適切にサイズ指定されたコントローラでは、多くの読み込みがいずれかのソフトウェアキャッシュから行われます。

パフォーマンスを最適化するには、RAID構成のストライプサイズが書き込みサイズと一致することが重要です。2つの書き込みサイズは、16Kb（データベース）と128Kb（ログ）です。サポートされる最小ストライプサイズを使用する必要がありますが、16 Kb よりも小さくすることはできません。ハードウェアベースのRAIDコントローラを使用している場合、これらのストライプサイズに対応していることを確認してください。ストライプサイズは、データディスクの数とストリップ/セグメント/チャンク（単一ディスクに保存されるデータ部分）を乗算することで特定できます。

SANベースストレージの制限

通常はオンボードディスクがI/O要件を満たしていても、I/O待機時間が長いためにSANベースストレージのパフォーマンスが低下する場合があります。また、AppDynamicsでは、NFSマウントされたファイルシステムの使用が推奨されていません。NFSによって待機時間や処理能力の制限が増え、コントローラのパフォーマンスが低下し、データの破損につながることもあります。同様に、基盤となるネットワークのサービス品質上の問題の影響を受けるiSCSIまたはその他のSANテクノロジーも使用しないでください。

待機時間が長いこれらのストレージテクノロジーの1つを、1分あたりの予測メトリクス処理数が1M以上のシステムにデプロイする場合、すべてのストレージアクセスに対するライトバックキャッシュとして構成されたミラーNVMeが推奨されます。このようなデバイスを構成することで、これらの環境で発生した長い待機時間の一部が解消されます。

すべてのケースで、実際のトラフィック負荷でデプロイの完全なテストを実行してから、AppDynamicsコントローラを実稼動環境に配置してください。

エンドユーザーモニターリング（EUM）の考慮事項

通常、エンドユーザーモニターリング（EUM）により、収集されるメトリックの数は増えます。そのため、EUMを使用するインストールでは、小コントローラプロファイルがサポートされていません。EUM に対しては、20 以上の高トラフィック BRUM/MRUM エージェントを実行する中プロファイルを、大プロファイルに近い指定でサイズ指定する必要があります。

具体的に、EUMは以下のようなメトリックに影響します。

• Web RUMは、1分間あたりの個別のメトリックデータポイント数を最大2万2000増やすことができます。

• モバイル RUM は、ご使用のアプリケーションへのアクセスが多い場合、1 分間あたりの個別のメトリックデータポイント数をインストゥルメント化されたアプリケーションごとに 15K から 25K 増やすことができます。実際の数は、アプリケーションが受け取るネットワークリクエストの数によって異なります。

• EUM のモニターリングはメモリを大量に消費するため、メトリックキャッシュにより多くの容量が割り当てられることがあります。

コントローラのデータベースに保存されている個別の EUM メトリック名の数は、保存された個別のデータポイントの種類より大きくなることがあります。たとえば、ユーザー全員が iOS 5 から移行したとしても、iOS 5 のメトリックのメトリック名はデータベース内に残ることがあります。メトリック名はリソースの利用に影響することはありませんが、アプリケーションごとのメトリック名に関するコントローラのデフォルト制限に対して、カウントされます。名前のデフォルト制限はブラウザ RUM で 200,000、モバイル RUM で 100,000 となります。

データベースモニターリングの考慮事項

次のガイドラインは、データベースエージェントをモニターリングしているコントローラをホストするマシンに必要な追加のディスクやRAMを判断する時に役立ちます。非常に大規模なインストールについては、AppDynamics の担当者と連携して追加の指示を受けてください。 

オンプレミスのインストールでは、コントローラとイベントサービスを実行するマシンが追加の考慮事項を満たす必要があります。データ保持期間は 10 日間です。

• 1 ～ 10 コレクタ：2 GB RAM、シングル CPU
• 10 ～ 20 コレクタ：4 GB RAM、2 CPU
• 20以上のコレクタ：8 GB RAM、4 CPU

イベントサービスに対するコントローラのサイズ指定

イベントサービスはEUM、データベースモニターリング、分析で使用されるファイルベースのストレージ機能です。データベースモニターリングは、デフォルトでコントローラに埋め込まれているイベントサービスインスタンスを使用します。必要なディスク容量は、データベースの稼働状況やモニターリングされている数によって異なります。 

冗長性やパフォーマンスの最適性を考慮し、イベントサービスは別のマシンで実行する必要があります。サイズ指定に関する考慮事項の詳細は、「イベントサービス要件」を参照してください。  

.NET環境におけるノードカウントの計算

.NETエージェントは、IISサーバーで監視されるアプリケーションの構成によってノードを動的に作成します。IISサーバーは、監視される各IISアプリケーションのインスタンスを複数作成できます。各インスタンスに、.NET エージェントがノードを作成します。たとえば、IISアプリケーションが5つのインスタンスを持っている場合、.NETエージェントは各インスタンスに1つずつ、つまり5ノード作成します。

特定のIISアプリケーションのインスタンスの最大数は、次の図で示されているように、アプリケーションプール用に構成されるワーカープロセスの数によって決まります。

図は、3つのアプリケーションプールを示しています。AppPool-1、AppPool-2、AppPool-3は次のような特徴を持っています。

• AppPool-1 と AppPool-3 のワーカープロセス（Web ガーデン）は最大 2 つで、含まれるアプリケーションはそれぞれ 2 つ（AppA、AppB）と 1 つ（AppF）です。 
• AppPool-2 はワーカープロセスが 1 つで、3 つのアプリケーションがあります。

各AppPoolのノード数を特定するには、アプリケーションの数と最大ワーカープロセス数を乗算します。これらと、Windows サービスのノードまたはスタンドアロン アプリケーション プロセスを合計します。 

この例では、9 つの AppPool ノードが作成されます。Windows サービスに対するノードを追加すると、合計 10 ノードになります。計算は以下のとおりです。

AppPool-1: 2 (applications) * 2 (max number of worker processes)  = 4
AppPool-2: 3 (applications) * 1 (max number of worker processes)  = 3
AppPool-3: 1 (application) * 2 (max number of worker processes)   = 2
Windows Service or standalone application process                 = 1
------
Total:                                                            = 10

特定の.NETアプリケーション/AppPoolのために起動されるCLRの数を確認する方法：

1. IISマネージャーを開き、そのAppPoolに割り当てられたアプリケーション数を確認する。
2. AppPool が Web ガーデンとして実行されるよう構成されているか確認する。これは、前述のように、この AppPool から来ている .NET ノードの数の乗数となる。

http://technet.microsoft.com/en-us/library/cc725601(v=ws.10).aspx も参照してください。

非同期コールモニターリングの考慮事項

小プロファイルは、大規模な非同期モニターリングを使用するインストールに対応していません。40 以上のエージェントを実行する中プロファイルでは、大規模な非同期モニターリングが追加される場合、大プロファイルに近い構成へのアップグレードが必要になる可能性があります。 

具体的には、非同期コールのモニターリングにより、1 分あたりのメトリック数が最大 2 万 3000 に増加します。