開発完了後は何をする?【後編:非機能試験】

開発完了後は何をする?【後編:非機能試験】

前編では、開発完了後にリリースへ進む前の工程として、「機能テスト」と「モニタリング設計」について整理しました。

つくったものが意図どおり動くかを確認し、さらに本番運用で異常に気づける状態を試験の前に用意しておく、というところまでが前編の内容です。

▼前編の記事はこちら
https://tech.i3design.jp/post-development-testing-monitoring/

後編となるこの記事では、その次の工程である「非機能試験」について整理していきます。

機能が正しく動くことと、本番環境で問題なく使えることは、まったく別の話です。

「何人まで同時に使うことができるのか」
「どのサイズまでのファイルならアップロード可能か」
「1ヶ月動かし続けたらどうなるのか」

このような「どんな条件で、どれだけ使えるか」を確かめるのが非機能試験の目的です。

この記事では、私が実際のプロジェクトで経験して学んだ「非機能試験」の流れを、性能・障害・運用の3カテゴリを中心に整理してみたいと思います。

前提:非機能試験の内容は、プロジェクトの性質やシステムの要件によって大きく異なります。今回紹介するのは、私が実際に経験した範囲の性能試験・障害試験・運用試験の概要になります。

非機能の観点は、実はかなり幅広くあります。
国際規格のISO/IEC 25010では、性能効率・信頼性・セキュリティ・互換性・保守性など、多数の品質特性が定義されています。

そのすべてを毎回行うわけではなく、プロジェクトの性質に応じて重要なものを選んで実施します。
今回は実際に体験した性能・障害・運用の3カテゴリを中心に解説し、最後に今回触れていないものも紹介します。

第1章 非機能試験 — 性能・障害・運用

まずは非機能試験の全体像を確認します。
非機能試験はひとつの試験ではなく、いくつかのカテゴリがあり、その中にさらに個別の試験がぶら下がる構造になっています。

カテゴリ含まれる主な試験何を確かめるか
性能試験単性能 / 複合 / 限界性能 / ロングラン速さと捌ける量。正常時にどれだけの性能が出るか
障害試験障害検知 / 耐障害性 / 回復性・DR異常が起きたとき、検知できるか・耐えられるか・戻せるか
運用試験定常運用 / 非定常作業リリース後、定常運用と非定常作業を回していけるか
その他セキュリティ / 互換性 / 移行 など案件次第で実施(本記事では概要のみ)

それでは、上から順に深掘りしていきます。

1.1 性能試験

性能試験は「速さ」と「捌ける量」を確かめる試験です。
同じ「性能」でも、負荷のかけ方によって見つけたいものが変わるので、性能試験の中でもいくつかの種類に分かれます。

試験負荷のかけ方主に見つけたいもの
単性能試験機能・APIを単体で個々の性能の基準値
複合試験複数機能を混在させる現実の使われ方での劣化・競合
限界性能試験負荷を上げ続ける破綻する限界点・ボトルネック
ロングラン試験長時間・連続メモリリーク・じわじわした劣化

単性能試験

個々の機能・APIを単体で動かし、レスポンスタイムやリクエスト成功率の基準値を測ります。

たとえば「この検索APIは、1リクエストあたり何ミリ秒で返るか」を、他の処理に邪魔されない状態で確認します。
性能要件を満たしているかを確認するだけでなく、後の複合試験や限界性能試験で「どこが遅いのか」を切り分けるための土台となる数値にもなります。

また、モニタリングのアラート閾値を、単性能試験の結果から再検討することもあります。

複合試験

実際の運用に近い形で、複数の機能を混在させた負荷をかけて挙動を確認する試験です。

本番運用では、検索もダウンロードも登録も同時に走ります。
単体では問題なくても、複数のサービスや処理が混ざると「特定のリソースを奪い合って遅くなる」ということが起きます。

つまり複合試験は、共有しているリソースの競合を確認する試験です。

限界性能試験

負荷を上げ続けて、システムが破綻する点(限界点)を見つける試験です。

「どこまで負荷を上げると応答が崩れるか」
「アップロードに失敗するファイルサイズはどのくらいか」
「何ユーザーが同時にリクエストを送ると、システムが処理できなくなるか」

このような限界を把握します。
限界を知っておくことで、キャパシティ計画やオートスケールの設定根拠になります。

ロングラン試験(耐久試験)

長時間連続で負荷をかけ続け、時間の経過とともに劣化しないかを確認するテストです。

短時間のテストでは見えないメモリリークや、リソースの少しずつの枯渇、性能のじわじわとした低下を炙り出すのが目的です。

その他性能試験

  • スパイク試験:急激なトラフィックの跳ね上がりに耐えられるか、トラフィックが収まった後に問題なく回復するか
  • ボリューム試験:大量のデータを抱えた状態で性能が落ちないか

 急なアクセス集中があるか、データが膨れ続けるかなどのプロジェクトの特性次第で、上記を足すか判断が必要になります。

1.2 障害試験

障害試験は「異常が起きたときにどう振る舞うか」を確かめる試験です。

障害検知試験

わざと障害を起こし、監視がそれを正しく検知して、通報(アラート)が飛ぶかどうかを確認する試験です。

ここで前編のモニタリング設計が効いてきます。
「サーバーを落としたのに、誰にもアラートが届かなかった」では監視の意味がありません。

障害を検知できること自体を、試験として確かめます。

耐障害性試験

構成要素の一部が壊れても、システム全体としてサービスを継続できるかを確認します。

たとえば冗長化したサーバーの1台をわざと停止し、残りに処理が引き継がれて(フェイルオーバー)、ユーザーから見て影響がないかを確認します。

「単一障害点(そこが落ちると全部止まる箇所)がないか」を、実地で確かめるイメージです。

回復性試験

障害でデータやシステムが壊れたとき、元の状態に復旧できるかを確認する試験です。

代表例はバックアップからのデータ復旧です。
「バックアップは取れていたのに、いざ戻そうとしたら復旧できなかった」を防ぐため、復旧手順を実際に試します。

DR(災害復旧)試験

回復性試験の中でも、規模が大きいものです。

データセンターやリージョン全体が使えなくなるような災害を想定し、別拠点へ切り替えてサービスを継続・復旧できるかを訓練します。
可用性要件が高いシステムほど重視されます。

1.3 運用試験

「リリースした後、正しく運用・保守していけるか」を確かめるのが運用試験です。

ただし注意したいのは、運用試験は性能試験のように内訳の型が決まっていないことです。
「運用試験の種類はこれ」という業界共通の分類はなく、何をどう区切るかはプロジェクトごとに異なります。

ここでは一例として、私が経験した現場での分け方である「定常運用」と「非定常作業」の2つを紹介します。

定常運用

日常的に回り続ける運用が、手順どおりに回るかを確認します。

定期的なバッチやジョブ、バックアップの取得、監視と運用通報の確認など、あらかじめ定義された定常運用プロセスが想定どおりかを確認します。

非定常作業

ユーザーからの個別依頼や例外事象が発生したときに、人が手順に沿って行う作業を正しく実施できるかを確認します。

たとえば、最大添付ファイルサイズを超過したファイルのアップロードなど、通常運用では頻繁に起きないものの、発生したときには対応が必要なケースです。

1.4 ここで触れていない非機能試験

冒頭で書いたとおり、非機能の観点はもっと広くあります。
プロジェクトによっては、これらも独立した試験として実施されます。

セキュリティ試験

脆弱性診断やペネトレーションテストで、攻撃に対する耐性を確認します。

互換性試験

対応ブラウザ・OS・端末で正しく動くかを確認します。

移行試験

旧システムからのデータ移行が、欠損なく正しく行えるかを確認します。

まとめ

この記事では、開発完了後からリリース前までに行う非機能試験について、性能・障害・運用の3つの観点で整理しました。

開発中は、どうしても機能や性能に目が向きやすいですが、リリース後には日々のバッチ処理、バックアップ、監視、問い合わせ対応、例外対応など、運用の仕事が続いていきます。
そのため、システムが動くだけでなく、人が手順に沿って正しく運用できるかも、リリース前に確認しておく必要があります。

非機能試験を経験して感じたのは、リリースとは「機能が完成したから出す」ものではなく、「本番で使い続けられる状態になったから出す」ものだということです。

機能が正しく動くこと。
想定した負荷に耐えられること。
障害が起きても検知・継続・復旧できること。
リリース後の運用を回していけること。

ここまで確認して、ようやくリリース判断に必要な材料が揃います。

私自身も最初は、非機能試験と聞いても「性能を見るもの」くらいのイメージしかありませんでした。
でも実際には、性能だけでなく、障害時の振る舞いや運用の現実性まで含めて確認する工程でした。

一つひとつの試験には、「何を担保するための工程なのか」という理由があります。
その理由が見えてくると、開発完了からリリースまでの流れが、単なる作業の羅列ではなく、本番に出すための確認プロセスとして理解しやすくなりました。

この記事が、同じように「開発の後って結局何をするんだろう?」「非機能試験では何を見ればいいんだろう?」と感じている方の参考になれば嬉しいです。

開発完了後は何をする?【前編:機能テスト・モニタリング設計】
サムネイル