アプリの差別化を図るにはインフラ監視だけでは不十分。UXを担保するAPMの必要性と手法とは

ご存知の通り、すでにコンシューマー向けのアプリケーションは飽和状態だ。こうした状況では、アプリケーションのユーザー体験（User Experience、以下UX）が極めて重要になる。貧弱なUXでは、機能的に不足はなくとも、ユーザーはいとも簡単に競合アプリケーションに乗り換えるからだ。逆にUXによる差別化を図れば、競合に対しリードすることも可能となる。

豊かなUXを実現することは、今やアプリケーション開発者の最大の関心事といっても差し支えないだろう。UXではユーザーインターフェース（UI）等のデザイン面が話題の中心となることがまだまだ多い。しかし、実のところその概念は広範囲にわたる。例えば、アプリケーションのレスポンスの速さや可用性といった性能的な要素も、UXに多大な影響を及ぼす。

今時のユーザーは、わざわざ我慢をしない。レスポンスに時間がかかる、あるいは、障害で使えないといったUX上の劣化が起きれば、アプリケーションの使用を簡単に諦めてアンインストールし、競合に乗り換える検討を始めることだろう。

「そこで重要になるのがアプリケーション・パフォーマンス・マネジメント、APMと呼ばれる概念です」と日本ヒューレット・パッカード株式会社（以下HPE）の飯沼宏光氏は述べる。「APMによって性能面でのUX劣化を直ちに検出し、素早い回復が可能となります」

日本ヒューレット・パッカード株式会社
ソフトウェア事業統括 プリセールス本部 アプリケーションデリバリマネジメント部シニアコンサルタント
飯沼宏光氏

APMとは、一言でいえばユーザー視点に基づくアプリケーションの性能監視の手法だ。監視といっても、CPUやネットワークといったインフラのリソース監視のようなものとは一線を画す。例えばAPMの監視方式の１つとして、ユーザーが実際に行う操作を再現して実行し、その応答にかかる時間を監視する方式がある。監視ということでは、結局のところどれも似たようなものなのではと考える向きもあるかもしれないが、従来のインフラ監視とは観点がかなり異なる。APMによる監視の特徴をまず解説しよう。

APMならUXの劣化に気づくことができる

現在のアプリケーションは、多数のインフラから構成されていることが多い。こうした状況では、個々のインフラが正常の範囲内であっても、多くの要因や競合などが積み重なることによって、レスポンスの遅延といったUX上の劣化が起きることがある。

インフラ監視上は正常範囲なので、インフラ監視だけではこうした状況に気づくことができない。しかし前述のような実際の操作を再現する方式でレスポンスを計測するAPMであれば、劣化が起きれば直ちに検出できる。もちろん各インフラの状態を知るうえでインフラ監視も欠かせないものではあるが、それだけではUXの劣化まで検出できないケースも存在しているわけだ。

APM導入前後の変化：ユーザーからの問い合わせによって問題が発覚するケースも

UXの劣化に気づけないというのは、かなり恐ろしい状況ではないだろうか。UXの劣化によってクレームになるならまだマシなほうで、ユーザーは黙って立ち去っていくことがほとんどだろう。じわじわと顧客の流出を招くことになりかねない。

また、めったに使われない機能などは、誰も使わないがゆえにその劣化に誰も気づいていないということも十分ありうる。いざ使おうと思ったときになって問題が発覚するのでは、致命的になる場合もあるだろう。緊急時や災害時に使用するものを想定してみてほしい。

こうした被害を最小限に食い止めるには、とにかくUXの劣化をできるだけ早期に検出し、リカバリまでの時間を短縮せねばならない。それにはAPMが非常に有効であることはお分かりいただけるだろう。

飯沼氏はこのように続ける。「APMはここ2、3年で導入が進んできています。なお、HPEでは10年以上前から推進しており、実績も豊富です」

なるほど、UXがビジネスを左右する以上、その劣化を自動的に素早く検出できるAPMの導入の流れは今後も加速することだろう。

APMの全体像とHPEの注力ポイント

APMの有用性を確認できたところで、いちど全体像を整理しておこう。APMにはいくつかの方式がある。その区分と該当するHPEの製品群を列挙してみると次のようになる。

今回は、数あるAPM製品群の中でも最も取り組みやすく、効果が出やすい疑似ユーザー監視のソリューションである「Business Process Monitor」と「AppPulse Active」にスポットを当ててみよう。「Business Process Monitor」と「AppPulse Active」の大きな違いは、前者はオンプレミス、後者はSaaSであるという点になる。

できることは両者ともほぼ同じだ。どちらの場合も、記録ツールを使って監視したいアプリケーションの操作を記録する。この記録をスクリプトとして保存し、監視の実行時には、スクリプトに基づいて操作を再現し、スクリプト内の任意の区間の応答時間を測定し記録する。「Business Process Monitor」はオンプレミスだけあって機能は豊富だ。ただし、DBが別途必要になるなど導入にハードルがある。スモールスタートなど、気軽に始めるにはやはりSaaSの「AppPulse Active」となるだろう。10分もあれば監視を開始できる。

開発時からの導入のすすめ

APMの必要性や製品はわかった。では実際に導入しようとなると、これが少々難しい側面があるのもまた事実だ。

一般的に監視は運用担当者の仕事の範疇だろう。しかしAPMでは、アプリケーションそのものの仕様や、性能的な要件を正しく理解するところから始めなくてはならない。監視すべきポイントが正しくないと、APMを導入したところで効果が薄くなってしまうからだ。また、コストは監視対象の数に依存するため、意味のない監視を仕掛けることは、無駄なコストが生じることにもなりかねない。

「そこで、運用担当者ではなく、開発担当者がAPMを導入することをお勧めしています。リリース前のβ版といった早い段階から導入してもいいでしょう」と飯沼氏は語る。

確かに開発側であれば、アプリケーションのどこを監視すべきかという判断を正しく、また即座に下すことができるだろう。もちろん運用側でそれができないわけではないが、開発から運用への情報伝達を経由する必要性は、どうしてもある。開発側でAPMを導入するほうが、効率の面で望ましいというわけだ。

また、リリース前から導入することで、開発者が実際のレスポンスを評価でき、フィードバックを得られる。運用フェーズにおいても即座に監視結果やトレンドを知ることができ、即応性といった面でもメリットがある。SLAを開発側が決められるようにもなるだろう。

HPEでは、機能テストのUFTや負荷テストのLoadRunnerといったテスト関連ソリューションも豊富にそろっている。こうしたツールで作成したスクリプトをそのまま使用できるため、開発担当者がスムーズにAPMを導入できる。これはHPEならではの強みとなっている。

このテストから監視へのシームレスな流れは、昨今のDevOpsの潮流にも合致する。まさにこうした取り組みが開発と運用双方をより近づける手段のひとつとなるだろう。

効率的な可用性・レスポンス監視：テストフェーズで使用したスクリプトをそのまま使用して、運用監視をシームレスに開始

様々な都合で開発担当者だけでAPMを導入することは難しい場合もあるかもしれないが、いずれにしても開発側がリーダーシップを取るのがよいだろう。冒頭で、UXはアプリケーション開発者の最大の関心事であるということを述べた。UXを担保する手段のひとつとしてAPMを考えてみても、やはり開発者が中心となって推進すべき課題といえる。