アプリ起動エクスペリエンスの徹底検証

Splunkのお客様は、オンコールや緊迫した状況でのトラブルシューティングの際に、Splunkのモバイルアプリを利用しています。フォーチュン100社のうち96社がSplunkのお客様であり、その多くはSplunkのモバイルアプリを使用してサービスの中断や大規模なパフォーマンスの問題を解決しています。そのため、Splunkの製品とサービスには、信頼できる質の高いエクスペリエンスが求められています。

私のチームは、Splunkで以下の2つのモバイルアプリに携わっています。

1. Splunk On-Call (iOSおよびAndroid)：呼び出しを受信し、それに対応する際に使用するアプリ。
2. Splunk Observability (iOSおよびAndroid)：発生した問題の診断とトリアージに使用するアプリ。

お客様が当社のモバイルアプリを使用する際には、アプリの起動のわずかな遅れさえもMTTA(平均確認時間)、ひいてはMTTR(平均解決時間)に影響するため、一分一秒が非常に重要です。SplunkのWebアプリケーションやモバイルアプリを使用して本番環境のインシデントを確認、トリアージ、解決するための時間が1秒増えるごとに、お客様が最大で100ドルもの損失を被ることはよく知られています。

アプリの起動時間が短いことはユーザーエクスペリエンスにとって非常に重要です。そのため私たちは、iOSおよびAndroid向けのSplunk Real User Monitoring (RUM)を使用して、重要なチェックポイントとシナリオを監視および測定しています。アプリの起動エクスペリエンスの品質の判断には、測定値として3つのサービスレベル指標(SLI)を設けています。
1. アプリの起動時間
2. 準備完了までの時間
3. ログインの失敗

アプリの起動時間

ベンチマークには、Android Vitalsで推奨されているものを使用し、iOSにも同じ項目を使用しました。また、この調査での起動時間は、アプリの起動開始から画面に最初のフレームが表示されるまでの時間を計測しています。アプリのコールド、ウォーム、ホットそれぞれの起動時間の計測には、SplunkⓇ RUMの自動インストルメンテーションを使用しています。

準備完了までの時間

オペレーティングシステム(OS)によってレポートされるアプリの起動時間も重要ではありますが、ユーザーの目線では、アプリにデータがロードされるまではアプリが完全に起動したとは感じられません。アプリがユーザーにとって完全に使用できる状態、つまり「準備完了」となるまでにはさらに時間がかかるのです。

アプリの「準備完了までの時間」を測定するために、私たちはSplunk RUMを使用してカスタムのイベントとスパンを追加し、アプリがユーザーの操作を受け付けられる、完全に使用可能な状態になるまでの時間を取得できるようにしました。コードの中ではこのイベントを「o11y_user_logged_in_and_ready」と名付けています。

Android：

iOS：

ここでは、Splunkのオープンソースディストリビューション(iOSおよびAndroid用)で利用できるOpenTelemetryの柔軟なトレーシングAPIを使用して、複数のユーザーパス内の複雑なアプリケーションロジックを読み解き、「準備完了」を示す1つのメトリクスを突き止めます。そして、準備完了までのシーケンスを構成する重要なチェックポイントを監視することで、何がボトルネックになっているかを迅速に特定し、起動プロセスを継続的に最適化します。

複数のユーザーパスと1つのメトリクス

パス1(最も一般的なアプリのユーザーパス)：既存のアプリユーザーは、キーストアに認証トークンを安全にキャッシュしています。アプリの起動時に、「準備完了までの時間」(o11y_user_logged_in_and_ready)カスタムイベントが開始され、以下のステップがスパンとして取得されます。
a. アプリが正常に認証されると、「o11y_socket_connection_attempt」スパンを取得し、最初のチェックポイントを完了します。
b. 次に、アプリによってユーザーのアカウント、アラート、ダッシュボード、その他のアプリケーションに関するデータが要求され、複数の応答メッセージの形で返された後に処理されます。これは、Splunk RUMの「o11y_fetch_and_store_dashboards」スパンで取得されます。
c. これと並行して、アプリのロジックによってユーザーは適切な画面に誘導され、アプリはデータを取り込みながらレンダリングを開始します。画面がロードされたところで停止して、「準備完了までの時間」カスタムイベントを取得します。

パス2(アプリのユーザーパスとしてはまれで10%未満の割合)：キャッシュされた資格情報を持つユーザーが認証を試み、トークンが無効であるか期限切れであるために認証に失敗した場合、アプリはユーザーをログイン画面に誘導し、「準備完了までの時間」(o11y_user_logged_in_and_ready)カスタムイベントのレポートを停止します。さらに、アプリは「o11y_socket_connection_attempt」などのその他のスパンも停止します。新しいユーザーがログイン操作で無効な資格情報を入力した場合も同様に動作します。

ログインの失敗

急いでいるときにログインができなければ、ユーザーは不満を募らせ、アプリの使用を止めてしまう可能性があります。ログインが失敗する原因は複数あり、Splunk RUMは以下のケースのステータスコードとメッセージを取得します。
- 403：ユーザー名とパスワードに誤りがある
- 503：バックエンドが認証リクエストを受け付けない
- 302：シングルサインオン(SSO)が正しく設定されていない

私たちは、SLIの一環として503ステータスの割合を注意深く監視し、この割合が急増した場合にはバックエンドチームと協力しながら迅速に対応しています。

モバイルアプリの詳細なオブザーバビリティ

Splunk Real User Monitoringをオブザーバビリティのスタックに加えて以来、モバイルエンジニアリングチームはエンドユーザーのエクスペリエンスについて、そしてコードの変更や新バージョンの公開による影響について明確に把握することができるようになりました。

私たちは、上に紹介した3つのSLIも含め、実際のさまざまなユーザーメトリクスを継続的に測定、監視、最適化しています。フロントエンドとバックエンドのボトルネックを特定して、アプリの準備完了までの時間を30％以上改善する方法に興味のある方は、ブログ記事「Splunk RUMを使用したモバイルアプリ起動の最適化」をご覧ください。

このブログ記事は、SplunkのシニアプロダクトマネージャーであるSeerut Sidhuとの共同執筆です。

このブログはこちらの英語ブログの翻訳です。