クラウドエンジニア、初めての性能試験に挑む！

Transcript

1. クラウドエンジニア、初めての性能試験に挑む！ ～NRIネットコム TECH AND DESIGN STUDY #29～ 2024年4月25日 NRIネットコム株式会社 クラウド事業推進部 今村 陽心
2. 1 Copyright（C） NRI Netcom, Ltd. All rights reserved. 自己紹介 1 性能試験とは 2 性能試験のアプローチ方法 ～体験談を添えて～ 3 さいごに 4 2.1. 性能試験とその目的 2.2. 性能試験の全体像 3.1. システムの性能要件を定義しよう 3.2. 性能目標の指標 3.3. 性能試験の準備 3.4. 性能試験の実施と評価 3.5. 性能試験の結果を顧客に報告
3. 2 Copyright（C） NRI Netcom, Ltd. All rights reserved. ◼ 経歴 ⚫ 2020年3月 大学卒業 • 化学系、毎日液晶材料にレーザーあててました ⚫ 2020年4月 SIer 新卒入社 • 中央省庁業務システムの保守、運用（1.5年） • ネットワーク維持管理（0.5年） ⚫ 2023年1月 NRIネットコム 中途入社 • AWSを活用した顧客システムの設計、開発、構築に従事 ◼ 資格 ⚫ AWS認定 • 12個 ⚫ 高度情報処理技術者 • ネットワークスペシャリスト（NW） ⚫ その他 • 200-301 CCNA（Cisco） • ITIL 4 Foundation（運用系） ◼ 趣味：ゴルフ、筋トレ 1. 自己紹介
4. 3 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2. 性能試験とは
5. 4 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2.1. 性能試験とその目的 2. 性能試験とは ◼ 性能試験（負荷テスト、パフォーマンステストとも呼ばれます）とは、設計/構築したシステムに対して一定の高負荷をかけ、 「要件どおりの性能を満たしているかどうか」、「どのくらいの負荷までなら耐えられるのか」を確認する工程 • 一般的にV字モデルの総合テストの一環として性能試験が行われる • 要件定義フェーズで決定した機能/非機能要件を満たし、性能的な 問題がないかどうかを確認することが性能試験の目的と言える 実装 単体テスト 詳細設計 要件定義 総合テスト 結合テスト 基本設計 V字型モデル
6. 5 Copyright（C） NRI Netcom, Ltd. All rights reserved. 2.2 性能試験の全体像 2. 性能試験とは ◼ 性能試験の全体像を一般的なシステム開発の工程をベースにご紹介します ビジネス システム要求事項検討 要件定義 方式/詳細設計 基盤構築 基盤テスト 総合テスト インフラ構築 テスト 運用 サービス ※インフラ開発と並行して別軸でのアプリ開発があり、総合テストで合流 ▪発注者 RFP（提案依頼書）等で発注するシステムの利用 規模や求める性能・拡張性などの非機能要件を開 発者に伝える ▪発注者、開発者（アプリ、インフラ） ・要求された非機能要求を定量的な性 能目標に変換する ・性能試験で必要になる試験シナリオに ついて大まかな認識を合わせておく ▪開発者（アプリ、インフラ） ・必要に応じて本番同等の性能試験用 環境を構築 ・利用する試験ツールを準備 ・試験シナリオと必要なダミーデータを作成 ▪開発者（アプリ、インフラ） ・性能試験を実施し、その結果を評価 ・ボトルネックの切り分けと環境を修正 ▪開発者（アプリ、インフラ） ・性能試験の結果を顧客に報告 • テスト工程以外でも対応しておくべきことはたくさんある • 性能試験の主な対応である試験シナリオの作成、試験の実施/評価、ボトルネックの修正は数日でできるものではない • 性能試験工程を少なくとも1カ月程度組み込んだシステム開発スケジュールをたてておくことが大事
7. 6 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3. 性能試験のアプローチ方法 ～体験談を添えて～
8. 7 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3.1. システムの性能要件を定義しよう 3. 性能試験のアプローチ方法 ◼ まずは作りたいシステムの要件を整理しておきましょう ビジネス システム要求事項検討 要件定義 方式/詳細設計 基盤構築 基盤テスト 総合テスト インフラ構築 テスト 運用 サービス ※インフラ開発と並行して別軸でのアプリ開発があり、総合テストで合流 ▪発注者 RFP（提案依頼書）等で発注するシステムの利用 規模や求める性能・拡張性などの非機能要求を開 発者に伝える ▪発注者、開発者（アプリ、インフラ） ・非機能要求を定量的な性能目標に変 換する ・性能試験で必要になる試験シナリオに ついて大まかな認識を合わせておく ▪開発者（アプリ、インフラ） ・必要に応じて本番同等の性能試験用 環境を構築 ・利用する試験ツールを準備 ・試験シナリオと必要なダミーデータを作成 ▪開発者（アプリ、インフラ） ・性能試験を実施し、その結果を評価 ・ボトルネックの切り分けと環境を修正 ▪開発者（アプリ、インフラ） ・性能試験の結果を顧客に報告
9. 8 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3.1. システムの性能要件を定義しよう 3. 性能試験のアプローチ方法 ◼ 非機能要求とは ビジネス システム要求事項検討 要件定義 方式/詳細設計 基盤構築 基盤テスト 総合テスト インフラ構築 テスト 運用 サービス ※インフラ開発と並行して別軸でのアプリ開発があり、総合テストで合流 ▪発注者 RFP（提案依頼書）等で発注するシステムの利用 規模や求める性能・拡張性などの非機能要求を開 発者に伝える ▪発注者、開発者（アプリ、インフラ） ・非機能要求を定量的な性能目標に 変換する ・性能試験で必要になる試験シナリオに ついて大まかな認識を合わせておく ▪開発者（アプリ、インフラ） ・必要に応じて本番同等の性能試験用 環境を構築 ・利用する試験ツールを準備 ・試験シナリオと必要なダミーデータを作成 ▪開発者（アプリ、インフラ） ・性能試験を実施し、その結果を評価 ・ボトルネックの切り分けと環境を修正 ▪開発者（アプリ、インフラ） ・性能試験の結果を顧客に報告 （出典）システム構築の上流工程強化（非機能要求グレード）紹介ページ https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
10. 9 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3.1. システムの性能要件を定義しよう 3. 性能試験のアプローチ方法 ◼ まずは作りたいシステムの要件を整理しておきましょう ビジネス システム要求事項検討 要件定義 方式/詳細設計 基盤構築 基盤テスト 総合テスト インフラ構築 テスト 運用 サービス ※インフラ開発と並行して別軸でのアプリ開発があり、総合テストで合流 ▪発注者 RFP（提案依頼書）等で発注するシステムの利用 規模や求める性能・拡張性などの非機能要求を開 発者に伝える ▪発注者、開発者（アプリ、インフラ） ・非機能要求を定量的な性能目標に 変換する ・性能試験で必要になる試験シナリオに ついて大まかな認識を合わせておく ▪開発者（アプリ、インフラ） ・必要に応じて本番同等の性能試験用 環境を構築 ・利用する試験ツールを準備 ・試験シナリオと必要なダミーデータを作成 ▪開発者（アプリ、インフラ） ・性能試験を実施し、その結果を評価 ・ボトルネックの切り分けと環境を修正 ▪開発者（アプリ、インフラ） ・性能試験の結果を顧客に報告
11. 10 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3.1. システムの性能要件を定義しよう 3. 性能試験のアプローチ方法 ◼ 性能試験の目的は、設計/構築したシステムに対して一定の高負荷をかけ、「要件どおりの性能を満たしているかどうか」、 「どのくらいの負荷までなら耐えられるのか」を確認する工程 • 一般的にV字モデルの総合テストの一環として性能試験が行われる • 要件定義フェーズで決定した機能/非機能要求を満たし、性能的な 問題がないかどうかを確認することが性能試験の目的と言える 実装 単体テスト 詳細設計 要件定義 総合テスト 結合テスト 基本設計 V字型モデル 再掲
12. 11 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3.1. システムの性能要件を定義しよう 3. 性能試験のアプローチ方法 ◼ 性能試験の目的は要件定義で決めた要件を満たしていることの確認 後々の性能問題や認識相違を防ぐために非機能要求として性能要件を定義しておく • 一般的にV字モデルの総合テストの一環として性能試験が行われる • 要件定義フェーズで決定した機能/非機能要求を満たし、性能的な 問題がないかどうかを確認することが性能試験の目的と言える 実装 単体テスト 詳細設計 要件定義 総合テスト 結合テスト 基本設計 つまり、要件定義フェーズでは性能試験で確認すべき性能目標（ゴール）をできるだけ定量化しておくとよい V字型モデル • この工程から性能試験の話題を出しておくとよい • 性能試験のスケジュールを確保しやすい • 機能に対するイメージがわきやすい
13. 12 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3.2. 性能目標の指標 3. 性能試験のアプローチ方法 ◼ 性能目標や性能試験全体を通して理解しておくべき指標「レスポンスタイム」と「スループット」 ・レスポンスタイム（response time） 辞書的には「応答」「反応」「返答」といった意味を持つ英単語で、性能試験的には「どれだけ素早く反応を返せるか」を 測るための指標 ・スループット（throughput） 辞書的にはスループット、処理量といった意味で、性能試験的には「一度にどれだけの量を処理できるか」を測るための指標 運ぶ人数が増加！ 比例してスループットは2倍 走って速度2倍！比例してレスポンスタイムが2倍向上 レスポンス、スループットがそれ2倍となり、 同じ時間で運べる数は元の4倍！
14. 13 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3.2. 性能目標の指標 3. 性能試験のアプローチ方法 ◼ スループットとレスポンスの関係 アクセス数を増加させながら、レスポンスタイムとスループットをプロットしたグラフ 0 500 1000 1500 2000 2500 3000 3500 4000 0 20 40 60 80 100 120 0 200 400 600 800 1000 1200 Response(ms) Throughput(tps) アクセス数 レスポンスとスループットの関係 Throughput(tps) Responsetime(ms) 条件：1秒以内のレスポンス 処理量：増加 レスポンスタイム：横ばい 性能の限界 処理量：横ばい レスポンスタイム：増加 ◼ 多重度 同時接続数やシステムの処理数の並列度として用いられる指標ですが、扱いには注意が必要 例）「100 人が同時に接続している」というシナリオ ①各ユーザーが 1 秒おきにリクエストを発行する ②10 秒おきにリクエストを発行する ⇒スループットが 10 倍異なります。 • リクエスト発行の間隔や、シナリオ内のシンクタイム の有無で得られる結果は全く異なる
15. 14 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3.3. 性能試験の準備 3. 性能試験のアプローチ方法 ◼ 性能試験に必要なリソースやデータの準備を行いましょう ビジネス システム要求事項検討 要件定義 方式/詳細設計 基盤構築 基盤テスト 総合テスト インフラ構築 テスト 運用 サービス ※インフラ開発と並行して別軸でのアプリ開発があり、総合テストで合流 ▪発注者 RFP（提案依頼書）等で発注するシステムの利用 規模や求める性能・拡張性などの非機能要求を開 発者に伝える ▪発注者、開発者（アプリ、インフラ） ・非機能要求を定量的な性能目標に変 換する ・性能試験で必要になる試験シナリオに ついて大まかな認識を合わせておく ▪開発者（アプリ、インフラ） ・必要に応じて本番同等の性能試験用 環境を構築 ・利用する試験ツールを準備 ・試験シナリオと必要なダミーデータを作成 ▪開発者（アプリ、インフラ） ・性能試験を実施し、その結果を評価 ・ボトルネックの切り分けと環境を修正 ▪開発者（アプリ、インフラ） ・性能試験の結果を顧客に報告
16. 15 Copyright（C） NRI Netcom, Ltd. All rights reserved. ◆ 性能試験を実施する環境構築 ⚫ 環境差分による障害発生を防ぐために、性能試験は本番環境もしくは本番と同等の環境で実施しましょう ✓ 本番環境でないと再現しない事象 ✓ 基盤スペックは向上しているはずが、他の設定には悪影響だった ⚫ 構築した環境に負荷をかけるクライアントと経路の作成 ✓ NW経路や許可設定の追加などインフラ構成の一時的な変更が必要 ✓ 負荷生成ツール選定と初期設定 ◆ 負荷生成に必要なデータ準備 ⚫ 負荷生成ツールに実行させたい操作をシナリオスクリプトとして作成 ✓ 運用開始後に想定される実際の操作に基づいて作成します ⚫ ダミーデータの作成 ✓ 例）操作させたいログインさせたい人数分のユーザーダミーデータが必要 3.3. 性能試験の準備 3. 性能試験のアプローチ方法 ◼ 性能試験を実施する環境と実施するために必要な道具を準備します • 動作確認も含め、本番環境で性能試験 を実施 • クライアント側がボトルネックにならないよ うに、ある程度のスペックは必要 • 使いこなせるようになるまでに時間がかかる • シナリオスクリプトは利用者になりきって シンクタイム等を考慮して作成する
17. 16 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3.4. 性能試験の実施と評価 3. 性能試験のアプローチ方法 ◼ 性能試験を実施し、その結果を評価しましょう ビジネス システム要求事項検討 要件定義 方式/詳細設計 基盤構築 基盤テスト 総合テスト インフラ構築 テスト 運用 サービス ※インフラ開発と並行して別軸でのアプリ開発があり、総合テストで合流 ▪発注者 RFP（提案依頼書）等で発注するシステムの利用 規模や求める性能・拡張性などの非機能要求を開 発者に伝える ▪発注者、開発者（アプリ、インフラ） ・非機能要求を定量的な性能目標に変 換する ・性能試験で必要になる試験シナリオに ついて大まかな認識を合わせておく ▪開発者（アプリ、インフラ） ・必要に応じて本番同等の性能試験用 環境を構築 ・利用する試験ツールを準備 ・試験シナリオと必要なダミーデータを作成 ▪開発者（アプリ、インフラ） ・性能試験を実施し、その結果を評価 ・ボトルネックの切り分けと環境を修正 ▪開発者（アプリ、インフラ） ・性能試験の結果を顧客に報告
18. 17 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3.4. 性能試験の実施と評価 3. 性能試験のアプローチ方法 ◼ 性能試験を実施し、その結果を評価しましょう ◆ 性能試験の実施 ⚫ 「段取り八分」といった言葉がありますが、性能試験の実施はまさにこの言葉のとおりです 性能試験を実施する環境が整っていて、実行するシナリオスクリプト、ダミーデータがあれば後は実行ボタンを押す だけです ◆ 性能試験の結果を評価してボトルネックを解消する ⚫ 各試験項目が性能要件を満たしているか ⚫ リソースが想定どおり消費されているか本番環境でないと再現しない事象 ✓ 基盤スペックは向上しているはずが、他の設定には悪影響だった • 試験によっては数日かけて実行するものがあり、週末も組み込んだスケジュー ルを立てると時間の有効活用が可能 • 同じ試験でもシナリオを変化させながら、複数パターン実施することになる • 実施環境のリセットやチューニングなどを実施するため、慣れていないと 1シナリオ1日と考えておいた方がよい • キャッシュが上手く利用できない事象に直面し、原因の特定に2, 3週間かかった • 原因調査は多くの複数のステークホルダーへの確認が必要になるため、コミュニケーションコストが大きい
19. 18 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3.4. 性能試験の実施と評価 3. 性能試験のアプローチ方法 ◼ 代表的な性能試験をいくつかご紹介します ①ピークテスト：予想される最大同時アクセス数において、目標時間内にレスポンスが返却されるか ⇒要件定義フェーズで決定した非機能要求を満たしていることを確認することが主な目的 ②限界性能テスト：目標レスポンスタイムを維持しながら、どのくらいのアクセス数に耐えられるのか ⇒最大性能とボトルネックを把握することが主な目的 0 500 1000 1500 2000 2500 3000 3500 4000 0 20 40 60 80 100 120 0 200 400 600 800 1000 1200 Response(ms) Throughput(tps) アクセス数 レスポンスとスループットの関係 Throughput(tps) Responsetime(ms) ①顧客からの非機能要求を満たしているかどうか ・前年度の実績から予想最大同時アクセス数は600件/分 ・上記の条件下で1秒以内のレスポンスが必須 ③ヒートラン：長時間負荷をかけ続けたとしても性能劣化が起きないかどうか ⇒メモリリークが発生していないか、不要なプロセスが残り続けていないかなど想定どおりの挙動かどうか ②構築した環境の限界が知りたい • 各MWの仕様を把握しておかないと、なぜ このタイミングでメモリに余裕ができたのか迷宮入りする • 各MWのconf設定どおりかどうかを確認できる
20. 19 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3.5. 性能試験の結果を顧客に報告 3. 性能試験のアプローチ方法 ◼ まずは作りたいシステムの要件を整理して具体的な性能目標に落とし込む ビジネス システム要求事項検討 要件定義 方式/詳細設計 基盤構築 基盤テスト 総合テスト インフラ構築 テスト 運用 サービス ※インフラ開発と並行して別軸でのアプリ開発があり、総合テストで合流 ▪発注者 RFP（提案依頼書）等で発注するシステムの利用 規模や求める性能・拡張性などの非機能要求を開 発者に伝える ▪発注者、開発者（アプリ、インフラ） ・非機能要求を定量的な性能目標に変 換する ・性能試験で必要になる試験シナリオに ついて大まかな認識を合わせておく ▪開発者（アプリ、インフラ） ・必要に応じて本番同等の性能試験用 環境を構築 ・利用する試験ツールを準備 ・試験シナリオと必要なダミーデータを作成 ▪開発者（アプリ、インフラ） ・性能試験を実施し、その結果を評価 ・ボトルネックの切り分けと環境を修正 ▪開発者（アプリ、インフラ） ・性能試験の結果を顧客に報告
21. 20 Copyright（C） NRI Netcom, Ltd. All rights reserved. 3.5. 性能試験の結果を顧客に報告 3. 性能試験のアプローチ方法 ◼ 顧客の一番の関心は、運用開始後に想定どおりの性能でシステムが動くのかどうか ◆ どんな試験をどのようなシナリオで実施したのか ⚫ 性能試験の目的を網羅している ⚫ 実運用を考慮している ◆ 顧客の要求を満たしているか ⚫ Yes / No ⚫ 要求を満たしていることを裏付けるデータ ◆ 性能試験で発見された問題について ⚫ 課題とその原因 ⚫ どのように解消したか ⚫ 問題を取り除いたことで性能が改善しているか • ビジネス的な観点で試験を実施したことを伝える • 不信感を与えないためにも、具体的な数値やグラフは報告資料に添付しておく • 現在の構成におけるボトルネック • 上記を解消するためのスケーリング方針なども報告しておく
22. 21 Copyright（C） NRI Netcom, Ltd. All rights reserved. 4. さいごに
23. 22 Copyright（C） NRI Netcom, Ltd. All rights reserved. ◼ さいごに 今回はシステム開発工程における性能試験とは何なのか、性能試験はどう進めたらよいのかを中心にお話させていた だきました。 システムの品質や信頼性を保証することは、顧客のビジネス目標を達成するためには必要不可欠であり、性能試験 はシステムが期待通りに動作し、ユーザーがスムーズにシステムを利用できるかどうかを確認する重要なステップと言えま す。 今回ご紹介できていない性能試験の重要な考え方や実践的な内容は下記参考文献やサイトに掲載されています。 本日の勉強会が性能試験に対する学習を始めるきっかけになれば幸いです。 ◼ 参考文献 ⚫ 絵で見てわかるシステムパフォーマンスの仕組み • 小田 圭二／岡田 憲昌／榑松 谷仁／平山 毅 著 • 翔泳社（ISBN：9784798134604） ◼ 実際に性能試験を実施するときに参考になるサイト ⚫ シナリオ作成入門（株式会社ディーネットが負荷テストについての情報を発信しているサイト） • https://ptune.jp/tech/introduction-to-jmeter-scenario-creation/ 4. さいごに