# 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) 統合などがあります。
自動化された手順が失敗した場合に、手動でも重要な手順を実施できるようにしておく必要があります。