# 16 – 継続的なパフォーマンスと最適化のオプションを理解する
**パフォーマンスの変化や最適化の機会を測定するために、どのようなプロセスや手順を導入していますか?** 過去のモニタリングデータからアプリケーションのパフォーマンス要件をベースライン化し、逸脱が発生した場合にシステム管理者に通知するアラートを設定します。システム管理者がマニュアルまたは自動化されたアクションでそのような問題を修正するための手順を用意します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-16.html)
# ベストプラクティス 16.1 – パフォーマンスを評価するデータを持つ
SAP システムのパフォーマンスを評価し、パフォーマンスが最適でない場合に対処するためには、リソースのモニタリングに関する Well-Architected Framework Performance Excellence ガイドラインに記載されているように、コンピューティング、メモリ、ストレージ、ネットワークに関するモニタリングデータを収集する必要があります。Well-Architected Framework 運用上の優秀性の柱に説明されているように、システムの現状を理解し、重要なパフォーマンス指標を導入し、診断のためにタイムリーにメトリクスを収集することは、パフォーマンスの問題を調査するために非常に重要です。
+ Well-Architected Framework [パフォーマンス効率]: [リソースをモニタリングして、それらが期待通りに機能していることを確認する](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/monitor-your-resources-to-ensure-that-they-are-performing-as-expected.html)
+ Well-Architected Framework [運用上の優秀性]: [ワークロードの状態の把握](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)
**提案 16.1.1 – パフォーマンスメトリクスに関連するデータを収集し、保存する**
関連する SAP モニタリングデータを収集して表示するには、AWS Data Provider for SAP をインストールして設定し、SAP ワークロードをサポートする選択したモニタリングツールでメトリクスを設定する必要があります。モニタリングの詳細とその他のレコメンデーションは、運用上の優秀性の柱に記載されています。
+ AWS ドキュメント: [AWS Data Provider for SAP (SAP 向け AWS データプロバイダー)](https://docs.aws.amazon.com/sap/latest/general/aws-data-provider.html)
+ SAP Lens [運用上の優秀性]: [ベストプラクティス 1.1 - SAP on AWS をモニタリングするための前提条件を実装する](best-practice-1-1.md)
+ SAP Lens [運用上の優秀性]: [ベストプラクティス 1.2 - SAP のインフラストラクチャモニタリングを実施する](best-practice-1-2.md)
+ SAP Lens [運用上の優秀性]: [ベストプラクティス 1.3 - SAP の個別アプリケーションモニタリングの実装](best-practice-1-3.md)
# ベストプラクティス 16.2 – ベースラインパフォーマンスの要件を設定する
すべての SAP アプリケーションには、固有のパフォーマンス要件があります。過去のモニタリングデータを使用することで、SAP 管理チームはこれらのアプリケーションのベースラインパフォーマンスを理解し、パフォーマンスの変化の程度を特定し、理解できます。意図しない CPU の急上昇、ストレージのスループット低下、メモリ消費量の増加、より複雑なパフォーマンスの低下などの異常を検出するために、関連するアラートを設定できます。このモニタリングデータを使用して、パフォーマンスをさらに微調整できます。
**提案 16.2.1 – SAP 固有の KPI を反映したデータを収集し、評価する**
この提案は、Well-Architected Framework パフォーマンス効率の柱の [リソースモニタリングに関する議論における追加提案と密接に連携しています](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/monitor-your-resources-to-ensure-that-they-are-performing-as-expected.html)。
この一般的なガイダンスに加え、SAP 特有の KPI として、ダイアログの応答時間、バッファスワップ、使用メモリなどがあります。これらの KPI は、実行中の SAP ソフトウェアのタイプとバージョンによって異なる場合があります。KPI とモニタリングに関するレコメンデーションの詳細については、このドキュメントの運用上の優秀性の柱に記載されています。
+ SAP Lens [運用上の優秀性]: [ベストプラクティス 1.2 - SAP のインフラストラクチャモニタリングを実施する](best-practice-1-2.md)
+ SAP Lens [運用上の優秀性]: [ベストプラクティス 1.3 - SAP の個別アプリケーションモニタリングの実装](best-practice-1-3.md)
# ベストプラクティス 16.3 – データを使用してパフォーマンスの傾向を特定する
パフォーマンスのベースラインを設定した後、システム管理者は、KPI が望ましい基準値内で安定しているかどうかを確認するために、時間の経過とともに傾向をモニタリングする必要があります。パフォーマンスデータから KPI の許容できない値への傾向が示された場合、システム管理者はパフォーマンスへの影響を回避または軽減するための措置を講じることができます。
**提案 16.3.1 – SAP システムのパフォーマンスに関する定期的なレビューを実施する**
システム管理者は、KPI を定期的にレビューすることで、パフォーマンス関連データの傾向を把握し、どのアラートが最も有効かを判断することができます。これらのアラートを使用して、傾向が続く場合は通知を自動化し、潜在的なパフォーマンスの問題に対処するための自動修復手段を講じることができます (例えば、パフォーマンス指標に対応して SAP パラメータを動的に変更するなど)。KPI と関連する傾向の例は、SAP EarlyWatch Alert レポートに記載されており、場合によっては、有用なメトリクスを追加してカスタマイズすることもできます。SAP サービスレベルレポートは、SAP ワークロードのサービスレベルアグリーメント (SLA) を締結している場合にも有用です。
+ SAP ドキュメント: [サービスレベルレポート](http://support.sap.com/slr)
+ SAP Note: [1040343 - SAP EarlyWatch Alert](https://launchpad.support.sap.com/#/notes/1040343) [SAP ポータルへのアクセス権が必要]
+ SAP Note: [1829914 - Customize EWA Reports (Customize EWA レポートをカスタマイズする)](https://launchpad.support.sap.com/#/notes/1829914) [SAP ポータルへのアクセス権が必要]
**提案 16.3.2 – 傾向を把握するために過去のデータを保持する**
システム動作の傾向を把握するために、パフォーマンスデータおよび関連するログを所定の期間保持する必要があります。SAP システムのパフォーマンスチューニングは、パフォーマンスの傾向または周期的なパフォーマンスイベントを構成するものを理解するために、数日、数週間、および数か月の履歴期間を振り返る機能に依存します。パフォーマンスへの影響を観察するためにデータの保持が必要な一般的なイベントには、以下のようなものがあります。
+ 月末および年末の財務処理
+ ビジネスのマイルストーンにおけるレポート要件の増加 (例えば、半期に一度の大規模なセールスキックオフの後など)
+ ビジネス内の大規模な新しい SAP ユーザー人口のオンボーディング
+ インフラストラクチャのサイジング、データベースパッチ、オペレーティングシステムのバージョンアップ、SAP ソフトウェアのアップグレードなど、テクノロジーの変更。
# ベストプラクティス 16.4 – パフォーマンスに関する問題を特定し、分類する
主要なメトリクスがパフォーマンスの低下を示している場合、根本的な原因を改善するためのプロセスを整備します。オートメーション (ダイナミックスケーリングに関する以下のベストプラクティスを参照) を使用すれば、マニュアルによる介入の必要性を減らすことができますが、それができない場合、管理者向けの自動アラートプロセスを用意することが不可欠となります。
**提案 16.4.1 – パフォーマンスアラートを適切に設定する**
モニタリングとアラートについては、Well-Architected Framework パフォーマンス効率の柱で説明したガイドラインに従い、SAP アラート機能が追加機能を提供する場合はそれを利用します。その他の詳細は [運用上の優秀性] でもご覧いただけます [1 - 状態の理解と反応ができるように SAP ワークロードを設計する](design-principle-1.md) .
+ Well-Architected Framework [パフォーマンス効率]: [モニタリング](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/monitoring.html)
+ SAP ドキュメント: [SAP NetWeaver Alert Monitor](https://help.sap.com/doc/7a827019728810148a4b1a83b0e91070/1610 001/en-US/frameset.htm?frameset.htm)
**提案 16.4.2 – パフォーマンスインシデントの自動修復**
パフォーマンスインシデントの管理には、Well-Architected Framework 運用上の優秀性の柱で詳述されているオペレーションに関するベストプラクティスが含まれますが、潜在的なパフォーマンス障害を事前に検出し、自動修復することによって、パフォーマンス問題の深刻化を防ぎ、エンドユーザーエクスペリエンスを改善することができます。パフォーマンス問題を軽減するための自動化されたプロセスが使用できない場合、運用チームがパフォーマンス問題にどのように対応すべきかの詳細なランブックを用意しておけば、パフォーマンスインシデントに早く対応できます。
+ SAP Lens [運用上の優秀性]: [ベストプラクティス 1.8 自動化された応答と回復技術を使用してモニタリングアラートに対応する](best-practice-1-8.md)
+ Well-Architected Framework [運用上の優秀性]: [ベストプラクティス: 運用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/oe-operate.html)
# ベストプラクティス 16.5 – パフォーマンス要求に対して拡張する
AWS でワークロードを運用する最大のメリットは、ユースケースに必要なパフォーマンスに合わせて、コンピューティング性能の増減やストレージのパフォーマンス特性の変更が可能なことです。SAP ワークロードの場合、パフォーマンスのボトルネックを回避するために、必要に応じて動的スケーリングを使用します。SAP HANA データベースクラスターのスケールアウトなど、動的スケーリングが不可能なシナリオでは、マニュアルによるデプロイプロセスを使用します。
**提案 16.5.1 – SAP ワークロードを受動的に拡張する**
ワークロードのパフォーマンス要件の動的な変化に対応し、SAP リソースを必要に応じて拡張できます。可能な限り、スケールインまたはスケールアウトにはオートメーションを使用しますが、それができない場合 (データベースインスタンスのスケールアップなど) には、マニュアルで行うプロセスを用意してください。考慮すべき点:
+ 需要に応じてアプリケーションサーバーの容量を追加または削除したり、インスタンスサイズを変更したりする
+ プログラムによる仮想リソースの再配布のために SAP パラメータを変更する
+ [ストレージタイプの変更](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modify-volume.html) (例えば、Amazon EBS の `gp3` を `io2` へ、またはその逆など、AWS 内で) 行うことで、ストレージのパフォーマンスを最適化します。
**提案 16.5.2 – 予測可能な SAP ワークロードのスケーリングをスケジュールする**
オートメーションまたはマニュアルのいずれであっても、予測可能なパフォーマンスパターンに基づいて SAP ワークロードをスケーリングすることが推奨されます。例えば、SAP ECC システムで月末の財務処理により、アプリケーションサーバーのインスタンスの処理要件が 20% 増加することが予測される場合、システム管理者は、アプリケーションサーバーの数やサイズを事前に増やし、使用量が予測どおりに減少したらインスタンス数をスケールインさせることができます。
# ベストプラクティス 16.6 – 分析のための生産負荷シミュレーションのメカニズムを開発する
テストシステム内に本番稼働データのクローンを持つことで、システム管理者は本番稼働の SAP ワークロードをシミュレーションし、ストレスやボリュームテストなどの重要なパフォーマンステストを実施することができます。このタイプのテストは、潜在的なパフォーマンスのボトルネックを特定し、本番稼働環境でのパフォーマンス問題の発生を防止するのに役立ちます。
**提案 16.6.1 – SAP システムにおける自動ストレステストとボリュームテストを実施する**
AWS で実行する場合、本番稼働データをテスト環境にコピーするのは比較的簡単です (例えば、 [本番稼働環境から EBS スナップショットを使用して](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/ec2-backup.html) 新しいテストインスタンスを作成する)、ただし、マニュアルまたは自動のコピー後のステップを正しく実行するように注意する必要があります。コピー後のステップには、トランザクション BDLS による論理システム名の変更、機密本番稼働データのスクランブルや削除、関連するテストシステムとの統合設定などがあります。また、必要に応じてインスタンスのプロビジョニング、設定、シャットダウンが可能なため、分離されたパフォーマンステストシステムを永続的に維持する必要がないことも利点の一つです。
テストシステムへの負荷のかけ方はさまざまです。
+ AWS では、 [Distributed Load Testing](https://aws.amazon.com/solutions/implementations/distributed-load-testing-on-aws/) ソリューションが自動負荷テストに役立つかもしれません
+ eCATT (Extended Computer Aided Test Tool) による SAP ソフトウェアでの [スクリプトの作成と自動化](https://wiki.scn.sap.com/wiki/display/ABAP/eCATT)
+ サードパーティーの自動テストソリューションの使用
+ SAP システム内で適切なプログラムを大規模に開始するための、オペレーティングシステムレベルでのスクリプトの作成
# ベストプラクティス 16.7 – パフォーマンスデータに基づいてサイジングと設定を継続的に最適化する
インシデント対応プロセス以外でも、定期的にパフォーマンスメトリクスを確認します。そうすることで、サイズが小さい、大きすぎる、あるいはまったく使われなくなったシステムコンポーネントを発見できます。SAP ワークロードのパフォーマンス最適化を定期的に行い、実際のユーザー負荷に応じたシステムコンポーネントの適切なサイジングに重点を置く必要があります。このアクティビティは、ユーザーエクスペリエンスを向上させ、アーキテクチャの不要な部分を排除し、ワークロードのコスト効率と耐障害性の両方を向上させるのに役立ちます。
**提案 16.7.1 – 過去のパフォーマンスメトリクスを参考に、アーキテクチャの適切なサイジングを定期的に実行する**
SAP のワークロードを定期的に確認し、コンポーネントのサイズを適正化する機会を設けます。ストレージ、コンピューティング、ネットワーク、およびサポートサービスを増減して、ビジネスパフォーマンス要件により適合させる必要があるかどうかを検討します。
詳細については、以下のリソースを参照してください。
+ SAP Lens [コスト最適化]: [ベストプラクティス 20.5 - 使用状況を確認し、最適化を図る](best-practice-20-5.md)
+ SAP Lens [運用上の優秀性]: [ベストプラクティス 4.4 - 定期的なワークロードレビューを実行して、回復力、パフォーマンス、俊敏性、コストを最適化する](best-practice-4-4.md)
+ AWS ドキュメント: [規模の適正化](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/right-sizing/)