SAP HANAワークロードの非本稼働環境における小さいサイズのX1eインスタンス

この記事は、Amazon Web Services (AWS)でSAP Solutions Architectを務めるWilson Karunakar Puvvulaによるものです。

AWS上でSAP HANAを稼働しているお客様の多くは、R4ファミリーの小規模なインスタンスで開発やQA、テスト環境を実行し、X1/X1eインスタンス上で本稼働環境を実行しています。このブログでは、開発やQA、テスト環境において、より小さいX1eインスタンスを使用する方法について説明します。これは特に、グリーンフィールドソリューションとしてSAPを導入しようとしているお客様や、SAP HANAのデータ使用量が少ないお客様に役立ちます。

AWSでは、お客様がTCO (総所有コスト)の低いソリューションを構築できるよう常に努力しており、SAP HANAワークロードをサポートする多くのインスタンスタイプを提供しています。R4インスタンスは、より最適なvCPUとメモリの比率を提供しますが、非本稼働環境の中には高いCPU性能やI/Oをあまり必要としないものもあります。例えば、r4.8xlargeはx1e.2xlargeと同様のインメモリ処理量を提供しますが、vCPUは4倍のスペックを持っています。これはしばしば十分に活用されません。

すべてのSAP本稼働システムでは、それ以外に数多くの非本稼働システムがあるため、非本稼働システムのコストが全体のTCOのかなりの部分を占める可能性があります。したがって、TCOを下げるために、X1eファミリーの小さなインスタンスの1つで、非本稼働環境を実行してはいかがでしょうか。これは、SAPノート 2271345 – Cost-Optimized SAP HANA Hardware for Non-Production Usage (SAPログオンが必要)に記載されているアプローチと一致しています。

X1eとR4インスタンスの比較

小さいX1eインスタンスはAmazon EBSのスループットが低いため、Amazon EBSにバックアップを書き込むときに、あるいはデータベースの起動時にメモリにテーブルを読み込むときに、一般に通常より時間がかかります。しかし、非本稼働環境では、コストを低く抑えたいと思う大多数のお客様にとって、これは許容できるトレードオフです。

同様のメモリ量を提供するが、異なるvCPU数を提供するX1eとR4インスタンスの一部を見てみましょう。

* SAP Application Performance Standard

私たちは、これらのインスタンスをSAP標準および分散インストール構成の両方でテストし、結果が合理的であることを確認しました。テストでは、SAP HANAのバックアップの書き込み性能とメモリへのデータの読み込み時間を中心に行っています。バックアップにはインスタンスに接続された1TBのAmazon EBS スループット最適化HDDボリューム (st1)を使用しました。書き込み性能は、R4インスタンスの場合の6〜9GB/分に対して、小さいX1eインスタンスでは3〜6GB/分でした。メモリへのデータ読み込みでは、R4インスタンスが17～25GB/分であるのに対して、小さいX1eインスタンスでは3〜4GB/分のデータ読み込み速度を計測しました。これらのテストは、前述の表に記載されているすべてのインスタンスで行いましたが、他のSAP運用要件も含めてお客様のビジネスに適しているかテストすることをお勧めします。

インスタンスのサイズ変更: 必要なときに容量を増やす

AWSでは、お客様の需要に応じて拡張できる必要性を理解しています。例えば、x1e.2xlargeインスタンスからr4.8xlargeインスタンスにスケールアップするなど、より大きなインスタンスに移行することができます。

インスタンスのサイズ変更は、SAPアプリケーションのアップグレードなどのメンテナンス作業中に特に役立ちます。QAやテスト環境を本稼働環境の性能に合わせる必要があります。インスタンスのサイズ変更を使用すると、アップグレードの期間中にQAやテスト環境をスケールアップし、作業が終了した後にスケールダウンすることができます。また、SAPノート 2271345 – Cost-Optimized SAP HANA Hardware for Non-Production Usage (SAPログオンが必要)にあるように、性能関連のSAPサポートは本稼働想定のハードウェアでのみ受けられることにも注意してください。インスタンスのサイズ変更機能を使用することで、本稼働認定インスタンスにすばやく切り替えることができます。

EC2インスタンスをオンデマンドで拡張しているSAPアップグレード作業のタイムラインの例を見てみましょう。

この例では、お客様がx1e.2xlargeのリザーブドインスタンスでQAとテスト環境を実行していることを前提としています。アップグレードのダウンタイムフェーズでは、x1e.2xlargeのリザーブドインスタンスが8時間にわたってr4.8xlargeのオンデマンドインスタンスにスケーリングされます。この場合、お客様は8時間のダウンタイム期間分だけr4.8xlargeのオンデマンド料金を支払い、QAとテスト環境をx1e.2xlargeにスケールダウンして、リザーブドキャパシティに戻します。r4.8xlargeのオンデマンドインスタンスを8時間実行した場合、us-east-1リージョンでは17ドルのコストがかかります。

このような拡張性により、コストを削減しながらパフォーマンスを最適化することができます。より小さいX1eインスタンスも、SAP HANA on AWS クイックスタートを使用して展開することができます。

詳細については、Amazon EC2のドキュメント「インスタンスタイプを変更する」を参照し、SAPワークロードでサポートされている「インスタンスタイプの一覧 (SAPログオンが必要)」および「Amazon EBSの最大スループット」も確認してください。

質問や提案があればお気軽にご連絡ください。ありがとうございます。

— Wilson

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