PaaSとkubernetesについて

今、PaaSが熱い。いや、kubernatesが熱い。
先日、MicrosoftがDeisを買収したというNewsが出た。
Cloud FoundryとKubernetesを統合運用する新プロジェクトKuboを立ち上げ も進んでいるようだ。
先日のkubernetes meetupは200人枠が一瞬で埋まってた。 
もうこのムーブメントに乗っかるしかない！ということで、PaaSとKubernetesについて述べたいと思う。

PaaSの定義と種類

PaaSはよく定義が曖昧だといわれるが実はシンプルである。
それは、アプリケーションとデータ以外のすべての部分、つまり「アプリケーションの実行環境プラットフォームを提供するサービス」をPaaSという。
PaaSを利用することでアプリ開発者はプラットフォームのことを考える必要はなくなりアプリ開発に専念することができるようになる。
もちろん、プラットフォームにはアプリケーションライフサイクルの他に、可用性やオートスケールといった機能もあり、これにより開発者はサービス運用後の障害や負荷さえも気にしなくてよくなる。
IaaSが提供するのはIT資産の仮想化環境までで、その目的がインフラ調達の最適化であったのに対し、PaaSははさらにアプリの実行環境管理もお任せできることがポイントだ。

PaaSを推すベンダーの製品は様々であるが、大きく分けて、以下の４つに分類されると思う。制約事項が少ない順に、

　1.単に自社ソフトウェアを組み合わせたもの(Oracle Cloud Platform as a Service等)
　2.コンテナベースのOpenPaaS(Cloudfoundry)やKubernetes(OpenShift等やGKE)
　3.プロプライエタリなサービスを組み合わせるもの(GAE、Elastic Beans Talk等)
　4.SaaSをベースとするPaaS(Force.comやkintoneなど)

Google AppEngineやElastic Beans Talkといった初期のプロプライエタリなPaaSは失敗に終わったといっても過言ではない。 
私自身、GAEに入れ込んでいた一人であったので、そろそろ何がダメだったのか総括してみたいと思っている。 

原因については、PaaSに何が起きているのか? で、Mike Kavis氏が指摘しているように、 「不明確なマーケティングメッセージ」、「成熟度の欠如 」、「制限事項 」の３つが考えられる。 
私は特に「制限事項」が導入を遅らせてしまった最大の原因だったように思う。

1.の自社ソフトウェアを組み合わせたものは開発の自由度は大きいかもしれないが開発者への負担が大きい。 単なる組み合わせは「成熟度の欠如 」の裏返しであり、「不明確なマーケティングメッセージ」そのものだ。
一方で、4.のSaaSをベースとするPaaSは、「EXCEL以上社内システム未満」といわれているように、ちょっとしたツールを作るには便利かもしれないが自由度に乏しい。 
3.のプロプライエタリなサービスは、SaaSよりは自由度はあるものの、正しく機能させるにはそのサービスの限界を十分に理解した上で作らないといけないというハードルの高さがあり、なかには制限を超えられないものもある。 

また、これらに共通していえるのはベンダー依存でありロックインに陥りやすいということだ。 ただし、SaaSに限っては必ずしも「ロックインに陥りやすい」がイコール「流行らない」というわけではないようである。 
それは、ベンダーロックインを承知で使っている利用者が多いと思われるからだ。 すぐに使えるパッケージがあり、利用者に直接セリングしてアプローチする。スクラッチでシステム開発するよりはSaaSで十分と考える顧客も多いと思われるのだ。 ・・ 成功のヒントはSaaSにある 
しかし、PaaSに関していえば、制限やベンダーロックインがあるのは致命的である。
それはこれまでの歴史が証明している。 

プロプライエタリなPaaSは「悪魔は細部に宿る」という言葉がピッタリあてはまる。
全体としてはよさそうに見えても、事を進めていくと細部で支障がおこり、物事が進まなくなるのだ。 
使いたいフレームワークやライブラリがなく、例えあったとしてもバージョンの不整合で泣かされる。 新しいバージョン対応はベンダー任せになって、いつ使えるようになるかわからない。 いざ、業務アプリを構築しようとすると様々な問題が発生するのは当然の結果だった。 
私たちの経験でいえば、GAEでコストを劇的に下げることは可能になったものの、ユーザビリティが低下してしまい、すべての機能をGAEに載せるのを諦めざるを得ないことが多かった。 
例えば、この事例では、クラウドとオンプレミスの融合と紹介しているが、本当はクラウド(GAE)だけで実現したかったものだ。 
お客様にいわれてドキっとした言葉がある。 「システムダウンはゼロでスケールもする。技術者も大変優秀で満足。しかし、特殊な技術にロックインされていて一般的な他の技術者が入り込む余地がない。」 

このような話を「テクノロジードリブンの失敗例」として紹介している人もいる。

「しかも正式リリースでGAEが値上げ。他への移行を検討するも断念。サービス継続不能に。」 ・・アジャイル開発を成功に導くPaaS基盤

これまでタダ同然で使えていたのが値上げされればそりゃユーザも離れていくのが当然である。 しかし、それ以上にショックだったのは値下げはあっても値上げはないと硬く信じていたクラウドへの信頼が裏切られたからだ。 ましてロックインされたあげく（値上げで）茹でられる恐怖は正直嫌なものだ。一度味わうと二度とお近づきにはなりたくないと思う。 

いや、実は今でもGAEはPaaSインフラとしては究極の理想の形だと思ってはいる。 あまりに便利すぎて、サーバインフラのことを全く考えなくてよい時期があって、技術者として駄目になりそうな錯覚(褒め言葉)を覚えたのも、GAEの完成度が素晴らしかったからだと思う。
しかし、制約とロックインはそれをも覆い隠して余りあるダメダメな欠点であることは強調しておこう。 ※
GAEブームで盛り上がっていたときは「あばたもえくぼ」で見えなかった欠点が、時が経って冷静になると許しがたい欠点としてはっきり見えるようになったということだ。 

※ これは実はBaaS(Firebaseや弊社のvte.cx)にも言える事！

幻滅期を乗り越えたPaaS

 ところが、「アンチベンダーロックイン」というスローガンのもと、制約とロックインの難題を解決するコンテナベースのPaaS(OpenPaaS)が現れ、次第に世の中に受け入れられるようになってきた。 
Herokuのようなコンテナベース(※1)のPaaSが一定の支持を得るようになり、HerokuのBuildpack(※2)と互換があるCloudfoundry(※1)はオンプレミスとパブリックの両面を見据えたPaaS基盤としてエンタープライズ領域に浸透しつつある。 
パブリックではIBM Bluemix、富士通K5、NTT cloudnなどが基盤として採用、オンプレミスではyahooなどでも導入が進んでいくようになった。

 (※1) CloudfoundryはWardenという独自のコンテナ機構、HelokuはLXC、kubernatesはDocker。いずれもLinuxのcgroupsやnamespaceという機能を活用している。
 (※2) Herokuによって作られた、任意の言語やフレームワークを扱えるようにする仕組み

OSSの世界を見てみると、Cloud Foundryでは「BuildPack」と呼ぶパッケージを用意しており、Herokuとの互換性を確保しています。恐らくPaaSの世界では究極的には、どのPaaSを利用しようがベンダーロックインされることなく、アプリケーションの完全な可搬性が実現されるでしょう。まだまだ課題は多いですし、アプリケーションの独立性を保つことは、ベンダーからすれば大きなジレンマではあります。 つまり、アプリケーションの可搬性が確立されたときに、PaaSの世界が固まるのです。Azureを選ぶこととオラクルを選ぶことが、従来のLinuxを選ぶのかWindowsを選ぶのかという議論にならない世界が訪れるということです。・・【座談会】主要ベンダーのPaaS戦略と普及の条件

また、先行するCloudfoundryに対して、コンテナの本命、Dockerをベースとするkubernetesと、それを取り入れたOpenShiftやDeisなどのOpenPaaS群が対峙する形で大きく盛り上がってきている。 

ハイプの時期を乗り越えた2014年にPaaSが成熟して、確固たる提案として十分な信頼性を備えることで企業に受け入れられ、成功への道へと進むことができる」・・PaaSに何が起きているのか？ - InfoQ

2017年の今は、Cloudfoundryの実績と信頼性、kubernetesの盛り上がりによってPaaSの幻滅期はすでに過ぎていると見ている。 それはDeisを買収したMicrosoftの本気度にも伺い知ることができる。 今後は特に、実質的にデファクトとなったkubernetesを中心にPaaSの世界が普及していくと思われる。

コンテナ技術が重要である理由

コンテナ技術が多くの技術者に受け入れられているのは主に以下の３つの理由による。 

 ・可搬性がありベンダーロックインになりにくい 
 ・制約が少なく柔軟性がある(IaaSと同程度の自由がある) 
 ・これまでの延長線上の技術で構築でき敷居が低い 

コンテナはリソースをコントロールしながら異なる実行環境をアプリに提供でき、セキュリティを担保しつつアプリ同士を隔離出来る。また、イメージ化により可搬性も優れている。
そもそも、日本企業には自由度の高いPaaSが合ってあっていると思われるが、前述したように、SaaSやプロプライエタリなものでは制約が大きすぎて要求をクリアできなかった経緯がある。 

日本企業は、独自の文化や組織を形成しており、SAP導入のカスタマイズに代表されるように企業の独自ニーズは強い。企業の進化に合わせてシステムを変化させる必要もあり、SaaSでは要求をクリアできない。既存システムをPaaS化することでミドルウェアの運用コストを落とすことができ非常に効率的にスリムアップが可能となる。・・アジャイルを成功に導くPaaS基盤

また、PaaSはSaaSからのトップダウンやプロプライエタリなサービスによる破壊的進化ではなく、IaaSからのボトムアップによって、これまでの技術やノウハウの延長線上でなければ企業のエンジニアはついてこれない。 

さらに、コンテナを使うメリットとして、素早く立ち上げることがきるという点が挙げられる。 例えば、閾値を設定してオートスケールする仕組みを作る場合、VMでやろうとすると数分かかるのに対し、コンテナなら数秒で立ち上がる。 
これはAWSのIaaSでcloudwatchとか駆使してスケールアウトしていた時代と比べると隔世の感がある。

クラウドには必須のアクセス急増（スパイク）に対応できるよう、アプリケーションのインスタンス（実体）を1つから300にまで増やすのに30秒程度しか要しないという。VM（Virtua Machine：仮想マシン）に比べてはるかに軽量なコンテナ技術を使ってアプリケーションを稼働させるからだ。 「VMwareはHA（高可用性）構成の時、リカバリーに要する時間は2分です。これがCloudFoundryでは2秒で完了します。短時間なのでHTTPリクエストはフェイルしません」（Watters氏） 

あるいは、利用状況を見ながらリソースを調達できるようにしたり、自動化ツールを組み合わせて開発環境やテスト環境を素早く構築したり、CI/CDを組み合わせて継続的に開発/デリバリーすることにもコンテナは向いている。今流行りのDevOpsというやつだ。 

一方で、否定的な意見があるのも知っている。・・Dockerの本番運用 や、・・dockerやめてどうしたか？
これはもう、時間が解決するとしかいえない。かつて、windowsやLinuxのエンタープライズでの本番運用は、それは酷い言われ方をした時代もあったのだから。 

一つだけいえるのは、DockerやKubernetesは実質的にデファクトとなったということ。 OpenPaaSといわれるプロダクトはほとんどがKubernetesベースであり、Cloudfoundryでさえ、DiegoにおいてDockerイメージ対応をしている。 

また、基盤ソフトウェアで重要なのは持続可能かどうか、言い換えればOSSコミュニティを含めたエコシステムが成立しているかどうかだ。 
私には、DockerやKubernetesが、かつてのLinuxのように王道を歩んでいるように見える。

Twelve-Factor App

CloudfoundryやOpenshiftなどのコンテナ型のPaaSがどれも似た感じになっている。 

例えば、gitやCLIツールからデプロイができ、DockerfileやBuildpackのような複数言語を扱う仕組みが使えて、コマンド一発で起動・停止・スケールアウトができ、リクエストルータもあってマルチホストに展開ができる。・・ひしめき合うOpen PaaSを徹底解剖！ PaaSの今と未来

これは偶然ではなく、スケールするWebアプリケーションのベストプラクティス、12 Factor appがあるからである。

12 Factor appの考え方は極めてシンプルで優れている。 
どのPaaSも、12 Factor appを前提に作り込んでいくと、結果としてどれも使い勝手が似たようなものとなるわけだ。 また、12 factor appを前提に作られたアプリのことを、クラウドネイティブなアプリケーションと呼ぶらしい。 

「CloudFoundry」の開発を主導する米PivotalのJames Watters副社長は、こう言い切る。

 アプリケーションから見ればPaaSはOSそのもの。つまりPaaSはクラウドOSです

12 factor appはPaaSにアプリを載せるための制約といえなくもないが、普通にスケーラビリティや可用性を追求していくと同じような制約は出てくるはずで、企業のアプリケーションが超えられないものではないように思う。 

私たちもまた、ReflexWorksをkubernetesに載せ、クラウドネーティブ化をまさに行っている最中である。