# 10 – 障害に耐える設計
**SAP ワークロードを障害に耐えるようにどのように設計しますか?** ビジネス要件からさかのぼって、SAP インフラストラクチャとデータの可用性目標に合わせたアプローチを定義します。それぞれの障害シナリオについて、回復性要件、受け入れ可能なデータ損失、および平均復旧時間 (MTTR) は、サポートするコンポーネントとビジネスアプリケーションの重要性に比例する必要があります。SAP の可用性のために提供されるアーキテクチャのパターンは、ほとんどのお客様の要件に対応していますが、定義した条件に基づいて適応させることができます。これらの条件には、各障害について認識されたリスクと影響を含める必要があり、コストとパフォーマンスも考慮する必要があります。どのような場合も、初期テストと定期的なテストによって、決定を検証してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-10.html)
詳細については、以下の情報を参照してください。
+ 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) 以下が含まれます。 [障害シナリオ](https://docs.aws.amazon.com/sap/latest/general/arch-guide-architecture-patterns.html#arch-guide-failure-scenarios) とアーキテクチャパターン
+ AWS ドキュメント: [The Amazon Builders' Library: アベイラビリティーゾーンを使用した静的安定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ AWS ドキュメント: [Multiple data center HA network connectivity](https://d0.awsstatic.com/aws-answers/AWS_Multiple_Data_Center_HA_Network_Connectivity.pdf)
+ SAP ドキュメント: [SAP HANA システムアーキテクチャの概要](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/LATEST/en-US/1b4477a539ab4b77a3bfe2a6835b5e0e.html)
# ベストプラクティス 10.1 – ビジネス要件に合った SAP ワークロードの可用性目標について合意する
可用性目標を理解することは、組織にとって重要な要素に注意を向けるための最初のステップです。これは、アーキテクチャパターンの評価に使用できる条件を定義する上で役立ちます。
**提案 10.1.1 – 範囲内の SAP アプリケーションとそれらの相互依存関係を特定する**
AWS にデプロイした、またはデプロイする予定の SAP アプリケーションを特定します。場所に関係なく、これらのアプリケーションの依存関係を理解します。
**提案 10.1.2 – 障害の影響に基づいてシステムを分類する**
計画された可用性と障害のリスクに応じたシステム分類について、公開されているスタンダードはありません。「ミッションクリティカル」や「非常に重要」などの用語を使用したシステムの定義は、パターンの定義、アプリケーショングループの識別、およびコストの正当化に役立ちます。生産アプリケーションは、停止によって異なる影響を受ける可能性があります。考慮すべき要素は、次のとおりです。
+ 収益創出または収益報告
+ 外向きまたは内向き
+ コアビジネス対技術サポート
+ 他のシステムとの密結合対疎結合
非生産環境もビジネスの間接的なサポートにおいて重要な役割を果たすことがあります。これらはプロジェクトのフェーズとスケールに従って分類する必要があり、トランスポートパス (通常営業とプロジェクトなど) やサポートの役割 (開発、ユニットテスト、生産コピー、トレーニングなど) を考慮に入れる必要があります。
**提案 10.1.3 – 停止によるビジネスへの影響を評価する**
影響は測定可能でなければならず、停止の期間を考慮する必要があります。影響分野の例としては、健康と安全性、財務、法務、規制、ブランドなどがあります。
**提案 10.1.4 – コンプライアンスおよび規制要件を理解する**
データレジデンシーと場所間の距離に関するコンプライアンスまたは規制要件を理解することは、事業継続性の確保に役立ちます。
**提案 10.1.5 – 最小許容稼働率を定義する**
各システムまたは各システムグループについて、ビジネス要件に応じた許容可能稼働率を合意し、文書化します。このコンテキストでは、以下の用語が使用されます。
+ MTTR – 平均復旧時間
+ RTO – 目標復旧時間
+ RPO – 目標復旧時点
用語の詳しい説明については、「Well-Architected Framework [信頼性]」を参照してください。 [可用性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html) .SAP における信頼性の詳細については、次のホワイトペーパーを参照してください。
+ 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 – 可用性および容量要件に適したアーキテクチャを選択する
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 とサブネットを設計します。これにより設計に回復性が組み込まれ、接続性とサービスへのアクセスを事前に確認できます。
# ベストプラクティス 10.3 – 重要な SAP データの可用性を確保するアプローチを定義する
SAP アプリケーション用のビジネスデータは、主にデータベースに保存されますが、バイナリ (実行可能ファイル、ライブラリ、スクリプトなど)、構成、インターフェイスの場合はファイルベースのデータを含むこともあります。選択したアプローチの耐久性、整合性、および復旧オプションを調べて、データの重要性や許容可能データ損失率 (RPO) に合うことを確認する必要があります。
**提案 10.3.1 – MTTR 要件を評価して、要件を満たす方法を特定する**
[信頼性] [提案 10.1.5 – 最小許容稼働率を定義する](best-practice-10-1.md) で、各アプリケーションの MTTR 要件を定義します。障害のリスクとシステムの可用性を保護するメカニズムを評価した後は、要件を満たせることを確認し、各障害シナリオで予想される MTTR を文書化します。コスト、複雑さ、または整合性の点で妥協が必要な場合は、ビジネス所有者と協議して、合意を得ます。
**提案 10.3.2 – バックアップからの復旧が必要になる障害シナリオを判断する**
バックアップは、多くの場合、可用性を確保または復旧するための 2 次的なメカニズムですが、ほとんどのアーキテクチャは何らかの形でバックアップに依存します。以下は、分析の参考になる障害シナリオの例です。シナリオ、分類、および影響の詳細度は、要件とアーキテクチャによって異なります。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/best-practice-10-3.html)
**提案 10.3.3 – データのレプリケーションが必要な場所を決める**
データのレプリケーションは、同じデータのコピーを複数の場所に置くことによって信頼性を高めるために使用され、多くの場合、RPO が低いシステムの要件です。可用性または復旧のためにレプリケーションが必要かどうかを判断するときには、サービスがゾーン別 (Amazon EC2 および Amazon EBS とそれらがサポートするデータベースなど) かリージョン別 (共有ストレージと Amazon S3 など) かを考慮してください。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/best-practice-10-3.html)
[AWS DataSync](https://aws.amazon.com/datasync/) を使用して、必要な場合、 [Amazon EFS](https://aws.amazon.com/premiumsupport/knowledge-center/datasync-transfer-efs-cross-region/) と [Amazon FSx](https://aws.amazon.com/blogs/aws/aws-datasync-update-support-for-amazon-fsx-for-windows-file-server/) の両方をリージョンにまたがって保護できます。
[CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/) は、AWS アカウント間も含め、アベイラビリティーゾーンまたはリージョン間でインスタンスを継続的に複製します。
**Amazon S3 レプリケーション**
バックアップやその他のオブジェクトストレージは、Amazon S3 に保存されることがあり、以下を使用して複製できます。 [Amazon S3 レプリケーション](https://aws.amazon.com/s3/features/replication/) .
**提案 10.3.4 – 一貫した構成データとバイナリを確保する戦略を立てる**
予測可能な動作と障害後のテスト済みセットアップを確保するためには、一貫性のある構成データとバイナリが重要です。これには、オペレーティングシステムのパッケージ、アプリケーションのパラメータ、およびクラスター構成が含まれます。回復力のためのもの (追加のアプリケーションサーバー、セカンダリデータベースノードなど) も含め、アプリケーションのすべてのインスタンスについて整合性を確保する方法を決めます。
Amazon EFS、Amazon FSx、および Amazon S3 は、共有バイナリまたは構成を集中管理できる耐久性の高い場所を提供します。
[運用上の優秀性] [ベストプラクティス 2.1 - バージョン管理と設定管理を使用する](best-practice-2-1.md) の柱のバージョン管理と構成管理のメカニズムを参照してください。
**提案 10.3.5 – データ整合性のための包括的アプローチを持つ**
重要な SAP データの整合性を確保するためのアプローチは、単一のデータセットに注目するだけでなく、データセット内とシステム内およびデータセット間とシステム間の依存性も考慮する必要があります。例えば、プルの元になるソースシステムではなく SAP BW システムを復旧する必要がある場合、変更ポインターにはどのような影響が予想され、整合性のある復旧を確保するためにどのようなメカニズムが存在しているでしょうか?
**提案 10.3.6 – データを再生または再送信できるインターフェイスの戦略を立てる**
システム間のデータ交換について、統合が疎結合かどうかと、ソースまたはターゲットでデータを再生または再送信できるかどうかを判断します。シナリオを中断したり、停止中にキャッシュしたりできるキューイング機能があるかどうかをレビューします。
**提案 10.3.7 – データバンカーの使用を評価する**
偶発的な削除や悪意ある行動などの状況により、オンラインデータが使用不能または入手不能になるような障害シナリオでは、データの保護または復旧可能性を確保するために異なるアプローチが必要になることがあります。
ネットワーク分離とアクセスコントロールをカバーするセキュリティフレームワークでの予防が最良の防御ですが、復旧と回復のコンテキストで影響を考慮する必要があります。
保持期間が限られた *書き込み専用* バックアップアカウントを使用するのが、このようにまれですが潜在的に高い影響力を持つシナリオでの一般的なアプローチです。
+ SAP Lens [セキュリティ]: [ベストプラクティス 8.3 - データ復旧メカニズムを確保して、脅威から保護する](best-practice-8-3.md)
# ベストプラクティス 10.4 – ビジネス要件に基づく一連の条件に対して設計を検証する
ビジネスの要件に基づき、障害のリスク、ビジネスへの影響、および許容可能なトレードオフのバランスを取って、一連の条件を設定します。これらの条件を使用して、設計を検証し、必要な場合は調整を加えます。
**提案 10.4.1 – 停止によるビジネスのコストを評価する**
AWS サービスまたは SAP コンポーネントの障害は、回復性および復旧戦略に応じて異なる影響を SAP システムに及ぼします。障害のタイプによって、停止の期間 (RTO) と潜在的なデータ損失 (RPO) が決まります。
障害ごとに、停止のリスクとビジネスのコストを評価します。例えば、システムが使用できないことによって影響を受ける収益創出プロセスがありますか、また、時間あたりのコストはどのくらいですか?
**提案 10.4.2 – アーキテクチャのコストを評価する**
SAP 環境では、AWS の月額で最大の要素は、一般に Amazon EC2 とストレージ関連のサービスです。コストへの影響を理解して、信頼性要件に応じた最良のアーキテクチャを選択してください。主な要因には以下のものがあります。
+ ハードウェアの利用率を最大化しないデプロイパターン
+ 冗長なデータコピー
+ オペレーティングシステムのライセンスコスト
+ クラスタリングソフトウェアライセンスのコスト
+ メンテナンス、テスト、およびスキルを備えた人材に関連するコスト
詳細については、[コスト最適化]: [コスト最適化のためのベストプラクティス](cost-optimization.md) を参照してください。
**提案 10.4.3 – フレームワークの他の柱に対して設計を評価する**
信頼性は単独で設計することはできず、AWS Well-Architected Framework の他の柱に対して評価する必要があります。これを評価するための質問の例を以下に示します。
+ 運用上の優秀性 — ソリューション管理の経験とスキルはありますか?
+ セキュリティ — データはレプリケーションや復旧などの際に保護されていますか?
+ パフォーマンス — レプリケーションまたはバックアップアクティビティはユーザーのパフォーマンスに影響を与えますか?
+ コスト最適化 — ソリューションのコストは想定されるリスクに合っていますか?