サーバーレスとは

サーバーレスは、開発者がサーバーを管理する必要なくアプリケーションを構築および実行できるようにするクラウドネイティブ開発モデルです。

サーバーレスにもサーバーはありますが抽象化されており、アプリケーション開発から切り離されています。サーバー・インフラストラクチャのプロビジョニング、保守、スケーリングといった定型作業はクラウドプロバイダーが行います。開発者は、コードをコンテナにパッケージ化するだけでデプロイできます。

デプロイされると、サーバーレス・アプリケーションは需要に対応し、必要に応じて自動的にスケールアップやスケールダウンを行います。パブリッククラウドプロバイダーのサーバーレスサービスは、通常、イベント駆動型実行モデルを通じてオンデマンドで測定されます。そのため、サーバーレス機能がアイドル状態である間は、費用がかかりません。

サーバーレスは、クラウドプロバイダーがクラウド・インフラストラクチャとアプリケーションのスケーリングの両方の管理を担うという点で、他のクラウド・コンピューティング・モデルとは異なります。サーバーレス・アプリケーションは、呼び出されたときにオンデマンドで自動的に起動するコンテナにデプロイされます。

標準の IaaS (Infrastructure-as-a-Service) クラウド・コンピューティング・モデルでは、ユーザーは容量を単位で事前に購入します。つまり、パブリッククラウドプロバイダーに、アプリケーションを実行するために常時稼働しているサーバーコンポーネントの料金を支払います。需要が高いときにサーバーの容量をスケールアップし、その容量が不要になった場合にスケールダウンするのはユーザー側の作業です。アプリケーションの実行に必要なクラウド・インフラストラクチャは、アプリケーションが使用されていないときでもアクティブです。

対照的に、サーバーレス・アーキテクチャでは、アプリケーションは必要な場合にのみ起動されます。イベントがトリガーされてアプリケーションのコードが実行されると、パブリッククラウドプロバイダーはそのコードにリソースを動的に割り当てます。コードの実行が完了すれば、ユーザーの料金の支払いは生じません。コストや効率性におけるメリットに加えて、サーバーレスによって、アプリケーションのスケーリングやサーバーのプロビジョニングに伴う定型作業や単純作業から開発者が解放されるという利点があります。

サーバーレスでは、オペレーティングシステムとファイルシステムの管理、セキュリティパッチ、ロードバランシング、容量管理、スケーリング、ロギング、モニタリングなどの定型作業が、すべてクラウドサービス・プロバイダーにオフロードされます。

サーバーレス・アプリケーション全体を構築することも、サーバーレスと従来のマイクロサービス・コンポーネントを組み合わせてアプリケーションを構成することもできます。

サーバーレスモデルでは、クラウドプロバイダーが物理サーバーを実行し、ユーザーに代わってリソースを動的に割り当てます。すると、ユーザーはコードを直ちにプロダクションにデプロイできます。

サーバーレス・コンピューティング・サービスは、通常、BaaS (Backend-as-a-Service) と FaaS (Function-as-a-Service) の 2 つのグループに分類されます。  

BaaS を使用すると、開発者はさまざまなサードパーティのサービスやアプリケーションにアクセスできます。たとえば、クラウドプロバイダーが認証サービス、暗号の強化、クラウドでアクセスできるデータベース、信頼性の高い使用状況データを提供する場合に使用されます。BaaS では、サーバーレス機能は通常、アプリケーション・プログラミング・インタフェース (API) を通じて呼び出されます。

多くの場合、開発者が言うサーバーレスは FaaS モデルを指しています。FaaS では、開発者は依然としてカスタムのサーバー側ロジックを記述しますが、クラウドサービス・プロバイダーが完全に管理するコンテナで実行されます。 

主要なパブリッククラウドプロバイダーはすべて、1 つ以上の FaaS サービスを提供しています。Amazon Web Services の AWS Lambda、Microsoft Azure の Azure Functions、Google Cloud では複数のサービス、IBM Cloud の IBM Cloud Functions などがあります。 

一部の組織では、 Kubernetes の Knative プロジェクトに基づく Red Hat® OpenShift® Serverless などのオープンソースのサーバーレス・プラットフォームを使用して、独自の FaaS 環境を運用しています。

FaaS (Function-as-a-Service) は、開発者が、プラットフォームが完全に管理するコンテナにデプロイされ、オンデマンドで実行されるロジックを記述するイベント駆動型コンピューティング実行モデルです。

BaaS とは対照的に、FaaS は開発者により高度な制御を提供するため、開発者は事前に記述されたサービスのライブラリを利用せずにカスタムアプリケーションを作成できます。 

コードは、クラウドプロバイダーが管理するコンテナにデプロイされます。これらのコンテナには以下のような特長があります。

• ステートレス：データ統合がシンプルになります。
• 一時的：実行される期間はきわめて短時間です。
• イベント駆動型：必要なときに自動的に実行できます。
• クラウドプロバイダーによる完全管理：常時稼働のアプリケーションとサーバーではなく、必要な分だけ購入できます。

開発者は FaaS を使用して、FaaS プロバイダーが API ゲートウェイ を通じて処理する API を介してサーバーレス・アプリケーションを呼び出すことができます。

サーバーレス・アーキテクチャは、即座に開始できる非同期のステートレス・アプリケーションに最適です。同様に、サーバーレスは、予測できない需要の急増がまれに見られるユースケースに適しています。

着信するイメージファイルのバッチ処理のようなタスクを考えてみてください。頻度は低いかもしれませんが、大量のイメージが一度に着信する場合にも対応できるようにしておく必要があります。あるいは、データベースに着信する変更を監視し、その変更を品質基準と照らし合わせたり、それらを自動変換したりするなどの一連の機能を適用するようなタスクです。

サーバーレス・アプリケーションは、着信データストリーム、チャットボット、スケジュールされたタスク、ビジネスロジックなどに関連するユースケースにも適しています。

その他の一般的なサーバーレスのユースケースとしては、バックエンド API とウェブアプリケーション、ビジネスプロセスの自動化、サーバーレスウェブサイト、複数のシステム間の統合などがあります。

コンテナ化されたアプリケーションを自動化されたインフラストラクチャで実行する方法として、Kubernetes コンテナ・オーケストレーション・プラットフォームがサーバーレス環境を実行するための一般的な選択肢だということに驚きはありません。しかし、Kubernetes だけでは、サーバーレス・アプリケーションを実行できません。

Knative は、サーバーレス・アプリケーションを Kubernetes でデプロイ、実行、管理するためのコンポーネントを追加するオープンソース・コミュニティ・プロジェクトです。

Knative のサーバーレス環境では、Red Hat OpenShift などの Kubernetes プラットフォームにコードをデプロイできます。Knative では、コードをコンテナイメージとしてパッケージ化し、それをシステムに引き渡すことでサービスを作成します。コードは必要な場合にのみ実行され、インスタンスは Knative によって自動的に開始および停止されます。

Knative の主要コンポーネントは次の 3 つです。

• Build：ソースコードをコンテナにビルドするための柔軟なアプローチ
• Serving：要求に基づいてワークロードをサーブするリクエスト駆動型モデルによるコンテナの迅速なデプロイメントと自動スケーリング
• Eventing：アプリケーションを活動させるイベントを消費および作成するためのインフラストラクチャアプリケーションは、独自のアプリケーションのイベント、複数のプロバイダーのクラウドサービス、SaaS (Software-as-a-Service) システム、Red Hat AMQ ストリームなどのさまざまなソースによってトリガーされます。

以前のサーバーレス・フレームワークとは異なり、Knative は、モノリシック・アプリケーションからマイクロサービスやちょっとした機能に至るまで、先進的なアプリケーションのあらゆるワークロードをデプロイするように設計されました。

単一のサービスプロバイダーによって制御される FaaS ソリューションの代替手段として、Knative はKubernetes を実行するあらゆるクラウドプラットフォームで実行できます。これには、オンプレミスのデータセンターでの実行も含まれます。これにより、組織はサーバーレスワークロードを実行する際のアジリティと柔軟性を向上させることができます。

長所

• サーバーレス・コンピューティングによって開発者の生産性が向上し、運用コストを削減できます。プロビジョニングとサーバー管理の定型作業の負担が軽減されるので、開発者は自分のアプリケーション業務に集中する時間を増やせます。 
• サーバーレスによって、開発者がプロビジョニングしてほしいインフラストラクチャの仕様を明示的に運用担当者に説明する必要がなくなり、DevOps の導入が可能となります。  
• サードパーティによる BaaS サービスのコンポーネント全体を組み込むことで、アプリケーション開発をさらに効率化することができます。
• サーバーレスモデルでは運用コストが削減されます。固有のサーバーを常時実行して管理するのではなく、必要に応じてクラウドベースのコンピュート時間単位で料金を支払うからです。

短所

• 固有のサーバーを実行せず、固有のサーバーサイド・ロジックを制御しないことで、欠点も生じます。
• クラウドプロバイダーがコンポーネントの連携方法について厳密な制約を設けている場合には、ユーザー固有のシステムの柔軟性やカスタマイズの度合いに影響を及ぼします。BaaS 環境の場合、開発者は、コードが自分の制御外にあるサービスに依存する可能性があります。
• IT スタックのこのような側面の制御を他に委ねると、ベンダーロックインに陥るおそれがあります。プロバイダーを変更しようとしても、新しいベンダーの仕様に準拠することになり、システムをアップグレードするコストが生じる可能性があります。

サーバーレス・アーキテクチャと FaaS の概念は、コンテナやオンデマンドのクラウドサービスの人気と相まって成長しています。Red Hat との連携により作成された  451 Research のレポートでは、サーバーレスの進化に 3 つのフェーズがあることが明らかになりました。

サーバーレスの「1.0」フェーズではさまざまな制限があり、一般的なコンピューティングにとって理想的なものではありませんでした。サーバーレス 1.0 の特徴は次のとおりです。

• HTTP と他のいくつかのソース
• 機能のみ
• 限られた実行時間 (5 〜 10 分)
• オーケストレーションなし
• わずかなローカル開発エクスペリエンス

Kubernetes の登場によって、「サーバーレス 1.5」時代を迎えました。このとき、多くのサーバーレス・フレームワークがコンテナの自動スケーリングを開始しました。サーバーレス 1.5 の特徴は次のとおりです。

• Knative
• Kubernetes ベースの自動スケーリング
• マイクロサービスと機能
• ローカルでのデバッグとテストが容易
• 多言語で可搬性がある

今日では、統合とステートが追加され、「サーバーレス 2.0」時代になりつつあります。プロバイダーは不足している部分を追加し始めており、サーバーレスを汎用のビジネスワークロードに適したものにしています。サーバーレス 2.0 の特徴は次のとおりです。

• 基本的なステート処理
• エンタープライズ統合パターンの使用
• 高度なメッセージング機能
• エンタープライズ PaaS との融合
• エンタープライズ対応のイベントソース
• ステートと統合