業務を妨げない“プロアクティブ”な運用がキモ 収益向上のカギを握る、APMという“経営課題” |
企業のITインフラが年々複雑化、大規模化していく一方で、多くの企業が懸念しているのがシステムに問題が起こった際の業務への影響だ。むろん、従来もCPU使用率やメモリ消費量などを監視し、システムの安定稼働を図ってきた。だが、企業にとって重要なのは「システムの安定稼働」ではなく、「業務の遂行」「サービスの提供」である。これを受けて、業務やサービス提供を直接支えるアプリケーションのパフォーマンス管理にフォーカスしたAPMという概念が、いまにわかに注目を集めている。では従来の運用管理と何が違うのか、具体的に紹介しよう。 |
ユーザー視点でアプリケーションのパフォーマンスを管理 | ||
ビジネスにますますの効率とスピードが求められている近年、業務を支えるITシステムも進化し、大規模化、複雑化の一途をたどっている。特に昨今は、多くの企業が仮想化技術を導入しているほか、SaaS、PaaSといったクラウドサービスの利用にも乗り出しつつある。これによって物理環境と仮想環境、またオンプレミスとクラウド環境が混在し、システムインフラのアーキテクチャが複雑化する傾向は一層加速している。
このようにシステム環境が大規模化、複雑化している中で、多くの企業が危惧しているのが、ITシステムに問題が発生した際の対応だ。ITシステムと業務が密接に結びついている昨今、システムに支障が出れば、即、機会損失や顧客満足度、信頼性の低下につながる。よって、ITシステムに問題が起きた、あるいはその兆候をつかんだ際には、アプリケーションをはじめ、それを支えるサーバ、データベース、ネットワークなど、複雑に絡み合った各システム構成要素の「どこに、どんな問題があるのか?」、即座に原因を突き止めて解決し、業務への影響を最小限に抑えなければならない。
こうした状況を受けて、いまにわかに注目を集めているのがAPM(アプリケーション・パフォーマンス・マネジメント)という概念だ。企業によって受け止め方が異なるなど、統一された定義があるわけではないが、ひと言で言えば、「アプリケーションのレスポンスタイムやエラーログなどを監視し、その適正なパフォーマンスを担保する取り組み」を指す。“運用管理者の視点”を軸とした従来の運用管理とは異なり、“エンドユーザーの視点”を中心に運用管理する点が大きな特徴だ。
というのも、従来の運用管理は「サーバ、アプリケーションなど、各システム構成要素を、それぞれ個別に監視」するため、 個別の障害には対応できるが、それらが互いに影響を与え合った「全体的なパフォーマンスの低下」 には十分な対応ができていなかった。それに対してAPMでは、ユーザー視点に立ち、サービスを支える全システム構成要素をトータルで監視し、「アプリケーションを快適に使えるように」運用管理する。すなわち、「円滑に業務を遂行できる/サービスを提供できる」環境を整えるのである。
例えば、Webアプリケーションにおいて、あるアクションを起こすボタンをクリックしてもレスポンスが遅い、あるいは返ってこない場合がある。そこでアプリケーションやサーバ、ネットワークなどの稼働状況を調べてみるが、各構成要素とも正常に稼働している、といったことは往々にしてある。
しかし、いくら各構成要素が正常に稼働していようが、アプリケーションのレスポンスの遅れは、業務にさまざまな悪影響を与える。例えば、Webアプリケーションの提供機能がeコマースの決済機能なら、決済完了までに何分もかかっていると、その間に短気な消費者は決済をあきらめてサイトを離れていってしまう可能性が高い。銀行のWebバンキングであれば、レスポンスの低下は信頼失墜につながりかねない。
そもそも企業がITシステムを使う目的とは、「ITシステムを正常に稼働させること」ではなく、業務を効率的に遂行し「社業を発展させること」にある。そこで、そうした「本来の目的」を確実に達成するために、「エンドユーザーが円滑に業務を遂行できる、あるいはサービスを利用できる状態を確保すること」にフォーカスしたのがAPMという概念であり、この点が従来の「システム監視」を主軸とした、“ユーザー不在の運用管理”との大きな違いなのだ。
問題を未然に防ぐ“プロアクティブな運用管理”を目指そう | ||
では、APMには具体的にどのような取り組みが求められるのだろうか。これは「システムは正常に稼働しているのに、アプリケーションのレスポンスが悪い」場合、従来はどう対応してきたかを思い返すと理解しやすい。
まず、ユーザーからクレームを受けた情報システム部門のサポート担当者は、アプリケーション、サーバ、ネットワークなどの各運用管理担当者に状況を聞いて回るはずだ。しかし異常は見つからない。また、各担当者の担当範囲はサイロ化しているうえ、ミッションはあくまで“システムの監視”にある。そのため、担当範囲外の情報――例えば、ほかのシステム構成要素の知識や稼働状況、自分の担当システムが担っているビジネストランザクションの知識――などは持ち合わせていないケースが多い。従って、問題原因を追求するためには、すべての管理者が集まってアプリケーションのエラーログを見ながら、少しずつ原因を絞り込んでいくほかない。
むろん、そうした対応は時間も手間もかかる。そして前述のように、そのアプリケーションがeコマースの決済機能を提供するものであれば、レスポンスが遅れていると、多くの顧客が決済をあきらめてサイトを離れてしまう。つまり、対応に時間がかかるほど、加速度的に機会損失は拡大し、サービスの信頼性は低下していく。では、こうした状況を回避するためにはどんな取り組みが必要なのか? 一般的には次の5つがポイントになる。
1つ目は、ユーザー視点でアプリケーションのパフォーマンスを測れるSLAを設定すること。具体的には「あるべきレスポンスタイム」を定め、常にサービスレベルを監視する。これにより、ユーザーからクレームが入る以前に異常を検知し、問題解決に乗り出せる。また、「遅い」という事象を「レスポンスに○秒かかっている」といった明確な数値データに置き換えられるため、問題解決の手掛かりとすることができる。
他社が提供しているWebサービスを、自社のサービスとマッシュアップする際も、WebサービスのSLAをきちんと定めておく。例えば、Webバンキングの機能の一部を、他社のWebサービスに頼っている場合、そのレスポンスの遅れは自社の信頼性の悪化につながる。しかし「レスポンスタイム」や「万一、レスポンスに遅れが生じた際の対応手順、対応時間」などを明確に取り決めておけば、一定のサービスレベルを担保できるほか、万一の際も顧客に対応状況を説明することで、自社の信頼性も守ることができる。
2つ目は各アプリケーションの業務上の重要度と、レスポンスの遅滞が業務にどのような影響を与えるかを分析しておくこと。そうすれば、複数のアプリケーションでサービスレベルが悪化しても、対応の優先順位を付けられるため、業務への影響を最小限に抑えられる。
3つ目は、「一連のビジネストランザクションに沿って、各システム構成要素がどう連携しているのか」を明確化しておくこと。ビジネスの視点でITシステム を俯瞰(ふかん)できれば、問題発生時の原因究明や対応の優先順位付けの有効な手掛かりとなる。
4つ目は、アプリケーションとそれを支える各システム構成要素をひも付けて稼働状況を監視すること。例えば「アプリケーションのレスポンスタイムが○秒遅れているとき、サーバAのCPU使用率は○%になっている」「アプリケーションから○○というエラーログが出たとき、データベースの稼働状況はこうなっている」といった情報を把握する。さらに、そうした情報を各管理者間で共有する体制を築く。これが、どの構成要素がレスポンス低下のボトルネックになっているかを把握する重要な手掛かりとなるとともに、担当範囲のサイロ化の弊害を防ぎ、より迅速な問題解決を可能にする。
最後は、アプリケーションを支えている各システム構成要素のパフォーマンスを常に監視しておき、アプリケーションのサービスレベル低下を未然に防ぐことだ。その際、「アプリケーションには影響を与えないが、システムの安定稼働を図るうえでは何らかの対策を施した方が良いレベル」と「アプリケーションの稼働に影響が出るレベル」という2段階のしきい値を設けておき、極力、前者のレベルに至った段階で対策を施す。
そして最も重要なのは、以上5つのポイントの共通点だ。そう、すべて“早めの問題解決”に寄与するものなのである。つまり、従来の運用管理が、業務に影響が出てから対処する“リアクティブ”な対応だったのに対し、APMでは業務への影響を未然に防ぐ“プロアクティブ”な運用を狙うのである。この「業務を妨げないアプリケーション運用」こそが、APM最大のキモなのだ。
アプリケーションは社業の柱。人やSIer頼みの問題ではない | ||
ただ、「APM」ほどシステマティックではないにせよ、アプリケーションのパフォーマンス改善自体は、どの企業も必要に応じて取り組んできたことであるし、APMという概念も、統一された定義こそないものの、実は2000年代初頭から存在している。ではなぜここに来て、あらためてAPMが注目され始めたのだろうか。
1つは冒頭で簡単に述べたように、年々システムが複雑化し、問題個所の特定が困難になっているためだろう。むろん、問題が起こっても関係者間で協議することで対処は可能であるし、中には社内システムのことなら何でも知っており、レスポンス低下のボトルネックを瞬時に言い当ててしまうような“スーパーマン”を擁している企業もあるだろう。
しかし現在、企業においては、複数のシステム構成要素が連携してサービスを提供するWebアプリケーションが主流になっているほか、SOAや仮想化技術、また、SaaS、PaaSなどのクラウドサービスの活用も進んでいる。このようにさまざまな要素が入り組んだ複雑なシステム環境にあるいま、人の“知恵”や“経験”だけで、常に確実・迅速に問題個所を見抜き、解決することはほぼ不可能に近くなりつつある。そうした状況には今後、一層拍車が掛かるだろう。そうした中で、アプリケーションのパフォーマンスを“確実かつ安定的に”担保するためには、それなりの「方法論」や「体制」が必要だと、あらためて認識され始めたのではないだろうか。
もう1つは、やはりビジネスの競争優位を獲得するためだろう。いまやBtoB、BtoC問わず、ほとんどの業務やサービス提供をITシステムに頼っている。中でもWebバンキングやオンライントレードなどのサービスを提供する銀行や保険・証券、またインターネット通販など、アプリケーションの提供サービスが収益に直結している業態の企業ほど、APMは必須の取り組みとなってきている。
特に、市場競争が激化している近年、機会損失の防止、信頼性担保などは、もはや“土俵に上がるための前提条件”であり、「いかに快適にサービスを提供できるか」「どんなときも確実に業務を遂行できるか」が勝負のポイントとなっている。すなわち、アプリケーションのパフォーマンスを“プロアクティブ”に監視し、確実かつ安定的に武器として生かせるか否かが、社業発展の大きなカギを握っているのである。
つまり、APMとはIT部門だけの問題でも、属人的な対応で済ますべき問題でもなければ、“SIerに何とかしてもらう”ような問題でもない。あくまで自社が主体となって、ユーザー部門やステークホルダーの声を聞きながら、しかるべき方法論と体制に基づいて、システマティックかつ継続的に取り組むべき“経営課題”といえるのである。
まずは、自社にどんなアプリケーションがあり、どんな業務やサービスを担っているのか、確認してみてはいかがだろうか。そのうえで、何かあった際の業務への影響を考えれば、APMの重要性を実感として理解できるはずである。
ソリューションFLASH Pick UP! |
||
|
提供:日本CA株式会社
企画:アイティメディア営業企画
制作:@IT情報マネジメント編集部
掲載内容有効期限:2010年07月31日
ソリューションFLASH Pick UP!
CA Wily Introscope
日本CA
ビジネスの成長やニーズの多様化に対応するにつれて、低下していくWebサイトのレスポンス。その根本原因を突き止めようと、各システム管理者の間を聞いて回っても、誰もが「うちの責任じゃない」と言う。この問題は、そもそも“運用管理の視点”に原因があるのだ。システム要素単位にぶつ切りするのではなく、そこに1本横串を刺して、俯瞰的な、まさに“利用者の目線”で性能を把握することが重要なのだ。これからはこの利用者目線の発想を持たないと、“アクセスされないWebサイト”の道をひた走ることになるかもしれない。
ホワイトペーパーダウンロード
責任問題を終結に導く――プロアクティブなアプリケーションパフォーマンス管理の第一歩
アプリケーション性能問題に対し、部門を超えて責任が追及される場合、アプリケーションのプロジェクトリーダーはアプリケーションの障害を引き起こしたとして互いに非難し合うグループ間の仲裁に追われることが多い。こんな事態を招かないようにするには……。