SAP on AWS のエンドツーエンドオブザーバビリティ: パート 2 ネットワークレイテンシ監視

概要

これは、AWS の SAP 環境における End-to-End 監視の概要に関するブログシリーズの第 2 回目です。
第 1 回はこちらをご覧ください。

ネットワークのパフォーマンスは、通常、企業のビジネスプロセスを実行する SAP のようなエンタープライズアプリケーションにとって重要です。SAP ブログ “SAP Netweaver ABAP のネットワークパフォーマンス分析” では、SAP の 3 層ソフトウェアアーキテクチャ (つまり、プレゼンテーション層、アプリケーション層、データベース層) が、プロトコルと API の組み合わせを使用して相互に通信する方法について説明されています。

ネットワークのパフォーマンスが遅いと、データの処理に大幅な遅延が生じ、ユーザーへのレスポンスタイムも遅くなります。ネットワークトラフィックの混雑により、パケットロスが発生し、階層間の通信が完全に失敗する可能性があります。これにより、データの損失や破損が発生し、SAP アプリケーションとそのユーザーに深刻な影響を及ぼす可能性があります。一般的に高速なデータベースの応答時間は 100 マイクロ秒程度ですが、ネットワークの応答時間は約 300 マイクロ秒となります。つまり、ネットワーク時間が応答時間全体の 75 % を占めることになります。

AWS クラウド内で SAP のネットワークパフォーマンスを最適化および監視する方法について説明します。まず、SAP サーバ間のネットワークパフォーマンスから始めましょう (図 1 の赤い枠線の部分)。

SAP サーバ間のネットワークパフォーマンス

SAP はクライアントとサーバーのエンタープライズアプリケーションで、ユーザーが日々の業務を実行するためにログインする SAP アプリケーションサーバーと、SAP データを格納するデータベースなど、複数のコンポーネントで構成されています。
以下の図は、顧客のネットワーク (オンプレミス) の SAP ユーザーが、サイト間 VPN や AWS Direct Connect と呼ばれる専用リンクなどの WAN (広域ネットワーク) 接続を通して、AWS Cloud 上で実行されている SAP アプリケーションにアクセスする様子を示しています。

図 1 : AWS クラウドで実行されている SAP アプリケーションへのオンプレミス接続を示すアーキテクチャ図

ミッションクリティカルワークロード向けの AWS グローバルインフラストラクチャ

はじめに、AWS のグローバルインフラストラクチャについて理解しましょう。
AWS には、リージョンという概念があります。リージョンとは、データセンターを集約させた世界中の物理的な場所を指します。
論理的なデータセンターのグループを Availability Zone (AZ) と呼びます。
各 AWS リージョンは、地理的な区域内に最低 3 つの、独立した、物理的に分離された AZ で構成されています。

他のクラウドプロバイダーが 1 つのデータセンターを 1 つのリージョンとして定義することが多いのとは異なり、すべての AWS リージョンにはマルチ AZ 設計が備わっており、お客様に優れた利点があります。各 AZ には、独自の電源、冷却システム、物理的セキュリティが備わっており、冗長化された超低レイテンシーのネットワークで接続されています。ワークロードが AZ 間で分割されている場合、お客様はさまざまな問題 (停電、落雷、トルネード、地震など) から保護され、より高い絶縁性が確保されます。AZ は互いに数キロメートル離れた場所にあり、距離の上で十分に分離されていますが、それでもすべての AZ が 100 km 以内にあります。高可用性を求める AWS のお客様は、さらに高い耐障害性を備えるため、複数の AZ 上で実行されるようにアプリケーションを設計することができます。その上、AWS インフラストラクチャの各リージョンは、セキュリティ、コンプライアンス、データ保護に関する最高レベルの要件を満たしています。

AWS のリージョンとアベイラビリティーゾーンのモデルは、Gartner から高可用性が必要なエンタープライズアプリケーションを実行するための推奨アプローチとして認められています。

SAP のネットワークレイテンシ要件

最適なパフォーマンスを得るために、SAP はネットワークに関する推奨事項を示しています。

SAP アプリケーションサーバーとデータベースサーバー間のネットワークレイテンシは、SAP Note 1100926 で示されているとおり、0.7 ミリ秒 (ms) 未満である必要があります。
データロスゼロ (セロ) を実現するために必要な、データの同期レプリケーションによる HANA システムレプリケーションのネットワークレイテンシは、1 ms 未満である必要があります。

SAP は、ローカルの SAP システムで使用されているネットワークインフラストラクチャの健全性を測定するツールとして、NIPING を提供しています。
NIPING はクライアント/サーバーツールとして実行され、ネットワークレイテンシと帯域幅を測定するために使用できます。

上記を踏まえて、AWS の北バージニアリージョン (us-east-1) の 6 つの AZ 間 (AZ 間) および同じ AZ 内 (AZ 内) のネットワークレイテンシを見てみましょう。
各 AZ に 1 つずつ、計 6 つの EC2 インスタンスを作成し、NIPING を使ってテストを実行します。AZ1 をベースラインとします。

図 2 : NIPING を使用したネットワーク待ち時間の測定に使用した EC2 インスタンス

NIPING の結果は、AZ1 から AZ2-AZ6 までの AZ 間のネットワーク遅延を 0.7 ms の閾値に対して相対的に示しています。
AZ1 内の AZ 内ネットワーク遅延も 0.7ms の閾値を下回っています。

図 3 : AWS バージニア北部リージョン (us-east-1) における NIPING を使用したネットワーク待ち時間 ( 2023 年 7 月 )

上記のように、NIPING ツールを使用すると、AZ 間および AZ 内のネットワーク遅延を監視および測定できます。ただし、EC2 インスタンスを複数実行する必要があります。そこで、AWS Network Manager を使用すれば、この測定の代替手段となります。

AWS Network Manager – Infrastructure Performance

AWS Network Manager は、AWS でのネットワーク管理と監視を助けるツールと機能を提供します。
Network Manager は、接続管理、ネットワーク監視とトラブルシューティング、IP 管理、ネットワークセキュリティとガバナンスを簡単に行えるようにします。
特に、AWS Network Manager – Infrastructure Performance に注目したいと思います。

インフラストラクチャパフォーマンスを使用すると、ほぼリアルタイムと過去 45 日間の AWS リージョン間、AZ 間、または AZ 内の AWS グローバルネットワークパフォーマンスを、指定された期間のネットワーク待ち時間で監視できます。
ネットワーク待ち時間を最大 5 分間隔で監視でき、過去 45 日間のトレンドも確認できます。
さらに、これらの待ち時間メトリクスを Amazon CloudWatch に公開し、さらなる監視、分析、アラートを行うこともできます。
これにより、ネットワークのパフォーマンスが SAP やその他の実行中のアプリケーションに影響を与えるかどうかを容易に評価できます。
インフラストラクチャパフォーマンスの利用は無償であり、EC2 インスタンスのプロビジョニングも必要ありません。

AWS の北バージニア (us-east-1) リージョンを使用し、アベイラビリティーゾーン (AZ) 間 (Inter-AZ) および同一 AZ 内 (Intra-AZ) のネットワーク遅延を分析してみましょう。

AWS コンソールから Network Manager を選択し、Infrastructure Performance を選択してください:

図 4 : AWS Network Manager – Infrastructure Performance サービス

ネットワーク遅延監視をセットアップするのは簡単で手軽です。「Inter-Availability Zone」を選択し、以下の例では AZ1 を基準として、他の 5 つのアベイラビリティーゾーンを選択します。

図 5 : Inter-Availability Zoneと監視対象の各 us-east-1 AZ の選択

次に、適切な期間 (この例では 1 週間) と監視間隔 (5 分) を選択します。 :

図 6 : 監視期間の選択

AZ1 (use1-az1) から他の 5 つのアビリティーゾーンへの AZ 間レイテンシーは、上記の NIPING の結果と一致しています:

図 7 : AZ 間ネットワークレイテンシモニタリング

同様に、6 つのすべての Availability Zone 内で Intra-AZ ネットワーク待ち時間のテストを繰り返し、平均ネットワーク待ち時間が 0.3 ms 未満であり、0.7 ms の閾値をはるかに下回っていることを示しています。

図 8 : AZ 間ネットワークレイテンシモニタリング

上の例では、AZ1 をベースラインとして使用しました。AZ2 をベースラインとして、その後 AZ3 などと、他の AZ ペア間で上記の遅延テストを繰り返し、推奨事項を満たす AZ を特定してください。

リージョン間のネットワークレイテンシについてはどうでしょうか? AWS バージニア北部リージョン (us-east-1) と他の米国内の AWS リージョン、オハイオ (us-east-2)、北カリフォルニア (us-west-1)、オレゴン (us-west-2) とを比較してみましょう。

図 9 : リージョン間ネットワークレイテンシモニタリング

この場合、地理的な距離が短いため、us-east-1 (バージニア北部) と us-east-2 (オハイオ) 間のネットワーク遅延が最も低いことが観測されます。

Amazon CloudWatch による AZ レイテンシのモニタリング

以下の手順に従って、「AggregateAWSNetworkPerformance」CloudWatch メトリクスをサブスクライブし、AZ 間の待ち時間監視用のダッシュボードを作成してください。CloudWatch ダッシュボードの作成
ネットワーク待ち時間が特定のしきい値を超えた場合に、アラートも作成して送信できます。AWS Network Manager – Infrastructure Performance は無料でご利用いただけますが、CloudWatch 監視には料金がかかります。料金についてはAmazon CloudWatch 料金をご確認ください。

図 10 : AZ 間モニタリング用の CloudWatch ダッシュボード

Infrastructure Performance では、トランジットゲートウェイ、NAT ゲートウェイ、VPC エンドポイント、Elastic Load Balancing、Amazon EC2 ネットワークインターフェイスなど、VPC ネットワーキングリソースを通過するパスのパフォーマンス指標は考慮されません。
また、SAP アプリケーション/オペレーティングシステム/データベースのオーバーヘッドの影響があるため、SAP アプリケーションから観測されるネットワークレイテンシーも Infrastructure Performance では考慮されません。
詳しくは、AWS ドキュメントの Infrastructure Performance に関する説明をご確認ください。

信頼性と可用性を考慮した SAP の設計

複数のサーバー (つまり、複数の SAP アプリケーションサーバー、SAP Web ディスパッチャー) がある場合、信頼性と可用性を高めるため、これらのサーバーを可用性ゾーン間で分散することをお勧めします。これにより、追加のネットワーク待ち時間の影響を上回ります。
SAP を高可用性で設計する場合 (つまり、データベースの複製を行う場合)、最適なパフォーマンスを確保するには、ネットワーク待ち時間が他より短いアベイラビリティーゾーンのペアを選択してください。ネットワーク待ち時間は時間の経過とともに変化し、リージョンとアビラビリティーゾーンのペアによっても異なることに注意してください。

パフォーマンス要件が極めて高いバッチジョブの場合は、データベースサーバーと同じアベイラビリティーゾーン内の SAP Application Server で実行するようにスケジュールすることをお勧めします。

クロスリージョン災害復旧 (DR) の要件がある場合、AWS リージョン間のネットワークレイテンシーと対応する地理的距離を考慮して、DR の二次リージョンを決めてください。

詳細については、SAP Lens AWS ウェルアーキテクトフレームワークドキュメントを参照してください。

RISE with SAP では、AWS は、すべての AWS リージョンで Short-Range DR と Long-Range DR の両方をサポートする初めてのクラウドプロバイダーです。Short-Range DR は 1 つのリージョン内の 2 つの AZ 間での DR を提供し、Recovery Point Objective (RPO) はゼロ、つまりデータロスはありません。これは、地理的に離れた AZ 間の高速で低レイテンシのネットワークリンクによるシンクロナスなデータレプリケーションをサポートする AWS のマルチ AZ インフラストラクチャに対する SAP の確信の証しです。

長距離 DR とは、2 つの AWS リージョン間でのディザスタリカバリであり、RPO は 30 分です。お客様は、DR オプションを選択するか、短距離 DR と長距離 DR の両方を SAP RISE の構成の一部として組み合わせることができます。

オンプレミスユーザーと AWS Cloud 間のネットワークパフォーマンス

図 11 : オンプレミスと AWS 間の WAN 接続

オンプレミスと AWS Cloud 間の WAN 接続は、顧客が SAP システムにアクセスできることを確保する上で重要です。
WAN 接続の信頼性、可用性、パフォーマンスを維持するには、監視が重要な部分を占めます。

Amazon CloudWatch は、サイト間 VPN 接続と AWS Direct Connect の両方の監視を提供します。サイト間 VPN の場合、少なくとも VPN トンネルの状態、送受信されたデータ量を監視することをおすすめします。使用可能な監視指標の詳細は、AWS ドキュメントサイト間 VPN 接続の監視と CloudWatch での Direct Connect の監視を参照してください。

RISE with SAP

SAP RISE on AWS を実行している場合、ユーザーを AWS Cloud に接続するための WAN 接続が必要になります。この場合、次の図のように、あなたの AWS アカウントと SAP RISE によって管理される AWS アカウントを AWS Transit Gateway で接続できます。詳細とその他の接続オプションについては、AWS ドキュメント SAP RISE on AWS Connectivity を参照してください。

図 12 : AWS 上の SAP RISE 顧客のための WAN 接続例

AWS グローバルアクセラレータによるネットワークレイテンシの削減

地理的に分散したリモートユーザーが SAP システムにアクセスしようとする場合はどうでしょうか。例えば、ヨーロッパのユーザーがインターネットを介して AWS シンガポールリージョンの SAP システムにアクセスすると、ネットワークのパフォーマンスが予測できず、ユーザー体験が低下する可能性があります。

1 つの選択肢は、AWS Global Accelerator を利用することです。AWS Global Accelerator は、トラフィックを AWS のグローバルネットワークバックボーンを通すことで、アプリケーションの可用性とパフォーマンスを向上させます。ユーザーが AWS Global Accelerator に接続すると、トラフィックは自動的にネットワークレイテンシーが最も低い最適な AWS エンドポイントにルーティングされます。さらに、Accelerated Site-to-Site VPN を利用することで、AWS Global Accelerator も使用しながらデータを暗号化することができ、ユーザーに対して最適なセキュリティとネットワークパフォーマンスを提供することができます。

図 13 : AWS アクセラレーテッドサイト間 VPN 経由で SAP にアクセスするリモートユーザー

リモートの SAP ユーザーに AWS Global Accelerator が有益かどうかを判断するには、AWS Global Accelerator Speed Comparison ツールを使用して様々な AWS リージョンへのネットワーク待ち時間を測定できます。このツールを SAP ユーザーの場所で実行すると、AWS Global Accelerator がネットワークトラフィックを最も近い AWS エンドポイントに向けるため、既存のインターネット接続と待ち時間を比較できます。複数回テストを実行すると結果が異なる場合があることに注意してください。ダウンロード時間は、お使いの最終回線ネットワークの品質、容量、距離など、Global Accelerator 以外の要因によって変動する可能性があります。

図 14: AWS Global Accelerator を使用した場合と使用しない場合のネットワーク遅延の比較

Amazon CloudFront を使用した SAP Fiori のパフォーマンスの向上

Amazon CloudFront は、コンテンツ配信ネットワークサービスで、SAP Fiori などの Web コンテンツを、エッジロケーションのグローバルネットワーク全体にキャッシュすることで低遅延と高速の転送が可能です。CloudFront にキャッシュされた SAP Fiori のコンテンツをユーザーがリクエストすると、CloudFront はリクエストを最も近いエッジロケーションにルーティングし、そこからコンテンツを直接ユーザーに配信します。これにより遅延が減り、ユーザーエクスペリエンスが向上します。

SAP Fiori を使用したグローバルな SAP システムを運用し、地理的に分散したユーザーが利用している場合は、Amazon CloudFront を利用するメリットがあります。

AWS Global Accelerator と Amazon CloudFront の詳細な比較については、このAWS ブログを参照してください。

結論

ネットワークのパフォーマンスチューニングと監視は、時間のかかる作業です。AWS Network Manager – Infrastructure Performance を使えば、リージョン間、アベイラビリティーゾーン内外を問わず、AWS のグローバルインフラストラクチャのネットワーク待ち時間を簡単に監視できます。
この情報を使うことで、AWS Cloud 上で SAP アプリケーションの最大のネットワークパフォーマンスを引き出すための最適な配置を決められ、ミッションクリティカルな SAP ワークロードを継続的に監視し、問題が発生したときにはトラブルシューティングが行えます。

Amazon CloudWatch を使うと、SAP にとって重要なネットワークコンポーネントを単一の観点から監視できます。
AWS Network Manager と Amazon CloudWatch を組み合わせると、AZ 間、AZ 内のネットワークレイテンシーと、お客様のネットワークから AWS クラウドへの WAN 接続を監視できます。

AWS Cloud へのエンドユーザー接続を改善するため、AWS Global Accelerator または Amazon CloudFront を検討できます。
前者はルーティング機能により、後者はキャッシュ機構により、それぞれアプリケーションの可用性とパフォーマンスを改善します。

AWS 製品ドキュメント https://docs.thinkwithwp.com/index.html から、AWS 上の SAP、Network Manager – Infrastructure Performance、Amazon CloudWatch、AWS Global Accelerator、Amazon CloudFront の詳細を確認できます。

クレジット

Derek Ewell と Spencer Martenson のブログへの貢献に感謝いたします。

翻訳はPartner SA 松本が担当しました。原文はこちらです。

Amazon Web Services ブログ