Microsoft Peering つかって SAP アプリケーションに接続してみた

初めに

今回はExpressRouteのMicrosoft Peeringを使った閉域接続の例として、SAPのアプリケーションを試してみました。

実際にSAP社のエンジニアと連携してアット東京の設備を使って接続の確認ができました、という内容です。

Cloud Labを利用したSAPとAzureの連携検証

SAP社はCloud Foundry 環境で使用可能な地域および API エンドポイントに一覧があるとおり、いくつかのPublic CloudでAPIのエンドポイントを提供しています。

日本（東京）という地域ではapi.cf.jp20.hana.ondemand.comというエンドポイントが提供されており、これはAzureCloud.japaneastというサービス タグの範囲の中に入っています。

内部的な構成は把握できる範囲ではありませんが、SAP社としてAzureで共通基盤を作成し、そこに配置されたPublic Load BalancerやApplication GatewayにこのIPアドレスを持つPublic IPがひもづいている、というようなイメージですね。

AzureCloud.japaneastというService Tagに含まれているのであれば、その通信はMicrosoft Peeringを利用してExpressRouteを経由させた閉域接続を実現できます。

今回はその検証環境を実際にCloud Labを利用して構築し、SAP社のエンジニアと連携して確認を行いました。

普段は「部屋」としてのCloud Labを借りるのですが、都合が合わなかったためラックの横の空きスペースをお借りして実施しています。

本来はラックの周辺は写真撮影禁止ではあるのですが、アット東京の方にいくつか写真を撮っていただいたのでここに掲載します。

検証環境

Cloud Labからお借りしたCisco 892を利用して、Private PeeringとMicrosoft Peering、一部の通信にはインターネットを利用するため3種類の接続を構成します。

詳細なconfigは掲示しませんが、基本的にはsubinterfaceを切って、BGPの設定、NATの設定などがメインです。

さらにCisco配下に自分たちのPCを接続するセグメントを切り、私たちやSAP社のエンジニアたちが接続できるようにしてあります。

検証パターンとしては以下のふたつのパターンを実施し、それぞれで問題がなく、意図どおりに通信ができたことを確認しています。

Microsoft Peeringのみを利用した検証

最初のパターンは、SAPのアプリケーション環境がカスタマーサイト配下、つまりCisco 892の配下にあるという想定です。

AzureCloud.japaneastというサービス タグをAzureのルート フィルターで設定しているため、該当する経路はCisco 892が受け取っており、SAPのエンドポイントへはNATしたのちにMicrosoft Peeringを経由して通信させます。

認証等の一部の通信についてはMicrosoft Peeringには含まれていないため、別のIPアドレスでNATしてインターネットへと通信させます。

 Microsoft PeeringとPrivate Peeringを併用した検証

別のパターンとして、SAPのアプリケーション環境をAzure上に構築し、そこからSAPのエンドポイントにアクセスするというパターンも検証しました。

こちらのパターンでは、Azure VNetの中に立てた環境から、一度Private Peeringを経由してCisco 892に接続し、そこからMicrosoft Peeringを経由してSAPのエンドポイントに接続するというパターンです。

Microsoftのドキュメント上で見かけたことはない気がしますが、一部ではクロス アドバタイズ（cross advertise）と呼ばれる方法を利用しており、Microsoft Peeringで受信した経路をCisco 892でPrivate Peering側にも経路広報しています。

これにより、Azure VMの有効なルート（effective route）上でもMicrosoft Peeringで受信した経路が表示されるようになり、それに沿ってAzure VMから該当の宛先の通信が一度Cisco 892に戻ってきてから出ていく、という経路に変わります。

ちなみに、この方法は通信にかかる遅延（latency）の観点から考えるとやや不利に感じられます。

Azure VMでSAPのアプリケーション環境を配置し、今回のようにExpressRouteを利用しなかったとしても、その通信は広い意味でのAzureのネットワーク内で完結しており、セキュリティの観点からも大きな問題はなく、遅延は最小限に抑えられます。

とはいえ、さまざまなご意見からやはり閉域での接続が必要、ということであれば今回検証したような構成が可能です。

また、一部のSAPアプリケーションではPrivate Endpointを利用した接続もサポートされているようなので、こちらもよい選択肢になるかと考えています。

https://help.sap.com/docs/private-link/private-link1/consume-azure-services-in-sap-btp

まとめ

今回はSAP社のエンジニアと連携して、Microsoft Peeringを利用したSAPの閉域接続の検証を行いました。

また、Microsoft Peeringだけでなく、Private Peeringと併用した検証も行い、それぞれについて設計どおりに通信ができることを確認しました。

当社のパートナーと連携した検証は初めてでしたが、このようなコラボレーションをさらに進めていければと思っているので、お気軽に声をかけていただけるとありがたいです。

この記事を書いた人　日本マイクロソフト 酒見

同じカテゴリーの記事