サーバレス、CaaS、PaaSをどう使い分けるか：【完訳】CNCF Serverless Whitepaper v1.0（3）（2/2 ページ）

本連載では、Cloud Native Computing Foundationのサーバレスコンピューティングホワイトペーパーを完訳し、計5回の連載として掲載している。第3回は、コンテナオーケストレーション、PaaS、サーバレスの使い分け、および併用についての解説をお届けする。

[三木泉，＠IT]

複数のプラットフォームを活用したアプリケーションの実行

　提供されている各種クラウドホスティング技術を見る限りでは自明ではないかもしれませんが、全てのデプロイメントについて、単一のソリューションのみを使用する必要はありません。実際、単一のアプリケーション内で同一ソリューションを使用しなくてはならない理由はありません。アプリケーションが複数のコンポーネント、あるいはマイクロサービスに分割されるなら、ニーズに即して最善だと判断した場合、それぞれを完全に別個のインフラストラクチャへ自由にデプロイすることができます。

　同様に、各マイクロサービスは、それぞれの目的に合った最良の技術（すなわち開発言語）で開発することもできます。ただし、 「モノリスの解体」に伴う自由は、新たな課題をもたらします。以下のセクションでは、プラットフォームを選択し、マイクロサービスを開発する際に考慮すべきいくつかの側面について説明します。

デプロイメントターゲット間でコンポーネントを分割する

　例えばIoTデモでは、接続デバイスの（管理）ダッシュボードへのリクエストを処理するPaaSアプリケーションと、デバイス自体からのMQTTメッセージ・イベントを処理するサーバレス関数の両方を使用することがあります。サーバレスは全てのニーズに応えられる「魔法の弾丸」ではなく、各自のクラウドネイティブアーキテクチャ内で検討すべき新たな選択肢の1つです。

複数のデプロイメントターゲットを考慮して設計する

　また、コードをできるだけジェネリックにし、ローカルでテストできるようにし、環境変数などのコンテキスト情報を使用して特定の環境での動作を制御するといったアプリケーション設計上の選択もできます。例えば、従来型のJavaオブジェクトのセットは、3つの主要環境のいずれにおいても実行でき、使用可能な環境変数、クラスライブラリ、またはバインドされたサービスに基づいて、振る舞いを正確に調整できる可能性があります。

いずれのアプローチにおいてもDevOpsパイプラインを利用し続ける

　大部分のコンテナオーケストレーションプラットフォーム、PaaS実装、およびサーバレスフレームワークはコマンドラインツールで駆動でき、同じコンテナイメージを一度構築したら、各プラットフォーム上で再利用できる可能性があります。

モデル間の移植性を容易にする抽象化を検討する

　PaaSまたはCaaS上で実行されているHTTPベースのWebアプリケーションを、サーバレスプラットフォームに移植する際のギャップを埋める、サードパーティープロジェクトのエコシステムが拡大しています。Serverless, Inc.やZappa Frameworkのツールなどがあります。

　サーバレスフレームワークは、Python WSGiやJAX-RS REST APIなどの一般的なWebアプリケーションフレームワークを使用して作成されたアプリケーションを、サーバレスプラットフォームで実行できるようにするアダプタを提供します。こうしたWebアプリケーションフレームワークは、複数のサーバレスプラットフォーム間の違いを吸収し、移植性と抽象度を高めることもできます。

ここでは、サーバレスアーキテクチャを選択する際の基準を、具体的に紹介している。ホワイトペーパーでは強調されていないが、その基準は、サーバレスプラットフォームをオンプレミスで動かすか、クラウド上のサービスとして利用するかによっても変わると考えられる。クラウド上のサービスとして使う場合は、特定クラウドへの依存度が高まりはするものの、サーバレスをコンテナオーケストレーションやPaaS、APIなど、他のサービスと併用することも自然に考えられる。（三木）

　連載第4回は、サーバレスアーキテクチャとはどのようなものかを、技術的に解説した部分を掲載する。