Kubernetes、PaaS、Serverlessのどれを選ぶのか？ 機能比較と使い分けのポイント

4月19日に開催された「Japan Container Days v18.04」カンファレンス。「『コンテナ疲れ』と戦う k8s・PaaS・Serverlessの活用法!」のセッションでは、Pivotalジャパン株式会社 Platform Architectの草間一人氏が、自前のKubernetesプラットフォームとPaaS、Serverlessの比較と使い分けについて解説した。

「コンテナ疲れ」はコンテナ技術の抽象度の低さから

草間氏はまず、コンテナ技術が面白くてわくわくする一方で、辛い面もあるということを取り上げた。具体的には「美しいDockerfileを書いていたら半日が過ぎていた」「イメージサイズが大きくなりすぎて改善するのに2日かかった」「社内にプライベートリポジトリ立てて苦労」「Kubernetesの独自の概念を教えるだけで○週間かかる」……といった例を紹介した。

また、草間氏は「特にコンテナでは次から次へと新しい仕組みが出てきて、それが面白い点であるが、会社でほかの人に教えて普及させるには大変な点でもある」とし、これを「コンテナ疲れ」と呼んだ。さらにその背景として「コンテナ技術は抽象度が低く、エンジニアがカバーしないといけない責任範囲が広い」ことを挙げた。

コンテナの次はPaaSやServerless？

ここで草間氏は、10年前と5年前のクラウドに関する話題を比較し、「技術は発展とともに抽象度が上がり自動化される」と述べた。

そして、「コンテナもさらに抽象化され自動化されたものが中心になるのではないか」と主張した。例えば、Dockerfileを書かなくても自動的にいい感じに動かしてくれたり、運用も見てくれたり、勝手にスケールしてくれたりというものだ。

これはつまり、昔からあるPaaSだ。Pivotalが開発する「Cloud Foundry」もPaaSプラットフォームである。現在のPaaSは内部ではデプロイされたコードがコンテナとして動くことが多い。開発者はコンテナについて意識する必要はないが、コンテナ活用方法の1つと言える。「中身はそのときどきで変わる。コンテナであろうとなかろうと、PaaSが提供したい価値は変わらない。もしコンテナが廃れてもPaaSの考え方は廃れない」（草間氏）。

PaaSよりさらに抽象度が高いものにServerlessがある。なお、一般にServerlessはFaaS（Function as a Service）とBaaS（Backend as a Service）の2種類あるとされているが、草間氏はFaaSに絞って解説するとした。

FaaSではアプリケーションの作り方が変わる。また、コンテナやPaaSではあらかじめスケールさせる必要があるが、Serverlessは必要なときだけ呼ばれるため、自動的にスケールするという特徴がある。なお、Serverlessも実装としては中ではコンテナが使われており、これもコンテナの活用方法の1つだ。

選択基準はビジネスの目的から

さて、コンテナプラットフォーム（CaaS）とPaaS、Serverlessの3つの選択肢は、それぞれメリットとデメリットがある。これについて草間氏はCNCFが2月に公開したホワイトペーパー「CNCF Serverless Whitepaper」がよくまとまっていると紹介し、これを参考にしながら説明した。

まず、CaaSのメリットには柔軟性やツール、再利用できるコンテナイメージなどのエコシステムがある。また、Kubernetesではステートフルなアプリケーションも対応するようになっている。一方、デメリットとしては冒頭で語られた「コンテナ疲れ」が挙げられた。

PaaSのメリットは、アプリケーションのことだけ考えれば良い点だ。デメリットは、CaaSに比べると柔軟性に欠けることがある点だ。

Serverlessのメリットは、とてもスケールすること、うまくやればコストが下げられることだ。デメリットは、今までのアプリの作り方と変わることや、運用やデバッグのナレッジがまだ不足していることがある。また、コールドスタートのタイムラグの問題や、ほかと比べてベンダーロックインの可能性も高い点がある。

では、どのように選ぶべきか。「システム要求だけでなく組織やビジネスなどにもよるため変数が多すぎて、『こういうときはこれを選べ』というのは難しい」と草間氏は言う。

そこで考えるべきは「目的を明確にすることだ」と草間氏は主張する。コンテナやPaaS、Serverlessは手段であり、目的はアプリケーションによるビジネスだ。「どういう価値をもたらそうとしているか。ビジネスがはっきりしないとシステムの要求が決まらない」（草間氏）。

ビジネスでの評価ポイント

そのうえで草間氏は、評価ポイントをいくつか挙げた。

1点目は「強靭性・回復性」、2点目は「スケーラビリティ」だ。例えば、キャンペーンサイトはServerlessのメリットが生きる（ただしコスト高になる可能性もある）という。3点目は「パフォーマンス」で、例えばServerlessのコールドスタート問題を許容できるかどうかで判断が変わるという。

4点目は「ステートフルかステートレス」か。データベースのようなステートフルなアプリケーションを動かすならCaaSを選ぶことになる。5点目は「アプリケーションの更新頻度」で、更新頻度が高い場合はPaaSが向いているという。

6点目は「既存資産を流用するか」。そのままLift & Shiftで動かすにはCaaSが良いかもしれない。7点目は「開発者と運用者の人数」で、十分な開発者・運用者を確保できないならPaaSが良いかもしれない、という。

こうした機能要件のほか、草間氏は潜在的なコスト面についても指摘する。

1点目は「誰もが一からアプリケーションを作れる恵まれた環境にいるわけではない」ということ。例えば、CaaSにLift & Shiftするだけなら楽な一方、長期的にはコストがかかるという可能性もある。また、Serverless化するとインフラコストは下がる一方、アプリを書き換えるコストがかかる可能性もある。

2点目は「依存サービスとの関係」だ。ServerlessはRDBMSとの組み合わせにはあまり向かず、同じプラットフォームのサービスを使うことになる。

3点目は「セキュリティの問題」だ。CaaSは柔軟性が高いが、そのぶんプラットフォームは自分で対応しなくてはならない。

4点目は「ベストプラクティス」。PaaSやServerlessはベストなやり方に従うことを求められるが、それにより生産性が上がるためだ。一方でCaaSは自由度が高いが、そのまま移行しただけでは生産性が改善されないかもしれないという。

5点目は「ベンダーロックイン」。「Serverlessはほかのサービスとの組み合わせが前提なので、究極のロックインだと私は思っている」と草間氏。「ただし、ベンダーロックインも考えようで、気持ちよくやれるならそれで良い。基準は『ビジネスに支障があるかどうか』だ」（草間氏）。

こうしたポイント踏まえて、草間氏は「万能なものはないので、それぞれ適したプラットフォームに任せて組み合わせよう」とまとめた。さらに「大事なのは、CI/CDの自動化は必ずやろう。手作業が増えては意味がない」とつけ加えてセッションを締めくくった。

写真提供: https://www.flickr.com/groups/3958077@N22/