AWSとSAP Cloud Platform

こんにちは、特派員のI.Mです。

最近やっとAmazon Echo dotが届き、Amazon Music Unlimited(Echoプラン)を使い始めました。
ですが、ライブ音源とかカバー歌手の曲がかかったりしてなかなか思い通りの曲に辿り着けず、家族にガッカリされていたところ、
「プレイリストを使いたまへ」
という天啓を受けまして、それから快適にリビングの音源となっています。

なお、自分で作ったプレイリストの名称は単語を半角スペースで区切ると認識されやすくなっていい気がします。

閑話休題。

今回はPaaSのあり方について思うところを書きます。

ハイブリッドクラウド(パブリッククラウド×オンプレミス)

日本ではまだまだ基幹システムをパブリッククラウドに置く企業は少ないと思います。
基幹システムはオンプレミスやプライベートクラウド、他の業務システムはパブリッククラウドというハイブリッドクラウドという構成は多いでしょう。
この構成で、業務システムと基幹システムを連携させるアーキテクチャに悩むことは多いのではないでしょうか。とくに業務システムから基幹システムのデータ参照は、クラウドからオンプレミス側のファイアーウォールを超えなければなりません。

AWSとSAPのアプローチ

AWSでこの連携を実現するためには、AWS上のVPCへVPN接続を設定する必要があります。
一言で「VPN接続を設定」と言っても、VPC上にVirtual Private Gatewayを作成し、オンプレミスネットワーク上で「カスタマーゲートウェイ」を構成しなければなりません。
AWSのサイト上で、VPCと接続テスト済みのゲートウェイデバイスの一覧を確認できますし、ソフトウェアゲートウェイも利用できますが、ゲートウェイの働くマシンはDMZに配置する必要があります。
アプリケーション開発者が接続環境を構築するには、少しハードルが高いですね。。。

SAP Cloud Platformでは、この課題に対してCloud Connectorというアプリケーションを用意しており、環境構築の手順は簡単です。

  1. 任意のマシン(Windows/Linux)にインストール
  2. Webブラウザでアクセス
  3. 接続対象のSAP Cloud Platformアカウントを設定
  4. 接続状態を保持

Cloud ConnectorをインストールしたマシンはDMZに配置する必要もなく、複数台での冗長構成も可能です。
但し利用できる通信プロトコルには制限※があり、完全なVPNとは言えません。
※HTTP(S)とRFC(=Remote Function Call: 異なるSAPシステム間の標準通信プロトコル)のみ

SAPは公式でこのCloud Connectorを「SAP Cloud Platformのアプリケーション(&サービス)とオンプレミスシステム間のリンクとして機能する」と説明していますが、ここでいう「オンプレミスシステム」とはSAPの基幹システムを中心として構築されているもの、それらが存在すること、それらを活用することを前提としたPaaSを設計していることがよくわかります。

SAP Cloud Platformの代表的ハイブリッドアーキテクチャ

SAPのクラウド事業は、それのみでも利用可能な各種SaaS(Concur:経費清算/SuccessFactors:人材マネジメント/Ariba:部材調達支援/ByDesign:中小企業向けERP/Hybris:eコマースプラットフォーム)と、それらとの親和性が高く、上記のような特徴を持ったPaaSの二段構えです。
(勿論オンプレミスだけでなく、Public/Privateを問わずクラウドにある基幹システムも対象とされています)

対してAWSはクラウド上のVPC間のプライベートネットワーク接続を可能にするPrivateLinkというサービスを提供し、クラウド間(というかAWS内)の連携に不自由しないようになっています。
Cloud Nativeな新しいシステムは、AWS上だけで完結するアーキテクチャを設計しやすく、スタートアップにも優しいですよね。

AWSの代表的アーキテクチャ

料金体系

よく知られているように、AWSの料金体系は「使った分だけ」という従量制です。
AWS上で動くプロセスが消費するリソース量によって料金が変わるので、利用するユーザやトラフィックが少ない場合にはコストも低く、多くなるに比例して必要なコストが大きくなります。

SAP Cloud Platformはクラウド上のリソースの性能、サービス利用ユーザー数、利用できるPaaSの機能などがあらかじめ決められたパッケージでの毎月固定額の課金が発生する形態(Subscription-based)が主流でした。

新たに構築するシステムやサービスについて適正な規模や性能を当初から見通すことは難しく、余裕のある規模で構築することは、よくあったのではないでしょうか。
クラウドの黎明期に、従来の物理的な環境構築と同様に「余裕のある」規模を確保してしまうことで「クラウドは高い」という誤解が生まれたように、SAP Cloud Platformでは最小構成のパッケージであってもイニシャルコストが高いと思われがちなのではないか、と私は常々思っていました。
クラウドの活用について「スモールスタートで始めたい」という企業はまだまだ多いように思われるのですが、SAP Cloud Platformを余すことなく活用するには、利用シーンの拡大など結構ドラスティックなシフトが必要だと言わざるを得ませんでした。

ここまで料金体系について、過去形で述べていることに気づいた方もいらっしゃるかも知れませんが、
実は、(AWSのような、と私はイメージしていますが)「使った分だけ」=従量制(Consumption-based)の料金体系も提供開始※という発表がありました。

※参考:Innovation Accelerated With New Consumption-Based Commercial Model for SAP Cloud Platform
(2018年4月現在、日本では利用不可)

これを機に利用シーン拡大の動きが拡がるといいな、と思っています。