AWS Lambdaでのmysqldump取得失敗

Question

AWS にて mysqldump の取得を Lambda で自動化しています。
後述する関数コードで正常に取得できていましたが DB のデータ量が増えてから下記のメッセージが出て取得に失敗するようになってしまいました。
Lambda 関数設定画面よりメモリ設定を 1024MB → 1536MB に変更してみましたが、メッセージ内容は変わらず失敗。(後述のメッセージはメモリ値変更後のもの)

対処方法をご教授頂きたく思います。
環境情報を記載します。(足りない情報ありましたら追記致します)

例えばですが、mysqldump コマンドのオプション「--single-transaction」を指定出来れば…とも考えましたが、Node.js上でコマンドオプションの指定は可能なのでしょうか。

　
[Lambdaログ]
(Cloudwatchログに出力されたもの)

START RequestId: 19d4d7ed-cd4b-11e7-a42f-a13c00653d3a Version: $LATEST
END RequestId: 19d4d7ed-cd4b-11e7-a42f-a13c00653d3a
REPORT RequestId: 19d4d7ed-cd4b-11e7-a42f-a13c00653d3a	Duration: 9208.56 ms	Billed Duration: 9300 ms Memory Size: 1536 MB	Max Memory Used: 1536 MB	
RequestId: 19d4d7ed-cd4b-11e7-a42f-a13c00653d3a Process exited before completing request

START RequestId: 19d4d7ed-cd4b-11e7-a42f-a13c00653d3a Version: $LATEST
END RequestId: 19d4d7ed-cd4b-11e7-a42f-a13c00653d3a
REPORT RequestId: 19d4d7ed-cd4b-11e7-a42f-a13c00653d3a	Duration: 9429.58 ms	Billed Duration: 9500 ms Memory Size: 1536 MB	Max Memory Used: 1536 MB	
RequestId: 19d4d7ed-cd4b-11e7-a42f-a13c00653d3a Process exited before completing request

START RequestId: 19d4d7ed-cd4b-11e7-a42f-a13c00653d3a Version: $LATEST
END RequestId: 19d4d7ed-cd4b-11e7-a42f-a13c00653d3a
REPORT RequestId: 19d4d7ed-cd4b-11e7-a42f-a13c00653d3a	Duration: 9621.80 ms	Billed Duration: 9700 ms Memory Size: 1536 MB	Max Memory Used: 1536 MB	
RequestId: 19d4d7ed-cd4b-11e7-a42f-a13c00653d3a Process exited before completing request

　
[Lambda]
・関数コード設定　(ランタイム：Node.js 4.3)
mqldump コマンドで取得後、S3バケットに配置してます。

'use strict';

const AWS = require('aws-sdk');
const mysqlDump = require('mysqldump');
const fs = require('fs');
require('date-utils');

var date = new Date();
var timeStamp = date.toFormat('YYYYMMDDHH24MISS');
// dumpファイルのファイル名
const dumpFileName = 'dump_' + timeStamp + '.sql';
const dumpPath = '/tmp/' + dumpFileName;

// メインの処理
exports.handler = (event, context) => {

      // mysqldumpを実行
      mysqlDump({
        host: process.env.HOST,
        user: process.env.USER,
        password: process.env.PASSWORD,
        database: process.env.DBNAME,
        dest: dumpPath
      }, (err) => {
        // エラーが起こった場合、ログを出力
        if (err) {
          context.fail(err);
          console.log('mysqldump error:' + err);
        } else {
          console.log('mysqldump saved.');
          // mysqldumpの作成が成功した場合、S3へdumpファイルを送信する
          sendS3();
        }
      });

};

// S3へdumpファイルを送信する
function sendS3() {
  const s3 = new AWS.S3();

  var params = {
    Bucket: 'バケット名',
    Key: 'sqlbackup/' + dumpFileName,
    Body: fs.readFileSync(dumpPath)
  };

  // S3にmysqldumpを配置する
  s3.putObject(params, (err) => {
    if (err) {
      console.log('S3 PutObject error:', err);
    } else {
      console.log('mysqldump is uploaded to S3.');
    }
  });
}

・基本設定
メモリ　　　：1536MB(MAX)
タイムアウト：2分30秒


[RDS]
エンジン　：MySQL 5.7.16
タイプ　　：db.m4.2xlarge
ストレージ：30GB

DB 総容量：

mysql> select table_schema, sum(data_length+index_length) /1024 /1024 as MB from 
information_schema.tables where table_schema = database();
+--------------+-----------+
| table_schema | MB        |
+--------------+-----------+
| ***          | 15969.765 |   現在 約15GB
+--------------+-----------+
1 row in set (0.03 sec)

Comments

[TaichiYanagiya]

毎回、10秒近くで強制終了されているようです。タイムアウト設定が反映されていないのでは？

[th0167]

確かに、タイムアウト値を 2分30秒 と設定しているのに反映されていないとなると…AWS側の原因という可能性があるという事でしょうか？

[th0167]

処理が開始されて直ぐにメモリが一杯になってしまい、処理が落ちてしまって強制終了したのでは、とも考えています。

[TaichiYanagiya]

API Gateway から実行ですか？ それとも CloudWatch イベントから？ ネットで検索すると、API Gateway に 10秒の制限があった(今は 30秒)という Webサイトが見つかるので。

[th0167]

実行は Cloudwatch イベントからですね。

Answer 1

JSは全然読めないんですが、

https://github.com/webcaetano/mysqldump/blob/master/index.js#L230

にあるようになんか処理の終了時に一括で取得したデータをファイルに書き込んでいる気がします。。。

なんかIssueも立ってますしこのライブラリは大きなデータベースのダンプには向かない気がします。

（気がします、気がします、ですいません）

Comments

[th0167]

回答ありがとうございます。
すいません、私も Node.js は読めないんです・・・質問にある関数コードは別のヒトが作成して私が運用管理しています。

＞このライブラリは大きなデータベースのダンプには向かない気がします。
自分なりに調べている内に、これは私も感じてきてます・・・

Answer 2

結局 Lambda での改善は見込めそうにない為、EC2 上で dump 取得コマンドをシェル実行する方向になりました。
Lambda は AWS 側の機能改善を気長に待ちたいと思います。

ご意見/ご回答頂いた皆様、ありがとうございました。


(12/11 追記)
上記の自己解決を記述して間もなくLambdaの使用メモリ上限が1.5GB→3GBに引き上げられた為、質問で書いたLambda関数コードが成功する様になりました。一旦はそれで解決していますが、今後DBが肥大化していく事を想定すると一時的な解決に過ぎない為、引き続き別の機能を使った解決方法を模索していく事にします。