2019.12.19

すぐに始められるServerlessアーキテクチャのパフォーマンスチューニング

yassan

この記事はAWS LambdaとServerless #1 Advent Calendar 2019の19日目です

サンタにNintendo Switchをくださいとお願いした2児の父 やっさん でございます。

この記事ではすぐに始められるServerlessアーキテクチャのパフォーマンスチューニングと題しまして、Lambda, DynamoDBのパフォーマンスチューニング方法をご紹介いたします！

また、Serverlessの監視については弊社下條の記事、
AWSサーバーレスシステムにおける監視のコツもご参照いただければと思います！

Contents

Lambdaのパフォーマンスチューニング
DynamoDB
1. DynamoDBのプロビジョニングオプション
2. Contributor Insightsによる頻繁に利用されるクエリの確認
AWS X-RayによるE2Eパフォーマンスの確認
おわりに

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(*)

プロビジョニングされたメモリサイズが少ないLambdaを調べる

メモリ残量が 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の5分間隔のレイテンシー統計を調べる

Lambdaの実行時間の 平均 、 最大 、 最小 時間を確認できました。

DynamoDB

DynamoDBのプロビジョニングオプション

Lambdaは無限にスケールしますが、DynamoDBはプロビジョニングオプションによってスケール方法が異なります。ですので、運用中のDynamoDBのキャパシティユニットはボトルネックになりやすいポイントとなります。

運用するアプリケーションに合わせてプロビジョニングオプションを指定する

ワークロードに合わせて適切なプロビジョニングオプションを選択します。

モード	最適なケース	適用例
オンデマンドモード	・未知のワークロード・アプリケーショントラフィックが予測できない。	・スパイクアクセスが発生するワークロード・普段は頻繁に利用されない開発ワークロード
プロビジョンドモード	・アプリケーショントラフィックが予測できる・トラフィックが一定または徐々に変化するアプリケーションを実行する。	・スパイクアクセスが発生しない一定のワークロード