サーバレス、CaaS、PaaS――それぞれの利点と欠点：【完訳】CNCF Serverless Whitepaper v1.0（２）（2/2 ページ）

本連載では、サーバレスコンピューティングの概要とユースケース、コンテナオーケストレーションやPaaSとの使い分け方などを分かりやすく解説した、Cloud Native Computing Foundationのホワイトペーパーを完訳してお届けする。第2回は、コンテナオーケストレーション、PaaS、サーバレスの3つのクラウドネイティブアプリケーションプラットフォームについて、それぞれの想定ユーザー、長所と短所などを説明した部分を掲載する。

[三木泉，＠IT]

サーバレス

　サーバレス（Functions as a Service）は、さまざまなイベントに応答する小さなコードとしてロジックを記述します。例：AWS Lambda、Azure Functions、Apache OpenWhiskに基づくIBM Cloud Functions、Google Cloud Functions、HuaweiのFunction StageおよびFunction Graph、Kubeless、iron.io、funktion、fission、nuclio。

　サーバレスでは、開発者は、さまざまなトリガに応答するイベントドリブンな関数で構成されたアプリケーションに専念でき、残りの部分をプラットフォームが担当します。すなわち、トリガを関数につなげるロジック、ある関数から別の関数への情報の受け渡し、コンテナおよびランタイムの自動プロビジョニング（いつ、どこで、何を）、自動スケーリング、アイデンティティー管理などを実行します。

　メリットとしては、クラウドネイティブなパラダイムでインフラストラクチャ管理の必要性が最も少ないことが挙げられます。操作やファイルシステム、ランタイム、コンテナ管理さえ考慮する必要はありません。 サーバレスでは、自動化されたスケーリング、エラスティックロードバランシング、最もきめ細かな「使っただけ課金（pay-as-you-go）」のコンピューティングモデルが利用できます。

　短所には、包括的で安定したドキュメント、サンプル、ツール、ベストプラクティスの不足、デバッグがより困難、応答時間が遅くなる可能性、標準化やエコシステムの成熟度の欠如、プラットフォームロックインの可能性などがあります。

ターゲットオーディエンス

• 関数が需要に応じて自動的にスケールし、トランザクションとコストを密接に結び付ける環境を利用し、個々の関数におけるビジネスロジックにもっと集中したい開発者
• アプリケーションをより迅速に構築し、運用面への関わりを減らしたい開発者
• データベースの変更、IoT情報の読み出し、人による入力などのイベントによって駆動されるアプリケーションを作成する開発者およびチーム
• 標準とベストプラクティスがまだ完全に確立されていない分野で、最先端の技術を採用するのに慣れている組織

開発／運用エクスペリエンス

• 関数を対象にイテレーション（反復作業）を行い、ローカルWeb開発環境で構築、テストを実行
• 個々の関数をサーバレスプラットフォームにアップロード
• イベントトリガ、関数とそのランタイム、およびイベントと関数の関係を宣言します。
• 本番環境でアプリケーションをテストし、監視
• 高可用性の確保と需要に合わせたスケーリングのために構成を更新する必要はなし

利点

• 開発者の視点は、可用性を確保した上での関数のデプロイメント管理などの運用上の懸念から、関数ロジックそのものに向かってシフトしている
• 開発者は、需要／ワークロードに基づく自動スケーリングを活用できる
• コードが実際に稼働している時間についてのみ課金する新しい「使っただけ課金（pay as you go）」のコストモデルを活用できる
• OS、ランタイム、およびコンテナのライフサイクルまでを完全に抽象化（サーバレス）
• IoT、データ、メッセージを含む新世代のイベント駆動型および予測不可能なワークロードに適する
• 通常、ステートレスで不変で一時的なデプロイメントで利用。各関数は、指定された役割に基づき、リソースに対する明確に定義され、制限されたアクセスの下に実行される
• ミドルウェア層はチューニング／最適化され、時間の経過とともにアプリケーションのパフォーマンスが向上
• ほとんどのサーバレスランタイムは個々の関数のサイズや実行時間に制限を設けているため、マイクロサービスモデルを強力に推進
• サードパーティーのAPIと、カスタムのサーバレスAPIはどちらも簡単に統合できる。双方とも利用に応じてスケールし、クライアントとサーバのいずれからも呼び出せる柔軟性がある

欠点

• 新しいコンピューティングモデルであり、高速なイノベーションが起こっていて、包括的で安定したドキュメント、サンプル、ツール、およびベストプラクティスが不足している
• ランタイムのよりダイナミックな性質のため、IaaSやPaaSに比べ、デバッグはより困難であることが考えられる
• オンデマンド構造であるため、サーバレスランタイムがアイドル時にある関数の全てのインスタンスを削除する場合、ランタイムの「コールドスタート」がパフォーマンスの問題になることがある
• より複雑な場合（例えば、他の関数をトリガする関数）には、同程度の量のロジックと比較して、より多くの運用を要することがあり得る
• 標準化とエコシステムの成熟の欠如
• プラットフォームのプログラミングモデル、イベント／メッセージ・インタフェース、およびBaaS製品によるプラットフォームロックインの可能性

　今回掲載したセクションでは、サーバレスに関するホワイトペーパーではあるが、コンテナオーケストレーション、PaaSと横並びで、それぞれの長所、短所に言及している。

　コンテナオーケストレーションツールの長所、短所については、Kubernetesとそのエコシステムを推進する役割も持っているCNCFの活動にもつながってくる。Kubernetesは、そのまま使う場合には運用負荷が高くとも、Kubernetesベースの商用製品は、利用者がインフラ的側面をあまり考えないで済むような進化を遂げる可能性がある。また、サーバレスについては、Kubernetes上で動くものが既に複数存在している。つまり、コンテナオーケストレーションは確かに抽象度が低いが、他の2つのクラウドネイティブプラットフォームの基盤としても使えるようになってくる。

　連載第3回は、サーバレス、コンテナオーケストレーション、PaaSの使い分けについて解説した部分を掲載する。