Amazon Web Services ブログ

Amazon EC2 R5bインスタンスが要求の厳しいSAPワークロード向けに認定を取得

AWSにおいて、私たちが構築するオファリングの大半は、お客様からのフィードバックが直接的な起因になっています。SAPをお使いのお客様が私たちに言うことの一つは、AWS上のストレージにおいて、さらに高いレベルのスループットとIOPSおよびレイテンシーの削減を希望していることです。これらの要件についてお客様と直接取り組み、最新のAmazon EC2 R5bインスタンスタイプでSAP NetWeaverとSAP HANA向けに認定を取得したことをお知らせできて嬉しく思います。R5bインスタンスは、最大60Gbpsのストレージ帯域幅と260K IOPSのEBS性能をサポートし、R5インスタンスと比較して3倍高いEBS最適化パフォーマンスを提供します。これにより、お客様は、SAP HANAシステムやその他のIOPSの高いワークロードの極端なストレージ性能要求を凌ぐことができます。例えば、R5bの拡張ストレージ機能により、お客様は次のことが可能になります。

  • システムの起動後または必要なときに、SAP HANAのテーブルをより高速にメモリーにロードし直せます
  • I/O要求が非常に高い場合でもデータのロード時間を短縮できます
  • これまでよりも大幅に高速なバックアップとリストアが可能になります

最初に、データのリロード性能とユースケースについて説明しましょう。

SAP HANAテーブルのリロード

SAP HANAをお使いのお客様は、データをメモリー内に保持し、オンデマンドで処理する準備が整っていることに慣れています。しかしながら、データをメモリーにロードする前に、ストレージ層から読み取ってロードする必要があります。ストレージ層がSAP HANAの要求に可能な限り即座に応えることができない場合、ユーザーはインメモリーシステムが要求を処理し終えるのを待つことになります。1つのテーブルのみをメモリーにロードする場合なら性能遅延の影響は少ないでしょうが (この”遅延ロードの仕組み“は、SAP HANAがデータをメモリーにロードする標準の動作です)、大きなテーブルをロードしたり、SAP HANAの再起動後にデータをリロードしたりする場合は、システムの性能に深刻な影響を与える可能性があります。一部のSAP HANAユーザーにとって、ストレージサブシステムの性能劣化による影響は、ユーザーエクスペリエンスの低下から収益の損失まで様々です (例えば、要求を十分に迅速に処理できない受注システムは、その顧客を失う可能性があります)。

R5bが持つデータのリロード能力の速度の例を紹介するために、418GBのデータをSAP HANAデータベースにロードし、単に再起動して、このデータがSAP HANAにロードされて再び利用できるようになるまでの速度を確認しました。ここでは、データのリロード時間を示すHANAのログから抜粋します。

SAP HANA table reloading

r5b.24xlargeインスタンスでは、わずか76秒ですべてのデータをリロードできました。これは、EBSからデータを読み取り、SAP HANAの後続処理を含めると、約5.5GB/秒、あるいは44Gbpsのスループットになります。SAP HANAのログを詳しく見ていきましょう。

At 04:52:27, we can see data reload starting with this message: 

Now reloading 31820 tables (loading up to 5 tables in parallel). 

And at 04:53:43 we can see the data reload complete with this message: 

Pre-/Re-Loading of column store tables finished.

それから、SAP HANAにクエリを実行して、その76秒間でリロードされたデータ量を確認できます。

SAP HANA column store tables loaded after system restart

ローデータのリロード性能に加えて、SAP on AWSのお客様は、公開済みSAPベンチマークを比較することで、EC2インスタンスの性能特性を把握することもできます。この比較によると、R5bを使用すれば、I/O要求が非常に高い場合でも、データのロード時間を短縮できることが分かります。これを掘り下げて見ていきましょう。

I/O集中型のSAPワークロードにおけるデータのロード時間の短縮

テストの一環として、SAP BW/4HANAアプリケーションワークロードを活用したSAPベンチマークを実行して、コンピューティング、メモリー、ストレージ、ネットワーク機能の性能を測るストレステストを行います。SAP HANA標準アプリケーションベンチマークのバージョン3におけるSAP BWエディションの一部 (フェーズ 1)は、データをSAP BW/4HANAシステムにロードします。vCPU、RAM、ベンチマークで使用するレコード数が同じである場合、EC2インスタンスの色々な機能を容易に比較できます。 これは、r5.metalとr5b.24xlargeインスタンスタイプの場合が当てはまります。この2つのインスタンスタイプの主な違いは、r5.metalがベアメタルのニトロインスタンス (ハイパーバイザーが存在しない)であること、r5b.24xlargeインスタンスは同じvCPUとメモリーを兼ね備えているものの、I/Oとストレージ性能が向上していることです。公開済みのr5.metalのベンチマーク記録を見ると、フェーズ 1の結果は21,091秒で完了しています (数値が小さいほど良いです)。r5.metalとr5b.24xlargeのフェーズ 1におけるデータのロード時間を比較すると、r5b.24xlargeの性能が約25%高速であることが分かります。

Comparison of r5.metal vs. r5b.24xlarge data load performance

SAP HANAのバックアップ

また、お客様から可能な限り早く完了したいと良く言われるバックアップ/リストアのシナリオもテストしました。これを確認するために、AWS Backint Agent for SAP HANAを活用しました。このエージェントを使用すれば、SAP HANA Cockpit、SAP HANA Studio、SQLコマンドなどのSAP管理ツールを使用して、Amazon S3に直接SAP HANAデータベースをバックアップ、あるいはリストアできるようになります。Amazon S3へのSAP HANAデータベースおよびカタログの完全、増分、差分、ログバックアップをサポートしています。 AWS Backint Agentを利用するための費用は不要で、使用するAWSサービス (例えば、バックアップで消費するAmazon S3)に対してのみ料金がかかります。以下で確認できるように、544GBのSAP HANAデータベースを5分未満でバックアップすることができています。

SAP HANA 544GB database backed up in less than 5 mintues

このような短い時間枠で最も重要なデータをバックアップできるということは、AWS上でミッションクリティカルなSAPシステムを稼働させる際の心配事が1つなくなることを意味します。

これらの新しいSAP on AWSの能力を皆様に共有できて嬉しく思います。また、皆様からの声をお待ちしています。SAP HANA クイックスタートを含む自動化されたデプロイメントツールを使用してR5bインスタンスを展開できます。SAPシステムの選択肢について質問がありましたら、また確認したい場合は、お問い合わせいただくか、aws.com/sapにアクセスして確認してください。

今すぐAWSを触って、楽しんでください！

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