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

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

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

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

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

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

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

サーバーレスアーキテクチャは、開発者からサーバーの管理を抽象化し、基盤となるインフラの処理をクラウドプロバイダーに依存する。一般的な仕組みはこうだ：
1. 関数の作成： 開発者は個々の関数としてコードを記述し、各関数は特定のタスクやサービスを実行するように設計されている。サーバーレス・アーキテクチャは、Function-as-a-Service（ファンクション・アズ・ア・サービス）または ファース.

2. 機能展開： 関数はパッケージ化され、クラウドサービスプロバイダーが提供するサーバーレスプラットフォームにデプロイされる。最も一般的なサーバーレスプラットフォームは、AWS Lambda、Azure Functions、Google Cloud Functionsだ。

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

4. オートスケーリング： イベントが発生すると、サーバーレス・プラットフォームは自動的に基礎となるリソースをスケールしてワークロードに対応する。リクエストが急増した場合、クラウド・プロバイダーはより多くのリソースを提供する。

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

6. 請求書： 課金は、関数が実際に使用した実行時間とリソースに基づいて行われます。実行ごとに課金され、実行中に割り当てられたCPUやメモリなどの計算リソースに対して課金されます。

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

8. ログとモニタリング サーバーレス・プラットフォームは通常、組み込みのロギングとモニタリング・ツールを提供し、開発者がパフォーマンスを追跡したり、機能の問題をトラブルシューティングしたりできるようにしている。

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

サーバーレス開発は従来の開発に代わるものであるため、サーバーレスアプリケーションの設計、デプロイ、管理方法を明確に理解するために、以下の用語や概念に精通しておく必要がある：
召喚： サーバーレス関数の実行をトリガーするイベント。HTTPリクエスト、データベースの更新、スケジュールされたタイマーなどが例として挙げられる。

期間 サーバーレス関数の実行にかかる時間で、実行コストを計算する際の要素となる。

コールドスタート： サーバーレス機能を最初に実行することで、クラウドプロバイダーがリソースをプロビジョニングし、実行環境をセットアップする。コールドスタートでは、ウォームスタートに比べてさらに待ち時間が発生する。

ウォームスタート： 実行環境がすでに準備されているときにサーバーレス関数の後続実行を行うことで、コールドスタートと比較して応答時間が短縮される。

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

タイムアウト： サーバーレス関数の実行時間の最大許容値。関数がこの制限を超えると強制的に終了し、結果が返されなくなる可能性があります。

イベント・ソース サーバーレス機能をトリガーするイベントの発生源。イベントソースの例としては、Amazon S3バケット、APIゲートウェイ、メッセージキュー、データベースの更新などがある。

無国籍： サーバーレス関数は通常ステートレスで、呼び出しの間にデータを保持しない。必要なステートは、データベースやストレージ・サービスに外部保存する必要がある。

資源配分： サーバーレス関数のCPUやメモリなどの計算リソースの指定。これらのリソースは、関数を定義する際に開発者が選択することが多い。

オートスケーリング： クラウドプロバイダーによるサーバーレスリソースの自動調整により、さまざまなワークロードに対応し、最適なパフォーマンスを確保する。

サーバーレス・データベース: サーバーレスデータベースは、インフラを公開することなく、弾力的にスケーリングできるデータベースである。 Couchbase Capella™ DBaaS は完全に管理されたサーバーレス・データベースの例である。

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

サーバーレスアーキテクチャは汎用性が高いものの、すべてのユースケースに最適な選択というわけではありません。長時間実行するタスク、高い計算要件、一貫性のあるワークロードを持つアプリケーションでは、従来のサーバーベースアーキテクチャの方がメリットが大きいことがよくあります。サーバーレスがアプリケーションに適しているかどうかを判断する際には、具体的な要件とサーバーレス独自の強みを考慮するようにしてください。

サーバーレスアーキテクチャの使用例

サーバーレスアーキテクチャの最も一般的で最適なユースケースには、以下のようなものがある：
ウェブとモバイルアプリ： ウェブやモバイルアプリのバックエンドを処理し、コンテンツを提供し、ユーザーリクエストを処理し、ユーザー認証を管理する。

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

IoTだ： センサーデータでイベントをトリガーするIoTデバイスからのデータ処理と分析を効率的に管理します。

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

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

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

ユーザー認証と承認： ユーザー認証と認可のためのアイデンティティ・アクセス管理（IAM）サービスは、サーバーレス機能に適している。

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

チャットボットとバーチャルアシスタント： 自然言語によるリクエストを処理し、応答を生成する機能を備えた会話型インターフェースを構築する。

データと画像処理： 画像サイズ変更、フォーマット変換、データ変換など、ユーザーの操作を最小限に抑えるタスクを実行します。

スケジュールされたタスク： データバックアップ、レポート作成、データベースメンテナンスなどの定期的なタスクを自動化します。

マイクロサービス： より大きなアプリケーションの中で個々のマイクロサービスを作成・管理し、容易なスケーリングと独立したデプロイを可能にします。

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

サーバーレスとコンテナの比較

一見すると、サーバーレスアーキテクチャはコンテナアーキテクチャやマイクロサービスアーキテクチャと混同されることがある。実際には、サーバーレスは両者とは全く異なるものであり、何が異なるのかを説明する。

何 容器 とサーバーレスの共通点は、どちらも開発者がホスト環境を抽象化してアプリケーションコードをデプロイできるようにすることだ。しかし、重要な違いの1つは、サーバーレスがサーバー管理を完全に抽象化するのに対し、コンテナは開発者がインフラをよりコントロールしながら独自のサーバー環境を管理できることだ。

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

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

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

マイクロサービス は、アプリケーションを、APIを介して通信し、複雑でモジュール化された機能を提供するために連携する、小規模で独立してデプロイ可能なサービスの集合体として構造化するソフトウェアアーキテクチャパターンである。マイクロサービスとサーバーレスアーキテクチャの混同は、モジュール性とスケーラビリティを重視する両者の共通点から生じることが多い。さらに境界線を曖昧にしているのは、より大規模なマイクロサービスベースのアプリケーションの中で、サーバーレス機能がマイクロサービスとして機能するなど、両者が併用されることが多いことだ。

類似点はあるものの、サーバーレスとマイクロサービスには以下のような独自の特徴があり、両者は一線を画している：

インフラ管理

• マイクロサービス 開発者は、サーバーとコンテナのオーケストレーションをコントロールできる。
• サーバーレス サーバー管理は完全に抽象化され、開発者は基盤となるインフラを扱う必要がない。

実行モデル

• マイクロサービス 専用サーバーインスタンスで継続的に実行される。
• サーバーレス 関数はイベントやトリガーに反応して実行される。この違いは、サーバーレスアプリケーションがコールドスタートを経験する可能性があるため、レスポンスタイムの違いにつながる可能性がある。

コストモデル

• マイクロサービス は、サーバー・リソースのプロビジョニングと保守を必要とする。このため、利用が少ない期間でも継続的にコストがかかる可能性があります。
• サーバーレス は、実際の機能実行に基づく従量課金モデルに従う。これは、散発的なワークロードの場合、よりコスト効率が高くなります。

モジュール性

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

スケーラビリティ

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

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

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

自動スケーリング： サーバーレス・アーキテクチャ・プラットフォームは、入力されるワークロードに基づいてリソースを自動的に増減します。これにより、アプリケーションはさまざまなレベルのトラフィックに対応できるようになり、手動による介入なしに高い可用性とパフォーマンスを実現できます。

コスト効率： サーバーレスでは、関数の実行中に実際に使用されたコンピュート・リソースに対してのみ支払いが発生します。アイドルタイムに関連するコストは発生しないため、特に予測不可能なトラフィックや散発的なトラフィックを伴うワークロードでは、費用対効果が高くなります。

オペレーション・オーバーヘッドの削減： サーバーレスはサーバー管理タスクを抽象化するため、開発者はインフラのメンテナンスよりもコードに集中できる。これにより、DevOpsの必要性が減り、デプロイとスケーリングが簡素化される。

より速い開発： サーバーレスは、サーバーやインフラを管理する必要性を排除することで、開発プロセスを加速させる。開発者はコードを素早く反復してデプロイできるため、アプリケーションの市場投入までの時間が短縮される。

レジリエンス： サーバーレス機能は一般的にステートレスであり、データの永続性を外部ストレージサービスやデータベースに依存する設計を促進する。これは、より弾力的で耐障害性の高いアプリケーションにつながる可能性がある。

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

ベンダーの囲い込みを減らす： 多くの機能は比較的ベンダーに依存しないように設計できるため、移行や異なるクラウドプロバイダーのサービスの統合が容易になる。次のサーバーレスの制限のセクションで説明するように、これは必ずしもそうではない。

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

エネルギーと資源の効率化： サーバーレス・プラットフォームの自動スケーリングとリソース管理は、エネルギー効率とリソース利用の改善につながり、環境への影響を軽減する。

サーバーレスアーキテクチャの限界

サーバーレスアーキテクチャには多くの利点がある一方で、限界もある。サーバーレスの特定の特徴は、利点や課題として現れる可能性がある。特定のアプリケーションに対してサーバーレスを評価する際には、以下に関連する要件や制約を考慮してください：
コールドスタート： サーバーレス関数は、クラウドプロバイダーが新しい実行環境を初期化する必要があるため、関数が最初に呼び出されたときに遅延が発生する可能性がある。この遅延は、常に高速なレスポンスタイムを必要とするアプリケーションにとって問題となる可能性がある。

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

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

ベンダーロックイン： 多くの機能は比較的ベンダーに依存しないように設計できるが、アプリケーションにはプラットフォーム固有の構成や統合があり、別のクラウド・プロバイダーに移行するのが難しい場合がある。

複雑なデバッグ： サーバーレスアプリケーションのデバッグとトラブルシューティングは、サーバーレスアーキテクチャではより困難になる可能性がある。なぜなら、機能が分散していることと、サーバーに直接アクセスできないことが、問題の特定と解決を難しくしているからだ。

現地でのテストは限定的： ローカルでのテストではクラウドでの実行環境を完全に再現できない可能性があるため、サーバーレス関数をローカルで開発・テストすることは困難な場合がある。開発者は多くの場合、徹底的なテストのためにサーバーレスプラットフォームに関数をデプロイする必要がある。

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

開発者が好きなコーディング言語やクラウド・サービス・プロバイダーを使ってサーバーレス・アプリケーションを構築、デプロイ、管理できるサーバーレス・コンピューティング・プラットフォームやツールは数多くある。最も人気のあるものをいくつか紹介しよう：

プラットフォーム

アマゾンのAWSラムダ は様々なプログラミング言語をサポートし、他のAWSサービスとシームレスに統合する。AWSはまた、RESTful APIを作成し、Lambda関数をトリガーするためのAPIゲートウェイも提供している。

マイクロソフトのAzure Functions は、Azureクラウドエコシステム内で提供されるサーバーレス製品だ。複数の言語をサポートし、Azureサービスとの統合を提供するため、Windowsベースのアプリケーションにとって強力な選択肢となる。

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

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

アリババ・クラウド・ファンクション・コンピュート 開発者はAlibaba Cloudエコシステムでアプリケーションを構築し、複数の言語を使用して他のAlibaba Cloudサービスと統合することができます。

ツール

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

オープンファース は、コンテナベースの機能のためのオープンソースのサーバーレス・フレームワークである。Dockerコンテナを使ってサーバーレス機能を構築し、実行することができる。

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

結論

サーバーレスアーキテクチャは、ウェブやモバイルアプリケーション、IoT、リアルタイムデータ処理、その他の一般的なユースケースに人気がある。管理責任は、AWS Lambda、Azure Functions、Google Cloud Functionsのようなクラウドプロバイダーに委ねられるため、クラウドプロバイダーは基盤となるインフラを処理し、ワークロードの変化に合わせてリソースを自動的にスケールさせることができる。しかし、サーバーレスはすべてのユースケースに理想的というわけではなく、特定のワークロードや長時間実行するタスクは、従来のサーバーベースのアプローチの方が適している場合もある。

サーバーレス・アーキテクチャと関連テクノロジーについてもっと知りたい方は、以下のリソースをご覧ください：

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