Amazon Web Services ブログ

マルチ AZ 展開における SAP ネットワーク パフォーマンスの自動化と最適化

はじめに

Amazon Web Services（AWS）には、あらゆる規模の組織のニーズを満たす SAP の導入パターンが複数用意されています。AWS では、 AWS patterns for Resilience に従って、SAP のワークロードは AWS リージョン内の複数のアベイラビリティゾーン（AZ）にまたがって展開することができます。
当社の標準的な推奨事項は、SAP システム（例：S/4HANA または ECC ）に複数の SAP アプリケーションサーバーがある場合、SAP システムの可用性と信頼性を全体的に向上させるために、これらのアプリケーションサーバーを異なる AZ に展開することです（図1参照）。

Figure 1 : A SAP application with multiple SAP application servers distributed across multi-AZs図1：マルチ AZ に分散した複数の SAP アプリケーションサーバーを持つ SAP アプリケーション

図1 は簡略化したアーキテクチャ図であり、(1) SAP ユーザーは SAP アプリケーションサーバーに接続し、(2)アプリケーションサーバーはデータベースサーバーに接続します。 SAP のクライアント／サーバーアーキテクチャでは、アプリケーション層のスケールアウト、つまり複数の SAP アプリケーションサーバーを追加することで、大規模な SAP ワークロードをサポートすることができます。

このアーキテクチャのトレードオフは、一部のワークロード（パフォーマンスが重要なバッチジョブなど）において、AZ  間のレイテンシがランタイムパフォーマンスに影響する可能性があることです（SAP Lens for Well Architected – Performance recommendations for latency および  SAP ノート 3496343（SAP サポートポータルへのアクセスが必要です）参照）。 このブログでは、この問題を軽減するために、データベースサーバーと同じ AZ でホストされているアプリケーションサーバー上でバッチまたはパフォーマンスが重要なワークロードを実行するソリューションについて説明します。

レイテンシーに関する SAP の推奨

ブログ “End-to-End Observability for SAP on AWS： Part 2 – SAP Network Latency Monitoring “では、SAP アプリケーション層とデータベース層間の SAP ネットワークパフォーマンスの重要性について説明しました。 パフォーマンスの良い SAP システムのためには、SAP アプリケーション層（つまりアプリケーションサーバー）とデータベースサーバー間のネットワークレイテンシが以下の SAP の推奨に従っていることを確認することが重要です：

  • SAP ノート 1100926 に従って、SAP アプリケーションサーバーとデータベースサーバー間のネットワーク遅延を 0.7 ミリ秒（ms）未満にすること（SAP サポートポータルへのアクセスが必要です）
  • 同期データレプリケーションを使用した HANA システムレプリケーションのネットワークレイテンシ（データ損失をゼロにするために必要）を 1ミリ秒未満にすること

AWS for SAP におけるレイテンシの影響

一般的に、AZ 間ネットワークのレイテンシは、上記の SAP のネットワーク推奨値を遵守しています。 ただし、このレイテンシは時間の経過とともに変化し、リージョンや AZ ペアによっても異なります。

お客様は、AWS Network Manager – Infrastructure Performance または  SAP の NIPING（SAP サポートポータルへのアクセスが必要）を使用して、AZ 間のネットワークレイテンシ（Inter-AZ ネットワークレイテンシとして知られている）と同じ AZ 内のネットワークレイテンシ（Intra-AZ ネットワークレイテンシ）を測定することができます。 AZ 間の地理的距離を考慮すると、AZ 内ネットワークレイテンシは AZ 間ネットワークレイテンシよりも低くなります。 したがって、AZ 間の高可用性を実現するために SAP ワークロードをアーキテクトする場合は、ネットワークレイテンシが最も低い AZ ペアで展開することをお勧めします。

パフォーマンスクリティカルな SAP ビジネスプロセスの例として、自動車、消費財、食品・飲料、製薬などの製造業で使用されるバックフラッシュプロセス（自動出庫）があります。 自動車業界では、バックフラッシュプロセスでは、生産オーダーが確定すると、部品表（BOM）とルーティングに基づいて、在庫から原材料や部品の必要量を自動的に差し引きます。 例えば、あるメーカーが 100 個の自動車エンジンを生産する場合、各エンジンに 4 個のピストン、8 個のバルブ、1 個のクランクシャフトが必要であれば、バックフラッシュプロセスは、手入力することなく、自動的に 400 個のピストン、800 個のバルブ、100 個のクランクシャフトを在庫から差し引きます。 これにより、効率的で正確な在庫管理が保証され、手作業によるデータ入力が削減され、生産進捗と材料使用に関するリアルタイムの最新情報が提供されます。 このバックフラッシュプロセスの動作が遅いと、製造ラインの生産性に影響が出ます。

バックフラッシュプロセス（トランザクション MFBF）に対する AZ 間ネットワーク遅延の影響を理解するため、図2 に示すテストを実行しました。このテストによると、データベースサーバーとは異なる AZ にあるアプリケーションサーバー 2 および 3 で実行した場合、RFC 実行時間のパフォーマンスが 4～10 倍低下しました。

図2：パフォーマンスクリティカルなジョブおよびトランザクションに対する AZ 間ネットワーク遅延の影響の比較

図 2 によると、AZ 間レイテンシは、長時間実行されるトランザクションや、大量のデータベース呼び出し （ラウンドトリップ）を行うタイムクリティカルなパフォーマンス要件のバッチジョブに大きな影響を与えます。 したがって、レイテンシがより低い AZ  内ネットワークに利点があるため、これらのジョブをデータベースサーバーと同じ AZ 内の SAP アプリケーションサーバーで実行することをお勧めします。 次のセクションで説明するソリューションは、障害が発生し、プライマリデータベースがある AZ から別の AZ に移動した場合でも、このプロセスを自動化するのに役立ちます。

SAP ネットワークのパフォーマンスを自動的に最適化

SAP のワークロードが適切に管理され、SAP アプリケーションサーバーに均等に分散されるように、SAP は以下のワークロード バランシングまたは分散メカニズムを提供しています：

表1：SAPの負荷分散メカニズム

図3 のように、高可用性を備えた SAP S/4HANA を実行し、複数の SAP アプリケーションサーバーがデータベースサーバーに接続している自動車関連企業の例を見てみましょう。 パフォーマンスクリティカルなバックフラッシュバッチジョブは、表 1 にあるように、SAP の負荷分散メカニズムを使用してアプリケーションサーバー 1 で実行されるように構成されています。

図3：パフォーマンスクリティカルなジョブ/トランザクションについて、プライマリーデータベースと同じ AZ にあるアプリケーションサーバーを指すように SAP の負荷分散メカニズムを調整する

  1. パフォーマンスクリティカルなトランザクション / ジョブ用のログオン / バッチ / RFC サーバーグループは、プライマリ DB と同じ AZ にあるアプリケーションサーバー 1 を指すように構成されています。
  2. プライマリ DB からスタンバイ DB にデータベースサーバーがフェイルオーバーした場合、アプリケーションサーバー1 から実行されるパフォーマンスクリティカルなトランザクション/ジョブは、AZ 内のネットワークレイテンシーがわずかに高くなるため、パフォーマンスが低下します。
  3. この問題を解決するには、ログオン / バッチ / RFC サーバーグループを調整し、代わりにアプリケーションサーバー 2 を指すようにする必要があります。 提案するソリューションは、データベースと同じ AZ にあるアプリケーションサーバーを指すように、SAP の負荷分散メカニズム（ログオングループ、バッチサーバーグループ、RFCサーバーグループ）を自動的に更新します。 これにより、データベースのフェイルオーバー / フェイルバックが発生した場合でも、パフォーマンスが重要なトランザクションとジョブは、データベースと同じ AZ 内のアプリケーションサーバーで処理されます。

図4 は、提案ソリューションのハイレベル アーキテクチャを示しています。 図3 にアプリケーションサーバーを追加したものと似ています。 このソリューションは SAP の ABAP 言語で開発されているため、AWS SDK for SAP ABAP を活用し、以下のステップ 4 に従って、Amazon Simple Notification Service（SNS）を介して、SAP システムを管理する IT チームにこの変更の通知を送信することができます。

図 4 : SAP サーバーグループの動的更新と AWS ABAP SDK による通知

マルチ AZ ネットワーク最適化ソリューションの構築

このソリューションは、SAP ABAP 言語を使用するため、ABAP スタックを使用するあらゆる SAP アプリケーションとの互換性を保証し、RISE with SAP を含む、SAP Netweaver ABAP アーキテクチャ上で動作するあらゆる SAP for AWS 環境にインストールすることができます。

重要な考慮事項

  • このソリューションは、SAP S/4HANA 2023 で正常にテストされました。
  • ログオングループと RFC サーバーグループ (RZ12) を変更するために、このソリューションは SMLG_MODIFY 関数モジュールを使用します。
  • バックグラウンド処理グループ（SM61）を変更するには、CL_BP_SERVER_GROUP クラスを使用します。
  • AWS SDK for SAP ABAP から通知機能を使用する場合は、Getting Started with the AWS SDK for SAP ABAP Blog を参照してください。
  • サンプル ABAP コードは、Multi-AZ Network Optimized Solution github にあります。
  • 3 つのロードバランシングメカニズムのいずれかを使用することができます（例えば、バッチサーバーグループのみを更新し、ログオングループと RFC サーバーグループはそのままにしておくことができます）。
  • パフォーマンスが重要なバッチジョブや、大量の RFC 呼び出しを行うジョブは、バッチサーバーグループと RFC サーバーグループを更新して、これらのジョブがデータベースと同じ AZ にあるアプリケーションサーバーで実行されるようにするのが得策です。
  • 以前の S/4HANA または SAP ECC のバージョンでソリューションを実装したい場合は、上記の両方の機能モジュールの可用性を確認し、最初に Non-Production システムでテストしてください。

AZ/DB 障害の検出

AZ および/またはデータベースに障害が発生すると、スタンバイ データベースインスタンスは 高可用性クラスタソフトウェアによってアクティブな役割に変更されます。 そのため、プライマリデータベースインスタンスのホスト名が変更されます。このホスト名は、ABAP の SQL クエリで確認できます。

Figure 5 : The solution workflow図5 : ソリューションのワークフロー

このソリューションでは、2つのテーブルを使用します：

  1. /AWSSAMP/MAZ_DB : SQL クエリで取得したプライマリデータベースのホスト名が含まれています。
  2. /AWSSAMP/MAZ_CO : アプリケーションサーバーと定義されたログオン/サーバーグループのコンフィギュレーション情報が含まれています。 このテーブルは、プライマリデータベースに対するアプリケーションサーバーの AZ を決定します。

Figure 6 : Table /AWSSAMP/MAZ_CO showing the application servers assigned to the respective logon/server groups
図 6 : それぞれのログオン/サーバーグループに割り当てられたアプリケーションサーバーを示す表 /AWSSAMP/MAZ_CO

AZ /データベースの障害状況を検出するコード スニペットです。 この SQL 実行結果をテーブル /AWSSAMP/MAZ_DB に保存しておけば、次回プログラム実行時に、データベースのホスト名が前回実行時と変わっていれば、AZ やデータベースに障害が発生したと判断できます。

DATA: lv_hostname TYPE char20.
lo_con TYPE REF TO cl_sql_connection,
lo_stmt TYPE REF TO cl_sql_statement,
lo_result TYPE REF TO cl_sql_result_set,
lv_sql TYPE string,
lt_data TYPE REF TO data.

TRY.
lo_con = cl_sql_connection=>get_connection( ).
lo_stmt = lo_con->create_statement( ).

lv_sql = |select host from M_DATABASE|.
lo_result = lo_stmt->execute_query( lv_sql ).

get REFERENCE OF lv_hostname into lt_data.
lo_result->set_param( lt_data ).
lo_result->next( ).

lo_con->close( ).
CATCH cx_sql_exception INTO DATA(err).
MESSAGE err->get_text( ) TYPE 'E'.
ENDTRY.


DATA: lo_get_dbhost TYPE REF TO /AWSSAMP/CL_MAZ_GET_DBHOST.

* Get a result of previous execution.
SELECT * INTO TABLE lt_dbhost FROM ZTAWSMULTIDB.

* Compare a current SQL execution with the previous execution
LOOP AT lt_dbhost INTO ls_dbhost.
* If it is different, Updating the current result to a temporary table.
IF lv_hostname NE ls_dbhost-dbhost.
ls_current_dbhost-mandt = '100'.
ls_current_dbhost-dbhost = lv_hostname.
* Update current Active DB Hostname into /AWSSAMP/MAZ_DB
UPDATE /AWSSAMP/MAZ_DB FROM ls_current_dbhost.
ENDIF.
ENDLOOP.

ログオン/ RFC サーバーグループの変更

ログオングループはトランザクションコード  SMLG  で変更でき、RFC サーバーグループはトランザクションコード RZ12 で変更できます。 SAP Netweaver ABAP スタックには、これら 2 つのグループを照会および変更するための SMLG_GET_DEFINED_SERVERS および SMLG_MODIFY 標準関数が用意されています。 サーバーグループを変更する前に、SMLG_GET_DEFINED_SERVERS 関数を呼び出して現在登録されている既存のアプリケーションサーバーを確認し、SMLG_MODIFY 関数を呼び出して既存のアプリケーションサーバーを削除して新しいアプリケーションサーバーをリストに登録します。

以下は、ログオンおよび RFC サーバーグループを変更するためのコード スニペットです。 GROUPTYPE 入力パラメータでグループのタイプを指定します。 例えば、’S’ は RFC サーバーグループを意味します。 SMLG_MODIFY 関数は、グループ内のアプリケーションサーバーの削除や挿入にも使用されるため、サンプルコード 2 に示すように、MODIFICATN パラメータに適切なタイプを入力する必要があります。 例えば、削除を行う場合は ‘D’ を入力します。

DATA: BEGIN OF ls_group,
        group_name TYPE char20,
        group_type TYPE char1,
      END OF ls_group.
      
DATA: lt_group LIKE TABLE OF ls_group,
      lv_grouptype TYPE char1.

DATA: lt_modi TYPE TABLE OF RZLLIMODIF,
      ls_modi TYPE RZLLIMODIF,
      lt_del_server TYPE TABLE OF RZLLIAPSRV.

ls_modi-CLASSNAME = ls_group-group_name.
ls_modi-GROUPTYPE = ls_group-group_type.

* Function Modification Type
* I. insertion of an item
* D. deletion of an item
* U. update of an item
ls_modi-MODIFICATN = 'D'. 
ls_modi_erfc-CLASSNAME = ls_group-group_name.
ls_modi_erfc-GROUPTYPE = ls_group-group_type.
ls_modi_erfc-MODIFICATN = 'U'.
INSERT ls_modi_erfc INTO TABLE lt_modi_erfc.

* Get exisiting application servers in Logon/RFC server group
* Sever Group Type
* '' Logon Server Group
* 'S' RFC Server Group
CALL FUNCTION 'SMLG_GET_DEFINED_SERVERS'
  EXPORTING
    GROUPTYPE = ls_group-group_type
    GROUPNAME = ls_group-group_name
  TABLES
    INSTANCES = lt_del_server
  EXCEPTIONS
    no_group_found = 1
    OTHERS         = 2.
        
* Change application servers in Logon/RFC server group.
CALL FUNCTION 'SMLG_MODIFY'
  EXPORTING
    GROUPTYPE = lv_grouptype
  TABLES
    MODIFICATIONS = lt_modi
    ERFC_MODIFICATIONS = lt_modi_erfc
  EXCEPTIONS
    no_group_found = 1
    OTHERS         = 2.

バッチサーバーグループの変更

バッチサーバーグループは、トランザクションコード SM61 で変更できます。 SAP Netweaver ABAP スタックには、これを表示および変更するための標準クラス CL_BP_SERVER_GROUP が用意されています。 変更が必要なグループに関する情報を取得するには、LOAD_DB メソッドを呼び出す必要があります。LOAD_DB メソッドは保護されたセクションとして宣言されているので、このクラスを継承した別のカスタムビジネスオブジェクト（CBO）クラスを作成します。

以下は、バックアグラウンド処理グループを変更するためのコード スニペットです。 クラス内の LOAD_DB メソッドと GET_LIST メソッドを呼び出して既存のアプリケーションサーバー リストを取得し、DEL_FROM_LIST メソッドを呼び出して既存のアプリケーションサーバー リストを削除し、ADD_TO_LIST メソッドを呼び出して新しいアプリケーションサーバーを登録します。 変更を確実に保存するには、SAVE_DB メソッドを呼び出します。

* /AWSSAMP/CL_MAZ_BP_GROUP Class Definition
CLASS /AWSSAMP/CL_MAZ_BP_GROUP DEFINITION INHERITING FROM CL_BP_SERVER_GROUP.
  PUBLIC SECTION.
    METHODS : LOAD_SRV_LIST IMPORTING p_groupname TYPE char20,
              GET_SRV_LIST EXPORTING p_list TYPE BPSRVENTRY,
              DEL_FROM_SRV_LIST IMPORTING p_srv TYPE BPSRVLINE,
              ADD_TO_SRV_LIST IMPORTING p_srv TYPE BPSRVLINE,
              SAVE_SRV_LIST_DB.
ENDCLASS

* /AWSSAMP/CL_MAZ_BP_GROUP Class Implementation
CLASS /AWSSAMP/CL_MAZ_BP_GROUP IMPLEMENTATION.
  * LOAD_SRV_LIST method to call LOAD_DB. To load a group information from DB.
  METHOD LOAD_SRV_LIST.
    TRY.
      CALL METHOD LOAD_DB
        EXPORTING i_name = p_groupname.
    CATCH CX_BP_HEALTH_DATA.
      MESSAGE 'Data Inconsistency Found.' TYPE 'E'.
    CATCH CX_UUID_ERROR.
      MESSAGE 'Error Class for UUID Processing Errors.' TYPE 'E'.
    ENDTRY.
  ENDMETHOD.

  * GET_SRV_LIST method to call LOAD_DB. To get servers for a list.
  METHOD GET_SRV_LIST.
    CALL METHOD GET_LIST
      RECEIVING o_list = p_list.
  ENDMETHOD.

  * DEL_FROM_SRV_LIST method to call DEL_FROM_LIST. To delete a server in a list.
  METHOD DEL_FROM_SRV_LIST.
    CALL METHOD DEL_FROM_LIST
      EXPORTING I_SRV_ENTRY = p_srv.
  ENDMETHOD.

  * ADD_TO_SRV_LIST method to call ADD_TO_LIST. To add a server in a list.
  METHOD ADD_TO_SRV_LIST.
    CALL METHOD ADD_TO_LIST
      EXPORTING I_SRV_ENTRY = p_srv.
  ENDMETHOD.

  * SAVE_SRV_LIST_DB method to call SAVE_DB. To save a list in a DB.
  METHOD SAVE_SRV_LIST_DB.
    TRY.
      CALL METHOD SAVE_DB.
    CATCH CX_BP_DATABASE.
      MESSAGE 'An Error Occurred While Attempting to Write to DB.' TYPE 'E'.
    ENDTRY.
  ENDMETHOD.

ENDCLASS.

ABAP プログラムを定期的に実行するバックグラウンドジョブを作成する

トランザクションコード SM36 を使用してバックグラウンドジョブを作成すると、ABAP プログラム（/AWSSAMP/MAZ_SOL）を定期的（たとえば 5 分ごと）に実行できます。 ジョブの作成時に、Edit > Start time メニューから実行間隔を設定できます。

Figure 7 : Transaction SM36 Job Configuration図 7 : トランザクション SM36  のジョブ設定

上記の Multi-AZ ネットワーク最適化ソリューションは、1 時間以内に SAP シ ステムに適用し、テストすることができます。 また、AWS SDK for SAP ABAP を使用して Amazon SNS サービスに通知を発行し、SAP チームに電子メールまたは SMS でアラートを通知する機能も含まれています。

まとめ

企業のビジネスプロセスの中核となる SAP ソリューションには、可用性と信頼性の高いアーキテクチャを用意することが重要です。そのため、AWS は、SAP lens Well-Architected Framework – Select an architecture suitable for your availability and capacity requirements に従い、SAP アプリケーションを複数の Availability Zone にわたってアーキテクトすることを推奨しています。

SAP トランザクションとバッチジョブの最適なパフォーマンスを確保するために、データベースサーバーのフェイルオーバー時に SAP ログオングループ（トランザクション SMLG）、RFC サーバーグループ（トランザクション RZ12）、バッチサーバーグループ（トランザクション SM61）の自動切り替えを有効にすることができます。 これにより、パフォーマンスが重要なトランザクションとバッチジョブは、常にデータベースサーバーと同じ AZ のアプリケーションサーバー上で実行されます。

このブログでは、ビジネスクリティカルなトランザクションやバッチジョブの最適なパフォーマンスを確保しながら、マルチ AZ アーキテクチャで高可用性と高信頼性を実現するために、SAP for AWS のメリットをどのように活用できるかをご紹介しました。

詳細については、Multi-AZ network optimized solution github page でサンプルコードをご覧ください。

何千ものお客様が AWS for SAP を選択する理由については、AWS for SAP のページをご覧ください。

SAP for AWS のディスカッションに参加する

お客様のアカウントチームと AWS サポートチャネルに加えて、私たちは re:Post – A Reimagined Q&A Experience for the AWS Communityを立ち上げました。 弊社の AWS for SAP Solution Architecture チームは、AWS for SAP のトピックを定期的に監視し、お客様やパートナー様を支援するためのディスカッションや質問にお答えしています。 もしあなたの質問がサポートに関連したものでなければ、re:Post で議論に参加し、コミュニティのナレッジベースに追加することを検討してください。

翻訳は SAP Specialist SA 菅谷が担当しました。原文は こちらです。