Amazon Web Services ブログ

Amazon CloudWatch RUM がモバイルアプリケーションモニタリングをサポート

本記事は 2025 年 12 月 9 日 に公開された「Amazon CloudWatch RUM now supports mobile application monitoring」を翻訳したものです。

Amazon CloudWatch RUM のモバイル対応を発表できることを嬉しく思います。これにより、AWS のリアルユーザーモニタリング (RUM) 機能が iOS および Android アプリケーションにも拡張されます。これまで Web アプリケーションでのみ利用可能だったモニタリングツールが、モバイル開発者にも提供されるようになりました。

モバイルデバイスが日常生活においてますます重要になる中、モバイルアプリの最適なパフォーマンスとユーザーエクスペリエンスを確保することがこれまで以上に重要になっています。しかし、モバイルアプリのモニタリングには、デバイス、オペレーティングシステム、アプリケーションバージョン、ネットワーク、ユーザーインタラクションの多様性により、独特の課題があります。モバイルアプリ開発者は、「テストでは完璧に動作するのに、実環境ではパフォーマンスの問題が発生する」という継続的な課題に直面しています。合成テストや従来のモニタリング手法は実世界のパフォーマンスに関する洞察を提供しますが、エンドユーザーエクスペリエンスを理解するために必要なデータが不足しています。そこで CloudWatch RUM Mobile の出番です。実際のユーザーの手の中でモバイルアプリがどのように動作しているかについて深い洞察を提供するメトリクスを収集できます。

モバイル向け Amazon CloudWatch RUM

モバイル向け Amazon CloudWatch RUM は、エンドユーザーのモバイルアプリが使用される際に、非常に重要なパフォーマンスデータとユーザー行動メトリクスを収集するのに役立ちます。軽量な SDK を Android または iOS アプリに実装することで、アプリのパフォーマンス、ユーザーインタラクション、ユーザーエクスペリエンスに影響を与える潜在的な問題に関する豊富な情報をキャプチャできます。

開始するには、CloudWatch RUM コンソールで「アプリケーションモニター」を作成し、SDK をアプリに統合してデプロイするだけです。SDK はユーザーがアプリを操作する際にバックグラウンドで実行され、貴重なデータを RUM に送信して集約と分析を行います。このツールは単独で使用することも、Amazon CloudWatch Application SignalsAWS X-Ray などの他の AWS サービスと組み合わせて使用することもでき、Web およびモバイルプラットフォーム全体でアプリケーションのパフォーマンスを包括的に把握できます。

開発プロセスを変革する主なメリット

CloudWatch RUM Mobile は、開発チームがリアクティブなデバッグからプロアクティブな最適化へと移行できるようにします。実際のユーザーからリアルタイムのパフォーマンスメトリクスを収集し、ユーザー満足度に影響を与える前にパフォーマンスの問題を特定できます。システムは画面の読み込み時間を監視し、アプリのクラッシュ、Android の ANR (Application Not Responding) または iOS のアプリハングを完全なコンテキストとともに追跡し、これらすべてのデータを包括的なダッシュボードで視覚化します。

変革は即座に起こります。ユーザーからの苦情を待ったり、バグを再現しようとしたりする代わりに、ユーザーがアプリとやり取りするたびに何を経験しているかについて、明確で実用的な洞察が得られます。

はじめに: モバイルモニタリング強化への道

このブログでは、Amazon CloudWatch RUM を Android および iOS モバイルアプリに統合する方法を学びます。モバイル向け CloudWatch RUM の使用を開始するには、以下の詳細な手順に従って、Android または iOS アプリのモニタリングをセットアップして実装します。

Android 用アプリケーションモニターのセットアップ

開始するには、まず「アプリケーションモニター」を作成する必要があります。これを行うには、AWS CloudWatch コンソールを開き、Application Signals に移動して RUM を選択します。次に「Add app monitor」をクリックします。

Figure 1: Create app monitor via AWS CloudWatch console

図 1: AWS CloudWatch コンソールからアプリモニターを作成

これで「Android」と「iOS」という 2 つの新しいオプションが表示されます。「App monitor name」の下でアプリモニターに名前を付け、プラットフォームとして「Android」または「iOS」のいずれかを選択して続行します (ここでは Android を選択します)。

Figure 2: Create app monitor – Options for Android and iOS

図 2: アプリケーションモニターの作成 – Android と iOS のオプション

要件に基づいて有効にできるいくつかの「オプション」フィールドがあります。

  • RUM テレメトリAmazon CloudWatch Logs で利用できるようにする場合は、「Data Storage」オプションをチェックします
  • リソースベースのポリシーを使用してアクセスを制御する場合は、「Attach a public Resource Based Policy」をチェックします
  • スパンを X-Ray で利用できるようにする場合は、「Active tracing」オプションをチェックします

Figure 3: Create app monitor – Optional fields

図 3: アプリケーションモニターの作成 – オプションフィールド

Add app monitor をクリックして完了します。

コンソールは、データの収集を開始するために Android アプリケーションに追加する必要があるコードスニペットを提供します。コードは「手動計装」「ゼロコード計装」の両方で提供されます。

スニペットを保存しましょう。これは、このブログの後半の「Android アプリの計装」セクションで使用します。

Figure 4: Create app monitor – Code snippet for Manual and Zero-code instrumentation

図 4: アプリモニターの作成 – 手動およびゼロコード計装用のコードスニペット

Android アプリの計装: 実装パスの選択

アプリケーションモニターが作成されたので、テレメトリデータをアプリケーションモニターに送信するようにモバイルアプリを計装しましょう。上記で気づいたように、モバイルアプリを計装または設定するには、ゼロコード計装手動計装の 2 つのオプションがあります。

まず、「アプリケーションモニターのセットアップ」セクションのコードスニペットを手元に用意してください。このセクションを完了するために必要になります。コードは https://github.com/aws-observability/aws-otel-android でも入手できます。それでは、これらの各オプションを確認しましょう。

オプション 1: ゼロコード計装 (エージェント)

これには、まずアプリケーションの "app/build.gradle" ファイルにいくつかの依存関係を注入する必要があります。以下は Kotlin DSL の例です。

plugins {
     id("com.android.application")
     id("org.jetbrains.kotlin.android")
}

dependencies {
    // ADOT Android Agent - includes automatic instrumentation
    implementation("software.amazon.opentelemetry.android:agent:1.0.0")

    // Automated HTTP client instrumentation with byteBuddy (optional but recommended)
    byteBuddy("io.opentelemetry.android.instrumentation:okhttp3-agent:0.15.0-alpha")// if you are using OkHttp-3.0
    byteBuddy("io.opentelemetry.android.instrumentation:httpurlconnection-agent:0.15.0-alpha") // if you are using URLConnection/HttpURLConnection /HttpsURLConnection
}

次に、ゼロコード設定では、アプリケーションの "res/raw" ディレクトリの下に "aws_config.json" というファイルを作成し、以下のコードスニペットを記述する必要があります (各パラメータの値を必ず置き換えてください)

{
  "aws": {
    "region": "<your-region>", // specify the AWS region your app monitor has been created in
    "rumAppMonitorId": "<your-app-monitor-id>", // replace with the ID of the app monitor created above
  },

  // optional attributes that will be appended to all OpenTelemetry application spans and events
  " otelResourceAttributes ": {
     "service.name": "<your_app>", // Note: Update this with your application name
     "service.version": "1.0.0" // specifying service.version will allow you to filter telemetry on the RUM console based on your running app's version    
  }
}

これで完了です! これは、Android エージェントを初期化し、CloudWatch RUM アプリケーションモニターへのテレメトリの収集を開始するために必要な最小限のものです。

オプション 2: 手動計装

クライアントをプログラムで設定するには、オプション 1 で使用した「agent」モジュールの代わりに、軽量な「core」モジュールを使用します。これには、アプリケーションの "app/build.gradle" ファイルに以下の SDK を追加しましょう。

plugins {
       id("com.android.application")
       id("org.jetbrains.kotlin.android")
}

dependencies {
      implementation("software.amazon.opentelemetry.android:core:1.0.0")

     // Automated HTTP client instrumentation with ByteBuddy (optional but recommended)
     byteBuddy("io.opentelemetry.android.instrumentation:okhttp3-agent:0.15.0-alpha")
     byteBuddy("io.opentelemetry.android.instrumentation:httpurlconnection-agent:0.15.0-alpha")
}

次に、アプリケーションで AWS Distro for OpenTelemetry (ADOT) Android エージェントを初期化する必要があります。

class MyApplication : Application() {
      override fun onCreate() {
          super.onCreate()

         OpenTelemetryRumClient {
              androidApplication = this@MyApplication
              awsRum {
                    region = "<your-region>"
                    appMonitorId = "<your-app-monitor-id>"
             }
             otelResource = Resource.builder()
                    .put("service.name", "MyApp") // Note: Update this with your application name
                    .put("service.version", "1.0.0") // Note: Keep this updated with latest version
                    .build()
        }
    }
}

最後に、Application クラスがまだない場合は、この新しい「MyApplication」を Android マニフェストに登録する必要があります。

<application>
        android:name="com.example.MyApplication" 
        <!-- All other attributes, activities, etc --> 
         android:label="MyApplication"> 
</application>

この後、アプリケーションを実行して、アプリケーションモニターへのテレメトリの受信を開始できるはずです。

iOS 用アプリケーションモニターのセットアップ

iOS アプリケーション用のアプリケーションモニターを作成するプロセスは、上記で示した Android アプリケーションの場合と同じです。iOS 用のアプリモニターが作成されたら、テレメトリデータの送信を開始するためにアプリケーションを計装する方法を見てみましょう。iOS のコードも https://github.com/aws-observability/aws-otel-swift で入手できます。

オプション 1: ゼロコード計装 (エージェント)

Android の「アプリケーションモニター」と同様に、「アプリケーションモニター」作成の最終ページで iOS アプリを計装するための「コードスニペット」を取得できます。これらの手順に基づいて、Swift SDK の依存関係をアプリケーションの "Package.swift" ファイルに注入します。

// In your package dependencies:
dependencies: [
     .package(url: "https://github.com/aws-observability/aws-otel-swift.git", .upToNextMajor(from: "1.0.0"))
]

// In your target dependencies:
targets: [
    .target(
         name: "<YourAppTarget>",
         dependencies: [
             // Only for automatic initialization
            .product(name: "AwsOpenTelemetryAgent", package: "aws-otel-swift"),
          ]
      )
]

SDK は、「AwsOpenTelemetryAgent」モジュールがアプリにインポートされると自動的に初期化されます。アプリバンドルのルートディレクトリで "aws_config.json" という名前のファイルを探します (各パラメータの値を必ず置き換えてください)

{
   "aws": {
      "region": "<your-region>",// specify the AWS region your app monitor has been created in
      "rumAppMonitorId": "<your-app-monitor-id>" // replace with the ID of the app monitor created above
   },
   "otelResourceAttributes": {
          "service.name": "<your-app>", // Note: Update this with your application name
          "service.version": "1.0.0" // Note: Keep this updated with latest application version
    }
}

オプション 2: 手動計装

クライアントをプログラムで設定するには、プロジェクトの "Package.swift" ファイルに以下の依存関係を追加します。

// In your package dependencies:
dependencies: [
     .package(url: "https://github.com/aws-observability/aws-otel-swift.git", .upToNextMajor(from: "1.0.0"))
]

// In your target dependencies:
targets: [
     .target(
          name: "YourAppTarget",
          dependencies: [
              .product(name: "AwsOpenTelemetryCore", package: "aws-otel-swift"),
          ]
     )
]

次に、アプリケーションで ADOT Swift エージェントを初期化します。

import AwsOpenTelemetryCore
class AppDelegate: UIResponder, UIApplicationDelegate {
       func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
                AwsOpenTelemetryRumBuilder.create(
                      config: AwsOpenTelemetryConfig(
                            awsRum: AwsRumConfig(
                                  region: "<your-region>",
                                  appMonitorId: "<your-app-monitor-id>"
                             ),
                            otelResourceAttributes: [
                                    "service.name": "<your-app>", // Note: Update this with your application name
                                    "service.version": "1.0.0" // Note: Keep this updated with latest application version
                             ]    
                   )
              )?.build()
             return true
      }
}

アプリのパフォーマンスの可視化: データが洞察に変わる場所

モバイル向け CloudWatch RUM がデータの収集を開始すると、CloudWatch RUM はモバイルパフォーマンスのコマンドセンターに変わり、生のパフォーマンスデータを実用的な洞察に変える複数の専門的なビューを提供します。

表示される RUM アプリケーションモニターのリストから、上記のセクションで作成したアプリケーションモニターを選択します。これにより、Performance、Errors、Sessions、Metrics、Configuration などのさまざまなタブを持つダッシュボードが表示され、画面、アプリバージョン、OS バージョン、デバイス、国、リージョン、地域によるフィルタリング機能が提供されます。

Performance タブ: 速度と応答性の詳細な分析

CloudWatch RUM コンソールの Performance タブは、モバイルアプリのパフォーマンスに関する洞察を提供します。この詳細ビューでは、画面読み込み時間を画面名、OS バージョン、アプリバージョン、デバイス、国別に分類して表示します。以前は見えなかったパターンが明確になります。特定の国ではネットワークインフラストラクチャの違いによりアプリのパフォーマンスが異なる、または特定のデバイスモデルが特定の機能で苦労しているなどです。チャート内の画面読み込み時間のデータポイントをクリックすると、右側に診断パネルが開き、データポイントに関連する詳細な洞察 (最新の関連セッションなど) と、1 つまたは他の類似セッションのトラブルシューティングを行うための Sessions タブへのリンクが提供されます。

App Launch time ビューでは、アプリケーションの起動パフォーマンスを詳細に分析し、起動タイプ (コールド/ウォーム)、OS バージョン、アプリバージョン、デバイス、国別に起動時間を分類します。この詳細なビューは、パフォーマンスのボトルネックを特定するのに役立ちます。特定の OS バージョンでコールドスタートが遅い、または特定のデバイスモデルが初期化で苦労しているなど、最も影響力のあるユーザーセグメントに対して的を絞った最適化の取り組みを可能にします。

Locations タブは、アプリケーションパフォーマンスに関する地理的な洞察を提供し、国、リージョン、地域全体のメトリクスを表示して、場所ベースのパフォーマンスパターンを明らかにします。このビューは、地域のインフラストラクチャの課題、ネットワークレイテンシーの問題、またはユーザーがパフォーマンスの低下を経験している地理的エリアを特定するのに役立ちます。

Figure 5: AWS CloudWatch RUM – Performance tab

図 5: AWS CloudWatch RUM – Performance タブ

Errors タブ: デバッグの相棒

Errors タブは、エラー追跡を体系的な問題解決に変換します。アプリケーションの問題を 3 つのカテゴリに分類します: Network Errors、Crashes、ANRs/App hangs。Network Errors タブには、HTTP リクエストの折れ線グラフがあり、HTTP パフォーマンスメトリクスを表示し、左の Y 軸に失敗率 (HTTP エラー、HTTP フォールト、ネットワーク障害) を、右の Y 軸に HTTP レイテンシーを示します。この時系列データポイントにより、ユーザーはクリックして、診断パネルでトラブルシューティングのために関連するスパンとセッションを表示できます。下部のテーブルには、最も一般的な 100 のネットワークルートがリストされます。

同様に、Crashes および ANRs/App hangs タブには、各エラーのカウントの折れ線系列が表示されます。下部のテーブルには、最も一般的な上位のクラッシュメッセージ/ANR スタックトレースが表示されます。エラーメッセージをクリックすると、クイックリファレンス用にスタックトレース全体がポップアップ表示されます。

Figure 6: AWS CloudWatch RUM – Errors tab

図 6: AWS CloudWatch RUM – Errors タブ

Sessions タブ: ユーザージャーニーの追跡

次に、Sessions タブでは、詳細なウォーターフォール表示を使用して、アプリ内の個々のユーザージャーニーを追跡できます。これらの可視化は、ユーザーインタラクション中に時間がどこで費やされているか、ユーザーがどこで摩擦や遅延を経験しているかを正確に示します。このユーザー中心のビューは、技術的なパフォーマンスだけでなく、全体的なユーザーエクスペリエンスを最適化するのに役立ちます。

すべてのセッションをリストするテーブルがあり、時刻の降順にソートされています。下部には、選択したセッションのすべてのテレメトリを視覚化するウォーターフォールがあります。ウォーターフォールの各行を選択して、診断パネルを開くことができます。行が HTTP リクエストの場合、トレースコンソールにディープリンクされた traceId があります。例外、クラッシュ、または ANR/App hang を受信した HTTP リクエストの場合、診断パネルにはスタックトレースを表示する Exception タブもあります。ウォーターフォールの「View」ボタンは、ワンクリックで例外に直接移動する簡単な方法でもあります。

Figure 7: AWS CloudWatch RUM – Sessions tab - ARN

図 7: AWS CloudWatch RUM – Sessions タブ – ARN

Figure 8: AWS CloudWatch RUM – Sessions tab – HTTP traceId

図 8: AWS CloudWatch RUM – Sessions タブ – HTTP traceId

Metrics タブ: アプリケーションヘルスのモニタリング

Metrics タブは、レイテンシー、エラー、ボリューム、拡張メトリクスに関するアプリケーションのパフォーマンスに関するリアルタイムデータを視覚化するのに役立つ包括的なダッシュボードを提供します。

このタブには、右上に「Add to dashboard」というオプションもあり、このデータを他の CloudWatch ダッシュボードにエクスポートできます。

Figure 9: AWS CloudWatch RUM – Metrics tab

図 9: AWS CloudWatch RUM – Metrics タブ

Configuration タブ: 継続的な管理

最後に、Configuration タブは、アプリモニター設定とインストルメンテーションコードスニペットへのアクセスを容易にし、モニタリングのニーズが進化しても、継続的な管理と更新を容易に行えます。

Figure 10: AWS CloudWatch RUM – Configuration tab

図 10: AWS CloudWatch RUM – Configuration タブ

まとめ

モバイル向け Amazon CloudWatch RUM は、モバイルアプリケーションのオブザーバビリティをリアクティブなトラブルシューティングからプロアクティブな最適化に変革し、パフォーマンスモニタリングを通じてビジネスインパクトをもたらします。チームは、地域のクラッシュを引き起こすローカライゼーションのバグや、コールドスタートのパフォーマンスを低下させるサードパーティ SDK などの重要な問題を特定して解決できます。CloudWatch Application Signals とのシームレスな統合により、モバイルユーザーエクスペリエンスからバックエンドの依存関係までのエンドツーエンドのトレースが可能になります。

この機能は、CloudWatch RUM が動作するすべての商用リージョンで利用できます。この実装により、チームは既存の開発ワークフローを維持しながらパフォーマンスデータを収集でき、アプリケーションスタック全体でトレースされたユーザーセッションからのメトリクスを使用して、組織がモバイルアプリ開発にアプローチする方法を変えます。

この新機能の詳細については、ドキュメントをご覧ください。また、Android および iOS の入門ガイドもご覧ください。最後に、料金 の詳細もご確認いただけます。


著者について

Ruchika Modi

Ruchika Modi

Ruchika Modi は、Amazon Web Services (AWS) の Lead DevOps Consultant です。クラウドインフラストラクチャ、自動化、コンテナ化、CI/CD を専門としています。安全でスケーラブルかつ高可用性のクラウドネイティブアーキテクチャの構築において豊富な経験を持ち、DevOps 手法を使用した最先端のクラウドソリューションの設計と実装に関する深い理解と専門知識を持っています。仕事以外では、未開拓の新しい場所への旅行、ペットとの時間、Kindle での読書を楽しんでいます。

Siva Guruvareddiar

Siva Guruvareddiar

Siva Guruvareddiar は、AWS の Senior Solutions Architect であり、お客様が高可用性システムを設計するのを支援することに情熱を注いでいます。マイクロサービス、コンテナ化、オブザーバビリティ、サービスメッシュ、クラウド移行を使用して、プラットフォームインフラストラクチャと内部アーキテクチャをモダナイズすることで、クラウドネイティブの採用を加速させます。LinkedIn で連絡できます: linkedin.com/in/sguruvar

Vijay Kumar

Vijay Kumar

Vijay Kumar は、セキュリティとオブザーバビリティの領域で革新的な製品を提供してきた実績を持つ Senior Product Manager であり、深い技術的専門知識とユーザー中心の設計を活用しています。


この記事は Kiro が翻訳を担当し、Solutions Architect の Aya Hara がレビューしました。