モバイル開発におけるストレステスト：定義、目的、実施方法

Stress Testとは

Stress Test（ストレステスト）— 設計値を超える条件下でシステムが動作する能力を評価するプロセスです。モバイルアプリケーションの場合、通常1000のところを10000の同時プッシュ通知、バックエンドの場合、期待値5000に対して50000 RPSが該当します。Load Testとの主な違いは、目標がパフォーマンスの確認ではなく、設計能力を超えたシステムの動作を研究することです。Netflix Engineering (2024) はStress Testを“システムが予測可能な方法で故障するという仮説の検証”と定義しています。

ストレステストには2つの必須段階があります：障害までの負荷と復旧の観察です。復旧（recovery）— 過負荷解除後にシステムが正常動作に戻る能力。再起動なしで復旧できないシステムは、短期的な過負荷に耐えられたとしても脆弱と見なされます。AWS Well-Architected Framework (2024) によると、Stress Test後の復旧時間は5分を超えてはいけません。

モバイルクライアントの場合、Stress Testにはプロセスの強制終了、ネットワーク切断、RAM枯渇時の動作確認が含まれます。Android Low Memory Killer はRAM不足時にバックグラウンドプロセスを終了する可能性があります — ストレステストでは、そのような終了後もアプリケーションが状態を適切に復旧できることを確認する必要があります。Apple UIKit (2024) は、アプリケーションの各画面でメモリ警告シナリオをテストすることを推奨しています。

ストレステストの目的

障害点の特定

Stress Testの第一の目的は障害点の特定（breaking point）です。これは、主要なパフォーマンス指標のいずれかがクリティカルなしきい値を超えた瞬間です：p95応答時間が10秒超過、HTTP 5XXエラー率5%超過、またはスループットがベースラインの50%未満に低下。障害点を記録することで、チームは事前にシステムのスケーリング限界を知ることができます。Capacity planning は、Load TestではなくStress Testのデータに依存します。Load Testは限界条件をチェックしないためです。

復旧メカニズムの確認

第二の目的は復旧メカニズムの確認です。負荷が通常レベルに低下した後、システムは正常な指標に戻る必要があります。データベースへの接続プールが解放されない、キャッシュが無効化されない場合、Stress Testがこの問題を特定します。Circuit breaker（Hystrix、Resilience4j）は過負荷時に作動し、安定化後に自動的に接続を復旧する必要があります。Health check エンドポイントは、テスト中の各サービスの状態監視に役立ちます。

Auto-scalingの検証

第三の目的はauto-scalingの検証です。インフラストラクチャがKubernetesやAWS Auto Scalingを使用している場合、Stress Testは新しいpodやインスタンスが十分に速く作成されるかを確認します。Google Kubernetes Engine (2024) によると、HPA（Horizontal Pod Autoscaler）メトリックトリガーから新しいpodのデプロイまで30秒を超えてはいけません。HPA はCPU、メモリ、カスタムメトリックに基づいてスケーリングする必要があります。Cluster Autoscalerは、現在のノードがpodを収容できない場合に新しいノードを追加します。

Stress Testの方法論

段階的な負荷増加（Ramp-up Stress Test）— 最も一般的なシナリオ。初期負荷は期待値の50%に設定され、その後2分ごとに10%ずつ増加し、システムが故障するまで続けます。このシナリオにより、耐障害性の正確な限界を見つけることができます。Grafana Cloud k6 (2025) は、応答時間の滑らかなグラフを得るために10%以上の増加を推奨していません。

急激な負荷スパイク（Spike Stress Test）— 負荷が10%から500%に10～30秒で増加します。このシナリオは、バイラルコンテンツの拡散やDDoS攻撃などの状況をモデル化します。Spike Stress Testはパフォーマンスよりも、システムの生存性をテストします：完全に停止せず、安定化後に動作に戻る能力です。API Gateway は、急激なスパイクからバックエンドを保護するためにレート制限を設定する必要があります。

長時間の過負荷維持（Sustained Stress Test）— システムを30～60分間過負荷状態に維持します。このシナリオは、短期間のテストでは現れないリソースリークを発見します。メモリリーク はJava/Kotlinアプリケーションで20～40分の集中的な動作で蓄積され、Sustained Stress Testのみで検出できます。

障害点と復旧の分析

障害点は3つの基準で決定されます：応答時間、エラー率、スループット。通常、最初に応答時間のしきい値を超えます — リクエストの処理が設定された制限時間を超えます。次にエラー率が上昇します：サーバーがリクエストを処理できず503を返します。最後にスループットが低下します — システムは最小限の負荷にも対応できなくなります。障害点のメトリックは、キャパシティ計画のために負荷プロファイルに記録されます。

復旧の分析には3つのフェーズがあります：即時反応（負荷解除後最初の30秒）、安定化（1～5分）、完全復旧（5～30分）。即時反応フェーズでは、応答時間がベースラインを下回る必要があります — システムがキューから解放されます。これが起こらない場合、問題は負荷ではなく蓄積された状態にあります。Graceful degradation — 過負荷時にシステムが部分的な機能を維持する能力 — はアーキテクチャの成熟度を示す重要な指標です。

Chaos Engineeringは、意図的な障害の導入によってStress Testを補完します：データベースサーバーの停止、ネットワーク遅延、マイクロサービスの停止。Chaos Monkey（Netflix、2024）は本番環境でランダムにプロセスを終了し、システムの耐障害性をテストします。モバイルアプリケーションの場合、Chaos Engineeringは次のシナリオのテストを意味します：ネットワーク不在、API利用不可、空のサーバーレスポンス。

Stress Testのツール

ramping-arrival-rate対応のk6

k6 は、ramping-arrival-rate設定の`execution`モジュールを通じてStress Testをサポートしています。このモードは、各リクエストの実行時間に関係なく1秒あたりのリクエスト数を増加させます。Load Testと比較して、k6でのStress Testではよりアグレッシブなしきい値設定と、急激な障害をシミュレートするためのgracefull-stopの無効化が必要です。Grafana Cloudは応答時間グラフの折れ点から自動的に障害点を検出します。k6-operator for Kubernetesを使用すると、クラスターから分散Stress Testを実行できます。

Ultimate Thread Group対応のJMeter

JMeter は、Ultimate Thread Groupプラグインを通じてStress Testを設定できます — このプラグインはテーブル形式で負荷プロファイルを定義します：スレッド数、ウォームアップ時間、保持時間、クールダウン時間。Ultimate Thread Groupは複雑なマルチフェーズシナリオに便利です。JMeter Backend Listener は、障害点グラフ作成のためにInfluxDBにメトリックを送信します。Stress Testでは、過負荷時の動作をより正確に測定するためにJMeterの接続タイムアウトを無効にすることを推奨します。

Chaos EngineeringのためのGremlin

Gremlin — インフラストラクチャのStress TestのためのChaos Engineeringプラットフォーム。Gremlinはネットワークの切断、CPUへの負荷、ディスクの満杯化、Kubernetesの個別podでのプロセス終了を可能にします。SREチームはGremlinをk6と組み合わせて包括的なStress Testを実施します：k6が負荷を生成し、Gremlinが障害を導入します。Game Day — Gremlinを使用した定期的なStress Testセッションで、システムの耐障害性分析のために“chaos report”に文書化されます。

k6でのStress Testの例

以下のk6スクリプトは、障害まで負荷を段階的に増加させるStress Testを示しています。Ramping-arrival-rate は、各リクエストの実行時間に関係なく1秒あたりのリクエスト数を増加させます。しきい値はアグレッシブな劣化検出用に設定されています：p95は2000 ms以内、エラーレートは5%以内。しきい値を超えるとk6はエラーコードでテストを終了し、Stress TestをCI/CDパイプラインに組み込むことができます。

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

export const options = {
    scenarios: {
        stress: {
            executor: 'ramping-arrival-rate',
            startRate: 50,
            timeUnit: '1s',
            stages: [
                { duration: '2m', target: 200 },
                { duration: '5m', target: 500 },
                { duration: '2m', target: 1000 },
            ],
            preAllocatedVUs: 50,
            maxVUs: 200,
        },
    },
    thresholds: {
        http_req_duration: ['p(95)<2000'],
        http_req_failed: ['rate<0.05'],
    },
}

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

ストレステストのベストプラクティス

stagingでStress Testを開始する — 本番環境でのストレステストには高度なモニタリングとロールバック計画が必要です。Google SRE (2024) は、アーキテクチャと能力において本番環境を再現する100%分離された環境でStress Testを実施することを推奨しています。stagingでのテスト成功後、SREの監視下で本番環境に移行できます。Feature flag による過負荷時の機能停止 — 必須の要素です。

CI/CDでStress Testを自動化する 障害点の回帰分析のため。新しいバージョンのアプリケーションの障害点が以前より20%低い場合、これはリリース前に修正すべき回帰です。Baseline breaking point はメトリックに保存され、各Stress Testの結果と自動的に比較されます。障害点が10%低下するとアラートが作動します。

各Stress Testを文書化する：負荷プロファイル、障害点、復旧動作、発見された問題のリスト。Netflix Engineering (2024) は“Game Day”を実施しています — 定期的なStress Testセッションで、その結果は“chaos report”に文書化されます。ストレステストレポート には、障害点がマークされた“RPS — 応答時間”グラフを含める必要があります。