# ベストプラクティス 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 システム複製スケールアップ - コスト最適化シナリオ) \| 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% をプロビジョンします。 ![](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) をご覧ください。