# ベストプラクティス 10.2 – 可用性および容量要件に適したアーキテクチャを選択する SAP on AWS をデプロイするほとんどのお客様の要件に適した SAP 可用性の標準的なアーキテクチャパターンがあります。以下の提案を参考にして、お客様の可用性および容量要件に最適なパターンを判断してください。ビジネス要件に対して、各障害シナリオのリスクと影響を評価します。 SAP の可用性に関する追加情報については、次のホワイトペーパーを参照してください。 [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) . **提案 10.2.1 – SAP システムに必要なすべてのコンポーネントと AWS サービスを特定する** SAP システムに必要な技術コンポーネントをすべて特定します。コア (データベース、アプリケーションサーバー、中央のサービス、グローバルファイルシステム) から始めて、オプションコンポーネント (例えば、ウェブディスパッチャー、SAProuter、クラウドコネクター) へと広げていきます。これらのコンポーネントをサポートするために必要な AWS サービスを決めます。 **提案 10.2.2 – SLA、耐久性、可用性、および履歴データを障害の可能性のガイドとして使用する** 障害の可能性は主観的です。公開されているサービスレベルアグリーメント (SLA) と過去のパフォーマンスは、将来の潜在的な障害リスクの目安にしかなりません。ただし、さまざまなシナリオの想定頻度は、やはり有益なデータポイントです。統計上、年に一度は発生する可能性のあるものは、まだ発生していない障害より設計の決定に与える影響が大きいかもしれません。 以下の情報はサービスの理解を深めるのに役立ちます。 + [AWS Personal Health Dashboard](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/) は、AWS がユーザーに影響を及ぼす可能性のあるイベントを検出したときにアラートと修正ガイダンスを提供します。 + [AWS Post-Event Summaries](https://aws.amazon.com/premiumsupport/technology/pes/) は、AWS サービスの可用性に影響を及ぼすあらゆる主要なサービスイベントについて提供されます。 + [Amazon Compute Service Level Agreement](https://aws.amazon.com/compute/sla/) は、コンピューティングサービスの SLA をリストします。 + AWS ドキュメント: [Amazon EBS 耐久性と可用性](https://docs.aws.amazon.com/whitepapers/latest/aws-storage-services-overview/durability-and-availability-3.html) + AWS ドキュメント: [Amazon EFS データ保護と可用性](https://aws.amazon.com/efs/faq/#Data_protection_and_availability) + AWS ドキュメント: [AWS Direct Connect の回復性に関する推奨事項](https://aws.amazon.com/directconnect/resiliency-recommendation/?nc=sn&loc=4&dn=2) その他のサポートサービスの障害の可能性も評価する必要があり、これにはドメインネームサービス、ロードバランサー、サーバーレス機能などが含まれますが、これらに限りません。 詳細については、 [「SAP on AWS の可用性と信頼性のためのアーキテクチャガイダンス」ホワイトペーパーを参照してください。](https://docs.aws.amazon.com/sap/latest/general/architecture-guidance-of-sap-on-aws.html) . **提案 10.2.3 – クラスタリング、回復性、およびロードバランシングのためのオプションを評価する** SAP システムは、可用性を確保するために、メカニズムの異なる複数のホストに分散することができます。例えば、クラスタリングソリューションを使用して、単一障害点 (SAP データベースや SAP セントラルサービスなど) を保護することができます。SAP アプリケーション層を水平に拡張でき、ロードバランシングを使用してウェブディスパッチャーの可用性を高めることができます。 + AWS ドキュメント: [SAP NetWeaver Deployment and Operations Guide for Windows - High Availability System Deployment (高可用性システムのデプロイ)](https://docs.aws.amazon.com/sap/latest/sap-netweaver/net-win-high-availability-system-deployment.html) + AWS ドキュメント: [SAP on AWS – IBM Db2 HADR with Pacemaker](https://docs.aws.amazon.com/sap/latest/sap-ibmdb2/sap-ibm-pacemaker.html) + AWS ドキュメント: [SQL Server Deployment for High Availability (SQL Server 高可用性のためのデプロイ)](https://docs.aws.amazon.com/sap/latest/sap-netweaver/sql-server-deployment-for-high-availability.html) + SAP ドキュメント: [High Availability Partners (高可用性パートナー)](https://wiki.scn.sap.com/wiki/display/SI/High+Availability+Partner+Information) **提案 10.2.4 - アベイラビリティーゾーン内の EC2 インスタンスファミリーの可用性を決める** 一部の Amazon EC2 インスタンスファミリー (例えば、X および U) は、すべての AZ で使用可能なわけではありません。AWS アカウントチームまたは AWS サポートとともに、使用したい EC2 インスタンスファミリーが目的のアベイラビリティーゾーンで使用できることを確認します。論理 AZ 識別子は、アカウントによって異なる場合があることに注意してください。詳細については、AWS のドキュメントを参照してください。 + AWS ドキュメント: [AWS リソースの AZ ID](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html) **提案 10.2.5 – 容量を確保するための戦略を調査する** 容量確保に役立つ最善の方法は、障害の際に使用できる同様のサイズのインスタンスを用意しておくことです。その他の戦略としては、クラウドネイティブなオプション (オンデマンドインスタンス、EC2 インスタンス復旧など) や共有容量の再割り当てがあります。 必要なときに容量が使用できるように、SAP 単一障害点をサポートする Amazon EC2 インスタンスについて少なくとも 2 つの AZ で容量コミットメントを行うことをお勧めします。 EC2 容量は、以下を使用して予約できます。 [ゾーンリザーブドインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances-scope.html) または [オンデマンドキャパシティ予約](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservations-using.html) .ゾーンリザーブドインスタンスとオンデマンドキャパシティ予約は、両方とも、同じ AWS 組織内の AWS アカウント間で共有できるため、重大な障害 (完全な AZ 障害など) の際には、別の環境の犠牲容量を使用するというアプローチが可能です。 キャパシティ予約の詳細については、以下を参照してください。 + 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) **提案 10.2.6 – 複数のアベイラビリティーゾーンにまたがって VPC を設計する** 初期の設計が 1 つか 2 つのアベイラビリティーゾーンに依存する場合でも、複数の AZ でインスタンスをプロビジョニングできるように VPC とサブネットを設計します。これにより設計に回復性が組み込まれ、接続性とサービスへのアクセスを事前に確認できます。