AWS

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

MMM Corporation
yassan

この記事は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(*)

プロビジョニングされたメモリサイズが少ない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のキャパシティユニットはボトルネックになりやすいポイントとなります。

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

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

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

Contributor Insightsによる頻繁に利用されるクエリの確認

「CloudWatch Contributor Insights for DynamoDB」を利用することで、
以下のルールが作成され、視覚化することが出来ます。

  • 最もアクセスされたアイテム
  • 最も調整されたキー

Contributor Insights for DynamoDBの有効化

有効化はDynamoDBのテーブル毎に行います。
Contributor Insights for DynamoDBの有効化

以下のようにメトリクスとして確認できます。
Contributor Insights for DynamoDBのメトリクス

これにより、 スロットリングされた項目 を確認しボトルネックを調査できるようになりました。

AWS X-RayによるE2Eパフォーマンスの確認

Lambdaを利用する場合は、AWS X-Rayによるトレースをすぐに有効化できます。
AWS X-Rayの有効化

AWS X-Rayのトレース結果

X-Rayのトレースデータにより、処理時間を確認することができました。
また、API Gatewayのトレースデータも有効化することでAPI Gatewayのレイテンシーも測ることが出来ます。

おわりに

Serverlessアーキテクチャのパフォーマンスチューニングとして、すぐに始められる内容を紹介いたしました。もちろん、パフォーマンスチューニングの方法はこれらだけではありません。例えば、 DataDog などのSaaSを利用して得られた情報からパフォーマンスを確認する手法もございます。

少しでもお役に立つ情報を提供を出来ていれば幸いです。

ぜひ以下のページも合わせてご覧ください。

サーバーレスアーキテクチャ(AWS Lambda)

クラウド運用監視(Datadog)

AUTHOR
Yasuyuki Sato
Yasuyuki Sato
記事URLをコピーしました