AWSを使用したSAPアプリケーションのオートスケーリングの有効化

今日、SAP on AWSを稼働しているお客様は、ネイティブクラウドサービスの最も幅広く深いセットを活用しています。これらは、信頼性の高いグローバルインフラストラクチャに加えて、コンピューティング、ストレージ、データベースなどの従来のサービスだけでなく、IoTや機械学習などの新しいテクノロジーにも及びます。

お客様が利用する主な機能の1つは、インスタンスタイプの変更です。ワークロードが変化すると、お客様はインスタンスが過剰に使用されている (インスタンスタイプが小さすぎる)か、十分に使用されていない (インスタンスタイプが大きすぎる)ことに気付きます。

このスケーラビリティの概念は、垂直スケーリングと呼ばれます。もっと簡単に言うと、リソースを追加するだけで追加のワークロードに対応できるシステムの機能です。

ご存じの通り、SAPのデータベース層での垂直方向のスケーラビリティは重要ですが、アプリケーションサーバー層についてはどうでしょうか。全てのワークロードをサポートするために1台の大規模なアプリケーションサーバーを作成することはできますか？できるかもしれませんが、それはおそらく良い考えではありません。これが、SAPがアプリケーションサーバーを水平方向にスケールするように設計した理由です。ここは、オートスケーリングの概念がしばしば登場する領域です。

水平方向のスケーラビリティを確保するために、お客様はサイジングを行い、履歴データを使用し、ピークワークロードをサポートするために必要なアプリケーションサーバーの数を決定します。これにより、マーケティング主導の注文の急増やレポート用の大量のデータ抽出といった計画外のイベントが発生したときに、リソースが十分に活用されなかったり、リソースのボトルネックが生じたりします。

水平方向のスケーラビリティの議論になったら、DevOpsチームやクラウドエンジニアリングチームの誰かがAmazon EC2 Auto Scalingを提案するかもしれません。しかし、ご存知のように、SAPでは、丸い穴に四角い釘を打つようなことがあります。SAPでは、オンプレミスを前提としており、スケーラビリティを常に簡単に処理できるとは限りません。

ここでは、AWSを使用した、SAPが持つオンプレミスのスケーラビリティ機能をクラウドネイティブのAuto Scalingグループと連携する橋渡しの構築のご支援について記述します。

ソリューション概要

従来の自動的なスケーリングでは、CPU使用率からロードバランサーのターゲットへのリクエスト数までの一連のメトリックを使用します。これらは、基礎となるリソースを使用しているワークロードとアプリケーションに関する優れた指標です。ただし、SAPでの利用においては、お客様が考慮しなければならないいくつかの必要な動作パターンを反映していません。

全てのSAPアプリケーションサーバーは、SAPカーネルを基盤としたSAPサービスであるワークプロセスで構成されています。これによりSAPがユニークになります。各ワークプロセスは、CPU、メモリ、ネットワークなどを消費するOS層で実行される個々のタスクタイプに特化しています。SAPアプリケーションサーバーのサイジングをするとき、これらのバランスと分散が、健全なSAPシステムにとって重要です。

マイクロサービスとほとんどの現代のアプリケーションでは、アプリケーションの自動的なスケーリングを処理するには、CPUやリクエストカウントなどの標準のスケーリングメトリックで十分です。SAPの場合、特に空いている、または現在使用中のワークプロセスの数を考慮する必要があります。

それでは、ネイティブの自動的なスケーリング機能をどのように橋渡しして、CPU使用率とリクエスト数、およびワークプロセスの消費を考慮すれば良いでしょうか？

そこで、AWSプロフェッショナルサービスのSAPアプリケーションのオートスケーリングソリューションが登場します。

このソリューションにより、企業やSAP Basis管理者は、ダイアログ、バッチ、エンキュー、印刷ワークプロセスといったSAP固有のワークロードメトリックに基づいて、SAPアプリケーションサーバーの使用率を自動的に検出できます。このソリューションは、同時ユーザーログイン、月末の締め処理、支払いの実行、つまり予測可能なワークロードと予測不可能なワークロードの両方のスパイクと落ち込みに適応できます。

このソリューションでは、必要なアプリケーションサーバーのみをプロビジョニングするオンデマンドなクラウドモデルを使用しています。定義したメトリックに基づいて、水平方向にスケールアウト (新しいコンピュートはアプリケーションサーバーとして起動)、および元に戻します (アプリケーションサーバー同様に既存のコンピュートを停止)。これは、サーモスタットが家の温度を維持する方法に似ています。温度を選択すれば、サーモスタットがよしなに行います。

次の図は、このアーキテクチャの構成方法を示しています。

ちょっと待ってください。このソリューションがスケールアウトするだけでなく元に戻るとなったとき、ユーザーとバックグラウンドジョブが実行されているアプリケーションサーバーをシャットダウンしてしまいますか？

微妙なSAPならではの課題がもう一つあります。全てのSAPトラフィックがロードバランサーを経由してルーティングされるわけではないため、コネクションドレイニングを積極的に使用できます。このトラフィックの一部は、SAP GUIを利用するエンドユーザー、またはネイティブのSAP RFCを介してシステムを呼び出す他のシステムからです。

これをSAPでネイティブに処理するには、サーバーレスコンピューティングのAWS Lambdaを使用して、SAP内部でソフトシャットダウン、あるいはグレースフルシャットダウン機能を呼び出します。これにより、SAPインスタンスの終了時にリクエストやデータが失われることがなくなり、このソリューションの全体的なTCOを最小限に抑えることができます。

ソフトシャットダウンは、トランザクションが特定の順序で完了するまで待機します。次に、これをEC2のAPIコントロールプレーンと組み合わせて、アプリケーションサーバーの基盤となるEC2インスタンスを調整し、オンデマンドのSAPキャパシティ管理への包括的なアプローチを実現します。

AWSサーバーレスコンピューティング、ストレージ、アナリティクスを使用するAWSプロフェッショナルサービスのソリューションにより、オンプレミスおよびモノリシックなSAPアーキテクチャに縛られたお客様は、より柔軟でスケーラブルで費用効果の高い方法でSAPを稼働できます。

結論

このオファリングは、ネイティブなインフラストラクチャ・アズ・コードの形でのターンキーソリューションとしてだけでなく、お客様固有の要件に合わせて高度にカスタマイズされたソリューションを構築するアクセラレータとしても機能します。

AWSのAuto Scalingにより、お客様が必要とするものに支払うだけで済み、運用コストの削減に貢献し、より高いサービスレベル目標を提供できます。週末にかかる新しいプロジェクトや今後のマーケティングキャンペーン用に計算されたSAPS値を上回るために、オーバープロビジョニングしなければならないアプリケーションサーバーの数を計算する時代は終わりました。

サーモスタットのように、メトリックを選択すると、このソリューションがよしなに行います。

お客様が今日このソリューションをどのように利用しているか興味がありますか。また、基礎となるサービスをより深く理解したいですか？詳細については、sap-on-aws@amazon.comにお問い合わせください。

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