[レポート]これから始める SAP on AWS ～ 設計と運用のベストプラクティス～ #AWSSummit

こんにちは、臼田です。

こちらはAWS Summit2018で行われたセッション「これから始める SAP on AWS ～ 設計と運用のベストプラクティス～」のレポートです。

概要は下記のとおりです。

スピーカ: 河原 哲也

アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト

基幹業務アプリケーションの代表格である SAP システムにおいてもクラウド化が進んでおり、現在世界で数千のお客様が SAP on AWS を採用されています。本セッションでは、多くのお客様実績から培った、主に SAP Basis /インフラ担当者が押さえておくべき SAP 認定 Amazon EC2 インスタンス、アーキテクチャ設計、実装から運用自動化などのポイントをご紹介します。

資料は後ほど公開される予定とのことです。

レポート

本セッションの内容

• SAPプラットフォーム認定
• サイジング
• アーキテクチャ
• 運用管理
• 自動化

SAPプラットフォーム認定

• SAPの認定をとっているインスタンスタイプ
  • 汎用
  • コンピューティング最適化
  • メモリ最適化
• インスタンスタイプは新しい世代の利用を推奨
  • M4からM5の世代に変わってSAPSは19%向上、3%値下げ
  • 新しい世代で高い機能を安く
• ブロックストレージ
  • ボリュームごと向いているユースケースがある
  • 例: Windows MSSQL
  • ドライブごとストレージタイプを変える
    • システムは汎用SSD
    • DBはプロビジョンどIOPS
    • バックアップはスループット最適化HDD
  • Linuxでも同じ
• SAP HANAアプライアンス認定
  • HANAはストレージパフォーマンスが重要
  • データとログを別のEBSボリュームで構成する事ができるようになった

サイジング

• サイジングの流れ
  • 一般的なSAPサイジング手法と同様だがSAPS値が開示されているためお客さまがセルフサービスで実施可能
  • 新規はSAP Quick Sizerで算出
  • 移行はSAP ealyWatchレポートの稼働状況から算出
  • AWSを利用すると実質的なサイジングからの開放される
    • 初期の段階で5年の原価償却を見込んだサイズを選定する必要がない
  • 常に適切なインスタンスタイプを選ぶ、増やす
  • ストレージも同じ
  • Elastic Volumesでリアルタイムに変更する
    • ボリュームサイズの変更
    • ボリュームタイプの変更
    • IOPSパフォーマンスの調整

アーキテクチャ

• 参考: SAP on AWSにおけるVPCサブネットのゾーニングパターン | Amazon Web Services ブログ
•  ネットワーク設計例
  • 基本はVPCの一般的な構成と一緒
  • AWSアカウント、VPC、サブネットをどの単位で分離するか
  • セキュリティグループ、NACL、ルートテーブルをどう構成するか
  • パブリックとプライベートをどうするか
  • サブネットで分ける場合
    • パブリックにSAPルータを置く
    • 管理共用サービス用のプライベートを作成
    • AP/DB用のプライベートを作成
  • VPCで分ける場合
    • 上記3つをVPCとしてピアリングとする
  • 社外接続する場合
    • PI,EDIなどと連携するなどの用途
    • 上記+エクストラネットゾーンを作成
    • エクストラにSAP_CONN等を配置
  • プライベート領域からS3と通信する場合
    • VPCエンドポイント経由でS3プライベート接続する
• 可用性
  • サーバ単体の障害にどう対応するか
    • EC2 AutoRecoveryで自動復旧
  • アプリやDB障害についてはHAとして別AZにスタンバイ
    • サードパーティでデータのレプリケーションやEFSで共有ストレージとする
    • AZ間は2ms程度の遅延があるのでそこは注意
  • 要件が厳しい場合にはクラスタではなくスプレッドプレイスメントグループ
  • それぞれ異なるHWに配置されるインスタンスのグループ
  • HW障害が起きた際の影響範囲を小さくすることができる

【速報】EC2でSpread placement groupsが使えるようになりました #reinvent

• バックアップ
  • リージョン内でS3にバックアップ
  • DRの場合はS3のCRRによるバックアップ
  • S3ストレージクラス
    • 1ゾーン低頻度アクセスもあるのでDR先でより安価に利用できる
    • 元データの保管には利用しない
  • バックアップ領域はOS、SAP、DBでそれぞれどうするか考える
  • システムバックアップとしてAMI作成
    • OS、SAPがバックアップできる
  • DBはDB標準やサードパーティのダンプにEBSスナップショットやS3との組み合わせで世代保管

運用管理

• 基本的にAWSのコンポーネントを利用する形
•  プロビジョニング
  • CloudFormation
  • AWS Service Catalog
• 構成管理
  • AWS Systems Manager(SSM)でパッチ適用などで利用できる
• パフォーマンス、死活
  • ここはいくつかSAP特有の構成になる
  • CloudWatch
  • SAP拡張監視
  • CloudWatch詳細モニタリング
  • AWS Data Provider for SAP(モジュール)
    • インストールすると下記情報を取得可能
    • AWS固有情報
    • システム構成情報
    • 監視メトリクス
• ガバナンス、コンプライアンス
  • AWS Config
  • CloudTrail
  • Amazon Inspector
  • IAM
• リソース最適化
  • Trusted Advisor

自動化

• デプロイの高速化
• 必要なソフトウェアを予め導入設定済みの再利用可能なAMIを用意
• 運用管理の工数削減
• セキュリティコンプライアンス違反の自動通知
• スナップショット、バックアップ、パッチの自動化
• システムリフレッシュ、SAP Basisタスク
• 自動化のためのいろんなCloudFormationのテンプレートを公開している
• AWS Quick Start for SAP HANA
  • 1時間未満で用意に展開
• AWS Quick Start for SAP NetWeaver
  • GitHubのリポジトリにあるのでカスタマイズ可能
• SAPに依存しないソリューションで使えるものもある
• AWS Answersのソリューション
  • AWS Instance Scheduler
    • 起動停止を自動的に

EC2 SchedulerでEC2インスタンスをスケジュール操作してみた

•  AWS Ops Automator
  • 世代保管

AWS Answersで公開されているAWS Ops Automatorを試してみた #reinvent

• どちらもCFnがありすぐ利用できる

まとめ

通常のAWS環境上での構築についての考慮点も含めて、AWS上でSAPを展開する上で必要な情報がまとまっている内容でした。

詳しく知りたい方は公開された資料をチェックしてみてください！