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

AWS Summit Online Japan 2022

森田力

2022.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 を利用する
- コネクションの再利用