サーバーレスアーキテクチャ

サーバーレスアーキテクチャとは何ですか？

サーバーレスアーキテクチャとは、開発者が従来のサーバーを管理することなくアプリケーションを構築および実行できるクラウドコンピューティングモデルです。サーバー自体は存在しますが、それらはクラウド上にあり、クラウドプロバイダーがインフラストラクチャ、スケーリング、リソース割り当てを自動的に処理します。.

サーバーレスアプリケーションにおいて、開発者は通常、イベントやトリガーに応答して実行される独立した関数としてコードを記述し、クラウドプロバイダーは実際に使用されたコンピューティングリソースに対してのみ課金します。このアプローチにより、アプリケーション開発が簡素化され、運用のオーバーヘッドが削減され、迅速な拡張が可能になるため、マイクロサービスやイベント駆動型アプリケーションに最適です。.

このページで取り上げている：

• サーバーレスアーキテクチャの仕組み
• サーバーレスアーキテクチャの主要な概念
• サーバーレスアーキテクチャを使用するタイミング
  
• サーバーレスアーキテクチャの利点
  
• サーバーレスアーキテクチャの制限事項
• サーバーレスコンピューティングツール
• 結論

サーバーレスアーキテクチャの仕組み

サーバーレスアーキテクチャは、開発者からサーバー管理の負担を取り除き、基盤となるインフラストラクチャの管理をクラウドプロバイダーに任せるものです。通常、仕組みは以下の通りです。

1. 関数の作成 開発者は個別の関数としてコードを書き、それぞれの関数は特定のタスクやサービスを実行するように設計されています。サーバーレスアーキテクチャは、Function-as-a-Service または FaaS.

2. 関数のデプロイ: 関数はパッケージ化され、クラウドサービスプロバイダーが提供するサーバーレスプラットフォームにデプロイされます。最も一般的なサーバーレスプラットフォームは、AWS Lambda、Azure Functions、およびGoogle Cloud Functionsです。.

3. イベントトリガー： 関数は、特定のイベントやトリガーに応答して実行されるように設定されます。イベントには、HTTPリクエスト（API Gatewayなど）、データの変更（データベースの更新など）、タイマー、ファイルのアップロード、その他さまざまなものが含まれます。クラウドプロバイダーがイベントソースを管理し、関連する関数を自動的に呼び出します。.

4. オートスケーリング イベントが発生すると、サーバーレスプラットフォームはワークロードに対応するために基盤となるリソースを自動的にスケーリングします。関数へのリクエストが急増した場合、クラウドプロバイダーはより多くのリソースをプロビジョニングします。.

5. 実行 イベントが関数をトリガーすると、サーバーレスプラットフォームはその関数のコンテナまたは実行環境を初期化します。関数内のコードが実行され、必要なリソースやデータにアクセスできるようになります。関数がタスクを完了した後、コンテナは短期間ウォーム状態を維持し、後続のリクエストをより早く実行できるようにします。.

6. 請求： 課金は、関数の実際の実行時間と使用されたリソースに基づいて行われます。実行回数ごと、および実行中に割り当てられたCPUやメモリなどのコンピュートリソースに対して料金が発生します。.

7. 無国籍 サーバーレス関数は通常ステートレスであり、つまり呼び出しの間で情報を保持しません。必要な状態やデータは、多くの場合データベースやストレージサービスなどの外部に保存する必要があります。.

8. ログとモニタリング： サーバーレスプラットフォームは通常、組み込みのロギングおよびモニタリングツールを提供しており、開発者は関数のパフォーマンスを追跡し、問題のトラブルシューティングを行うことができます。.

サーバーレスアーキテクチャの主要な概念

サーバーレス開発は従来型開発の代替手段であるため、サーバーレスアプリケーションの設計、デプロイ、管理の方法を明確に理解するために、以下の用語と概念を習得する必要があります。

呼び出し サーバーレス関数の実行を引き起こすイベント。例えば、HTTPリクエスト、データベースの更新、または定期的なタイマーなどがあります。.

期間 サーバーレス関数の実行にかかる時間であり、実行コストを算出する際の要素の一つ。.

コールドスタート サーバーレス関数の初回実行。クラウドプロバイダーがリソースをプロビジョニングし、ランタイム環境をセットアップする。コールドスタートは、ウォームスタートに比べて追加のレイテンシをもたらす。.

ウォームスタート コールドスタートと比較して応答時間が速くなる、ランタイム環境がすでに準備されている状態でのサーバーレス関数の2回目以降の実行。.

同時実行制限： サーバーレスプラットフォームで許可される同時関数実行の最大数。この制限は、同時リクエストやイベントを処理する能力に影響を与える可能性があります。.

タイムアウト: サーバーレス関数の実行が許可される最大時間。関数がこの制限を超えた場合、強制終了され、その結果が返されない可能性があります。.

イベントソース: サーバーレス関数をトリガーするイベントの発生源。イベントソースの例には、Amazon S3 バケット、API ゲートウェイ、メッセージキュー、データベースの更新などがあります。.

無国籍 サーバーレス関数は通常ステートレスであり、つまり呼び出しの間でデータを保持しません。必要な状態はすべて、データベースやストレージサービスに外部保存する必要があります。.

リソース配分 サーバーレス関数のCPUやメモリなどのコンピュートリソースの仕様。これらのリソースは通常、関数を定義する際に開発者によって選択されます。.

オートスケーリング クラウドプロバイダーが変動するワークロードに対応し最適なパフォーマンスを確保するためにサーバーレスリソースを自動的に調整すること。.

サーバーレスデータベース: サーバーレスデータベースとは、稼働基盤を意識させることなく、弾力的にスケールするデータベースのことです。 Couchbase Capella™ DBaaS は完全マネージド型のサーバーレスデータベースの例です。.

サーバーレスアーキテクチャを使用するタイミング

サーバーレスアーキテクチャは汎用性が高いものの、あらゆるユースケースに最適な選択肢というわけではありません。長時間のタスク、高い計算要件、または安定したワークロードを持つアプリケーションには、従来のサーバーベースのアーキテクチャの方が適していることがよくあります。アプリケーションにとってそれが正しい選択であるかを決定する際には、特定の要件とサーバーレス特有の長所を必ず考慮するようにしてください。.

サーバーレスアーキテクチャのユースケース

サーバーレスアーキテクチャの最も一般的で最適なユースケースには、以下のようなものがあります。

ウェブおよびモバイルアプリ： ウェブおよびモバイルアプリのバックエンドの処理、コンテンツの配信、ユーザーリクエストの処理、およびユーザー認証の管理。.

API RESTfulおよびGraphQL APIを自動スケールし、他のサービスと簡単に統合できます。.

IoT センサーデータでイベントを発生させるIoTデバイスからのデータ処理と分析を効率的に管理する。.

リアルタイムデータ処理 クリックストリーム分析、ログ処理、イベント駆動型分析などのリアルタイムデータストリームを処理します。.

バッチ処理 データETL（抽出、変換、ロード）、レポート生成、データクレンジングなどの定期またはオンデマンドのバッチジョブを実行します。.

ファイルおよびデータ保存タスク： クラウドストレージサービスと連携して、ファイルのアップロード、ダウンロード、およびデータ操作を管理します。.

ユーザー認証と認可： ユーザー認証および認可のためのアイデンティティ・アクセス管理（IAM）サービスは、サーバーレス関数に適しています。.

通知サービス： 特定のエントやトリガーに応じて、メール、SMS、プッシュ通知などの通知やアラートを送信します。.

チャットボットとバーチャルアシスタント： 関数が自然言語のリクエストを処理し、応答を生成する、会話型インターフェースを構築します。.

データおよび画像処理： 画像のサイズ変更、フォーマット変換、データ変換など、ユーザーの操作がほとんど必要ないタスクを実行します。.

スケジュールされたタスク: データバックアップ、レポート生成、データベース保守などの定期的タスクを自動化します。.

マイクロサービス 大規模なアプリケーション内で個々のマイクロサービスを作成および管理し、容易なスケーリングと独立したデプロイを可能にします。.

セキュリティおよびコンプライアンスサービス： 侵入検知、監視、コンプライアンス監査などのセキュリティ関連機能を実装する。.

サーバーレス対コンテナ

一見したところ、サーバーレスアーキテクチャはコンテナアーキテクチャやマイクロサービスアーキテクチャといくつかの類似点があるため、混同されることがあります。実際には、サーバーレスはそれらのどちらとも大きく異なっており、何がそれらを区別しているのかをこれから説明します。.

何 コンテナ サーバーレスと共通しているのは、どちらもホスト環境を抽象化することで、開発者がアプリケーションコードをデプロイできるようにする点です。しかし、主な違いの一つは、サーバーレスがサーバー管理を完全に抽象化する一方で、コンテナは開発者が独自のサーバー環境を管理し、インフラストラクチャをより詳細に制御できるようにする点です。.

軽量な仮想化の一形態であるコンテナは、アプリケーションとその依存関係を、共有オペレーティングシステム上で独立したインスタンスとして実行される、隔離された一貫性のある環境にパッケージ化します。コンテナは、開発環境から本番環境に至るまで、さまざまな環境でアプリケーションが確実に一貫して動作するようにする方法を提供し、ソフトウェアをパッケージ化および配布するための標準化された方法を提供します。コンテナは通常、長時間実行され、単一のコンテナ内に複数のプロセスを含めることができます。.

要するに、サーバーレスコンピューティングはサーバー管理を抽象化し、イベント駆動型の短時間タスクに最適である一方、コンテナはサーバー環境に対する制御性が高く、長時間稼働するプロセスや一貫したワークロードに適しています。どちらを選択するかは、アプリケーションの具体的な要件と、基盤となるインフラストラクチャに対する制御の度合いによって決まります。場合によっては、1つのアプリケーション内で異なるコンポーネントに対して両方のテクノロジーを組み合わせて使用することもあります。.

サーバーレスとマイクロサービス

マイクロサービス アプリケーションを、API経由で通信し、複雑でモジュール化された機能を提供するために連携する、小さく、独立してデプロイ可能なサービスの集まりとして構築するソフトウェアアーキテクチャパターンです。マイクロサービスとサーバーレスアーキテクチャの間の混乱は、モジュール性と拡張性を共に重視していることから生じることがよくあります。さらに境界線を曖昧にしているのは、サーバーレス関数がより大きなマイクロサービスベースのアプリケーション内でマイクロサービスとして機能するなど、これらが組み合わせて使用されることが多い点です。.

類似点があるにもかかわらず、サーバーレスとマイクロサービスには、それらを区別する以下の分野において独自の特性があります：

インフラストラクチャ管理

• マイクロサービス – 開発者はサーバーとコンテナオーケストレーションの制御を保持します。.
• サーバーレス サーバー管理は完全に抽象化されており、開発者は基盤となるインフラストラクチャを意識する必要がありません。.

実行モデル

• マイクロサービス – 専用サーバーインスタンス上で継続的に実行する。.
• サーバーレス 関数はイベントやトリガーに応じて実行されます。この違いにより、サーバーレスアプリケーションではコールドスタートが発生するため、応答時間に差が生じることがあります。.

コストモデル

• マイクロサービス – サーバーリソースのプロビジョニングと維持が必要となります。これにより、利用が少ない期間でも継続的なコストが発生する可能性があります。.
• サーバーレス 実際の関数実行に基づく従量課金制を採用しており、これは単発のワークロードにおいてより費用対効果が高くなる可能性があります。.

モジュール性

• マイクロサービス – アプリケーションは、小さく独立したサービスに分割されている。.
• サーバーレス 開発者はコードを個別の機能単位として記述する。.

スケーラビリティ

• マイクロサービス – 各サービスの独立したスケーリングを可能にする。.
• サーバーレス 個々の関数を自動的にスケーリングします。.

サーバーレスアーキテクチャの利点

サーバーレスアーキテクチャには、多くのアプリケーションやユースケースで魅力的な選択肢となる幅広いメリットがあります。最も強力な利点は以下の通りです。

自動スケーリング サーバーレスアーキテクチャのプラットフォームは、受信するワークロードに応じてリソースを自動的に上下にスケーリングします。これにより、手動での介入なしで、アプリケーションがさまざまなレベルのトラフィックを処理できるようになり、高い可用性とパフォーマンスが提供されます。.

コスト効率： サーバーレスでは、関数の実行中に使用された実際の計算リソースに対してのみ料金が発生します。アイドル時間に関連するコストは一切かからないため、特に予測不可能なトラフィックや散発的なワークロードに対して費用対効果が高くなります。.

運用のオーバーヘッドの削減： サーバーレスはサーバー管理タスクを抽象化し、開発者がインフラストラクチャの保守ではなくコードに集中できるようにします。これにより、DevOpsの労力が軽減され、デプロイとスケーリングが簡素化されます。.

より高速な開発： サーバーレスは、サーバーやインフラストラクチャの管理を不要にすることで、開発プロセスを加速させます。開発者はコードの反復とデプロイを迅速に行うことができ、その結果、アプリケーションの市場投入までの時間を短縮できます。.

レジリエンス サーバーレス関数は通常ステートレスであり、データの永続性を外部ストレージサービスやデータベースに依存する設計を促進します。これにより、より回復力が高くフォールトトレラントなアプリケーションを実現できます。.

組み込みのロギングとモニタリング： サーバーレスプラットフォームは多くの場合、監視やログ記録のための組み込みツールを提供しており、開発者がパフォーマンスの追跡、問題のトラブルシューティング、アプリケーションの挙動に関する洞察を得ることを可能にします。.

ベンダーロックインの軽減： 多くの機能は比較的ベンダーに依存しないように設計できるため、それらの移行や、異なるクラウドプロバイダーのサービスの統合が容易になります。次のセクションで説明するサーバーレスの制限事項からもわかるように、常にそうであるとは限りません。.

高い可用性： サーバーレスプラットフォームは、冗長性とフェイルオーバーの仕組みが組み込まれており、可用性が高くなるように設計されています。これにより、障害が発生した場合でも、アプリケーションにアクセスでき、応答性を維持できるようになります。.

エネルギーおよび資源効率： サーバーレスプラットフォームの自動スケーリングとリソース管理により、エネルギー効率とリソース利用率が向上し、環境負荷を軽減することができます。.

サーバーレスアーキテクチャの制限事項

サーバーレスアーキテクチャには多くの利点がある一方で、制限もあります。サーバーレスの特定の特性は、メリットとしても課題としても現れます。特定のアプリケーションでサーバーレスを評価する際には、以下の項目に関連する要件や制約を考慮してください。

コールドスタート： サーバーレス関数は、クラウドプロバイダーが新しい実行環境を初期化する必要があるため、最初に呼び出されたときに遅延が発生する場合があります。このレイテンシは、一貫して高速な応答時間を必要とするアプリケーションにとって問題となる可能性があります。.

リソースの制約： サーバーレス・プラットフォームには、メモリや実行時間制限などのリソース制約課せられます。これらの制約は、計算集約型のタスクや長時間の処理を必要とするアプリケーションにとって制限となる場合があります。.

無国籍 サーバーレス関数は通常ステートレスであり、つまり呼び出しの間でデータを保持しません。これは（上記で説明したように）耐障害性の向上に役立つ一方で、データ永続化のために外部データベースやストレージサービスを使用すると、一部のアプリケーションにおいて複雑さが増す可能性があります。.

ベンダーロックイン： 多くの関数は特定のベンダーに依存しないよう比較的柔軟に設計できますが、アプリケーションによっては、異なるクラウドプロバイダーへの移行を困難にするプラットフォーム固有の設定や統合が含まれている場合があります。.

複雑なデバッグ： サーバーレスアーキテクチャでは、関数の分散的な性質や直接的なサーバーアクセスの欠如により、問題の特定と解決が難しくなるため、サーバーレスアプリケーションのデバッグやトラブルシューティングはより困難になる場合があります。.

ローカルテストの制限： サーバーレス関数のローカルでの開発とテストは、ローカルでのテストがクラウド上の実行環境を完全に再現できない場合があるため、困難を伴うことがあります。開発者は十分なテストを行うために、関数をサーバーレスプラットフォームにデプロイしなければならないことがよくあります。.

サーバーレスコンピューティングツール

開発者がお気に入りのプログラミング言語やクラウドサービスプロバイダーを利用してサーバーレスアプリケーションを構築、デプロイ、管理できるようにするサーバーレスコンピューティングプラットフォームやツールは数多く存在します。以下はその中でも特に人気のあるものです：

プラットフォーム

Amazon Web Services (AWS) の Lambda 様々なプログラミング言語をサポートし、他のAWSサービスともシームレスに統合します。AWSはまた、RESTful APIの作成やLambda関数のトリガーを行うためのAPIゲートウェイも提供しています。.

Microsoft Azure Functions Azureクラウドエコシステム内のサーバーレスサービスです。複数の言語をサポートし、Azureサービスとの統合を提供するため、Windowsベースのアプリケーションにとって強力な選択肢となります。.

Google Cloud Functions 複数のプログラミング言語をサポートし、他のGoogle Cloudサービスともうまく統合できるため、Google Cloudエコシステム内でアプリケーションを構築するのに適しています。.

IBM Cloud Functions Apache OpenWhiskフレームワークをベースにしており、さまざまな言語を使用してIBM Cloudサービスと統合することができます。.

アリババクラウド Function Compute 開発者が複数の言語を使用してAlibaba Cloudエコシステム内でアプリケーションを構築し、他のAlibaba Cloudサービスと統合できるようにします。.

ツール

ネットリファイ 静的ウェブサイトのホスティングで最もよく知られているプラットフォームですが、バックエンドサービス、API、ワークフローを構築するためのサーバーレス関数も提供しています。.

OpenFaaS コンテナベースの関数向けのオープンソースのサーバーレスフレームワークです。Dockerコンテナを使用してサーバーレス関数を構築および実行できます。.

核分裂 もう一つのオープンソースのKubernetesネイティブなサーバーレスフレームワークであり、複数の言語をサポートし、Kubernetesクラスター上で簡単にデプロイできるように設計されています。.

結論

サーバーレスアーキテクチャは、開発者がサーバーの管理ではなくコードの記述に集中できるため、Web・モバイルアプリケーション、IoT、リアルタイムデータ処理、その他の一般的なユースケースで人気があります。管理責任はAWS Lambda、Azure Functions、Google Cloud Functionsなどのクラウドプロバイダーにオフロードされるため、基盤となるインフラストラクチャを処理し、ワークロードの変化に対応してリソースを自動的にスケーリングできます。しかし、サーバーレスがすべてのユースケースに最適であるとは限らず、特定のワークロードや長時間実行されるタスクには、従来のサーバーベースのアプローチの方が適している場合もあります。.

サーバーレスアーキテクチャおよび関連技術について詳しく学ぶには、以下のリソースをご覧ください：

クラウドコンピューティングによるサーバーレスアーキテクチャ
Couchbaseの2023年予測 – エッジコンピューティング、サーバーレス、その他
カペラ・アプリ・サービス（BaaS）
私たちのウェブサイトをご覧ください。 コンセプト・ハブ データベースに関連する他のトピックについて学ぶ.