AWSとSAP BTPの接続構成
目次
はじめに
SAP Business Technology Platform(BTP)とオンプレミス環境、AWS環境を接続する構成検討を行ったため、備忘として記録します。
SAP BTPとは、SAP社のクラウドアプリケーション開発基盤のようなもので、S/4HANA等のSAPの業務アプリケーションの標準機能以外の機能開発を行えるプラットフォームです。SAP社と契約すると主要なハイパースケーラーを選択して利用できます。
参考：SAP Business Technology Platform (BTP) のインフラ概要 - Qiita
AWSでは、資格試験としてSAP on AWS(PAS-C01)を新たに用意する程、SAPをAWSで利用するビジネスが昨今伸びており、本記事でご紹介する構成もそういったビジネスのためのソリューション検討の一つとなります。
SAP Cloud Connectorの構成
SAP BTPはクラウドサービスとして提供されているため、例えばBTP上にアプリケーションを開発してオンプレミスのシステムと通信をしようとすると、通信がインターネットに出ることになります。仮にBTPのプラットフォームにAWSを選んだとしても、オンプレミスからBTPまで直接Direct Connectを敷設したり、Site-to-Site VPNを張ることはできません。 また、SAP PrivareLinkサービスというものも開発されているようで、AzureはGAしているようですが、AWS用のサービスはまだ開発中とのことです。
SAP Private Link Service (BETA) is Available | SAP Blogs
この条件下で、BTPからオンプレミス環境にプライベート接続が必要であるとの要件がある場合、オンプレ側の環境にSAP Cloud Connector(SCC)を構築して、リバースプロキシの代替として永続的なTLSトンネルをBTPと構成する必要があります。
今回は、オンプレからAWSまではDirect Connectの閉域網で地続きになっており、AWS上でSCCを構成してBTPと接続する構成を検討します。
SCCの冗長構成
SCCは製品機能でマスタ/シャドウのHA構成を取ることが出来るようです。AWSのブログではシングル構成でオートスケーリンググループの自動復旧の選択肢も提示されていますが、HA構成で待ち受けている方が障害発生時の切り替え時間が早そうな気がする、かつベンダーサポートが得られるマスタ/シャドウ構成とします。
How to connect SAP solutions running on AWS with AWS accounts and services | AWS for SAP
The SAP Cloud Connector offers a software-based HA implementation to protect against failures, or you implement the connector in an Amazon EC2 autoscaling group
SCCの災害対策
前述のマスタ/シャドウ構成はあくまで近距離間のHAソリューションであり、リージョンを跨いだDR構成用ではないと理解しました。
SAPのブログにもSCCはロケーションごとにデプロイしてLocation IDを持たせるとあるので、SCCの災対構成を考えるのであれば、例えば東京リージョンでマルチAZでマスタ/シャドウを構成し、大阪リージョンにもマルチAZでマスタ/シャドウを構成して、それぞれに異なるロケーションIDを持たせるのが良さそうです。災害発生でSCCを稼働しているメインリージョンがダウンした時は、BTP上のアプリケーション側から災対環境SCCのロケーションIDを指定して通信を行うようです。
How to crash your iflows and watch them failover beautifully | SAP Blogs
Connecting multiple Cloud Connectors to an account in SAP Cloud Platform | SAP Blogs
なお、SAPのドキュメントに気になる記載があり、シャドウインスタンスはメインインスタンスと同じネットワークセグメント上に配置するよう記載があります。AZが分かれれば当然サブネットは異なりますので、同じネットワークセグメント上にはなりません。HA構成を組むのにマルチAZで組めない=ゾーン障害に対応できないという古めかしい仕様が現在も有効なものでしょうか？
記憶が定かではありませんが、Db2のクラスター構成を組む際もTSAの仕様が古く、ネットワークセグメントを跨いだクラスター構成では切り替えをサポートしないという記述がありました。オンプレミスを前提に設計されているミドルウェアのクラスター機能はマルチAZと相性が悪いのかもしれません。
マルチAZの話は一度置くとして、これでSCCの災対構成が出来ました。ただし、SCCの災対構成を考えるのであれば、本質的にはAWSの災対構成だけではなく、オンプレミスのデータセンターの災対構成やBTPの災対構成も検討しなければ、完全な業務継続は出来ません。
なお、BTPの災対構成はマルチデータセンタの設定で自動フェールオーバーの構成を行えるようです。
マルチデータセンタの設定を使用し、自動フェイルオーバーを実装することで、データセンタが停止した場合のアプリケーションの高可用性を確実にします。
アプリケーションを 2 つのデータセンタに並列にデプロイし、問題が発生した場合に相互に切り替えることができるようにします。
SCCの拡張性
SCCの拡張性を考えてみます。SCCはスケールアウトが出来る製品ではないようなので、基本的にはスケールアップが前提になります。ただし、複数SCCをデプロイし、それぞれに異なるロケーションIDを指定してBTP側から接続を分散すれば、疑似的なロードバランスは出来るとのこと。災対構成との関係もあるので、無理にスケールアウトを考えず、スケールアップ前提の構成が良さそうです。
これまでのところ、水平スケールを直接実行することはできません。ただし、関連するすべてのサブアカウントについて異なるロケーション ID を使用して複数の Cloud コネクタ インストールを操作することにより、負荷を静的に分散できます。
SCCのサイジング
SCCをインストールするインスタンスサイズについては、SAPのドキュメントにガイドがあるため、こちらを参照すれば間違いありません。
SCCを導入するOS選定
SAPのガイドで製品出荷マトリクスが公開されているため、この中から検討しましょう。
ここまでの検討を構成図に起こしたものが以下になります。ただし、マスタ/シャドウ構成をマルチAZで組めるかは未確認です。
BTPに向けたオンプレミスからの接続
SCCを構成することで、BTPからオンプレミス向けの通信については解決しました。しかし、ここに落とし穴がありますが、SCCはあくまでBTPからオンプレミス環境へHTTP(S), RFC, TCPで通信するものであるということです。
オンプレミスのシステムからBTPのアプリケーションに向けて接続する場合は、SCCのサービスチャネルを使用して限られた通信のみ可能です。それ以外の接続は別の仕組みで通信する必要があります。
Direct ConnectのパブリックVIFで接続
オンプレミスのシステムからBTPのアプリケーションに向けて接続するベストな構成は、Direct ConnectのパブリックVIFを使用することでしょう。例えば、SAP BTPでAPI Gatewayを開発したとして、オンプレミスのシステムがBTP上のAPI Gatewayを介して他のシステムとやり取りする場合は、この構成が必要です。
AWSで稼働するSAPソリューションをAWSアカウントおよびサービスと接続する方法 | Amazon Web Services ブログ
BTPサービスに接続するには、インターネット経由でパブリックエンドポイントにアクセスできます。より安定したネットワーク環境を必要とする場合は、AWS Direct Connectを使用してBTPプラットフォームに接続することもできます。ただし、このユーズケースでは、AWS Direct ConnectはオンプレミスネットワークとパブリックなAWSエンドポイントの間で接続を確立する必要があります。
Accessing SAP Cloud Platform via AWS Direct Connect | SAP Blogs
リバースプロキシでの接続
通常であれば、Direct ConnectのPublic VIFで接続すれば、オンプレミスからBTPへの閉じられた接続を行うことが出来ます。ただし、オンプレミスのルーターからPublic VIFへの通信をNAPTする上でNAPTのポート上限(65535)があるため、大量の通信(ポート)が発生するシステムではこの方法を選択できないことがあります。(オンプレミスのルーター側で1:Nではなく、N:NのNAPTができればポート上限を気にする必要はなくなりますが、オンプレミスルーターの拡張性に課題がある場合を想定しています。)
AWS Direct Connect パブリック VIF を使用して、プライベートネットワークを AWS パブリックサービスに接続する | AWS re:Post
その場合、代替案として取り得る選択肢は少ないですが、SCCを構成しているAWS環境に、オンプレミスからBTPまでのリバースプロキシを構成すれば、オンプレミス->Direct Connect->AWSまでの閉じられた通信を作ることはできます。
もっとも、結局その先はAWSからBTPまでインターネットでの通信になるため、システム要件としてインターネットに通信が出ない事、という要件があった場合は満たせません。インターネットに通信が出ない事、ではなく物理的な閉域網を使用すること、という意味であれば、AWSはAWSのサービス間での通信は、例えパブリックIPアドレスを使用するものであってもAWSのプライベートネットワークに閉じると説明しているため、BTPの実行環境にAWSを選択して、リバースプロキシもAWSにデプロイすれば、通信はAWSの閉域網に閉じていると言えます。
Q:2 つのインスタンスがパブリック IP アドレスを使用して通信する場合、またはインスタンスがパブリックな AWS のサービスエンドポイントと通信する場合、トラフィックはインターネットを経由しますか?
いいえ。パブリック IP アドレスを使用する場合、AWS でホストされているインスタンスとサービス間のすべての通信は AWS のプライベートネットワークを使用します。AWS ネットワークから発信され、AWS ネットワーク上の送信先を持つパケットは、AWS 中国リージョンとの間のトラフィックを除いて、AWS グローバルネットワークにとどまります。
なお、先述したSAP PrivateLinkサービスですが、これはあくまでBTPからオンプレミス向けの通信の話であり、通常のPrivateLinkのようにオンプレミスからBTP向けの通信を受けられるわけではないようなので、用途が異なります。
まとめ
本記事では、オンプレミス環境/AWSとSAP BTP環境のFrom/Toの接続についてどのような構成が実現できるか説明しました。昨今伸びているSAP on AWSのビジネスで検討されることがあるSAP BTP環境との接続について、要点をまとめることが出来たと思います。SCCのマルチAZ構成の箇所については内容の正確性の保証は出来ませんが、どなたかの参考になれば幸いです。
