みなさんこんにちは。GS2 CEO の丹羽です。
先日 Cloud Native Computing Foundation(CNCF) が サーバレスコンピューティングに関するホワイトペーパーを発行しました。
今日はサーバレスアーキテクチャを活用したプラットフォーマーとしての立場としてこのホワイトペーパーを読んでの雑感をお伝えしたいと思います。
まずは、ホワイトペーパーの中から重要だと感じた部分を抜粋します。
What is serverless computing?
最初にサーバレスコンピューティングの定義から始まります。
どうやらここでは FaaS と BaaS こそがサーバレスコンピューティングという定義がされているようですが、後々の文書を見る限り PaaS もサーバレスコンピューティングとして捕らえている節もあり
CNCF の中でも PaaS をどう扱うか決めあぐねている様子がうかがえますが、文書構成的に本ホワイトペーパーにおける サーバレスコンピューティング とは FaaS を指していると言えそうです。
しかし、そのようなことは些末な問題であり、サーバレスコンピューティングの達成する事項は以下である。と定義しています。
- サーバのプロビジョニング、メンテナンス、アップデート、スケーリング、キャパシティプランニングに時間とリソースを費やす必要がなくなる
- サーバレスプラットフォームには「事前計画された容量」という概念がなく、「自動スケーリング」トリガやルールを設定する必要がない
- アイドルキャパシティに起因するコストがない
ただし
- これにはステートフルなストレージコストや追加された高レベルな機能などの他のコストは含まれていない
つまり、サーバレスコンピューティングとは
- イベントに対してオンデマンドで実行され、実行された時間に応じて費用が発生すること
- ただし、永続化するためのストレージに関する必要などはそれに値しない
- キャパシティ管理が不要であること
こそが肝と捕らえられているといえます。
Serverless use cases
このセクションでは実際の応用例を用いて サーバレスコンピューティング の有用性を解説しています。
サーバレスコンピューティングが有用な箇所として以下の特徴があるワークロードに適しているとしています。
- 非同期、並行、独立した作業単位への並列化が容易
- 処理が頻繁に発生せず散発的な需要があるもの。予測できない大きな利用変動が起こりえる
- ステートフル、短いレイテンシを必要としない
- 開発速度を加速し、ビジネス要件が頻繁に変化する
Serverless vs. Other Cloud Native Technologies
ここでは FaaS とPaaS/CaaS といった既存のテクノロジーとの比較が語られます。
Continer(CaaS)
利点
- 開発者は、展開されているものに対して、最も支配力があり、その力に伴う責任があります。コンテナオーケストラを使用すると、展開する正確なイメージのバージョンと、実行時を制御するポリシーとともに、どのような構成で運用するかを定義できる
- ランタイム環境（ランタイム、バージョン、最小OS、ネットワーク構成など）を制御できる
- システム外のコンテナイメージの再利用性と可搬性の向上
- コンテナ化されたアプリやシステムをクラウドにもたらすために最適
欠点
- セキュリティパッチと配布の最適化を含む、ファイルシステムのイメージと実行環境に対する責任が開発者/運用者による
- ロードバランシングとスケーリングの動作を管理する責任がある
- キャパシティ管理の責任がある
- デプロイ/プロビジョンに長い時間を要する
- ビルドとデプロイメントのメカニズムに対する責任がある
- 監視、ログ、およびその他の共通サービスの統合に対する責任がある
PaaS
利点
- 開発者の焦点はアプリケーションコードとそれが接続するデータサービスにあります。実際のランタイムはほとんど制御できませんが、開発者はビルドステップを避け、スケーリングオプションとデプロイメントオプションを選択することもできる
- 基礎となるOSを管理する必要がない
- 安定したプログラミングモデルを備えた多くの既存のWebアプリケーションに最適
欠点
- OSの制御が自由に行えない
- プラットフォームロックイン
FaaS
利点
- 開発者の視点が、高可用性を実現するという運用上の懸念から、機能ロジック自体にシフト
- 開発者は、デマンド/ワークロードに基づいた自動的なスケーリングを獲得
- コードが実際に稼働している場合にのみ課金する新しいコストモデル
- OS、ランタイム、およびコンテナのライフサイクルまでが完全に抽象化
- IoT、データ、メッセージを含む新興のイベント駆動型および予測不可能なワークロードに適している
- 通常、ステートレスで不変で一時的な展開。各機能は、指定された役割と、リソースへの明確に定義された/限定されたアクセスで実行
- ミドルウェア層はチューニング/最適化され、時間の経過とともにアプリケーションのパフォーマンスが向上
- ほとんどのサーバレスランタイムは個々の機能のサイズや実行時間に制限を設けているため、マイクロサービスモデルを強力に推進
欠点
- 新しいコンピューティングモデル、より包括的で安定したドキュメント、サンプル、ツール、およびベストプラクティスによる迅速なイノベーション
- ランタイムのよりダイナミックな性質のため、IaaSおよびPaaSと比較してデバッグするのは難しい
- オンデマンド構造により、ランタイムがアイドル時に関数のすべてのインスタンスを削除する場合、サーバーレスランタイムの「コールドスタート」がパフォーマンスの問題になる
- 複雑なユースケースにおいて、同じ量のロジックに対してより多くの実装を求められる可能性がある
- 歴史が浅く標準化と生態系成熟の欠如
- プラットフォームのプログラミングモデル、イベント/メッセージインターフェイス、およびBaaS製品によるプラットフォームロックイン
雑感
このホワイトペーパーから感じ取れることは、FaaS を使うべきかどうかを判断するための指針を伝えたかった。ということです。
細かいレベルでインフラストラクチャーを制御したい場合は Container を使うのが最良だと言えるでしょうし、そんなものどうでもいいから、可用性とか考えたくないからいい感じにして欲しい。という場合は PaaS か FaaS ということになります。
PaaS と FaaS のどちらを選ぶべきか。という点においては、既に成熟したアプリケーションフレームワークを使いたい場合は PaaS。ごくまれにトラフィックが発生し、普段はトラフィックがほぼ無いケースや、突発的なアクセスの増加が予想される場合は FaaS が望ましいといえそうです。
IaaS の欠点のうち、コールドスタートやロックインといった部分に関しては PaaS と共通する箇所でしょうから、
逆に言えば、成熟したアプリケーションフレームワークが使えない以外のデメリットは PaaS と比較する分には FaaS にはない。といえます。
FaaS のためのアプリケーションフレームワークが整ってくれば次世代のサーバレスコンピューティングとして芽吹いてくる可能性が高そうです。
ところで、BaaS はサーバレスコンピューティング である。と言った割に BaaS について全然触れられてないのはなんとかして欲しいですね。
BaaS も オンプレミス/IaaS/PaaS/FaaS のいずれかで動いているアプリケーションだということを正しく伝えておかないと、BaaS を使えば 『FaaS のような柔軟性が得られる』という絶望的な勘違いが生まれかねません。
GS2 のような FaaS で設計/開発された BaaS というのは世界的に見ても現時点では殆ど存在しないでしょうから、ここはしっかり押さえておくべきではないか。と感じました。
GS2 ってなんやねーん。という方がもしここまで読んでくださっていた場合に備えて紹介を。
GS2 とは Game Server Services というスマートデバイス向けゲームの BaaS です。FaaS で設計/実装 されており、スケーラブルかつ高可用性なサーバシステムを提供しています。
gs2.io
それでは、また。
