最終更新日 2024年04月29日(月)

負荷テストを使用すると、実際のトラフィックの下でアプリケーションがどのように実行されるかを確認できます。新機能を公開する前に大規模にテストしたり、アプリをトラフィックの増加に備えて準備したりするには、負荷テストを実行します。

この記事では、負荷テスト環境を設定して、負荷テストを実行し、その結果を使用してアプリのパフォーマンスを向上させる方法について説明します。

負荷テスト環境を設定する

実際のユーザーへの影響を回避するために、個別の負荷テスト環境を設定します。

• 本番環境と同じ dyno タイプ​、dyno の数​、スタック​、ランタイム​を使用して、負荷テストのための個別のアプリ​を起動します。
• 負荷テストアプリをパイプラインに追加​して、それを本番環境アプリと共に表示します。
• 本番環境と同じプランを使用して、負荷テストアプリに個別の データサービス​ (Postgres、Redis、Kafka) を追加します。
• アプリが内部サービスまたは API に依存している場合は、可能であれば、そのサービスの個別のインスタンスをプロビジョニングします。

シードデータを追加する

アプリが Heroku Postgres​ に依存している場合、負荷テストアプリでは、シード​と呼ばれる、本番同様の (ただし、機密でない) データを含む独自のデータベースを使用する必要があります。

本番環境のデータの多様性を反映しており、本番同様の行数が存在するシードを作成します。個人情報または機密情報は含めないでください。

使用している言語またはフレームワークがシードにどのように対応しているかを調査します。次に例を示します。

• Ruby gem Faker​ や JavaScript/Node ライブラリ Faker.js​ は偽のデータを生成します。
• Rails​ や Node.js の Sequelize​ などのライブラリにはシードを記述するための規則があります。

ログ記録アドオンと監視アドオンをインストールする

負荷テストを実行する前に、負荷テストアプリにログ記録アドオンと監視アドオンをインストールします。これらのツールは、結果を評価するために使用します。

• ログ記録アドオン​は、テストのアプリおよびデータベースログを表示します。
• アプリケーションパフォーマンス監視 (APM) アドオン​ (New Relic、Scout、AppOptics など) は、時間のかかるエンドポイントやサービスを識別します。
• インフラストラクチャ監視アドオン​ (Librato や AppSignal など) は、アプリやデータベースへの負荷を測定します。

負荷テストツールを選択する

負荷テストツールはテストを実行して、負荷テストアプリ上のエンドポイントを突き止めます。Apache AB​ や JMeter​ などのオープンソースツールは、ローカルで、またはクラウド仮想マシン上で負荷テストを実行します。

負荷テストツールを設定する

負荷テストツールで、負荷テストでのトラフィックの量を指定します。たとえば、1 秒あたり X クライアントに合わせて設定します。負荷テストを現在の、または近い将来に予測される本番環境の負荷に一致させてください。

次に、テストにどのエンドポイントを含めるかを決定します。特定の機能をテストしている場合は、その機能のエンドポイントに焦点を絞ります。アプリ全体のスケーラビリティをテストしている場合は、APM ツールを使用して最も一般的で、最もレイテンシーの高いエンドポイントを見つけ、テストの焦点をそれらに置きます。

負荷テストを実行する

負荷テストツールを使用して、個別の負荷テストアプリ​でテストを実行します。

結果を使用してアプリのパフォーマンスを向上させる

負荷テストが終了したら、メトリクス内の以下の主なシグナルを探して、次の手順を決定します。これらの問題についての詳細は、テキスト内のリンクに従ってください。

応答時間

Heroku Dashboard でアプリに移動し、「Metrics」 (メトリクス)​ タブに移動します。応答時間のグラフ​をチェックし、95 パーセンタイルの応答時間に焦点を絞ります。それはテストの途中で増加するか、またはテスト中に急増していますか。

応答時間が増加している場合は、APM を使用して、どのサービスに問題があるかを判定します。たとえば、データベースが応答時間の大部分を占めていたことが示される可能性があります。最後に、APM をチェックして、テスト中に最も低速であったエンドポイントを見つけます。

増加した応答時間に対処するために、次のアクションを検討します。

• dyno をスケーリング​するか、または dyno タイプ​をアップグレードします。
• 並列性をチューニングします。Node​ および Ruby​ アプリに関するガイダンスを参照してください。
• APM で特に時間のかかるエンドポイントが検出された場合は、コードレベルの最適化に関するガイダンス​を参照してください。
• APM がテスト中にデータベースの速度が低下していることを示している場合は、「低速なクエリとデータベースの負荷​」を参照してください。

エラー

Heroku Dashboard のアプリの 「Metrics」 (メトリクス)​ タブで、スループットのグラフ​をチェックします。テスト中に 5xx failed​ 応答が増加したことを示していますか。その場合は、その期間中の Heroku エラーコード​に関するエラーのグラフ​をチェックします。

テスト中に増加したエラー率に対処するために、次のアクションを検討してください。

• H12 - Request timeout​ エラーが急増している場合は、「応答時間​」を参照し、リクエストタイムアウトに関する詳細を確認して​ください。
• R14 - Memory quota exceeded​ エラーが急増している場合は、「メモリ​」を参照してください。
• エラーがアプリから発信され、エラーのグラフには示されない場合があります。APM の失敗した応答をチェックし、エラー監視アドオン​を追加することを検討してください。

メモリ

メモリ使用がアプリのパフォーマンスに大きな影響を与え、応答時間を増加させる場合があります。

Heroku Dashboard でメモリ使用量​をチェックします。それはメモリ割り当てを満たしていますか、またはそれを超えていますか。ダッシュボードで、プラットフォームのエラー​に R14 - メモリ超過​エラーがあるかどうかをチェックします。

クォータを超えるメモリ使用と R14 エラーの結果に対処するために、次のアクションを検討してください。

• 設定をチューニングし、プロファイリングを実行することによって、アプリのメモリ使用量を最適化します。Ruby​、Node​、および Java​ アプリに関するガイダンスを参照してください。
• メモリの多い dyno タイプ​へのアップグレードを検討してください。

dyno の負荷

アプリへの Web リクエストは dyno によって処理されるため、負荷テストからの dyno レベルのメトリクスを調べることが重要です。

Heroku Dashboard で dyno の負荷​をチェックします。それは dyno タイプに推奨される dyno の負荷​を超えて急増していますか。

推奨される制限を超えている dyno の負荷に対処するために、次のアクションを検討してください。

• CPU の多い dyno タイプ​へのアップグレードを検討してください。
• dyno の負荷に影響を与える可能性がある並列性設定を評価します。Node​ および Ruby​ アプリに関するガイダンスを参照してください。

低速なクエリとデータベースの負荷

低速なクエリは、長期間にわたって発生する可能性があるため、本番環境で診断することが最適です。ただし、負荷の結果の中にヒントが見つかることがあります。

APM の負荷テストの時間中に低速なクエリがあるかどうかをチェックします。ログツールで、2 秒を超えるクエリに対して存在するクエリ期間のログ​を探します。

Librato などのプラットフォーム監視ツールを使用してデータベースの負荷を確認します。それが 1​ を超えている場合は、クエリのパフォーマンスに影響を与える可能性があります。

低速なクエリまたはデータベースの高い負荷に対処するために、次のアクションを検討してください。

• 実行速度の遅い特定のクエリを最適化​します。
• より高い Heroku Postgres プラン​へのアップグレードを検討してください。