# 17 – SAP のアーキテクチャパターンを評価し、コスト効率を高める
**SAP のアーキテクチャパターンの評価にコスト面の配慮をどのように取り入れますか?** アーキテクチャについて決定する場合、設計の検討の一環としてコストへの影響を十分に理解する必要があります。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-17.html)
# ベストプラクティス 17.1 - SAP マネージドサービスの利用を評価する
AWS の責任共有モデルにより、お客様は AWS 上の SAP ワークロードを管理する責任を負います。あるいは、サービスプロバイダーを利用して AWS の SAP ワークロードを管理することができます。サービスプロバイダーを評価する際、初期費用と継続的費用の両方のコスト管理を適切に委託し、継続的プロセスとして扱う必要があります。
複数の AWS パートナーが SAP 環境のデプロイとオペレーションのサービスを提供しています。サービスの範囲や成熟度はパートナーによって異なります。このようなサービスには、例えば効率、一元化されたサポート、デプロイサービスの自動化といった利点があります。それにより、全体的なコストの削減が可能であるため、お客様の具体的なビジネス要件に基づいて評価する必要があります。パートナーの AWS コンピテンシーを評価する際、 [SAP コンサルティングコンピテンシー](https://aws.amazon.com/sap/partner-solutions/) や AWS パートナーネットワーク (APN) を参考にしてください。
**提案 17.1.1 – コスト管理に関連したロールと責任を理解する**
各種マネージドサービス製品は、それぞれ異なるコストモデルに基づいてインフラストラクチャ、ライセンス、サービスをカバーしています。コスト管理の責任がどこにあるかを見極めましょう。そのプロセスでは次のような質問が役に立ちます。
+ プロバイダーのコストは
+ インフラストラクチャ支出の割合に基づくのか
+ 合意した総保有コスト (TCO) に基づくのか
+ 大まかにクラス分けされているか (S、M、L)。 適切な変更管理プロセスが確立されていて、コストが制御可能で内容がわかるようになっているか
+ インフラストラクチャコストの可視性と透明性は十分か
+ コストガバナンスがイノベーションや柔軟性を制限していないか
**提案 17.1.2 – コスト管理と最適化のアプローチについて全当事者と合意する**
各種マネージドサービスを評価するときは、マネージドサービスパートナーのコスト管理に対するアプローチを理解してください。どのように協力すればお客様の組織のコストを継続的に最適化できるかを考える必要があります。
この評価には、定期的なレビュープロセスが必要です。また、共有報酬モデルなどのインセンティブを提供すると、パートナーの責任感が強まり、コストの削減を達成したときに両当事者が財政的なメリットを受けることになるため、有効でしょう。
# ベストプラクティス 17.2 – SAP アプリケーションアーキテクチャパターンのコスト特性を評価する
SAP 環境のアーキテクチャを形作る際、インフラストラクチャの規模や場所に加えてコンポーネント数のコストを考慮してください。ソリューションのビジネス要件を確立し、リスクや最適化の機会を認識することで、大幅なコスト削減が実現できます。
**提案 17.2.1 – 選択した SAP インストールパターンを見直す**
各 SAP アプリケーションについて、スタンドアロン、分散型、高可用性 (HA) といったデプロイパターンを定義します。コスト特性と信頼性特性のバランスを取りながらビジネス要件を満たすようなアーキテクチャパターンを選択します。効果的なアプローチとしては、ビジネスのダウンタイムのコストを数量化し、そこから逆算していく方法が考えられます。可用性に影響する個々の障害のリスクと、そのリスクを削減するのにかかるコストを計算し、バランスを取ります。
さらに、アーキテクチャに最適なサイジングができるだけの柔軟性が備わっているかどうかを検討します。オペレーティングシステムのライセンスやストレージを見直す、複数のアプリケーションサーバーを単一ホストで管理する、といった方法でコストを削減できる場合があります。アプリケーション層に対しては、サポートされているインスタンスファミリーにおいて CPU やメモリを細かく調整し、それに合わせて価格を設定したインスタンスサイズが提供されています。小規模なインスタンスを複数デプロイした場合、インスタンス再利用やワークロードに基づいたスケーリングの選択肢が広がります。
論理的なグループ分けを評価し、コンポーネント、システム (SID)、環境を組み合わせたときの効果を検討してください。これらのアクティビティによってオペレーションの複雑さが増し、信頼性が低下するかどうかを考えます。
+ AWS ドキュメント: [Architecture Guidance for Availability and Reliability of SAP on AWS (SAP on AWS の可用性と信頼性のためのアーキテクチャガイダンス)](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html)
+ SAP Lens [信頼性]: [信頼性の設計原則](reliability.md)
+ AWS Well-Architected Framework [信頼性]: [信頼性の柱](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)
**提案 17.2.2 – 例外的なマルチテナントの使用または単一ホストでの複数データベースのホスティングを評価する**
ほとんどのデータベースでは、システムの要件に合わせた柔軟なインスタンスサイジングを活用して各システムを個別にサイジングします。ただし、その原則に従わない方がコスト面のメリットが大きいケースもあります。例:
+ HANA ベースのコンポーネントが必要とするメモリが、用意されている最小の EC2 インスタンスサイズより少ない場合は、 [SAP HANA マルチテナントデータベースコンテナ](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/623afd167e6b48bf956ebb7f2142f058.html)の使用を検討します。他のコンポーネントと一緒にホストすれば、コンピューティングリソースを効率的に使用できます。
+ Oracle および SQL Server などのリレーショナルデータベースに適したコアベースのデータベースライセンスモデル
+ アップタイム要件とバージョン依存関係のために密接に結びついているアプリケーション。これには、管理ツール (例えばソリューションマネージャーや SAP HANA Cockpit)、一部の SAP NetWeaver Gateway デプロイオプション (Fiori および ECC) が含まれます。
**提案 17.2.3 – 回復力やスケーラビリティを必要としないシステムについて単一ホストインストールパターンの使用を評価する**
個々のアプリケーションや環境について、単一ホストモデルのメリットを考える必要があります。単一ホストモデルを利用することで、システムの運用コストやストレージの重複、ソフトウェアライセンスのコスト、マネージドサービスのコストを節約できる場合があります。特に非本番稼働環境で一般的なアーキテクチャオプションには、次のようなものがあります。
+ 共同ホストデータベース、アプリケーション、SAP Central Services
+ 個別のデータベース (データベースライセンスを最小限に抑える)詳細については次を参照 [コスト最適化]: [ベストプラクティス 18.3 - ライセンス形態の影響と最適化オプションを評価する](best-practice-18-3.md) .
+ アプリケーションと SAP Central Services の組み合わせ
**提案 17.2.4 – コスト効率が最も良く、要件に合ったリージョンを選ぶ**
SAP リージョンを選択する際の主要な基準は、近接性、データレジデンシー、サービスの可用性です。複数の選択肢があるデプロイでは、各 AWS リージョンで提供されている料金が地元市場の条件に基づくことに注意してください。そのため、AWS サービスの料金はリージョンごとに異なります。料金の差とその影響を確認してください。
**提案 17.2.5 – 障害発生時にスケールできるアーキテクチャを使用する**
復旧メカニズムとクラウドの伸縮性により、冗長ストレージが 100% 稼働する必要のない設計が可能です。ビジネス要件が、より柔軟な RTO または RPO を許すようであれば、以下の点を考慮してください。
データベース:
+ 目標復旧時点が許すなら、プライマリデータベースノードからの変更を適用するのに同等のコンピューティング性能を必要としないセカンダリまたはスタンバイデータベースノードを検討します。復旧時間への影響を考慮した上で、セカンダリにより小さなインスタンスまたは共有インスタンスをデプロイし、必要なときだけスケールアップする場合のコスト面でのメリットを検討します。より小さなインスタンスを使用すると、プライマリシステムインスタンスとセカンダリシステムインスタンスの関係は 1 対 1 に保たれます。共有インスタンスアーキテクチャが、セカンダリデータベースを非複製システムデータベースとともに単一インスタンスにプールします。障害が発生した場合、テイクオーバーが起こる前に非複製システムを停止しなければなりません。これは、RTO の増加につながります。
+ セカンダリ SAP HANA データベースにより小さいインスタンスを使用している場合は、メモリの事前ロード機能をオフにしてスタンバイ時のメモリフットプリントを小さくし、コストを削減します。SAP によるメモリ要件の見積もりは、 [Secondary System Usage (セカンダリシステムの使用) ](https://help.sap.com/viewer/4e9b18c116aa42fc84c7dbfd02111aba/2.0.05/en-US/9d62b8108063497f9d6aab08902b2e04.html)のヘルプドキュメントに記載されています。
+ SUSE ドキュメント: [SAP HANA System Replication Scale-Up - Cost Optimized Scenario (SAP HANA システム複製スケールアップ - コスト最適化シナリオ) \$1 SUSE](https://documentation.suse.com/sbp/all/html/SLES4SAP-hana-sr-guide-CostOpt-12/index.html)
+ 目標復旧時間と回復力の要件が許せば、データとログのバックアップに関してマルチ AZ ストレージを使用するアプローチを検討してください (Amazon FSx、Amazon EFS、Amazon S3 など)。これらのアプローチでは、冗長セカンダリリソースを必要とせずにデータの地理的保護が可能です。障害が発生した場合、オンデマンドでセカンダリリソースを作成し、ロケーション間バックアップとログストレージから迅速に復元することができます。
+ SAP on AWS ブログ: [How to use snapshots to create an automated recovery procedure for SAP ASE databases (スナップショットを使用した SAP ASE データベースの自動化された回復手順を作成する方法)](https://aws.amazon.com/blogs/awsforsap/how-to-use-snapshots-to-create-an-automated-recovery-procedure-for-sap-ase-databases/)
アプリケーション:
+ [AWS インスタンスリカバリ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) は、CloudWatch アラームを使用して Amazon EC2 インスタンスをモニタリングし、ハードウェア障害が原因でインスタンスに問題が発生した場合に自動的にインスタンスを復旧します。カバーされている障害シナリオを確認し、十分な保護が提供されているかを評価してください。
+ アプリケーションサーバーをすばやく再作成しなければならないシナリオでは、プロビジョン済みで実行されていない EC2 インスタンス、テンプレート化した AMI、一般的なステージングサーバーを使用したストレージレプリケーション、Infrastructure as Code (IaC) などのオプションがあります。
**提案 17.2.6 – 障害発生時の最小コンピューティング性能のコストを検討する**
SAP コンポーネントをアベイラビリティーゾーン間で分散させることで、障害発生時のキャパシティ予約にかかるコストが削減できます。アベイラビリティーゾーン間でコンポーネントを分散させれば、ワークロードの一部が地理的に散らばっているため、余分な容量が必要になりません。これにより、AZ 障害が発生しても影響範囲を最小限に抑えることができます。
例えば、障害が発生して 1 つのアベイラビリティーゾーンが失われた状況で 100% の容量が必要なシナリオでは、2 つのアベイラビリティーゾーンの間で 200% の容量をプロビジョンするのではなく、3 つのアベイラビリティーゾーンで 150% をプロビジョンします。
![\[SAP production account with three availability zones, each hosting application and database instances.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/images/example-three-availability-zone-architecture.png)
**提案 17.2.7 – ストレージのみに基づいた復旧オプションの使用を評価する**
AWS では全般に、広範な障害シナリオからの保護を保証するため、ストレージレプリケーションよりデータベースレプリケーションを推奨しています。アプリケーションレイヤーまたはそれほど重要でないインスタンスについては、コンピューティングが不要なストレージレプリケーションを使用した DR ソリューションでコストを削減することができます。それにより、変更管理に関連した複雑さも軽減されます。
+ AWS ドキュメント: [CloudEndure Disaster Recovery - アマゾン ウェブ サービス (AWS)](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ SAP ドキュメント: [CloudEndure Disaster Recovery for SAP Applications](https://d1.awsstatic.com/products/CloudEndure/Disaster_Recovery_for_SAP_Applications.pdf)
+ AWS ドキュメント: [Replicating automated backups to another AWS Region - Amazon Relational Database Service (Amazon RDS) (別の AWS リージョンへの自動バックアップのレプリケーション - Amazon Relational Database Service (Amazon RDS))](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReplicateBackups.html)
**提案 17.2.8 – ネットワーク関連のコストを理解する**
SAP のお客様の多くは、オンプレミスネットワークと Amazon VPC を安全に接続する必要があります。適切なサイズの Direct Connect か VPN 接続、またはその両方を使用すると、パフォーマンスおよび信頼性の要件を満たしながらコストを最小限に抑えることができます。
データ転送のコストは、リージョン、VPC、アベイラビリティーゾーンの設計に左右されます。SAP コンポーネントの分散とレプリケーションを、どうすれば信頼性に影響することなく最適化できるか評価してください。
例えば、大量のデータを転送する 2 つのシステムが別々の場所にある場合は、データ転送コストへの影響を考えます。
+ AWS ドキュメント: [Amazon EC2 オンデマンド料金](https://aws.amazon.com/ec2/pricing/on-demand/)
+ AWS ドキュメント: [Architecture Patterns - General SAP Guides (アーキテクチャパターン - 一般 SAP ガイド)](https://docs.aws.amazon.com/sap/latest/general/arch-guide-architecture-patterns.html)
詳細なガイダンスは、Well-Architected Framework のコスト最適化の柱のレビュー、 [Plan for Data Transfer - Cost Optimization Pillar (データ転送を計画する - コスト最適化の柱) ](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/plan-for-data-transfer.html) をご覧ください。
# ベストプラクティス 17.3 – 各環境の設計においてコストが最適化されるような決定を行うためのビジネス要件を理解する
システムまたは環境それぞれのコストをその特性に基づいて最適化しましょう。ビジネス要件に合わせて容量、パフォーマンス、信頼性、運用時間を検討します。エンドユーザーエクスペリエンスやビジネスプロセスにとってあまり重要でない環境やアプリケーションの場合は、ストレージやコンピューティング、運用時間を最小限に抑えてコストを削減します。構成を簡素にすることで削減できるコストと、テストまたはサポートのオペレーション要件の間でバランスを取ります。
**提案 17.3.1 – 非本番稼働環境で本番稼働のデータの完全コピーが必要かを評価する**
非本番稼働環境に本番稼働データの完全コピーを用意することは、ストレージコストとコンピューティングコストに大きく影響します。テスト要件を満たしながら本番稼働データのコピーの数を最小限に抑えることを検討しましょう。非本番稼働環境のデータストレージコストは、次のような方法で抑えることができます。
+ 開発およびテストシステムに使用するストレージ容量を少なくします。
+ データスライシングツールを使用して非本番稼働システムのテストデータから小さなサブセットを切り取ります。
+ 一時本番稼働コピーの使用を検討します。一時本番稼働コピーは、オンデマンドで作成して、ビジネスニーズやテストが終わった時点ですばやく廃棄またはアーカイブすることができます。
+ SAP HANA データベースに対して推奨されている 50% の作業メモリが、非本番稼働システムで必要かどうかを評価します。
**提案 17.3.2 – 非本番稼働環境で常に本番稼働と同じパフォーマンスが必要かを評価する**
非本番稼働システムと一部のサポートシステムでは、ユーザーの数が比較的少ないか、処理するトランザクションボリュームが大幅に少ない、または応答時間の要件が柔軟であるのが普通です。以下の点を考慮してください。
+ 小さめの EC2 インスタンスタイプを使用することで、ワークロードの SAP Application Performance Standard (SAPS) を小さくします。
+ 使用するアプリケーションサーバーの数を少なくします。
+ 低コストの Amazon EBS ストレージタイプを使用します (例えば、 `io2` ではなく `gp3` )。
+ 非本番稼働システムのボリュームとして、パフォーマンス特性が低めのものを選びます (例えば、10,000 IOPS ではなく 3,000 IOPS)。
+ クラウドの伸縮性が意味するのは、ロードテストやスケーリングテストなど、本番稼働と同等のパフォーマンスを必要とする非本番稼働テストリソースをスケールアップできることです。
**提案 17.3.3 – 非本番稼働環境で本番稼働と同等の運用時間が必要かを評価する**
テスト、トレーニング、およびサンドボックスシステムのような非本番稼働環境では、本番稼働環境より運用時間が短いことがあります。サポートチームのタイムゾーンと営業時間を考慮して、すべてのシステムが年中無休 24 時間体制であるべきかどうかを判断します。この情報を使って最低の料金モデルを選択します。
例えば、オンデマンド料金モデルで SAP トレーニングシステムを週 40 時間実行した場合 (最大 23% のアップタイム)、3 年間のリザーブドインスタンスまたは Savings Plan で常時 100% 実行した場合より安価です。
**提案 17.3.4 – 非本番稼働環境で常に本番稼働と同等の信頼性が必要かを評価する**
個々のシステムの信頼性要件に合わせてコスト効率の最も高いアーキテクチャを選びましょう。[信頼性]: [ベストプラクティス 10.1 – ビジネス要件に合った SAP ワークロードの可用性目標について合意する ](best-practice-10-1.md) を参照してください。詳細なガイダンスは、 [信頼性の柱](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html) - AWS Well-Architected フレームワークをご覧ください。
テスト目的だけに本番稼働環境同様のアーキテクチャを用意する場合は、本番稼働をミラーリングしなければならない頻度について考えます。信頼性またはパフォーマンステストのために非本番稼働環境でデータベースの高可用性を実現する必要があるなら、テスト期間外にセカンダリインスタンスをシャットダウンまたはスケールダウンすればコストが削減できます。
オートメーションの使用や、本番稼働同様のパフォーマンスを常に必要とするわけではない環境にオンデマンド料金を適用することで、コスト効率を高めることができます。
**提案 17.3.5 – サポートおよびレガシーシステムなどコア以外のシステムのビジネス要件を評価する**
参照目的だけにある環境、またはビジネス上それほど重要な役割を持たない環境については、アップタイム、パフォーマンス、信頼性の要件をコアの本番稼働システムと比較して評価します。
例えばレガシーの ERP システムなら、以前のアプリケーションからの変換やビジネス再編を理由とした参照目的で維持する場合があるでしょう。このようなシステムでは、必要なときだけ EC2 インスタンスを実行し、Amazon EBS ストレージの料金だけ支払うようにしてコストを最適化できます。コスト効率がさらに高いのは、バックアップを介してシステムを Amazon S3 と Amazon S3 Glacier にアーカイブするというソリューションです。
# ベストプラクティス 17.4 – SAP コンポーネント用に EC2 インスタンスの規模、詳細度、最新製品を確認する
小規模な EC2 インスタンスを選ぶと、SAP ワークロードのコストの柔軟性が高くなります。水平スケーリングが可能になり、使用しないときにコンピューティングをオフにしたり、ピーク負荷時にスケールアップしたりできます。アプリケーション層に一貫した EC2 インスタンスサイズを採用すれば、リザーブドインスタンスおよび Savings Plans 契約の利点をあらゆるワークロードで最大限に活用できます。最新の AWS SAP 認定インスタンスを考慮に入れてください。運用上の影響、ライセンスコスト、サポート、共有および再利用性もコンポーネントごとに評価する必要があります。
**提案 17.4.1 – 小規模なアプリケーションサーバーを複数使用して柔軟性を持たせた場合のコストメリットを評価する**
SAP ワークロードの多くで、イミュータブルなアプリケーションサーバーを設計することができます。基本ユニットをレプリケーションして水平スケーリングする標準のアプリケーションサーバー構成では、一貫した繰り返し可能なユニットのオプションが使用できます。利点は、再利用性、コンピューティング使用率、予約、オートメーションです。オペレーティングシステムのライセンスやストレージの重複、管理コストなど、ユニットごとの要件を評価に含める必要があります。
以下の点を考慮してください。
+ SAP on AWS ブログ: [DevOps for SAP – Driving Innovation and Lowering Costs (SAP 向け DevOps – イノベーションの促進とコストの削減)](https://aws.amazon.com/blogs/awsforsap/devops-for-sap-driving-innovation-and-lowering-costs/) .
+ SAP on AWS ブログ: [Using AWS to allow SAP Application Auto Scaling (AWS を使用して SAP Application Auto Scaling を有効にする)](https://aws.amazon.com/blogs/awsforsap/using-aws-to-enable-sap-application-auto-scaling/)
**提案 17.4.2 – SAP HANA スケールアウト構成 (がサポートされている場合) のコストメリットを評価する**
SAP OLAP ワークロードは、 [スケールアップとスケールアウトの](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.05/en-US/a165e192ba374c2a8b17566f89fe8419.html) 構成の両方でデプロイできます。SAP は、運用を簡略化するためにスケールアウトより先にスケールアップすることを推奨しています。しかし、大量の分析ワークロードやネイティブの SAP HANA ワークロードで大規模なコンピューティングが必要となる場合は、スケールアウト実装が適切なことがあります。
S/4HANA も一部のケースでスケールアウト構成をサポートしていますが、制限があります。次を参照してください。SAP Note: [2408419 - SAP S/4HANA - Multi-Node Support (SAP S/4HANA - マルチノードのサポート)](https://launchpad.support.sap.com/#/notes/2408419) [SAP ポータルへのアクセス権が必要]。
スケールアップとスケールアウトのどちらを選ぶかを検討するときは、次の点を考慮します。
+ [Certified EC2 instance sizes (認定 EC2 インスタンスのサイズ) ](https://www.sap.com/dmc/exp/2014-09-02-hana-hardware/enEN/#/solutions?filters=iaas;ve:23;v:105) のうち、スケールアップとスケールアウトに利用できるもの
+ 各インスタンスファミリー用の EC2 メモリの 1 GiB あたりのコスト。大規模な EC2 インスタンスは、小規模なインスタンスに比べて 1 GiB あたりのコストが高いのが普通です。
+ スケールアウトデプロイによって生じる、データ分散管理の複雑さと運用諸経費。次を参照してください。SAP Note: [2081591 - FAQ: SAP HANA Table Distribution (FAQ: SAP HANA テーブルディストリビューション)](https://launchpad.support.sap.com/#/notes/2081591) [SAP ポータルへのアクセス権が必要]
# ベストプラクティス 17.5 – コスト効率を高める目的でオンデマンドキャパシティの使用を検討する
オンデマンド料金モデルは、短めの運用時間、短期プロジェクト、試験的運用が必要となる、または (例えばパフォーマンステストのために) 短期間だけ容量を拡張する必要がある SAP ワークロードに適しています。使用している SAP アーキテクチャのどこでオンデマンド料金が利用できるかを特定します。
**提案 17.5.1 – 年中無休 24 時間体制を必要としない SAP システムでのオンデマンドの利用を評価する**
オンデマンド料金モデルとその他の料金モデルを利用した場合の損益分岐点に基づいて ([信頼性]: [ベストプラクティス 18.1 - Amazon EC2 の利用可能な支払いおよび契約オプションを理解する](best-practice-18-1.md) )、オンデマンドの方が低コストかどうかを評価します。この評価では、Savings Plan 契約全体も考慮に入れます。
一般的なユースケースとしては、営業時間または短期のビジネス実験 (トライアルアップグレード、概念実証など) 以外には必要でない非本番稼働システムが挙げられます。
+ SAP on AWS ブログ: [SAP システムの起動停止自動化を AWS Systems Manager で実現](https://aws.amazon.com/blogs/awsforsap/automate-start-or-stop-of-distributed-sap-hana-systems-using-aws-systems-manager/)
**提案 17.5.2 - ピーク負荷に備えてスケジュールされたスケーリングオプションと動的スケーリングオプションを評価する**
オンデマンドキャパシティは、通常、容量要件が短期間だけ急上昇したピークの SAP ワークロードで使用されます。以下の点を考慮してください。
+ 期間、月末、年末、季節性ピークなど、使用パターンが既知である場合のピークには、スケジュールベースの SAP アプリケーションサーバースケーリングを使用します。
+ ピークがより不確実でユーザー負荷に合わせてリアルタイムでスケーリングする必要があるアプリケーション層には、動的スケーリングを適用します。SAP 対応で、必要なガバナンスとコントロールを備えたメカニズムを検討します。
**注記:** アプリケーション層の動的スケーリングを評価する際は、ステートフルな SAP コンポーネントが原因で SAP アプリケーションサーバーがシャットダウンされた場合にユーザー接続とバッチジョブ影響が受ける影響を考慮します。この要件への対処には、AWS、SAP、APN パートナーの開発によるツールが役立ちます。
+ AWS ドキュメント: [Systems Manager オートメーションアクションのリファレンス](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-actions.html)
+ SAP ドキュメント: [SAP Landscape Management (SAP 環境管理)](https://www.sap.com/products/landscape-management.html)
+ SAP on AWS ブログ: [Using AWS to enable SAP Application Auto Scaling (AWS を使用した SAP アプリケーションのオートスケーリングの有効化)](https://aws.amazon.com/blogs/awsforsap/using-aws-to-enable-sap-application-auto-scaling/)
# ベストプラクティス 17.6 – 共有サービスおよびソリューションのコストメリットと影響を評価する
複数の SAP システムが同じ機能を必要とするケースでは、既存のソリューションや共有コンポーネントを使用して管理とコストを一元化すると、コスト効率が高まります。AWS アカウント境界の内側、または専用のアカウントで管理できる一般的な機能には、モニタリング、バックアップ、接続性があります。標準化、重複の削減、複雑さの軽減がコストの削減につながります。
適度な隔離を維持しながら、また運用に影響する可能性のある依存関係を作り出すことなく、コスト削減のためにリソースを共有する方法を見つけましょう。
**提案 17.6.1 – 共有サービスごとに 1 対多のセットアップと比べた 1 対 1 のコストメリットを評価する**
SAP 環境では、マルチアカウント戦略の一環として、非本番稼働ワークロードと本番稼働ワークロードを別々のアカウントに隔離するのが標準的なパターンです。これは、一部のサービスにとって論理的境界となります。管理境界を含むことでセグメント化を余儀なくする各シナリオの複雑さと運用コスト、さらにリージョン、AZ、VPC、アカウント間でのデータ転送コストの影響を検討します。
マルチアカウント設計では、一部の AWS サービスを一元的にホストし、ハブアンドスポーク設計で複数のアプリケーションおよびアカウントからアクセスしてコストを節約することができます。次のサービスが含まれます。
+ スポーク VPC からのアウトバウンドトラフィック用専用 VPC と NAT ゲートウェイ
+ ロードバランサーとウェブディスパッチャーの一元化モデル
+ 転送その他のファイル共有ニーズのための共有 Amazon EFS または Amazon FSx
**提案 17.6.2 – 既存のサービスを再利用してコストを削減できる場所を評価する**
この提案は、さまざまなレベルに当てはまります。
+ AWS のサービスがあるところでそれを利用すると、諸経費が最小限に抑えられるので消費ベースの料金モデルに最適です。例として、Amazon EFS、SAP HANA 向け AWS Backint、AWS Backup が挙げられます。
+ 一部の機能 (例えばエンタープライズバックアップ) に対して全社的な標準が設定されている場合は、それを使用して運用の一貫性とスケールメリットを保つ必要があります。
+ AWS Marketplace または BYOL (Bring-Your-Own-License) では、具体的なビジネス要件に合った APN パートナーソリューションが入手できます。
+ ライセンス込みの AWS Marketplace マシンイメージにより、初期コストを削減できる可能性があります。このシナリオでは、ライセンス制限を考慮する必要があります。なぜなら、異なるインスタンスタイプへの移植性が制限されるとソリューションの柔軟性に影響が及ぶからです。
**提案 17.6.3 – ビルド・購入・オープンソースの各アプローチを使った場合の影響を理解する**
AWS のソリューションも APN パートナーのソリューションも、自分でビルドを作成する部分、オープンソースの部分、既製品の部分が異なる比率で組み合わさっています。バックアップソリューション、高可用性 (HA) ソリューション、共有ストレージソリューションがその例です。
自分でビルドを作成するアプローチ、またはオープンソースソリューションの使用を検討する場合は、次の点を考慮する必要があります。
+ サービスレベルアグリーメント (SLA)
+ ビルドとメンテナンスに必要なスキル
+ サービスの停止がビジネスに及ぼす影響
また、具体的なビジネス要件に合わせて購入しようとしているソリューションについて、入手可能な商用モデルとその機能性を評価する必要があります。商用モデルの条件、例えば使用権を購入するのか利用に応じて料金を支払うのか、料金はどのように計算されるのかを検討します。
# ベストプラクティス 17.7 – オートメーションのコストメリットを評価する
AWS にオートメーションを導入することのメリットは、効率と生産性が上昇し、組織のコストの削減につながることです。
**提案 17.7.1 – ビルドオートメーションの効率を評価する**
Infrastructure as Code を使ったビルドプロセスのオートメーションは、コスト効率に優れ、市場投入までの時間と生産性の改善につながります。品質、整合性、反復性、回復性といった面で DevOps のベストプラクティスがどの程度のメリットをもたらすかを、オートメーションの開発にかかる初期投資の高さと比較する必要があります。
AWS Professional Services または AWS パートナーと協力し、その経験を活用すれば、全体的な労力を減らすことができます。
AWS Launch Wizard for SAP は、オートメーションを通じて SAP デプロイを加速させます。このサービスは、AWS での SAP HANA アプリケーションのサイジング、設定、デプロイの手順を SAP のベストプラクティスに沿って案内します。これは追加料金なしで利用できるサービスで、AWS によるサポートも提供されます。
+ AWS ドキュメント: [Infrastructure as Code](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)
+ AWS ドキュメント: [AWS CloudFormation](https://aws.amazon.com/cloudformation/)
+ SAP on AWS ブログ: [AWS for SAP DevOps (SAP DevOps 向け AWS)](https://aws.amazon.com/blogs/awsforsap/category/devops/)
**提案 17.7.2 – 運用のオートメーションの効率を評価する**
運用の実施とモニタリングを自動化する上で AWS およびサードパーティーのツールをどのように利用できるかを調べ、反復タスクのコストと手間を減らしましょう。以下の点を考慮してください。
+ AWS サービス: [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)
詳細なガイダンスは、[運用上の優秀性] [ベストプラクティス 3.6 - オートメーションを使用して SAP 環境オペレーションを実行する](best-practice-3-6.md) をご覧ください。