VPCLambda × RDSのデメリットを正しく理解しよう!!

VPCLambda × RDSのデメリットを正しく理解しよう!!

2019/8/1に開催されたServerlessMeetupOsaka#5で発表させて頂いた際の資料です

119659c28d16f22d01eb48a6f3ee1391?s=128

TomoyaIwata

August 01, 2019
Tweet

Transcript

  1. VPC Lambda×RDSのデメリットについて 正しく理解しよう︕! Serverless Meetup Osaka #5 2019/8/1 クラスメソッド株式会社 岩⽥

    智哉 1
  2. Attention スライドは後で⼊⼿することが出来ますので 発表中の内容をメモする必要はありません。 写真撮影をする場合は フラッシュ・シャッター⾳が出ないようにご配慮ください

  3. 3 ⾃⼰紹介 lクラスメソッド株式会社 lサーバーレス開発部 改め CX事業本部 l趣味︓ブレイクダンス 岩⽥ 智哉

  4. 4 今⽇話したいこと 無駄なコスト VPC Lambdaを使う︖︖ 何⾔ってるの、ダメダメ

  5. 5 今⽇話したいこと VPC Lambda(×RDS)のデメリットを 良く理解せぬまま VPC Lambda(×RDS)を悪だと 決めつけていませんか︖

  6. 6 アジェンダ 無駄なコスト • Lambdaについて 5分 • VPC Lambda ×

    RDSのデメリットについて • VPC Lambdaと⾮VPC Lambdaについて • まとめ 3分 12分 2分
  7. 7 アジェンダ 無駄なコスト • Lambdaについて 5分 • VPC Lambda ×

    RDSのデメリットについて • VPC Lambdaと⾮VPC Lambdaについて • まとめ 3分 12分 2分
  8. 8 Lambdaについて • サーバーの管理が不要 • アイドル時間に課⾦されない • ⾃動でスケールアウト AWS上でのイベントをトリガーにユー ザーが作成した関数(Lambda関数)が実

    ⾏できるサービス
  9. 9 Lambdaについて • コンテナ型の仮装化技術を⽤いてLambda実⾏環境を作成 • Lambda関数はコンテナ上で実⾏される • コンテナは必要に応じて⽣成・破棄される ※説明を簡略化するために⼀部省略 詳細は

    AWS公式の資料「 Security Overview of AWS Lambda 」を参照 Micro VM Lambda関数実⾏環境 (コンテナ) Worker
  10. 10 Lambda実⾏環境のライフサイクルについて (ENIの作成) ※詳しくは後述 コンテナの作成 デプロイパッケー ジのロード デプロイパッケー ジの展開 ランタイム

    起動・初期化 関数・メソッドの 実⾏ コンテナの破棄 20190402 AWS Black Belt Online Seminar Let's Dive Deep into AWS Lambda Part1 & Part2 https://www.slideshare.net/AmazonWebServicesJapan/20190402-aws-black-belt-online- seminar-lets-dive-deep-into-aws-lambda-part1-part2
  11. 11 Lambda実⾏環境のライフサイクルについて (ENIの作成) ※VPC Labdaの場合 コンテナの作成 デプロイパッケー ジのロード デプロイパッケー ジの展開

    ランタイム 起動・初期化 関数・メソッドの 実⾏ コンテナの破棄 20190402 AWS Black Belt Online Seminar Let's Dive Deep into AWS Lambda Part1 & Part2 https://www.slideshare.net/AmazonWebServicesJapan/20190402-aws-black-belt-online- seminar-lets-dive-deep-into-aws-lambda-part1-part2 コールドスタート
  12. 12 Lambda実⾏環境のライフサイクルについて (ENIの作成) ※VPC Labdaの場合 コンテナの作成 デプロイパッケー ジのロード デプロイパッケー ジの展開

    ランタイム 起動・初期化 関数・メソッドの 実⾏ コンテナの破棄 20190402 AWS Black Belt Online Seminar Let's Dive Deep into AWS Lambda Part1 & Part2 https://www.slideshare.net/AmazonWebServicesJapan/20190402-aws-black-belt-online- seminar-lets-dive-deep-into-aws-lambda-part1-part2 ウォーム スタート
  13. 13 Lambdaのプログラミングモデルについて 関数・メソッド 実⾏ ランタイム 起動・初期化 (広義の)コールドスタート時のみ実 ⾏される コールドスタート時、ウォームスタート 時共に毎回実⾏される

  14. 14 無駄なコスト • Lambdaについて 5分 • VPC Lambda × RDSのデメリットについて

    • VPC Lambdaと⾮VPC Lambdaについて • まとめ 3分 12分 2分
  15. 15 VPC Lambdaと⾮VPC Lambdaについて AWSにはVPC(Virtual Private Cloud)という概念がある VPC AWS Cloud

    Availability Zone 1 Availability Zone 2 Public subnet Private subnet Private subnet Public subnet
  16. 16 AWSのサービス分類(⼀部抜粋) Amazon Aurora Amazon DocumentDB (with MongoDB compatibility) Amazon

    DynamoDB Amazon ElastiCache Amazon RDS Amazon Neptune Amazon Elasticsearch Service Amazon Simple Storage Service (S3) Amazon Cognito VPC内にリソースを作成するサービス VPC外にリソースを作成するサービス AWS IoT Device Management AWS CloudFormation データベース系のサービスがVPCに寄っている Amazon CloudWatch
  17. 17 VPC Lambdaと⾮VPC Lambdaについて • VPC内のリソースにアクセスできるように設定されたLambda関数 = VPC Lambda •

    VPC内のリソースにアクセスするためにENI(Elastic Network Interface)を利⽤する
  18. 18 ここまでのまとめ LambdaからRDSにアクセス したければ、VPC Lambdaを 利⽤する必要がある ※RDSのエンドポイントをインターネット向けに公開するやり⽅もあります

  19. 19 無駄なコスト • Lambdaについて 5分 • VPC Lambda × RDSのデメリットについて

    • VPC Lambdaと⾮VPC Lambdaについて • まとめ 3分 12分 2分
  20. 20 VPC LambdaあるいはVPC Lambda × RDSのデメリット • コネクションプーリングの問題 • 同時接続数の問題

    • IPアドレス枯渇問題 • インターネットアクセスにNAT Gatewayが必要 (その分コストが・・・) 今回話しません • コールドスタートの問題 XXX問題という表現は良く聞くけど、具体的に何が問題︖︖
  21. 21 コネクションプーリングの問題

  22. 22 コネクションプーリングとは︖ プログラムからデータベースへ接続を確⽴する際、 接続要求のたびに接続・切断を繰り返すのではなく、 ⼀度確⽴した接続(コネクション)をプール(保 持)しておき、再利⽤する⼿法 速度⾯のメリット • 接続が早くなる •

    Prepared Statementを共有すること で、SQLの実⾏が早くなる 可⽤性のメリット • 接続要求のスパイクを回避しやす い • 同時接続数超過のエラーを避けや すい
  23. 23 コネクションプーリングのメリット(⼀例) コネクションプーリングを使うことで これらの初期化処理を省略可能

  24. 24 ⼀⼝にコネプーといっても⽅式は様々 • 例) PreForkのApache × PHPでxxxx_pconnect • プロセスを跨いでコネクションは共有できない •

    永続化であって「プーリング」ではない シングルスレッドのWeb(AP)サーバーで接続を永続化 • 例) Tomcat JDBC Connection Pool • スレッド間で接続を共有することで、物理的な同時接続数を削減できる可能性 がある マルチスレッドのWeb(AP)サーバーでプーリング • 例) pg_pool2 × PostgreSQL • 中間層を設けることで、プロセスを跨いでコネクションを共有できる ミドルウェアでプーリング DBMSの特性によってコネプーの効果もマチマチ...
  25. 25 ⼀⼝にコネプーといっても⽅式は様々 • 例) PreForkのApacheでxxxx_pconnect • プロセスを跨いでコネクションは共有できない • 永続化であって「プーリング」ではない シングルスレッドのWeb(AP)サーバーで接続を永続化

    • 例) Tomcat JDBC Connection Pool • スレッド間で接続を共有することで、物理的な同時接続数を削減できる可能性 がある マルチスレッドのWeb(AP)サーバーでプーリング • 例) pg_pool2 • 中間層を設けることで、プロセスを跨いでコネクションを共有できる ミドルウェアでプーリング Lambda実⾏環境でも実現可能 ※明⽰的に接続を閉じるタイミングが無いことに注意 Lambda実⾏環境では実現不可能 Lambda実⾏環境でも実現可能 ※メリットが出せるかどうかは別にして...
  26. 26 コネプーに求めるのは可⽤性︖︖ • Lambdaは1コンテナが1リクエストを処理する • リクエスト間では完全にプロセスが分離しており、コンテナを跨いだ接続 の共有はできない コンテナ コンテナ コンテナ

    環境分離 環境分離
  27. 27 コネプーに求めるのは速度︖︖ • handler内で毎回RDSに接続して、接続に要する時間を計測 • PostgreSQLでも10 〜 100ms程度の遅延に収まることが多い • 性能要件がシビアならRDS以前にLambdaの採⽤を⾒直すべきでは︖

  28. 28 コネクションプーリングの問題 コネクションプーリングに 何を求めますか︖ そのワークロードには 本当にコネクションプーリング が必要でしょうか︖

  29. 29 同時接続数の問題

  30. 30 同時接続数の問題について • RDBには最⼤同時接続数のパラメータがある • 最⼤同時接続数を超える接続要求はエラーになる 例えばデフォルトの設定値を採⽤したAmazon Aurora PostgreSQLの 場合、最⼤同時接続数は以下のようになる

    インスタンスクラス max_connections db.r5.large 1600 db.r5.xlarge 3300 db.r5.2xlarge 5000 db.r5.4xlarge 5000 db.r5.12xlarge 5000 db.r5.24xlarge 5000 上限緩和申請無し状態での Lambdaの同時実⾏数上限 1000を上回っている
  31. 31 コストと同時接続数の関係(DynamoDBの場合) • DynamoDBでは処理可能な最⼤同時接続数を意識する必要性は無い • 接続数が増えればその分コストが増えるだけ • ※⾮オンデマンドモードの場合はキャパシティ超過に注意 コスト 実際の接続数

    DynamoDBにおける接続数とコストの関係
  32. 32 コストと同時接続数の関係(RDSの場合) • 最⼤同時接続数を上げるにはインスタンスタイプを変える必要がある • 柔軟にスケールアップできない • コストを最適化できない RDBにおけるコストと同時接続数の関係 処理可能な最⼤同時接続数とコスト

    実際の接続数 インスタンスタイプ変更 インスタンスタイプ変更 無駄なコスト
  33. 33 同時接続数の問題 ⾃動スケール、完全従量課⾦といっ たLambdaのメリットが薄れる

  34. 34 同時接続数の問題 システムのワークロードが予想可能 で、⼤量の同時接続数が発⽣しない なら特に問題にはならない コストメリットは薄れるが APサーバーがLambdaになるだけでも ⾮サーバーレスな構成よりも メリットは出せる

  35. 35 同時接続数の問題 DBの同時接続数をユーザーの アクセス数に置き換えた場合に どの程度のアクセス数になるのか 把握した上で判断を︕︕ max_connections: 100で処理可能な限界値は1万アクセス/h ︖ それとも5万/h︖

  36. 36 IPアドレス枯渇問題

  37. 37 IPアドレスの枯渇について • LambdaがVPC内のリソースにアクセスするためにはENIが必要 • ENIごとにIPアドレスを消費する • 多数のVPC Lambdaが起動するとIPアドレスが枯渇する可能性が・・・ Micro

    VM Lambda関数実⾏環境 (コンテナ) Worker VPC Amazon RDS AWS Cloud Elastic network interface
  38. 38 IPアドレスの枯渇について Lambdaのコンテナ1つにつき1つのENIを消費する訳では無い Micro VM Lambda関数 実⾏環境 (コンテナ) Worker Lambda関数

    実⾏環境 (コンテナ) Lambda関数 実⾏環境 (コンテナ) Lambda関数 実⾏環境 (コンテナ) ※EC2モデルの場合の例 Projected peak concurrent executions * (Memory in GB / 3GB) ENIキャパシティの計算式
  39. 39 Lambda実⾏環境1つにつき 1つのENI(IPアドレス)を 消費する訳では無い /16ネットマスクで作成した VPCでもIPが枯渇するほどの⼤量 アクセスが予想されますか︖︖

  40. 40 コールドスタートの問題

  41. 41 コールドスタートの問題について (ENIの作成) コンテナの作成 デプロイパッケー ジのロード デプロイパッケー ジの展開 ランタイム 起動・初期化

    関数・メソッドの 実⾏ コンテナの破棄 20190402 AWS Black Belt Online Seminar Let's Dive Deep into AWS Lambda Part1 & Part2 https://www.slideshare.net/AmazonWebServicesJapan/20190402-aws-black-belt-online- seminar-lets-dive-deep-into-aws-lambda-part1-part2 VPC Lambdaの コールドスター ト時に発⽣
  42. 42 コールドスタートの問題について ENIの作成は遅い(10秒~20秒程度) • ※Lambdaのコンテナ1つにつき1つのENIを消費する訳では無い • Lambdaの初期化処理が⾛る = ENI作成処理が⾛る では無い

    • Lambda関数へのメモリ割り当てを減らすことでENI作成の頻度を下げられる
  43. 43 コールドスタートの問題 2019年中にVPC Lambdaの コールドスタートが 改善されることがアナウンス済み

  44. 44 コールドスタートの改善について 以後はre:invent2018のセッション ベースでの情報になります 実際のスケジュールは現時点では 未定(のはず)です ※今後の予想を含む内容なので注意

  45. 45 コールドスタートの改善について 画像はre:invent2018「 SRV409 A Serverless Journey: AWS Lambda Under

    the Hood 」の発表資料より引⽤ https://www.slideshare.net/AmazonWebServices/a-serverless-journey-aws-lambda-under-the-hood-srv409r1-aws-reinvent- 2018?ref=https://dev.classmethod.jp/cloud/aws/reinvent2018-srv409/ • コールドスタート時にENIを作成し てWorkerにアタッチする構成 • WorkerごとにIPアドレスを1つ消費 • Lambda関数作成時にENIを作成 • Worker外のRemoteNATというコン ポーネントでENIとのNAT処理を⾏ • 複数のWorkerで1つのENIを共有
  46. 46 コールドスタートの問題について • ENI作成を伴わなければ現状でもVPC Lambdaの初 期化処理は⼗分に⾼速 • VPC Lambdaの改善がリリースされれば、コール ドスタート時の⼤幅な遅延が無くなりそう︖︖

    • ENI作成を⾼速化するというアプローチでは無い ので、スケールアウト時の挙動は注意(予想です) • スパイクが想定されるワークロードには引き続き要注意︖︖
  47. 47 アジェンダ 無駄なコスト • Lambdaについて 5分 • VPC Lambda ×

    RDSのデメリットについて • VPC Lambdaと⾮VPC Lambdaについて • まとめ 3分 12分 2分
  48. 48 まとめ VPC Lambda × RDSという構成は⼀般的にアンチパターンと されており、実際に様々なデメリットが存在する システム要件次第ではデメリットを受容する選択肢も有効 ⼤きなデメリットであるコールドスタートの遅延について は改善の予定あり

  49. 49 まとめ VPC Lambdaの特性を 理解した上で ユースケースに応じた 適切な判断を︕︕

  50. 50 まとめ 別にVPC Lambdaでええやん

  51. 51 ご静聴ありがとうございました

  52. 52