Kubernetes でエフェメラルコンテナを使用してユーザエクスペリエンスのシンセティックモニタリングを簡素化する方法
この記事は、Cisco AppDynamics のR&D およびエンジニアリング部門のシニアテクニカルリーダー Karthikeyan Ramasamy とシニアリーダー Ashish Mishra の共同執筆によるブログ「How We Simplified Synthetic User Experience Monitoring Using Ephemeral Containers in Kubernetes」
（2021/01/11）の抄訳です。
このドキュメントでは、クラウドネイティブで「Lambda に似た」 Kubernetes アーキテクチャを使用して AppDynamics が既存のシンセティック ユーザ モニタリングのワークロードをコスト効率の高い方法で大規模に実行するしくみについて説明します。
アプリケーション モニタリング戦略にはシンセティックモニタリングが不可欠です。シンセティックモニタリングは、エンドユーザや API による Web サイトや Web アプリケーションの利用状況をシミュレートすることで、パフォーマンスの問題をプロアクティブに警告する重要な役割を果たします。これにより、企業はサイトやアプリケーションを常に利用可能な状態に保ち、最適なユーザエクスペリエンスを提供することができます。
AppDynamics は現在最先端のモニタリング機能を提供していますが、機能強化にも取り組み続けています。今日のデジタル環境においては、Web サイト、モバイルアプリ、IoT デバイスなどのデジタルエクスペリエンスに対する需要がかつてないほど高まっています。そのため、今日の企業はオンライン資産への依存度をますます高めています。多くのお客様が使用量の記録的な急増に対応するために SaaS ベースのマイクロサービスへ移行する中で、AppDynamics はいくつかの理由からアーキテクチャ刷新の必要性を痛感しました。
たとえば AppDynamics のサービスを利用するには Windows ベースの実装が必要でしたが、高額なライセンス料に加え、動作の重い Windows エージェントが原因となってセキュリティとパフォーマンスの問題が生じていました。AppDynamics が管理するホステッドエージェントに対しては、フリートキャパシティ管理のニーズに対応するために社内でエージェント フリート マネージャを構築していますが、長期的に見ると、これらのコンポーネントにはメンテナンスとエンジニアリングが必要になります。
お客様のニーズに対応していくためには、社内のマイクロサービス API と一般向けマイクロサービス API の両方の高可用性（HA）を最小限のメンテナンスコストとインフラストラクチャ ライセンス料で大規模にモニタリング・測定できるようにならなければなりません。
皆様も AppDynamics エンジニアリングチームの最新プロジェクト「Simple Synth」にぜひご参加ください。
Simplified Synthetics への一大転換
Simplified Synthetics（「Simple Synth」）は、AppDynamics のソリューションと導入アーキテクチャを刷新するために AppDynamics エンジニアリングチームが取り組んでいるプロジェクトです。具体的には、Kubernetes クラスタを利用してエフェメラル Docker コンテナをスピンアップすることでこれらの目的を達成しようとしています。これらのコンテナは Linux ホスト上で実行され、Web および API をモニタリングするために短時間のワークロードを実行します。そのため、長時間にわたって稼働する Windows ベースのエージェントと、それに伴うライセンス料やその他の複雑な管理が不要になります。
AppDynamics エンジニアリングチームは、このアーキテクチャの刷新により、製品パフォーマンスの向上とメンテナンスの削減に成功し、優れたエンジニアリングを達成しています。新しい AppDynamics エージェント プラットフォームでは、5 秒という短い測定間隔で高度なモニタリングユースケースをサポートできるため、お客様のユーザエクスペリエンスを向上させることができます。
以下に、その概要をご紹介します。
「Lambda に似た」新しい Kubernetes ベースアーキテクチャ
Simple Synth アーキテクチャには、さまざまなクラウドプロバイダーやロケーションに展開された複数の Kubernetes（K8s）ベースクラスタが含まれています。各クラスタは、シンセティックチームが開発した「Heimdall」と呼ばれるローカルコンポーネントで構成されており、クラウドベースのリモートサーバコンポーネントと通信します。
Heimdall はオーケストレータとして機能して、各ロケーション/クラスタの Web/API 測定値を取得し、個別の Kubernetes ジョブとして測定を実行します（Heimdall は Kubernetes ジョブに対するフォールトトレラント機能を備えているため、AppDynamics ではポッドではなく Heimdall を採用しています）。高可用性が確保されたローカル オーケストレータ コンポーネントである Heimdall は、リアクティブな Spring Webflux をベースとして構築されています。そのため、導入に必要なフットプリントは小さくて済むにもかかわらず、拡張性に優れ、大量の処理が可能です。Heimdall は Kubernetes と通信し、ジョブ固有の情報を送信・取得し、測定コンテナのライフサイクル全体を管理します。
Heimdall は、分散データグリッドのニーズを満たすために、オープンソースの Hazelcast も使用します。高可用性が確保されたマルチノードの Heimdall サービスを利用するため、Hazelcast による効率的な分散収集が可能となっています。
エージェント側の各 Kubernetes ジョブは、「Lambda に似た」Docker イメージに基づいており、サーバからのメタデータに基づいて動的に選択されます。そのため、Simple Synth は、各ビジネスニーズの性質に基づいて、さまざまなタイプの軽量なコンテナイメージを実行できます。
たとえば Web ページ測定コンテナには Headless Chrome と Puppeteer が含まれています。これらは Web ページのパフォーマンスのインストゥルメンテ－ション機能を持つ業界初の「Visual Completion Time」トラッキングコンポーネントによって実行されます。同様に、API テストコンテナは、API のテストに必要なインストゥルメンテ－ション機能を持つ別の API テストイメージに基づいて実行されます。
Heimdall の導入環境は負荷の増大に応じ、自動スケーリングルールに基づいて拡張できるため、各ロケーションでの測定回数を増やすこともできます。AppDynamics では、オープンソースとして提供されている Kubernetes ベースの「クラスタオートスケーラ」コンポーネントを使用することで、Kubernetes クラスタに使用される基盤ノード/VM のリアクティブかつ柔軟なフリートキャパシティ管理を実現しています。つまり、オープンソースの Kubernetes ベースエコシステムを活用することで、今後は社内のフリート管理ソフトウェアが不要となります。
クラウド固有のソリューション（Lambda や Fargate など）を使わない理由
AppDynamics では、Lambda や Fargate を Amazon Web Services（AWS）のマネージドサービスとして直接利用する代わりに、上で説明した独自のエフェメラル ポッド アーキテクチャを採用しています。これにはいくつかの理由があります。
特定のクラウドに依存しない展開
Fargate をはじめとするクラウドプロバイダーベースのサービスを利用すると、特定のクラウドプロバイダーに依存しなければならなくなる可能性があります。シンセティックモニタリングでは、世界中のさまざまなクラウドプロバイダーにわたってテスト環境を提供できるため、AppDynamics のビジネスを拡大する機会が生まれます。
オンプレミス型ソリューション
単一のコードベースを使用して SaaS とオンプレミスの両方を構築できるため、開発とテストの労力を最小限に抑え、優れた運用を実現できます。これにより、高度な製品イノベーションを幅広く実現することができます。
コスト
Fargate/AWS Lambda をはじめとするクラウドベースのコンテナサービスは、一定のブロック期間（1 時間当たり、または 1 分当たりのコンテナランタイムなど）に基づいて課金する仕組みになっています。現在のシンセティックサービスで実行されている 1 日当たり約 300 万件のテストを詳しく調べたところ、70% のシンセティック モニタリング ジョブでタイムアウトが 30 秒に設定されていることがわかりました。つまり、30 秒しか必要としないジョブであっても AWS のサービスを利用すると請求額が割高になります。AWS ポータルの課金の仕組みを見てみると、Fargate/AWS Lambda ではコンテナイメージのダウンロードから課金が開始されます。イメージの一部としてシンセティックエージェントがブラウザに組み込まれる場合、時間またはデータに基づく料金が増える傾向にあります。
可用性
1 社のクラウドプロバイダーのみを利用している場合でも、クラウドプロバイダー固有のソリューションをすべてのロケーションで利用できない場合があります。たとえば Fargate は一部の AWS ロケーションでは利用できません。
その他の制限
クラウド固有のソリューションでは、ブラウザテストや API テストなどの Simple Synth ユースケース向けに CPU とメモリをきめ細かく組み合わせて提供することができません。限られた組み合わせの中で最も近い最大のサイズを選択することになるため、コスト増を招きます。
最後に、コンピューティング集約型マシンの選択という課題があります。Simple Synth の研究により、Synth ペイロードは、クロックレートが高く CPU キャッシュの大きいコンピューティング集約型マシンを使用すると格段に効率的になることがわかっています。
メリットと成果のまとめ
Simple Synth は、可用性が高く、柔軟で、特定のクラウドに依存しないシンセティック モニタリング エージェント向けのソリューションであることが実証されています。社内テストにより、AppDynamics のプラットフォームには以下のメリットがあることが明らかになっています。
- 追加設定なしに SaaS とオンプレミスの両方で導入できる
- 高頻度での測定の実行をサポートしている（エージェントのロケーションで 5 秒間隔）
- Windows からの移行が可能になり（インフラストラクチャ コストを約 45% 削減）、長時間稼働する複数の VM を使用する場合と比べて測定コンテナに必要なフットプリントが小さくなるため（後のフェーズでインフラストラクチャコストを 60 〜 70% 削減可能）、コストを最適化できる
- Lambda に似たアーキテクチャと、測定の種類（API テストやネットワークテストなど）ごとに異なる Docker イメージを使用するため、AppDynamics の新機能を迅速に導入できる
- 各測定が短時間のコンテナとして個別に実行されるため、サンドボックス機能が自然に提供される
- CPU の制御、メモリの仕様、バースト可能制限などによりモニタリングと運用が改善されるため、お客様のワークロードに適したプラットフォームを構築できる
さらに、AppDynamics が管理するホステッドエージェントとお客様が管理するオンプレミス環境の両方で、シンセティックエージェントの管理、拡張、アップグレードを行うために各分野の専門家（SME）を配置する必要がなくなります。Kubernetes の知識を持つ開発プロフェッショナルであれば、Docker ベースのイメージを使用してシンセティックエージェントを処理できるからです。
今後に向けて
上で説明した機能の多くは、業界で初めてシンセティックモニタリングに導入された機能であり、AppDynamics は将来のモニタリング ユースケースの進化にも対応することができます。「Lambda に似た」短時間の軽量コンテナを大規模に実行できる機能は、AppDynamics アーキテクチャの独自性の証しであり、カスタマーエクスペリエンスを真に変革するものと私たちは確信しています。
現在、AppDynamics エンジニアリングチームは、スポットインスタンスを使用してコストをさらに削減する計画に取り組んでいます。これにより最大 90% の割引価格が実現しますが、その一方で、測定を短時間で完了しなければならないという制約があります。シンセティック測定コンテナには短時間という特性があるため（現在の実稼働ワークロードに基づく平均タイムアウトは 30 秒）、予備のキャパシティインスタンスを用意したうえで実行することをお勧めします。終了が通知された場合は、各ノードやマシンをテイントすることで新たなコンテナのスケジューリングを回避できます。また、代替ノードをスピンアップしてフリートサイズを調整できます。
今後も AppDynamics のシンセティック モニタリング サービスの最新情報にご注目ください。
