ベストプラクティス 16.5 – パフォーマンス要求に対して拡張する

AWS でワークロードを運用する最大のメリットは、ユースケースに必要なパフォーマンスに合わせて、コンピューティング性能の増減やストレージのパフォーマンス特性の変更が可能なことです。SAP ワークロードの場合、パフォーマンスのボトルネックを回避するために、必要に応じて動的スケーリングを使用します。SAP HANA データベースクラスターのスケールアウトなど、動的スケーリングが不可能なシナリオでは、マニュアルによるデプロイプロセスを使用します。

提案 16.5.1 – SAP ワークロードを受動的に拡張する

ワークロードのパフォーマンス要件の動的な変化に対応し、SAP リソースを必要に応じて拡張できます。可能な限り、スケールインまたはスケールアウトにはオートメーションを使用しますが、それができない場合 (データベースインスタンスのスケールアップなど) には、マニュアルで行うプロセスを用意してください。考慮すべき点:

• 需要に応じてアプリケーションサーバーの容量を追加または削除したり、インスタンスサイズを変更したりする

• プログラムによる仮想リソースの再配布のために SAP パラメータを変更する

• ストレージタイプの変更 (例えば、Amazon EBS の gp3 を io2 へ、またはその逆など、AWS 内で) 行うことで、ストレージのパフォーマンスを最適化します。

提案 16.5.2 – 予測可能な SAP ワークロードのスケーリングをスケジュールする

オートメーションまたはマニュアルのいずれであっても、予測可能なパフォーマンスパターンに基づいて SAP ワークロードをスケーリングすることが推奨されます。例えば、SAP ECC システムで月末の財務処理により、アプリケーションサーバーのインスタンスの処理要件が 20% 増加することが予測される場合、システム管理者は、アプリケーションサーバーの数やサイズを事前に増やし、使用量が予測どおりに減少したらインスタンス数をスケールインさせることができます。