# 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 サービスとワークロードの進化の実装とテストに定期的に取り組めることを確認します。