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

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

[三木泉，＠IT]

【完訳】CNCF Serverless Whitepaper v1.0　連載バックナンバー

　本連載では、サーバレスコンピューティング（以下、サーバレス）を解説したCloud Native Computing Foundation（CNCF）のServerless Working Groupによるホワイトペーパー、CNCF Serverless Whitepaper v1.0」を完訳してお届けしている。

　連載第2回は、「コンテナオーケストレーション（Container as a Service）」「PaaS（Platform as a Service）」「サーバレス（Functions as a Service）」の3つのクラウドネイティブアプリケーションプラットフォームについて、それぞれの想定ユーザー、長所と短所などを説明した部分を掲載する（翻訳・構成：三木泉）。

サーバレスと他のクラウドネイティブテクノロジー

　クラウドネイティブアプリケーションを稼働するプラットフォームを探す際、ほとんどのアプリケーション開発者が検討する可能性のある、3つの主要な開発／展開モデルがあります。各モデルに、さまざまな実装（オープンソースプロジェクト、ホステッドプラットフォーム、オンプレミス製品など）があります。これらの3つのモデルは、密度、性能、分離、およびパッケージングの観点から、多くの場合コンテナ技術を基盤としていますが、コンテナ化は必須ではありません。

　コードを実行する実際のインフラストラクチャからの抽象度が高まる順、開発の対象であるビジネスロジックへの集中度が高まる順に並べると、「コンテナオーケストレーション（またはContainer as a Service）」「PaaS（Platform as a Service）」「サーバレス（Functions as a Service）」となります。これらのアプローチは全て、クラウドネイティブアプリケーションを展開する方法を提供しますが、想定する開発者および作業負荷のタイプが異なり、このため機能面および非機能面の優先順位付けが異なります。次のセクションでは、それぞれの主要な特性の一部を示します。

　全てのクラウドネイティブな開発と展開の課題を解決できる、唯一のアプローチは存在しないことに留意してください。特定のワークロードのニーズを、これらの一般的なクラウドネイティブ開発テクノロジーのメリットおよび欠点とマッチさせることが重要です。また、アプリケーションのサブコンポーネントそれぞれが、別のアプローチに適している可能性があるため、「（単一アプリケーションを）ハイブリッド構成とすることもあり得る」と考えることも重要です。

コンテナオーケストレーション

　「Container as a Service（CaaS）」とも呼ばれ、 インフラストラクチャに対する完全な制御を維持し、最大限の移植性を実現します。例：Kubernetes、Docker Swarm、Apache Mesos。

　Kubernetes、Swarm、Mesosなどのコンテナオーケストレーションプラットフォームでは、ポータブルなアプリケーションを構築し、展開できます。構成に関して柔軟性と制御が得られ、異なる環境への展開のための再構成は不要で、どこへでも動かすことができます。

　メリットとしては、最大限の制御、柔軟性、再利用性があり、既存のコンテナ化されたアプリケーションをクラウドに持ち込むことも最も容易です。これら全ては、「あるべき姿についての主張を抑えた（less-opinionated）」アプリケーション展開モデルであることからくる自由度によって可能となっています。

　CaaSの欠点としては、オペレーティングシステム（セキュリティパッチを含む）、ロードバランシング、キャパシティ管理、スケーリング、ロギング、およびモニタリングに関する開発者の責任が大幅に高まります。

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

• アプリケーションとその依存関係のパッケージ化とバージョン管理の方法を制御し、展開プラットフォーム間の移植性と再利用性を確保したい開発者と運用チーム
• 独立してスケールするが、相互に依存関係にあるマイクロサービス群のまとまったセットとして、高いパフォーマンスを求めている開発者
• コンテナをクラウドに移行する、またはプライベート／パブリッククラウドに展開する組織、そしてエンドツーエンドのクラスタ展開に慣れている組織

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

• Kubernetesクラスタ、Docker Swarmスタック、またはMesosリソースプールを作成（1回実行）
• イタレーションで（反復的に）コンテナイメージをローカルにビルド
• タグ付けしたアプリケーションイメージをレジストリにプッシュ
• コンテナイメージに基づいてコンテナをクラスタに展開
• アプリケーションをテストし、本番環境で監視

利点

• 開発者は、展開されているものに対して、最も支配力があり、その力に伴う責任がある。コンテナオーケストレータを使用して、展開するイメージのバージョンと設定を、ランタイムを制御するポリシーとともに、細かく定義できる
• ランタイム環境（ランタイム、バージョン、軽量OS、ネットワーク構成など）に対する制御性
• コンテナイメージのシステム外での再利用性と可搬性の向上
• コンテナ化されたアプリケーションやシステムのクラウド移行についての高い適性

欠点

• セキュリティパッチと配布の最適化を含む、ファイルシステムのイメージと実行環境に対する責任の増大
• 負荷分散とスケーリングの振る舞いについての管理責任の増大
• 一般的にはキャパシティ管理の責任が増大
• 現時点では、一般的により長い起動時間を要する
• 通常、アプリケーションの構造に関する「あるべき姿についての意見を抑えている（less opinionated）」ため、ガードレールの役割を果たすものは少ない
• 一般的には、ビルドとデプロイメントのメカニズムに対する責任が増大
• 一般的には、監視、ロギング、その他の共通サービスの統合に関する責任が増大

PaaS（Platform as a Service）

　PaaS（Platform as a Service）は、開発者がアプリケーションに専念し、プラットフォームが残りの部分を処理するようにします。例：Cloud Foundry、OpenShift、Deis、Heroku。

　サービスとしてのプラットフォームの実装により、チームはコンテナやOSを手動で設定・管理することなく、アプリケーションに構成情報を注入することで、幅広い一連のランタイム、データカタログ、AI、IoT、およびセキュリティサービスへのバインディングを使用してアプリケーションを展開および拡張できます。これは、安定したプログラミングモデルを持つ既存のWebアプリケーションに最適です。

　利点としては、アプリケーション、自動スケーリング、最も一般的なアプリケーションのニーズに即した事前構成済みサービスの管理およびデプロイメントの容易化などがあります。

　欠点には、OS制御、きめ細かなコンテナの可搬性や負荷分散、アプリケーションの最適化といった点での欠如、潜在的なベンダーロックイン、そしてほとんどのPaaSプラットフォームでは監視・ログ機能の構築と管理が必要であることなどが挙げられます。

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

• アプリケーションのソースコードとファイル（パッケージ化が不要）に専念し、OSを気にすることなく展開できるプラットフォームを求める開発者
• デフォルトでルーティング可能なホスト名を使用して、従来のHTTPベースのサービス（アプリケーションやAPI）を作成している開発者。ただし、一部のPaaSプラットフォームでは、汎用TCPルーティングもサポートするようになっている
• 包括的なドキュメントと多数のサンプルによってサポートされた、クラウドコンピューティングのより確立されたモデル（サーバレスと比較して）に慣れている組織

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

• ローカルWeb開発環境でアプリケーションの実行、ビルド、テストを繰り返す
• PaaSにアプリケーションをプッシュし、PaaSが構築され実行される
• 本番環境でアプリケーションをテストし、監視
• 高可用性の確保と需要に合わせたスケーリングのために構成を更新

利点

• 開発者が参照できる対象は、アプリケーションコードとそれが接続するデータサービスにある。実際のランタイムはあまり制御できないが、開発者はビルドのステップを避け、スケーリングおよびデプロイメントについて、複数の選択肢から選ぶこともできる
• 下で動作するOSの管理は不要
• ビルドパックはランタイムに関し、必要に応じた制御（分かりやすいデフォルト）を提供
• 安定したプログラミングモデルを備えた多くの既存のWebアプリケーションに最適

欠点

• ビルドパックのバージョンに左右され、OSに対する制御が失わる可能性がある
• アプリケーション構造の「あるべき姿についての考え方がより明確（more opinionated）」で、12ファクターマイクロサービスのベストプラクティスを指向しており、アーキテクチャの柔軟性は潜在的に犠牲となる
• 潜在的なプラットフォームへのロックイン