SAP on AWS ワークロードの最適化術:コスト削減ガイド

はじめに

現在の経済環境では、コスト最適化が多くの企業の主要な優先事項となっています。企業が SAP を新規に導入、または最新バージョンに更新する際、SAP が実行される AWS サービスのコストを最適化できれば、その分のリソースを他のイノベーションに振り向けることができます。このブログでは、SAP Lens for the AWS Well-Architected Framework のベストプラクティスを活用して、SAP ワークロードのコストと運用を最適化するためのインサイトと戦略を共有しています。

前提

開始する前に、目標を明確に設定し、総コストを算出し、SAP on AWS 参考コストガイドを確認する必要があります。

SAP ワークロードが実行されているすべてのアカウントで、AWS コストエクスプローラを実行します。SAP で一般的に高コストとなるサービスは、Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Elastic Block Store (Amazon EBS)、Amazon Simple Storage Service (Amazon S3)、Amazon EBS スナップショット、Amazon Elastic File Store (Amazon EFS) などです。本ブログではこれらのサービスの最適化とコスト削減のベストプラクティスと指針を示します。

Amazon EC2

Amazon EC2 から始めましょう。SAP ワークロードで Amazon EC2 インスタンスを選択する場合は、必ず SAP 認定 Amazon EC2 インスタンス上で SAP NetWeaver と SAP HANA インスタンスを実行してください。

#1 ワークロードに最適なインスタンスサイズの選択
ワークロードに最適なインスタンスサイズの選択とは、ワークロードのパフォーマンスと容量の要件を満たす最小限のコストのインスタンスタイプとサイズを選択するプロセスです。

Amazon EC2 インスタンスのサイズ変更は、ビジネスピークと四半期末期間を含めた過去 3 か月間の実際の使用状況に基づいて行う必要があります。そのためには、Amazon CloudWatch と SAP Early Watch Alert を使用して使用状況分析を行います。

AWS Compute Optimizer の拡張インフラストラクチャメトリクス機能を有効にすると、Amazon CloudWatch のデータ 3 か月分を利用して推奨事項を生成できます。(デフォルトでは、AWS Compute Optimizer は Amazon CloudWatch のメトリクス履歴を最大 14 日間保存し、それを使って推奨事項を生成します。) 推奨事項の精度を上げるため、SAP EarlyWatch Alert レポートと比較してください。
分析に基づき、実行中のインスタンスを適切なSAP 認定 NetWeaver または HANA インスタンスに置き換えてください。

注: Compute Optimizer は一般に信頼できますが、SAP ワークロードに対して最適でない推奨を行う場合がたまにあります。特にアイドルの SAP アプリケーションサーバーの場合に発生する可能性があります。これは、Compute Optimizer がワークプロセスによって使用される予約済みメモリを考慮していないためです。そのため、Compute Optimizer の推奨を SAP 認定インスタンスと照合して最適なパフォーマンスであることを確認することをお勧めします。

#2 SavingsPlans を活用する
SavingsPlans は柔軟な価格モデルを提供し、1 年間または 3 年間の時間ベースの課金コミットメントと引き換えに、オンデマンド価格と比較して最大 72 % の料金削減が可能です。

オンデマンドで実行中の Amazon EC2 インスタンスが存在するかを確認し、ワークロードとインスタンスの使用状況が安定している場合は、 SavingsPlans に追加してください (例: 3 年間の前払い SavingsPlans を利用すれば、バージニア北部でオンデマンドの u-3tb1 Linux インスタンスよりも 60 % 以上安価になります)。
AWS Trusted Advisor と AWS Cost Explorer は、現在の SavingsPlans の利用状況と推奨事項を示します。

予測可能なワークロードのオンデマンドコストを避けるために、これを定期的 (月に 1 回程度) に見直す必要があります。

#3 Amazon EC2 インスタンスファミリの標準化でディスカウントを最大化
インスタンスファミリの標準化によって、利用率を最大化し、予約管理に関連する作業負荷を最小化します。

SAP で認定されている Amazon EC2 インスタンスファミリーとタイプは多数あります。コストを最適化するには、インスタンスファミリーとタイプを標準化する必要があります。例えば、小規模インスタンス (ASCS、SCS、WebDispatcher など) には Amazon EC2 C6i または最新世代を、SAP アプリケーションサーバーには Amazon EC2 M6i または最新世代を、1TB 未満の HANA データベースインスタンスには Amazon EC2 R6i または最新世代を使用してください。

#4 非本番用の Amazon EC2 インスタンスの開始 & 停止を自動化する
開発環境、トレーニング環境、サンドボックス環境、プロジェクト関連のインスタンスは、稼働時間の要件が低い (1 日数時間のみ、または特定の日付のみ) 場合や、プロジェクトサイクルでの役割が短期間のみである可能性がありますので、これらのインスタンスに予約インスタンスを購入するのは費用対効果が低くなる恐れがあります。この場合、稼働時間の要件に基づいてコストを削減するために、AWS Systems Manager または SAP Landscape Management を使用し、インスタンスの開始・停止をスケジューリングすることができます。

非本番の SAP ワークロードインスタンスの起動と停止を自動化することで、AWS コストを削減できます。
必要な時だけインスタンスを動作させれば、使われていないインスタンスに支払う必要がなくなります。

#5 最新世代の Amazon EC2 インスタンスへの移行
新しい世代のインスタンスタイプに移行することで、SAP ワークロードの価格性能を改善できます。
理由は、新しい世代のインスタンスでは SAPS が高く、価格が低いためです。
その結果、同等の性能を実現するために、インスタンスの台数やサイズを少なくできるかもしれません。
または、同じサイズの最新世代のインスタンスタイプに変更することで、ワークロードの増加に対応できます。
たとえば、m5 ファミリから m6i ファミリに移行すれば、インスタンスタイプ、OS、リージョンによっては、CPU が最大 15 % 高速、メモリ帯域幅が最大 20 % 高速、ネットワーク帯域幅が 25 ~ 100 % 高速になります。

#6 使用されていないオンデマンドキャパシティ予約 (ODCR) を解除する
オンデマンドキャパシティ予約を利用すると、任意の期間、特定のアベイラビリティーゾーンで Amazon EC2 インスタンスのコンピューティングリソースを確保できます。

特定のインスタンスタイプを使った SavingsPlans で ODCR (オンデマンドキャパシティ予約)を作成した場合、Amazon EC2 インスタンスを利用できるようにするためです。インスタンスのサイズ変更、Amazon EC2 インスタンスファミリーの標準化、または別のインスタンスタイプへの移行後は、既存の ODCR をキャンセルし、適切なサイズのインスタンスの新しい ODCR を作成する必要があります。たとえば、u-3tb1.56xlarge から r6i.32xlarge にインスタンスを変更する場合、前の ODCR をキャンセルし、r6i.32xlarge の新しい ODCR を作成する必要があります。
未使用の ODCR を定期的にチェックするプロセスを実装してください。

#7 RTO と RPO に応じて、AWS Elastic Disaster Recovery を使用して DR アーキテクチャを最適化
AWS Elastic Disaster Recovery (AWS DRS) を使用すれば、組織は新しい災害復旧プランを AWS に素早く簡単に実装したり、既存の災害復旧プランを AWS に移行することができます。
ソースシステムをステージングエリアのレプリケーションサーバーにレプリケーションすることで、低コストのストレージ、共有サーバー、最小限の計算リソースを使用することにより、継続したレプリケーションを維持しながら、災害復旧コストを最適化できます。

必要な RTO および RPO が達成できる場合は、AWS DRS (SAP アプリケーションサーバーとデータベースに該当する場合) を、アクティブ・アクティブではなくディザスターリカバリー (DR) に活用してください。
RTO と RPO のオプションが異なる場合は、SAP on AWS システムの復旧性を管理するための他のデザインパターンを評価することを検討してください。

#8 クラウドの柔軟性を活かして、必要に応じて一時的なシステムを構築する
AWS Launch Wizard は、SAP HANA などのサードパーティのアプリケーションに必要な AWS リソースをサイジング、構成、デプロイするための手順付きのウィザードです。

必要に応じて、AWS Launch Wizard を使って Amazon Machine Image (AMI) (サポートされている OS バージョン向けのセキュリティ強化プロセスで構築されたもの) から一時的なシステム (SAP HANA ベース) を構築し、そのシステムを稼働したままにしたり、シャットダウンするのではなく利用してください。インスタンスをシャットダウンしている場合でも、ストレージコストが発生するためです。

また、AWS Service Catalog のプロダクトを AWS Launch Wizard で作成できます。
これにより、AWS Launch Wizard 内で事前に定義された SAP アーキテクチャを直接プロビジョニングできるため、チームは時間を節約できます。

Amazon EBS (Elastic Block Store) の概要

SAP HANA Tailored Data Center Integration (TDI) の要件を満たすには、EC2 インスタンスで SAP HANA を実行する際の最低限の構成として、必ず SAP HANA on AWS の認定ストレージ構成を使用してください。
これにより、最適なパフォーマンスを実現し、SAP のストレージ KPI を満たすことができます。

#1 最新の Amazon EBS ボリュームタイプを使用する
GP2 から GP3 ボリュームタイプに Amazon EBS ボリュームを移行すると、コストを最大 20 % 節約できます。

#2 IO2 よりも Amazon EBS GP3 ボリュームタイプを使用する
Amazon CloudWatch から Amazon EBS IO2 ボリュームの IOPS 使用量をチェックしてください。
IOPS の使用率が 16,000 を下回る場合は、ボリュームを IO2 から GP3 に移行することを検討してください。
また、16,000 IOPS の制限をバイパスし、より高い IOPS およびスループットを実現するために、GP3 ボリュームのストライピングを検討することもできます。

注意: プロビジョンド IOPS SSD (IO2) ボリュームタイプは、サブミリ秒のレイテンシー、高い IOPS、スループット、高い耐久性 (99.999 %) が必要なミッションクリティカルなワークロードに使用してください。

#3 使用されていないAmazon EBSボリュームを削除してAWSのコストをコントロールする
AWS コンソールで切り離された Amazon EBS ボリュームを確認し、今後使用する予定がない場合は削除してください。
切り離されたボリュームは、「終了時に削除」のフラグがない状態で起動された終了した Amazon EC2 インスタンスから残されている可能性があります。

#4 AWS Backup または AWS Backup Agent を使用して直接 AWS S3 ストレージにデータベースをバックアップする
AWS Backup または AWS Backup Agent を使って、データベースのバックアップとリストアを直接 AWS S3 に対して行えます (anyDB と SAP HANA の高可用性環境の場合)。こちらの手順に従って設定してください。

EC2 上の SAP HANA では、AWS Backup* および AWS Backint Agent for SAP HANA が利用可能です。

Oracle on EC2: Oracle Secure Backup (OSB) モジュールを利用してください。
Symantec Advanced Solutions (Symantec 高度ソリューション) データベース: AWS File Gateway を使用して、データを非同期的に転送します。

これにより、(Amazon EFS または Amazon EBS のいずれかで) バックアップを保持するための一時保存用のストレージコストを避けることができます。

#5 データベース以外のボリュームの EBS スナップショットを最適化する
Amazon EBS ボリュームや Amazon EC2 インスタンスを含む、さまざまな AWS リソースのバックアップ、リストア、およびポリシーベースの保持を行うための集中管理型サービスである AWS Backup を使用してください。

データベースサーバー:

ルートボリュームとバイナリボリュームのスナップショットを有効にします
データとログのボリュームのスナップショットを無効にしますが、データベースのバックアップ (データベースツールを使用) が適切に行われている必要があります
アドホックのデータおよびログボリュームのスナップショットを AWS Backup と併用すれば、大規模データベースのシステムリフレッシュを迅速化できます

SAP アプリケーションサーバー:

ルートボリュームとバイナリボリューム (/usr/sap) のスナップショットを有効にします

Amazon S3

#1 データベースのバックアップスケジュールと保持期間を改善する (AWS Backup Agent を使ってバックアップを S3 に取る場合)
プロダクション、ステージング、プレプロダクション、品質管理、開発、サンドボックス、プロジェクト環境ごとに、フルバックアップとインクリメンタルバックアップを組み合わせたバックアップスケジュールを設定します。
このスケジュールは、各環境での復旧ニーズと、復旧に必要なデータの新しさ・タイムリーさを考慮し、適切な保持期間に基づくものにしてください。

たとえば、30 日のデータ保持期間がある開発環境やサンドボックス環境では、月次の完全バックアップと週次の増分バックアップで十分です。また、必要に応じて、これらの環境を本番環境やその他の環境のバックアップからリストアすることができます。

#2 Amazon S3 でライフサイクルポリシーを有効化する
Amazon S3 分析 – ストレージクラス分析を利用し、ストレージアクセスパターンを分析して、適切なデータを適切なストレージクラス(上記で特定の保持期間を設定したクラス)に移行するタイミングを判断します。

環境ごとのリカバリー要件とデータ保持期間に基づいて、ライフサイクルポリシーを設定してください。例えば、本番環境のバックアップは 5-7 日間は Amazon S3 Standard に格納し、その後、5 日以上前のバックアップの復元の必要性が非常に低い場合は、Amazon S3 Glacier または Amazon S3 Glacier Deep Archive で 6 か月保持するなど、低コストの格納先に移行します。

#3 バックアップのバージョン管理を無効にする
バックアップのバージョン管理を無効にし、セキュリティのためにマルチファクター認証による削除またはvault ロックを有効にします。

#4 DR リージョンに低コストストレージを採用
ビジネス継続および災害復旧 (BC/DR) のため Amazon S3 クロスリージョンレプリケーション (CRR) が有効な場合、復旧時間目標 (RTO) および復旧ポイント目標 (RPO) に応じて、災害復旧 (DR) リージョンに Amazon S3 Glacier や Amazon S3 Glacier Deep Archive などの低コストストレージを採用してください。

#4 インターフェイスまたはアーカイブファイルの保存には Amazon EBS や Amazon EFS ではなく、Amazon S3 を活用する
ライフサイクルポリシーとバージョン管理を実装することで、インターフェイスまたはアーカイブファイルの保存に Amazon S3 を活用してコストを削減できます。
AWS SDK for SAP ABAP を使えば、SAP ABAP プログラムから Amazon S3 のファイルにアクセスできます。

#5 Amazon S3 の AWS Private Link
AWS Private Link は、VPC (Virtual Private Cloud)、サポートされている AWS サービス、オンプレミスのネットワークの間でプライベート接続を提供し、トラフィックをパブリックインターネットに露出させません。
これは Amazon VPC エンドポイントを利用して実現されます。

Amazon EC2 と Amazon S3 間の接続を確立するための接続先を設定します。
これにより、データ転送に AWS バックボーンネットワークを使用し、インターネット出口料金を回避できます。
接続先はそれ自体と接続先がアクセスを提供するリソースのリソースポリシーで保護できます。
ゲートウェイエンドポイントを使用すると、VPC 用のインターネットゲートウェイや NAT デバイスを必要とせずに VPC から Amazon S3 にアクセスでき、追加料金はかかりません。

#6 Amazon S3 を定期的に、また大規模プロジェクト後に整理する
SAP のインストールとアップグレードでは、データベース、カーネル、プロファイル、SUM ディレクトリ、SAP ソフトウェアファイルの一時的バックアップを保存するために多くの Amazon S3 ストレージ容量が必要になります。
ライフサイクルポリシーを有効にして保持期間を設定するか、プロジェクト完了後に Amazon S3 バケットを整理するタスクをプロジェクト計画に組み込んでください。

Amazon EFS の利用

Amazon EFS は、サーバー間で共有する必要があるファイルシステムである SAP の “/usr/sap/trans”、”/sapmnt”、その他のファイルシステムに利用できます。

https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html

#1 未割り当ての Amazon EFS を確認する
未割り当ての Amazon EFS があれば、中身を確認したうえで削除してください。

#2 ライフサイクルポリシーを有効にする
Amazon EFS ライフサイクル管理を使用して、/usr/sap/trans、SARA がアクセスするアーカイブ、SOX 関連ファイル、SAP ソフトウェア、SAP のインストールとアップグレードツール、バックアップなどの SAP のファイルストレージの経済的な管理を行うことができます。

Amazon EFS の Intelligent Tiering は、ワークロードのファイルアクセス状況を監視し、ファイルシステムの Infrequent Access (IA) ストレージクラスへのファイルを自動的に移行させるように設計されています。

#3 Amazon EFS を定期的にクリーンアップし、大規模なプロジェクトが完了した後にも行う
SAP のインストールやアップグレードには、SAP ソフトウェアファイルや Software Provisioning Manager、Software Update manager などの SAP ツールを保存するために大量の Amazon EFS ストレージが必要になります。

結論

SAP と AWS のベストプラクティスに従って、SAP ワークロードのコストを最適化することは不可欠ですが、顧客にとっては難しい課題となります。

AWS Trusted Advisor や AWS Cost Explorer などの AWS サービスを利用すれば、SAP ワークロードのコストを分析・モニタリングしたり、Amazon S3 や Amazon EFS のライフサイクルポリシーや、SAP 向けに認定されたインスタンス種別やストレージ種別を確認したりできます。これらは、コスト最適化に重要となる分野です。AWS コスト配分タグを活用すれば、AWS のコストを細かいレベルで追跡して高額となる要因を特定することができます。

予算超過を防ぐためのプロセスとガバナンスを整備してください。

次のステップ

毎四半期 (または必要に応じて) 、SAP Lens レビューを AWS Well-Architected ツール (AWS WA ツール) で自助型のコスト最適化の観点から実施してください。AWS WA ツールの実行では、AWS テクニカルアカウントマネージャー (TAM) またはアカウントチームに支援を求めてください。

クラウドリソース管理サービスを実装し、コスト最適化を継続的に監視および改善してください。

ご質問やご確認事項がある場合は、AWS サポートまでお問い合わせください。また、分析中は AWS テクニカルアカウントマネージャー (TAM) または AWS ソリューションアーキテクトにご相談ください。

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

Amazon Web Services ブログ