SAPパフォーマンステスト：IT責任者が知っておくべきこと

SAPのパフォーマンステストは、重要なトランザクション、バックグラウンドジョブ、インターフェースが、本番のデータ量のもとで合意した応答時間を満たすことを、本稼働の前に証明するものです。設計の段階から始め、コンフィギュレーションが安定したらRealizeフェーズでボリュームテストと負荷テストを実施し、ユーザー受入テスト（UAT）の前にサイクルを終え、その結果をカットオーバーの判定条件にします。本ガイドは、RISE with SAPを含むS/4HANAプログラムのCIO、プログラムディレクター、テストリード向けです。何をテストするか、誰が責任を持つか、受入基準をどう書くか、クラウドで何が変わるかを取り上げます。まず受入基準の表から始めてください。埋められないなら、テストを始める準備はできていません。

SAPプログラムの性能問題は、ほぼ必ず本稼働の後に見つかります。シフト交代で300人がログインすると、Fioriのタイルがタイムアウトします。誰かが5,000万件のレコードを持つテーブルに対して、会計年度の条件を絞らない照会を実行したために、Zレポートが固まります。月次決算の最中にバックグラウンドジョブが重なり、転記の実行が異常終了します。

SAPプログラムの性能問題が、不意打ちで訪れることはまずありません。大半は予測できたのに、計画に入っていなかっただけです。よくあるパターンは次のとおりです。機能テストは徹底していました。ボリュームテストは計画されていましたが、スケジュールが圧縮されたときに後回しにされました。その結果は、本番稼働の最初の数週間に現れました。

これらは例外的なケースではありません。予測できるものです。問われるのは、プログラムがそれらをテストしたのか、それとも実際の受注が動いている最中に、事業部門が見つけるのかだけです。

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（CPI）による連携が加わり、性能は複数のレイヤーに同時に左右されます。Fioriのタイルが遅い原因は、長いABAPの呼び出し、ゲートウェイのタイムアウト、同時リクエストを想定して設計されていないODataサービス、ハイブリッド構成でのネットワークの遅延のいずれかかもしれません。バックエンドだけをテストしても見つかりません。経路全体をテストすれば見つかります。

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

エンドツーエンドで測る、一つの応答時間

連携フローには、それ自体のリスクがあります。開発環境や品質保証環境で、単発のテストメッセージでは動いていたフローが、本番のデータ量では滞留したり、気づかないうちに失敗したりすることがあります。メッセージキューが実際の負荷に合わせて設計されていなければ、遅延が積み上がります。症状は別の問題のように見えます。断続的に起きる受注の失敗、請求書の不一致、一方のシステムにあって他方にないデータです。

1. 負荷テストは、想定される量のもとでの挙動を確認します。重要なのは「想定される」という言葉です。実際のトランザクション量、ユーザー数、同時セッション数が必要です。多くの負荷テストが失敗するのは、楽観的すぎると誰もがすでに分かっていた量の見積もりを使ったからです。
2. ストレステストは、設計上の限界を超えて負荷をかけ、システムがどこで壊れるかを見つけます。18か月後に量が倍になるなら、アーキテクチャがそれに耐えられるのか、次のインフラ見直しの前にサイジングが問題になるのかが分かります。
3. ソークテストは、一定の負荷を長時間かけ続け、時間とともに蓄積する問題を表に出します。メモリリーク、断片化、繰り返しの実行にわたるジョブチェーンの競合です。最も頻繁に省略されるテストであり、後述する月次決算の障害を捉えられたはずのテストでもあります。
4. エンドツーエンドテストは、ユーザーがたどる経路全体を追います。タイルの起動、ODataの呼び出し、ABAPの処理、データベースの読み取り、画面の描画です。各レイヤーを単独でテストしたのでは見えない問題を見つける、唯一の方法です。

シフト交代とログインのピーク。 午前8時に200人のユーザーがFioriランチパッドを開くと、認証とランチパッドの描画が急増します。ピーク時以外には問題のないシステムでも、同時ログインをテストしていなければ、その時間帯には使い物にならなくなることがあります。製造、小売、金融サービスのどの業界でも、ログインの集中は、稼働初日に最も目立つ苦情を生みます。

月次決算と年次決算。 大半のプログラムで最もリスクの高いシナリオです。大量の転記、厳密な順序を持つジョブチェーン、そして固定された期限に追われる経理チームがそろいます。決算のジョブチェーンは、1日あたりの平均件数ではなく、決算期の件数で、最初から最後まで通して実行してください。

バッチジョブは通常、単独でテストされますが、それは現実を反映していません。月末にはバックグラウンド処理がピークに達し、多くのプログラムが同じリソースの上で並行して動きます。最適化が不十分なジョブが1つあるだけで、ほかの5つを止めてしまい、決算が予定の時間枠を超えて続くことがあります。

ECCからS/4HANAへのコンバージョン。 ECCで安定して動いていたコードも、HANA上では挙動が変わります。多くのプログラムは大幅に速くなりますが、特定のデータパターンで想定外の性能特性を示すものもあります。コンバージョン固有の回帰テストは、省略できません。これがコンバージョン計画のどこに入るかは、私のECCからS/4HANAへの移行ガイドで解説しています。

複数リージョンのユーザー。 ネットワークの遅延は、すべてのトランザクションに影響します。ホスティングしている国では2秒で済む受注登録が、3,000マイル離れた場所では壊れているように感じられることがあります。そこからテストした人がいなければ、気づけません。RISEではホスティングがSAPに移りますが、遅延は依然として、選択するリージョンとユーザーまでの経路に左右されます。

基準は、Prepareフェーズで、テストを実行する前に事業部門と合意します。それぞれが、トランザクションまたはジョブ、負荷、しきい値を明記します。以下の例は形式を示したものです。数値は、業務上の必要から自分たちで設定してください。

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

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

次のそれぞれを、名指しで求めてください。

期待事項	提供されるべきもの	重要な理由
性能のサービスレベル	トランザクション、インターフェース、ジョブごとのしきい値と、合格・不合格の判定	UATでの意見が、証拠を覆すのを防ぐ
リスクベースのスコープ	ユーザー数、連携ポイント、データ依存度による優先順位付け	テストのサイクルを、重要なワークロードに集中させる
チーム横断の参加	Basis、インフラ、機能、セキュリティ、連携の各担当が、実行中に同席する	問題が見つかったときの責任のなすり合いを防ぐ
ツールと環境の準備	負荷生成ツール（OpenText LoadRunner、Tricentis NeoLoad、Apache JMeter）、モニタリング、データのリフレッシュが、サイクルの開始前に整っている	シミュレーションを現実的なものにする
現実的なテストデータ	本番のデータ量のマスタデータ、実際のインターフェース呼び出し、代表的なトランザクションの構成	結果が、本稼働時の挙動を予測できるものになる
性能レポート	負荷の構成、応答時間、CPUとメモリ、ジョブの実行時間、エラー率	カットオーバーの承認に、証拠の裏付けを与える
本稼働後のモニタリング計画	最初の30〜60日間に監視するKPI	本番システムが、テスト済みの限界の範囲内にとどまっていることを確認する

成熟したデリバリーモデルを持つ大企業でも、最もよく出てくるミスは4つです。

機能テストを性能テストと見なすこと。 機能テストが証明するのは、トランザクションが正しい結果を返すことです。150人が同時に実行したときのことは、何も語りません。

少ないデータ量でテストすること。 未処理の注文明細が20万行ある顧客は、5,000行の顧客とは挙動が異なります。テストでは一瞬で返っていたフィルターが、本番ではタイムアウトします。リスクの高い領域には、ボリュームを仕込んでください。

性能をBasisに任せきりにすること。 Basisが担うのは、サイジングとジョブのスケジューリングです。レポートの設計、ODataサービスのアーキテクチャ、連携フローの設計は担いませんが、アプリケーションの性能を左右するのはそれらです。

責任をQAだけに負わせること。 QAはテストを実行し、結果を報告します。性能問題の原因になる判断は、設計の段階で、機能、技術、Basisの各チームが下します。プログラムレベルのテストリードまたはアーキテクトに、それらの判断に早い段階で異議を唱える権限が必要です。RACIには、性能を理由に誰が本稼働を止められるかも明記しておくべきです。

RISEは責任を分ける

RISE with SAPでは、SAPがインフラを担います。サイジング、ハイパースケーラーのリージョン、ネットワーク、プラットフォームの可用性です。クライアントとパートナーは、アプリケーション層を担います。SAPのRISEの役割と責任に関する文書は、この点をはっきり述べています。負荷の高いSQL文を見つけてチューニングする作業は、SAPの追加のアプリケーションサービスを購入しない限り、顧客側に残ります。

RISEのプログラムでよくある失敗は、インフラを運用しているのだから、性能の問題はSAPが見つけてくれるだろうと思い込むことです。SAPが見つけるのは、インフラの問題です。設計の悪いODataサービス、非効率なABAPジョブ、スケールしない連携フローは見つけません。この分担を、憲章とテスト計画に書き込んでください。

1. SAP： インフラの可用性と、プラットフォームレベルの応答
2. パートナー： 定義された負荷のもとでのアプリケーションの性能。拡張と連携フローを含みます
3. クライアント： 決算の実行時間や受注のスループットといったプロセスレベルの成果と、受入の判断

Public EditionとGROWは、スコープを狭める

通常はGROW with SAPを通じて購入するS/4HANA Cloud Public Editionでは、SAPが自社の製品標準の一環として、マルチテナントのプラットフォームで性能テストを実施しており、顧客が共有システムに負荷テストをかけることは想定していません。テストの重点は、自社が責任を負う部分に移ります。カスタムの連携、拡張、大量データを扱うレポートとアナリティクス、決算と連結のシーケンス、拠点からのネットワーク経路です。プラットフォーム自体の性能問題は、SAPサポートに持ち込みます。

AIが役立つのはスクリプトであり、アーキテクチャではない

負荷テストのベンダーは、スクリプトの保守と結果の分析にAIを加えつつあります。サイクルの合間にアプリケーションが変わるプログラムでは、これが役に立ちます。対価を払う前に、その主張を自社のシステム環境で試してください。SAP Cloud ALMはテストケースと要件の生成を支援でき、AIアシスタントはプロセスの記述からシナリオの概要の下書きを作れます。

どれも、アーキテクチャの問題を解決するものではありません。ODataサービスは別の設計にすべきだったとか、あるレポートがそのデータ量には重すぎるとかを、AIが教えてくれることはありません。そうした判断は、これまでどおり、テストが走る前の設計の段階で、人が下します。

本番で性能問題を抱えているプログラムの大半は、テストを完全に省いたわけではありません。合意した基準なしにテストしたか、テストはしたものの、スケジュールの圧力のもとで、その差を既知の問題として受け入れたのです。規律は、基準とその徹底にあり、ツールにはありません。ほかのテストの種類のなかで性能がどこに位置づけられるかは、私のSAPのテストと検証ツールの比較と、SAPのクオリティゲートのガイドをご覧ください。

SAPのパフォーマンステストとは何で、なぜ重要なのですか？

現実的な負荷のもとで、SAPがどう振る舞うかを確認するものです。ユーザーのトランザクションの応答時間、バックグラウンドジョブの実行時間、インターフェースのスループット、同時作業時のリソース使用量を対象とします。

機能の正しさと性能は、別の性質です。1人のユーザーにとっては正しいトランザクションが、200人になるとタイムアウトすることがあります。テストデータでは10分で終わるジョブが、本番のデータ量では何時間もかかることがあります。それが本稼働の後に見つかれば、業務が混乱し、緊急の変更を強いられ、定着が最も不安定な時期にユーザーの信頼を損ないます。

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

リスクの洗い出しはExploreフェーズで始めます。アーキテクチャの選択が、性能の結果を決めるからです。実際のテストはRealizeフェーズで、結果に意味が出る程度までコンフィギュレーションが安定してから始めます。中途半端な設定では、誤解を招く数値が出ます。

最後のサイクルは、UATの最中ではなく、UATの前に終えてください。UATで見つかった性能の欠陥は、残りのスケジュールを圧迫し、既知の問題として受け入れてしまう圧力を生みます。

SAPのパフォーマンステストは、誰が責任を持つべきですか？

QAだけではなく、プログラムが持つべきです。QAはテストを実行して報告しますが、性能を左右する判断は、機能、技術、Basisの各チームにまたがる設計の段階で下されます。中心となるアーキテクトまたはプログラムのテストリードに、それらの判断に早い段階で異議を唱える権限が必要です。

RACIで明確にしてください。受入基準を承認するのは誰か、基準を満たせなかったときの是正に責任を持つのは誰か、性能を理由に本稼働を止められるのは誰か、です。

RISE with SAPで、パフォーマンステストの責任はどう変わりますか？

SAPがインフラを担います。サイジング、リージョン、ネットワーク、プラットフォームの可用性です。クライアントとパートナーは、アプリケーションの性能を担います。コンフィギュレーション、拡張、ODataとFioriの設計、連携フロー、プロセスのKPIです。SAPのRISEの役割と責任に関する文書は、SAPの追加サービスを購入しない限り、SQLのチューニングを顧客側に残しています。

この分担を受入基準に書き込み、すべてのしきい値に責任者を置きます。

SAP Fioriの性能問題で、最もよくあるものは何ですか？

4つのパターンで大半をカバーできます。シフト開始時のログインの集中で、認証とランチパッドの描画が急増します。大きな結果セットを返したり、1回の操作でバックエンドを何度も呼び出したりするODataサービス。ゲートウェイ層がそれ自体のボトルネックになる問題で、テスト中に監視しなければなりません。そして、標準の性能の前提が当てはまらない、カスタムアプリや大幅に修正されたアプリです。

SAPの性能の受入基準は、どう定義しますか？

トランザクション、負荷、しきい値を明記します。たとえば、「受注入力ロールのユーザー150人が同時に操作したとき、受注登録がトランザクションの95%で3秒未満に完了する」。これならテストできます。

「システムは十分に速くあるべきだ」では、テストできません。基準は、Prepareフェーズで、実際の業務上の必要に基づいて事業部門と合意し、結果が出たあとに変えてはいけません。

パフォーマンステストを省いたり圧縮したりすると、どうなりますか？

問題は本番で表面化します。ジョブが時間枠を超えてほかのジョブを止める。Fioriアプリがピーク時にタイムアウトする。月次決算に2倍の時間がかかり、報告の期限に間に合わない。インターフェースのキューが滞留する。

稼働後の最初の数週間に性能問題に直面したユーザーは、システムに否定的な印象を持ち、それを覆すのは困難です。しかも、本番稼働中の緊急の是正は、テストよりもコストがかかります。Realizeフェーズでの設計判断だったものが、緊急のアーキテクチャ変更になるからです。