# 11 – 障害を検出し、対応する
**SAP ワークロードに影響を与える障害をどのように検出し、対応しますか?** ソフトウェアまたは操作手順によって SAP ワークロードのヘルスと回復性を確立する方法を設計します。可能な場合は予防を重視して、潜在的な障害と実際の障害を監視します。コンポーネント分散されているか、それとも単一障害点かを考慮して、ワークロードへの影響を最小化する回復性ソリューションを設計します。リスクのプロファイルを理解するための定期的なテストに加えて、オートメーションによって回復性を向上させられるか調べます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-11.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) と [アーキテクチャパターン](https://docs.aws.amazon.com/sap/latest/general/arch-guide-architecture-patterns.html#arch-guide-patterns)
# ベストプラクティス 11.1 – SAP アプリケーション、AWS リソース、および接続性の障害をモニタリングする
SAP アプリケーション、AWS リソース、および接続性の障害のモニタリングは、障害または潜在的な障害に迅速に対応するのに役立ちます。
**提案 11.1.1 – AWS Personal Health Dashboard および通知を使用する**
それらの [AWS Personal Health Dashboard](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/) は、アプリケーションを支援する AWS サービスのステータスをパーソナライズして表示するため、SAP ワークロードに影響する問題をすぐに把握できます。例えば、 [Amazon Elastic Block Store (Amazon EBS)](https://aws.amazon.com/ebs/) ボリュームのうち、 [Amazon EC2](https://aws.amazon.com/ec2/) インスタンスの 1 つに関連するものが失われた場合です。
ダッシュボードは予想通知も提供し、E メールも含む複数のチャネルでアラートをセットアップできるため、計画的変更のプランニングに役立つ関連情報を適時に受け取ることができます。例えば、AWS ハードウェアメンテナンスアクティビティが発生し、 [Amazon EC2](https://aws.amazon.com/ec2/) インスタンスの 1 つに影響がある場合は、今後の変更を計画し、関連する問題に予防的に対処するのに役立つ情報を含んだ通知を受け取ります。
**提案 11.1.2 – AWS サービスを評価して、SAP システムのヘルスを理解する**
AWS が提供する多数の [管理およびガバナンス](https://aws.amazon.com/products/management-and-governance/) サービスを評価する必要があります。EC2 インスタンス障害、高い CPU 使用率、ファイルシステム使用率など、障害または潜在的な障害を示すメトリクスに注目します。
詳細については、「運用上の優秀性の柱」を参照してください。
+ SAP Lens [運用上の優秀性]: [ベストプラクティス 1.1 - SAP on AWS をモニタリングするための前提条件を実装する](best-practice-1-1.md)
+ SAP Lens [運用上の優秀性]: [ベストプラクティス 1.4 – ワークロード設定モニタリングを実装する](best-practice-1-4.md)
**提案 11.1.3 – 障害をモニタリングする SAP ツールの機能を評価する**
Solution Manager や Landscape Manager など、SAP のツールでは、アプリケーションのコンテキストでモニタリングデータを表示できます。SAP には、以下のモニタリングソリューションがあります。これらのツールの評価の一環として、追加のライセンシングコストをレビューしてください。
+ SAP ドキュメント: [SAP Focused run](https://support.sap.com/en/alm/sap-focused-run.html)
+ SAP ドキュメント: [SAP Solution Manager](https://support.sap.com/en/alm/solution-manager.html)
+ SAP ドキュメント: [SAP Landscape Manager (LaMa)](https://help.sap.com/viewer/lama_help)
+ SAP Note: [2574820 - SAP Landscape Management Cloud Manager for Amazon Web Services (AWS) (アマゾン ウェブ サービス (AWS) 向け SAP Landscape Management Cloud Manager)](https://launchpad.support.sap.com/#/notes/2574820) [SAP ポータルへのアクセス権が必要]
**提案 11.1.4 – AWS と SAP のモニタリングのためのサードパーティーツールを評価する**
AWS Marketplace から以下のモニタリングソリューションを入手できます。これらやその他のサードパーティーツールを評価してください。
+ AWS ドキュメント: [Monitoring Solutions in AWS Marketplace (AWS Marketplace のモニタリングソリューション)](https://aws.amazon.com/marketplace/b/2649280011?ref_=mp_nav_category_2649280011)
# ベストプラクティス 11.2 – 可用性を維持するためのアプローチを定義する
単一の技術的要素の障害や AWS サービスの障害に耐えられる回復力のあるアーキテクチャを持つことで、可用性を維持します。メカニズムには、冗長な容量、ロードバランシング、およびソフトウェアクラスターなどが含まれます。
**提案 11.2.1 – リソースの枯渇やサービスの低下による障害を回避する**
リソースのオーバープロビジョニング、増加のプロアクティブなモニタリング、および制限の設定による使用量のスロットリングを調査します。
運用上の優秀性の柱では、SAP アプリケーションの状態を理解し、適切なアクションを取るためのさまざまな方法が説明されています。以下を参照してください。[運用上の優秀性]: [1 - 状態の理解と反応ができるように SAP ワークロードを設計する](design-principle-1.md) .
パフォーマンスの柱は、容量の適切なサイジングとスケーリングに関するガイダンスによって支援します。[パフォーマンス]: [16 – 継続的なパフォーマンスと最適化のオプションを理解する](design-principle-16.md) .
**提案 11.2.2 – 計画保守の戦略を持つ**
ビジネスに保守停止を最小限にする要件がある場合は、すべてのレベル、つまり、SAP アプリケーション、データベース、オペレーティングシステム、および AWS でメンテナンス戦略を開発する必要があります。以下の点を考慮してください。
+ プライマリノードとセカンダリノードを切り替えるためのレプリケーションおよびクラスターソリューションの使用。
+ ローリング停止を容易にするための超過容量と拡張縮小メカニズム。
+ 可能な場合は、オペレーティングシステムのライブパッチ適用アプローチの使用。
+ [SUSE Linux Enterprise Live Patching](https://www.suse.com/products/live-patching/)
+ [Red Hat Reducing downtime for SAP HANA ホワイトペーパー](https://www.redhat.com/cms/managed-files/pa-sap-hana-reducing-downtime-overview-f22788pr-202004-en.pdf)
+ AWS ドキュメント: [AWS Systems Manager Patch Manager パッチグループの使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ SAP Note: [1913302 - HANA: 短時間のメンテナンスタスクのための DB 接続の中断](https://launchpad.support.sap.com/#/notes/1913302) [SAP ポータルへのアクセス権が必要]
+ SAP Note: [2077934 - Rolling kernel switch in HA environments (HA 環境でのローリングカーネルスイッチ)](https://launchpad.support.sap.com/#/notes/2077934) [SAP ポータルへのアクセス権が必要]
+ SAP Note: [953653 - Rolling Kernel Switch (ローリングカーネルスイッチ)](https://launchpad.support.sap.com/#/notes/953653) [SAP ポータルへのアクセス権が必要]
+ SAP Note: [2254173 - Linux: Rolling Kernel Switch in Pacemaker-based NetWeaver HA environments (Linux: ペースメーカーベースの NetWeaver HA 環境でのローリングカーネルスイッチ)](https://launchpad.support.sap.com/#/notes/2254173) [SAP ポータルへのアクセス権が必要]
一時的にパフォーマンスを高めることによって計画保守の全体的ダウンタイムを短縮する AWS サービスのエラスティック機能も評価してください。例えば、データベースを実行している Amazon EC2 インスタンスのサイズを拡張して、アップグレードアクティビティのために CPU とストレージのスループットを高めたり、EBS ボリュームのタイプを gp2 から io2 に切り替えて、データベースの再編成中のストレージスループットを高めたりします。
**提案 11.2.3 – SAP の単一障害点をソフトウェアクラスターまたはその他のメカニズムで保護する**
高可用性 (HA) クラスタリングソリューションを使用して、アベイラビリティーゾーン間の SAP の単一障害点 (SAP セントラルサービスとデータベース) の自律的フェイルオーバーを実現できます。
複数の SAP 認定クラスタリングソリューションがあり、 [SAP ウェブサイトに記載されています](https://wiki.scn.sap.com/wiki/display/SI/Certified+HA-Interface+Partners) .SAP クラスタリングソリューションは、SAP ではなく、クラスターソフトウェアベンダー自身によってサポートされています。SAP はソリューションを認定しているだけです。カスタムビルドのソリューションは認定されず、ソリューションビルダーのサポートが必要です。
単一障害点にクラスタリングソリューションを使用しないことにした場合は、サービスの復元に関連するエラーを最小化するために、スクリプティングまたはランブックを検討してください。
**提案 11.2.4 – サポートするコンポーネントについては、冗長容量またはオートスケーリング**
使用状況に合った静的、動的、またはスケジュールされた容量変更を評価します。最小容量要件と、障害およびメンテナンスによる影響を調べます。適切な場合は、障害から復旧する時間が得られるように、オーバープロビジョニングします。
AZ 障害の発生時に 100% の容量を維持する必要がある場合は、アプリケーション層を 3 つの AZ に、必要な総容量の 50% ずつデプロイすることを検討してください。
SAP アプリケーションサーバーレイヤーを複数の AZ にデプロイすることに加えて、SAP on AWS ブログ投稿で説明されているようなスケーリングソリューションを検討することもできます。 [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling) .
+ 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/)
+ AWS ドキュメント: [SAP 向け Amazon EC2 インスタンスタイプ](https://aws.amazon.com/sap/instance-types/)
+ SAP Note: [1656099 - SAP Applications on AWS: Supported DB/OS and Amazon EC2 products (AWS 上の SAP アプリケーション: サポートされる DB/OS および Amazon EC2 製品)](https://launchpad.support.sap.com/#/notes/1656099) [SAP ポータルへのアクセス権が必要]
**提案 11.2.5 – 特定されたすべての障害シナリオに対応する容量を確保する**
以下は、分析の参考になる障害シナリオの例です。シナリオ、分類、および影響の詳細度や範囲は、要件とアーキテクチャによって異なります。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/best-practice-11-2.html)
キャパシティ予約に関する詳しいガイダンスは、次をよく確認してください。[信頼性]: [提案 10.2.5 - 容量を確保するための戦略を調査する](best-practice-10-2.md) および 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) .
AWS を使用して、アカウント内で利用可能なリザーブドインスタンスを確認できます。 [AWS Cost Explorer RI レポート](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-default-reports.html#ce-ri-reports) .
**提案 11.2.6 – 該当する場合は、固有の可用性を持つ AWS のサービスを使用します**
いくつかの AWS のサービスは、設計の一部として固有の可用性を備えており、高可用性を実現するために複数のアベイラビリティーゾーンで実行されます。SAP のコンテキストで使用される関連サービスには、以下のようなものがあります。
+ AWS サービス: [Amazon EFS](https://docs.aws.amazon.com/efs/latest/ug/how-it-works.html)
+ AWS サービス: [Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html)
+ AWS サービス: [Route 53](https://aws.amazon.com/route53/faqs/)
+ AWS サービス: [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/how-transit-gateways-work.html)
+ AWS サービス: [Amazon S3](https://aws.amazon.com/s3/)
また、踏み台ホストや SAPRouter などのステートレスサービスを使用するコンポーネントは、Auto Scaling グループを使用して高可用性を実現できます。
**提案 11.2.7 – AWS のベストプラクティスに従って、ネットワーク接続を確保する**
使用中の AWS リージョンへのネットワーク接続の回復力を確保するために、以下の AWS ベストプラクティスを 1 つ以上評価すること。
+ AWS ドキュメント: [AWS Direct Connect Resiliency Toolkit](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resilency_toolkit.html)
+ AWS ドキュメント: [AWS VPN CloudHub](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-vpn-cloudhub.html)
クラスターソリューションがオーバーレイ IP に依存している場合、VPC 外からのアクセスを可能にするために以下を検討してください。
+ AWS ドキュメント: [SAP on AWS High Availability with Overlay IP Address Routing (オーバーレイ IP アドレスルーティングによる SAP on AWS の高可用性)](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-ha-overlay-ip.html)
# ベストプラクティス 11.3 – サービスの可用性を復元するためのアプローチを定義する
可用性の復元は、特定の障害シナリオで、サービスの損失が発生することを前提としています。リストアのアプローチでは、サービスの復元に必要な時間、および可用性目標を達成するために必要なアクションを検討する必要があります。
**提案 11.3.1 – EC2 インスタンスのインスタンスの復旧を有効にする**
Amazon EC2 インスタンスをモニタリングし、基盤となるハードウェアの障害が原因でインスタンスに障害が発生した場合に自動的にインスタンスを復旧する Amazon CloudWatch アラームを作成できます。このアクションにより、マニュアルによる介入の必要性を取り除くことができますが、スタートアップ、アプリケーションの再起動、ロード時間を、目標復旧時間 (RTO) の計算に含める必要があります。クラスタリングソリューションを使用してハードウェア障害から保護する場合は、インスタンスリカバリがクラスターソリューションと互換性があるかどうかを評価する必要があります。
+ AWS ドキュメント: [Amazon EC2 インスタンスの復旧](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
**提案 11.3.2 – AMI と Infrastructure as Code を使用して EC2 インスタンスを再構築する戦略を立てる**
Infrastructure as Code (IaC) の利点は、プログラムで環境全体を構築および破棄できることです。回復力を考慮した設計であれば、 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) のテンプレートや [AWS Systems Manager のオートメーションにより、数分で環境を実装することができます。](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) .オートメーションは、高可用性と迅速な復旧を維持するために不可欠です。
戦略の一環として、次の AWS のサービスを評価する必要があります。
+ AWS サービス: [EC2 Image Builder](https://aws.amazon.com/image-builder/)
+ AWS サービス: [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-sap.html)
+ AWS サービス: [AWS Cloud Development Kit](https://aws.amazon.com/cdk/)
+ SAP on AWS ブログ: [DevOps for SAP (SAP 向け DevOps)](https://aws.amazon.com/blogs/awsforsap/category/devops/)
**提案 11.3.3 – Amazon EBS の障害を理解する**
1 つまたは複数の EBS ボリュームに障害が発生した場合、SAP ワークロードの可用性と耐久性に影響を与える可能性があります。そのため、Amazon EBS の障害発生率、通知メカニズム、復旧オプションについて理解しておく必要があります。
+ AWS ドキュメント: [Amazon EBS の耐久性](https://aws.amazon.com/ebs/features/#Amazon_EBS_availability_and_durability)
+ AWS ドキュメント: [ボリュームのステータスのモニタリング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-volume-status.html)
+ AWS サービス: [AWS Personal Health Dashboard](https://aws.amazon.com/premiumsupport/technology/personal-health-dashboard/)
+ AWS ドキュメント: [Amazon EBS スナップショットを使用したボリュームリカバリ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
**提案 11.3.4 – AWS Personal Health Dashboard の通知に対応するための戦略を立てる**
AWS Personal Health Dashboard からの通知を受け取り、対処するための戦略を立てる必要があります。これには、CloudWatch を使用して Amazon SNS を開始したり、 [AWS Health API を介して ITSM ツールと統合したりすることが含まれます](https://docs.aws.amazon.com/health/latest/ug/health-api.html) 。
**提案 11.3.5 – 可用性に影響を与える偶発的または悪意のあるイベントから保護されていることを確認する**
SAP ワークロードの可用性に影響を与える可能性のある偶発的または悪意のあるイベントから確実に保護するために、次のアプローチを検討する必要があります。
+ 最小特権の原則を [実装し、](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) AWS Identity and Access Management 内で職務の分離を実施します。
+ AWS ナレッジセンターの記事のガイダンスに従ってください。 [EC2 インスタンスの偶発的な終了からデータを保護するにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/accidental-termination/)
+ Amazon EC2 の [ベストプラクティスに従ってください。](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html)
+ [セキュリティ] のセキュリティガイダンスにも従う必要があります。 [ベストプラクティス 8.3 - データ復旧メカニズムを確保して、脅威から保護する。](best-practice-8-3.md)
**提案 11.3.6 – AWS の SAP ワークロード以外の依存関係を特定します。**
共有サービスやサポートコンポーネントまたはシステムなど、SAP ビジネスプロセスの基本的な依存関係を理解します。例えば、アクティブディレクトリ、DNS、ID プロバイダー、SaaS サービス、オンプレミスシステムなどです。障害発生時の影響と必要な緩和策を評価します。
# ベストプラクティス 11.4 – 定期的な回復力テストの実施
ソフトウェアと手順が予測可能な結果をもたらすことを証明するために、重要な障害シナリオに対する回復性を定期的にテストします。アーキテクチャ、ソフトウェア、サポート担当者の変更について評価し、追加テストが必要かどうかを判断します。
**提案 11.4.1 – ビジネス要件に基づき、対象範囲内の重要な障害シナリオを定義します。**
ビジネス要件に合わせて、テストできる重大な障害シナリオを定義する必要があります。以下は、分析の指針として使用できる障害シナリオの例です。シナリオ、分類、および影響の詳細度や範囲は、要件とアーキテクチャによって異なります。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/best-practice-11-4.html)
**提案 11.4.2 – 重大な障害をシミュレートするためのテストケースを定義する。**
SAP のワークロードに影響を与える重要な障害シナリオをシミュレートするために、完全なテストセットを定義しておく必要があります。
障害のシナリオによっては、シミュレーションが実際に発生する障害を完全に表現できない場合があることを認識しておく必要があります。例えば、ハードウェアの問題をシミュレートするために、EC2 インスタンスの障害を引き起こすことはできませんが、Nitro ベースのインスタンスでは、インスタンスを再起動させるためにカーネルパニックを発生させることができます。
加えて、 [AWS Fault Injection Simulation は、](https://aws.amazon.com/fis/) お客様の AWS リソース内の障害をシミュレートするのに役立つように設計されています。
+ AWS ドキュメント: [SAP on HANA の高可用性設定ガイド](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-hana-on-aws-ha-configuration.html)
+ AWS ドキュメント: [診断割り込みの送信](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/diagnostic-interrupt.html#diagnostic-interrupt-prereqs)
**提案 11.4.3 – 各テストケースに期待される動作を定義する**
テストのベースラインを作成するには、期待される結果のセットを文書化する必要があります。
**提案 11.4.4 – 変更の影響を評価するためのアプローチと、その後に必要なテストを定義する**
変更が環境に与える影響を評価するためのアプローチと、その変更の一部として必要なテストを定義して、可用性と信頼性に対するアプローチを無効にしないように支援する必要があります。例えば、ソフトウェアのアップグレード、パッチ、パラメータの変更などです。
**提案 11.4.5 – テストスケジュールを定義する**
初期実装、変更点のテスト、環境の定期的な検証をカバーするテストスケジュールを確実に立ててください。
**提案 11.4.6 – テスト結果を確認する**
テスト結果に基づいて、テストケース、設定、またはアーキテクチャの改善点を特定します。
**提案 11.4.7 – テスト前の状態に戻すために必要なアクティビティを定義する**
各テストの一環として、テスト前の状態に戻すために必要なアクティビティを定義する必要があります。これは、各テストケースを他のテストから分離し、テストが本番稼働システムの可用性と信頼性に影響を与えないようにするためです。
# ベストプラクティス 11.5 – 障害時の対応を自動化する
障害時の対応を自動化することで、サービスへの影響を最小限に抑えることができます。障害、容量の低下、接続性の喪失に対応するオートメーションを設計します。誤検出を回避するために、明確な調停基準が定義されていることを確認してください。
**提案 11.5.1 – 破損のリスクについてオートメーションを評価する**
データの破損がリスクとなるコンポーネントの場合、高可用性 (HA) ソリューションで、データレプリケーションの方法、スプリットブレインの回避、接続の安定性、およびアプリケーションの認識が考慮されていることを確認してください。
**提案 11.5.2 – オートメーションを開始するヘルスチェックメカニズムを評価する**
ヘルスチェックは、誤検出の結果としてオートメーションが開始されないようにするためのコントロール機能を使用して設計する必要があります。