令和の Lambda x RDS 

# はじめに
`Lambda x RDS` は令和になってから重大ニュースがいくつかあった影響もあり、
VPC Lambdaは遅い、同時接続数がつらい、だからアンチパターンかと思いきや、
VPC Lambdaそんなに悪くない、Proxy使えばいい、とも言われてて
相反する情報が多く混乱してしまったので、平成と令和での状況変化を各記事を参考にまとめる
※「VPC Lambda」 = VPC内で実行するオプションを付けたLambda(デフォルトはVPC外で実行される)


# 【平成】 以下5つの点でLambdaとRDSは相性が良くないと言われていた 

    1. VPC Lambdaでの実行時に、起動コストが高い問題
        初回起動時はコールドスタートでENIの作成とアタッチなどに10~20秒ほどかかる
        対応方法
            定期的にlambdaをkickする

    2. VPC Lambdaでの実行時に、サブネットのIPを浪費する問題
        アタッチされたENIの数だけサブネット内のIPを消費してしまう
        サブネットのIPリミットやアカウントのENI作成リミット、APIレートを使い切るリスクがある
        また、LambdaのスケーリングがENIのリミットに依存する
        対応方法
            lambda用に別で大きめのサブネットを切る

    3. VPC Lambdaでの実行時に、インターネットアクセスするにNat Gatewayが必要な問題
        1時間あたり$0.062
        1GBあたり$0.062
        何もしなくても $44.64/月 かかってしまう
        高い。。。

    4. VPC外での実行時はRDSにPublicAccessを許可する必要がある問題
        VPC内がだめなら、外が良いのかというとそうでもない
        RDSのポート公開はビジネスではセキュリティリスクになるので取れない方法になる
        個人用途ならぎりあり
        対応方法
            lambdaのIPレンジのみからPublicAccessを許可する
                https://dev.classmethod.jp/articles/limiting-access-to-just-aws-ip-ranges/

    5. 最大接続数の問題
        lambdaは同時実行数を制御することが難しく、東京リージョンだと最大1000まで増やせる性能がある
        一方mysqlはコネクション数が多いとその分スペックを要求され、ピークに合わせるとコスパが悪くなる
        同時接続数の制御としては、コネクションプールが使われることが多い
        しかし、lambdaではコンテナ間でデータ共有する仕組みがないため、コネクションプールの実装が難しい
        なので、スケールアップで対応するしかなく、ピークに合わせてチューニングするとコスパが悪い
        そのため、LambdaはDynamoDBとの組み合わせが推奨されている
        対応方法
            これを許容できる規模のサービスで使う
            自身でコネクションプールするサービスを作る

    参考
        なぜAWS LambdaとRDBMSの相性が悪いかを簡単に説明する
            https://www.keisuke69.net/entry/2017/06/21/121501
        AWS LambdaをVPC内に配置する際の注意点
            https://devlog.arksystems.co.jp/2018/04/04/4807/
        Lambda x RDSはアンチパターンやでって話1
            https://qiita.com/teradonburi/items/86400ea82a65699672ad
        Lambda x RDSはアンチパターンやでって話2
            https://www.keisuke69.net/entry/2017/06/21/121501
        VPC Lambdaそんなに悪くないでって話
            https://dev.classmethod.jp/articles/serverless-meetup-osaka-5-vpclambda-demerit/

# 【令和】 問題の致命的な部分がほぼ改善された

    1. 「VPC内での実行時に起動コストが高い問題」の解決
        2019年9月頃にコールドスタートの起動速度が改善された
        Lambda関数が作成された時に「Hyperplane ENI」がマッピングされるようになった
        そのおかげでENIの作成/アタッチのコストが削減されたみたい
        ただし、アクセス数が増加すると追加のENIが作成されて、その瞬間は「2~6秒」ほどレイテンシが発生するらしい
        追加のENIは使われないと削除されるらしい
        完全には改善できていないが、大分マシになったという印象

    2. 「VPC内での実行時にサブネットのIPを浪費する問題」の解決
        「Hyperplane ENI」によってENIを使い回すので浪費がなくなった
        ENIの作成リミット依存もなくなった

    3. 「VPC Lambdaでの実行時に、インターネットアクセスするにNat Gatewayが必要な問題」
        動きなし、引き続き課金が必要

    4. 「VPC外での実行時はRDSにPublicAccessを許可する必要がある問題」
        動きなし、引き続きRDSをPublicAccess許可にしないといけない
        ただ、これはIP制限でなんとかなる気がする
        VPC Lambdaが改善されたので、必要性は薄れたかも

    5. 「最大接続数の問題」の解決
        2019年12月「RDS Proxy(プレビュー版)」リリース
        コネクションプーリングやフェイルオーバーを担ってくれるProxyがリリースされた
        これを使えばピークカットできるので、問題は解決できそう
        ただし、「RDS Proxy」を使うと追加料金がかかる
            基となるデータベースインスタンスの vCPU あたりの料金: 0.018USD/時間
            db.r5.large(Aurora)を使用している場合、
                db.r5.large 使用料: $252 ($0.35 x 24時間 x 30日)
                プロキシ使用量:  $25.92 ($0.018 x 2vCPU x 24時間 x 30日)
        現時点でまだプレビュー版なので本番投入可能な状態はまだ先になりそう
        いくつかの検証ブログを見るにまだコントロールしづらそうな感じはする

    参考
        【公式】 Amazon RDS プロキシのご紹介 (プレビュー)
            https://aws.amazon.com/jp/about-aws/whats-new/2019/12/amazon-rds-proxy-available-in-preview/
        【公式】 PostgreSQL 互換の Amazon RDS Proxy (プレビュー)
            https://aws.amazon.com/jp/about-aws/whats-new/2020/04/amazon-rds-proxy-with-postgresql-compatibility-preview/
        【公式】Amazon RDS プロキシの料金
            https://aws.amazon.com/jp/rds/proxy/pricing/
        【公式】 Announcing improved VPC networking for AWS Lambda functions
            https://aws.amazon.com/jp/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/
        【公式】AWS LambdaでAmazon RDS Proxyを使用する
            https://aws.amazon.com/jp/blogs/news/using-amazon-rds-proxy-with-aws-lambda/
        VPC アーキテクチャ変更のまとめ
            https://dev.classmethod.jp/articles/announced-vpclambda-improved/
        RDS Proxy パフォーマンス検証1
            https://tech.fusic.co.jp/posts/2019-12-11-aws-lambda-with-rds-proxy-performance-1/
        RDS Proxy パフォーマンス検証2
            https://blog.mmmcorp.co.jp/blog/2020/04/03/lambda-rds-proxy/

# Tips: 「Hyperplane ENI」とは
    「Hyperplane」というのが、2017年のre:Inventで紹介されていたAWS内部で使われているネットワーク関連技術
    もともとは内部的なS3 Load Balancerとして開発されたらしい
    これらの問題を解決するソリューション
        トラブル解決が困難
        キャパシティ管理が困難
        コストが増大
    ネットワークロードバランサーやNATゲートウェイなどに使われている
    そのHyperplaneを使って、ENIをNATできるようにして、VPCの問題を解決したらしい

    参考
        [レポート] AWS を支えるネットワークインフラと要素技術 #AWSSummit
            https://dev.classmethod.jp/articles/awssummit-2018-day2-h1-2-10-aws-network-infrastructure/
        AWS re:Invent 2017 Keynote - Tuesday Night Live with Peter DeSantis
            https://www.youtube.com/watch?v=dfEcd3zqPOA&feature=youtu.be&t=4661

↓これが
![aws lambda vpc nat before](https://d2908q01vomqb2.cloudfront.net/1b6453892473a467d07372d45eb05abc2031647a/2019/08/28/many-enis-1024x616.png)
↓こうなった
![aws lambda vpc nat after](https://d2908q01vomqb2.cloudfront.net/1b6453892473a467d07372d45eb05abc2031647a/2019/08/28/v2n-architecture-1024x613.png)
画像引用: [AWS Compute Blog](https://aws.amazon.com/jp/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/)

# まとめ
2020/06時点で「VPC Lambda」は使い物になるかというと、
VPCの問題は改善されたが、RDS Proxyがまだプレビュー版なので、正式版がくるまでは規模のあるビジネス用途ではまだ厳しそう。
個人用途ならVPCの改善だけでもありだけど、インターネットアクセスするなら
NatGateway課金が必要なのでお財布と相談って感じ。

よし、VPC Lambda一択だ！と思いきや、
ステイッステイッ、まだだまだだ、な状況


※2020/07/01 追記
https://aws.amazon.com/jp/blogs/aws/amazon-rds-proxy-now-generally-available/
RDS Proxy が GA(General Availability:一般利用可能) になりました！