Fastlyの障害から考えるオブザーバビリティの重要性

6月8日火曜日、コンテンツ配信ネットワークのFastlyで約1時間にわたってサービスが停止し、多くのWebサイトがアクセス不能に陥りました。前向きに捉えるならば、この障害は、今日のWebサイトが自社の管理下にないリソースにどれだけ依存しているか、そしてオブザーバビリティのマインドセットが確立されていない状況でこうしたリソースの問題を「観測」することがいかに難しいかを明らかにした点で、オブザーバビリティチームへの警鐘の役割を果たしました。このブログ記事では、先日発生したFastlyの障害に対する従来の監視テクノロジーでの対応を検証し、オブザーバビリティの実践にデジタルエクスペリエンス監視を活用することがこの種の問題の検出と対応にいかに効果的であるかについて解説します。

CDN障害の概要

Fastlyはコンテンツ配信ネットワーク(CDN)です。今日のCDNは幅広い機能を提供しますが、主要な機能は、Webサイトのコンテンツやリソースのコピーを世界中のデータセンターにキャッシュして、Webサイトの訪問者がコンテンツやリソースを要求したときに、訪問者の所在地に最も近いデータセンターからコピーを提供することで、遅延を減らしてパフォーマンスを向上させることです。そのため、CDNはWebサイトやAPIの「前」に配置されます。たとえば、ユーザーがsplunk.comにアクセスすると、要求されたサイトの画像、CSS、フォント、場合によってはHTMLマークアップもすべて、サイトのサーバーではなくCDNから提供されます。

次の図は、サイトの訪問者とサーバー間で行われるCDNの処理を示します。ブラウザがmain.jsを要求したとき、CDNがそのコピーをすでに持っている場合は、コピーを返します。これにより、サイトのサーバーから返すよりも時間を短縮できます。ブラウザがAPIを呼び出したときは、CDNは要求をサイトのサーバーに転送します。

問題の6月8日は、内部で発生した障害により、Fastlyが一切の要求に応答できなくなりました。要求がサイトのサーバーに転送されることもなかったため、サーバーも要求に対応できませんでした。その障害の様子を示したのが次の図です。

CDN障害時のユーザーエクスペリエンス

Splunkのオブザーバビリティチームが運用しているBroomsToGoというサンプルオンラインサイトもこのCDN障害の影響を受けました。このサイトの基盤となっているShopifyがFastlyを利用しているためです。私はオブザーバビリティツールを使って、ユーザーの立場でこの障害を直接体験することができました。下の図は、Splunk Synthetic Monitoringのウォーターフォール図です。BroomsToGoを読み込もうとしたときにブラウザが実行した要求が示されています。

アプリケーションのホスト、broomstogo.comに直接送信されたHTMLやAPIなどの要求は成功しています。CSS、大半の画像、JavaScriptを含むアセットは通常、ホストのcdn.shopify.comがFastly経由で提供します。しかし障害のため、これらのアセットの要求に対してはすべて503エラーが返されています。CSSとJavaScriptを読み込めなかった結果はひどいものです！その画面をキャプチャしたのが次の図です。CDN障害の間、サイトの表示がどれだけ悲惨なものになっていたかおわかりいただけるでしょう。

このひどいユーザーエクスペリエンスはビジネスにも悪影響を及ぼしました。画面をスクロールして、スタイルの崩れたチェックアウトボタンを見つけたとしても、機能しません。main.jsファイルがCDNから読み込まれなかったため、このボタンに設定されたJavaScript関数が読み込まれなかったためです。

従来の監視ツールでのCDN障害への対応

BroomsToGoが楽しいサンプルアプリケーションではなく正式なオンラインショップであったとしたら、どのような影響があったか考えてみましょう。チームは従来の監視ツールを使ってこの問題を検出できたでしょうか。

想像してみてください。BroomsToGoのSREであるMelanieがのんびりコーヒーを飲んでいるときに、事業開発部のEthanが慌てて電話をかけてきました。「Webサイトがダウンしている！チェックアウトもできない！このままじゃ大損だ！」

まさか！そう思いながらMelanieは監視ツールをチェックします。問題は一切発生していません。Slackの運用チャネルにもアラートは投稿されていません。インフラやアプリケーションの監視のどこかで実は問題が見つかっていたのでしょうか。

残念ながらそうではありません。CDNはアプリケーションの前に配置されます。そのため、CDNの障害は、従来のツールによる「観察」方法では検出できないのです。従来の監視ツールでは、この障害は次のように処理されます。

• 従来のインフラ監視(IM)：IMは、コンテナ、サーバー、クラウドリソースなどのインフラの健全性に関するインサイトを提供します。CDNの障害では、すべてではなくとも大部分のユーザートラフィックはそもそもインフラにアクセスできなかったため、IMのダッシュボードでは問題は報告されません。自社が管理するインフラはいずれも影響を受けなかったのです。
  
  
• 従来のアプリケーションパフォーマンス監視(APM)：APMは、1層上のデータベース、Webサーバー、アプリケーションコードの動作状況に関するインサイトを提供します。障害により、大部分のトラフィックがアプリケーションまでたどり着けなかったため、APMでも問題は検出できず、アラートは生成されません。実際に、サンプルサイトでもアプリケーション自体は正常に機能していました。ベースとなるHTMLページとすべてのAPI要求は、「200 OK」のステータスコードを返していました。アプリケーションの処理の失敗は、外部のCDNから提供されるCSSやJavaScriptリソースの遅延やアクセス不能によるものです。
   

Melanieがサイト分析に注意を向けていたら問題を発見できていたでしょう。障害の規模に応じてチェックアウト率が低下していたはずです。トラフィック数やエンゲージメント数も低下していたでしょう。また、自社のソーシャルメディアをチェックしていれば、利用者から不満の声があがっていることに気付いたかもしれません。

Digital Experience Monitoringによるオブザーバビリティの向上

Melanieのミスは、管理下にあるインフラとアプリケーションを監視していればアプリケーションの健全性や可用性に関する重要な情報をすべて把握できると考えたことです。しかし今回は違いました。今日のアプリケーションは管理下のリソースを超えて広く展開されます。多くのアプリケーションが、外部コンポーネントを利用し、不透明な環境で実行されます。マーケティングチームがWebサイトに新しいチャットウィジェットを無断で追加するなど、サイトを構成するインフラ、アプリケーション、依存関係をSREが把握できていないこともあります。従来のIMやAPMツールはたしかに問題の検出と診断に有効ですが、監視対象にならない部分は測定できません。今日のアプリケーションにはSREの手の届かない部分が多いのです。

この問題を解決するのがデジタルエクスペリエンス監視 (DEM)です。DEMは、ユーザー視点でパフォーマンスとエクスペリエンスを監視します。そのため、バックエンドと外部アセットのどちらについてもパフォーマンスがユーザーに及ぼす影響を把握し、アプリケーションの可用性を低下させる障害がスタック内のどこで発生しても異常を検出できます。DEMは、Synthetic MonitoringやReal User Monitoring (RUM)と組み合わせて使用します。Synthetic Monitoringでは、世界各地で実行されている実際のブラウザを使ってページやビジネスフローのパフォーマンスが分単位で測定されます。RUMでは、JavaScriptを使って、サイトにアクセスしたりアプリケーションを使用したりした現実のユーザーに関するデータが収集され、実際のパフォーマンス、エクスペリエンス、エラーに関するメトリクスが提供されます。 

私はBroomsToGoサイトでSplunk Synthetic Monitoringを使用していたため、実際に障害に関するアラートを受け取りました。Synthetic Monitoringによって、CDN障害が発生したまさにその瞬間に、クライアント側でエラーが増加したことが検出されています。

上の図では、緑色のグラフがFCP (First Contentful Paint)を示し、黒のグラフがブラウザでリソースのダウンロード中に発生したエラー数を示します。このグラフから、障害が発生した瞬間に、CSSやJavaScriptなどのアセットの読み込みが失敗し、エラー数が増加しているのがわかります。一方、これらのアセットの要求が失敗したことで、描画するコンテンツが減ったため、描画時間を表すFCPが向上しているのは皮肉なことです。

もちろん、DEMソリューションではインフラやアプリケーションの内部の状況まではわかりません(そもそも、相手が実際のユーザーであれ合成ブラウザであれ、アプリケーションの内部処理まで見えてしまったら問題です)。Splunk Observability Cloudなどのオブザーバビリティスイートに含まれるIMやAPMなどのソリューションとDEMを組み合わせて使用する必要があるのはそのためです。他のソリューションと組み合わせることにより、アプリケーション、インフラ、ユーザーエクスペリエンスを包括的に可視化して、問題がスタック内のどこで起きても把握することができます。

まとめ

今回のFastlyの障害によって、自ら管理できる範囲を超えた場所にあるコンテンツやインフラがいかにサイトの障害を引き起こし、ビジネスに影響を与え得るかが明らかになりました。デジタルエクスペリエンス監視を活用すれば、視野を広げ、ユーザー視点でエクスペリエンスを測定して、この種の問題をすばやく検出し、対応して、影響を最小限に抑えることができます。包括的なオブザーバビリティ戦略を策定するときは、デジタルエクスペリエンス監視の導入をぜひご検討ください。

Splunk Synthetic Monitoringをお試しになりたい場合は、無料のトライアル版をご利用いただけます。

Splunkの関連リソース：

• Synthetic Monitoringの製品ページ
• Digital Experience Monitoringの製品ページ
• Observability Cloudの製品ページ

このブログはこちらの英語ブログの翻訳、大谷 和紀によるレビューです。