AWS Innovate "もはやアンチパターンではない、AWS Lambda からのリレーショナル・データベース利用 (T4-5)"を見ていて

AWS Lambda イベント

AWS Innovateの"もはやアンチパターンではない、AWS Lambda からのリレーショナル・データベース利用 (T4-5)"を見ていた時のメモ

メモ

  • LambdaからDBをつなぐ際、Writeのスケーリングはどうすんの
    • スケールアップ
      • セッションの中では触れられなかったけどAurora Serverlessでも対応できるケースがありそう。負荷が時間帯によってぐるんぐるん変わるようなサービスは向いてそう。
    • ElasticacheやDynamoDBにオフロード
    • RDS ProxyをLambda-DB間に配置してDB負荷を抑制

  • Readは素直にSlave(Reader）のスケールアウトで解決

  • RDS Proxy

    • 負荷軽減
      • コネクション周りの負荷をRDS Proxyに移す、という理屈らしい。
    • DNSではないフェイルオーバーの実現
      • 感想： DNSキャッシュや、切り替え遅延や、業務用のRoute53なんて気楽に触りたくないよ勘弁してよという思いから解放される（かもしれない）
    • ピン留めに注意

  • LambdaからDBを使う際のアーキテクチャ選択は

    • DynamoDBが使えるならDynamoDBがおすすめ
    • コネクション管理をDB任せにしても問題ない程度の軽めの負荷ならDB直。
    • 高負荷ならRDS Proxyを使おう

感想

  • Lambdaから使う場合は基本的にRDS Proxy必須なのかなと思っていた。負荷が低いならDB直でもOKと知ったのは収穫。
  • DynamoDBは使いどころが難しいけど、Serverlessで小さなマイクロサービスみたいなものならRDSと混ぜてトランザクション管理が地獄の様相を呈することも避ける余地がありそうだし、Serverlessとなら相性が悪くなさそう。
    • モノリシックな造りだとどうしてもRDSに頼らざるを得ないところがでてくる可能性が否定できず、そうすると結局DynamoDBだけではなくRDSも併用せざるを得ないことになり、そんな複雑な構成を甘受するならＲＤＳ一本にまとめたほうがトータルで考えて一番だよねという判定が多かった。
    • DynamoDBはKVSなので検索機能がRDSと比べると弱い、集計も厳しい、という特性があって、そこがどうしてもネックになりやすい。検索や集計がないシステムなんてそうそうない。
      • ただ集計はログにいったん吐いてS3に集めてそこでやるからOK、検索は別に専用のサブシステムを持つ――あるいはそっちがメインでDynamoDBを使う側がサブシステムだ――から問題なし、ということが高い確度で言えるならいける。かもしれない。
        • 究極、要件による。
          • ただLambda+DynamoDBで突発的なスパイクも余裕でさばける構成には夢と浪漫がある・・・。