Serverlessとは？

Serverlessのビジネスロジックとは一体何でしょうか？すべてのアプリケーションは、どこかのタイミングでサーバーを使用します。「Serverless」という用語は、デベロッパーがインフラストラクチャに関して悩むことなく、その代わりにアプリケーションのビジネスロジックに注力できるアーキテクチャとサービスモデルであることを示しています。Serverlessは、Adrian Cockcroft氏がこの動画で説明しているように、モノリスからマイクロサービス、そして関数へと進化を遂げたアーキテクチャ設計の新たなる姿だと言えます。

ServerlessとFaaSは同じ意味で使われることが多いですが、これは実際のところ正確ではありません。Serverlessは、FaaSを他のクラウドマネージドサービスとともに利用する包括的なアーキテクチャパターンです。一方、FaaSとは、AWS Lambda、Google Cloud Functions、Azure Functionsなど、デベロッパーが関数をデプロイできるようにする特定のタイプのサービスのことです。

1. 小規模な単位の個別コード。大抵の場合、Serverlessアーキテクチャで記述されたサービスは、単一の関数で構成されています。
2. イベントドリブンの実行。関数がトリガーされるまで、関数の実行に必要なインフラストラクチャは存在しません。イベントを受信すると、そのリクエストを実行するために一時的なコンピューティング環境が作成されます。この環境は即座に破棄されることもあるものの、多くの場合は5分程度の短期間だけ有効になります。3. ゼロまでスケールダウン可能。関数がリクエストの受信を停止すると、インフラストラクチャは完全に停止され、削除されます。使用時にのみインフラストラクチャが実行されるため、コストを削減できます。使用していないときは、コンピューティング環境をゼロまでスケールダウンできます。
3. 無限にスケール可能。理論上、FaaSがモニタリングできる負荷の量と、必要に応じて作成できる追加のインスタンスの数には制限がありません。そのため、アプリケーションの設計時に、デベロッパーが規模について考える必要はほぼありません。関数を1つデプロイするだけで、コードをまったく変更することなく、1件または10億件のリクエストを処理できます。
4. マネージドサービスの利用。Serverlessアーキテクチャでは通常、ファイルストレージ、データベース、キューイングなどの分化されておらず負荷のかかるアプリケーション要素に、クラウドで提供されるサービスを利用しています。たとえば、GoogleのFirebaseは、Cloud Functionsなどの他のGoogleサービスに接続するデータベースおよび状態管理サービスとして、Serverlessコミュニティで好評です。

以下のチャートでは、AWSやGoogle Cloud、Azureのマネージドサービスの例を、同等のオープンソースサービスとともにご紹介します。

GitLab Serverlessを使用すると、企業は独自のFaaSをKubernetesにデプロイできます。

より速く

イノベーションを加速します。デベロッパーがビジネスロジックのみに注力できるようになれば、生産性が向上します。

安定性

安定性と回復力に優れているため、ダウンタイムにより収益を失う可能性が減ります。

スケール可能

スケーラビリティに優れているため、ソフトウェアをビジネス上のニーズに応じて拡張できます。

コスト

コストを削減できます。Serverlessでは、サービスがアクティブなときにのみコンピューティングに対して課金が発生するため、常時稼働のインフラストラクチャと比べて大幅なコスト削減を実現可能です。

ベンダーロックインなし

ベンダーロックインはありません。コンピューティングを実行するベンダーは、組織が選べます。Kubernetesをサポートするあらゆるクラウドから、またはオンプレミスサーバーも選択できます。

ワークフロー

単一のアプリケーションにより、FaaSは、計画からテスト、そしてデプロイからモニタリングまで、ソフトウェア開発の他の部分と同じワークフローに含まれます。

デプロイ

直接Knativeを使用するのと比べて、関数のデプロイプロセスが大幅に合理化され、簡素化されます。