中に誰かいるのか？ 家には誰かいるのか？ アプリケーション監視について考えると、Pink Floydの「Comfortably Numb」のこの一節を思い出します。奇妙に聞こえるかもしれませんが、少しお付き合いください。ビジネスニーズを満たすセキュアなアプリケーションを迅速に提供するにはさまざまな配慮が必要であり、ネットワークやアプリケーションポートフォリオには多くの潜在的な問題箇所が生じます。さらに、代表的なものだけでもSaaS、クラウド、オンプレミス、ハイブリッドなど、導入オプションはますます多様化しています。その結果、各問題箇所には、障害、設定ミス、攻撃ベクトル化の可能性がある領域が存在し、それぞれ影響範囲と根本原因も異なります。アプリケーションとネットワークを責任を持って管理するには、ネットワークインフラストラクチャ内でトラフィックがどのように流れているかを俯瞰的に把握する必要があります。では、アプリケーションがビジネス機能に不可欠な場合、このリスクをどのように管理すればよいのでしょうか。どのようにアプリケーションの可用性を把握し、ユーザーがアプリケーションにアクセスする際の体験を理解すればよいのでしょうか。そもそも、アプリケーションが本当にそこに存在することを、どうすれば確認できるのでしょうか。
アプリケーションの監視は、アプリケーションのセキュリティと配信戦略を成功させるうえで極めて重要です。トラフィックがどのようにアプリケーションに到達できるかを把握することで、ユーザーに影響する問題へと発展する前に対処するための知見が深まるからです。昨年のアプリケーション戦略の現状レポートに関するF5の調査では、約3分の1の企業がアプリケーションパフォーマンスのベースラインを確立していませんでした。エンドユーザーより先にアプリケーションの問題や停止を検知できる企業の割合は、さらに低くなっています。また、40%のモバイルユーザーが、アプリケーションで一度でも不快な体験をすると競合他社に乗り換えるという事実を踏まえると、企業にとってアプリケーションの健全性を監視することがいかに重要になり得るかが分かります。ここで重要なのは、BIG-IP Local Traffic Managerの（LTM）ヘルスモニターがアプリケーションの可用性を確認する一方、パフォーマンスモニターはパフォーマンスと負荷を確認するという点です。ただし、このアプリケーション監視のアプローチは、多くの点で、クライアントから見たアプリケーションの動作をより現実に即して把握できます。
それでは、BIG-IP LTMがアプリケーションの監視に役立つ3つの方法をご紹介します。
シンプルモニタリング – その名のとおり、シンプルモニタリングは簡易的な監視です。この監視方法では、基本的に「そこに何か存在するか」を確認し、LTMノード、BIG-IP DNSサーバー、仮想サーバー、プール、プールメンバー、またはリンクのステータスが「up」か「down」かのみを判定します。シンプルモニターには、Gateway ICMP、ICMP、TCP_ECHOの3種類があり、プールメンバーや、ノード上の個々のプロトコル、サービス、アプリケーションではなく、ノード自体のみを監視します。
別の言い方をすると：友達とプールで「マルコ・ポーロ」をするようなものです。1人が「マルコ」と叫ぶと、ほかのメンバーが「ポーロ」と答えます。プールにいることは分かりますが、それ以上のことはほとんど分かりません。
パッシブモニタリング – パッシブモニタリングでは、クライアントリクエストの処理の一環として、一定期間内に試行するデータリクエストまたは接続リクエストの回数など、管理者が定義したパラメーターに基づいてプールメンバーの健全性を確認します。指定期間内にその回数の試行を行ってもサーバーに接続できない、応答を受信できない、または不正な応答を受信した場合、システムはそのプールメンバーを「ダウン」としてマークします。
この方法では、クライアントのリクエストとサーバーのレスポンス以外に追加のネットワークトラフィックは発生しません。また、ネットワークトラフィックがある場合は、プールメンバーを迅速に「down」としてマークできます。パッシブモニターは実質的にクライアントのリクエストに便乗するため、特定のレスポンスを確認できず、プールメンバーを「up」としてマークするまでに時間がかかることがあります。
別の言い方をすると、小学校の廊下を見回る係のようなものです。ほかの児童が廊下を通る様子を見守り、教室にたどり着けたかどうかを報告します。ただし、報告するのはトラフィックがある場合に限られます。
アクティブ監視 – アプリケーションとの間のトラフィックについて、単に「何か存在するか」だけでなく、その状態を把握する必要がある場合、このタイプのモニターは定期的にステータスチェックを実行します。指定した時間内に応答がない場合や、ノードのステータスがパフォーマンス低下を示している場合、BIG-IPはトラフィックを別のプールメンバーまたはノードにリダイレクトできます。また、アプリケーションサーバーに対するヘルスチェックとしてユーザーセッションをシミュレートし、HTTPヘルスチェックでアプリケーションを監視して、サーバーから特定の応答が返されるかどうかを確認することもできます。
アクティブモニターは、クライアントのリクエストとサーバーのレスポンスに加えてネットワークトラフィックを生成するため、プールメンバーを「ダウン」と判定するまでに時間がかかる場合があります。トラフィックが増えるほど、遅延が発生する可能性も高まります。
別の言い方をすると：交通状況を確認するために、実際に車で道路を走るようなものです。交通の流れや渋滞が発生している可能性のある場所を詳しく把握できますが、その車自体が監視対象の交通量を増やすことになります。
速度、エンジン温度、燃料消費量を確認できない車を運転したいとは思わないでしょう。同様に、ユーザーが良好な体験を得られるかどうかに多くがかかっている中で、アクセス状況を監視せずにビジネスクリティカルなアプリケーションを提供するべきではありません。アプリケーションに「誰かいますか？」と問いかけることを忘れないでください。
BIG-IPの監視機能について詳しくは、以下のリソースをご覧いただくか、F5のアカウントチームにお問い合わせください。BIG-IPのアプリケーションヘルスモニターをお客さま固有のユースケースにどのように適用できるかをご案内します。
関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。