On this page:

Related pages:

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

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

デプロイ概要

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

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

デプロイタスク

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

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

ネットワーク要件

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

以下は、AppDynamics をデプロイする環境に関する一般的な考慮事項です。他のネットワーク構成要件については、「2020-05-12_18-16-01_AppDynamics Quick Start」を参照してください。 

相関HTTPヘッダー

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

クロック管理

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

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

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

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

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

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

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

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

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

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

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

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

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