SAPの負荷テスト：AWSによるサーバーレスアプローチ

はじめに

SAPシステムの適切な負荷テストを実施することは、ピーク使用時にシステムがビジネスのパフォーマンスと信頼性の期待に応えられることを保証する主要な要因です。負荷テストが必要となる典型的なシナリオには、新しい会社/国の展開、ECCからS/4HANAへのソフトウェアリリースアップグレード、アプリケーションパッチ（例：サポートパッケージ）、S/4HANA変革プロジェクト、またはSAP RISEへの移行があります。このような大規模な変更後の安定した運用を確保するため、潜在的なパフォーマンス関連の問題を回避するために、本番カットオーバー前に負荷テストを実行することが推奨されます。このブログでは、オンプレミスまたはRISEにデプロイされたSAP ERPシステムに異なるタイプの負荷を注入するために、AWS上で負荷テストプラットフォームを実装し使用する方法を学びます。

SAP負荷テストとは？

SAPにおける負荷テストは、重負荷条件下でのシステムの動作を測定するために、システムに様々なタイプの負荷を体系的に注入することです。このプロセスは、複数の同時ユーザーがシステムに同時にアクセスし、様々なSAPトランザクションを実行し、大量のデータを処理し、ビジネスクリティカルなプロセスをテストしながら、適切なパフォーマンス評価のためにレスポンス時間とリソース使用率を測定することをシミュレートします。

負荷テストの重要性

SAP負荷テストの重要性は、いくつかの重要な理由から過小評価することはできません。ビジネス継続性の観点から、ピークビジネス時間中のシステムクラッシュを防ぎ、月末締めプロセスなどの重要なビジネスがスムーズに実行されることを保証し、ユーザーの生産性と満足度を維持します。

リスク軽減の観点では、負荷テストは運用に影響を与える前にパフォーマンスのボトルネックを特定し、コストのかかるシステムダウンタイムを防ぎ、データ処理エラーのリスクを軽減します。リソース最適化については、最適なハードウェア要件を決定し、容量計画を支援し、パフォーマンスチューニングの領域を特定します。コスト削減に関しては、適切な負荷テストはリソースのオーバープロビジョニングを防ぎ、予期しないメンテナンスコストを削減し、ビジネスの中断を最小限に抑えます。適切な負荷テストなしでは、組織は重要なビジネス期間中のシステム障害、システムダウンタイムによる収益損失、ユーザー生産性の低下、ビジネス評判の損傷、メンテナンスコストの増加のリスクを負います。

従来の負荷テストの課題

負荷テストの状況は近年大きな変革を遂げています。確立されたツール（例：Tricentisが提供するLoadRunnerを含むテスト自動化スイート）は長い間SAPエコシステムの定番ソリューションでしたが、その従来のアプローチには、多くの組織が正当化することがますます困難になっている相当な要因が伴います。従来の負荷テストツールは、ライセンス、インフラストラクチャ、専門スキルの観点から調達と運用が高価であることが多いです。

AWSによるサーバーレス負荷テスト

現代の負荷テストアプローチは、特にAWSネイティブサービスを使用して、サーバーレスアーキテクチャを採用するように進化しています。AWS Lambda、Amazon EventBridge、AWS Batch、AWS Fargate、AWS Step Functions、AWS Systems Manager、Amazon CloudWatchなどのサービスを活用することで、組織はSAPシステム向けのスケーラブルでコスト効率的な負荷テストソリューションを作成できます。このサーバーレスアプローチにより、専用のテストインフラストラクチャを維持する必要がなくなり、オンデマンドでのテスト実行が可能になります。AWS Step Functionsによるテストシナリオのオーケストレーションと、テスト結果を保存するAmazon S3またはAmazon DynamoDBの組み合わせにより、詳細なパフォーマンスメトリクスと洞察を提供しながら数千の同時ユーザーをシミュレートできる堅牢で自動化されたテストフレームワークが作成されます。

サーバーレス負荷テストの利点は大きく、従量課金制の価格モデル（以下で詳述するように、多くのサービスがAWS無料利用枠に含まれます）、インフラストラクチャメンテナンスゼロ、自動スケーリング機能、テストのセットアップと実行の複雑さの大幅な軽減があります。

負荷テストを実行するタイミング

SAP負荷テストは、SAPのお客様が考慮すべき全体的な非機能テストの重要な部分です。負荷テストは、新しいSAP実装の本稼働前、主要なシステムアップグレードやパッチ適用後、新しいビジネスプロセスの追加時、年末締めなどのピークビジネス期間前、ビジネス成長の計画時に実行すべきです。

月末や年末の財務締めなど、例外的なシステム負荷を生成する計画されたビジネスイベントは、スムーズな運用を確保するために事前のパフォーマンス評価が必要です。さらに、組織が新しいビジネスエンティティを統合したり、新しい複雑なプロセスを実装したりする計画がある場合、負荷テストは増加した複雑さと量を処理するシステムの能力を検証するために不可欠になります。

一貫したシステムパフォーマンスを維持するために、組織は変更管理戦略内に負荷テストを組み込むべきです。この体系的なアプローチは、アプリケーションの変更が本番環境に影響を与える前に、潜在的なパフォーマンスへの影響を特定するのに役立ちます。自動化されたテスト機能を統合することで、組織は将来のアップグレードと統合を通じて品質を維持するための基盤を確立しながら、システムパフォーマンスをより効率的に検証できます。パフォーマンステストに対するこの積極的な姿勢は、最終的にシステムの信頼性とSAPランドスケープ全体での最適なユーザーエクスペリエンスを確保するのに役立ちます。

ソリューションアーキテクチャ

SAP on AWS Native

図1：SAP on AWS Nativeアーキテクチャ

RISE with SAP

図2：RISEアーキテクチャ

注：RISE内で実行されているSAPシステムからOSメトリクスを抽出するために、いくつかのコード調整が必要な場合があります

テストシナリオ

RISE環境

アプリケーションテスト

図3：RISE負荷テストタイプ

HANAデータベース負荷テスト

このオープンソースソリューションは、SAP HANAシステム向けの現実的なデータベースワークロードを生成し、k6-sqlモジュールとk6スクリプト機能を使用して大規模なデータベース挿入/更新/削除SQL操作を注入します。以下は例です：

import sql from "k6/x/sql";
import driver from "k6/x/sql/driver/hdb";
import secrets from 'k6/secrets';

const db = sql.open(driver, `hdb://${username}:${password}@${hanaHost}:${hanaPort}`);

export function setup() {
  db.exec(`
  CREATE COLUMN TABLE test_table (
    A INT GENERATED BY DEFAULT AS IDENTITY,
    B TEXT,
    C TEXT,
    D TEXT
    );
  `);
}

export default function () {
  // first insert
  let insert_result = db.exec(`
    INSERT INTO test_table (B, C, D) 
    VALUES ('test', 'test', 'test');
  `);
  console.log("Row inserted");

  // then select
  let selectResult = db.query(`
    SELECT * FROM test_table 
    LIMIT 10;
  `);
  console.log(`Read ${selectResult.length} rows`);
}

export function teardown() {
   db.exec(`DROP TABLE test_table;`);
   db.close();
 }

HANAネイティブとAmazon CloudWatchに基づく監視コンポーネントは、トランザクションスループットとレスポンス時間に焦点を当て、システム全体の詳細なリソース使用パターンを取得します。エラー率とパフォーマンスボトルネックを分析しながら、メモリとCPUへの影響に関する洞察を提供します。

SAP FioriとIDoc負荷テスト

高ボリュームのIDoc処理をテストするために設計されたk6ベースのフレームワークで、堅牢なビジネス文書交換機能を確保します。システムは、販売注文などの様々な文書タイプ（idocの例についてはコードリポジトリを参照）の動的IDocペイロード生成をサポートし、ランプアップ、持続、ピークテストフェーズを含む設定可能な負荷パターンを提供します。AWS CloudWatchとの深い統合により、メトリクス収集と閾値ベースのパフォーマンス検証が可能になります。

同様に、SAP Fioriフロントエンド経由の複数の並列エンドユーザーインタラクションを同じアプローチを使用してシミュレートし、システムが重負荷状態に入ったときのエンドユーザーエクスペリエンスをテストできます。

パフォーマンス監視は2つの主要な領域に焦点を当てています。第一に、FioriアクセスまたはIDoc処理パフォーマンスは、スループット率、処理時間、負荷下でのキューの動作、エラーパターンを追跡しながら、エンドツーエンドの処理を検証します。第二に、システム影響分析は、SAPレスポンス時間、データベースパフォーマンス、ネットワーク使用率、全体的なリソース消費パターンを調査します。k6データベースシナリオと同様に、JavaScriptスクリプトを使用してSAPシステムに販売注文idocを注入したり、SAP Fioriユーザーインタラクションをシミュレートしたりできます：

import http from 'k6/http';
import { check, sleep } from 'k6';
import { Rate } from 'k6/metrics';
import encoding from 'k6/encoding';
import secrets from 'k6/secrets';

//get information from secret
const username = await secrets.get('username');
const password = await secrets.get('password');
const sapClient = await secrets.get('sapClient');
//get baseUrl from environment variable
const sapBaseUrl = __ENV.SAP_BASE_URL
//set the sap client in url parameter
let sapClientStringParameter=""
if (sapClient.match(/^[0-9]{3}$/)) {
    sapClientStringParameter=`?sap-client=${sapClient}`
}

// define your url path
const urlPath="/sap/bc/idoc_xml"
//build the final url
const url = `${sapBaseUrl}${urlPath}${sapClientStringParameter}`;

//start your load test logic

const xmlfile = open('./sample_idoc_ID1.xml');
const todayDate = new Date().toISOString().slice(0, 10);
const newDate = todayDate.replace("-","")

export const successRate = new Rate('success');

export const options = {
  vus: 5,
  duration: '60s',
  insecureSkipTLSVerify: true,
};

export default function () {
    const data = getAndConvertIdocXml();
    const credentials = `${username}:${password}`;
    const encodedCredentials = encoding.b64encode(credentials);

    const httpOptions = {
        headers: {
          Authorization: `Basic ${encodedCredentials}`,
          "Content-Type": 'text/xml'
        },
      };

  check(http.post(url, data, httpOptions), {
    'status is 200': (r) => r.status == 200,
  }) || successRate.add(1);

  sleep(5);
}

function getAndConvertIdocXml() {
    let result = xmlfile.replace("{{GENERATED_IDOC_NUMBER}}", Math.floor(Math.random() * 100000000000000))
    result  = result.replace("{{GENERATED_MESSAGE_ID}}", Math.floor(Math.random() * 100000000000000))
    return result
  }

サンプルxml idoc構造は、トランザクションWE19（idocテストツール）を介して生成できます。idocが生成されたら、xmlは負荷テストスクリプトの実行時にランタイムで埋められる文字列プレースホルダーGENERATED_IDOC_NUMBER、GENERATED_MESSAGE_IDを持つテンプレートに変換する必要があります。

注：ステータス53（アプリケーション文書が投稿済み）でのインバウンドIDoc処理を成功させるために、SAPシステムに応じて送信者/受信者とパートナー番号/ポートが正しい値で設定されるなど、適切なALE設定を実行することを確認してください。

両方のテストアプローチは、現実的なビジネスプロセスシミュレーションとスケーラブルなテストシナリオを通じて大きな利点を提供します。包括的な監視フレームワークは、コスト効率的なオープンソースツールと組み合わされ、可視性と制御の向上のためのAWSサービスとの深い統合を提供します。

SAP on AWS Native環境

RISE環境オプションに加えて、SAPをAWS上でネイティブに実行する場合、以下のテストを実行できます。

インフラストラクチャテスト

図4：インフラストラクチャ負荷テストタイプ

この図は、異なるインフラストラクチャ側面に焦点を当てた、AWS上のSAPシステムの3つの主要なテストシナリオを示しています：

コンピュートテストシナリオ：

このシナリオは、オペレーティングシステムツールを使用した体系的なストレステストを通じて、SAPシステムのコンピューティング能力を評価します。CPU負荷シミュレーションでは、AWS Fault Injection Simulator（FIS）と同様に、’stress-ng‘などのツールを使用して正確なCPU使用率パターンを生成します。例えば、stress-ngを使用してすべてのコアで75%のCPU負荷を維持したり、利用可能なRAMの80%を消費するメモリストレステストを行います。チュートリアルはこちらで見つけることができます。これらのツールは、SAP固有のパフォーマンスメトリクス（例：sapsocol / Workload Monitorによって収集される）と組み合わされ、IntelとAMDプロセッサ間のインスタンスタイプ比較に関する包括的な洞察を提供し、特定のSAPワークロードに最適なコンピュート設定の決定を支援します。テスト方法論には、段階的な負荷増加、持続的な高使用率期間、様々な計算ストレス条件下でのシステム動作の監視が含まれます。

ストレージテストシナリオ：

このシナリオは、Flexible I/O（FIO）テスターを使用した包括的なテストを通じて、ストレージパフォーマンスの最適化に焦点を当てています。FIOは、ランダム読み取り/書き込みテスト、シーケンシャル読み取りパフォーマンス、EBSボリュームのIOPSテストなど、様々なテストパターンを通じてストレージパフォーマンス特性の正確な測定を可能にします。AWS上でのFIOベンチマークの詳細については、このリンクを参照してください。FIOテストは、異なるEBSボリュームタイプ（例：gp3 vs io2）で実行され、以下を分析します：

• 最大スループット能力
• 様々なワークロード下でのIOPSパフォーマンス
• 異なるキュー深度でのレイテンシパターン
• 持続的負荷下でのストレージシステムの動作

ネットワークテストシナリオ：

このシナリオは、SAPシステムのパフォーマンスに影響を与える重要なネットワークパラメータを測定することで、ネットワークパフォーマンスと接続性を調査します。主要な機能は、Linuxの’tc‘（トラフィック制御）などのオペレーティングシステムコマンドを使用したネットワーク遅延シミュレーションです。これにより、人工的なレイテンシ、パケット損失、帯域幅制限を導入することで、ネットワーク条件を正確に制御できます。例えば、’tc qdisc’などのコマンドを使用することで、以下を含む実世界のネットワーク条件のシミュレーションが可能になります：

• 特定のレイテンシ値の導入（例：300ms遅延）
• パケット損失シナリオのシミュレーション（例：5%パケット損失）
• 帯域幅スロットリング条件の作成
• ネットワーク通信でのジッターの実装

これらのネットワーク障害シミュレーションは、様々なネットワーク条件下でのSAPシステムの動作に関する貴重な洞察を提供します。このアプローチは、組織がSAPシステムのネットワーク問題に対する回復力を理解し、それに応じてネットワーク設定を最適化するのに役立ちます。このシナリオは、SAP相互接続システム（例：ERP ↔ BW）間で追加のレイテンシを導入し、ERPがオンプレミスで実行され、BWがAWSに移行される移行プロジェクトをシミュレートすることで、データ抽出プロセスを測定するために使用できます。

負荷テスト監視

リアルタイム監視オプション

CloudWatchダッシュボード

カスタムAmazon CloudWatchダッシュボードは、インフラストラクチャメトリクス、アプリケーションパフォーマンスデータ、カスタムテストメトリクスを包括的な視覚化に組み合わせて、統一されたビューで重要なパフォーマンスメトリクスを表示します。主要パフォーマンス指標は論理グループに整理されています：SAP運用チーム向けのダイアログとデータベースレスポンス時間、システムダンプ数、アクティブユーザーなどのSAP技術メトリクス、およびインフラストラクチャ運用チーム向けのCPU、メモリ使用率、ストレージIOPSとスループットなどのOSメトリクス。ダッシュボードは、事前定義された閾値に基づく自動アラート機能を備えており、テスト実行中のパフォーマンス問題に対する積極的な対応を可能にします。履歴データ保持により、トレンド分析と異なるテスト実行間のパフォーマンス比較が可能になり、容量計画とシステム最適化のための貴重な洞察を提供します。

図5：負荷テスト中のCloudwatchダッシュボードメトリクス

Amazon Managed Grafana（オプション）

CloudWatchダッシュボードの代替または補完として、Amazon Managed Grafanaは強化された視覚化機能とより深い分析機能を提供します。このサービスは、高度なデータ相関とカスタムメトリクスを通じて監視エクスペリエンスを向上させ、事前構築されたパネルとカスタムパネルの両方で豊富な視覚化オプションを提供します。クロスアカウントとクロスリージョンのメトリクス集約をサポートし、複雑なSAPランドスケープの包括的な監視を可能にします。チームベースのアクセス制御とダッシュボード共有により、異なるステークホルダーグループ間でのコラボレーションが促進され、AWSサービス（このシナリオではAmazon CloudWatch）と外部データソースとのネイティブ統合により監視機能が拡張されます。リアルタイムメトリクス探索とアドホック分析機能は、パフォーマンス問題の即座の調査をサポートし、Infrastructure as Codeによる自動化されたダッシュボードプロビジョニングによって補完されます。組み込みのアラートと通知チャネルにより、パフォーマンス異常への適時な対応が保証されます。CloudWatchメトリクスとGrafana視覚化の組み合わせにより、リアルタイム運用監視と長期パフォーマンス分析の両方をサポートする強力な監視エコシステムが作成され、SAPシステム最適化のためのデータ駆動型意思決定が可能になります。

図6：負荷テスト中のGrafanaダッシュボードメトリクス

どちらの場合も、SAP Netweaver固有のメトリクスは、このオープンソースソリューションを使用してCloudwatchで収集できます。

負荷テストワークフロー

オーケストレーションと実行フロー

ワークフローは、SAPシステム負荷テストを実行し監視するために、AWSサービス全体で構造化されたイベントシーケンスに従います：

1. テスト開始：Step Functionが専用のWebアプリケーションUIでのエンドユーザー入力に基づいてテストワークフローを開始し、テスト実行と監視を制御するステートマシンを通じて全体のプロセスをオーケストレートします。入力ペイロードは、どのシナリオが実行されるか（SAP、HANA、またはインフラストラクチャ）を決定します。
2. テスト実行：AWS Secrets Managerを介して認証する特定のLambda関数が負荷テストシナリオを実行します。関数には特定のテストシナリオのロジックとパラメータが含まれています。
3. システムアクセス：AWS Systems ManagerとFargateがVPC内のSAPランドスケープへの安全なアクセスを提供し、以下でのテスト実行を可能にします：
   • アプリケーションレベルテスト用のSAPアプリケーションサーバー
   • データベースレベルテスト用のSAP HANAデータベース
   • CPU、メモリ、ストレージ、ネットワークテスト用のオペレーティングシステムレベル
4. 監視とデータ収集：
   • Amazon CloudWatchがテスト実行からパフォーマンスメトリクスを収集・処理し、すべてのSAPコンポーネントとインフラストラクチャ要素からデータを収集します。
5. リアルタイム視覚化オプション：
   • リアルタイム監視用の直接CloudWatchダッシュボード
   • 高度な視覚化と分析用のAmazon Managed Grafana（オプション）、認証用のAWS IAM Identity Center（AWS Single Sign-Onの後継）とのオプション統合
6. 長期データ処理と分析：
   • パフォーマンスメトリクスはAmazon S3に保存されます
   • AWS Glueがデータを処理・変換します
   • Amazon AthenaがSQLベースの結果分析を可能にします
   • Amazon QuickSight（オプション）がパフォーマンス洞察と視覚化を生成します

エンドユーザーエクスペリエンスをさらに改善し合理化するために、Amazon Cognitoを介して安全に認証されたユーザーが負荷テストを直接開始し、ステータスを監視できるReactアプリケーションが開発されました。これはAmazon CloudFrontでホストされ、Amazon API Gatewayを通じてStep Functionワークフローと相互作用します。

このワークフローは、VPC分離と適切なアクセス制御を通じてセキュリティを維持しながら、包括的なテスト実行、監視、分析を保証します。

実装

今日から始めましょう：

• GitHubリポジトリをクローンする
• ステップバイステップのデプロイメントガイドに従う
• SAPシステムで最初の負荷テストを実行する – セットアップから結果まで – 60分以内に！

コスト

コストの詳細については、このリンクでご確認ください。

結論

この包括的なブログ投稿では、AWSサーバーレスサービスを活用してSAP負荷およびパフォーマンステストを実行する方法を探求しました。クラウドネイティブサービスを採用することで、深い実用的なメトリクスを収集しながらSAP環境の広範囲な負荷テストを実施する効率的でコスト効率的なアプローチを実証しました。私たちのアプローチは、現代のクラウド機能が従来のパフォーマンステストを、SAPデプロイメントのためのよりスケーラブルで、コスト効率的で、データ駆動型のプロセスに変革する方法を示しています。

AWS for SAPブログを読んで、SAP投資からより多くを得る方法についてのインスピレーションを得てください。今日からAWS上でSAPを始めて、SAPランドスケープで負荷テスト戦略を開始しましょう！

SAP on AWSディスカッションに参加

お客様のアカウントチームとAWSサポートチャネルに加えて、AWSはre:Postサイトで公開の質問回答フォーラムを提供しています。私たちのAWS for SAPソリューションアーキテクチャチームは、お客様とパートナーを支援するために回答できるディスカッションと質問について、AWS for SAPトピックを定期的に監視しています。質問がサポート関連でない場合は、re:Postでのディスカッションに参加し、コミュニティナレッジベースに貢献することを検討してください。