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

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

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

このデメリットは、リソースが完全にスピンダウンすると、次に実行が必要になった際に予測可能な遅延が発生することです。関数を実行するためにリソースを再割り当てする必要があり、これには時間がかかります。結果として、最近使用された「ホット」関数には一連のパフォーマンス特性があり、プラットフォームが実行環境を作成するのを待つ必要がある「コールド」関数には別のプロファイルが適用されることになります。

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

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

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

リソースの事前割り当てに代わる最近の方法として、より軽量なランタイム環境に切り替えることでこの問題を回避する動きがあります。V8のようなランタイムは、従来のサーバーレスとは大きく異なる実行戦略を持ち、異なる分離技術とより簡素化された環境を使用することでコールドスタート問題を回避できます。これらは、より堅牢な環境に依存する関数との互換性を犠牲にして、コールドスタートの問題を回避します。

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

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

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

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

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

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

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

どのような種類のロックインが発生しうるか？

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

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

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

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

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

JavaScriptのような広くサポートされている言語で関数を記述することは、ハードな依存関係を避ける最も簡単な方法の一つです。選択した言語が多くのプロバイダーでサポートされている場合、コードを実行できる可能性のある他のプラットフォームの選択肢が得られます。

開発者はまた、各プラットフォームでほぼ同じようにサポートされているコモディティなサービスに利用を限定するように努めることができます。例えば、先に挙げたオブジェクトストレージの例は、実際には別のプロバイダーのサービスによって置き換えられる可能性が高いサービスの理想的な例です。依存しているサービスが専門的であればあるほど、そのエコシステムから移行するのは難しくなります。これは、より専門的なツールの代わりに汎用的なツールを諦めなければならない可能性があるため、ケースバイケースで評価する必要があるトレードオフです。

開発者はどのような違いを期待できるか？

サーバーレスパラダイムの約束は、コード自体を除くすべての責任をプラットフォームプロバイダーに移すことです。これは、運用上のオーバーヘッドを削減し、開発者にとっての実行環境を簡素化するという点で多くの利点をもたらしますが、開発者が通常頼りにする多くの技術やツールを使用するのが、より困難になるか不可能になるという側面もあります。

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

役立つ選択肢は？

開発者がこのより制限されたデバッグ環境で作業するのに役立つ、さまざまな戦略があります。

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

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