性能テスト

性能は、本番で確かめるものではありません。

負荷テストの計画とシナリオの策定から、試験基盤の構築、実施、レポート作成まで一貫してご支援します。 インフラを設計・構築している私たちが担当するため、結果の解釈から改善までが一本につながります。

THE PROBLEM

性能の問題は、いちばん直したくない時期に見つかります

リリース直前、あるいは本番稼働後。どちらも構成を変える余地が最も小さいタイミングです。

どこが遅いのか、切り分けられない

アプリなのか、データベースなのか、ネットワークなのか。層をまたいだ切り分けには、インフラ側の計測点を最初から用意しておく必要があります。

本番相当の負荷をかける環境がない

十分な負荷を生成するには、負荷側にもそれなりの構成が要ります。試験のためだけに用意して、終わったら畳む——その手間が後回しの理由になりがちです。

数字が残らず、次に活かせない

その場で確認して終わってしまうと、構成を変えたときに比較する基準がありません。条件と結果を記録して初めて、判断の材料になります。

TEST TYPES

4種類の試験に対応します

確かめたいことによって、かけるべき負荷のかたちは変わります。目的から逆算して設計します。

LOAD TEST

負荷試験

想定されるピーク負荷をかけ、応答時間・スループット・エラー率が要件を満たすかを確認します。

答えが出る問い 想定のアクセスを、いまの構成でさばけるか

STRESS TEST

限界試験

負荷を段階的に上げ、性能が頭打ちになる点と、そのとき何がボトルネックになっているかを特定します。

答えが出る問い どこまで耐えられるか/最初に何が音を上げるか

SOAK TEST

耐久試験

長時間にわたって負荷をかけ続け、メモリリークや接続の枯渇、時間とともに進む性能劣化がないかを確認します。

答えが出る問い 動かし続けても、性能が落ちていかないか

SPIKE TEST

スパイク試験

短時間で負荷が急増する状況を再現し、オートスケールが間に合うか、追従までの間に何が起きるかを確認します。

答えが出る問い 急に来ても、落ちずに追従できるか

HOW WE WORK

計画からレポートまで、5つの工程でご支援します

どの工程からでもご相談いただけます。試験基盤の構築だけ、レポートの読み解きだけ、という形も可能です。

  1. 01

    負荷テスト計画とシナリオの策定

    何を確かめたいのかを整理し、試験の種類・目標値・合格基準を決めます。あわせて、実際の利用のされ方に沿ったシナリオを設計します。

  2. 02

    負荷テスト基盤の構築

    必要な負荷を生成できる環境と、結果を計測するための仕組みを構築します。試験が終われば畳めるよう、コードで用意します。

  3. 03

    インフラ負荷試験の実施

    設計した条件で試験を実施し、各層のメトリクスを取得します。想定と違う結果が出た場合は、原因の切り分けまで行います。

  4. 04

    アプリケーション負荷試験の支援

    テストシナリオの草案は弊社からご提示します。実行環境の準備、試験中の計測、結果の読み解きはインフラ側の知見が要るところなので、そのまま弊社が担当します。実施そのものも、ご要望に応じて代行いたします。

  5. 05

    レポートの作成

    試験の条件、計測結果、合格基準に対する判定、ボトルネックの所在と改善の方向性をまとめてお渡しします。次に構成を変えたときの比較基準になります。

HOW WE ENGAGE

線を引くためではなく、確実に終わらせるために。

下記は標準的な進め方です。役割を固定したいわけではありません。 体制やご事情に合わせて、弊社が引き受ける範囲は調整できます。 アプリケーション側の実施まで含めた代行も承ります。

インフラの専門家として担当する範囲

  • 試験計画・合格基準の策定
  • アプリケーションテストシナリオの草案作成
  • 負荷テスト基盤の構築と撤去
  • インフラ負荷試験の実施
  • 計測・結果分析・ボトルネックの特定
  • レポートの作成

ご一緒に進めたい範囲

  • シナリオ草案のご確認と、業務実態に沿った補正
  • アプリケーション負荷試験の実施
  • 試験対象環境・テストデータのご準備
  • アプリケーション側の改修が必要になった場合の対応

アプリケーションの中身を最もよくご存じなのはご担当者さまです。 そのため草案を土台に一緒に仕上げる形が、最も精度が上がります。 とはいえ手が回らない場合は、実施まで弊社で引き取ることも可能です。

TOOLING

ツールは、要件に合わせて選定します

シナリオの複雑さ、必要な負荷の規模、その後の運用体制。この3点から、案件ごとに適したものを選びます。

Apache JMeter

GUI でシナリオを組めるため、開発チームとの共同作業や引き継ぎがしやすい構成です。

k6

シナリオを JavaScript のコードとして書けるため、CI/CD に組み込んで継続的に回す構成に向きます。

Gatling

少ないリソースで高い負荷を生成しやすく、大規模な負荷をかけたい場合の選択肢になります。

Locust

Python でシナリオを記述でき、既存の資産やチームのスキルセットに合わせやすい構成です。

いずれか一つに固定しているわけではありません。試験後もお客様側で回し続けたいのか、 今回限りで確認できればよいのか——その前提によって適したツールは変わるため、 計画の段階でご相談のうえ決定します。

いまの構成で、どこまでさばけるか。

試験の目的が固まっていない段階でも構いません。何を確かめるべきかの整理からご相談を承ります。

無料相談する → サービス一覧を見る →