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

こんにちは、森田です。

本記事は、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 のコード実装の際に、意識すべきポイントがいくつも紹介されており、非常に参考になりました。

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

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