Related pages:

このページでは、AppDynamics の稼働環境へのデプロイに関連するタスクを紹介します。これには、ホストの準備とコントローラのインストールが含まれます。

本番環境でコントローラをホストするマシンのシステムリソースで、予測されるワークロードに対応できる必要があります。

デプロイ概要

通常、AppDynamics をテストまたは評価設定にインストールする場合、システム要件が確認され、ホストが準備されてから、コントローラのインストールが実行されます。「コントローラホストの準備」および「Enterprise Console を使用したコントローラのインストール」を参照してください。  

コントローラをその実稼働運用環境にデプロイすると、通常は追加の要件および考慮事項が発生します。運用環境デプロイプランでは、安全性、可用性、スケーラビリティ、パフォーマンスすべてが重要な役割を果たします。次のセクションでは、コントローラのデプロイに関連するタスクが一覧にされています。 

デプロイタスク

個別の要件と環境によって、デプロイタスクには以下が含まれる場合があります。

  • 対象のシステムが、コントローラの予測されるワークロードに対して コントローラシステム要件 を満たしていることを確認する。 
  • コントローラの高可用性を実装して、コントローラサーバーで障害が発生してもサービスを確実に継続させる。   
  • ネットワーク環境を構成する。リバースプロキシを使用してコントローラをデプロイする場合、コントローラトラフィックのパススルーを構成する。デプロイ環境については、他のネットワーク要件も参照。 
  • 環境のセキュリティ要件を実装する。クライアントが HTTPS によりコントローラに接続している場合は、コントローラ上にカスタム SSL サーバー証明書をインストールする。  
  • コントローラとプラットフォームでビルトイン システム アカウントのパスワード管理戦略を生成する。  
  • 対象の環境のコントローラに対して、メールサーバーが適切に構成されていることを確認し、アラート戦略を定義する。
  • バックアップ戦略を工夫する。通常のバックアップ戦略は、頻繁に行われる部分的なバックアップと断続的なフルバックアップで構成されている。
  • 構成メンテナンスとエンハンスメント戦略を計画する。構成の変更は、重要ではない環境でステージングし、徹底的なテストを行った後でのみ実稼働環境にロールオーバーする。AppDynamics UI および REST API には、さまざまなコンテキストから構成設定をエクスポートおよびインポートする機能が備わっている。   
  • アプリエージェントのデプロイは、特に監視されているシステムを定期的に停止し、新しいシステムを立ち上げる動的な環境では、継続的なタスクであることが多くなる。管理された環境で多数のアプリエージェントをデプロイするための基本戦略は 2 つある。
    1. デプロイアプリケーションサーバー内のアプリケーションのエージェントを個別にデプロイする。この方法なら、アプリケーションの再デプロイによってエージェントのデプロイが上書きされなくなる。
    2. AppDynamicsエージェントのデプロイをアプリケーションのデプロイに統合する。この細かなアプローチを行うには、既存のアプリケーションデプロイの自動化スクリプトを変更する必要がある。
    詳しくは、以下を参照。

ネットワーク要件

コントローラの展開では、ネットワークのファイアウォールやロードバランサなど、既存のネットワークコンポーネントの構成変更が必要になることがよくあります。コントローラがロードバランサまたはリバースプロキシの背後に存在する場合、コントローラのためにトラフィック転送を設定する必要があります。また、トラフィックが横断しなければならないファイアウォールまたはその他のデバイスで AppDynamics が使用するポートを開く必要があります。  

以下は、AppDynamics をデプロイする環境に関する一般的な考慮事項です。その他のネットワーク設定要件については、「AppDynamics クイックスタート」を参照してください。 

相関HTTPヘッダー

AppDynamics は、モニター対象の環境のトラフィックに singularityheader という名前のカスタムヘッダーを追加します。このヘッダーにより、AppDynamicsはティア全体でトラフィックを関連付けることができます。モニターされている階層間、または階層とコントローラ間のネットワークにあるロードバランサ、プロキシ、またはファイアウォールに AppDynamics により追加されたヘッダーが保存されていることを必ず確認してください。 

クロック管理

AppDynamicsのデプロイでイベント時間レポートの一貫性を確保するために、アプリケーションエージェントがイベント時間とコントローラ時間の同期を試みます。

そのために、5分毎にコントローラから時間を取得します。それから、コントローラの時間を自身のローカルマシンのクロックタイムと比較します。時間にずれがあれば、コントローラに報告するメトリックのタイムスタンプとの違いに基づいて、タイムスキューを適用します。

エージェントがコントローラの時間に基づいてメトリックの報告を試みているにもかかわらず、コントローラが自身の時間より先のタイムスタンプを持つメトリックを受け取った場合、コントローラはそのメトリックを拒否します。これを防ぐために、AppDynamics は監視環境全体でクロックタイムを一貫させることを推奨します。 

インストール時に作成される管理アカウント

インストールプロセスで、コントローラに対する複数のユーザーを構成する必要があります。これには、埋め込み MySQL データベースアカウント、コントローラのルートユーザーアカウント、コントローラの管理者などが含まれます。 

ユーザー名とパスワードに「 &」および「!」を使用することはできません。ユーザーアカウントがコントローラ REST API にアクセスする必要がある場合、ユーザー名における特殊文字の使用に関する追加制限が適用されることに注意してください。「テナントユーザーの作成と管理」を参照してください。  

コントローラテナンシーモードについて

ほとんどのインストール環境では、コントローラはシングルテナントモードで動作します。マルチテナントモードでは、コントローラUIのコンテキストが個別のアカウントに分割されます。各アカウントにはそれ自体のユーザーセット、それにレポートするエージェント、およびアプリケーションモニタリング構成が含まれています。 

テナントモードはインストール時に選択します。後からテナントモードをシングルテナントモードからマルチテナントモードに切り替えることができます。マルチテナントモードからシングルテナントモードに切り替えることはできません。

シングルテナントのコントローラはほとんどのインストールに適性があります。非常に大きなインストールまたは大きく異なるユーザーグループを持つインストールの場合のみ、マルチテナントが必要になる場合があります。

モード間の違いの概要は、次のとおりです。

  • マルチテナントモードの場合：
    • アカウントコントローラで複数のアカウント（テナント）を作成できる。 
    • 各アカウントが独自のユーザーとアプリケーションを持つ。 
    • コントローラのログインページに、ユーザーがログインするためのアカウントを選択する必要のある追加のフィールドがある。 
    • 基本的に、マルチテナントモードでは論理的かつ安全な方法でユーザーを分割し、アプリケーションデータへのアクセスを可能にする。 
  • シングルテナントモードの場合：
    • コントローラシステムにあるアカウント（テナント）は 1 つのみである。 
    • すべてのユーザーとアプリケーションは、この単一の組み込みアカウントの一部であるため、このモードではすべてのユーザーが監視対象の全アプリケーションにアクセスできる。
    • アカウントはコントローラUIでユーザーに公開されない。シングルテナントモードでは、ログインページのアカウントフィールドが省略されている。
    • AppDynamics では、大部分のインストールにおいてシングルテナントモードを推奨。

詳細については、「マルチテナント コントローラ アカウント」を参照してください。 

コントローラのセルフモニタリング

システムアカウントを使用すると、コントローラをセルフモニターすることができます。コントローラで顕著なパフォーマンスの問題が発生した場合は、システムアカウントにログインして、過去数時間のメモリ使用率のトレンドにアクセスして確認することができます。  

コントローラで、パス <Controller_home>/appserver/jetty/appagent/javaagent.jar にバンドルされている内部 Java エージェントのアプリケーションのみがセルフモニタリングのサポート対象です。別のパスからカスタム Java エージェントを使用している場合は、セルフモニタリングがサポートされません。

コントローラをセルフモニターするには、マシンエージェントを使用して JMX を構成する必要があります。

マシンエージェントを使用した JMX の構成

デフォルトでは、JMX モジュールはコントローラの Jetty サーバーで有効になっています。

マシンエージェントを使用してコントローラで JMX を設定するには、次の手順を実行します。

  1. コントローラを展開したサーバーにログインします。

  2. マシンエージェントとコントローラが異なるサーバーにある場合は、次のコマンドを使用して JMX リモートモジュールを有効にします。

    java -jar start.jar --add-to-start=jmx-remote
    CODE
  3. （オプション）JConsole を使用してスレッドプールを確認します。Java のモニタリングおよび管理コンソールで、次の手順を実行します。
    1. JMX を有効にしたプロセスを選択します。 
    2. MBean を選択し、com.appdynamics.serverthreadpools に移動します。
      設定されたスレッドプールが表示されます。
  4. コントローラで com.appdynamics.serverthreadpools ドメインの JMX メトリックを報告するようにマシンエージェントを構成します。
  5. コントローラを再起動します。