<< Javaヒープサイズのチューニングについて(世代別の場合) | main | 業務システム、またはSoRとSoEについて >>

スポンサーサイト

一定期間更新がないため広告を表示しています

| - | - | - |

ITシステムにおける性能試験について

はじめに

ITシステムは、単に動くだけではなく、本業務のピーク時に、目標の応答時間や単位時間当たりの業務処理量を達成する必要がある。また、初期構築から、次回のシステム更改時までのデータ保持量や、ログメンテナンスサイクル内でのログ量などの、キャパシティを満たす必要もある。

そのために実施するのが、性能試験だ。性能試験には、おおよそ、次の種類がある。

  • 単体性能試験
  • オンライン負荷試験
  • バッチ走行試験
  • ロングラン試験

テスト環境とテストデータについて

大前提として、性能評価のためには、基盤環境、業務アプリ、データを、本番相当にすることが必要だ。新規構築やシステム更改案件なら、構築中の本番化予定の環境で試験すべきである。

フェーズが早い、もしくは変更案件で本番環境は本業務サービス提供中で使えないなどの理由で、本番環境・本番化予定環境でテストができない場合は、ハードウェアとソフトウェアの技術的構成要素が、出来る限り本番環境と近しいテスト環境を、ステージング環境として用意する必要がある。

テストデータの観点では、レコード数、カーディナリティ、比率が、最も重要な要素となる。まれに、レコード数だけを本番相当にして満足している場合があるが、レコード数は一定量を超えたらあまり影響しなくなるので、特にカーディナリティと比率が重要だ。

品質の良いテストデータを生成することは非常に難しい営みとなる。単純な場合は、テストデータ生成プログラムを開発することが多いが、本番データをマスキングしてテストデータを生成することもある。

DBが複数存在するような大規模で複雑な場合は、本番データの中で大元になるデータをマスキングし、バッチを走行させて、各DBへバッチ処理後のデータを行き渡らせ、この処理で行き渡らない個別データは、ターゲットDBにて個別にマスキングすることになる。このデータを準本データと呼ぶことがあり、保守・運用サイクルの中では、定期的に準本データを最新化する必要がある。

データマスキングツールには色々あるが、複数のデータベース間で、識別子の一意性を保ってマスキングすることは難しいことから、このような営みが必要となる。

これは、かなり大規模な営みであり、高度に管理されたテスト環境が必要となることから、代替策として、本業務環境の統計情報をエクスポートして、テスト環境にインポートするだけのこともある。但し、テーブルレイアウトやインデックス有無などが変更される場合は、この方法は使えない。

単体性能試験

まず、単体性能試験は、SQLやトランザクションの単体試験の一環として実施する。機能確認試験に加えて、応答時間、メモリ使用量、アクセスパスなどを単体レベルで検証する。この試験では、網羅性目標を設けて、その目標を満たすようにケースを策定するほか、データを本番相当にすることが重要だ。

単体試験には、多くの開発者・開発チームが、各々独立して取り組むことになるので、UT完了のクライテリアとなるように開発規約に組み込むと共に、簡単かつ同じ品質で実施できるように、ツールを開発して提供することが望ましい(開発者の各々に、ログを見て評価してもらうことは、事実上できない)。

SQLについては、データを用意した上で、アクセスパス、読み込み量、応答時間などを評価することになるが、評価対象指標に閾値を設けて、超過したものだけ詳細に評価するプロセスが望ましい。ここでも、簡略化するためのツールの提供が望ましい。

オンライン負荷試験

次に、オンライン性能試験を、ITbのフェーズで実施することになる。概ねのスケジュールとしては、数週間テストケーススクリプトを作成・検証し、テストを一週間程度実施し、数週間、結果評価・チューニングした後、リトライして検証することになる。開発規模・変更規模に応じて、このサイクルを、何度か繰り返すことになる。

本業務サービス提供済みのシステムなら、次の2つの何れかの方針で、ベース負荷をかけることになる。これを実現するためには、何らかのツールの適用が必要になる。

  • ログからテストケーススクリプトのスケルトンを生成して、バインド値などを作りこむ。
  • 本業務サービス提供中のパケットをキャプチャして再生する。このためには、キャプチャ開始時のデータのバックアップを、テスト環境にロードする必要がある。

前者の場合は、ログから負荷ツール用のスクリプトを生成するプログラムの開発が必要になる。バインド値の設定など、人手の対応が多いので、100%再現することはできないため、「本業務サービス時の80%のリクエストを再現する、実行件数の多い上位20%の画面を再現する。全体の件数が100%となるように、全体を80%で割る(1.25倍する)」などの方針を設けて取り組むことになる。

後者の方が簡単そうに感じられるかもしれないが、本業務のパケットをキャプチャして再送する場合でも、リクエスト・レスポンス毎に動的に変動するパラメータ(カンバセーションIDなど)などの取り扱いに人手の対応が必要になり、本業務のデータをテスト環境にロードすることも、規模が大きくなるほど困難になる。

なお、本業務サービス提供時の振る舞いを再現するに当たっては、当該トランザクション実行時に同時に実行される予定の、オン中バッチについても、走行させることが必要だ。

上記のように、本業務サービス時のトランザクションミックス・負荷状況を再現できたら、次に、テスト対象のアプリ・時期による変動分を、作り込んで行く。たとえば、来年4月に本番化されるアプリの試験であれば、以下の対応が必要となる。

  • テスト環境に、来年4月リリース予定のアプリをデプロイする
  • 背景負荷となる本業務相当トランザクションミックスから、来年4月以降に追加・削除・変動する見込みのトランザクションを取り除く
  • 追加・削除・変動分のトランザクションを、負荷スクリプトとして開発して追加する

テストのやり方としては、まず、変更前のアプリに本業務サービス相当の負荷を掛けて、本業務サービス提供時の振る舞いを、ある程度満足できるだけ再現できることを確認してから、変更後のアプリをデプロイして、リリース後の本業務サービス提供時の見込みの負荷を掛けて、パフォーマンスとスループットを評価することになる。

本業務サービス提供中のシステムで、新規トランザクション追加・既存トランザクション変更が、少数である場合は、最初からトランザクションミックスの負荷を掛けずに、まず、追加・変更予定のトランザクション単体の負荷試験を実施して、当該トランザクション単独負荷でのパフォーマンス&スループットを評価することが望ましい。

バッチ走行試験

夜間バッチの場合は、オンライントランザクションよりも単純だ。業務処理量のピーク時相当のデータで、本業務サービス提供時と同じ種類のバッチを、同じ順序で、同じ多重度で走行させて、スループットとキャパシティを評価すればよい。

この際、データによって、個々のジョブユニットの走行時間や多重度が変動する可能性がある場合は、いくつかのデータのバリエーションで、走行試験を実施することが望ましい。

ロングラン試験

ロングラン試験は、長時間サービス提供を継続することで、メモリやファイルシステムが単調増加することがないかどうかを評価するために行う。

理想的には、日次・週次・月次のジョブおよび、オンライン負荷を、本番サービスイン後想定となるように、走行させることであるが、現実的には難しい、もしくはできないことが多い。

そのため、検証できる内容に制約が設けられることにはなるが、例えば、以下の方針で試験を実施することになる。

  • ジョブについては、データの繰り回しを含んだ機能確認試験の観点で、一週間程度、繰り回し試験を行う。
  • また、データの繰り回しを含まない空回しを、本番サービスイン前の1, 2ヶ月間以上、ST・運用試験として走行させる。
  • オンライン負荷については、参照系のトランザクションミックスを、数日から一週間程度、継続的に掛け続ける。

おわりに

開発工程標準の一部として、上記のような営みを定義することとあわせて、各工程で、品質と効率を向上させるためのツール適用、ツールと環境の結合・自動化が必要となる。

ツールの適用に当たっては、ツールと環境が利用できるようになっていれば良い、というものではなく、「使われているか、プロセスは遵守されているか」、「利用に当たって困難はないか」、「次のプロジェクトで再利用可能なアセットを抽出できないか」といった、技術的なサポートを提供する体制とセットで考える必要がある(参考)。

また、別の観点として、システムをテストしやすく作るということが挙げられる。テストは、テスト範囲が広ければ広いほど、幾何級数的に準備と結果検証の負担が高まる。一方、ハードウェアと、ソフトウエアの観点で共有するコンポーネントがない部分は、各々を独立してテストすることができる。

昔から、巨大なシステムは、手頃な範囲にサブシステム分割し、サブシステム間は互いに疎になるように結合することが推奨されてきた。現状においても、Systems of Record (SoR)かSystems of Engagement (SoE)か、SoRであればマスターデータのフローやクライアントチャネル、SoEであればAPI単位などに注目して、管理できる程度のサイズまで細かく、そして逆に細かくなり過ぎないように、分割することが必要だ。なお、API単位まで分割する場合は、人手で個別に管理することは困難になるので、テストを完全に自動化すべきだ。

性能試験は、一回、二回という単位で数えられるイベントではなく、数週間単位を何度か繰り返す、フェーズとして計画する必要がある。そして、性能試験を実施できるように、巨大なシステムは、凝集度が高くなるようにサブシステム分割し、サブシステム間の連携は、結合が疎になる方式で標準化すべきである。

| 日記 | comments(0) | trackbacks(0) |

スポンサーサイト

| - | - | - |
コメント



この記事のトラックバックURL
http://msugai.jugem.jp/trackback/1083
トラックバック
CALENDAR
Sun M T W T F Sat
    123
45678910
11121314151617
18192021222324
252627282930 
<< June 2017 >>
WATCH
SEARCH THIS BLOG
LATEST ENTRIES
CATEGORIES
SELECTED ENTRIES
RECENT COMMENTS
RECENT TRACKBACKS
Twitter
MY WEB SITES
PROFILE
ADMIN
MOBILE
qrcode
ARCHIVES
SPONSORED LINKS