AWSラムダのcontainer execution modelを利用できます。ラムダが呼び出されると、AWSはコンテナを回転させてハンドラ関数内でコードを実行します。そのため、ハンドラ関数の外でPG接続を定義すると、Lambda関数の呼び出し間で共有されます。あなたは上記のリンクでそれを見つけることができます。
ラムダ関数コードの宣言(ハンドラコードの外、「プログラミングモデル」を参照)は、関数が再度呼び出されたときに追加の最適化を提供して初期化されたままです。たとえば、ラムダ関数がデータベース接続を確立する場合、接続を再確立するのではなく、元の接続が後続の呼び出しで使用されます。コードにロジックを追加して、接続を作成する前に接続がすでに存在するかどうかを確認できます。
const pg = require('pg');
const client = new pg.Client(<connection_string>);
exports.handler = (event, context, cb) => {
client.query('SELECT * FROM users WHERE ', (err, users) => {
// Do stuff with users
cb(null); // Finish the function cleanly
});
};
はthisブログ記事を参照してください。
しかし、警告があります。
ラムダファンクションコードを記述するとき、AWSラムダがコンテナを再利用しないことを選択する可能性があるため、AWSラムダが常にコンテナを再利用すると仮定しないでください。 AWS Lambdaは、さまざまな要因によっては、既存のコンテナを再利用する代わりに、単に新しいコンテナを作成することもできます。
さらに、ラムダ機能をウォーミングアップするスケジュールジョブを作成できます。 (5分ごとに実行されます)
ラムダの各タスクはどれくらいの期間実行されますか?私はDBの接続時間が全体の時間のかなりの割合を占めている場合にのみこれが重要だと考えています。そして、RDBMSの機能が必要な場合でも、おそらくそれは支払う価値のある価格です。しかし、まず、その影響を定量化しようとします。 –
@DavidAldridge通常、ラムダ関数は100~200ms MAXを要し、多分約2つの選択と1つの要求の挿入を要する。私は高い並行性を期待しています。レガシー接続ハンドシェイクを回避するためにPostgRESTと呼ばれるこのプロジェクトを使用することをお勧めしますか? – Ryan
可能な接続制限を処理するために、接続プーリング用に[PgBouncer](https://wiki.postgresql.org/wiki/PgBouncer)を検索することもできます。 –