この記事は、AppDynamics チームのシニアコンサルタントである Vinit Varghese によるブログ「Best Practices for Monitoring Kubernetes Cluster in Production with AppDynamics」
（2020/8/18）の抄訳です。
AppDynamics を Kubernetes（k8s）環境に導入する
ステップとは、どのようなものでしょうか。今回の記事では、最新の情報と迅速な導入に向けたベストプラクティスをご紹介します。
瞬く間にコンテナ オーケストレーションのデファクトスタンダードとなり、開発者の間で屈指の人気を集めるプラットフォームとなった Kubernetes。その理由は簡単です。Kubernetes が登場するまで、アプリケーションやサービスの展開には月単位の期間を要する場合もありました。現在では、このオープンソースのプラットフォームを利用して、物理マシンまたは仮想マシンのクラスタ上でコンテナを実行できます。オーケストレーションのプロセスは簡素化され、オンプレミスとクラウドネイティブのどちらの環境にも対応しています。
一方で、Kubernetes 環境はその性質上、きわめて動的かつスケーラブルであり、分散型の構造となっています。つまり、Kubernetes のインフラストラクチャやアプリケーションをモニタリングするには、これまでとは異なるアプローチが必要です。
AppDynamics には、Kubernetes 環境のアプリケーションとインフラストラクチャをモニタリングするための優れた手段が複数用意されています。今回のブログ記事では、常用しているモニタリング プラットフォームを最大限に活かすためのベストプラクティスについて、いくつか簡単にご紹介します。最初の Kubernetes クラスタの運用を開始して間もない場合、または開始を予定している場合に、モニタリングの導入の参考になさってください。
製品の最新情報
AppDynamics は、この 1 年の間にさまざまな新機能と機能改善が加えられ、Kubernetes 環境への導入がきわめて容易になっています。いくつか例を挙げてみましょう。
- AppDynamics クラスタエージェントを新たにリリース。クラスタレベルのメトリックを、簡単な手順で効率的に収集できます。
- エージェントレス分析をリリース（現時点では Java による実装）。スタンドアロンの分析エージェントやマシンエージェント拡張を個別に展開することなく、トランザクション分析を実行できます。
- 自動インストゥルメンテーションの機能をクラスタエージェントに追加。大規模なアプリケーションに対するアプリケーション パフォーマンス管理（APM）エージェントの展開が容易になるとともに、展開のための仕様を手動で更新する必要もなくなります。
- AppDynamics コントローラ全体にわたって、新たなユーザエクスペリエンスを実現。トランザクション、ネットワーク、ノード、ポッド、コンテナのレベルでエンティティ間をすばやく移動してメトリックを参照し、相関関係を分析して、パフォーマンス上の問題が生じている根本的な原因を特定できます。
利用を開始する
以下の例では、Google Cloud Platform 上で運用されているクラスタを使用します。
（詳細については、この記事にあるリンク先の公式ドキュメントをご覧ください。）
このクラスタは 3 つのノードで構成され、「prod」名前空間で実行されている 1 つの Java アプリケーションに数種のサービスが含まれています。
「prod」名前空間で実行されているアプリケーションを以下に示します。
ステップ 1：AppDynamics オペレータを展開する
最初のステップは、AppDynamics オペレータを展開することです。このオペレータは Kubernetes API のクライアントであり、クラスタ内のカスタムリソースのコントローラとして機能します。download.appdynamics.com からクラスタエージェントをダウンロードする際に、cluster-agent-operator.yaml をダウンロードできます。
このオペレータおよび関連するすべてのポッドの展開先は、「appdynamics」名前空間です。この名前空間はカスタマイズできます。アプリケーションが「appdynamics」以外の名前空間で実行されていることを必ず確認してください。
ステップ 2：クラスタエージェントを展開する
オペレータを運用する準備が整ったら、次のステップはクラスタエージェントの展開です。このエージェントはモニタリングを支援するもので、Kubernetes のインフラストラクチャによって、アプリケーションやビジネスのパフォーマンスがどのような影響を受けているかを把握するうえで有用です。
展開するクラスタエージェントは、クラスタごとに 1 つのみです。なお、Docker モニタリングを有効にした状態のサーバの可視性と、クラスタエージェントを同時に実行しないでください（インフラストラクチャの可視性については、次のセクションをご覧ください）。シークレットの作成など、クラスタエージェントの展開に先立って必要な作業については、こちらのドキュメントですべて取り上げています。cluster-agent.yaml は、オペレータのダウンロードに使用したものと同じディレクトリに格納されています。
数分で、コントローラへと集約されるクラスタレベルのメトリックとイベントを参照できる状態になります。
ステップ 3：インフラストラクチャの可視性を展開する
ノードレベルのハードウェアメトリックを最も簡単に取得する方法は、サーバの可視性エージェント（SIM ライセンスを使用するマシンエージェント）をクラスタの各ノードに展開することです。
この方法で進めるには、スタンドアロン マシン エージェントを DaemonSet として展開します。これにより、クラスタに配置される既存および将来のノードすべてでこのマシンエージェントポッドのコピーが確実に実行され、ハードウェアメトリックが収集されます。すべての設定項目の詳細については、Git リポジトリをご覧ください。以下に例を示します。
先ほど述べたとおり、インフラストラクチャの可視性（InfraViz）をクラスタエージェントと併用する場合は、enableDockerViz: “false” を追加します。InfraViz を展開すると同時に、この例のように、ネットワークの可視性または分析のマシンエージェント拡張および設定を有効にすることもできます。
ここまでの作業を完了すると、各ノードのハードウェアメトリックが AppDynamics コントローラに表示され始めます。
ステップ 4：自動インストゥルメンテーションを有効にする
クラスタエージェントが備える機能の中でも屈指の魅力的な機能の 1 つが、Kubernetes クラスタに展開されているアプリケーションに対して、APM エージェントを自動でインストゥルメント化できること、つまり動的に追加できることです。
現時点では Java エージェントがサポートされています。Init コンテナを利用するアプローチも考えられますが、自動インストゥルメンテーションが不可能な場合のみとすることをお勧めします。以下の仕様では、単純にクラスタエージェントをポイントし、最新の Java エージェントイメージを使用して、「prod」名前空間で実行されているポッドを自動でインストゥルメント化したうえで、そのポッドを「my-k8-app」というアプリケーション名でコントローラのレポート収集元としています。自動インストゥルメンテーションのその他の例および使用可能なすべてのオプションについては、こちらをご覧ください。
この YAML を適用し、何らかのトラフィックをアプリケーションに適用すると、アプリケーション フローマップとメトリックがコントローラに表示され始めます。
今回は、InfraViz を展開すると同時にネットワークの可視性（NetViz）も有効にしたため、ネットワークフローマップも表示されます。
前述のとおり、最新の Java エージェントはエージェントレス分析機能を備えています。したがって、コントローラの UI でトランザクション分析を有効にすると、クラスタエージェントの自動インストゥルメンテーション機能で先ほどインストゥルメント化したアプリケーションについて、イベントが収集され、表示されるようになります。
手順の概要は以上です。
Kubernetes のコンポーネントおよびリソースを対象として、状態およびキャパシティを AppDynamics でモニタリングする方法の詳細については、KubeCon + CloudNativeCon Europe 2020 Virtual で入手できるオンデマンドデモとセッションを参照してください。併せて、ウェビナー Optimize Microservices Performance with AppDynamics Cluster Agent（AppDynamics クラスタエージェントでマイクロサービスのパフォーマンスを最適化する）もご覧ください。
Authors