こんにちは、大石（@se_o_chan）です。
AWS認定のうち、「AWS認定 SAP on AWS - 専門知識」に合格しました！！
この試験区分は2022年4月26日に正式版としてスタートしたばかりなので、世の中にあまり情報が出ていないのと、自分自身SAPの経験がなかったので従来の区分とは違った難しさがありました。
私が合格に至った勉強法と試験範囲の内容をまとめますので、同じく資格取得に興味のある方のご参考になれば幸いです。
準備期間と結果
準備期間は2022年9月29日～11月5日の1か月強でした。
SAPって何？というところからのスタートでしたが、結果は772点で、幾つかの分野は「改善が必要」と判断されつつも何とか合格できました。
合格までの勉強法
１．試験ガイド
AWSが提供している試験内容を説明した資料です。
いつも最初にざっくり目を通しますが、初見では分からない単語が多すぎました。
今回は試験日が近づいてきたタイミングで見返して単語の意味が理解できるようになっているか、という確認のために参照しました。
SAP on AWSの試験ガイドはこちら。
（出典）AWS Certified SAP on AWS - Specialty（PAS-C01）試験ガイド
２．サンプル問題
こちらも毎回最初に確認するAWS公式のサンプル問題10問です。 SAProuter？SAP Fiori？Backint？という状態だったので9割分からず。 初見はサラリと流すくらいで、後述の３～５を確認した後に戻ってくるのがよいと思います。 リンクはこちら。
３．AWS Skill Builder
ありがたいことに「SAP on AWS(Technical)(Japanese)」という日本語の教材が用意されています。 本格的に試験勉強を始めるなら、まずはここからが良いと思います。 VPC、EC2、S3などAWSサービス側からSAP on AWSの内容を説明してくれているので、AWSエンジニアなら読みやすいと感じるのではないでしょうか。 リンクはこちら。
４．SCSKさんブログ
他社のブログとなりますが、SCSK 大口さんのブログが素晴らしいです。 2022年11月現在、SAP on AWSに合格している方の多くがこのブログに助けられているのではないでしょうか？ ブログの記載内容や、中で紹介されている記事の内容をしっかりと理解できれば合格にたどり着けると思います。 リンクはこちら。
５．SAP on AWS技術文書
AWSが公開しているSAP on AWSに関するドキュメント集です。
今回の教科書的な位置づけになると思いますが、「SAP HANAのバックアップ」「SAP NetWeaverのLinuxサーバへのデプロイ」というように断片的な情報の集まりなので体系的に学ぶことは難しいです。
そういう意味でも３、４を先に参照することをおすすめします。リンクはこちら。
６．公式練習試験
Skill Builderに模擬問題が公開されています。2022年10月現在、日本語のコンテンツがあります。 20問だけですが、出題傾向や重要点を確認できる貴重な情報源ですので全問正解できるようやりこみましょう。 リンクはこちら。
今回学んだこと
自分の備忘もかねて、今回学んだことを整理していきます。
このブログの位置づけとしては、上記の「３．Skill Builder」と「４．SCSKさんブログ」の間くらいの情報量・難易度になると思います。
要点を抜粋して記載した（といってもそれなりに長文ですが）ので、試験範囲の全体感を掴んで頂けるかもしれません。
※SAP未経験者につき、正確な情報ではないかもしれませんがご了承ください。
SAP用語
なんといってもこの試験を難しくしているのは初学者には理解できないSAP用語です。 SAPエンジニアの方にとっては基本的な事ばかりなのでしょうが、触れたことが無い人にとっては？？？となります。 主なSAP用語を以下にまとめました。 この後、各用語が至る所で出てくるのでその都度ここに戻って意味を確認してください。
| 分類 | 用語 | 概要 |
|---|---|---|
| SAP製品 | SAP ERP Central Component（ECC） | SAP社の主力ERP製品 |
| SAP S/4HANA | SAP HANAをデータベースとするERP製品 | |
| SAP Business One | 中小企業向けERP製品 | |
| SAP BW/4HANA | SAP HANAをデータベースとするDWH製品 | |
| SAP Business Objects | データの可視化をするBI製品 | |
| コンポーネント | SAP NetWeaver | ABAP、Javaのランタイムを提供するミドルウェア |
| Primary Application Server (PAS) | SAPのプライマリアプリケーションサーバ | |
| Additional Application Server (AAS) | SAPのセカンダリアプリケーションサーバ | |
| ABAP SAP Central Services (ASCS) | メッセージングサーバとエンキューサーバの機能を持つサーバ | |
| Enqueue Replication Server (ERS) | ASCSのキュー情報をレプリケートしたACSCの副系サーバ | |
| Web Dispatcher | リバースプロキシ | |
| SAP HANA | 列指向のインメモリデータベース | |
| SAP ASE | SAPが提供するRDBMS | |
| AnyDB | 非HANAデータベースの総称。Oracle、SQLServer、DB2など | |
| SAP GUI | SAPのクライアントアプリ。Windows版とJava版がある | |
| SAP Fiori | HTML、Javascript、CSSによるブラウザアプリ | |
| ツール類 | HANAシステムレプリケーション（HSR） | SAP HANAのデータレプリケーション機能 |
| AWS Data Provider for SAP | EC2のOSパフォーマンス情報を収集するエージェント | |
| SAProuter | SAP OSSがSAP環境に接続するための入り口となるツール | |
| SAP Solution Manager（Solman） | SAPが提供するITライフサイクル管理ツール。監視など | |
| Software Provisioning Manager（SWPM） | SAPシステムを導入するツール | |
| Software Update Manager（SUM） | SAPシステムをアップデートするツール | |
| SUM Database Migration Option（DMO） | 異機種データベース間のデータ同期ツール | |
| その他 | ABAP | SAP特有の言語 |
| SAPS | サーバ(EC2)に対する性能指標 | |
| SAP Online Service System（OSS） | SAPサポート。製品に関する問い合わせ窓口 | |
| Secure Network Connection（SNC） | SAProuterとSAP OSS間のセキュア通信プロトコル |
SAPアーキテクチャ
まずはSAPの基本アーキテクチャから入ります。
各コンポーネントはSAP NetWeaverというミドルウェア上で稼働します。
NetWeaverはABAPというSAP特有の言語ベースで動作するものと、Javaベースで動作するものの2種類あります。
- SAPの業務アプリが稼働するのがPrimary Application Server（PAS）およびAdditional Application Server（AAS）です。 1台目はPAS、2台目以降はAASと呼ばれ、AASは冗長構成を組む場合のオプションの位置づけです。
- これらアプリケーションサーバのロードバランサとして機能するのがABAP SAP Central Services (ASCS）です。 ASCSにはアプリケーションサーバに対するロードバランサーの機能を持つメッセージングサーバと、データベースを更新する時のロック情報を管理するエンキューサーバの機能があります。
- Web Dispatcherはいわゆるリバースプロキシのような機能を持ちます。例えば本番、検証、開発環境がある場合にWeb Dispatcherが通信を振り分けます。Web Dispatcherは無い構成も見かけるので必須コンポーネントではないと思います。
- データベースとして使えるDBMSはSAPで指定されており、大きくはSAP HANAとAnyDB（Oracle、SQLServer、DB2など）に分かれます。
- 共有ファイルは各NetWeaverインスタンスが共通して使うファイル群を格納し、各サーバでマウントします。
AWS実装（サーバサイド）
ここからはAWSでの実装方式に入ります。
先ほどのアーキテクチャをAWSで実装する場合、共有ファイルの管理としてEFSを採用し、その他のコンポーネントは全てEC2で実装します。
したがって、AWS構成図は次のようになります。
Web DispatcherをPublic Subnetに配置していますが、これはSAPをインターネットに公開する場合です。
Direct ConnetやSite-to-Site VPNで閉域網からアクセスする場合はPrivate Subnetに配置することもありえます。
またPrivate Subnetからインターネットへの通信用にNATゲートウェイを配置するのが定石です。
ちなみに、SAPがサポートするEC2インスタンスタイプは限定されており、SAPの各インスタンス認定とHANA認定のインスタンスタイプがあります。
その一つの基準になっているのがSAPSという性能値で、100SAPSは1時間当たり2,000の注文明細を処理できる性能だそうです。
上記構成で単一障害点（SPOF）となるのはASCS、データべース、Web Dispatcher*1です。 そこでこれらのコンポーネントを高可用性アーキテクチャに変更します。
- まずASCSはクラスター化します。 クラスタリングソフトウェアとしてSAPが認定しているのはRed Hat HA、SLES HA、WSFC、SIOS、CLUSTERPROです。 ASCSのエンキューサーバにはデータベース更新する度にキューが格納されるわけですが、このキュー情報をクラスターの副系に同期する必要があります。 このキューを同期しエンキューサーバのレプリカとなるサーバ（＝ASCSの副系）をEnqueue Replication Server（ERS）と呼びます。
- データベースも同様にクラスター化することで高可用性を担保します。 データベースの副系へのデータ同期は各DBMS機能で実装します。例えばOracleであればData GuardがSAPでサポートされます。 試験で最も出題される可能性が高いのはやはりSAP HANAで、副系への同期はHANAシステムレプリケーション（HSR）で実装します。 またAWS固有の機能だとAWS DMSによる同期も可能で、SAP ASEはDMSを利用できます（HANAに対しては利用不可です）。
- Web Dispatcherはクラスター化することもできますが、ALBの配下に配置することで冗長化する方式もあります。
これで各コンポーネントがMulti-AZの高可用性アーキテクチャになりました。 ここでAWSでクラスター構成を組む際に重要なオーバレイIPアドレスについて触れておきます。 一般にクラスターはあらかじめ仮想IPアドレスを割り当て、それに紐づくホストを変更することで正系・副系を切り替えます。 ただしAWSの場合、プライベートIPアドレスはsubnetに紐づき、subnetはAZに紐づきますから、IPアドレスはAZリソースだと考えることが出来ます。 そのためクラスター仮想IPアドレスをどこかのsubnetに属させるとクラスターがAZ障害に耐えられなくなります。 そこで、クラスター仮想IPアドレスとしてVPC外のレンジから払い出し、NLB（またはTransit Gateway）とルートテーブルを使ってEC2と紐付けることでその課題を解消します。 このVPC外のレンジから払い出した仮想IPアドレスのことをオーバーレイIPアドレスと呼び、本試験での頻出用語となります。 詳細についてはSAP on AWS技術文書に記載があるので、こちらをご参照ください。
AWS実装（フロントサイド）
SAPのフロントサイドは、専用クライアント（SAP GUI）とブラウザアプリ（SAP Fiori）の2種類あります。 それぞれのAWSでの実装法を整理します。
SAP GUIの場合、クライアントアプリなので各パソコンに資材を配布したり、パッチレベルを統一するのに労力がかかります。 Amazon AppStreamを使うとクライアントアプリの資材を一元管理できるため、その労力の解消が期待できます。 aws.amazon.com Amazon WorkSpacesでも同様のことを実現でき、SAP Single Sign-Onというオプションと統合してシングルサインオンも実現できます。 aws.amazon.com
SAP Fioriの場合、ブラウザアプリなので一般的なWebサイトと同様のアプローチとなります。 本試験で問われるのは「CloudFrontによるキャッシュ管理」「Global Acceleratorによる通信高速化」「WAFによるセキュリティ高度化」などです。
これでフロントエンドのAWS実装もできました。
AWS実装（運用）
本番環境のシステムを運用するには、当然監視・バックアップが必要になります。 SAP on AWSではどのようにそれらを実装するかを整理します。
まず監視です。AWSサービスであるCloudWatchを使う方法が1つです。CloudWatch Application InsightはSAP HANAに対応していますし、LambdaでSAP関連のメトリクスを収集してCloudWatchに送信するといった方式が取れます。 aws.amazon.com aws.amazon.com SAP純正の方法としてはSAP Solution Manager（Solman）というサーバをセットアップして、パフォーマンス診断や監視を行うこともできます。 その他にもSolmanは多岐にわたる機能があるようですが、試験においては「監視系のツール」という理解で問題ないのではないかと思います。
次にバックアップです。試験上、重要なのがAWS Backint Agent for SAP HANAというHANA用のバックアップエージェントです。 HANAのデータバックアップをS3に取得してくれます。 その他には、ほとんどのコンポーネントがEC2なのでEBSスナップショットでのバックアップも可能です。 ただし、その際はデータベースを「バックアップモード」にするか、スナップショット取得前にデータベースをシャットダウンすることが求められる点に注意が必要です。
また、AWSで運用する環境をSAPが正式にサポートするには次のような制約があります。
- CloudWatchの詳細モニタリングを有効化する
- AWS Data Provider for SAPをSAPインスタンスに導入する
- SAProuterを配置し、SAP OSSからのアクセスを許可する
- AWS サポートをビジネス以上にする
AWS Data Provider for SAPとは、EC2のOSパフォーマンス情報を収集しSAPアプリへ連携するエージェントです。
EC2およびCloudWatch（monitering）のエンドポイント、およびEC2 Instance Metadataからパフォーマンス情報を収集しています。
本試験では「SAPでパフォーマンス情報が取れないのはなぜ？」という設問に対して、Data Providerがインストールされていない、エンドポイントへのIAMポリシーが付与されていない、などの回答に繋がります。
（出典）General SAP Guides
SAProuterとは、SAP OSS（＝SAP Online Service Sytstemの略称。SAPサポートの意）がユーザのSAP環境に接続するための入り口となるサーバです。 パブリックサブネットにEC2を配置し、Elastic IPを関連付けてインターネットに公開します。 この時、セキュアネットワーク通信（SNC）というプロトコルで暗号化・認証して通信します。 Direct ConnectやSite-to-Site VPNでオンプレ環境と接続されているなら、オンプレ環境側にSAProuterを用意することもできます。
また、試験ではライセンスキーに関する出題もあった記憶があります。 SAPシステムは、SAP社とライセンス契約をしてから使用します。 そのライセンスに紐づく形で、SAPインスタンス用のライセンスキーを取得してSAPインスタンスにキーを投入するのですが、このライセンスキーはEC2内部文書（≒メタデータ）に紐づくハードウェアキーを元に生成されます。 従って、AMIからインスタンス復元するとメタデータが変わるため、ハードウェアキーとライセンスキーの再取得・投入が必要です。 一方でメタデータが変わらないディスク拡張などではその対応は不要です。
これでAWS上でSAPシステムを運用するための構成が出来上がりました。
移行
試験ではゼロからSAP on AWS環境を構築するというよりも、オンプレミス環境からAWSへの移行というケースを想定した出題が多いです。 そこで最後に、SAPシステムの移行方式をまとめます。
SAPでは「システムコピー」というSAPシステムを複製するという概念があり、システムコピーでAWS上にオンプレ環境の複製を作り、運用を切り替えることで移行を実現します。 移行元・先のOS・DBの違いによって次の2種類に分かれます。
| 種類 | OS | DB | SAPバージョン |
|---|---|---|---|
| 同機種システムコピー | 同じ | 同じ | 同じ |
| 異機種システムコピー | 異なる | 異なる | 同じ |
システムコピーによる移行で中心となるSAPツールが2つあります。
- Software Provisioning Manager（SWPM）：SAPソフトウェアを導入するツール。
- Software Update Manager（SUM）：SAPソフトウェアをアップデートするツール。
・同機種システムコピー（Homogeneous System Copy）
- システム移行（SWPM Export / Import；R3COPY）
システム移行にはSWPMのExport /Imortが使えます。 オンプレSAP環境からSWPM ExportしたシステムファイルをR3COPYという手法でAWSに移送しImportすると、EC2上に環境を複製できます。
- データ移行（Backup / Restore or レプリケーション）
データ移行には、データベースのBackup / Restoreを行うのが最も簡易な方法です。 移行元・先のデータベースが同一のため、SAP HSR等を使ってデータレプリケーションすることで移行時のダウンタイムを短時間にするという手法もあり得ます。
- システム&データ移行（AWS MGN / SMS）
同機種システムコピーなら、AWS MGNを使ってOSごとブロックレベルで同期してしまう、という手法もあります。
類似サービスとしてAWS SMSもありましたが、2022年3月にサービス停止しました。
しかし、なぜか本試験ではまだSMSが出題されることがあり「エージェントレスで同機種システムコピーしたい」という時にAWS SMSが回答となることがあるようです。
AWS MGNについては過去にブログにまとめたことがありますので、そちらもご参照ください。
frontse.hatenablog.jp
・異機種システムコピー（Heterogeneous System Copy）
- システム移行（SWPM Export / Import；R3Load）
同機種システムコピーと同様、SWPM Export / Importを使うのですが、R3Loadという手法を使うことで移行元・先の環境差異を考慮したシステム移行を行うことが出来ます。
- データ移行（SUM DMO with System Mobe）
SUMにはData Migration Option（DMO）という機能があり、データベースの差異を吸収したデータ同期を実施してくれます。 例えばAnyDBからSAP HANAへの移行を行う場合、あらかじめAWS Launch WizardでSAP HANAのEC2インスタンスを構築しておき、SUM DMOを使ってデータ同期することで移行を実現します。
まとめ
長文となりましたが、試験範囲を一通り整理していきました。
SAPの基本アーキテクチャから入り、サーバサイド・フロントサイド・運用のAWS実装を具体化し、最後は移行手法という流れでまとめましたが、SAP on AWSという試験範囲をなんとなく体系的に捉えることが出来るようになったのではないでしょうか？
そうなれば知識を深める土台が出来上がっていますので、冒頭に紹介したブログや技術文書を読んでも意味が理解できるはずです。
個人的にはこれでAWS認定全12冠を達成し、2023年もAWS All Certifications Engineerとしてエントリーする条件を満たせたので一安心しています。
