はじめに
サーバーレスコンピューティングは、クラウドサービスを使用してアプリケーションを設計・デプロイする新しい方法を提供します。しかし、それは一体何であり、どのように機能するのでしょうか？
この記事では、サーバーレスとは何か、その仕組み、そして開発体験にどう影響するかについて見ていきます。サーバーレスが提供する利点や、適さない可能性のあるシナリオについても説明します。これにより、追加の調査を行い、サーバーレスモデルがプロジェクトに適しているかどうかを判断するために必要な背景知識が得られるはずです。
すべてのアプリケーションデータを一元管理するには、Prisma Data Platformをご確認ください。
サーバーレスとはどういう意味か？
サーバーレスとは、処理能力が実際のサーバーとしてではなく、APIを介して公開されるモデルを指します。アプリケーションは、実行される環境を管理することなく、計算リソースを使用してコードを実行できます。
多くの点で、サーバーレスは、クラウドプロバイダーによるユーザー向けのリソース抽象化の次の論理的な進化を示しています。仮想化されたサーバーを介してリソースにアクセスする代わりに、プロバイダーは従量課金モデルを使用してリソース自体へのアクセスを提供します。異なる視点から見ると、サーバーレスは、より汎用的な計算ロジックのためのマネージドサービス（たとえば、マネージドデータベースインスタンスに似ています）です。
サーバーレスコンピューティング
ほとんどの場合、人々が「サーバーレス」という言葉を使うとき、それはサーバーレスコンピューティングを指しています。サーバーレスコンピューティングとは、ユーザーがAPIがヒットしたときにプロバイダーによって実行される関数、つまり計算ロジックを作成できるパラダイムです。このため、サーバーレスコンピューティングプロバイダーはしばしばFunctions as a Service（FaaS）プラットフォームと呼ばれます。
サーバーレスコンピューティングで開発する際には、プロバイダーに事前に実行させたいロジックを定義します。アプリケーションは、必要に応じて多数の個別の関数を利用するように設計できます。関数は、アプリケーションが公開されたエンドポイントを介して異なるコードを呼び出すと、オンデマンドで実行されます。関数自体は状態を保持しないため、関数によって生成された出力やデータは、呼び出し元に返されるか、外部ストレージにオフロードされます。
開発者として、サーバーレスを扱う場合、コードを実行するために使用される環境の維持について心配する必要はありません。さらに、このモデルは、スケーリングを管理することなく、さまざまなトラフィック量に対応する柔軟性を提供します。支払う費用は、使用する計算能力の量に直接関連付けられるため、事前にリソースを見積もり、割り当てる必要がありません。
サーバーレスデータベース
サーバーレスデータベースは、サーバーレスパラダイムをデータベース機能に適用します。実際には、これはバックエンドのサーバーリソース、スケーリング、データ管理がユーザーから抽象化されることを意味します。ユーザーは、さまざまなシナリオに対応するための容量計画の必要性を排除するAPI駆動型サービスとしてデータベースを使用できます。
一般に、サーバーレスデータベースは階層型アーキテクチャを使用して実装されます。ユーザーは、バックエンドリソースへのルーティングを自動的に処理するAPIまたはプロキシゲートウェイとやり取りできます。ゲートウェイの背後では、実行ワーカーのプールが受信したクエリのリクエストを処理します。実際のデータは第3層で管理され、どの実行ワーカーもアクセスおよび操作できます。
このモデルでは、計算リソースとストレージリソースの両方を、需要に応じてバックグラウンドで独立してスケーリングできます。ユーザーはスケーリングを制御しません。その代わり、実行したクエリと保存しているデータの量に対して課金されます。
トレードオフの検討
サーバーレスとは何か、そしてユーザーの視点からそれが一般的にどのように機能するかについて説明したので、サーバーレスソリューションが適している場所を特定し始めることができます。
サーバーレス技術は、あらゆる状況に合う万能なソリューションではありません。これらの新しいパラダイムは、開発、デプロイ、および管理のライフサイクルの一部を簡素化できますが、特定の種類のワークロードやアプリケーション設計で最も効果を発揮します。サーバーレスが適しているかどうかを示す可能性のあるアプリケーションや組織の特性をいくつか見てみましょう。
サーバーレスが良い選択であるのはいつか？
サーバーレス環境は、いくつかのシナリオで適している可能性があります。
システム管理経験が限られている場合
チームに豊富なシステム管理経験がない場合、サーバーレスはその責任を軽減する方法を提供します。アプリケーションコードを実行するために使用されるインフラストラクチャは、プラットフォームプロバイダーによって維持されるため、ビジネスロジックに集中できます。インフラストラクチャ管理を責任リストから排除することで、より迅速に開始し、プロジェクトが成熟しても速度を維持できます。
優れたスケーラビリティが必要な場合
開発者がサーバーレスプラットフォームに移行する主要な動機の一つは、上記の点と密接に関連しています。サーバーレスアーキテクチャは、スケーリングを懸念事項から取り除くことで、それを簡素化します。アプリケーションは現在数回の操作しか必要としないかもしれませんが、採用が進んだり、使用量の急増があったりすると、より多くの操作が必要になるかもしれません。
サーバーレスプラットフォームは、これらのシナリオに自動的に適応できます。これは、リソース割り当てが使用パターンを自動的に反映するため、インフラストラクチャが過剰または過少にプロビジョニングされることがないことを意味します。プロバイダーはすでにそれを行うためのソリューションを設計しているため、ピーク負荷や平均負荷を把握したり、スケーリングポリシーをテストして構成したりする必要はありません。
コストに敏感な場合
前述のとおり、サーバーレスプラットフォームはコストが大きな懸念事項である場合にも非常に魅力的です。サーバーレスでは、実行した操作に対してのみ料金を支払います。必要になるかもしれないという理由だけでアイドル状態のサーバーに料金を支払う必要はありません。これは開発ライフサイクル全体で役立ちます。開発システムとテストシステムは本番システムと同じプラットフォームを使用できるため、専用のコンテキストを維持するコストなしで、より正確にテストできます。
サーバーレスを避けるべき場合
サーバーレスモデルには多くの利点がありますが、あらゆる状況に適しているわけではありません。
アプリケーションがパフォーマンスに敏感な場合
アプリケーションがレイテンシーやパフォーマンスに敏感な場合、サーバーレスアーキテクチャではニーズを満たせない可能性があります。サーバーレスプラットフォームは使用量に応じてスケーリングできますが、使用量の増加が認識され、新しい需要に対応するようにシステムが構成されるまでには顕著な遅延があります。
これはしばしば「コールドスタート」問題と呼ばれ、使用量に顕著な変化があるたびにシステムに影響を与えます。この起動時間の増加により、以前のアクティビティレベルに関係なく一貫した応答時間が要求される多くのユースケースでサーバーレスは除外されます。
クラウドベースまたはベンダー固有のソリューションに抵抗がある場合
クラウドベースまたはベンダー固有のソリューションに抵抗があるか、それらを使用できない場合、サーバーレスプラットフォームを避けるという選択肢もあります。コンプライアンス、プライバシー上の懸念、または単純な好みからクラウドベースのインフラストラクチャが選択肢にならない場合、サーバーレスプラットフォームの使用も選択肢になりません。
サーバーレスプラットフォームは、アプリケーションがプロバイダーの実装に縛られるため、ベンダーロックインの事例でもあります。アプリケーションロジックを個別の関数のコレクションに分解することで、ワークロードがポータブルに見えるかもしれませんが、各サービスが機能する詳細が、移行に大きな投資をすることなくプロバイダーを変更することを妨げる可能性があります。
インフラストラクチャ管理の経験がすでにある場合
最後に、チームがすでにインフラストラクチャの管理と従来のデプロイメントが提供するコンテキストでの作業に慣れている場合、サーバーレスは多くの利点を提供しないかもしれません。たとえば、すでにインフラストラクチャとサービスを管理する堅牢なDevOpsチームがいる場合、サーバーレスが提供する利点はそれほど魅力的ではないかもしれません。
さらに、開発者はアプリケーションコードのテストやデバッグ方法に関して、サーバーレス環境では不可能またはアクセスしにくい可能性のある期待を持っているかもしれません。従来のインフラストラクチャを使用する開発者が行うのと同じ方法で、サーバーレスプラットフォームにデプロイされた関数をプロファイリングすることは不可能かもしれません。
プロジェクトでサーバーレスを評価する際には、これらのトレードオフをすべて考慮することが重要です。特定の状況では優れたソリューションですが、あなたのユースケースがそれに当てはまるかどうかを判断することが重要です。
まとめ
この記事では、「サーバーレス」が実際に何を意味するのか、そしてなぜそれが多くのプロジェクトにとって魅力的な選択肢となり得るのかを説明することに焦点を当てました。Functions as a Serviceモデルがアプリケーションサーバーの管理をプラットフォームプロバイダーにオフロードする方法や、サーバーレスデータベースサービスがデータベース操作をデータストレージから分離できる方法について話しました。その後、サーバーレス設計に最も適したシナリオと、それが適切なソリューションではない可能性がある場合について検討しました。
サーバーレスアプリケーション、データベース、プロバイダー、および設計に関しては、学ぶべきことが他にもたくさんあります。学習を続ける上で、以下のリソースが役立つかもしれません。
- サーバーレスコンピューティングおよびデータベースプロバイダー トップ13
- 一般的なサーバーレスの課題入門
- 従来のデータベース vs サーバーレスデータベース
- サーバーレス用語集
- Martin Fowlerのサーバーレスアーキテクチャに関するページ（Mike Roberts著）
- Cloud Academyの「サーバーレスコンピューティングとは」
すべてのアプリケーションデータを一元管理するには、Prisma Data Platformをご確認ください。
FAQ
サーバーレスアーキテクチャは、インフラストラクチャを管理することなくアプリケーションやサービスを構築・実行する方法です。
アプリケーションは依然としてサーバー上で動作しますが、すべてのサーバー管理はプロバイダーによって行われます。
サーバーレスアプリケーションとは、サーバーレスアーキテクチャで構築されたアプリケーションのことです。
アプリケーションは、サーバーのプロビジョニングや管理を必要としません。
サーバーレスであることは、本質的にインフラストラクチャの制御をプロバイダーに譲渡するため、プロバイダーはキー管理、認証、認可などのセキュリティサービスを提供します。
サーバーレスセキュリティは、セキュリティがアプリケーション自体を中心に構築されていないため、アプリケーションセキュリティに対する考え方を変える必要があります。プロバイダーがアプリケーションの機能周りのセキュリティを処理します。
サーバーレスバックエンドは、サーバーレスパラダイムをデータベース機能に適用したものです。
実際には、これはバックエンドのサーバーリソース、スケーリング、データ管理がユーザーから抽象化されることを意味します。ユーザーは、容量計画の必要性を排除するAPI駆動型サービスとしてデータベースを使用できます。
サーバーレスコンピューティングとは、APIがヒットしたときにプロバイダーによって実行される関数、つまり計算ロジックをユーザーが作成できるパラダイムです。
このため、サーバーレスコンピューティングプロバイダーはしばしばFunctions as a Service（FaaS）プラットフォームと呼ばれます。
