この記事にはプロモーションが含まれていることがあります
最近、シリーズ物として執筆したWebシステムの性能テストツールとしてJMeterを紹介してきました。
そしたら、JMeter関係の記事、PVが良いので、きっとWebシステムの性能テストでお困りの方も多いのではないかと思い、性能テストのノウハウ的なものも書いてみようと思います。
システム開発で性能問題を起こさないにすべきこと
Webシステムでサービスを立ち上げる時、そのWebシステムがどれだけの負荷に耐えられるのか気になりますよね。
Webシステムは、ネットワーク上に設置して、いろいろな人がWebブラウザを使ってアクセスしてきます。Webシステムはいろいろな人からのリクエストを受け付けて、処理をしてレスポンスを返さなければなりません。
Webシステムの設計やプログラムコードに問題があったり、十分に性能を発揮できるインフラ設計をしないと、たくさんのリクエストを処理することができません。
システム稼動本番後に一般開放したところ、システム利用者が殺到してWebシステムがダウンした、というニュースもよく聞きますよね。
これはシステムの性能テストが十分実施されなかったか、或いは想定を超えてしまったのだと思います。
イントラネットに閉じた社内Webシステムや、身内しか使わない非公開Webシステムなど、リクエストがそれほど来ないシステムならあまり気にしなくてもよいかもしれませんが、インターネットに公開するWebシステムの場合はリクエストが殺到してもシステムが落ちないように確認しておく必要があります。
システム稼動本番を迎える前になにをすればよいのでしょうか。
それは、性能テストです！
性能テストって？
システム稼働本番前に大量のリクエストを処理できかどうかを試験する、それが性能テストと呼ばれるものです。負荷テストと呼ぶこともありますし、性能能試験、負荷試験と呼ぶこともあります。
この記事では「性能テスト」で統一します。
性能テストはいつやる？
システムテスト工程
性能テストはシステム開発工程でいうと、システムテスト工程という開発終盤で実施することが多いです。この工程で実施する理由は２つあります。
- 結合テスト工程が終わり、負荷を掛けなければ正常に動作するシステムが出来上がっている
- 本番相当のスペックの環境で実施することが多い
性能テストの実施には時間がかかります。
性能テストは大量のデータで長時間テスト実行を行うため、結合テスト工程で発生するような障害が残っているなどで負荷に関係ない障害が発生すると時間をロスしてしまいます。
また性能テストは本番環境と同等または近い環境で実施しないと意味がないためです。
単体テスト工程
大型のシステムのAPIなどは単体テスト工程でその機能単体での性能テストを実施しておくとよいでしょう。
システム開発の基本に、なるべく早い工程でできることは実施しておくというものがあります。
前の工程で問題をみつけて解消するほうが手戻りが少なくて済みます。
例えば、システムテスト工程で性能テストを実施した結果、性能が良くなかったとします。
ただ、原因を探っていくとある機能だけが著しく性能が悪かった、ということがよくあります。
この場合は、その問題のあった機能のプログラムに性能上の欠陥があることがほとんどです。これがシステム全体で見た時に枝葉の機能であればまだインパクトは少ないのですが、システム全体の基底処理や共通処理だった場合はシステム全体に影響があるため、大問題となります。
そして、それがシステム開発工程の終盤のシステムテスト工程で見つかるという事態は、システム開発スケジュール上の重大な問題に発展する可能性が高いです。
性能テストはどうやってやる？
Webシステムの性能テストは、JMeterというツールを使うと便利です。無料のツールなので、ダウンロードすれば使えます。
使い方についても書いていますので、興味のある方はご覧ください。
性能問題を起こさずにシステムを開発するには
それは、、、
システム開発に関わる関係者が性能を意識する。
これに尽きます。
これだけだとさすがに雑すぎると思いましたので、システム開発に関わるそれぞれのポジションで何を意識するとよいのか書いてみました。
システム発注者
システムベンダーに丸投げにしていませんか？
システムに対してきちんと責任を負う姿勢のベンダーや、技術力のあるベンダーであればその心配はあまりありません。
しかし、システムベンダーの中には作って納入したらおしまい、というスタンスだったり、そもそも技術力のないベンダーだと性能テストをなおざりにしたり、そもそもやらないかったりするケースがあります。
開発の見積もりやスケジュールに含まれているか確認しましょう。
非機能要件をベンダーに提示していますか？
ベンダーにシステム開発を依頼する場合は、SLA（Service Level Agreement）：サービスレベル合意書を提示してベンダーとすり合わせを行っておきましょう。性能品質定義はこの中の一つです。
大型のシステム案件ではSLAを双方合意がプロジェクト開始の前提となりますが、これを作るだけでもかなりのコストですので、小さいシステム開発案件ではSLAはつくらないことが多いです。
しかし、その場合でも要求はきちんと伝えて、品質はクリアしてもらうようにしましょう。
例えば利用想定者数が10,000人いるシステムを発注するのであれば、それを伝えてそこはクリアするように依頼しておきましょう。
ベンダー側見積もり担当者
発注元から性能要求はありましたか？
発注元からの性能要求を満たしたかを確認するために行う性能テストの工数を見積に含めるのを忘れないようにしましょう。
また性能要求がなかった場合でも、要求自体が無いということあまりなく、システム完成間近でいきなり要求をしてくることがよくあります。
発注元がシステム開発に詳しくない場合、悪気はなく、ただそこまで気が回らなかったので、逆にこちらから確認してあげる方がお互い幸せになると思います。
インフラコストは計算済みですか？
クラウド上にシステムを構築するのが主流です。
クラウドサービスは重量課金であるため、性能テストで大量のデータをデータベースに投入、大量のデータをフルスキャンするクエリの有無、ネットワークトラフィックの一時的な増加や、性能テスト環境として新しく専用のインスタンスを立ち上げるなど、様々なインフラコストが発生します。
これを見積もりに入れておかないと、品質を高めるためにテストをすればするほど利益を食いつぶすことになり、結果テストが十分に行われず最終的に本番障害が発生。
成果物責任を問われ開発費の減額、最悪損害賠償などに繋がりますので、気をつけましょう。
プロジェクトマネージャー
システム開発スケジュールに性能試験を組み込みましたか？
一般的にはシステムテスト工程ですが、システムテストではシナリオテストなども実施するため、直列で実施するのか並行で実施するのかでテスト期間や要員配置、テスト環境の準備なども変わってきますので注意が必要です。
性能テストでの障害は根が深いことがありますが考慮済みですか？
通常の動作では問題がないのに、高負荷の時に動作に問題が起きる、という類の障害は、障害の再現、原因の調査に思いの外時間を費やします。
また原因が特定できた場合でも、それがインフラのリソース不足やプログラムの単純バグならよいですが、選定したアーキテクチャに問題があったり、システム設計自体に問題がある場合は改修に大きな時間を要します。
システム開発終盤でこれが起きると、リリース日の延期や、それが無理な場合はデスマーチの始まりとなります。
システム開発担当者
データ量が多い場合を想定した設計ですか？
性能テストで問題となる原因として多いのが、データベース内のデータが少量の場合は問題ないのに大量のレコードを投入すると動かなくなるケースです。
検索処理などでデータベースから全件ネットワーク経由で取得してからヒットする情報だけを抽出するような処理や、フルスキャンしてしまっている場合は改善が必要です。
また、テーブル設計では性能を出すために敢えて正規化を崩すということも視野に入れる必要があります。
プログラミングにミスはありませんか？
プログラムのコードによくあるケースとしては、コードが冗長であったり、ループの無駄回しがあります。
同じ処理を複数回やっていたり、目的のデータが見つかっているのにループ処理を最後まで回しているなど無駄がないか確認が必要です。また、ループ処理がネストしている部分も本当に回す必要があるかどうか再チェックしてみましょう。
データベース検索クエリは正しく組み上がっていますか？
昔はSQLを直接書き上げたので問題ありませんでしたが、最近はフレームワークがデータオブジェクトをSQLに変換して処理してくれるものがあります。
SQL書かなくて済みますが、フタを開けると変なSQLを組み上がっていて、インデックスが効かずにフルスキャンになっている場合がありますので、最終的に実行されるSQLを確認するようにしましょう。
性能問題が発生してしまった場合
安易なインフラリソース強化は避ける
クラウド時代はオンプレと違っていつでもブラウザ上でマウス操作するだけで、サーバのリソースを強化できてしまいます。
よって、性能がでない場合でも最悪リソースを強化すれば解決できることがあります。但し、これは無駄な処理を行うためにリソースを強化して運用コストを無駄に上げてしまっている可能性があります。
もしシステムテスト工程で問題が発生したのであれば、先に記載した内容などを参考にして設計やプログラムを確認してみてください。
システム開発経験の浅い人が設計したものやプログラミングしたものは、まずは動くものを作る、というところに注力した結果、性能まで意識できていないことが多々あります。
もしシステム本番で性能問題が出てしまった場合、応急処置としてスケールアップやスケールアウトなどのリソース増強で一時凌ぎをしておき、落ち着いた状態でシステムのどこかに問題がないか探してみましょう。
きっとどこかにあると思います。
システムの作りに問題がないなら、リソース不足
もしどこにもシステム的な欠陥がないのであれば、単純にシステムリソースの準備が弱かったということになりますので、胸を張ってリソースの増強をしましょう。
まとめ
最後にまとめです。
システム開発中にはこの辺を意識していきましょう。
- システム発注者は、性能要件を提示しましょう
- 見積もり担当者は、性能テスト実施コストを見積もりに含めましょう
- プロジェクトマネージャーは、性能テストが効率よく実施できるようスケジュールしましょう
- システム開発担当者は、設計やコーディング時に処理性能を意識して作りましょう
性能テストで問題が発生したら次のポイントを確認しましょう。
- 安易なリソース増強はせず、まずは性能劣化の原因を突き止めましょう
- 性能劣化の原因を改善してもなお性能がでない場合はリソースを増強しましょう
そして、Webシステムの性能テストツールを探している方は、JMeterがオススメです。
コメント