モバイル開発におけるLoad Testとは何か、シナリオ、実施方法

Load Testとは何か？

Load Testは、システムが予期される同時アクセス数のリクエストやユーザーのもとでどのように動作するかを検証するプロセスです。モバイル開発の文脈では、Load Testはサーバーサイド (API、データベース、キャッシュ) とクライアントサイド (push通知処理、データ同期) の両方に適用されます。ストレステストとの主な違いは、Load Testが極端ではなく実際の負荷をシミュレーションすることです。AWS Well-Architected Framework (2024)により、負荷テストは実際の使用分析に基づいた負荷プロファイルを使用して実施する必要があります。

Load Testは、APIへのHTTPリクエスト、WebSocket接続、またはデータベーストランザクションのレベルで実施できます。目的は、各リクエストのレスポンス時間が指定された上限 (一般的にAPIの場合500–1000 ms) を超えず、スループット (RPS — 一秒間のリクエスト数) が要件を満たすことを確認することです。Google Cloud Armor (2024)は、パーセンタイルに基づいて上限値を定義しています: 重要なエンドポイントの場合、p95レスポンス時間は2秒を超えてはなりません。

モバイルバックエンドの負荷テストには、シナリオのシミュレーションが含まれます: 新規登録、認証、フィード読み込み、フォームの送信。シナリオはHARファイル (HTTP Archive) として記録され、負荷テストツールによって再生されます。k6のドキュメント (2025)によると、HAR変換によりLoad Testの準備時間を60%縮短できます。

負荷テストの目的

Load Testの第一の目的は、システムのスループットを確認することです。スペックが1000 RPSの処理を必要とする場合、負荷テストは20%の余裕をもって確認する必要があります。Netflix Tech Blog (2024)によると、Netflixではピーク負荷の2倍の余裕をもって負荷テストを実施しています: 10000 RPSが予測される場合、20000 RPSを検証します。このアプローチにより、突然のトラフィックのスパイクに対する精確性が確保されます。

第二の目的は、アーキテクチャのボトルネックを特定することです。モバイルバックエンドの典型的なボトルネックは、データベース (遅いクエリ)、キャッシュ (不正な無効化策略)、外部API (遅いサービス)です。分散トレーシング (Jaeger, Zipkin) は、特定のサービスやリクエストのレベルで問題を特定するのに役立ちます。

第三の目的は、飽和点 (saturation point) を決定することです。これは、新しいユーザーを追加してもスループットが向上しなくなる瞬間です。モバイルアプリケーションでは、飽和点はデータベースサーバーのCPU負荷が70–80%に達したときです。オートスケーリングは、この点に達する前に発動する必要があります。

負荷テストのシナリオ

スパイクテスト — 朝のpush通知やマーケティングキャンペーンの開始など、突然の活動のスパイクをシミュレーションします。Grafana k6 (2025)によると、Spike Testは30秒で負荷を100から10000 RPSまで増加させます。システムはリクエストを失わず、レスポンス時間が50%を超えないように処理する必要があります。

エンジュアランステスト — 負荷下での長時間動作におけるシステムの安定性を検証します。典型的な期間は1–4時間です。Endurance Testは、サーバーアプリケーションのメモリーリーク、データベース接続プールの問題、キャッシュパフォーマンスの急速な低下を示します。PostgreSQL接続プールは、適切な設定なしに長時間負荷がかかると、2–3時間で利用可能な接続を尽くす可能性があります。

ステップ負荷テスト — 2–5分ごとに10–20%ずつ負荷を段階的に増加させます。このシナリオは、システムが急速に劣化するまたごのレベルを見つけるのに役立ちます。InfluxDBとPrometheusは、各段階でメトリクスを収集し、レスポンス時間とRPSのグラフを作成します。

Load Testのメトリクス

レスポンス時間

レスポンス時間は、Load Testの主要メトリクスです。ミリ秒で測定され、パーセンタイルで分析されます: p50 (中央値)、p95、p99。Google SRE (2024)は、REST APIではp95が1000 msを超えないこと、gRPCで200 msを超えないことを推奨しています。パーセンタイルは平均値よりも重要です。なぜなら、ユーザーが最初に気付く最悪のリクエストの動作を示すからです。Apdex (アプリケーションパフォーマンス指数) は、満足しているユーザー、耐忍しているユーザー、不満のユーザーの割合を考慮した組み合わせメトリクスです。

スループット

スループット — 単位時間あたりの成功したリクエストの数。RPS (一秒間のリクエスト数) またはTPS (一秒間のトランザクション数) で測定されます。"時間 — RPS"の坐標でのスループットグラフは、飽和点まで線形である必要があります。負荷増加に伴うスループットの急速な低下は、システムがリミットに達したサインです。Apache Benchとwrkは、開発中にスループットを簡単に確認できるCLIツールです。

エラー率

エラー率 — 総リクエスト数のうちHTTPステータス4xxまたは5xxのレスポンスの割合。実用的な上限は1%未満です。高負荷下でのエラー429 (Too Many Requests) および503 (Service Unavailable) は、レートリミッティングとオートスケーリングの構成が必要であることを示しています。API Gatewayでのレートリミッターは、バックエンドを許容負荷を超えることから保護します。指数的バックオフ付きリトライ策略により、クライアントは一時的なエラーを適切に処理できます。

Load Testのためのツール

k6 (Grafana)

k6 — Grafanaによる主導的なオープンソースの負荷テストツール。スクリプトはJavaScriptで書かれ、モジュラーなシナリオ、スレッショルド、PrometheusやInfluxDBとの統合をサポートしています。k6はCLIおよびGrafana Cloud k6クラウドの両方で実行できます。Grafana Cloudは、Load Testの結果から自動的にダッシュボードを作成し、過去のデータと比較します。k6は、別途のk6/net/grpcモジュールを介してProtocol BuffersとgRPCをサポートしています。

Apache JMeter

Apache JMeter — グラフィカルインターフェイスを備えた、クラシックなLoad Testツール。HTTP、JDBC、JMS、FTP、TCPなど幅広いプロトコルをサポートしています。JMeterは複数のリクエストタイプを含む複雑なシナリオに適していますが、k6と比べてより多くの手動設定が必要です。JMeterプラグインは、WebSocketやgRPCのテスト機能を拡張します。分散実行には、JMeterは1つのコントローラーを持つマスタースレーブアーキテクチャを使用します。

Locust

Locust — Pythonベースのツールで、コードで負荷シナリオを記述できます。Locustは、Pythonを主なオートメーション言語として使用するチームに便利です。k6やJMeterとは異なり、Locustはボックスで分散実行をサポートしています: 1つのマスターノードが複数のワーカーノードを統括します。分散実行により、複数のマシンから100000 RPSまでの負荷を生成できます。Locustは、カスタム拡張を介してWebSocketテストもサポートしています。

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

k6でのLoad Test記述例

上記のk6スクリプトは、典型的な負荷テストの構造を示しています。Optionsは負荷プロファイルを定義します: 2分でランプアップして100ユーザーに達し、その後5分間定常負荷をかけ、さらにランプアップして200ユーザーに達します。スレッショルドは、テスト合格基準を定義します: p95リクエスト時間が500 ms以下、エラー率が1%未満。スレッショルドを超えた場合、k6は非ゼロのコードで終了します — これによりLoad TestをCI/CDに統合できます。

モバイル開発では、サーバーサイドのLoad Testは、追加の負荷を生み出す新しい機能 (いいね、コメント、ストリーミング) をローンチする際に特に重要です。推奨 — 本番環境にデプロイする前に、各stagingでLoad Testを実施してください。API設計階階でベースライン負荷プロファイルを作成すると、後の階階でのアーキテクチャ問題を避けることができます。