Firebase Performance — その概要、モニタリングツールとメトリクス

Firebase Performance Monitoringとは？

Firebase Performance Monitoringは、モバイルアプリケーションのパフォーマンスメトリクスを収集して表示するGoogleのクラウドサービスです。このサービスはFirebaseツールセットの一部であり、別途支払いは不要です。モニタリングは無料のSparkティア（1日あたり500,000イベントの制限）と有料のBlazeティアで利用できます。Firebase Performanceは、標準的なシナリオ（コールドスクリーンスタート、ウォームスタート、バックグラウンドHTTPリクエスト）に対して自動的にトレースを生成します。

サービスのアーキテクチャは、traces（トレース）とmetrics（メトリクス）の2種類のデータに基づいています。トレースは開始と終了がある時間間隔であり、その中で実行時間が測定されます。メトリクスは数値です：応答サイズ、エラー率、バイト/秒単位の速度。各トレースには複数のメトリクスを含めることができます。SDKはデバイス上でデータを収集し、バッファリングして、ユーザーエクスペリエンスに影響を与えないよう低遅延優先度でバックグラウンドでFirebaseに送信します。

Google I/O 2024のレポートによると、Firebase Performanceは世界中で200万以上のアプリケーションで使用されています。アラートが設定されている場合、Firebase Performanceを使用したパフォーマンス問題の平均検出時間はリリース後15分です。モニタリングがない場合、同様の問題は通常、ユーザーからサポートへの苦情を通じて2〜3日以内に検出されます。

Firebase Crashlyticsとの違い

Crashlyticsはクラッシュや致命的なエラーを追跡します。これはアプリケーションが予期せず終了する状況です。Firebase Performanceは実行中のアプリケーションのパフォーマンスを監視します：遅い画面、長いネットワークリクエスト、UI応答の遅延。Crashlyticsは「アプリがなぜクラッシュしたのか？」という質問に答え、Performanceは「アプリがなぜ遅いのか？」という質問に答えます。両方のサービスは単一のSDK（Firebase Core）を介して統合され、データはFirebaseコンソールの隣接するセクションに表示されます。

パーセンタイルメトリクス

Firebase Performanceは平均値を表示せず、パーセンタイル（P50、P75、P90、P95、P99）のみを表示します。これはパフォーマンスにとって重要です：平均時間は外れ値を隠します。99人のユーザーが200ミリ秒で画面を開き、1人のユーザーが20秒で開いた場合、平均は約400ミリ秒になり、許容範囲に見えます。P99は20秒を表示します — これが本当の問題です。Firebaseはパーセンタイルをタイムラインに表示し、時間単位の精度で回帰を追跡できます。

Firebase Performance Monitoringの仕組み

Firebase Performance SDKは、標準的な統合を通じてアプリケーションに組み込まれます：Gradle（Android）への依存関係の追加、またはCocoaPods（iOS）を介して。コード内でFirebaseを初期化した後、SDKは追加設定なしで自動的にメトリクスの収集を開始します。重要な原則は遅延収集です：SDKはデータをすぐに送信せず、蓄積してネットワーク状態が良好なときにバッチで送信します。

iOSの場合、SDKはHTTPリクエストをインターセプトするためにNSURLProtocolを使用し、Androidの場合はOkHttp Interceptorを使用します。アプリケーションがOkHttpを使用していない場合、SDKは自動的にHttpURLConnectionをラップします。インターセプトされたリクエストには、Content-Type、応答ステータス、バイト単位のサイズ、所要時間などのメタデータが追加されます。すべてのデータはTLS 1.3暗号化を使用してHTTPS経由でFirebaseサーバーに送信されます。

Firebase Performanceの重要な要件の1つは、Gradleプラグインリストの最後のプラグインであることです。順序が適切でないと、SDKがすべてのリクエストをインターセプトできなかったり、起動時間を誤って測定したりする可能性があります。Firebaseは、プラグインをプラグインブロックの最後に、Crashlyticsやその他のGoogle Servicesプラグインの後に配置することを推奨しています。

// build.gradle (Module: app) — プラグインの正しい順序
plugins {
    id "com.android.application"
    id "org.jetbrains.kotlin.android"
    id "com.google.gms.google-services"
    id "com.google.firebase.crashlytics"
    id "com.google.firebase.firebase-perf"  // 最後に!
}

dependencies {
    implementation platform("com.google.firebase:firebase-bom:33.0.0")
    implementation "com.google.firebase:firebase-perf"
}

自動トレース：画面、起動、ネットワーク

Firebase Performanceは、3種類の自動トレースを作成します：screen trace（画面レンダリング時間）、app start trace（アプリケーション起動時間）、network request trace（HTTPリクエスト）。Androidのscreen traceは、Activity.onCreateの呼び出しから最初のフレームのレンダリング完了までの時間を測定します。iOSの場合は、viewDidLoadからviewDidAppearまでの時間が測定されます。Firebaseは各画面に対して自動的にトレースを作成し、ActivityまたはViewControllerのクラス名を使用します。

App start traceは2つのタイプに分けられます：コールドスタート（アプリケーションがゼロから起動し、プロセスが存在しなかった）とウォームスタート（アプリケーションがバックグラウンド状態から復元される）。コールドスタートは、すべてのSDKの初期化、DEXファイルの読み込み、最初のActivityの作成を含むため、最も重要なメトリクスです。Firebaseは、プロセスが開始された瞬間から最初の画面が完全にレンダリングされるまでをコールドスタートとして測定します。Googleの推奨によると、コールドスタートはP50で500ミリ秒、P99で2秒を超えないようにする必要があります。

Network request traceは、メタデータ（URL、メソッド、応答コード、応答サイズ、転送速度）とともに各HTTPリクエストを自動的に記録します。Firebase Performanceコンソールでは、URLパターンでリクエストをフィルタリングできます。たとえば、/api/v2/ordersへのすべてのリクエストを表示できます。各パターンについて、応答時間のパーセンタイルと4xx/5xxエラー率が表示されます。これにより、個別のアラートを設定しなくても、特定のAPIの低下を迅速に検出できます。

画面メトリクスの詳細

画面の場合、Firebase Performanceは追加で「frozen frames」メトリクスを計算します — レンダリングに700ミリ秒以上かかったフレームです。このようなUIのフリーズは、ユーザーには「アプリがフリーズした」と認識されます。画面に1%を超えるfrozen framesがある場合、Firebaseはそのメトリクスを問題ありとしてマークします。Androidの場合、SDKは追加でスローレンダリングのメトリクス（16ミリ秒を超えるフレーム、60 FPSを逃す）を収集します。Screen traceとfrozen framesの組み合わせにより、読み込み時間とアニメーションの滑らかさの両方の完全な状況が得られます。

ビジネスシナリオ向けのカスタムトレース

カスタムトレースを使用すると、注文、クラウドへの画像アップロード、データ同期など、あらゆるユーザーシナリオの所要時間を測定できます。開発者はコード内でトレースの開始と終了を明示的に指定し、シナリオ名を設定します。自動トレースとは異なり、カスタムトレースは測定内容を完全に制御でき、フィルタリング用の属性を追加できます。

各カスタムトレースには属性を含めることができます — メタデータとして追加されるキーと値のペアです。属性はデータのセグメント化に役立ちます。たとえば、「promo_user」と「regular_user」でチェックアウト時間を個別に追跡できます。Firebase Performanceはトレースあたり最大5つの属性と、最大100の一意の属性値をサポートしています。属性はインデックス化され、Firebaseコンソールでフィルタリングに利用できます。

Google I/O 2024のプレゼンテーションによると、Spotifyチームはトラック切り替え時間の監視にFirebaseのカスタムトレースを使用しています。これにより、オーディオバッファキャッシングのボトルネックを特定し、切り替え時間の中央値を400ミリ秒から120ミリ秒に短縮できました。重要な洞察は「device_model」属性によるフィルタリングから得られました — 問題はAndroid 13を搭載したSamsungデバイスでのみ発生していました。

import com.google.firebase.perf.FirebasePerformance
import com.google.firebase.perf.metrics.Trace

class CheckoutTracker {

    private val firebasePerf = FirebasePerformance.getInstance()

    fun trackCheckoutFlow(userId: String, promoApplied: Boolean) {
        val trace: Trace = firebasePerf.newTrace("checkout_flow")
        trace.putAttribute("promo_user", promoApplied.toString())
        trace.putAttribute("user_tier", "premium")
        trace.start()

        // チェックアウトシナリオを実行中
        validateCart()
        processPayment()
        confirmOrder()

        trace.stop()
    }
}

AndroidプロジェクトへのFirebase Performanceの統合

AndroidへのFirebase Performanceの統合には、3つのステップが必要です：google-servicesプラグインの追加、Firebase BOM（Bill of Materials）の接続、firebase-perf依存関係の追加。Firebase Performanceは、AppCompatActivityを使用している場合、すべてのActivityとフラグメントで自動的に動作します。Compose画面の場合、自動screen traceはComposeを直接サポートしていないため、Firebaseはカスタムトレースの使用を推奨しています。

重要な注意点：Firebase Performance Gradleプラグインは、コンパイル時にアプリケーションのバイトコードを変更します。プラグインはすべてのActivityとOkHttpクライアントにインストルメンテーションコードを追加します。これにより、ビルド時間が5〜10%増加し、APKサイズが200〜400KB増加する可能性があります。デバッグビルドでは、Firebase Performanceは自動的に無効になります — これにより、ローカル開発中のメトリクスの歪みを防ぎます。デバッグで強制的に有効にするには、マニフェストでfirebasePerformanceInstrumentationEnabledフラグを使用します。

Firebase PerformanceはiOS用のMetricKitとAndroid用のPerfettoもサポートしています — 低レベルのシステムトレーサーです。MetricKitは、オペレーティングシステムレベルでのフレームレート、CPU、メモリ使用量に関するデータを提供します。Firebaseはこのデータを集約し、HTTPトレースやscreen tracesが表示される同じコンソールに表示して、システムとアプリケーションのテレメトリーを1つのインターフェースに統合します。

OkHttpを使用したHTTPリクエスト

import okhttp3.OkHttpClient
import com.google.firebase.perf.network.FirebasePerfOkHttpClient

val client = OkHttpClient.Builder()
    .addInterceptor FirebasePerfOkHttpClient
    .build()

val request = Request.Builder()
    .url("https://api.example.com/orders")
    .build()

client.newCall(request).enqueue(object : Callback {
    override fun onFailure(call: Call, e: IOException) { /* handle */ }
    override fun onResponse(call: Call, response: Response) { /* handle */ }
})

iOSプロジェクトへのFirebase Performanceの統合

iOSの場合、Firebase Performanceの統合はCocoaPodsまたはSwift Package Managerを介して行われます。FirebasePerformanceとFirebaseCoreのポッドをインストールした後、SDKは自動的にメトリクスの収集を開始します。HTTPリクエストをインターセプトするために、Firebase Performance iOSはNSURLProtocolを使用します — アプリケーション内のすべてのURL読み込みをインターセプトできるシステムメカニズムです。SDKは起動時にNSURLProtocolサブクラスを登録し、URLSessionを介したすべてのリクエストが自動的に監視対象になります。

iOSの制限：Firebase PerformanceはSwiftUIの自動screen traceをサポートしていません。SwiftUIアプリケーションの場合は、Viewの本体を開始/停止ブロックでラップして、手動でカスタムトレースを作成する必要があります。FirebaseはネイティブのSwiftUIサポートに取り組んでいますが、現在SDKは自動的にUIViewコントローラーのみをトレースします。UIKit + SwiftUIのハイブリッドアプリケーションの場合は、UIKitで画面を作成し、UIHostingControllerを介してSwiftUIを埋め込むことを推奨します。

Firebase Performance iOSはMetricKitとの統合も提供します — OSレベルで診断データを収集するAppleのフレームワークです。MetricKitは、CPU、GPU、メモリ、フレームレートのメトリクスを含む日次レポートを送信します。Firebase Performanceはこれらのレポートを集約し、カスタムトレースとともにコンソールに表示して、アプリケーションレベルとシステムレベルの両方でのパフォーマンスの完全な状況を提供します。

import FirebasePerformance

final class ImageUploadService {

    func uploadImage(_ data: Data, to url: URL) async throws {
        guard let trace = Performance.startTrace(name: "image_upload") else { return }
        trace?.setValue("image/jpeg", forAttribute: "content_type")
        trace?.setValue("\(data.count)", forAttribute: "file_size")

        var request = URLRequest(url: url)
        request.httpMethod = "POST"
        request.httpBody = data

        let (_, response) = try await URLSession.shared.data(for: request)
        guard let httpResponse = response as? HTTPURLResponse else { return }
        trace?.setValue("\(httpResponse.statusCode)",
                        forAttribute: "status_code")
        trace?.stop()
    }
}