はじめに

LambdaからRDSに接続する時に、Lambdaでは全てのプロセスが独立してしまうので、connectionも使いまわすことが出来ません。
このため、Lambdaに対する同時接続数を増やしていくと、RDS側でconnection数が上限を超えた時にエラーになります。
※ただ、これはLambdaに限らず、Connection Poolingが出来ないシステムでは同じです。

このことにより、Lambda+RDSはアンチパターンであるという見方をすることがあるようです。

結論

Lambdaを利用してもRDSのmax connection設定"だけ"が原因でスループットが実用に耐えなくなるということはなさそう。(即アンチパターンというわけではさそう)
[追記]RDSがSingleAZの場合、(試験した範囲では)インスタンスタイプを変えることでスループットをスケールすることができる。
[追記]RDSがMultiAZの場合、(試験した範囲では)インスタンスタイプに関わらず書き込みスループットは700rps前後を上限に止まってしまう。
Lambdaでは外部への通信が発生するケースにおいて、レイテンシを一定時間以下に抑えることは難しそうだ。

RDS for MySQLのmax-connectionについて

RDS for MySQLでは、インスタンスの搭載メモリ毎にmax-connection数が決定されています。
そのため、このconnection数を超えると接続時に接続エラーが発生します。

これは、DB Parameter Groupsのmax_connectionsを確認するとわかるのですが、デフォルトでは、以下の数値となっています。

max_connections: {DBInstanceClassMemory/12582880}

インスタンスタイプ	搭載メモリ	max_connections
db.t2.micro	1 GB	85
db.t2.small	2 GB	170
db.t2.midium	4 GB	341
db.t2.large	8 GB	682
db.m4.large	8 GB	682
db.m4.xlarge	16 GB	1365
db.m4.2xlarge	32 GB	2370
db.m4.4xlarge	64 GB	5461

ただし、アプリケーション側の使い方の問題で、メモリ使用量は比較的小さいにも関わらず、同時接続数をあげたいケースには、この制限を変更することが出来ます。(※Apacheの子プロセス数分のconnection poolingを行っている場合など)

max_connections: {DBInstanceClassMemory*2/12582880}

上げすぎるとメモリ不足でエラーとなりますので、落ちない程度に適宜調整して下さい。

Lambda + RDSの構成で負荷試験実施

負荷試験対象API

以下の機能を持つLambda function + API Gatewayを作成しました。

外部APIコール用のtokenをgetの引数として取得
外部のAPIにhttpでのコールを実施して情報取得
RDSに上記の結果を格納

インフラ構成

種別	タイプ
Jmeter	t2.large
RDS	t2.micro

試験実施結果

Jmeter 攻撃スレッド数	Average	95% Line	Throughput	RDS CPU負荷
50	335 msec	394 msec	146 rps	12%
100	352 msec	416 msec	276 rps	14%

攻撃スレッド数が50スレッドの段階で既に335msecと比較的応答が遅いですが、攻撃スレッド数を2倍にした時にレイテンシがほとんど低下せず、スループットがほぼ2倍にきちんとスケールしています。
RDSのCPUにもまだまだ余裕はありますし、API Gatewayには、デフォルトで1000rpsでスループットの上限がかかってしまいますので、まずはそこまでは上げることが出来るか試してみましょう。

Jmeter 攻撃スレッド数	Average	95% Line	Throughput	RDS CPU負荷
200	N/A	N/A	N/A	N/A

と思ったのですが、いきなりエラーで落ちてしまいました。
デフォルトでは、API Gatewayの制限ではなく、Lambdaの同時実行数制限の100同時起動までという制約に引っかかってしまうようです。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/limits.html

現在、こちらの上限緩和申請中ですが、「担当部署での確認に数日のお時間を要することがございます。」との事なので続きは気長に待ちたいところです。

応答が遅い原因の調査

スループットとしてはJmeterの攻撃スレッド数を増やすことで上げることはできそうですが、実際問題として、このAPIの応答は非常に遅いことはかわりがありません。それでAPIに少し細工をして、実行結果に実行時の区分ごとの実行時間を含めるようにしました。

{
  "Message": "***",
  ~中略~
  "time": {
    "prepare": "0msec",
    "execute external api": "141msec",
    "db connection": "18msec",
    "db insert": "121msec"
  }
}

npm requestパッケージを利用して外部APIの実行を行っているのですが、その部分だけで実行時間の半分を占めているようです。
実は、この外部APIの実行部分は外部で静的なファイルを返答するのみとしているため、外部への通信の確立のみでかなりのオーバーヘッドはありそうです。

追試

Lambdaの同時実行数制限を1000までに解除してもらったので、追試を行いました。
リファクタリングにより、上記とは少しアプリケーションを変えたため、直接の数値の比較は出来ないことに注意して下さい。

SingleAZ環境における試験

まずは、RDSをSingleAZとして立てて、攻撃スレッド数を上げていくことでスループットを計測していきました。
途中で挙動が不安定になった時点や、レイテンシが遅くなりすぎた時点でインスタンスタイプのスケールアップをして再計測しています。

RDS	攻撃スレッド	Average (msec)	95% Line (msec)	Throughput (rps)	特記事項
db.t2.micro	50	218	281	205
db.t2.micro	100	326	330	282	途中からconnectionが不安定
db.t2.micro	200	565	717	331	途中からconnectionが不安定
db.t2.small	50	218	280	207
db.t2.small	100	226	288	379
db.t2.small	200	331	366	547	途中からconnectionが不安定
db.t2.medium	50	210	271	215
db.t2.medium	100	211	272	429
db.t2.medium	200	240	319	745
db.t2.medium	250	252	366	878
db.t2.medium	300	N/A	N/A	N/A	1000rpsまでのスロットリング
db.t2.large	50	209	268	226
db.t2.large	100	214	275	443
db.t2.large	200	229	307	812
db.t2.large	250	N/A	N/A	N/A	1000rpsまでのスロットリング

SingleAZ環境においては、インスタンスタイプを選べばスロットリングによる制限の1000rps程度の応答をするAPIは作ることができそうです。

MultiAZ環境における試験

通常、サービスに利用するDBサーバは冗長化のため、MultiAZオプションを利用します。しかし、このMultiAZオプションを利用すると、ゾーン(データセンター)間でのデータの同期を待つことになるため、Write性能がインスタンスのCPUやメモリではなく、ゾーン間のネットワークレイテンシにより制限されてしまう現象が発生することが有ります。
具体的に言うと、より高価なインスタンスを利用しても書き込み性能が増えない可能性があるということです。
実際のサービスを想定して、MultiAZでの負荷試験を行ないます。

RDS	攻撃スレッド	Average (msec)	95% Line (msec)	Throughput (rps)	特記事項
db.t2.medium	50	221	281	196
db.t2.medium	100	261	349	350
db.t2.medium	200	303	507	592
db.t2.medium	300	392	899	676	途中からconnectionが不安定
db.t2.medium	400	508	1688	600	途中からconnectionが不安定
db.t2.large	50	249	310	182
db.t2.large	100	248	311	367
db.t2.large	200	269	351	662	※ピーク時で720rps程度
db.t2.large	300	371	805	722	途中からconnectionが不安定
db.t2.large	400	590	2282	643	途中からconnectionが不安定
db.m4.xlarge	50	229	290	198
db.m4.xlarge	100	236	303	387
db.m4.xlarge	200	267	348	658	※ピーク時で720rps程度
db.m4.xlarge	300	376	833	717	途中からconnectionが不安定
db.m4.xlarge	400	520	1975	618	途中からconnectionが不安定

SingleAZの場合においてdb.t2.small以上のインスタンスであればスロットリングされるまでの1000rpsまでのスループットが出せたにも関わらず、MultiAZでは、インスタンスタイプを変更しても700rps付近を限界にスループットが上がらないことがわかりました。

念のため、Auroraのdb.t2.mediumインスタンスでも同じ試験をしたのですが、若干数値は良いもののほぼ同じ結果となってしまいました。

※このSingleAZとMultiAZの違いは、Lambdaを利用している事が原因とは限らないことには注意が必要です。

Lambda + RDS benchmark