って思ってないですか？
（※ この記事はchillSAP 夏の自由研究2020の8月28日分の記事として執筆しています）
はじめに
みなさん、SAP Cloud Platform(SCP)での開発生活楽しんでいますか？
SCPって本当に快適ですよね。どんどんとサービスが増えていって、ますます便利になりそうです。
でも快適過ぎるあまり、サービスが増えるあまり、中身をよく知らないまま使い方だけ覚えてしまって
こんな状態↓になっていることってよくあるんじゃないでしょうか。
非常に恐ろしい様である。
得体の知れないサービスを利用し続けているものの、とりあえずアプリが動いてるからヨシ！
そもそもなんでアプリが動いているのか、よくわからんけどヨシ！
事実私は思い返してみたらSCPに浸ってはいるものの、知らないことだらけでした。
Cloud Foundryってそもそもなんだっけ、なんか新しくKubernetesとかServerlessとかリリースされてるって
聞くけどなんだっけ、おいしいんだっけ。。
ある意味でSAPによってラップされる前の素の技術の部分をよく知らなくても利用できてしまうところが
SCPの利点でもあったりするのですが、今回は現場で大事故を起こさないためにも、
改めてあえて普段アプリと直接関係はない、基礎の基礎であるインフラ技術周りについて整理してみました。
※本当はKubernetes(Kyma)のSCP上でのハンズオンも含めたかったのですが、
残念ながらTrial版がリリースされるのはまだ先の話になりそうなので今回は見送りました。。
とはいえ何から始めよう
思い切ってインフラだ！と言ってみたものの何から始めればよいのか？
ひとまずSCPのインフラって何があるんだろうと調べ始めると1つのBlogにたどり着きました。
Now available – The SAP Cloud Platform Extension Factory
ここでExtension Factoryなるキーワードに着目してみました。
なんと既に2018年のTechEdで発表されていたそう。
記事の中にはExtension Factoryを説明した図がありました。
なるほどわからん。
一つずつ解説していきます。
SAP Extension Factoryの中身
説明を分かりやすくするためにあえて図の下部分から解説します。
ABAP環境について
今回の話の主役ではないのですが、まずはABAPランタイムについて触れます。
これは名前の通りで、ABAPコードを実行可能なクラウド環境です。
既存のオンプレABAPのアドオンをそのまま移行して実行できるわけではなく、
この環境では新しくRestful ABAP Programming Model(RAP)というフレームワークが採用されているため、
その形に合わせることでABAPを実行可能となります。
ただしS/4HANA1909からはS/4HANA上でもRAPをサポートしています。
そして今回の話と関連する中での大事なポイントとしては、このABAP環境はCloud Foundry環境の上で実行されているわけではなく
あくまで単に仮想マシン上にABAP実行環境が構築されて動いているという点です。
https://www.slideshare.net/SusumuHonna/abap-abap-restful-application-programming-model
実際使用する時にはSCPのCloud Foundry内のサービスを有効化して使っているのですが
厳密にはCloud Foundryとは関係のないものとなっています。
https://blogs.sap.com/2019/09/28/its-trialtime-for-abap-in-sap-cloud-platform/
Cloud Foundry"環境"のおさらい
さてここからが本題です。
まず、今回のExtension Factoryで取り扱っているのはSCPのCloud Foundry環境が対象です。
Cloud Foundry環境は、それよりも以前からあったNeo環境に続いて登場したSCPの環境です。
Neo環境はSAPが管理するクラウド上に構築されていたのに対し、Cloud Foundry環境ではAWS、Azure、GCPといったパブリッククラウドの上にIaaSを構築できるのが大きな特徴です。
SCPの画面では、Cockpitから2つの環境の入り口があることが分かります。
Extension Factoryの図にも確かにそうしたパブリッククラウドの名前が見られます。
しかし図を見るとその上には4つのランタイムが乗っているではありませんか！
なぜ4つもあるのか？？
1つずつ、まずは見慣れたCloud Foundry(CF)から解説していきます。
Cloud Foundry"ランタイム"のおさらい
Cloud Foundryとはそもそも何者か？というところから振り返りましょう。
Cloud FoundryはVMWareによって最初に開発され、現在はOSSとして存在しているPaaSサービスです。
何がありがたいサービスなのかといえば、コンテナアプリケーションのランタイムとして存在するだけではなく、
アプリの運用、モニタリングやロギング、バックアップやリストアの仕組みを自前で構築しなくても
マネージドサービスを利用できるところにあります。
ちなみに少し脱線しますがそもそもコンテナとは何が嬉しいのか？
https://vmware-juku.jp/whatsvm/containers-benefits-why-kubernetes/2/
従来の仮想マシン技術がH/WからOSを分離していたのに対して、コンテナ技術はOSからアプリの分離を可能にしています。
こうすることで、アプリケーションがOSの影響を直接受けない為、環境を移してもアプリケーションを実行できたり環境構築の手間を大幅に省けたりするのでした。
Cloud Foundryはコンテナアプリケーションのランタイムなので、当然こんな恩恵も受けています。
Cloud Foundryの深堀り
Cloud Foundryの基本が振り返れたところで、もう少し深掘していきます。
Cloud Foundryの開発を行っているVMWareのサイトを見ると、
実はランタイムとしてのCloud Foundryとは複数あることが分かります！
Achieving Escape Velocity with Pivotal Cloud Foundry 2.0
ここで並べられているPAS,PKS,PFSはそれぞれランタイムです。
実はみんなが一般的にCloud Foundryと呼んでいるものはPASという、
Cloud Foundryの中でもコンテナを実行するランタイムの一種であったことが分かります。
その横に並んでいるPKSはKubernetesクラスタを動的にプロビジョニング、実行可能なランタイムです。
PFSはServerlessのランタイムとなっています。
その下にあるBOSHというのは、Cloud FoudryのOSを担っているものだと思ってください。
これが存在することで、Cloud FoundryではサーバのOSを気にすることなくアプリケーションを実行可能となっているのです。
そして再び注目すべきは図の右側、Marketplaceです。
ここにCloud FoundryからKubernetes、Serverlessへ続いていくヒントがありました。
Service Brokerについて
SCPで開発を行っていると必ず利用するであろう、Service Instanceの作成。
HANA DBやDestination、ロギング(Kibana)などのService Instanceのプロビジョニングや作成を
Cloud Foundryにお任せできる仕組みです。
画面のマウスクリック、あるいはcf create-serviceコマンドですぐに作成でき、
cf bind-serviceコマンドであっという間にアプリケーションの環境変数に埋め込みが行われ、疎通できる大変便利な機能です。
この機能、実はCloud FoundryのService Brokerという技術によって成り立っているものだったのです！
(SAPの技術だと思い込んでいました。。)
ただ、このService Brokerってとても便利なのですが、
当然Marketplaceに公開されたService Instanceしか作成、バインドすることができません。
例えばHANA以外の特定のDBを使いたかったり、CI/CDツールを使いたい、といった要件があったとしても
Marketplaceに存在しなければ当然使えないのです。
となれば、コンテナを立ててその中に無理やりサービスイメージをビルドするしか。。なかったのがここまででした!
実はこの素晴らしい機能、Service Brokerを外部サービスでも利用可能にしたのがOpen Service Brokerです。
Kubernetesとは？
Service Brokerの仕組みはとても便利だったので、Cloud Foundryだけに閉じるのはもったいない！
ということで他のPlatform(つまりKubernetes)でも使えるように仕様を整理した結果、
Open Service Broker APIという仕様ができました。
Service BrokerではCloud FoundryのMarketplaceで公開されているサービスしか利用できなかったのに対して、
Open Service BrokerではKubernetes経由でAWSやAzureで公開されているサービスを利用することができます。
これだけでも、これまでSCPを利用してきた人間からすると利用シーンがかなり広がりそうであることは想像できるかと思います。
AWS Service Broker
ここでそもそもKubernetesとは何者なのかといったところをおさらいしましょう。
コンテナの説明は先程述べた通りですが、実はコンテナ(Docker)の仕組みだけでは
コンテナの配置戦略(オーケストレーション)、ビジネス状況に合わせたコンテナスケーリングなどにおいて課題を抱えています。
SCPのCloud Foundry環境ではそのコンテナオーケストレーションにMulti Target Application(MTA)という仕組みを取ることで
対処していますが、OSSの世界では解決策としてKubernetesという技術がコンテナ運用全般のデファクトスタンダードとなっています。
KubernetesはGoogleによって開発された、コンテナの運用を自動化するための仕組み(コンテナオーケストレーションシステム)です。
https://enterprisezine.jp/article/detail/11024
SCPにおけるKubernetes
Kubernetesの登場によって、コンテナはビジネス状況に合わせた自動スケーリングなどの細かな設定を可能としています。
大きな特徴としては他にも、コンテナを無停止で切り替えることが可能であったり、
Yamlファイルの設定でCloud Foundryでは制御できなかったロードバランシング、環境別の構成情報、ストレージの管理といった操作が可能となることが上げられます。
こうしたことは全てKubernetesのリソースと呼ばれる1つ1つの機能により実現されているのですが、
SCPのKubernetesにおいては、KymaというOSSのKubernetesのリソースを独自に強化したランタイムを取り入れています。
実はサーバレスランタイムに関しても、Kymaで開発されたKubernetesのリソースを活用することでKubernetes上で動くものとなっています。
ほんのりServerlessについて触れておきますと、通常のアプリサーバが「常駐型プロセス」を実行するインフラだとすれば
サーバーレスは「非常駐型プロセス」をイベントによってトリガして実行するインフラだと思ってください。
Kymaで提供される機能には他にも、SAP製品の移送に合わせたリリース管理を可能にしたり、
S/4HANAとの接続を容易にするための機能などが提供されるようです。
SAP Extension Factoryの正体
再掲ですが、ここまでの説明で一通りExtension Factoryとは何者なのかを解説してきました。
まだ未説明と思われた、Central Management Planeとは実はService Broker、Open Service Brokerのことでした。
これらを使用することでService InstanceのDestination、XSUAAに代表されるようなセキュアな外部サービスとの接続が可能となります。
公式にはExtension Factoryとは、インテリジェントエンタープライズ向けのクラウドに特化した拡張性フレームワークとありますが、
ここまでの説明を使って超噛み砕いて言うならば、要件に合わせて柔軟に環境選択ができて、開発から運用まで抜かりないぜ！といった感じでしょうか。(ざっくり
Cloud FoundryとKubernetesのどちらを使うべきなのか？
要件に合わせて環境選択できる！と言いました。
確かにABAP環境はABAPを動かすためにありますし、Serverless環境も「非常駐型」のマイクロサービスを構築するためにあったりと、
この2つは使用用途が明確かつ限定的なので競合はしないでしょう。
では残りのCloud FoundryとKubernetesはというと、ここまでの説明では明確に用途を区別されていませんでした。
改めて両者の違いを上げてみたいと思います。
https://blogs.sap.com/2018/10/19/cloud-foundry-and-kubernetes-where-do-they-differ-how-do-they-fit-together/
Cloud Foundryではアプリを直接デプロイすると、言語ごとに自動的にランタイムを選択してくれてコンテナ化し、アプリを実行してくれていました。
インフラ部分をほとんど気にすることなく、デプロイと実行を可能とする便利さが魅力の一つです。
一方でKubernetesではアプリのデプロイ前に、アプリをYamlファイルに記述した設定に沿ってコンテナ化するというステップが必要となります。
このYamlの記述に手間がかかったり、細かなインフラ設定の考慮が必要になる面を持っているのが特徴です。
しかし逆に言えば、ロードバランシングやモニタリングといったインフラのソフトウェアを組み込んだり、
H/Wリソース(ベアメタル)に直接アクセスするといった複雑なアプリケーションを実行可能であることも意味しています。
結論: ケースバイケース
以上を踏まえると、確かにCloud Foundryを使用すればKubernetesに比べてアプリを簡単に構築、実行することが可能です。
KubernetesはCloud Foundryよりもアプリの構築と実行において高い柔軟性と制御を可能としているとも捉えられますが、
より多くの労力を必要とするのも事実です。
https://blogs.sap.com/2018/10/19/cloud-foundry-and-kubernetes-where-do-they-differ-how-do-they-fit-together/
ということで世の中の流れがKubernetesに段々傾いているとはいえ、SCPを利用する我々としては
Cloud Foundryの便利さも捨てがたいので現時点ではケースバイケースで利用するしかないのではないかと個人的には思っております。
おわりに
ということで今回はExtension FactoryからSCPの環境のお話でした。
ところでお気づきの方もいるかもしれませんが、Cloud Foundryという単語が記事中に2種類の意味で出てきてしまっています。
1つはNeo環境と対比したSCPの大きな括りとしてのCloud Foundry環境。
もう一つは実際のランタイム(実行環境)としてのCloud Foundry環境(Extension Factoryの図に出てくる方はこちら)。
最早Cloud Foundryという言葉はSCPの環境全体を指すというよりは、単にSCPの中の実行環境の選択肢の1つとしての位置付けになのではないかと感じた。
となると、今の"Cloud Foundry環境"はそのうち別の名前に変わるんだろうか。。ややこしい。。