# 運用上の優秀性
運用上の優秀性の柱では、ワークロードを効率的に開発して実行し、オペレーションに関するインサイトを得て、ビジネス価値をもたらすためのサポートプロセスを継続的に改善する能力に重点を置きます。
このセクションには、一連の設計原則と SAP ワークロードのガイダンスを提供するために具体的にカスタマイズされたレコメンデーションが記載されています。それらの [運用上の優秀性の柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html) には、幅広い設計原則とレコメンデーションが含まれます。この後の SAP ガイダンスと併せて読むことを強く推奨します。
# 1 - 状態の理解と反応ができるように SAP ワークロードを設計する
**SAP ワークロードの状態を理解できるようにするには、ワークロードをどう設計すればよいでしょうか?** SAP ワークロードを設計する際には、すべてのコンポーネントにわたって内部および外部状態を理解するために必要な情報を提供するようにします。インフラストラクチャ、SAP テクノロジー/ベース、フロントエンド、ネットワークコンポーネントを検討します。リアルタイムのモニタリングができるメトリクスをキャプチャする、モニタリングとログ記録のアプローチ、および修復とイベント後の分析ができる履歴ログ記録を設計します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-1.html)
詳細については、以下のリンクと情報を参照してください。
+ AWS ドキュメント: [AWS Data Provider for SAP (SAP 向け AWS データプロバイダー)](https://docs.aws.amazon.com/sap/latest/general/aws-data-provider.html)
+ AWS サービス: [Amazon CloudWatch](https://docs.aws.amazon.com/cloudwatch/index.html)
+ SAP on AWS ブログ: [Serverless Monitoring for SAP (SAP 向けサーバーレスモニタリング)](https://aws.amazon.com/blogs/awsforsap/sap-monitoring-a-serverless-approach-using-amazon-cloudwatch/)
+ SAP on AWS ブログ: [AWS DevOps for SAP - driving innovation and lowering costs (SAP 向け AWS DevOps – イノベーションの促進とコストの削減)](https://aws.amazon.com/blogs/awsforsap/devops-for-sap-driving-innovation-and-lowering-costs/)
+ AWS Marketplace: [SAP モニタリング向け製品とツール](https://aws.amazon.com/marketplace/search/results?page=1&searchTerms=SAP&category=45c68cc2-ccd6-426b-94bd-92a791004dc2)
+ SAP Note: [1656250 - SAP on AWS: Support Prerequisites (サポートの前提条件)](https://launchpad.support.sap.com/#/notes/1656250) [SAP ポータルへのアクセス権が必要]
+ SAP ドキュメント: [SAP Solution Manager 7.2 - Application Operations](http://help.sap.com/viewer/c3c5ec585ee248228ddb6c3f08073ea9/LATEST/en-US/456408e2a51b476c960fda046c96cb76.html)
# ベストプラクティス 1.1 - SAP on AWS をモニタリングするための前提条件を実装する
SAP on AWS の SAP 認定要件は、SAP Note 1656250 に記載されています。この Note には、SAP 向け AWS データプロバイダーの設定、Amazon CloudWatch 詳細モニタリングの有効化、SAP NetWeaver ソリューションでの SAP 拡張モニタリングの使用の手順が含まれています。これらの前提条件を有効にすると、AWS と SAP により SAP ワークロードの状態が完全に理解および調査されるようにできます。これらの前提条件は、全体的な SAP モニタリング戦略に入れる必要があります。
**提案 1.1.1 - SAP サポート前提条件をチェックする**
SAP サポートポータルで SAP on AWS ワークロードの最新のサポート前提条件について SAP Note 1656250 をチェックします。この Note の詳細な手順に従ってください。
+ SAP Note: [ 1656250 - SAP on AWS: Support Prerequisites (サポートの前提条件)](https://launchpad.support.sap.com/#/notes/1656250) [SAP ポータルへのアクセス権が必要]
**提案 1.1.2 - SAP NetWeaver ワークロード向け AWS データプロバイダーをインストールする**
SAP 向け AWS データプロバイダーは、SAP NetWeaver ワークロードをサポートする EC2 インスタンスそれぞれでインストールする必要があります。SAP 向け AWS データプロバイダーは、AWS サービスからパフォーマンス関連のメトリクスを収集し、SAP 内部アプリケーションモニタリングシステムに提供します。トランザクションコード ST06n や通常、SAPOSCOL サービスから収集される外部メトリクスを使用する Systems Manager のモニタリングなどの SAP ツールは、AWS メトリクスにアクセスするために SAP 向け AWS データプロバイダーが必要です。
詳細なモニタリングと、特定の間隔で SAP がモニタリングデータを受信するために必要な API コールの増加のため、SAP 向け AWS データプロバイダーの実行に関連して間接的なコストが発生します。参照先 [SAP 向け AWS データプロバイダーのインストール](https://docs.aws.amazon.com/sap/latest/general/data-provider-install.html) で詳細を確認してください。この理由で、SAP サポートと分析が必要な場合、非本番稼働環境では、SAP 向け AWS データプロバイダーのみを有効にすることを検討した方がよいかもしれません。
+ AWS ドキュメント: [AWS Data Provider for SAP (SAP 向け AWS データプロバイダー)](https://docs.aws.amazon.com/sap/latest/general/aws-data-provider.html)
**提案 1.1.3 - SAP ワークロードのモニタリング戦略を作成する**
SAP アプリケーションの現在のヘルスと履歴のヘルスを内側から外側と外側から内側の両方の視点で観察する方法を決定します。連携してエンドユーザーエクスペリエンスを提供するすべてのコンポーネントを検討します。内部 SAP アプリケーションメトリクスと外部ユーザーパフォーマンスおよび信頼性モニタリングに加えて、基盤となる AWS コンピューティング、ストレージ、ネットワークサービスからメトリクスをキャプチャするかを検討します。各コンポーネントの異なるツールを評価し、必要なときに根本原因分析を実行するための 1 つの場所 (例えば、ログの集約) でこれらをまとめる方法を決定します。この情報を使用してアラートしきい値を設計する方法としきい値に達したときに実行する修復アクションを決定します。
SAP Solution Manager のモニタリング、サードパーティーのモニタリングツール、カスタム SAP モニタリングメトリクスを設計の開始ポイントとして取り込める CloudWatch ダッシュボードの機能を理解します。
+ AWS ドキュメント: [SAP NetWeaver on AWS: Monitoring Guide (SAP NetWeaver on AWS: モニタリングガイド)](https://docs.aws.amazon.com/sap/latest/sap-netweaver/monitoring.html)
+ SAP on AWS ブログ: [Serverless Monitoring for SAP NetWeaver (SAP NetWeaver 向けサーバーレスモニタリング)](https://aws.amazon.com/blogs/awsforsap/sap-monitoring-a-serverless-approach-using-amazon-cloudwatch/)
+ SAP on AWS ブログ: [Serverless Monitoring for SAP HANA (SAP HANA 向けサーバーレスモニタリング)](https://aws.amazon.com/blogs/awsforsap/sap-hana-monitoring-a-serverless-approach-using-amazon-cloudwatch/)
+ AWS サービス動画: [Gaining Better Observability of Your VMs with Amazon CloudWatch (Amazon CloudWatch で VM の可観測性を改善する)](https://youtu.be/1Ck_me4azMw?ref=wellarchitected)
+ AWS Marketplace: [SAP モニタリング向け製品とツール](https://aws.amazon.com/marketplace/search/results?page=1&searchTerms=SAP&category=45c68cc2-ccd6-426b-94bd-92a791004dc2)
+ SAP ドキュメント: [SAP Solution Manager 7.2 - Application Operations](http://help.sap.com/viewer/c3c5ec585ee248228ddb6c3f08073ea9/LATEST/en-US/456408e2a51b476c960fda046c96cb76.html)
+ SAP ドキュメント: [SAP NetWeaver Alert Monitor](https://help.sap.com/doc/7a827019728810148a4b1a83b0e91070/1610 001/en-US/frameset.htm?frameset.htm)
# ベストプラクティス 1.2 – SAP のインフラストラクチャモニタリングを実施する
SAP アプリケーションの動作を維持し、ユーザーをサポートするため使用されるサポートサービスについても情報を提供する、インフラストラクチャモニタリングを設定します。例としては、CPU とメモリ使用率、ストレージとファイルシステム使用率、パフォーマンス (IOPS およびスループット)、ネットワークのスループットがあります。SAP が使用するあらゆる依存基礎サービスが含まれます。これにはオンプレミスアクティブディレクトリサービス、DNS、高可用性 (HA) やバックアップソフトウェアのようなサードパーティーツールなどがあります。DataDog、Splunk、DynaTrace、Avantra など、この情報を相互に関連付け可視化するのに役立つ AWS Marketplace の AWS ツールと SAP 固有のツールを評価します。この情報を使用して、傾向を識別し、是正措置が必要とされるタイミングを特定します。
**提案 1.2.1 - SAP をサポートするサービスに CloudWatch メトリクスとアラームを実装する**
Amazon CloudWatch の詳細なモニタリングメトリクスとすべての SAP システムに対するアラームのしきい値を実装します。これらのメトリクスとアラームには、SAP システムの可用性とパフォーマンスに影響する可能性がある一般的な問題のモニタリングを含める必要があります。一般的なインフラストラクチャモニタリング領域は、Amazon Elastic Compute Cloud (EC2) インスタンス、Amazon Elastic Block Storage (Amazon EBS) ボリューム、Elastic Load Balancing (ELB) に重点を置きます。
共通のモニタリング項目には以下が含まれます。
+ Amazon EC2 の高い CPU 使用率
+ Amazon EC2 の高いメモリ使用率
+ Amazon EBS ストレージページング
+ Amazon EBS ストレージのスループット
+ Amazon EBS ストレージ IOPS
+ Amazon EBS ストレージの空き容量といっぱいになっているボリュームの割合
+ Amazon EC2 ネットワークの飽和
+ ELB/ALB のヘルスとターゲットグループのヘルス
しきい値はシステムの履歴本番稼働使用状況の正常なパターンを基にします。問題を避けるためにアラームのしきい値を継続的に確認し、調整します。
使用を開始するには、以下のリソースを確認します。
+ SAP on AWS ブログ: [Serverless Monitoring for SAP NetWeaver (SAP NetWeaver 向けサーバーレスモニタリング)](https://aws.amazon.com/blogs/awsforsap/sap-monitoring-a-serverless-approach-using-amazon-cloudwatch/)
+ SAP on AWS ブログ: [Serverless Monitoring for SAP HANA (SAP HANA 向けサーバーレスモニタリング)](https://aws.amazon.com/blogs/awsforsap/sap-hana-monitoring-a-serverless-approach-using-amazon-cloudwatch/)
+ AWS ドキュメント: [Create a CloudWatch Custom Metric (CloudWatch カスタムメトリクスを作成する)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ AWS ドキュメント: [CloudWatch ダッシュボードの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html)
+ AWS ドキュメント: [Amazon CloudWatch でのアラームの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
**提案 1.2.2 - SAP サービスに AWS のサービスクォータモニタリングを実装する**
モニタリングツールまたはプロセスを実装して、 [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) を環境内で必要な SAP リソースについて追跡します。SAP 環境では、複数の Amazon EC2 インスタンスタイプを組み合わせて使用することも多く、一部のタイプでは異なる [オンデマンドサービスクォータを使用することがあることも考慮してください](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-on-demand-instances.html#ec2-on-demand-instances-limits) .例えば、 `x1*` と `u*` EC2 インスタンスタイプには異なるサービスクォータがあり、以下の組み合わせたクォータとは別個です。 `c5` 、 `m5` 、および `r5` インスタンスタイプ新しいワークロードを計画している場合、または既存のワークロードをスケーリングする場合は、Service Quotas にサポートされることを確認し、クォータライセンスが必要な場合は、AWS Support に依頼します。
+ AWS ドキュメント: [Service Quotas - AWS 全般のリファレンス](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ AWS ドキュメント: [オンデマンドインスタンス - Amazon Elastic Compute Cloud Service Quotas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-on-demand-instances.html#ec2-on-demand-instances-limits)
+ AWS ドキュメント: [Requesting a quota increase - Service Quotas (クォータの引き上げをリクエストする - Service Quotas)](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)
# ベストプラクティス 1.3 - SAP の個別アプリケーションモニタリングの実装
内部状態、ステータス、ビジネス成果の達成に関する情報が得られるように、アプリケーションとデータベースのモニタリングを設定します。例としては、取引の応答時間、利用できる作業プロセス、キューの深度、エラーとダンプメッセージ、停止したバッチジョブ、取引のスループットがあります。この情報を使用して、是正措置が必要とされるタイミングを特定します。
**提案 1.3.1 - SAP アプリケーションをサポートするデータベースのモニタリングを実装する**
SAP データベースを継続的にモニタリングして、SAP システムの可用性とパフォーマンスに影響する可能性がある一般的な問題に対するアラートを確立します。共通のモニタリング項目には以下が含まれます。
+ データエリアの空き容量
+ ロギングエリアの空き容量
+ 過剰なロックアクティビティ
+ キャッシュ利用率
+ 平均クエリ応答時間
+ 必要なセキュリティパッチとホットフィックス
+ 上部テーブルのサイズと拡大
アラートのしきい値はシステムの履歴生産使用状況の正常なパターンを基にします。アラームしきい値を継続的に確認して調整し、問題を回避してワークロードの変化や成長に対応します。
特定のデータベースのモニタリングを有効にする方法の詳細については、データベースソフトウェアプロバイダーのインストールおよび運用ガイドを参照してください。
**提案 1.3.2 - SAP トランザクションとツールを使用して SAP アプリケーションを理解する**
内部状態、ステータス、およびビジネス成果の達成に関する情報を提供するために SAP アプリケーションコードを設定します。この情報を使用して、応答が必要とされるタイミングを特定します。共通のモニタリング項目には以下が含まれます。
+ アプリケーション (ASCS、PAS、AAS) とデータベースサービスの可用性
+ アクティブな同時利用ユーザーの数
+ ユーザーのための作業プロセスの可用性
+ ユーザートランザクションの応答時間
+ バッチおよび非インタラクティブトランザクションの応答時間
+ エラーメッセージとダンプ
+ 失敗したジョブ
+ フルキューとスローキュー
SAP Solution Manager に [SAP EarlyWatch Alert レポートシステム](https://launchpad.support.sap.com/#/notes/2729186) を設定し、SAP システムのステータスに関する定期的なレポートを作成します。これらのレポートに記載されている問題を定期的に確認し、修復して問題を回避し、ワークロードサービスの中断を避けます。
+ SAP Note: [2729186 - General Process of EWA Generation (EWA 生成の一般的なプロセス)](https://launchpad.support.sap.com/#/notes/2729186) [SAP ポータルへのアクセス権が必要]
+ SAP ドキュメント: [SAP Solution Manager 7.2 - Application Operations](http://help.sap.com/viewer/c3c5ec585ee248228ddb6c3f08073ea9/LATEST/en-US/456408e2a51b476c960fda046c96cb76.html)
+ SAP Lens [パフォーマンス効率]: [ベストプラクティス 16.1 – パフォーマンスを評価するデータを持つ](best-practice-16-1.md)
**提案 1.3.3 - データ回復と保護メカニズムのモニタリングを実装する**
障害や災害の場合に SAP データを保護するメカニズムのモニタリングを実装します。共通のモニタリング項目には以下が含まれます。
+ 例えば、Amazon S3 に AWS Backint Agent で実行するような通常のデータベースバックアップのアラート
+ データベースレプリケーションのアラート、例えば、アベイラビリティーゾーンでの HANA システムレプリケーションの障害または遅延
+ ファイルストレージバックアップのアラート、例えば、EBS スナップショット、Amazon EFS バックアップ、または Amazon FSx バックアップ
+ リージョンにまたがるデータの回復性を提供する回復メカニズム (例えば、クロスリージョンレプリケーションのある Amazon S3 バケット、Amazon S3 同期または CloudEndure Disaster Recovery) のアラート
+ アカウントにまたがるデータの回復性を提供するメカニズム (例えば、WORM S3 バケットまたはロギングアカウントへの同じリージョンレプリケーションがある Amazon S3 バケット) のアラート
詳細については、以下のリンクを参照してください。
+ AWS ブログ: [AWS Backup Audit Manager を使用したバックアップコンプライアンスのモニタリング、評価、デモンストレーション](https://aws.amazon.com/blogs/aws/monitor-evaluate-and-demonstrate-backup-compliance-with-aws-backup-audit-manager/)
+ SAP ドキュメント: [SAP HANA System Replication Verification and Monitoring (SAP HANA システムレプリケーションの検証とモニタリング)](https://www.sap.com/documents/2017/07/606a676e-c97c-0010-82c7-eda71af511fa.html#page=68&zoom=auto,-69,384)
**提案 1.3.4 - 独立した可観測性が得られるように SAP ツール外の SAP モニタリングデータを公開する**
SAP モニタリングツールは、アプリケーションとオペレーティングシステムレベルのモニタリングに限定され、SAP サービスの可用性とヘルスのエンドツーエンドビューが得られる幅広いサポートサービスをカバーしません。SAP アプリケーションを設定して、選択した包括的な、外部モニタリングと可視性ツールにメトリクスを提供します。
以前のベストプラクティスで収集したメトリクスを使用し、これらの結果を外部化して、トレンドをモニタリング、アラート、レポートできる独立したツールを持てるようにします。独立したツールでは、SAP システムの可用性とリンクすることなく (SAP が災害または障害モードの場合)、可観測性、根本原因分析、履歴およびトレンドレポート作成が可能です。
+ SAP on AWS ブログ: [Serverless Monitoring for SAP NetWeaver (SAP NetWeaver 向けサーバーレスモニタリング)](https://aws.amazon.com/blogs/awsforsap/sap-monitoring-a-serverless-approach-using-amazon-cloudwatch/)
+ SAP on AWS ブログ: [Serverless Monitoring for SAP HANA (SAP HANA 向けサーバーレスモニタリング)](https://aws.amazon.com/blogs/awsforsap/sap-hana-monitoring-a-serverless-approach-using-amazon-cloudwatch/)
+ AWS ドキュメント: [Create a CloudWatch Custom Metric (CloudWatch カスタムメトリクスを作成する)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ AWS Marketplace: [SAP モニタリング向け製品とツール](https://aws.amazon.com/marketplace/search/results?page=1&searchTerms=SAP&category=45c68cc2-ccd6-426b-94bd-92a791004dc2)
# ベストプラクティス 1.4 – ワークロード設定モニタリングを実装する
現在の設定とこの設定に対する変更に関する情報が得られるようにワークロードを設計および設定します。例としては、新しいまたは削除された EC2 インスタンス、スケーリングイベント、コード変更、パッチレベル、セキュリティグループ設定、リソース削除があります。この情報を使用して、いつ対応が必要かを決め、変更が予想されていたか、許可されているかを判断します。設定変更のコストへの影響をモニタリングし、必要な場合は、予算を調整または分析します。
**提案 1.4.1 - ワークロード設定モニタリングを実装する**
AWS CloudTrail をセットアップして設定し、特に SAP 本番稼働用アカウントで、高優先度で重要なイベントをモニタリングします。イベントの例としては、新しい Amazon EC2 インスタンス、Amazon EC2 の廃止または変更、セキュリティグループの変更、AWS KMS および IAM セキュリティ変更イベントがあります。これらのイベントを使用して、CloudWatch ログアラーム (必要な場合) を設定し、予期しない変更の場合は対処します。
+ AWS ドキュメント: [AWS CloudTrail とは](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html?ref=wellarchitected)
+ AWS サービス: [AWS CloudTrail](https://aws.amazon.com/cloudtrail/?ref=wellarchitected)
+ AWS ドキュメント: [Amazon CloudWatch Logs による CloudTrail ログファイルをモニタリングする](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html)
+ AWS ドキュメント: [AWS CloudTrail セキュリティのベストプラクティス](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/best-practices-security.html)
**提案 1.4.2 - ワークロード設定の実施と修復を実装する**
AWS Config をセットアップして設定し、SAP 本番稼働アプリケーションをサポートする AWS リソースの設定ポリシーを追跡、評価、適用します。一般的な例としては、SAP バックアップを含む S3 バケット読み取り専用保護の適用、必須の Amazon EC2 EBS 暗号化、一般的なネットワークポートのブロック、すべてのリソースに必要なタグがあることの確認があります。AWS Config [マネージドルール](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html) を使用して、セキュリティを向上させ、SAP をサポートする AWS 環境のコントロール体制を変更します。AWS タグを使用して、設定ルールを適用し、可能なところでは自動化された修復を適用します。
+ AWS サービス: [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ AWS ドキュメント: [AWS Config の開始方法](https://docs.aws.amazon.com/config/latest/developerguide/getting-started.html)
+ AWS ドキュメント: [AWS Config ルールの設定](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)
+ SAP on AWS ブログ: [Audit your SAP systems with AWS Config – Part I (AWS Config で SAP システムを監査する – パート I)](https://aws.amazon.com/blogs/awsforsap/audit-your-sap-systems-with-aws-config-part-i/)
+ SAP on AWS ブログ: [Audit your SAP systems with AWS Config – Part II (AWS Config で SAP システムを監査する – パート II)](https://aws.amazon.com/blogs/awsforsap/audit-your-sap-systems-with-aws-config-part-ii/)
+ SAP on AWS ブログ: [Tagging Recommendations for SAP on AWS (SAP on AWS のタグ付けレコメンデーション)](https://aws.amazon.com/blogs/awsforsap/tagging-recommendations-for-sap-on-aws/)
**提案 1.4.3 - ワークロードコストモニタリングを実装する**
カスタム予算で [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) をセットアップして設定します。カスタム予算は、請求しきい値を超える (または超えると予測される) ときにアラートを発します。予算を予想される SAP 環境の支出に合わせ、異常をモニタリングしてコスト超過を回避します。予算レポートを使用して、リザーブドインスタンスと Savings Plans の使用と範囲をモニタリングします。AWS タグを使用して、SAP ワークロードでのコスト割り当てと使用量の理解を支援します。
+ AWS ブログ: [Getting Started with AWS Budgets (AWS Budgets の開始方法)](https://aws.amazon.com/blogs/aws-cost-management/getting-started-with-aws-budgets/)
+ AWS ブログ: [AWS Budgets Reports](https://aws.amazon.com/blogs/aws-cost-management/launch-aws-budgets-reports/)
+ AWS ドキュメント: [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/?track=costop_bottom)
+ AWS ドキュメント: [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)
+ SAP on AWS ブログ: [Tagging Recommendations for SAP on AWS (SAP on AWS のタグ付けレコメンデーション)](https://aws.amazon.com/blogs/awsforsap/tagging-recommendations-for-sap-on-aws/)
# ベストプラクティス 1.5 – ユーザーアクティビティモニタリングを実装する
SAP アプリケーションを設定して、例えば、応答時間、アクティブユーザーの数、トランザクション放棄率、注文処理時間などのユーザーアクティビティに関する情報を提供します。内側から外側へのアプローチ (SAP 内部ダイアログ応答時間のモニタリング) と外側から内側へのアプローチ (エージェントまたはロボットをエンドユーザーの場所に地理的にデプロイ) の両方を検討して、エクスペリエンスで接続性がどのようなロールを果たすか理解します。この情報を使用して、アプリケーションの使用方法や使用パターンを理解したり、パフォーマンスが低いために対応が必要とされるタイミングを特定したりできます。
**提案 1.5.1 - エンドユーザーの場所からユーザーエクスペリエンスモニタリングを実装する**
エンドユーザーの場所にユーザーエージェントまたはロボットをデプロイして、外側から内側へのモニタリングアプローチにより、SAP ユーザーエクスペリエンスでネットワークと接続性がどのようなロールを果たすかを理解することを検討します。このタイプのエンドユーザーの場所ベースのモニタリングでは、中心的なインフラストラクチャやアプリケーションでは検出できない問題のインサイトや早期の警告が得られる場合があります。
エンドユーザーの場所からの SAP アプリケーションの応答性を測定するためのエンドユーザーエクスペリエンスを提供する、SAP またはサードパーティーツールを実装します。例えば、SAP は、Solution Manager でエンドユーザーエクスペリエンスモニタリングを提供し、複数のサードパーティー製品はリモートの場所にロボット (またはモニタリングスクリプト) をデプロイしてユーザーエクスペリエンスを測定できます。
+ SAP ドキュメント: [SAP User Experience Monitoring (SAP ユーザーエクスペリエンスモニタリング)](https://help.sap.com/viewer/82f6dd44db4e4518aad4dfce00116fcf/LATEST/en-US/1083786db5f1461c8cff8fbcc1666a4d.html)
+ AWS Marketplace: [SAP モニタリング向け製品とツール](https://aws.amazon.com/marketplace/search/results?page=1&searchTerms=SAP&category=45c68cc2-ccd6-426b-94bd-92a791004dc2)
# ベストプラクティス 1.6 – 依存関係のモニタリングを実装する
依存するリソースの状態 (到達可能性や応答時間など) に関する情報が得られるように、ワークロードを設定します。外部依存関係の例としては、インターフェイス (例えば、SAP PI/PO 経由)、外部データストア、DNS、オンプレミスコンポーネント、アクティブディレクトリコントローラーとネットワークデバイスなどがあります。この情報を使用して、応答が必要とされるタイミングを特定します。エンドツーエンドの依存関係のヘルスをモニタリングするためのクロステクノロジーメトリクスを提供できるサードパーティーモニタリングツールを検討してください。
**提案 1.6.1 - 主要な SAP インターフェイスとクロスシステムビジネスプロセスの正常性追跡を実装する**
SAP ワークロードが依存するキーインターフェイスを特定しモニタリングします。これらのインターフェイスエンドポイントのヘルス、エラー、キューの長さと成功率をモニタリングします。SAP の組み込みメカニズムまたはサードパーティー統合ツールを使用してインターフェイス障害または遅延にアラートを設定し、モニタリングツールにフィードします。すべてのインターフェイスパスウェイ:
+ 異なる AWS ホスト SAP システム間 (RFC またはウェブサービス/HTTPS 経由で直接)
+ AWS ホスト SAP システムとオンプレミスシステムの間 (HTTPS/SFTP - SAP PI またはサードパーティー統合プラットフォーム経由)
+ AWS ホスト SAP システムと SAP Business Technology Platform (SAP Cloud Connector 経由) の間
+ AWS ホスト SAP システムと外部パーティーシステムの間 (通常、インターネット/VPN 経由の HTTPS)
SAP と SAP 以外の環境でのシステム間依存関係モニタリングに Solution Manager ビジネスプロセスモニタリングを使用することを検討します。
+ SAP ドキュメント: [SAP Business Process and Interface Monitoring (SAP Business プロセスとインターフェイスのモニタリング)](https://help.sap.com/viewer/c458e6a97c6746f2afb2a3d1bf0a630b/LATEST/en-US/2ffcb651ade3147fe10000000a44176d.html)
+ AWS Marketplace: [SAP モニタリング向け製品とツール](https://aws.amazon.com/marketplace/search/results?page=1&searchTerms=SAP&category=45c68cc2-ccd6-426b-94bd-92a791004dc2)
**提案 1.6.2 - SAP が依存するエンタープライズサービスの正常性追跡を実装する**
SAP ワークロードが、ビジネスユーザーにとって正常な状態であるためには、通常、複数の基本的なエンタープライズサービスに依存します。モニタリングアプローチとツールでこれらの基盤サービスを検討します。基本的なサービスの例としては、オンプレミスシステム接続性のための Direct Connect、認証/SSO のためのアクティブディレクトリ、時間の同期のためのネットワークタイムプロトコル (NTP)、アンチウイルスサービス、オペレーティングシステムのパッチリポジトリ (例えば、Microsoft Windows Update または SUSE パッチ適用) への接続性が含まれます。
+ AWS ブログ: [Amazon CloudWatch Agent with AWS Systems Manager integration - unified metrics and log collection for Linux and Windows (AWS Systems Manager 統合を備えた Amazon CloudWatch エージェント - Linux と Windows 用の統合されたメトリクスとロゴ収集)](https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-agent-with-aws-systems-manager-integration-unified-metrics-log-collection-for-linux-windows/?ref=wellarchitected)
+ AWS ドキュメント: [CloudWatch エージェントを使用した Amazon EC2 Instances インスタンスとオンプレミスサーバーからのメトリクスとログの収集](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html?ref=wellarchitected)
+ AWS ドキュメント: [AWS Direct Connect の強化されたモニタリング機能](https://docs.aws.amazon.com/directconnect/latest/UserGuide/monitoring-cloudwatch.html)
# ベストプラクティス 1.7 – SAP ワークロード全体でヘルスモニタリングの一括管理を実装する
ワークロード全体のトランザクションフローに関する情報が得られるように、SAP アプリケーション、AWS のサービス、依存するコンポーネントを設定します。複数のソースからのメトリクスを組み合わせて、SAP ワークロードのヘルスの一括管理する可視性を作成し、このダッシュボードに主要なユーザーがアクセスできるようにします。この情報を使用して、応答が必要とされるタイミングをすばやく特定し、ビジネスに影響する問題につながる要素の特定に役立てます。
**提案 1.7.1 - アプリケーションメトリクス、ワークロード設定、ユーザーメトリクス、依存関係ヘルスを 1 つの場所で結合する**
アプリケーションモニタリングメトリクス、ワークロード設定データ、ユーザーメトリクスと依存関係のヘルスを 1 つの場所またはツールに組み合わせ、SAP ワークロードとそのヘルスをエンドユーザービジネスプロセスがエンドツーエンドでモニタリングできるようにします。これは、SAP Solution Manager、カスタム CloudWatch ダッシュボードとメトリクス、またはサードパーティーのモニタリングツールの使用により実現できます。
ベストプラクティスは、ワークロードの可用性のドリルダウンビューが可能な、ヘルスとトレンドの交通信号を備えたビジネス向けヘルスダッシュボードを作成することです。ドリルダウン機能により、ユーザーとオペレーターは、問題の原因になっている、またはパフォーマンスが低い可能性がある、テクノロジースタックの特定のコンポーネントを評価できます。
+ AWS ドキュメント: [CloudWatch ダッシュボードの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html)
+ SAP on AWS ブログ: [Serverless Monitoring for SAP NetWeaver (SAP NetWeaver 向けサーバーレスモニタリング)](https://aws.amazon.com/blogs/awsforsap/sap-monitoring-a-serverless-approach-using-amazon-cloudwatch/)
+ SAP on AWS ブログ: [Serverless Monitoring for SAP HANA (SAP HANA 向けサーバーレスモニタリング)](https://aws.amazon.com/blogs/awsforsap/sap-hana-monitoring-a-serverless-approach-using-amazon-cloudwatch/)
+ AWS Marketplace: [SAP モニタリング向け製品とツール](https://aws.amazon.com/marketplace/search/results?page=1&searchTerms=SAP&category=45c68cc2-ccd6-426b-94bd-92a791004dc2)
+ SAP ドキュメント: [SAP Solution Manager 7.2 - Application Operations](http://help.sap.com/viewer/c3c5ec585ee248228ddb6c3f08073ea9/LATEST/en-US/456408e2a51b476c960fda046c96cb76.html)
# ベストプラクティス 1.8 – 自動化された応答と回復技術を使用してモニタリングアラートに対応する
イベントへの対応を自動化し、手動プロセスによって発生するエラーを減らして、迅速かつ一貫した対応を実現します。
**提案 1.8.1 - オートメーションサービスを使用して、イベントに対する応答を自動化する**
モニタリングツールからトリガーされる修復アクティビティの実行を自動化するには、複数の方法があります。一般的に、すべての SAP アプリケーションとデータベースイベントを、それに応じてイベントベースのオートメーションを提供する単一のチャネルに送り込む必要があります。
AWS リソースの状態変更や SAP の独自のカスタムイベントからのイベントに応答するには、 [EventBridge ルール](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) を作成して、イベント [ターゲット](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) (例えば、Lambda 関数、Amazon Simple Notification Service (Amazon SNS) トピック、Amazon ECS タスク、AWS Systems Manager オートメーションなど) でアクションを呼び出すことができます。AWS Systems Manager オートメーションは、sapcontrol コマンドを呼び出し、自動的に SAP システムタスクを実行するために使用できます。
リソースのしきい値を超えるメトリクス (待機時間など) に応答するには、 [CloudWatch アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 1 つ以上のアクションを実行する [Amazon EC2 アクション](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/OperationList-query-ec2.html) 、 [Auto Scaling アクション](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_Operations_List.html) 通知を [Amazon SNS トピック](http://aws.amazon.com/sns/) .
アラームに応答してカスタムアクションを実行する必要がある場合は、Amazon SNS 通知または AWS Systems Manager オートメーションを通じて Lambda を呼び出します (例えば、アクション `aws:runCommand` を使用します)、次を参照してください。 [AWS ブログ: SAP システムの起動停止自動化をAWS Systems Manager で実現](https://aws.amazon.com/blogs/awsforsap/automate-start-or-stop-of-distributed-sap-hana-systems-using-aws-systems-manager/) .
Amazon SNS を使用して、イベント通知とエスカレーションメッセージを発行し、人々に情報を提供します。
また、AWS は、AWS のサービス API と SDK を通じてサードパーティーシステムもサポートしています。AWS パートナーやサードパーティーでは、モニタリング、通知、応答を可能にするモニタリングツールを多数提供しています。これらのツールには、Avantra、New Relic、Splunk、Loggly、SumoLogic、Datadog などがあります。
組織に該当する場合は、イベントとインタラクションをサードパーティー ITIL ツールにプッシュすることを検討します。例としては、 [AWS から ServiceNow への](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/integrations-servicenow.html) 統合などがあります。
自動化された手順が失敗した場合に、手動でも重要な手順を実施できるようにしておく必要があります。
# 2 – SAP 変更の欠点を減らし、修正を簡単にし、フローを改善する
**どのように欠陥を減らし、修正を容易にして、本番環境へのフローを改善するのですか?** リファクタリング、品質についてのすばやいフィードバック、バグ修正を可能にし、本番環境への変更のフローを改善するアプローチを採用します。これらにより、本番環境に採用される有益な変更を加速させ、デプロイされた問題を制限できます。またデプロイアクティビティを通じて挿入された問題をすばやく特定し、修復できます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-2.html)
詳細については、以下のリンクと情報を参照してください。
+ AWS 動画: [Ops を考慮に入れて設計する](https://youtu.be/uh19jfW7hw4?ref=wellarchitected)
+ AWS ドキュメント: [AWS デベロッパーツール](https://aws.amazon.com/products/developer-tools/?ref=wellarchitected)
+ AWS ドキュメント: [AWS Launch Wizard for SAP](https://docs.aws.amazon.com/launchwizard/latest/userguide/what-is-launch-wizard-sap.html#:~:text=AWS%20Launch%20Wizard%20for%20SAP%20is%20a%20service%20that%20guides,deploy%20SAP%20applications%20on%20AWS.)
+ 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/)
# ベストプラクティス 2.1 - バージョン管理と設定管理を使用する
Configuration Management システムは、手動プロセスによって発生するエラーと、変更を導入する労力を減らします。そうすることで、変更の追跡、新しいバージョンのデプロイ、既存バージョンへの変更の検出、以前のバージョンの回復 (障害が発生する場合に、その前の良好な状態に戻すなど) をサポートします。設定管理システムのバージョン管理機能を SAP 全体のすべての手順 (インフラストラクチャ、データベース、アプリケーション、SAP カスタムコードと開発) に統合します (例えば、ABAP、Java、UI5/JavaScript)。
各タイプの設定に異なるバージョン管理システムを検討しますが、メトリクスをセントラルリリース計画ツールに統合します。非トランスポータブル設定とバイナリバージョニングを環境全体で管理する方法を検討します。(例: SAP カーネルバージョンが環境全体で整合していることをどのように確認しますか?)。
**提案 2.1.1 - SAP 開発コードとバージョン管理に SAP 変更管理またはその他のサードパーティー製ツールを実装する**
すべての開発アプローチと SAP アプリケーション (ABAP、Java、UI5/JavaScript) およびその他の拡張機能やスクリプティングエリアをサポートするカスタムコードを実装していることを確認します。複数の SAP デプロイパターンですべての SAP アプリケーションとコードデプロイをオーケストレートする方法を検討します (例えば、AWS と SAP ビジネステクノロジープラットフォームでホストされている関連した開発を同時にリリースする方法)。
+ AWS サービス: [AWS CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html?ref=wellarchitected)
+ AWS 動画: [AWS CodeCommit の紹介](https://youtu.be/46PRLMW8otg?ref=wellarchitected)
+ SAP on AWS ブログ: [SAP 用の AWS DevOps ツール、パート 1: Cloud Foundry アプリケーション](https://aws.amazon.com/blogs/awsforsap/aws-devops-tools-for-sap-part-1-cloud-foundry-apps/)
+ SAP on AWS ブログ: [AWS DevOps tools for SAP, Part 2: SAP Fiori Apps (SAP 向け AWS DevOps ツール、パート 2: SAP Fiori アプリ)](https://aws.amazon.com/blogs/awsforsap/aws-devops-tools-for-sap-part-2-sap-fiori-apps/)
+ SAP ドキュメント: [SAP 変更制御管理](https://help.sap.com/viewer/8b923a2175be4939816f0981b73856c7/LATEST/en-US/2b614e1cb8204f35b477eac703073589.html)
+ SAP ドキュメント: [SAP BTP のベストプラクティス - ライフサイクル管理](https://help.sap.com/viewer/df50977d8bfa4c9a8a063ddb37113c43/Cloud/en-US)
**提案 2.1.2 - SAP アプリケーションの設定管理システムを実装する**
ABAP、Java、およびその他の SAP テクノロジーに設定管理ツールを実装し、非トランスポータブル設定とバイナリバージョニングを環境全体で管理する方法を検討します。(例: SAP カーネルバージョンが環境全体で整合していることをどのように確認しますか?)。SAP Solution Manager を使用して、設定とバージョン変更を計画し、SAP アプリケーションに実装します。
+ SAP ドキュメント: [Enhanced Change & Transport System (CTS\$1) (拡張された変更および転送システム (CTS\$1))](https://support.sap.com/en/tools/software-logistics-tools/enhanced-change-and-transport-system.html)
+ SAP ドキュメント: [SAP Solution Manager: Planning Landscape Changes (SAP Solution Manager: 環境変更の計画)](https://www.sap.com/germany/documents/2016/08/8ea1d93a-857c-0010-82c7-eda71af511fa.html)
**提案 2.1.3 - オペレーティングシステムの設定管理システムを実装する**
AMI ベーキングまたは Ansible、Chef または Puppet などのインプレース設定管理ソフトウェアを使用して、SAP ワークロード オペレーティングシステム全体の設定管理を整合します。脆弱性のアラートを発し、オペレーティングシステムにパッチを適用して強化するように促す、セキュリティに重点を置いた設定管理ツールを検討します。
+ AWS ドキュメント: [AWS Systems Manager State Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html)
+ AWS ドキュメント: [Configuration management in Amazon EC2 (Amazon EC2 での構成管理)](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/configuration-management.html)
+ AWS ドキュメント: [AWS OpsWorks とは?](https://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html?ref=wellarchitected)
+ AWS ドキュメント: [Amazon Inspector とは](https://docs.aws.amazon.com/inspector/latest/userguide/inspector_introduction.html)
**提案 2.1.4 - データベースの設定管理システムを実装する**
データベースソフトウェアベンダーと連携して、使用しているデータベースの設定管理アプローチを理解します。
+ SAP ドキュメント: [SAP HANA Platform Lifecycle Management (SAP HANA プラットフォームライフサイクル管理)](https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/LATEST/en-US/571d0bb4b1b2402f8e7caf0fe0290b61.html)
**提案 2.1.5 - インフラストラクチャの設定管理システムを実装する**
Infrastructure as Code (IaC) アプローチを使用して SAP ワークロードをサポートする AWS リソースをプロビジョンおよび管理します。AWS CloudFormation と AWS Cloud Development Kit は、AWS リソースでプログラムにより設定をプロビジョニングして管理できるツールです。ルールとポリシーを作成して定期的にインフラストラクチャを評価し、コンプライアンスを評価して問題があれば解決できる、設定監査と管理ツールを検討します。
+ AWS ドキュメント: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/)
+ AWS ドキュメント: [AWS Systems Manager インベントリ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-inventory.html)
+ AWS ドキュメント: [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html)
+ SAP on AWS ブログ: [Infrastructure as Code Example: Terraform and SAP on AWS (Infrastructure as Code の例: Terraform と SAP on AWS)](https://aws.amazon.com/blogs/awsforsap/terraform-your-sap-infrastructure-on-aws/)
+ SAP Lens [信頼性]: [ベストプラクティス 11.3 - サービスの可用性を復元するためのアプローチを定義する](best-practice-11-3.md)
# ベストプラクティス 2.2 – コード品質の向上のためにプラクティスを実装する
コード品質の向上のためにプラクティスを実装し、欠陥を最小限に抑えます。例えば、テスト駆動型デプロイ、コードレビュー、標準の導入などがあります。少なくとも SAP Code Inspector ツールを使用します。
**提案 2.2.1 - コード品質の向上のためにプラクティスを実装する**
例えば、テスト駆動型デプロイ、ペアプログラミング、コードレビュー、規約の導入などがあります。
**提案 2.2.2 - SAP 開発用 Code Amazon Inspector ツールを使用して、このプロセスを CI/CD パイプラインに統合する**
SAP ワークロードでの自動コード検査とリンティングに以下のツールを検討してください。
+ AWS ドキュメント: [Amazon CodeGuru - AWS Java および Python 開発用](https://aws.amazon.com/codeguru/)
+ SAP ドキュメント: [SAP Code Inspector for ABAP and SAP-specific development (ABAP と SAP 固有の開発向け SAP Code Inspector)](https://help.sap.com/viewer/ba879a6e2ea04d9bb94c7ccd7cdac446/LATEST/en-US/49205531d0fc14cfe10000000a42189b.html)
# ベストプラクティス 2.3 – 構築およびデプロイ管理システムを使用する
構築およびデプロイ管理システムを使用します。ABAP 変更および転送システム (CTS)、ウェブ IDE または SAP ツールなど SAP 認定ビルドとデプロイシステムを使用していることを確認します。これらのシステムは、手動プロセスによって発生するエラーと、変更を導入する労力を減らします。
**提案 2.3.1 - SAP 構築およびデプロイシステムを実装する**
ABAP 変更および転送システム (CTS)、ウェブ IDE、SAP BTP 継続的デリバリーサービスまたはその他の SAP ツールなど SAP 認定ビルドとデプロイシステムを実装します。
+ AWS 動画: [ソフトウェア開発のための継続的インテグレーションのベストプラクティス](https://www.youtube.com/watch?v=GEPJ7Lo346A&ref=wellarchitected)
+ SAP on AWS ブログ: [AWS DevOps tools for SAP, Part 2: SAP Fiori Apps (SAP 向け AWS DevOps ツール、パート 2: SAP Fiori アプリ)](https://aws.amazon.com/blogs/awsforsap/aws-devops-tools-for-sap-part-2-sap-fiori-apps/)
+ SAP ドキュメント: [Enhanced Change & Transport System (CTS\$1) (拡張された変更および転送システム (CTS\$1))](https://support.sap.com/en/tools/software-logistics-tools/enhanced-change-and-transport-system.html)
+ SAP ドキュメント: [Deploying Applications to BTP (BTP へのアプリケーションのデプロイ)](https://help.sap.com/viewer/825270ffffe74d9f988a0f0066ad59f0/LATEST/en-US/4478283a220b46d9a46bb28d6a9140e8.html)
# ベストプラクティス 2.4 – 複数の環境を使用する
複数の SAP 環境を使用して、ワークロードの実験、開発、テストを行います。環境が本稼働環境に近づくにつれて増加するコントロールレベルを使用して、デプロイ時にワークロードが意図したとおりに運用するように確信を強化します。通常、SAP 環境には、開発、テスト、製造の 3 層環境が最小要件です。
**提案 2.4.1 - 実験に一時的な環境を使用する**
テクノロジーテストおよびデベロッパーチームに、実験とリスクの軽減を有効にするための最小のコントロールを備えた、サンドボックスまたは一時的な環境を提供します。
+ AWS ドキュメント: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/)
+ SAP on AWS ブログ: [Infrastructure as Code Example: Terraform and SAP on AWS (Infrastructure as Code の例: Terraform と SAP on AWS)](https://aws.amazon.com/blogs/awsforsap/terraform-your-sap-infrastructure-on-aws/)
**提案 2.4.2 - 並行して作業し、俊敏性を向上させられるように開発環境を整備する**
並行作業ができるように非本番稼働環境を提供し、開発とテストの俊敏性を高めます。開発者が必要なイノベーションの手段を利用できるように、本番に近い環境でより厳格なコントロールを実装します。通常、SAP 環境には、開発、テスト、本番稼働の 3 層環境が最小要件です。
+ AWS ドキュメント: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/)
**提案 2.4.3 - リリース品質を向上させるため、できる限り本番稼働を再現する統合テスト環境を整備する**
テストとステージング環境では、本番稼働環境のインターフェイス、セキュリティ、回復性、パフォーマンスの特性をできる限り忠実にミラーリングして、リリースする前にアーキテクチャとコードインタラクションの問題を特定する必要があります。この環境のコスト効率を向上させるために使用されていない場合、クラスターのセカンダリリソースをシャットダウンすることまたは環境のアプリケーションサーバーのパフォーマンスを (水平的および垂直的に) スケールダウンすることを検討します。
+ 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/)
**提案 2.4.4 - Infrastructure as Code (IaC) と設定管理システムを使用して一貫性のある環境をデプロイする**
Infrastructure as Code (IaC) を使用したり、構成管理システムを使用したりして本番環境に存在するコントロールに準拠して設定された環境をデプロイし、システムがデプロイ時に予想どおりに動作することを確認します。タグ付けとリソースグループを使用して環境メタデータにラベル付けを行い強化し、オートメーションとコンプライアンスの目的に使用できるようにします。
+ SAP on AWS ブログ: [Infrastructure as Code Example: Terraform and SAP on AWS (Infrastructure as Code の例: Terraform と SAP on AWS)](https://aws.amazon.com/blogs/awsforsap/terraform-your-sap-infrastructure-on-aws/)
+ SAP on AWS ブログ: [Tagging Recommendations for SAP on AWS (SAP on AWS のタグ付けレコメンデーション)](https://aws.amazon.com/blogs/awsforsap/tagging-recommendations-for-sap-on-aws/)
+ AWS ドキュメント: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/)
+ AWS ドキュメント: [AWS リソースグループとは何ですか。](https://docs.aws.amazon.com/ARG/latest/userguide/welcome.html)
**提案 2.4.5 - 使用していないときは非本番稼働環境をオフにする**
環境を使用しない場合は、オフにして、アイドル状態のリソース (夜間や週末の開発システムなど) に関連するコストを避けることができます。
+ 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/)
# ベストプラクティス 2.5 – 変更をテストし、検証する
すべてのライフサイクルステージ (開発、テスト、本番環境など) で変更をテストし、その結果を検証してください。テスト結果を使用して、新機能を確認し、失敗したデプロイのリスクと影響を緩和します。テストと検証を自動化し、レビューの一貫性を確保し、手動プロセスによって発生するエラーとそれにかかる労力を減らすことができます。
**提案 2.5.1 - すべてのライフサイクルステージ (開発、テスト、本番環境など) で変更をテストし、その結果を検証する**
**提案 2.5.2 - 変更および主要なプロジェクトをリリースするときに比較するための、機能テスト、パフォーマンス、回復性にまたがるテスト結果のベースラインを維持する**
**提案 2.5.3 - 異なるレベルの変更にどのレベルのテストが必要かを理解する。例えば、フルスイートのテストとマイナーな更新のための対象を絞った回帰テスト。テストの定義と、本番稼働にリリースするためにテストが必要な変更の範囲について合意する。**
**提案 2.5.4. - サードパーティー製ツールとテストハーネスにより可能な箇所でテストを自動化する。まずは定期的な変更タイプと頻繁なリリースに重点を置く。**
# ベストプラクティス 2.6 – 小規模かつ可逆的な変更を頻繁に行う
頻繁に、小さく、可逆的な変更を行うことで、変更の範囲と影響を減らします。多数の SAP NetWeaver ソリューションは、「パッチフォワード」アプローチのみをサポートしますが、ロールバックを可能にするカスタム開発での機能トグルの使用を検討します。これにより、トラブルシューティングが容易になり、修復がすばやくできるようになります。また変更を元に戻すこともできます。
**提案 2.6.1 - 可能な場合、開発とリリースを頻繁かつ小規模な変更に分割する**
**提案 2.6.2 - 多数の SAP ソリューションは、「パッチフォワード」アプローチのみをサポートする (そして可逆的転送を許可しない) ため、カスタム開発で機能トグルを使用して、ロールバック/撤回ではなく機能の無効化を許可する**
**提案 2.6.3 - 不可逆的な SAP の変更については、システム全体のスナップショット、データベースのバックアップ、復元オプションなど、ロールバックオプションの追加を検討する**
+ AWS ドキュメント: [Amazon EBS クラッシュコンシステントスナップショット](https://aws.amazon.com/blogs/storage/taking-crash-consistent-snapshots-across-multiple-amazon-ebs-volumes-on-an-amazon-ec2-instance/)
+ AWS ドキュメント: [AWS Backint for SAP HANA](https://aws.amazon.com/backint-agent/)
# ベストプラクティス 2.7 – 変更のテスト、統合、デプロイを自動化する
ワークロードのビルド、デプロイ、テストを自動化します。これにより、手動プロセスによって発生するエラーと、変更をデプロイする労力を減らすことができます。
**提案 2.7.1 - 構築、テスト、デプロイ、検証を通じたコードのチェックインから統合とデプロイのパイプラインを完全自動化する**
**提案 2.7.2 - アプリケーション変更のデプロイパイプラインにエンドツーエンドの構築をオーケストレートするために SAP Solution Manager ChaRM、Focused Build またはサードパーティー製の変更・リリース管理ツールを実装する**
+ SAP ドキュメント: [SAP Solution Manager Change Request Management (SAP Solution Manager 変更リクエストの管理)](https://help.sap.com/viewer/8b923a2175be4939816f0981b73856c7/LATEST/en-US/4c3acb82b50843b4e10000000a42189e.html)
+ SAP ドキュメント: [SAP Focused Build](https://support.sap.com/en/alm/focused-build.html)
+ AWS Marketplace: [DevOps 向け製品とツール](https://aws.amazon.com/marketplace/search/results?page=1&searchTerms=sap&category=45c68cc2-ccd6-426b-94bd-92a791004dc2)
+ AWS Marketplace - [テスト用の製品とツール](https://aws.amazon.com/marketplace/search/results?page=1&searchTerms=sap&category=b1cf3403-729a-4df1-908d-51105b3574a3)
+ SAP on AWS ブログ: [SAP 用の AWS DevOps ツール、パート 1: Cloud Foundry アプリケーション](https://aws.amazon.com/blogs/awsforsap/aws-devops-tools-for-sap-part-1-cloud-foundry-apps/)
# 3 – ワークロードを運用する方法を理解する
**ワークロードをサポートして運用する準備が整っていることはどうすれば確認できるでしょうか?** 運用準備状況を [ークロード](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads.html) 、プロセスと手順、人事に関して評価し、次に関する運用上のリスクを理解します: [ークロード](https://docs.aws.amazon.com/wellarchitected/latest/userguide/workloads.html) .一般的なオペレーションのためのランブック、問題のためのプレイブックを作成し、できる限り多数のオペレーションを自動化して、回復力を高めエラーを減少します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-3.html)
詳細については、以下のリンクと情報を参照してください。
+ AWS ホワイトペーパー: [AWS クラウド運用モデル](https://d1.awsstatic.com/whitepapers/building-a-cloud-operating-model.pdf)
+ AWS サービス: [AWS Config](https://aws.amazon.com/config/?ref=wellarchitected)
+ AWS ドキュメント: [AWS Systems Manager の特徴](https://aws.amazon.com/systems-manager/features/?ref=wellarchitected)
+ 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/)
# ベストプラクティス 3.1 – 従業員の対応力を確保する
運用上のニーズに対応できるようにトレーニングを受けた、適切な人数の従業員が配置されていること、およびまた、適切な SAP、AWS、またはサードパーティーの認定を備えていることを検証するメカニズムを導入します。効果的なサポートを継続できるように必要に応じて従業員のトレーニングを実施し、従業員の対応力を調整します。
**提案 3.1.1 - SAP オペレーションチームが必要な学習と認定を評価する**
環境と依存関係により、異なる認定が適用される場合があります。テクノロジースタックをサポートできるようになるためにチームに必要な認定を評価します。
+ AWS ドキュメント: [AWS トレーニング](https://aws.amazon.com/training/)
+ AWS ドキュメント: [AWS 認定](https://aws.amazon.com/certification/)
+ オペレーティングシステム認定
+ SUSE ドキュメント: [SUSE Enterprise Linux 認定](https://training.suse.com/certification/)
+ Red Hat ドキュメント: [Red Hat Enterprise Linux 認定](https://www.redhat.com/en/services/certifications)
+ Microsoft ドキュメント: [Microsoft Windows 認定](https://docs.microsoft.com/en-us/learn/certifications/)
# ベストプラクティス 3.2 – クラウド運用モデルが運用目的と一致することを確認する
SAP ワークロードに適切なクラウド運用モデルを特定して、クラウドプラットフォームサポートのデプロイの速度、セキュリティ、オペレーションと責任に対して特定されたビジネス要件と一致するようにします。クラウドの導入に成功し、ビジネスの俊敏性を向上させるには、適切なクラウド運用モデルが重要です。
**提案 3.2.1 - ビジネスの目的に適切なクラウド運用モデルを採用する**
IT とビジネスの要件に従って、適切なクラウド運用モデルが採用されていることを確認します。どのチームがワークロードを構築して運用するかを決定します。SAP Basis/テクノロジーチームと開発チームの両方が DevOps モデルで SAP ワークロードを構築して実行する、共有の所有者のモデルに向かって進む計画を立てます。
+ AWS ガイダンス: [AWS クラウド でのオペレーションのモダナイゼーション](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-operations-integration/welcome.html)
+ AWS ホワイトペーパー: [クラウド運用モデルの構築](https://docs.aws.amazon.com/whitepapers/latest/building-cloud-operating-model/building-cloud-operating-model.html)
+ AWS 動画: [Cloud Operating Models for Accelerated Transformation (トランスフォーメーションを加速するためのクラウド運用モデル)](https://www.youtube.com/watch?v=ksJ5_UdYIag)
# ベストプラクティス 3.3 – 設計標準を共有し、新しいサポートスタッフに手順を指導する
既存のベストプラクティス、設計標準、チェックリスト、業務手順、ガバナンス要件をチーム間で共有します。すべてのチームが SAP ワークロードのすべてのコンポーネントにまたがるサポート手順を認識するようにします。
**提案 3.3.1 - 既存のベストプラクティス、設計標準、チェックリスト、運用手順、ガイダンス、ガバナンスの要件をチーム間で共有し、複雑になるのを防ぎながら開発努力の成果を最大化する**
**提案 3.3.2 - 継続的な改善とイノベーションを支援するために、設計標準の変更、追加、例外を申請する手順を設ける**
**提案 3.3.3 - チームが公開済みのコンテンツを把握していることを確認し、コンテンツを活用して、やり直しや無駄な労力を制限する**
**提案 3.3.4 - チームが SAP ワークロードの異なるコンポーネントのサポートコールをログに記録する方法を知っていることを確認する**
誰がオペレーティングシステム、データベース、SAP アプリケーションをサポートしていますか? 例えば、AWS またはオペレーティングシステムベンダーが、クラスタリングまたはパッチ適用の問題を直接サポートするかどうかを理解します。EC2 を含むオペレーティングシステムライセンスの場合、AWS はこのサポートを直接提供します。
+ AWS ドキュメント: [How to log a case with AWS Support (AWS Support でケースをログに記録する方法)](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)
+ AWS ドキュメント: [AWS サポート](https://aws.amazon.com/premiumsupport/)
+ SAP Note: [1656250 - SAP on AWS: Support prerequisites (サポートの前提条件)](https://launchpad.support.sap.com/#/notes/1656250) [SAP ポータルへのアクセス権が必要]
# ベストプラクティス 3.4 – ランブックを使用して SAP 環境オペレーションを実行する
ランブックは、具体的な成果を達成するための文書化された手順です。ランブックに手順を文書化することにより、一貫性を保ち、汎用イベントにすみやかに対応できるようになります。実行される一般的な SAP オペレーションを理解し、レビューサイクルで具体的なバージョン管理されたドキュメントを作成します。
+ AWS Well-Architected Framework [運用上の優秀性]: [運用即応性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operational-readiness.html)
+ AWS ドキュメント: [AWS Incident Manager を使用するランブックとオートメーション](https://docs.aws.amazon.com/incident-manager/latest/userguide/runbooks.html)
**提案 3.4.1 - SAP セキュリティオペレーションのための具体的なランブックを作成する**
一般的な SAP セキュリティオペレーションのランブックを作成することを検討します。
+ ユーザープロビジョニングとアイデンティティ管理
+ Firefighter アクセス
+ 認可の変更
+ セキュリティと認可の監査
+ 暗号化キーのローテーション
+ TLS 証明書管理
**提案 3.4.2 - SAP スケーリングとパフォーマンスオペレーションに特定のランブックを作成する**
一般的なスケーリングとパフォーマンスオペレーションのランブックを作成することを検討します。
+ ディスクボリュームのリサイズ
+ SAP アプリケーションサーバーの水平的と垂直的スケーリング
+ データベースサーバーのリサイズ
+ ロードバランシングへのサーバーの追加または削除
**提案 3.4.3 - 障害中の SAP オペレーションに特定のランブックを作成する**
障害中のオペレーションのランブックを作成することを検討します。
+ システムの再起動とシステムを再起動する順序
+ SAP バックアップとリストア
+ クラスターフェイルオーバー
+ ストレージ障害
+ 重要なインターフェイスの再開と再生
+ DNS とネットワークルーティングの変更
+ ランサムウェアからの復旧
**提案 3.4.4 - SAP メンテナンスオペレーションに特定のランブックを作成する**
次のメンテナンスオペレーションのランブックを作成することを検討します。
+ SAP の起動と停止
+ SAP の更新/システムコピー
+ 毎日のヘルスチェック
+ エラー管理/ABAP ダンプ
+ SAP アプリケーション、オペレーティングシステム、データベースへのパッチ適用
+ ログローテーション、クリーンアップ、アーカイブ
SAP 環境のデータベースアプリケーションログとトレースファイルのクリーンアップを検討します。例: SAP Note: [2399996 - Automating SAP HANA Cleanup (SAP HANA クリーンアップの自動化)](https://launchpad.support.sap.com/#/notes/2399996) [SAP ポータルへのアクセス権が必要]
# ベストプラクティス 3.5 – プレイブックを使用して問題を調査する
調査プロセスをプレイブックに文書化することで、よく理解されていない問題に対する一貫性のある迅速な対応が可能になります。これらのプレイブックをオペレーションだけでなく、非本番稼働環境やゲームデーなどの指定された練習セッションでも定期的に使用して、検証し進化させます。
**提案 3.5.1 - インシデント対応で使用する問題プレイブックを作成する**
頻繁に発生する問題と特定された問題のそれぞれに使用されるトラブルシューティングステップを理解し、具体的な、バージョン管理された、レビューサイクルのあるドキュメントを作成します。プレイブックには以下を含めることを推奨します。
+ パフォーマンスの問題調査
+ 容量の問題調査
+ 認証とサインオンの問題の調査
+ セキュリティインシデント調査
+ 接続性とネットワークの調査
+ ランサムウェアとウイルスの調査
+ インターフェイスエラー調査
+ バッチジョブエラー調査
+ デプロイまたはトランスポートエラーの調査
プレイブックに関連するサポート機能やチームとの統合およびコミュニケーションステップが含まれていることを確認します。一般的なコミュニケーションステップには、重大インシデントデスク、セキュリティインシデントチームまたは変更管理チームへの通知と進捗の最新情報の提供が含まれます。
**提案 3.5.2 - 通常の SAP ゲームデーを実行し、オペレーション手順をテストし、プレイブックを検証する**
運用チームに SAP ゲームデーを定期的に実行することを検討します。ゲームデーでは、障害やイベントをシミュレーションしてシステム、プロセス、チームの対応をテストします。その目的は、例外的な出来事が発生した場合にチームが実行することになっているアクションを実際に実行することです。こうしたゲームデーを定期的に実施することで、チームは対応方法に関する「基礎体力」をつけることができます。ゲームデーでは、運用、セキュリティ、信頼性、パフォーマンス、コストの各分野をカバーする必要があります。専用の実験環境を使用して、運用手順と回復プロセスを検証して練習するために実世界のシナリオをシミュレートします。
# ベストプラクティス 3.6 – オートメーションを使用して SAP 環境オペレーションを実行する
SAP 環境構築とランドスケープオペレーションのためのオートメーションパイプラインを作成します。Infrastructure as Code テクニック (例えば、CloudFormation、Launch Wizard for SAP) を使用するオートメーションを使用すると、繰り返し可能で俊敏な環境の作成または拡張が可能になります。自動化されたパイプラインとランドスケープオペレーションは、マニュアルプロセスが原因のエラーを減らし、デプロイ変更の労力を減らして、ビジネスニーズに反応する速度を高めます。
自動化された方法で一般的な環境タスク (例えば、System Copy、Start SAP、Stop SAP、Scale SAP) を実行できる、自動化された SAP 環境運用パイプラインを作成します。時間ベースのシステムシャットダウンまたはユーザーロードによるオートスケーリングなど運用上のイベントに対応してこれらのパイプラインを呼び出します。
**提案 3.6.1- Infrastructure as Code テクニックを実装して SAP 環境に再現可能でコード主導の構築パイプラインを作成する**
AWS CloudFormation、AWS Cloud Development Kit または AWS Launch Wizard for SAP などのツールを使用して、繰り返し可能な、制御されたすばやい環境デプロイを作成します。
+ SAP on AWS ブログ: [Infrastructure as Code Example: Terraform and SAP on AWS (Infrastructure as Code の例: Terraform と SAP on AWS)](https://aws.amazon.com/blogs/awsforsap/terraform-your-sap-infrastructure-on-aws/)
+ AWS ドキュメント: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/)
**提案 3.6.2 - オートメーションで共通の SAP 環境オペレーションを実装する**
オーケストレーションと Infrastructure as Code (IaC) のツールを組み合わせて使用して、一般的な SAP 環境オペレーションを自動化された方法で実行します。AWS CloudFormation、AWS Systems Manager – Run Automations、SAP Landscape Management (LaMa) および AWS Lambda などのツールは、デプロイパイプラインでの一般的な SAP 環境オペレーションを実行するようにオーケストレートできます。
ツール間の複雑なまたは深い統合が必要な サードパーティーオートメーションツールを検討します (例: Terraform、Ansible、Chef)。
自己修復とセルフメンテナンス環境が可能になるように、SAP ワークロードイベントへの応答に自動化されたオペレーションを使用することを検討します。
+ 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 ポータルへのアクセス権が必要]
+ AWS ドキュメント: [AWS Launch Wizard for SAP](https://aws.amazon.com/launchwizard/)
+ AWS ドキュメント: [AWS Systems Manager オートメーション](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ AWS Marketplace: [DevOps 向け製品とツール](https://aws.amazon.com/marketplace/search/results?page=1&searchTerms=sap&category=45c68cc2-ccd6-426b-94bd-92a791004dc2)
# 4 – SAP ワークロードを定期的に検証し改善する
**SAP ワークロードが継続して効率的に稼働することをどのように検証しますか?** SAP ワークロードを定期的に改善し、AWS からの新しいサービスリリースを活用することを目標とします。SAP ワークロードを維持するためだけに時間とリソースを使います。SAP ワークロードの効率性を進歩させるために継続的な増分の改善を目指します。パフォーマンス、回復性またはコスト効率を向上させる是正措置により、パッチ適用、小規模な変更、以前に決定した設計の再評価を計画します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-4.html)
# ベストプラクティス 4.1 – SAP ワークロードのライフサイクルイベントを理解して計画する
SAP ワークロードは、非常に大きく SAP に依存して、新しいソフトウェアと脆弱性のパッチ適用、オペレーティングシステムとデータベースのカーネル、サポートのためのエスカレーションを提供します。SAP は定期的に、リリースタイプ、メンテナンス期間、計画された可用性、 [製品可用性マトリックス (PAM)](https://support.sap.com/en/release-upgrade-maintenance.html) と SAP Notes など、SAP ソフトウェアリリースに関する情報を公開しています。SAP アプリケーションのそれぞれの詳細を取得し、ローカルに追跡して、SAP ソフトウェアが最新か、サポートされているか、メンテナンスの観点からいつ耐用年数が終了するかを理解します
PAM は、サポートされているデータベースプラットフォームとオペレーティングシステムを含む、プラットフォームの可用性と互換性に関する情報も提供します。これにより、SAP ワークロードの基盤となるコンポーネントのパッチ適用とアップグレードをガイドします。オペレーティングシステムベンダーにも独自のパッチ適用とサポートライフサイクルがあり、アップグレードなどの SAP メンテナンスとライフサイクルイベントを計画するとき、考慮する必要があります。
**提案 4.1.1 - 主なサポートとライフサイクルの日付を考慮して、SAP アプリケーションのオペレーションロードマップを作成する**
すべての SAP ソフトウェア アプリケーション、カーネルバージョン、オペレーティングシステム、データベースバージョンを一元的に登録してリストし、サポートされているバージョンとメンテナンスウィンドウに関する PAM 情報と統合します。SAP を最新の状態に保ちサポートを受けられる状態を継続する必要があるすべてのコンポーネントで、このリストを統合ビューとして使用して、パッチ適用、アップグレードとプラットフォームの変更を計画します。
+ SAP ドキュメント: [SAP Release & Maintenance Strategy: Product Availability Matrix (SAP リリースとメンテナンス戦略: 製品可用性マトリックス)](https://support.sap.com/en/release-upgrade-maintenance.html) [SAP ポータルへのアクセス権が必要]
**提案 4.1.2 - 認証情報、証明書およびライセンスの有効期限のカレンダーを管理する**
前述のメジャーな SAP ライフサイクルイベントとパッチ適用とともに、マイナーシステムイベントを計画する運用カレンダーを用意します。これらのメンテナンスイベントの例としては、システム認証情報の期限切れ、証明書 (例えば、システム間での STRUST 統合用) の期限切れやライセンス更新作業または必要な更新 (例えば、移行、開発または POC 目的のための一時的な SAP またはデータベースライセンス) があります。
+ AWS ドキュメント: [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/)
**提案 4.1.3 - SAP ソフトウェアが寿命になる前にアップグレードまたは代替案を計画する**
主要な SAP ライフサイクルイベントと運用維持 (パッチ適用、ソフトウェアアップグレード、移行と必要な場合のリプラットフォーム) を可視化する SAP 環境ロードマップを作成します。このライフサイクルカレンダーをビジネスおよび技術的なステークホルダーに連絡します。これらの SAP ライフサイクルアクティビティ/プロジェクトに資金を提供する投資を計画します。ビジネスステークホルダーとどこでメンテナンスウィンドウを実行するか、ダウンタイムや再起動が必要になるかを前もって計画します。
+ SAP ドキュメント: [SAP Roadmap Explorer](https://www.sap.com/products/roadmaps.html)
**提案 4.1.4 - 最新の状態を保ち、主な SAP Notes に申し込んでサポートアドバイスを受ける**
SAP ワークロードの主要な SAP Notes とナレッジベース記事 (KBA) にサブスクライブして、サポートの可能性やアドバイスの変更や更新が通知されるようにします。「お気に入り」の SAP Notes 機能を使用して、SAP ワークロードの頻繁にアクセスする重要なメモのリストを維持し、簡単にアクセスして比較できるようにします。
+ [SAP サポートポータル - お気に入りの SAP Notes](https://launchpad.support.sap.com/#/mynotes?tab=Favorites) [SAP ポータルへのアクセス権が必要]
# ベストプラクティス 4.2 – パッチ管理を定期的に実行してソフトウェアを最新の状態に維持する
定期的にパッチ管理を実行し、問題を解決して、ガバナンスに準拠するようにします。オペレーティングシステム、データベースおよび SAP アプリケーションレイヤーでのパッチを検討します。パッチ適用プロセスが、既存のサーバーにパッチを適用するのか、新しいサーバーをプロビジョンしてパッチを適用するのかを理解します。パッチ管理を自動化して、マニュアルプロセスによるエラーを減らし、パッチ適用の負担レベルを下げ、メジャー SAP、データベース、カーネルパッチ適用に必要なアプリケーションのダウンタイムを短縮します。
**提案 4.2.1 - SAP パッチ管理手順を実装して、定期的に SAP Security Notes と新しくリリースされたパッチを確認する**
オペレーティングシステム、データベースおよび SAP アプリケーションレイヤーでのパッチを検討します。
AWS ドキュメント: [AWS セキュリティ速報](https://aws.amazon.com/security/security-bulletins/?card-body.sort-by=item.additionalFields.bulletinDateSort&card-body.sort-order=desc)
SAP ドキュメント: [SAP EarlyWatch Alert](https://support.sap.com/en/offerings-programs/support-services/earlywatch-alert.html)
SAP ドキュメント: [SAP セキュリティ関連のノートとニュース](https://support.sap.com/en/my-support/knowledge-base/security-notes-news.html)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/best-practice-4-2.html)
この項目の詳細については、次を参照してください。[セキュリティ]: [ベストプラクティス 6.2 - オペレーティングシステムを構築し、保護する](best-practice-6-2.md) .
**提案 4.2.2 - SAP 環境全体でパッチを調整し自動化するために、AWS Systems Manager や AWS OpsWorks などの自動化されたツールを検討する**
+ AWS ドキュメント: [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html?ref=wellarchitected)
+ AWS ドキュメント: [AWS OpsWorks](https://aws.amazon.com/opsworks/?ref=wellarchitected)
+ AWS ドキュメント: [AWS OpsWorks とは?](https://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html?ref=wellarchitected)
+ SAP Lens [セキュリティ]: [ベストプラクティス 6.2 - オペレーティングシステムを構築し、保護する。](best-practice-6-2.md)
# ベストプラクティス 4.3 – 事業継続性計画と障害復旧を定期的にテストする
SAP システムは、通常、ビジネスクリティカルで、主要なお客様向けトランザクションに依存します。IT オペレーションの迅速な再開を可能にし、障害または災害の状況でのデータ損失を最小限にすることは、運用上の優秀性に重要です。オペレーションチームとシステムが、何をいつなすべきかを知り、障害発生時には、ただちにワークロードサービスを再開できるようにするには、業務継続計画 (BCP) と障害復旧手順が必要です。
サービスを正常に再開するのに重要なことは、BCP 手順と障害復旧計画を定期的にテストし、システムとサポートチームの進化に合わせて改善し、洗練することです。本当の危機的状況ではないときに BCP と回復計画をテストすると、現実のシステム障害や災害が発生したとき、サービスを正常に再開し、目標復旧時間 (RTO) と 目標復旧時点 (RPO) に間に合わせる能力に自信を持つことができます。
**提案 4.3.1. - BCP および障害回復テストカレンダーを作成する**
SAP ワークロードの定期的な (少なくとも手動) BCP と障害復旧テストのスケジュールを設定するカレンダーを作成します。テクノロジー運用チーム、サポートスタッフとビジネスステークホルダーをテストに参加させて、手順が理解され、期待が一致するようにします。できる限りリアルな状況でテストすることを目標にします。
以下のシナリオをテストしてそれぞれの回復メトリクスを検証することを検討してください。
+ SAP アプリケーションサービス障害
*(例えば、設定変更のために SAP アプリケーションサービスがスタートできない)*
+ シングルインスタンスホスト障害
*(例えば、SAP アプリケーションサーバー EC2 インスタンスに到達できなくなる)*
+ 単一ストレージボリューム障害
*(例えば、1 つの EBS ボリュームに到達できなくなる)*
+ ネットワーク障害と冗長接続への切り替え
*(例えば、オンプレミス Direct Connect 接続に到達できない)*
+ プライマリとセカンダリのクラスター化されたコンポーネント間での自動フェイルオーバー
*(例えば、SUSE HAE クラスターが、プライマリ HANA データベースを代替アベイラビリティーゾーンにあるセカンダリデータベースに移行させる)*
+ プライマリコンポーネントとセカンダリコンポーネント間でのマニュアルフェイルオーバー
*(例えば、Oracle DataGuard をマニュアルで呼び出すと、代替アベイラビリティーゾーンにあるセカンダリデータベースに切り換わる)*
+ 複数の冗長化されたコンポーネント間でのロードバランシング
*(例えば、プライマリウェブディスパッチャーがアベイラビリティーゾーンの高可用性ペアで失敗する)*
+ 代替 AWS リージョンでの SAP アプリケーションの回復 (必要な場合)
+ ランサムウェアの被害を受けた場合にバックアップから回復する
*(例えば、Simple Storage Service (Amazon S3) WORM バックアップから SAP ERP システム全体を回復する)*
**提案 4.3.2 - ワークロード変更の一環として定期的に BCP と障害回復手順を見直す**
時間の経過に伴い、ワークロードが進化し変化するとき、BCP と回復手順がこれらの変更で考慮されていることを確認します。コードまたはインフラストラクチャの変更が RTO または RPO に影響する可能性がある場合、ドキュメントと設定が更新されていること、および新しい BCP と回復プロセスが、リリースプロセスまたは定期的なテストカレンダーの一環としてテストされることを確認します。
+ AWS ドキュメント: [Business Continuity Plan (BCP) Definition (ビジネス継続性の計画 (BCP) の定義)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.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)
+ SAP Lens [信頼性]: [ベストプラクティス 11.4 – 定期的な回復力テストの実施](best-practice-11-4.md)
# ベストプラクティス 4.4 – 定期的なワークロードレビューを実行して、回復力、パフォーマンス、俊敏性、コストを最適化する
SAP on AWS を実行するときは、継続的で段階的に改善するために専用の時間とリソースを計画して、ワークロードの効果と効率性を進歩させます。AWS は、SAP ワークロードを最適化できるように、定期的に新しいサービス、アプローチ、改善された SLA をリリースし、お客様が利用できる値下げを行っています。新しいサービスリリースが自分の SAP ワークロードに適切かどうかを理解して検証し、該当する場合は、本番稼働環境に実装してワークロードを進化させます。
**提案 4.4.1 - SAP ワークロードの定期的なレビューを計画する**
AWS チーム、AWS パートナー、または内部エキスパートと連携し、Well-Architected Framework SAP Lens (このドキュメント) を使用して、定期的に SAP ワークロードをレビューします。少なくとも毎年 1 回ワークロードのレビューを計画します。改善アクティビティを特定、検証、優先順位付けし、修正を発行してバックログに取り込みます。
**提案 4.4.2 - Amazon EC2 インスタンスのサイジングとパフォーマンスを確認する**
履歴 CloudWatch メトリクスを検証して、SAP ワークロードの CPU 使用量とメモリ使用率を確認します。低 CPU またはメモリ使用率について各 SAP コンポーネントを確認し、ワークロード要件への適合が向上するように EC2 インスタンスを適切にサイジングすることを検討します。パフォーマンスの適合とコストの最適化に、新しくリリースされた SAP 認定 EC2 インスタンスタイプを検討します。オペレーションバックログで新しい改善の利用を計画します。
参照先 [コスト最適化](cost-optimization.md) (SAP ワークロードで Amazon EC2 を使用する場合)。
+ AWS ドキュメント: [SAP 向け Amazon EC2 インスタンスタイプ](https://aws.amazon.com/sap/instance-types/)
**提案 4.4.3 - Amazon EBS サイジングとパフォーマンスを確認する**
CloudWatch 履歴メトリクスからボリューム消費、スループットと IOPS 使用量を確認して、SAP ワークロード全体でのストレージ使用量を確認します。各 SAP コンポーネントにサイズ超過のストレージまたは 低スループット/IOPS 利用率がないか確認し、ワークロード要件への適合が改善されるように、Amazon EBS ストレージサイズとタイプを適切にサイジングすることを検討します。パフォーマンスの適合とコストの最適化に、新しくリリースされた SAP 認定 Amazon EBS タイプを検討します。オペレーションバックログで新しい改善の利用を計画します
+ AWS ドキュメント: [適切なサイジング](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/right-sizing/)
+ SAP Lens [コスト最適化]: [ベストプラクティス 18.4 - 各ストレージオプションがコストに与える影響を必要な属性に基づいて評価する](best-practice-18-4.md) .
**提案 4.4.4 - SAP ワークロードオペレーションの効率性を改善する新しいサービスを確認する**
SAP ワークロードでのオペレーションを向上させられる新しいサポートサービスリリースを確認します。AWS Support 契約の一部としてテクニカルアカウントマネージャー (TAM) を割り当てられている場合は、TAM が新サービスと最適化の検討をお手伝いします。
共有ファイルストレージ、インターフェイスサービス (例えば、AWS Transfer、API Gateway)、セキュリティサービス (例えば、Amazon GuardDuty、AWS Firewall)、バックアップツール (例えば、AWS Backint)、オートメーションツール (例えば、Launch Wizard for SAP) などの新しいリリースを検討します。
オペレーションバックログで新しい改善の利用を計画します。
+ AWS ドキュメント: [「最新情報」フィード](https://aws.amazon.com/new/)
+ AWS ドキュメント: [Proactive Services from Support (サポートからのプロアクティブなサービス)](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)
**提案 4.4.5 - AWS ブログとお知らせで SAP をモニタリングする**
SAP on AWS ブログフィードと AWS 「最新情報」フィードにサブスクライブして、新しくリリースされたサービスの発表、イノベーションアプローチや値下げの最新情報を得ることを検討します。
+ [SAP on AWS ブログフィード](https://aws.amazon.com/blogs/awsforsap/)
**提案 4.4.6 - 新しい、または改善された AWS のサービスを活用するために定期的な強化作業を計画する**
運用予算が十分であり、予定されたサポートチームが、新しい AWS サービスとワークロードの進化の実装とテストに定期的に取り組めることを確認します。