モダンな監視サービス Datadog で観測する UX

クラウドの利用が一般的になり、従来オンプレミスの仮想サーバー上に構築していたシステムも、オブジェクトストレージ上での静的ページの公開や、ユーザーに対してのサービス API の提供など多様な提供形態が増えつつあります。その際、従来の監視のように CPU 利用率やディスクの空き容量といったリソースの計測だけではシステム障害対応やリソースプランニングといった”守り”の運用は可能でも、ユーザーにより良いサービスを提供するという”攻め”の運用はなかなか難しい面もあるでしょう。

そこで本ブログでは、モダンなモニタリングサービスの一つとして Datadog を取り上げ User Experience(UX) を計測し、どのようにビジネス戦略に繋げられるか例を挙げながらご紹介いたします。

Datadog とは?

Datadog は、 2010年ニューヨークで創業された Datadog .Inc が提供する監視サービスとなります。

当初は、“統合データプラットフォーム”を謳っておりデータの統合・可視化に注力していましたが、徐々にサービスを拡張し続け、インフラストラクチャ監視、APM(Application Performance Monitoring)、Log 管理と監視対象の領域を拡げるとともに近年では Day2 オペレーションを見据えたセキュリティ監視、インシデント管理などさらなる成長を続けています。

本 Blog で取り上げる UX に関するサービスは 、2019 年リリースされた比較的新しいサービスとなっており Synthetics(外形監視)、RUM(Real User Monitoring) と呼ばれる機能がその対象となっています。

Datadog における UX モニタリング

Datadog では、先に述べたような Synthetics、RUM といった大きく2種類の UX に関するモニタリングサービスが存在しており、さらに Synthetics では外部から対象システムに対し実際の HTTP Request を送信、Response 内容をチェックする “API テスト”, ブラウザ上のユーザー操作をシミュレートする “ブラウザテスト”が存在しています。

API テストでは、監視対象が提供する API を実際に叩くことで、そのサービスの健全性を確認するのはもちろん、Total Response Time, DNS, Connection といった項目も計測できるため、対象の死活監視だけではなくユーザー視点でのサービスの品質などを確認することができます。

ブラウザテストでは、 Google Chrome の拡張機能を利用し監視対象の Web サービスに実際にブラウザでアクセスした上で文字列入力、クリックといったブラウザ操作を Recording 、テスト実行することができます。テスト結果では操作毎に操作結果のスクリーンショットや処理時間、それによってダウンロードされた画像・CSS・JavaScript などのリソースの一覧、それらリソースのダウンロード時間などを計測することができます。

ブラウザテストの結果

RUM では、 Datadog 社から提供される SDK をアプリケーションに組み込むことで、ユーザーとアプリケーションとのインタラクションに関する情報を収集することができます。ページ遷移単位で取得することが可能で、ページ全体の描画にかかった処理時間はもちろん、JavaScript や CSS など個々のリソースの取得にかかった時間、発生しているエラー、デバイス情報やブラウザエージェントに関する情報など多岐にわたる情報を取得します。一見すると処理時間など Synthetics と似たような情報を取得しているように見えますが RUM では実際にアクセスしているユーザーのデバイスから計測している点が大きな違いと言えるでしょう。

RUM によるページ遷移の一覧

計測された UX のビジネス活用

このように、Synthetics、RUM といった機能によって取得されたデータは、ユーザーの観点からサービスの UX を計測するのに非常に重要ですが、これらのデータを取得しただけでは、ただ膨大な監視データが増えただけで運用コストが増大してしまいます。そこでこれらの取得されたデータを分析およびビジネス活用するための一例を紹介いたします。

Datadog では、これまでにご紹介した Synthetics のテスト結果から、サービス稼働率を算出することができ、ユーザー観点のサービスレベルを確認することが可能となっています。Synthetics を設定することで ”Monitor”と呼ばれるアラートの設定が自動的に行われ Synthetics で設定された “Response Time”, “Status Code”, “ヘッダ情報”, “Body情報”といった内容のチェックによって、1つでも予期していない内容が返ってきた際はアラートを発報することが可能です(設定により複数回のリトライ設定も可能です)。SLO を定義する際はこの Monitor を選択することで簡単に現在の Synthetics のテスト結果からサービス稼働率を算出することができます。

その際の SLI(Service Level Indicator)は、 ((成功したイベント数) / (Total の試行回数)) x 100 といった計算式から算出され、7日間(1週間)、30日間(1ヶ月)、90日間(3ヶ月)といった異なるタイムフレーム毎にサービス稼働率の算出、SLO の定義をすることができます。

サービス稼働率とエラーバジェットの算出

このように現状のサービスレベルの算出、SLO の定義を行うことで、さらに計算される項目が “エラーバジェット”です。エラーバジェットとは SLO とは対をなす数字であり、エラーを許容する時間、または見えざるリスクに対しての予算とも言いかえることができます。

具体的な計算式は 100 – SLO となっており、つまりはSLOの範囲で許容されるダウンタイムと捉えれば良いでしょう。例として、仮に SLO を 95% と設定した場合、1週間に8時間24分、1ヶ月に1日と12時間、3ヶ月に4日と12時間までダウンタイムを許容するということになります。

このような数字は、ビジネスにおける戦略の判断材料の一つとなり、エラーバジェットを多く消費し、20%ほどしか残っていないといった場合は、おそらくユーザーの不満度も上がっているでしょうから、新機能の投入よりサービスの安定化を優先するべきでしょう。逆にエラーバジェットが90%も残っている場合は、よりUXを向上させるための施策に挑戦してみるといったことも考えられます。

ここまで Datadog における UX 監視のための機能、SLO やエラーバジェットを活用したビジネス戦略の決定をご紹介いたしました。
UX 監視は、まさにサービスを利用しているユーザーの視点で監視する項目となるため、サーバーの CPU 利用率などのリソースに関する監視よりも、優先してとりかかるべき監視といえるでしょう(CPU の利用率が常に80%だったとしてもすなわちサービス影響があるとは言い切れません)。また、SLO の定義やエラーバジェットの見積りなどはサービスの特性や事業特性にも左右されるため一概にこうあるべきとは言い難い指標ではありますが、その考え方自体はとても重要なものです。

是非、みなさんも今回ご紹介しましたような UX 監視を検討していただき、素晴らしいユーザー体験をご提供ください。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。