ホーム > PC-Webzineアーカイブ > ユーザー視点のモニタリングは経営課題

ユーザー視点のモニタリングは経営課題

ユーザー視点のモニタリングは経営課題

2022年03月30日更新

第7回 ユーザー視点のモニタリングは経営課題

インターネットを利用したサービスで覇者となった企業たちは、マイクロサービスとコンテナを活用することで、競合他社を大きく引き離す成果を挙げた。このような手法と技術を、企業に取り入れるモダナイゼーションが注目されている。それはITサービス提供力を重視する戦略的活動であり、これからの企業の発展を大きく左右するためだ。マイクロサービスはアプリケーションを単純化するのに反して、全体ではシステムを複雑化して、不安定にさせる矛盾をはらんでいる。この矛盾を解消して長所に変える策について解説する。

日本IBM テクノロジー事業本部 高良真穂

モニタリングは経営課題

 安定的なサービス提供は、利用者の信頼と支持につながる重要な要素だ。しかし、こんな経験をしたことはないだろうか。「Web画面の反応が遅く、フォームに入力してサブミットしたら、エラーが発生して、それまでの結果を失う」。そうなると、ユーザーは利用を諦め、別のサービスを探し始めるのだ。

 サービスの提供状態を、ユーザー視点でモニタリングして、クレームを受ける前に改善する。そのようなサイクルを回すサービス運用の確立は重要な経営課題だ。多くのユーザーは、品質が悪ければクレームを上げることなく、去っていくからだ。「デジタル化を推進し、外に開かれたシステムを構築して、新たな価値を創造する」とスローガンを掲げても、サービス品質という足元を固めなければ、その成功は有り得ない。

ユーザー中心のモニタリング

 この問題解決のためSRE(Site Reliability Engineering)では、サービス提供に重要なモニタリング項目として「4つのゴールデンシグナル」を提唱している。それは、(1)応答時間(Latency)(2)リクエスト量(Traffic)(3)エラー発生(Errors)(4)飽和(Saturation)だ。これだけで十分というものではなく、最も優先するべきモニタリング項目とされている。それぞれの概要は以下だ。

(1)応答時間は、ユーザーのブラウザーなどからのリクエストを受けて応答するまでの時間である。ユーザーをイライラさせないために重要な指標だ。マイクロサービスでは個々のサービスの応答時間と総合的な応答時間の両方となる。

(2)リクエスト量とは1秒当たりのリクエスト数だ。この値が大きいとCPUなどの使用量が増え、やがて応答時間が伸びるといった影響が表れる。また、日や月で周期性があるため需要予測と増強計画の策定に有用だ。

(3)エラー発生は、ユーザーのリクエストにエラーで応答した件数だ。ユーザーの心象を悪くしないために、早急な原因分析と対策は重要だ。

(4)飽和は聞き慣れない言葉だがCPUやネットワーク帯域などの使用率が100%に近づき、これ以上処理できない状態になっていないかを表す。これはリクエスト量に比例するが、急激で過度な上昇は問題の発生を意味する。

 これまでの技術では「4つのゴールデンシグナル」をモニタリングすることは、容易ではなかった。例えば(1)応答時間を計測するためには、アプリケーションの各所に、応答時間を測るためのコードを埋め込まなければならない。これは膨大な作業になる上、監視システムのベンダーから逃れられない結果になる。

 マイクロサービスは、開発期間を短縮することが目的であり、CI/CDツールを活用して随時リリースする。ところが、従来の監視システムでは、アプリケーションへの埋め込みなどの準備作業に時間を取られ、高速化の妨げとなってしまっていた。

 コンテナを推進する業界団体CNCFでは、この課題解決をクラウドネイティブ技術で推進している。

コンテナ時代の運用監視

 ほとんどのマイクロサービスは、単独で存在することはない。ほかのマイクロサービスとともに役割を果たすシステムの一部だからだ。システム内部のマイクロサービス化が進むと、複雑に絡み合い、一つのマイクロサービスで起こった問題が、連鎖的に波及することが懸念される。例えば、電車のダイヤは、相互に接続しているため、一つの路線で起きた遅延が、首都圏全体に波及するのと同じだ。鉄道ネットワークでは、多少の遅れよりも、乗客を取り残さないことに重点を置いている。一方、マイクロサービスでは、原因となるマイクロサービスを特定して問題を回避するとともに、ほかの正常な部分を継続させることが求められる。

 この課題に対して「サービスメッシュ」がある。これは「4つのゴールデンシグナル」のうち、上位三つを可視化する。これの素晴らしいところは、アプリケーションのコードに変更が必要ない点だ。具体的には、マイクロサービスを構成するアプリケーションのコンテナに、Kubernetesの技術で、自動的に特殊なプロキシー(Envoyなど)を結合させて実現する。この方法では、モニタリングのために、提供スピードを妨げるものがない。

 このプロキシーを通じて、アプリケーションの応答時間、エラー発生状況、リクエスト量を収集することができる。そして、サービスメッシュのソフトウェアによって情報が統合され、全体の状態を可視化することができるのだ。ユーザー視点では、サービス提供の入り口で応答時間などを計測するために、ユーザーのクライアントPCの性能やネットワークの影響を除いた可視化となる。

 サービスメッシュのOSSプロダクトでは、Google,IBM,Lyftが共同で開発した「Istio」が有名だ。またCNCFのスポンサーで推進する開発プロジェクトもある。「Red Hat OpenShift」を利用していれば、「OpenShift Service Mesh」と名付けられたIstioを基礎とした機能を活用可能だ。2020年にIBMのグループに加わったInstanaは、サービスメッシュより広範囲のモニタリングを提供する。

 ユーザーの信頼と支持を得るための第一歩として、ユーザー視点のモニタリングは経営課題であり、これまでは難しかったユーザー視点のモニタリングをKubernetesによって解決できることを解説した。次回は4番目のモニタリング項目に注目していきたい。

キーワードから記事を探す