Knex: AWS LambdaでKnexを使用するにはどうすればよいですか？

Knexプーリングは、接続が同じノードプロセスから行われる場合にのみ機能します。

AWSラムダインスタンスが共有ノードプロセスを実行していない場合は、各ラムダインスタンスに最小/最大接続1の新しいプールを作成する必要があり、データベースに数百の同時接続を許可するのに十分な設定があることを期待します（RDSではインスタンスサイズによって異なります） ）。

これを読んだ後https://forums.aws.amazon.com/thread.jspa?threadID=216000

ラムダは実際にいくつかのプロセスを共有しているように見えるので、作成されたラムダコンテナーの最大数を把握できれば、最適なプールサイズを計算できるはずです（各コンテナーには個別のプールがあるため、DBへの接続の合計はプールになります。 max *最大コンテナ数）。

とにかく、プールから手動で接続を要求する必要はありません。knexは自動的に接続を待機し、数秒ですべてが終了した場合、その時間内にタイムアウトがトリガーされることはありません。

最大接続数に達したことを示すエラーがDBから発生する場合は、最大プールサイズを小さくする必要があります。

申し訳ありませんが、文の途中でコミットしました。私の子供は3リットルの水を床に投げました：1st_place_medal：上記のコメントをすぐに更新します...

返信いただきありがとうございます。 接続数は時間の経過とともに大幅に変化しますが、最大プールサイズを見積もることが最善の策のようです。

明確にするために、Knexで接続を閉じる方法はありませんよね？ 接続プールを破棄する機能のみですか？ Lambdaがコンテナを再利用することがあるという事実は、すべてを捨ててしまいます。

接続プールを破棄すると、すべての接続も破棄され（最初に完了するのを優雅に待機します）、ラムダがコンテナーを破棄すると、プロセスが終了すると、開いているすべてのTCPソケットが暗黙的に閉じられると思います。

プーリングの利点が失われるため、各リクエストの後に明示的に接続を閉じようとする必要がある理由がわかりません。 サイズ1のプールを作成し、後で破棄しても同じ効果が得られます。

プールのアイドルタイムアウトを構成することもできます。これは、使用されておらず、プールでのアクションを待機している場合に接続を自動的に閉じます。

Knexを使用してCOPYクエリをRedShiftクラスターに送信し、結果を待たないことはできますか？

pg Poolでこれを行うと、Lambda関数の終わりに達するとすぐにクエリが終了します。

@BardiaAfshinラムダ関数の終了に達したときにラムダコンテナが破棄され、そのすべてのソケットが解放された場合、dbクエリも終了し、終了しない可能性があります。

結果値を読み取る前に暗黙のトランザクションが終了していないためにCOPYクエリがロールバックされる場合、postgresqlがクライアント側の接続の終了にどのように反応するかはわかりません...

とにかく、クエリを送信できるかどうかはknex次第ではありませんが、awslambdaとpostgresqlがどのように機能するかによって異なります。

私の観察では、クエリはRedShiftで強制終了され、ロールバックされます。

とにかく、プールから手動で接続を要求する必要はありません。knexは自動的に接続を待機し、数秒ですべてが終了した場合、その時間内にタイムアウトがトリガーされることはありません。

データベース負荷テストスクリプトを実行していますが、これは正しくないようです。 30の同時接続のようなものより高いものは、開いている接続を待つのではなく、すぐにタイムアウトします。

クエリが実行されたら、現在使用されている接続を手動で解放する方法はありますか？

AWS Lambdaを始めたばかりの私たちのために共有できるサンプルコードを誰かが持っていますか？ 誰かがknex / postgres / lambdaのパターンやアンチパターンを共有できることを願っています。

これが私が今使っているものです-それは改善できると確信していますが、私が正しい道を進んでいるかどうかについて少しの証拠を期待しています...

'use strict';
var pg = require('pg');

function initKnex(){
  return require('knex')({
      client: 'pg',
      connection: { ...details... }
  });
}

module.exports.hello = (event, context) =>
{
  var knex = initKnex();

  // Should I be returning knex here or in the final catch?
  knex
  .select('*')
  .from('my_table')
  .then(function (rows) {
    context.succeed('Succeeded: ' + JSON.stringify(rows || []));
  })
  .catch(function (error) {
    context.fail(error);
  })
  .then(function(){
    // is destroy overkill? - is there an option for knex.client.release, etc?
    knex.destroy();
  })
}

私は同じ船に乗っています-たくさんのグーグルとテストにもかかわらず、まだ最善の方法が何であるかを理解していません。 私が今していることは：

const dbConfig = require('./db');
const knex = require('knex')(dbConfig);

exports.handler = function (event, context, callback) {
...
connection = {..., pool: { min: 1, max: 1 },

このようにして、接続（コンテナーごとに最大1つ）が維持されるため、コンテナーを簡単に再利用できます。 私は最後に私の接続を破壊しません。

http://blog.rowanudell.com/database-connections-in-lambda/

これが最善の方法かどうかはわかりませんが、これまでのところうまくいきました。

/肩をすくめる

@austingayler

const knexが宣言されたときに何が起こるか正確にはわかりません-これは初期接続がセットアップされる場所ですか？ 誰かが明確にすることができますか？ （dbConfigに接続情報があると想定しています）

あなたのコードでは、ハンドラーが呼び出されるたびに接続自体が上書きされて再作成されていませんか？

同じボートに乗っている人にチャイムを鳴らしているだけで、コンテナとプールのサイズを比較するのにあまり運がありませんでした（

const knex = require('knex');

const client = knex(dbConfig);

client(tableName).select('*')
  .then((result) => { 

    return Promise.all([
      result,
      client.destroy(),
    ])  
  })
  .then(([ result ]) => {

    return result;
  });

TL; DR：コールバックを呼び出す前にcontext.callbackWaitsForEmptyEventLoop = false設定するだけです。

AWS Lambdaは、空のイベントループを待機します（デフォルト）。 そのため、コールバックが実行されても、関数はタイムアウトエラーをスローする可能性があります。

詳細については、以下のリンクを参照してください。
https://github.com/apex/apex/commit/1fe6e91a46e76c2d5c77877be9ce0c206e9ef9fb

@elhigu @tgriesserへ：これはknexの問題ではありません。 これは間違いなくラムダ環境の問題です。 私はこの問題に質問のタグを付けて、閉じるのが良いと思います:)

@mooyoulうん、間違いなくknexの問題ではないが、ドキュメントの問題かもしれない... knexdocsにawslambda固有のものは必要ないと思うので、閉じます。

このリンクを見てください
https://stackoverflow.com/questions/49347210/why-aws-lambda-keeps-timing-out-when-using-knex-js
db接続を閉じる必要があります。そうしないと、Lambdaがタイムアウトするまで実行されます。

KnexをLambdaで使用するために完璧に機能するパターンを見つけた人はいますか？

接続を正しく閉じたときに他に問題がありますか？

私が避けようとしているのは、接続を閉じて、ラムダの呼び出し全体で利用できるようにすることです。

Lambdaが呼び出し間の状態の維持を許可しますか？

https://scalegrid.io/blog/how-to-use-mongodb-connection-pooling-on-aws-lambda/のnode.jsの部分を確認して

私はこのようにスレッドをぶつけるのは好きではありませんが、コメントで失われていると思うので、上記の@mooyoulの答えは私たちにとってうまくいきました。

そのフラグをfalseにしないと、Lambdaはイベントループが空になるのを待ちます。 そうした場合、コールバックを呼び出すとすぐに関数は実行を終了します。

私にとっては、ローカルマシンでは機能しましたが、デプロイ後は機能しませんでした。 私はちょっと誤解を招きました。

RDSインバウンドソースが私のLambda関数に対して開かれていないことがわかりました。 Stack Overflowで解決策が見つかりました：RDSインバウンドソースを0.0.0.0/0か、VPCを使用します。

RDSインバウンドソースを更新した後、KnexでLambdaを正常に実行できます。

私が使用しているLambdaランタイムはNode.js 8.10 、パッケージは次のとおりです。

knex: 0.17.0
pg: 7.11.0

非同期を使用する以下のコードも機能します

const Knex = require('knex');

const pg = Knex({ ... });

module.exports. submitForm = async (event) => {
  const {
    fields,
  } = event['body-json'] || {};

  return pg('surveys')
    .insert(fields)
    .then(() => {
      return {
        status: 200
      };
    })
    .catch(err => {
      return {
        status: 500
      };
    });
};

うまくいけば、それは将来同じ問題に遭遇するかもしれない人々を助けるでしょう。

私が人々の注意を引きたいのは、 serverless-mysqlパッケージです。これは、標準のmysqlドライバーをラップしますが、このスレッドで説明されている接続プール管理に関するラムダ固有の問題点の多くを処理します。

ただし、別のドライバーに交換する方法がないため、現時点では（この問題によると）Knexがserverless-mysqlで動作するとは思いません。 serverless-mysqlはコールバックの代わりにpromiseを使用するため、非互換性も存在する可能性があります。

最善のアプローチは、おそらくKnexに新しいクライアント実装を追加することです。 私はこれを試してみてうれしいですが、Knexに精通している誰かに、それが合理的/実行可能だと思うかどうか教えてもらいたいですか？

また、その間、Knexを使用してMySQLクエリを_ビルド_することはできますが、実行することはできませんでした。 したがって、 toSQL()を呼び出し、出力をserverless-mysqlに渡して実行します。

私が疑問に思っているのは、データベース接続なしでKnexを構成できるかどうかです。 使用されたことのない接続を開く意味はありません。

次は機能しますか？

connection = {..., pool: { min: 0, max: 0 ) },

@disbelief接続せずにknexを初期化できます。 このセクションの最後に、ドキュメントhttps://knexjs.org/#Installation-clientにそれを行う方法の例があり

const knex = require('knex')({client: 'mysql'});

const generatedQuery = knex('table').where('id',1).toSQL().toNative();

@elhiguああかっこいい、ありがとう。 暫定的にそのショットを与えます。

更新：上記は機能していないようです。 Knexは、クエリを実行するための呼び出しがまったくない場合でも、db接続を確立できない場合にエラーをスローします。

@disbeliefあなたはその解決策を見つけましたか？

@fdecampredonいいえ。 現時点では、 squelを使用してクエリをtoString()を呼び出して、 serverless-mysqlクライアントに渡しているだけです。

@disbeliefデータベース接続なしでクエリの構築が失敗したのは私にとって驚きです。

knexクライアントの構築に使用しているコードと構成を投稿していただけませんか？ また、knexバージョン。

以下は私にとってはうまくいきます
ノードv8.11.1
mysql ：2.13.0
knex ：0.18.3

const k = require('knex')

const client = k({ client: 'mysql' })

console.log('Knex version:', require('knex/package.json').version)
// => 0.18.3
console.log('sql:', client('table').where('id',1).toSQL().toNative())
// => { sql: 'select * from `table` where `id` = ?', bindings: [ 1 ] }

Lambdaのリソースリサイクルの仕組みに従って、 Knexインスタンスは常に関数またはクラスの外部に保持する必要があります。 また、プール内の接続で最大1を持っていることが重要です。

何かのようなもの：

const Knex = require('knex');
let instance = null;

module.exports = class DatabaseManager {
  constructor({ host, user, password, database, port = 3306, client = 'mysql', pool = { min: 1, max: 1 }}) {
    this._client = client;
    this._poolOptions = pool;
    this._connectionOptions = {
      host: DB_HOST || host,
      port: DB_PORT || port,
      user: DB_USER || user,
      password: DB_PASSWORD || password,
      database: DB_NAME || database,
    };
  }

  init() {
    if (instance !== null) {
      return;
    }

    instance = Knex({
      client: this._client,
      pool: this._poolOptions,
      connection: this._connectionOptions,
      debug: process.env.DEBUG_DB == true,
      asyncStackTraces: process.env.DEBUG_DB == true,
    });
  }

  get instance() {
    return instance;
  }
}

このようにして、Lambdaのリサイクルを最大限に活用できます。つまり、アクティブ化された（凍結された）各コンテナーは同じ接続のみを保持します。

補足として、同時コンテナーの数を制限しない場合、Lambdaはデフォルトでスケールアウトすることに注意してください。

Knexをラムダで1年近く実行していて、問題はありません。 他の投稿で言及されているように、Lambda関数の外部でKnexインスタンスを宣言し、 context.callbackWaitsForEmptyEventLoop = falseを利用しています。

とは言うものの、この1日で、Postgresで接続が大幅に急増しているのを見て、Lambda側で何かが変わったようです。 接続が閉じられていないようです。

前述のアプローチを使用している他の誰かが、過去1日ほどでチャンスを見たことがありますか？

@jamesdixonは、ラムダでのknex実装の一部をリファクタリングしながら、これを読んでいます。 これに関する更新はありますか？ context.callbackWaitsForEmptyEventLoop = falseが機能しなくなりましたか？