SAP Lens を全部読んだので概要レベルでまとめた

2022.12.22

この記事を書いたメンバー：

那須隆

こんにちは、那須です。

BeeX では SAP システムの移行や BASIS 運用を得意としていて、普段から SAP システムに触れる機会が多いです。一方でその SAP システムを Well-Architected フレームワークを参考にして運用できているかと言われるとそうでもない部分もあります。よく考えたら、そもそも Well-Architected フレームワークを最初から最後までキチンと読めているのかという疑問もあります。

少々時間はかかりましたが SAP システム向けの Well-Architected フレームワークである SAP Lens を全部読んだので、それを運用に活かせるようにまずは Priority が Required のものを概要レベルでざっくりとまとめてみました。

そもそも SAP Lens とは？

AWS 上の SAP ワークロードが適切に設計されていることを保証するための設計原則とベストプラクティスを集めたものです。詳細は↓こちらのドキュメントをご参照ください。
https://docs.aws.amazon.com/wellarchitected/latest/sap-lens/sap-lens.html

SAP Lens 概要紹介

Operational excellence

この柱では、システムの実行やモニタリング、および継続的な改善に焦点を当てた内容が書かれています。

まずはモニタリングです。AWS Data Provider for SAP をインストールすることから始まり、障害時の根本原因分析やトレンドを把握できるようにしたり、ワークロードの改善やインフラコストの最適化が重要だとあります。この内容はモニタリングというよりオブザーバビリティ（Observability）ですね。改善や最適化ができるようにするには、これまでのインフラ監視に加え SAP BASIS の観点で応答時間をチェックしたりキャッシュ使用率などを見ていく必要がでてきます。また、バックアップやレプリケーション、災害復旧（DR）についても正常動作ができなかったらアラートを出すことが求められます。

次に変更管理です。構成やバージョンを管理してロールバックできるようにしたり、IaC を活用してプロビジョニングしたり、テスト駆動開発したりといったことが重要だとあります。手作業だと再現性がないですし、そもそもオペミスなどで予期せぬ障害を引き起こしたりする可能性があるので、あらゆるタスクをコード化して自動化することはとても大切ですね。また、テスト環境は本番環境と同じにして、本番適用前に問題検知や原因特定していくことも求められています。

運用や改善の面では、あらゆる運用タスクをランブック化して自動化したり、GameDay などで定期的にチームの対応をテストして運用手順や復旧プロセスを検証し続けることが重要だとあります。あわせて体制やビジネス要求に合わせた運用モデルを作っていくことが求められます。DR 設計して実装したまではいいけど、テストせずに災害発生時にぶっつけ本番ではさすがに不安でしょうし他にも様々な問題が発生しそうですね。軽視されがちですが、運用において定期的なテストはとても重要な意味を持つので可能な限り実践していきたいです。

Security

この柱では、情報とシステムの保護に焦点を当てた内容が書かれています。

まずは責任共有モデルを理解するところから始まり、 SAP と AWS がサポートするセキュリティ標準とコンプライアンス認証を理解することが重要だとあります。そのうえで、トラフィックフローを制御したり適切なパッチ適用を実施したり本番と非本番を分離するような設計にすることが求められます。またそれらを文書化されていることもとても重要です。

また SSO などを活用して認証認可を適切に運用したり、ログを集めて分析できるようにしたりといったことも大切です。集めたログはパターン認識して分類したり、異常検知できるようにすることが求められます。

Reliability

この柱では、期待通りの機能を実行するワークロードと、要求に応えられなかった場合に迅速に回復する方法に焦点を当てた内容が書かれています。

まずはRTO、RPOを定義することから始まります。これがないと適切な信頼性設計ができませんね。そのうえで、インフラだけでなくアプリケーションまでモニタリングできる状態にし、いつの状態にでも戻せるようにバックアップしてリストアできるようにすることが求められます。

また、SAP ワークロードが停止した際のビジネスインパクトを把握することも欠かせません。何が停止したらビジネスにどのような影響が出るのか、それを把握してアプリケーション間の依存関係を理解した上で障害に耐えうる設計や実装を行うことが重要です。

Performance efficiency

この柱では、IT およびコンピューティングリソースの構造化および合理化された割り当てに焦点を当てた内容が書かれています。

EC2 インスタンスや EBS のスループット特性、SAPS 値を理解したり、ピークイベントを分析できるようにしたりすることが重要です。要件に合わせてストレージを選択したり、運用ではダイアログ応答時間やバッファスワップ、使用メモリを把握して評価するためにモニタリングしていくことが求められます。

Cost optimization

この柱では、不要なコストの回避に焦点を当てた内容が書かれています。

RPO や RTO などの要件を基にして、必要がなければ単一インスタンスのみで運用したり、盲目的に東京リージョンを選ぶのではなく費用対効果の高いリージョンを選択したりすることが重要です。また障害発生時に拡張できるようなアーキテクチャにしたり、縮退時の最低限のキャパシティを把握することはコストの最適化につながります。非本番システムにおいては、最小限のパフォーマンスを把握してインスタンスタイプを下げたり、使わない時間は停止したりといったことも重要です。Reserved Instance や Savings Plan の損益分岐点を把握しておくことも大切ですね。

データの観点では、不要なデータをそもそも保存しないといったことや、重要度の低いシステムは DB リカバリまでせずにストレージのみのリカバリで対応できないかを検討するとコスト最適化につながります。アーカイブできるものはアーカイブするといったことも大切です。

あまり頻度は多くはないかもしれませんが、使用頻度が低ければ廃棄することも検討しておくといいですね。ずっと停止していてもストレージ料金はかかるので、規模に比例して金額がかかることを考えるとこれも大切です。

Sustainability

この柱では、実行中のクラウドワークロードによる環境への影響を最小限に抑えることに焦点を当てた内容が書かれています。

環境への影響を考えて必要以上のリソースを使わないことが重要です。無駄に複数リージョンで設計しなくても Multi-AZ だけでできないか、パフォーマンス改善させてインフラリソースの使用量を減らしたり、Bastion をやめて Session Manager などのマネージドサービスに切り替えられないか、といったことを考えて実装することで環境にやさしいシステムを作ります。

さいごに

まとめてみると、ほとんどの柱でオブザーバビリティがカギを握っていることに気が付きました。そもそも可視化しないと今の状況が本当に適切に運用されている結果なのかどうかがわかりません。障害対応だけでなく、環境にやさしいシステムにしたり、インフラコストを最適化したり、パフォーマンス改善したりするためにも正しく現状を把握することがとても重要です。

本記事では Priority が Required の内容に絞って書きましたが、他にもたくさんのことが書かれています。Highly Recommended や Recommended の内容も理解して、お客様に価値ある SAP の運用をご提供できるように定期的に読み返したいと思います。

カテゴリー