すぐに始められるServerlessアーキテクチャのパフォーマンスチューニング
この記事はAWS LambdaとServerless #1 Advent Calendar 2019の19日目 です
サンタにNintendo Switchをくださいとお願いした2児の父 やっさん
でございます。
この記事ではすぐに始められるServerlessアーキテクチャのパフォーマンスチューニングと題しまして、Lambda, DynamoDBのパフォーマンスチューニング方法をご紹介いたします!
また、Serverlessの監視については弊社下條の記事、
AWSサーバーレスシステムにおける監視のコツもご参照いただければと思います!
Lambdaのパフォーマンスチューニング
Lambdaのメモリサイズ
Lambdaは適切なメモリサイズを指定すればパフォーマンスを確保できます。
しかしながら、全てのLambdaを最大メモリサイズで利用することはコストの増加に繋がります。では、どのようにして適切なメモリサイズを測ることができるのでしょうか。
CloudWatch Logs Insightを利用したメモリサイズの分析
CloudWatch Logs Insightを利用することで、実際のLambdaで実行されたログを分析し適切なメモリサイズを確認することができます。
過剰にプロビジョニングされたメモリサイズを調べるクエリの例
filter @type = "REPORT"
| stats max(@memorySize / 1024 / 1024) as provisonedMemoryMB,
min(@maxMemoryUsed / 1024 / 1024) as smallestMemoryRequestMB,
avg(@maxMemoryUsed / 1024 / 1024) as avgMemoryUsedMB,
max(@maxMemoryUsed / 1024 / 1024) as maxMemoryUsedMB,
provisonedMemoryMB - maxMemoryUsedMB as overProvisionedMB
923MBの overProvisionedMB
が確認できました。
プロビジョニングされたメモリサイズが少ないLambdaを調べるクエリの例
filter @type = "REPORT"
| fields (@memorySize / 1024 / 1024) as memorySize, (@maxMemoryUsed / 1024 / 1024) as maxMemoryUsed, memorySize - maxMemoryUsed as RemainingMemorySize, @logStream, @message
# メモリ残量が50MBを切っている実行を抽出
| filter RemainingMemorySize < 50
| stats count(*)
メモリ残量が 50MB
を下回っている実行回数を確認できました。
Lambdaの処理時間
Lambdaはメモリサイズに比例してCPUパワーも割り当てられます。
ですので、メモリ消費が少ないからとメモリサイズを下げますと、CPUパワーも下がってしまうところがLambdaのパフォーマンスチューニングの難しいところだと思います。これについても、CloudWatch Logs Insightを利用して分析することが可能です。
CloudWatch Logs Insightを利用した処理時間の分析
Lambdaの5分間隔のレイテンシー統計を調べる
filter @type = "REPORT"
| stats avg(@duration), max(@duration), min(@duration) by bin(5m)
Lambdaの実行時間の 平均
、 最大
、 最小
時間を確認できました。
DynamoDB
DynamoDBのプロビジョニングオプション
Lambdaは無限にスケールしますが、DynamoDBはプロビジョニングオプションによってスケール方法が異なります。ですので、運用中のDynamoDBのキャパシティユニットはボトルネックになりやすいポイントとなります。
運用するアプリケーションに合わせてプロビジョニングオプションを指定する
ワークロードに合わせて適切なプロビジョニングオプションを選択します。
モード | 最適なケース | 適用例 |
---|---|---|
オンデマンドモード | ・未知のワークロード ・アプリケーショントラフィックが予測できない。 |
・スパイクアクセスが発生するワークロード ・普段は頻繁に利用されない開発ワークロード |
プロビジョンドモード | ・アプリケーショントラフィックが予測できる ・トラフィックが一定または徐々に変化するアプリケーションを実行する。 |
・スパイクアクセスが発生しない一定のワークロード |
Contributor Insightsによる頻繁に利用されるクエリの確認
「CloudWatch Contributor Insights for DynamoDB」を利用することで、
以下のルールが作成され、視覚化することが出来ます。
- 最もアクセスされたアイテム
- 最も調整されたキー
Contributor Insights for DynamoDBの有効化
有効化はDynamoDBのテーブル毎に行います。
以下のようにメトリクスとして確認できます。
これにより、 スロットリングされた項目
を確認しボトルネックを調査できるようになりました。
AWS X-RayによるE2Eパフォーマンスの確認
Lambdaを利用する場合は、AWS X-Rayによるトレースをすぐに有効化できます。
X-Rayのトレースデータにより、処理時間を確認することができました。
また、API Gatewayのトレースデータも有効化することでAPI Gatewayのレイテンシーも測ることが出来ます。
おわりに
Serverlessアーキテクチャのパフォーマンスチューニングとして、すぐに始められる内容を紹介いたしました。もちろん、パフォーマンスチューニングの方法はこれらだけではありません。例えば、 DataDog
などのSaaSを利用して得られた情報からパフォーマンスを確認する手法もございます。
少しでもお役に立つ情報を提供を出来ていれば幸いです。
ぜひ以下のページも合わせてご覧ください。