サーバーレスアーキテクチャはどのようにデータベース接続を管理しますか？
サーバーレスアーキテクチャの主な利点は、そのようなプログラムが継続的に実行するために専用サーバーを必要としないことです。次に、要求時に呼び出され、関数の終了時に停止します。
つまり、レスポンシブであるためには、サーバーレスプログラムをすばやく起動する必要があります。次に、データベース接続などの時間のかかるアクションをどのように処理しますか？それは毎回データベースに接続しますか、それともサーバー接続で行われるような関数呼び出しのためにデータベース接続を個別に管理しますか？
サーバーレスアプリは実行間で状態を保持しないため、データベース接続プールを維持できません。サーバーレスアプリは、90年代のCGIスクリプトと同じ制約に直面しています。一般に、サーバーは初期化を要求ごとに1回ではなく1回行うため、永続的なサーバープロセスは、要求ごとのプロセスまたは要求ごとのコンテナーのアーキテクチャよりも優れたパフォーマンスを発揮できます。
サーバーレスプログラムは、Webサイトへのサービス提供など、遅延の影響を受けやすいタスクにはあまり適していません。これらは、追加のアプリケーションサーバーを手動で管理して負荷分散する必要がなく、メインサーバーで実行したくない散発的なバックグラウンドタスクに適しています。また、開発者の生産性が低レイテンシの応答よりもはるかに重要である場合、それらはまともな適合かもしれません。
場合によります。
ラムダランナーのバックグラウンド実装がこれに影響します。 AWSではコンテナが再利用される可能性があることがわかります。
http://docs.aws.Amazon.com/lambda/latest/dg/lambda-introduction.html
したがって、少なくとも一部のリクエストでは接続プーリング/再利用を確認できました。また、データベース自体と、データベースが着信接続要求を処理する方法についても検討する必要があります。
私にとってのこの種の質問は、「サーバーレス」の問題のいくつかを強調しています。それは、まだ非常に新しくて未熟なため、詳細は打ち出されていません。
サーバーレスとはサーバーがないという意味ではないことを常に覚えておく必要があります。ラムダを呼び出すレートが十分に高い場合、複数のサーバー、つまり「コンテナ」を実行している可能性があります。
実際には、起動時間とラムダのIPアドレスなどのリソースが実際の問題になる可能性があります。おそらく、それらを実行する方法についてのコンセンサスが成熟すると、これらの問題は確実な答えを得るでしょう。