【レポート】AWS Lambda Performance Tuning Deep Dive〜本当に知りたいのは”ここ”だった 〜 AWS-46 #AWSSummit

【レポート】AWS Lambda Performance Tuning Deep Dive〜本当に知りたいのは”ここ”だった 〜 AWS-46 #AWSSummit

Clock Icon2022.05.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、森田です。

本記事は、2022年5月26日(木)に行われたAWS Summit Onlineのセッション「AWS Lambda Performance Tuning Deep Dive〜本当に知りたいのは”ここ”だった 〜」のセッションレポートとなります。

こちらのセッションでは、今日から使える Lambda 関数の Tips が多く紹介されております。

ぜひチェックしてみてください!

セッション概要

 

AWS Lambda は 2014年に登場してから、 当初は予想もしていなかった幅広いユースケースで利用されるサービスへと成長しました。 今ここで再度 AWS Lambda のパフォーマンス・チューニングを理解することで、ビジネスをより加速させてみませんか?このセッションでは AWS Lambda の"ビジネスロジックにフォーカスできる"といった特徴を最大限活かすために、原点であるパフォーマンス・チューニングに絞って Deep Dive してみたいと思います。

 

スピーカー

AWS 技術統括本部

シニア サーバーレス スペシャリスト ソリューションアーキテクト

下川 賢介 氏

 

セッションレポート

AWS Lambda の スケーリング

  • 同時実行(Concurrency)
    • Little’s Law (リトルの法則)
      • Concurrency = rps((リクエストレート) × duration(実行時間)
    • クォータ 1000
      • スロットリンクに注意する
      • アカウント・リージョン単位で共有

Tuning の観測

  • 同期的な Serverless アーキテクチャ
    • API Gateway, AWS Lambda, Aurora, Secrets Manager, CloudWatch Metrics
      • DBへの負荷・Connection枯渇
      • Secrets Manager, CloudWatch Metrics スロットリング
    • Lambda の Concurrencyの制御
      • Concurrency は、共有プール
      • 関数単位で Concurrency の設定可能
        • Concurrency の最大値を事前定義
      • 制御するには
        • CloudWatch Metrics 標準1分
        • CloudWatch Logs Insights 1sの分解能で抽出
      • Duration Metrics
        • 外部リソースが原因の可能性を検討
        • コードチューニング
          • ベストプラクティスを参考

Lambda 実装プラクティス

  • 効率的なコード
    • FAT / モノリシックなコードは避ける
    • 依存パッケージを最小化
    • Tree shaking
  • 揮発性を意識する
    • 揮発性はあるが、リクエストをまたいで再利用される
      • オブジェクトのロードを遅延させる
      • グローバルスコープを利用
      • Dynamicなオブジェクトを作成しない
  • 同期的なServerless アーキテクチャ(6000rpsの場合)で考えてみる
    • Secrets Manager スロットリング
      • 5000rps 緩和不可
        • グローバルスコープに変更
          • Concurrencyの数に
    • CloudWatch Metrics スロットリング
      • 150rps 緩和可能
      • CloudWatch embedded metric format を利用
        • 自動的に非同期で処理
    • Database コネクション枯渇
      • RDS Proxy を利用
        • Secrets取得可能
      • CQRS による緩和
        • データベースを分ける
          • 単純クエリ DynamoDB
          • 複雑クエリ RDS
          • DynamoDB Stream で結果整合
      • Store選択による緩和
        • DynamoDBへの移行
    • Throttling に包括的に対処
      • Queue による緩和
        • SQS
          • デッドレターキュー
        • ユーザによってアーキテクチャを切り替える
        • 結果整合
  • 簡素な Lambda 関数
    • ハンドラーをコアロジックから分離
      • 単体テストが容易に
    • TRANSPORTではなくTRANSFORM
      • 外部APIは他のサービスに任せる
      • ビジネスロジックだけを実装する
    • 必要な情報だけを取得
      • DBの適切なIndex化
      • S3取得の場合もGetObjectではなく、SelectObjectContent
  • Event Filtering
    • SNS, EventBridge, S3
      • サービス側でのフィルタリング
    • SQS, Kinesis, DynamoDB
      • Lambda 側で Content base filtering
  • S3 Select
    • 必要なデータだけを返すことができる
  • 外部API
    • 別のサービスへオフロード
      • EventBridge
  • Node.js の Keep-Alive を利用する
    • コネクションの再利用

CPU の上⼿な利⽤⽅法

  • AWS Lambda Power Tuning によるチューニング
    • Step Functions を利用
    • 適切なメモリ量を確認できる
  • INIT CPU boost
    • 最初の 10s 間のみ
    • Node.js の際には ES modules
  • Multi thread
    • 1769MB以上の時は効果が期待できる
    • 基本は Lambda 関数の並列起動を検討

最後に

Lambda のコード実装の際に、意識すべきポイントがいくつも紹介されており、非常に参考になりました。

特にスロットリングの考え方は、今後アーキテクチャを構成する上で役に立ちそうです。

一部コードの解説もありますので、ぜひ配布資料もチェックしてみてください。

 

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.