Knex: Knex를 AWS Lambda와 함께 사용하려면 어떻게해야합니까?

Knex 풀링은 동일한 노드 프로세스에서 연결이 이루어진 경우에만 작동합니다.

AWS 람다 인스턴스가 공유 노드 프로세스를 실행하지 않는 경우 각 람다 인스턴스에서 최소 / 최대 연결이 1 인 새 풀을 생성하고 데이터베이스에 수백 개의 동시 연결을 허용 할 수있는 충분한 설정이 있기를 바라면됩니다 (RDS에서는 인스턴스 크기에 따라 다름). ).

이 https://forums.aws.amazon.com/thread.jspa?threadID=216000을 읽은 후

람다가 실제로 일부 프로세스를 공유하는 것처럼 보이므로 생성 된 람다 컨테이너의 최대 개수를 파악할 수 있다면 최적의 풀 크기를 계산할 수 있어야합니다 (각 컨테이너에는 별도의 풀이 있으므로 DB에 대한 총 연결은 풀입니다. 최대 * 최대 컨테이너 수).

어쨌든 풀에서 수동 연결 요청을 할 필요가 없습니다. knex는 자동으로 연결을 기다립니다. 모든 것이 몇 초 안에 완료되면 그 시간에 어떤 타임 아웃도 트리거되지 않습니다.

최대 연결 수에 도달했다는 오류가 DB에서 발생하면 최대 풀 크기를 작게 만들어야합니다.

문장 중간에 저질러서 미안 해요, 제 아이가 방금 3 리터의 물을 바닥에 던졌습니다.

답장을 보내 주셔서 감사합니다. 연결 수가 시간이 지남에 따라 크게 달라 지더라도 최대 풀 크기를 추정하는 것이 최선의 방법 인 것처럼 들립니다.

명확하게 말하면 Knex에서 연결을 끊을 방법이 없습니다. 맞습니까? 연결 풀을 파괴하는 기능 만 있습니까? Lambda가 때때로 컨테이너를 재사용한다는 사실은 모든 것을 포기합니다.

커넥션 풀을 파괴하면 모든 커넥션도 파괴되고 (먼저 완료되기를 기다립니다) 람다가 컨테이너를 파괴 할 때 프로세스가 종료 될 때 열려있는 모든 TCP 소켓이 묵시적으로 닫힐 것이라고 가정합니다.

풀링의 이점을 파괴하기 때문에 각 요청 후에 명시 적으로 연결을 닫아야하는 이유를 알 수 없습니다. 크기가 1 인 풀을 만들고 나중에 제거하면 동일한 효과를 얻을 수 있습니다.

사용하지 않고 풀에서 작업을 기다리는 경우 자동으로 연결을 닫는 풀에 대한 유휴 시간 제한을 구성 할 수도 있습니다.

Knex를 사용하여 COPY 쿼리를 RedShift 클러스터에 보내고 결과를 기다리지 않을 수 있습니까?

pg Pool로이 작업을 수행하면 Lambda 함수 끝에 도달하는 즉시 쿼리가 종료됩니다.

@BardiaAfshin 람다 컨테이너가 파괴되고 람다 함수 끝에 도달했을 때 모든 소켓이 해제되면이 경우 db 쿼리도 종료되고 완료되지 않을 수 있습니다.

결과 값을 읽기 전에 암시 적 트랜잭션이 완료되지 않아 COPY 쿼리가 롤백되는 경우 postgresql이 클라이언트 측 연결 종료에 어떻게 반응하는지 확실하지 않습니다.

어쨌든 쿼리를 보낼 수 있는지 여부는 knex에 달려 있지 않지만 aws lambda 및 postgresql의 작동 방식에 따라 다릅니다.

내 관찰은 쿼리가 RedShift에서 종료되고 롤백된다는 것입니다.

어쨌든 풀에서 수동 연결 요청을 할 필요가 없습니다. knex는 자동으로 연결을 기다립니다. 모든 것이 몇 초 안에 완료되면 그 시간에 어떤 타임 아웃도 트리거되지 않습니다.

db로드 테스트 스크립트를 실행 중이며 이것이 사실이 아닌 것 같습니다. 동시 연결 수가 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/

이것이 최선의 방법인지 확실하지 않지만 지금까지 나를 위해 일했습니다.

/어깨를 으쓱하다

안녕하세요.

const knex 가 선언되면 어떤 일이 발생하는지 정확히 모르겠습니다. 초기 연결이 설정되는 곳입니까? 누군가 명확히 할 수 있습니까? (dbConfig에 연결 정보가 있다고 가정합니다)

코드에서 핸들러가 호출 될 때마다 연결 자체를 덮어 쓰고 다시 생성하지 않습니까?

같은 보트에있는 사람에게 차를 치는 것만으로도 컨테이너와 수영장 크기를 알아 내려고 노력한 적은 운이 없었습니다 ( @elhigu 의 제안에 따라). 내 해결책은 모든 연결 후 풀을 파괴하는 것입니다 (최적이 아니라는 것을 알고 있습니다 😒).

const knex = require('knex');

const client = knex(dbConfig);

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

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

    return result;
  });

요약 : 콜백을 호출하기 전에 context.callbackWaitsForEmptyEventLoop = false 하기 만하면됩니다.

AWS Lambda는 빈 이벤트 루프를 기다립니다 (기본적으로). 그래서 함수는 콜백이 실행 되어도 Timeout 오류를 던질 수 있습니다.

자세한 내용은 아래 링크를 참조하십시오.
https://github.com/apex/apex/commit/1fe6e91a46e76c2d5c77877be9ce0c206e9ef9fb

@elhigu @tgriesser에게 : 이것은 knex 문제가 아닙니다. 이것은 확실히 람다 환경의 문제입니다. 이 문제를 질문에 태그하고 종료하는 것이 좋습니다. :)

@mooyoul yep, 확실히 knex 문제는 아니지만 문서 문제 일 수 있습니다.

이 링크를 봐주세요
https://stackoverflow.com/questions/49347210/why-aws-lambda-keeps-timing-out-when-using-knex-js
db 연결을 닫아야합니다. 그렇지 않으면 Lambda가 시간 초과 될 때까지 실행됩니다.

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 쿼리를 _build_하지만 _not execute_ 할 수 있다고 생각했습니다. 따라서 toSQL() 호출하고 출력을 serverless-mysql 하여 실행합니다.

DB 연결없이 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 db 연결없이 쿼리 작성이 실패한 것이 놀랍습니다.

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를 Lambda에서 거의 1 년 동안 아무 문제없이 실행했습니다. 내 Lambda 함수 외부에서 내 Knex 인스턴스를 선언하고 다른 게시물에서 언급 한대로 context.callbackWaitsForEmptyEventLoop = false 를 활용하고 있습니다.

즉, 지난 하루 동안 Postgres에서 엄청난 연결 스파이크를보고있는 것처럼 Lambda 측에서 무언가 변경된 것 같습니다. 연결이 닫혀 있지 않은 것 같습니다.

앞서 언급 한 접근 방식을 사용하는 다른 사람이 지난 하루 동안 기회를 본 적이 있습니까?

@jamesdixon 은 람다에 대한 knex 구현의 일부를 리팩토링하면서 지금 이것을 읽고 있습니다. 이것에 대한 업데이트가 있습니까? context.callbackWaitsForEmptyEventLoop = false 작동이 중지 되었습니까?