Splunk Observability CloudによるSplunk RUMの監視

私は、Splunk Real User Monitoring (RUM)チームのプリンシパルエンジニアとして、SLA(サービスレベル契約)やSLO(サービスレベル目標)の測定と監視に従事しています。そのため、サービスを測定、可視化、およびトラブルシューティングするために、オブザーバビリティが欠かせません。SplunkのSLAでは、サービスの可用性を99.9%保証しています。Splunkのアプリケーションの複雑さも最新のアプリケーションと同様です。これらは、さまざまなマイクロサービスからのリクエストのオーケストレーションを行う共有のGraphQLサーバーに支えられたマイクロフロントエンドです。お客様のAppから毎分約8億5千万ものスパンが取り込みパイプラインに取り込まれ、下流工程でタイムリーに処理されて、UIアプリケーションを通じてお客様にインサイトが提供されます。優れたユーザーエクスペリエンスを提供できるかどうかは、これらがスムーズに実行できるかどうかにかかっています。SplunkがSLAとSLOを遵守するには、違反の発生時に速やかにアラートを受け取り、すぐに是正措置を講じられるようにする必要があります。

このブログでは、私たちのチームがSplunk Observability Cloudを使用して、本番環境で発生した重大インシデントをどのように検出して、わずかな時間で根本原因を分析したかについて紹介します。

アプリケーションダッシュボードがユーザーに表示されない。至急解決せよ！

緊急事態発生

インシデントが検出され、オンコールエンジニアは2つのソースからアラートを受け取りました。

1. GraphQLエラーを検出するRUMディテクターが、GraphQLリクエストの失敗数がしきい値を超えたことを知らせるアラートを生成しました。

2. Splunk Syntheticsに設定された、RUM UIを定期的にテストするリアルブラウザチェックが3回連続失敗した後に、アラートが生成されました。

アラートには、実際の問題がどのようなものであるかを理解するのに必要な、以下のような情報が含まれていました。

• Splunk RUMが「アプリケーションサマリーダッシュボード」を読み込めなかった。
• 合成テストの失敗でキャプチャされたエラーページが、お客様に表示された。
• 問題は本番環境のus1のみで発生した。
• GraphQLリクエストが、HTTPレスポンスコード403で失敗した。
• 問題の発生は断続的であり、アラートがトリガーされた後もus1で一部の合成テストが成功していた。

また、失敗したテストをSplunk Syntheticsで詳しく調査したことで、その実行のためにトリガーされたブラウザリクエストを可視化して確認することができました。これによって、その実行のすべてのGraphQLリクエストがレスポンスコード403で失敗したことが明らかになりました。

影響の評価

次のステップは問題の規模を特定して、お客様向けのステータスページの情報を更新することでした。直ちにSplunk RUMのTag Spotlightに切り替えて、GraphQLエンドポイントでのエラー数の集計情報を簡単に表示することができました。これを行うために生データを調査したり複雑なクエリーを作成したりする必要はありませんでした。Tag Spotlightからは、環境、HTTPステータスコード、アプリケーションなどの複数のディメンションにわたるエラーの詳細な分析情報が提供されたため、他の本番環境は安定しており、問題が実際にus1環境固有のものであることが確認できました。

根本原因の特定

差し迫った問題は、GraphQLサーバーに何が起こっているのかを突き止めることです。次のような疑問への答えを見つけ出す必要があります。

• 問題があるのはGraphQLサーバーなのか？
• そうだとすれば、他のAPIにも影響を与えているか？
• そうでなければ、本当の問題はどこにあるのか？

バックエンドサービスの全体像を掴むために、Splunk APMの依存関係マップを開いて、共有のGraphQLサーバーの上流から下流に至るすべてのサービスを確認しました。その結果、問題があるのは共有内部ゲートウェイサービスであり、GraphQLサーバーではないことがすぐに判明しました。

さらにSplunk APMには、403 Forbiddenのエラーを返していたゲートウェイの特定コンポーネントの情報を得るためのサンプルトレースが表示されました。このサンプルトレースが大いに役立ち、この問題を内部ゲートウェイサービスの担当チームにエスカレーションすることができたため、干し草の山から針を探すような作業をする必要はありませんでした。

修正が完了し正常稼動に復帰

私たちは内部ゲートウェイサービスの担当チームと協力して、まずは一時的な対策を優先的に講じることができました。対策を展開した後は、インシデントが完全に解決したかどうかをSplunk Observability Cloudで検証することもできました。

Splunk Syntheticsでは、修正の展開後にus1でのテストが成功したことが示されました。

Splunk RUMのTag Spotlightページでは、/rumのすべてのGraphQLリクエストについて、HTTPステータスコード200のみがレポートされるようになりました。これで一安心です。

オブザーバビリティでSLAとSLOを達成

私たちエンジニアリングチームは、実際にお客様が使用する製品のオーナーであり、本番環境に新機能や機能強化を頻繁にデプロイしているため、Splunk Observability Cloudを使ってアプリケーションを監視するためのいくつかの方策を講じています。以下の方策への投資には大きな効果があり、SLAとSLOの達成に役立ちました。

• Splunk Syntheticsでのリアルブラウザチェックの設定：本番環境全体で5分間隔でチェックを実行し、アプリケーションの重要な部分にアクセスして、問題や予期しない遅延があれば通知します。
• Splunk Real User MonitoringによるWebアプリケーションのインストルメンテーション：Splunk RUMにテレメトリデータを送信して、フロントエンドのユーザーエクスペリエンスのパフォーマンスと健全性に関するインサイトを取得します。
• バックエンドのマイクロサービスからSplunk Application Performance Monitoringへのトレースの送信：分散システムの監視と、すべてのアプリケーションデータへの完全忠実なアクセスが可能になります。
• 重要メトリクスのダッシュボードの構築による、アプリケーションに関する有益かつ実用的なインサイトの提供：エラー率、遅延、ウェブバイタルなどの監視に役立ちます。
• 一定の条件が満たされた時にアラートをトリガーするディテクターの設定：指定されたしきい値を超えると、オンコールエンジニアに通知されます。

今後の開発のための教訓、改善、ガイドとなるオブザーバビリティ

オブザーバビリティへの取り組みに着手したことで非常に良かったのは、自分たちのアプリケーションの重要な側面に焦点を絞って小規模から開始し、本番環境の調査と監視を行う中で方法を学び、改善していくことができた点です。改善の努力を積み重ねていくことで、新たな価値がもたらされ、システムのアーキテクチャ、健全性、パフォーマンスについての包括的な理解を徐々に獲得しながら、その知識を共有することができました。

また、Splunk Observability Cloudのオブザーバビリティ機能により、インシデント事後レビューの精度を高めることもできました。これは、サイロ化した個々のソースからのイベントをつなぎ合わせるのではなく、記録されたシステムの動作をすべての関係者がリアルタイムで確認できるためです。このデータドリブンなガイダンスのおかげで、チームはインシデントの発生原因を理解し、将来のインシデントに対してより効果的な防止策と対応策を立てることができました。

データドリブンなチームを作り、パフォーマンスと生産性を最適化することに興味をお持ちでしたら、今すぐSplunk Observability Cloudを試してみることをお勧めします。