サーバーレス コンピューティングとは

アプリケーションの構築に関しては通常、デベロッパーはコードをデプロイするために、処理とストレージのためのリソースの定義、パッチ適用、ロード バランシングなど、多くのサーバー管理タスクを実行する必要があります。こうした余分な項目はすべて、長いプロビジョニング時間と、運用上のオーバーヘッドの増加をもたらし、最終的に開発チームの作業効率低下を招きます。

サーバーレス コンピューティングは、デベロッパーに目に見えない「サーバーレス」のエクスペリエンスを提供し、サーバーやアプリケーションの実行に必要なものを考える必要性を排除します。サービス プロバイダがバックグラウンドですべての作業を行い、コードを実行し、要件を満たすためのリソースを確保します。アイドル状態の容量に対して料金が請求されることはありません。

サーバーレスは、家に水道を引くようなものと考えてください。自分の井戸を掘り、水質をテストし、家に水道を引くために必要なすべての外部配管を設置して維持することができます。または、都市のメインの水道に接続することもできます。水道の蛇口を回すだけで、必要なときに必要な量の水が供給され、市は実際に消費した水量に対して毎月の請求書を送付します。

同様に、クラウド プロバイダはサーバーレス アプリの実行に必要なインフラストラクチャ リソースとランタイム環境を自動的にスピンアップし、実行が完了すると自動的にゼロにスケールダウンします。通常、実行時間中のリソースに応じて課金されます。ただし、これはサービスやベンダーによって異なる場合があります。

でも、他のタイプのクラウド コンピューティングでは、従量課金制でオンデマンドのリソースが提供されるのではないですか？Infrastructure as a Service（IaaS）やPlatform as a Service（PaaS）などのクラウド サービス モデルでも、コンピューティング リソースへのオンデマンド アクセスが提供されるのは事実です。

ただし、割り当てられたクラウド インフラストラクチャは、使用していない場合でもアクティブなままです。また、ユーザーの需要に応じてサーバーの容量を拡張したり、アプリケーションをスケールアップまたはスケールダウンするように構成したりすることも、お客様の責任となります。

一方、サーバーレス アーキテクチャはイベント ドリブンです。このモデルでは、イベントによってコードの実行がトリガーされた場合にのみ、プロバイダからリソースが提供されます。また、リクエストに応じて即座に自動的にスケーリングされます。

通常、サーバーレス クラウド コンピューティングには、Functions as a Service（FaaS）と Backend as a Service（BaaS）という 2 種類のサービスがあります。

• FaaS は、リクエストに応じてアプリケーション ロジックを実行するために必要なコンピューティング リソースを提供します。これらのロジック（または関数）は、クラウド サービス プロバイダによって完全に管理されるコンテナで実行されます。サーバーレス アプリケーションは通常、イベントに応答して 1 つのアクションを実行する単一の機能に分割されます。
• BaaS は、認証サービス、データベース管理、クラウド ストレージ、プッシュ通知、ホスティングなど、ウェブ アプリケーションやモバイル アプリケーションのバックエンド機能をサービスとして提供します。BaaS では、サーバー、コンテナ、仮想マシンを管理する必要もありません。

開発の分野では、「サーバーレス」という用語は通常、FaaS サービスを指すために使用されます。ただし、FaaS は技術的にはサーバーレス テクノロジーのサブセットであることに注意してください。サーバーレス コンピューティングとは、サーバーの管理、構成、スケーリング、課金など、エンドユーザーから抽象化されるあらゆる種類のサービスを指します。これには、データベース、ストレージ、イベント ストリーミング、メッセージング、API ゲートウェイなどが含まれます。

サーバーレス コンピューティングの一般的な例と新たな例をいくつかご紹介します。

• ユースケース: 異なるビジネス アプリケーション間で見込み顧客 / 顧客をシームレスに同期する（例: CRM からマーケティング自動化）
• サーバーレス ソリューション: HTTP トリガーの Cloud Run functions の関数がソースシステム（Salesforce など）から Webhook を受信し、データを変換して、宛先システムの API（HubSpot など）を呼び出します。多くの場合、認証情報には Secret Manager が使用されます。
• Google Cloud サーバーレス プロダクト: Cloud Run functions、Secret Manager

• ユースケース: 定期レポートの生成と配布を自動化する
• サーバーレス ソリューション: Cloud Scheduler ジョブが Pub/Sub を介して Cloud Run functions の関数を毎日トリガーします。この関数はデータ ウェアハウス（BigQuery など）をクエリし、データを処理してレポートを作成し、メール API を介して送信します。
• Google Cloud サーバーレス プロダクト: Cloud Scheduler、Pub/Sub、Cloud Run functions、BigQuery

• ユースケース: アイドル状態のコンピューティング リソースを自動的に特定して管理することで、クラウド費用を削減する
• サーバーレス ソリューション: 夜間の Cloud Scheduler ジョブが Pub/Sub を介して Cloud Run functions の関数を毎日トリガーします。この関数は、Compute Engine API と Cloud Monitoring を使用してアイドル状態のインスタンスを特定し、それらを自動的に停止または削除して、アクションを Cloud Logging に記録します。
• Google Cloud サーバーレス プロダクト: Cloud Scheduler、Pub/Sub、Cloud Run functions、Cloud Monitoring、Cloud Logging

• ユースケース: 大量のストリーミング データ（ユーザー アクティビティなど）を処理して補完し、即座に分析情報とアクションを得る
• サーバーレス ソリューション: ユーザーのクリックストリーム イベントは Pub/Sub にストリーミングされます。Cloud Run functions 関数（または Cloud Run サービス）がこれらのイベントを消費し、Firestore のデータで補完してから、そのデータを別の Pub/Sub トピックに公開して、BigQuery でリアルタイム分析を行ったり、おすすめをパーソナライズしたりします。
• Google Cloud サーバーレス プロダクト: Pub/Sub、Cloud Run functions、Cloud Run、Firestore、BigQuery

• ユースケース: コードの変更に応じてマイクロサービスのビルド、テスト、デプロイを自動化する
• サーバーレス ソリューション: Cloud Build トリガーが Git リポジトリ（Cloud Source Repositories など）をモニタリングし、コードが commit されると、Cloud Build がテストを実行し、コンテナ イメージを Artifact Registry にビルドし、新しいバージョンを Cloud Run に自動的にデプロイします。
• Google Cloud サーバーレス プロダクト: Cloud Build、Cloud Run、Artifact Registry、Cloud Source Repositories

• ユースケース: 最適化された画像バリアント（サムネイル、さまざまな形式など）をアップロード時に自動的に生成する
• サーバーレス ソリューション: 新しい画像が Cloud Storage バケットにアップロードされると、Cloud Run functions の関数がアクティブになります。この関数は画像を処理（サイズ変更、形式変換）し、新しいバージョンを Cloud Storage に保存して、Firestore のメタデータを更新します。
• Google Cloud サーバーレス プロダクト: Cloud Storage、Cloud Run functions、Firestore

• ユースケース: Llama 3.1、Gemma 2、Mistral などの LLM を使用してリアルタイムの AI 推論を実行する
• サーバーレス ソリューション: Cloud Run は、Gemini API、Vertex AI エンドポイント、GPU 対応の Cloud Run サービスでホストされているモデルなどの AI モデルと統合されます。また、スケーラブルな API エンドポイントとして機能し、AI エージェントをホストすることもできます。
• GCP サーバーレス プロダクト: Cloud Run、Cloud Storage、Firestore

サーバーレス コンピューティングの大きなデメリットの一つは、まだ比較的新しいテクノロジーであるということです。そのため、現時点では、考えられるすべてのユースケースに対応できるわけではありません。

また、サーバーレス コンピューティングが進化し続けるにつれて、現存する弱点の一部が時間とともに解決されることも明らかです。特に、サーバーレスのオープンソース実装や、さまざまなプラットフォームや環境でソリューションを移植できるようにクラウド サービスをよりオープンにする方法については、すでに多くの取り組みが行われています。

• ユースケースの適合性が限定的: サーバーレス アーキテクチャは、長時間実行されるプロセスや、非常に低いレイテンシが要求されるケースなど、特定の要件があるアプリケーションには必ずしも適していない
• パフォーマンスの制約: サーバーレス関数では、コールド スタート（最初の実行の遅延）が発生する可能性があり、実行時間やメモリに制限がある場合もある
• ベンダー ロックイン: サーバーレス アプリケーションをクラウド プロバイダ間で移行する場合、API や構成の違いにより、作業が複雑になる可能性がある
• サーバーの可視性の低下: デベロッパーに対して基盤となるインフラストラクチャの可視性が限られているため、パフォーマンスの問題のトラブルシューティングやリソース使用率の最適化が困難
• 起動が遅い: サーバーレス関数では、関数の呼び出しに遅延が発生する「コールド スタート」が発生することがあり、レイテンシに影響する可能性がある