一般的なサーバーレスの課題入門

コールドスタート問題とは？

サーバーレスの大きなセールスポイントの 1 つは、アクティビティがない期間にゼロにスケールできることです。関数がアクティブに実行されていない場合、関数のリソースはスピンダウンされ、プラットフォームに容量が返され、これらのコンポーネントを予約するユーザーのコストが削減されます。これはコストの観点からは理想的です。つまり、ユーザーはコードが実際に実行される時間とリソースに対してのみ料金を支払うことになります。

この欠点は、リソースが完全にスピンダウンすると、次回実行する必要があるときに予測可能な遅延が発生することです。関数を実行するためにリソースを再割り当てする必要がありますが、これには時間がかかります。最近使用された「ホット」関数と、プラットフォームが実行環境を作成するのを待つ必要がある「コールド」関数では、パフォーマンス特性のセットが異なります。

開発者はコールドスタートにどのように対処しようとしていますか？

開発者とプラットフォームがこの問題に対処しようとする方法は数多くあります。一部の開発者は、関数に関連付けられたリソースをスタンバイ状態に保つために「ダミー」リクエストをスケジュールします。多くのプラットフォームは、開発者がリソースを自動的にスタンバイ状態に保つことができるように、サービスに追加のティアを追加しました。

これらのソリューションは、サーバーレス環境を構成するものについて少し境界線を曖昧にし始めています。コードがアクティブに実行されていないときに、開発者がスタンバイリソースの料金を支払うことを余儀なくされる場合、サーバーレスパラダイムの基本的な主張のいくつかについて疑問が生じます。

リソースを事前割り当てする最近の代替案は、より軽量なランタイム環境に切り替えることで問題を回避することです。V8 などのランタイムは、従来のサーバーレスとは大きく異なる実行戦略を持っており、異なる分離テクノロジーとより簡素化された環境を使用することで、コールドスタート問題を回避できます。より堅牢な環境に依存関係を持つ関数との互換性を犠牲にして、コールドスタートの問題を回避します。

クラウドフレンドリーなアーキテクチャの設計

アプリケーションがサーバーレスプラットフォームを使用するために満たす必要のある最初の要件は、クラウドフレンドリーな方法で設計されていることです。この議論の文脈では、少なくともこれは、アプリケーションが少なくとも部分的に、他のコンポーネントが通信できるクラウドサービスにデプロイ可能である必要があることを意味します。また、設計でモノリシック関数を実装することは可能ですが、サーバーレスモデルはマイクロサービスアーキテクチャに最適です。

この結果、アプリケーションは、サーバーレスプロバイダーによって実行される一連の関数として部分的に設計する必要があります。制御できないインフラストラクチャで処理が行われることに抵抗がない必要があります。さらに、アプリケーションの機能をリモートで実行できる個別の関数に分解できる必要があります。

ステートレス実行への対応

サーバーレス関数は、設計上、ステートレスです。つまり、関数が同じリソースで実行された場合、一部の情報がキャッシュされる可能性がありますが、関数の呼び出し間で状態が共有されることを期待することはできません。

関数は、内部で実行するために必要なすべての情報を持つように設計する必要があります。外部状態はすべて、呼び出しの開始時にフェッチし、終了する前にエクスポートする必要があります。関数は並行して実行される可能性があるため、これにより、作用できる状態の種類も制限されます。一般に、関数が管理する必要のある状態が少ないほど、実行が速く安価になり、管理する必要のある複雑さが軽減されます。

関数のエフェメラルな性質の他の副作用もあります。関数がデータベースシステムにアクセスする必要がある場合、データベースの接続プールをすぐに枯渇させる可能性が高くなります。関数の各呼び出しは異なるコンテキストで実行できるため、データベースの接続プールは、さまざまな呼び出しに応答したり、リソースをプールに戻そうとしたりすると、すぐに枯渇する可能性があります。Prisma Accelerate のようなソリューションは、配置されている接続プーリングの前面でサーバーレスインスタンスの接続リソースを管理することで、これらの問題を軽減するのに役立ちます。

どのような種類のロックインが発生する可能性がありますか？

特定のサーバーレスプラットフォームをターゲットにして構築されたアプリケーションの場合、さまざまな要因が別のプロバイダーへのクリーンな移行を妨げる可能性があります。これらは、サーバーレス実装自体、またはアプリケーション設計に統合される可能性のあるプロバイダーの関連サービスの使用に起因する可能性があります。

実際のサーバーレス実装によって引き起こされるロックインの観点から、プロバイダー間の最も基本的な違いの 1 つは、関数を定義するためにサポートされている言語である可能性があります。アプリケーション関数が、他の候補プロバイダーでサポートされていない言語で記述されている場合、サポートされている言語でロジックを再実装しない限り、移行は不可能になります。サーバーレスの非互換性のより微妙な例は、プラットフォーム内の関数のトリガーメカニズムをさまざまなプロバイダーが概念化および公開する方法の違いです。これらのメカニズムが大幅に異なる場合は、新しいプラットフォームでトリガーを実装する方法を再定義する必要がある場合があります。

サーバーレスアプリケーションがアプリケーションをサポートするためにプロバイダーのエコシステム内の他のサービスを使用する場合、他の種類のロックインが発生する可能性があります。たとえば、サーバーレス関数は状態を処理しないため、呼び出し中に生成されたアーティファクトを保存するためにプロバイダーのオブジェクトストレージサービスを使用するのが一般的です。オブジェクトストレージは標準インターフェースを使用して広く実装されていますが、サーバーレスアーキテクチャの制約が、他の利用可能なサービスのエコシステムの採用と依存度の向上につながる可能性があることを示しています。

ロックインを制限するために開発者が行うこと

開発者がアプリケーションのロックインの可能性または影響を最小限に抑えるために試みることができる方法がいくつかあります。

JavaScript のような広くサポートされている言語で関数を作成することは、ハード依存関係を回避する最も簡単な方法の 1 つです。選択した言語が多くのプロバイダーでサポートされている場合、コードを実行できる他のプラットフォームのオプションが提供されます。

開発者は、サービスの使用を、各プラットフォームでほぼ同じようにサポートされているコモディティ製品に限定することもできます。たとえば、前に使用したオブジェクトストレージの例は、実際には別のプロバイダーの製品で置き換えられる可能性が高いサービスの理想的な例です。依存しているサービスが特殊であるほど、エコシステムから抜け出すのが難しくなります。これはケースバイケースで評価する必要があるトレードオフです。より特殊なツールの代わりに、より一般的なツールを使用する必要がある場合があります。

開発者はどのような種類の違いを期待できますか？

サーバーレスパラダイムの約束は、コード自体を除くすべての責任をプラットフォームプロバイダーに移すことです。これにより、運用オーバーヘッドの点で多くの利点が得られ、開発者の実行環境が簡素化されますが、開発者が通常依存している可能性のある多くの手法やツールが、より困難になるか、または使用できなくなります。

たとえば、一部の開発者は、SSH でホストに接続したり、プロセスによって公開されたコードをイントロスペクションおよびデータを使用したりして、プログラミング環境に直接アクセスしてデバッグすることに慣れています。実行環境はユーザーにとって不透明であり、関数ログのような特定のインターフェースのみがデバッグに使用できるため、これらはサーバーレス環境では一般的に不可能または容易ではありません。これにより、特にローカルで再現できない場合、またはパイプラインで複数の関数が呼び出される場合に、問題の診断が困難になる可能性があります。

役立つオプションは何ですか？

開発者がこのより制限されたデバッグ環境内で作業するのに役立つために採用できるさまざまな戦略が数多くあります。

一部のサーバーレス機能はローカルで実行またはエミュレートできるため、開発者はプロバイダーの本番環境でデバッグできないものを自分のマシンでデバッグできます。多くのツールは、一般的なサーバーレスプラットフォームをエミュレートするように設計されており、開発者は不足している可能性のある診断機能の一部を取り戻すことができます。これにより、関数をステップ実行したり、状態情報を確認したり、ブレークポイントを設定したりできます。

プラットフォーム自体でデバッグするには、プロバイダーが提供するすべてのツールを利用する必要があります。これは多くの場合、関数内で大量にログを記録し、API テストツールを使用してさまざまな入力で関数を自動的にトリガーし、プラットフォームが提供するメトリクスを使用して、実行環境で何が起こっているかを洞察しようとすることを意味します。