SAPパフォーマンステスト：負荷、同時実行、ツール

SAPパフォーマンステストは、多数のユーザーとジョブが同時に動いても、重要なトランザクション、バックグラウンドジョブ、インターフェースが合意した応答時間を満たすことを、本稼働前に証明するものです。私の経験では、重要なのは同時実行テストです。マスキングした本番並みのボリュームのデータで実行し、業務部門が最初の実行の前に合意した合格と不合格の基準で判定します。

このガイドは、RISE with SAPを含むS/4HANAプログラムのCIO、プログラムディレクター、テストリードに向けたものです。何をテストするか、必要なデータ、受入基準の書き方、どのツールが役に立つか、そして誰が何に責任を持つかを解説します。パフォーマンスが他のテストの種類の中でどこに位置するかについては、まず私の概要記事SAPテストとはをお読みください。

SAPプログラムでのパフォーマンスの問題が、思いがけないものであることはまれです。

シフトの始まりに何百人ものユーザーがログインすると、Fioriのタイルがタイムアウトします。誰かが非常に大きなテーブルに対して会計年度の条件を限定しない選択を実行したために、カスタムレポートが固まります。月末にバックグラウンドジョブが重なり、転記処理が異常終了します。

これらは予測できることです。問題は、プログラムがそれをテストしたのか、それとも業務部門が実際の注文を処理しながらそれを見つけるのか、ということだけです。

SAP Activateにおけるパフォーマンステスト

1. 01

   Explore

   設計の中にあるパフォーマンスのリスクを洗い出します。結果は、コードが書かれる前にアーキテクチャとレポートの形で決まります。

2. 02

   Realize

   設定が安定してきたら、ボリュームテストと負荷テストを実行します。設定が途中の状態では、誤解を招く結果が出ます。

3. 03

   UAT前

   パフォーマンステストの全サイクルを、UATの一部としてではなく、UATの前に完了します。

4. 04

   カットオーバー

   カットオーバーは、意見ではなく事前に合意した受入基準に照らして承認します。

5. 05

   ハイパーケア

   本番のKPIを30〜60日間監視します。性能の後退のほとんどは、最初の決算サイクルで表面化します。

従来型データベース上のECCシステムでは、パフォーマンステストとはアプリケーションサーバーとデータベースの負荷テストのことでした。ABAPの実行時間、SQLのパフォーマンス、ジョブのスケジューリングです。フロントエンドはSAP GUIで、意外な問題が起きることはほとんどありませんでした。

S/4HANAでは、Fioriのフロントエンド、SAP BTP上の拡張、SAP Cloud Integrationを通じた連携があり、パフォーマンスは複数のレイヤーに同時に左右されます。遅いFioriのタイルの原因は、長時間のABAP呼び出しかもしれませんし、ゲートウェイのタイムアウト、同時リクエストを想定して設計されていないODataサービス、ハイブリッド構成でのネットワーク遅延かもしれません。バックエンドだけをテストしても、それは見つかりません。

1. 01タイルの起動シフト開始時のログイン集中
2. 02OData呼び出しゲートウェイのタイムアウト、同時実行を想定していないサービス
3. 03ABAP処理長時間実行されるABAP呼び出し
4. 04データベースの読み取り大きなテーブルに対する条件を限定しない選択
5. 05画面の描画遠隔拠点ではネットワーク遅延も加わる

エンドツーエンドで測定した1つの応答時間

SAP HANAのパフォーマンステストには、システム変換ならではのひねりがあります。安定していたECCのコードも、インメモリデータベースでは振る舞いが変わります。多くのプログラムは大幅に速くなりますが、特定のデータパターンで予想外の特性を示すものもあるため、負荷の高いカスタムコードについて変換に特化した回帰テストを行うことは省略できません。

連携のフローには独自のリスクがあります。開発環境で1件ずつのテストメッセージでは動いていたフローが、本番のボリュームではキューに滞留したり、何も知らせずに失敗したりします。症状は別の問題のように見えます。断続的な注文の失敗、請求書の不一致、あるシステムにはあるのに別のシステムにはないデータなどです。

パフォーマンステストは本稼働前に実施しなければなりません。私が重要だと考えるのは同時実行テストです。多数のユーザーとジョブが、同じトランザクション、テーブル、サービスに同時にアクセスする状況のテストです。

1人のユーザーが2秒で受注を処理できても、ほとんど何も証明できません。150人が受注を入力し、バックグラウンドで出荷処理が走り、インターフェースが受信メッセージを転記している中での同じ受注こそが、稼働初日を予測するテストです。

各種類のテストが何を証明し、いつ実行するかを次の表に示します。

テスト	証明すること	実行する時期	よく見つかるもの
同時実行	多数のユーザーとジョブが同じオブジェクトを同時に扱えること	Realize、設定が安定したら。UATの前にもう一度	ロック待ち、ログインの集中、ゲートウェイのボトルネック
負荷	想定されるピーク時のボリュームで応答時間を満たすこと	Realize、同時実行のスクリプトが動くようになってから	遅いODataサービス、重いカスタムレポート
ストレス	設計上の限界を超えたときにどこで壊れるか	成長が見込まれる場合、UATの前	サイジングのギャップ、キューの上限
ソーク	何時間にもわたる安定した負荷に耐えること	UATの前、できれば決算をシミュレートしながら	メモリの増加、繰り返し実行でのジョブチェーンの競合
エンドツーエンド	ユーザーが待つ経路全体が目標を満たすこと	負荷テストと並行して	各レイヤーを単独でテストしたときには見えない問題

負荷テストで鍵となる言葉は「想定される」です。実際のトランザクション量、ユーザー数、セッションのパターンが必要です。誰もが楽観的だとわかっていたボリュームの見積もりで作った負荷テストでは、合格しても何の意味もありません。

最もよく省略されるのはソークテストです。ボリュームテスト全般が、スケジュールが圧縮されたときにプログラムが最もよく取る近道であり、最も後悔する近道でもあります。

まずこれらをスクリプト化してください。本番に到達する障害のほとんどをカバーします。

1. シフトの交代とピーク時のログイン。 数百人のユーザーが同時にFioriランチパッドを開くと、認証とランチパッドの描画の負荷が急増します。同時ログインを一度もテストしていなければ、ピーク時以外は問題のないシステムが、その時間帯には使えなくなることがあります。
2. 月次決算と年次決算。 大量の転記、厳密な順序を持つジョブチェーン、そして固定された期限と競争する財務チームです。決算のジョブチェーンは、1日の平均件数ではなく決算期間のボリュームで、最初から最後まで実行してください。
3. 重なり合うバックグラウンドジョブ。 バッチジョブは通常1つずつテストされますが、それは現実を反映していません。最適化が不十分なジョブ1つが他のいくつものジョブをブロックし、決算が予定の時間枠を超えてしまいます。
4. 条件を限定しないカスタムレポート。 テストデータでは即座に結果が返るレポートが、1会計年度分のデータでは何分もかかることがあります。典型的な選択と最悪の選択をテストし、条件を限定しない選択はブロックしてください。
5. 複数地域のユーザー。 ネットワーク遅延はすべてのトランザクションに影響します。RISEではホスティングがSAPに移りますが、遅延は引き続き選択したリージョンとユーザーまでの経路に左右されるため、最も遠い拠点からテストしてください。

システム変換のテストがより大きな計画のどこに位置するかは、私のECCからS/4HANAへの移行ガイドで解説しています。

本番レベルのテストデータ

これらすべてが意味を持つかどうかは、データで決まります。私は本番レベルのマスキングしたデータにこだわります。本番並みのボリュームと現実性を持ち、個人情報や機密性の高い項目はマスキングしたデータです。

未処理の受注明細が200,000行ある顧客は、5,000行の顧客とは振る舞いが違います。データの少ないテストクライアントでは即座に結果が返るフィルタが、本番ではタイムアウトします。リスクの高い領域にはボリュームを用意し、代表的なトランザクションの組み合わせを使い、可能な限り実際のインターフェース呼び出しを行ってください。

コピー、選択的なテストデータのツール、マスキングを通じて、そうしたデータを安全に用意する方法は、私のSAPテストデータ管理のガイドで解説しています。データの更新は、最初のパフォーマンステストのサイクルの前に計画してください。ほとんどのテスト計画が想定しているより時間がかかるからです。

基準は、テストを実行する前のPrepareフェーズで業務部門と合意してください。各基準では、トランザクションまたはジョブ、負荷、しきい値を明記します。

次の例は形を示すものです。数値は業務上の必要性から自社で設定してください。

項目	負荷の条件	合格のしきい値	責任者
受注登録（VA01またはFioriアプリ）	受注入力ユーザー150人が同時に作業	トランザクションの95%で3秒未満	受注から入金のプロセスオーナー
シフト開始時のFioriランチパッドの初回読み込み	最大のシフトでのピーク時の同時ログイン	ユーザーの95%で5秒未満	IT運用リード
月次決算のジョブチェーン	決算期間のボリューム、全工程	異常終了なく、合意した決算の時間枠内に完了	財務コントローラー
受注の受信インターフェース	ピーク時の1時間あたりのメッセージ量	15分を超えて滞留するキューがない	インテグレーションリード
大量データのカスタムレポート	本番データの全量、典型的な選択	60秒未満。条件を限定しない選択はブロック	レポートオーナー

「システムは業務に支障のない速さであるべき」という基準は、テストすることも受け入れることもできません。結果が出てから基準を変えれば、基準を持つ意味がなくなります。

UATのユーザーが速いと感じたから合格したのなら、それは意見であって受入基準ではありません。私のSAP品質ゲートのガイドで説明しているように、結果をカットオーバー前の正式なゲートにしてください。各テストフェーズの開始基準と終了基準を含むサイクル全体の計画は、S/4HANAテスト戦略に盛り込むべきものです。

SAPパフォーマンステストのツール

パフォーマンステストには3つのものが必要です。SAPのプロトコルを操作できる負荷生成ツール、SAP側の監視、そしてテストケースと結果を管理する場所です。私がSAPプログラムでチームに使わせてきた負荷テストのツールはLoadRunnerです。ライセンス、負荷生成マシン、スクリプト作成のスキルはどれも手配に時間がかかるため、テスト計画の早い段階でツールを決めてください。

2026年時点の主な選択肢は次のとおりです。

ツール	役割	知っておくべきこと
OpenText Professional Performance Engineering	負荷生成	以前はLoadRunner Professionalと呼ばれていた製品。プロトコルのバンドルはSAP、SAP GUI、SAP Webをカバー
Tricentis NeoLoad	負荷生成	TricentisはSAP GUI、Fiori、RFC、IDocへの対応を掲げており、Tricentis Toscaの資産を再利用できる
Apache JMeter	負荷生成	オープンソース。FioriやODataの呼び出しなどのHTTPトラフィックを生成
SAP Cloud ALM	テスト管理	手動と自動のテストケースを準備、実行し、不具合を追跡する。負荷そのものは生成しない
SAP Solution Manager	テスト管理	メインストリームメンテナンスは2027年12月31日に終了するため、新しい作業はCloud ALMで計画する

機能テストと自動化のツールをより広く知りたい場合は、私のSAPのテストおよび検証ツールの比較をご覧ください。ツールよりも、スクリプト、データ、基準のほうが重要です。

RISE with SAPでは責任が分かれる

RISE with SAPでは、SAPがインフラに責任を持ちます。サイジング、ハイパースケーラーのリージョン、ネットワーク、プラットフォームの可用性です。アプリケーションのレイヤーには顧客とパートナーが責任を持ちます。

SAPのRISEの役割と責任に関する文書は、この点を明確にしています。負荷テストの実行と高負荷のSQL文のチューニングは、追加料金のSAP Cloud Application Servicesです。購入しなければ、その作業は顧客が行います。

RISEプログラムでよくある失敗は、SAPがインフラを運用しているのだからパフォーマンスの問題も見つけてくれるだろうという思い込みです。SAPが見つけるのはインフラの問題です。責任の分担を憲章とテスト計画に書き込んでください。

1. SAP： インフラの可用性とプラットフォームレベルの応答
2. パートナー： 拡張と連携のフローを含め、定義した負荷のもとでのアプリケーションのパフォーマンス
3. 顧客： 決算の所要時間や受注の処理量といったプロセスレベルの成果と、受け入れの判断

パブリッククラウドでは範囲が狭まる

SAPのクラウドERPのパブリックエディションでは、システムはSAPが運用する共有のプラットフォームで動きます。テナントに対する負荷テストを計画する前に、それが許可されているか、どれくらい前に通知が必要かをSAPに書面で確認してください。

そのうえで、テストの対象は自社のものに移ります。カスタムの連携、拡張、大量データのレポート、決算の手順、そして自社の拠点からのネットワーク経路です。プラットフォームのパフォーマンスの問題はSAPサポートに上げます。

よくある失敗

1. 機能テストをパフォーマンステストとして扱う。 機能テストが証明するのは、トランザクションが正しい結果を返すことです。150人が同時にそれを実行したときのことは何もわかりません。
2. パフォーマンスをBasisに任せきりにする。 Basisが責任を持つのはサイジングとジョブのスケジューリングです。レポートの設計、ODataサービスのアーキテクチャ、連携フローの設計には責任を持たず、アプリケーションのパフォーマンスを左右するのはそちらです。
3. 責任をQAだけに負わせる。 QAはテストを実行して結果を報告しますが、パフォーマンスの問題を引き起こす決定は設計の段階で下されます。プログラムレベルのテストリードかアーキテクトが、早い段階でそれに異議を唱える権限を持つ必要があり、RACIには、パフォーマンスを理由に本稼働を止められるのは誰かを明記すべきです。
4. ギャップを既知の問題として受け入れる。 本番でパフォーマンスの問題を抱えるプログラムのほとんどは、テストを省略したわけではありません。合意した基準なしにテストしたか、テストしたうえでスケジュールのプレッシャーから失敗を受け入れたのです。

最もリスクの高いトランザクションとジョブについて、5つか6つの受入基準を書き、それぞれに責任者を指名してください。上の表を埋められないなら、テストの準備はできておらず、最初のギャップが見つかったことになります。

次に2つのことを確認してください。マスキングした本番並みのボリュームのデータ更新が計画に入っていること、そして同時実行テストのサイクルがUATの開始前に終わることです。

パフォーマンステストの計画や本稼働の判断について独立した視点が必要であれば、私はこうした支援を行っています。こちらからご連絡ください。

SAPパフォーマンステストとは何ですか？

現実的な負荷のもとでSAPがどう振る舞うかを確認するものです。ユーザーのトランザクションの応答時間、バックグラウンドジョブの実行時間、インターフェースの処理量、そして多数の人が同時に作業するときのリソースの使用量です。本稼働前に実施しなければなりません。

機能的な正しさとパフォーマンスは別の性質です。1人のユーザーでは正しく動くトランザクションが、200人ではタイムアウトすることがあります。

SAPプログラムでは、パフォーマンステストをいつ始めるべきですか？

リスクの洗い出しはExploreで始めます。アーキテクチャの選択がパフォーマンスの結果を決めるからです。実際のテストは、結果が意味を持つ程度に設定が安定してから、Realizeで始めます。

最後のサイクルはUATの最中ではなく、UATの前に終えてください。UATで見つかったパフォーマンスの不具合はスケジュールを圧迫し、それを既知の問題として受け入れるプレッシャーを生みます。

SAPの負荷テストと同時実行テストの違いは何ですか？

負荷テストは、想定されるピーク時のボリュームでの応答時間を確認します。同時実行テストは、多数のユーザーとジョブが同じトランザクション、テーブル、サービスを同じ瞬間に扱ったときに何が起きるかを確認します。ロック待ち、ログインの集中、ゲートウェイのボトルネックが表面化するのはそこです。

私の経験では、重要なのは同時実行テストです。まずそれを実行し、その上に本格的な負荷テストを組み立ててください。

SAPパフォーマンステストにはどのようなテストデータを使うべきですか？

本番レベルのマスキングしたデータです。つまり、本番並みのボリュームと現実性を持ち、個人情報や機密性の高い項目をマスキングしたデータです。少ないテストデータは、稼働初日に現れる遅いフィルタ、重いレポート、長いジョブの実行時間を隠してしまいます。

SAPパフォーマンステストにはどのツールが使われますか？

OpenText Professional Performance Engineering（旧LoadRunner Professional）、Tricentis NeoLoad、Apache JMeterといった負荷生成ツールが負荷をかけます。SAP Cloud ALMまたはSAP Solution Managerがテストケースと結果を管理し、SAP側の監視が、負荷のもとでシステムが何をしたかを示します。

RISE with SAPでは、パフォーマンステストの責任者は誰ですか？

SAPはインフラに責任を持ちます。サイジング、リージョン、ネットワーク、プラットフォームの可用性です。SAPのRISEの役割と責任に関する文書では、SAP Cloud Application Servicesを追加料金で購入しない限り、負荷テストの実行と高負荷のSQLのチューニングは顧客の担当とされています。

アプリケーションのパフォーマンスと受け入れの判断には、顧客とパートナーが責任を持ちます。受入基準に責任の分担を書き込み、各しきい値に責任者を置いてください。