そこに誰かいますか? 誰か家にいますか? アプリケーション監視について考えるとき、ピンク・フロイドの「Comfortably Numb」のこの歌詞を思い出します。 奇妙に聞こえるかもしれませんが、我慢してください。 ビジネス ニーズを満たす安全なアプリケーションを迅速に提供することに関する微妙な違いにより、ネットワークとアプリケーション ポートフォリオに多くの潜在的な問題が生じます。 さらに、導入オプションの多様化(SaaS、クラウド、オンプレミス、ハイブリッドなど、一般的なものだけでも)も進み、これらのトラブル スポットにはそれぞれ、故障したり、誤った構成になったり、攻撃ベクトルになったりする可能性のある領域があり、それぞれに爆発範囲と根本原因があります。 私たちは責任あるアプリとネットワークの管理者であるため、トラフィックがネットワーク インフラストラクチャ内でどのように移動しているかを俯瞰する必要があります。 では、アプリケーションがビジネス機能にとって重要である場合、このリスクをどのように管理できるでしょうか? アプリの可用性とユーザーのアクセスエクスペリエンスをどのように把握していますか? アプリケーションがそこにあるかどうかはどうやってわかりますか?
アプリケーションを監視することは、アプリケーションのセキュリティと配信戦略を成功させる上で非常に重要です。トラフィックがアプリケーションに到達する仕組みを理解することで、ユーザーにとって問題となる前に問題に対処するための洞察が深まるからです。 昨年のアプリケーション戦略の現状レポートのために調査した企業の約 3 分の 1 には、アプリ パフォーマンスのベースラインが欠けています。 さらに少数ですが、エンドユーザーよりも先にアプリの問題や停止を検出する企業もあります。 また、モバイル ユーザーの40%が、一度アプリケーションの使用感に不満を感じると競合他社へ移行するという事実を考慮すると、企業がアプリケーションの健全性を監視することがいかに重要であるかがわかります。 ここで重要なのは、 BIG-IP Local Traffic Manager (LTM) のヘルス モニターはアプリケーションの可用性をチェックし、パフォーマンス モニターはパフォーマンスと負荷をチェックするということです。 しかし、多くの点で、アプリケーションを監視するこのアプローチにより、クライアントの観点からアプリケーションの動作をより現実的に把握できるようになります。
それでは、BIG-IP LTM がアプリケーションの監視に役立つ 3 つの方法について説明しましょう。
シンプルな監視– 名前の通り、シンプルな監視はシンプルです。 この監視方法は基本的に「何かありますか?」と尋ね、LTM ノード、BIG-IP DNS サーバー、仮想サーバー、プール、プール メンバー、またはリンクの「アップ」または「ダウン」ステータスのみを確認します。 シンプル モニターには、ゲートウェイ ICMP、ICMP、TCP_ECHO の 3 つのモニター タイプが含まれており、プール メンバー、個々のプロトコル、サービス、またはノード上のアプリケーションではなく、ノード自体のみを監視します。
別の言い方をすると: 友達と一緒にプールで「マルコポーロ」をプレイするようなものです。 一人が「マルコ」と叫ぶと、プールの残りのメンバーは「ポロ」と答えます。 彼らがプールにいることは分かっていますが、それ以上のことはあまり分かりません。
パッシブ モニタリング- クライアント要求の一部として、パッシブ モニタリングは、一定期間内に発生した試行されたデータ要求や接続要求の数など、管理者が定義したパラメータに基づいてプール メンバーの状態をチェックします。 システムが指定された時間内に指定された回数の試行を行ってもサーバーに接続できないか応答を受信できない場合、またはシステムが不正な応答を受信した場合、システムはプール メンバーを「ダウン」としてマークします。
この方法では、クライアント要求とサーバー応答以外の追加のネットワーク トラフィックは生成されず、ネットワーク トラフィックがある場合は、プール メンバーをすぐに「ダウン」としてマークできます。 パッシブ モニターは実質的にクライアント要求に便乗するため、特定の応答をチェックできず、プール メンバーを「稼働中」としてマークするのに時間がかかる場合があります。
別の言い方をすると: 小学校時代の廊下監視員みたいだ。 彼らは他の生徒が廊下を行き来するのを監視し、それらの生徒が授業に来ているかどうかを報告しますが、交通渋滞がある場合にのみ報告します。
アクティブ モニタリング- 「何かあるか?」という以上の、アプリケーションとの間のトラフィックのステータスを知る必要がある場合、このタイプのモニターは定期的にステータス チェックを送信します。 指定された期間内に応答がない場合、またはノードのステータスにパフォーマンスの低下が見られる場合、BIG-IP はトラフィックを別のプール メンバーまたはノードにリダイレクトできます。 また、アプリケーション サーバーに対するヘルス チェックとしてユーザー セッションをシミュレートし、HTTP ヘルス チェックを使用してアプリケーションを監視し、サーバーからの特定の応答をチェックすることもできます。
アクティブ モニターは、クライアント要求とサーバー応答を超えるネットワーク トラフィックを生成するため、プール メンバーを「ダウン」としてマークするのに時間がかかることがあります。トラフィックが増えると、レイテンシが大きくなる可能性があります。
別の言い方をすると: 車を運転して道路の交通状況を判断するようなものです。 交通の流れや渋滞が発生している可能性のある場所を詳しく確認できますが、これを行うと監視対象の交通量が増えます。
速度、エンジン温度、燃料消費量を監視できない状態で車を運転したいとは思わないでしょう。特に、多くのことがユーザーの良好なエクスペリエンスに左右される場合、ユーザーがどのようにアクセスできるかを監視せずに、ビジネス クリティカルなアプリケーションを提供しようとするのはなぜでしょうか。 アプリに次の質問をすることを忘れないでください: 「誰か家にいますか?」
BIG-IP の監視機能の詳細については、以下のリソースを確認するか、F5 アカウント チームに連絡して、BIG-IP アプリ ヘルス モニターを特定の使用例に適用する方法を確認してください。