AWS Innovateの"もはやアンチパターンではない、AWS Lambda からのリレーショナル・データベース利用 (T4-5)"を見ていた時のメモ
メモ
- LambdaからDBをつなぐ際、Writeのスケーリングはどうすんの
- スケールアップ
- セッションの中では触れられなかったけどAurora Serverlessでも対応できるケースがありそう。負荷が時間帯によってぐるんぐるん変わるようなサービスは向いてそう。
- ElasticacheやDynamoDBにオフロード
- RDS ProxyをLambda-DB間に配置してDB負荷を抑制
- スケールアップ
Readは素直にSlave(Reader)のスケールアウトで解決
RDS Proxy
LambdaからDBを使う際のアーキテクチャ選択は
- DynamoDBが使えるならDynamoDBがおすすめ
- コネクション管理をDB任せにしても問題ない程度の軽めの負荷ならDB直。
- 高負荷ならRDS Proxyを使おう
感想
- Lambdaから使う場合は基本的にRDS Proxy必須なのかなと思っていた。負荷が低いならDB直でもOKと知ったのは収穫。
- DynamoDBは使いどころが難しいけど、Serverlessで小さなマイクロサービスみたいなものならRDSと混ぜてトランザクション管理が地獄の様相を呈することも避ける余地がありそうだし、Serverlessとなら相性が悪くなさそう。
- モノリシックな造りだとどうしてもRDSに頼らざるを得ないところがでてくる可能性が否定できず、そうすると結局DynamoDBだけではなくRDSも併用せざるを得ないことになり、そんな複雑な構成を甘受するならRDS一本にまとめたほうがトータルで考えて一番だよねという判定が多かった。
- DynamoDBはKVSなので検索機能がRDSと比べると弱い、集計も厳しい、という特性があって、そこがどうしてもネックになりやすい。検索や集計がないシステムなんてそうそうない。
- ただ集計はログにいったん吐いてS3に集めてそこでやるからOK、検索は別に専用のサブシステムを持つ――あるいはそっちがメインでDynamoDBを使う側がサブシステムだ――から問題なし、ということが高い確度で言えるならいける。かもしれない。
- 究極、要件による。
- ただLambda+DynamoDBで突発的なスパイクも余裕でさばける構成には夢と浪漫がある・・・。
- 究極、要件による。
- ただ集計はログにいったん吐いてS3に集めてそこでやるからOK、検索は別に専用のサブシステムを持つ――あるいはそっちがメインでDynamoDBを使う側がサブシステムだ――から問題なし、ということが高い確度で言えるならいける。かもしれない。