開発者におくるサーバーレスモニタリング

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
開発者におくる
サーバーレスモニタリング
AWS CREATIVE STUDIO | 2018

自己紹介
名前
小梁川貴史（こやながわたかし)
所属
技術統括本部
シニアソリューションアーキテクト
前職
電機メーカー自社サービスの開発・運用
元AWSユーザ
好きなAWSサービス
AWS IoT , AWS Lambda(python), Amazon Kinesis

本セッションの目的
Serverlessな構成、AWS Lambdaの導入でサーバ管理はなくなるが、運用業務は発
生する。本セッションでは、AWS Lambdaを中心にmetricsの意味/監視ポイントを
説明する
本セッションの対象
• AWS Lambdaを開発している方
• Severlessの運用に興味がある方
お話しないこと
• 各サービスのベーシックな説明
• AWS Fargate/Amazon Aurora Severlessのお話
• AWS Lambdaのコーディングに関わるお話

開発者にとってのモニタリングとは？
いま下記の質問にすぐに回答できますか？
• Lambdaの平均速度時間
• Lambdaの使われる方
• エラー回数
• 使っているログ容量
• deploy前後での性能差分
自分が作ったものがどう使われているのか/動いているのか？、や改善点
が見えるようにしておくのが重要。
また、運用を人に託すのであれば何を見るのかを提示する責任を持つべき。

Agenda
• AWS Lambdaのモニタリング
• X-Rayの利用
• CloudWatchとの連携
• Amazon API Gatewayのmetrics
• まとめ

AWS Lambdaのモニタリング

AWS Lambda起動パターンの違いによる考え方の違い
イベントベースストリームベース SQSベース
• S3
• API Gateway
など
• Kinesis streams
• DynamoDB streams
• SQS
ストリームのシャード数:Lambda
= 1:1
シャードの追加に自動追従
log polling型、queueの
数に応じてLambda 起動
数がauto scale
イベント数:Lambda =
n:n
Kinesis StreamS3 bucket
SQS
自動log polling
(最大10までの複数件取得)
自動polling
(指定したbatch sizeデータを取得
最大1万件まで指定可能)イベントから発火

（復習)同時期同数の定義
1s 2s 3s 4s 5s
秒間リクエスト:
10 req/sec
関数の平均実行時間: 3s / exec
同時実行数
= “同時”に実行されているタイミング

AWS Lambdaのモリタリングの意味
項目単位意味
Invocations count Lambdaの実行回数を計測したもの。=課金カウント
≠同時起動数
Duration ms Lambdaの実行時間を計測。（課金は100msで切り上げる)
※コールドスタートのLambda起動までの時間は含まない
Errors, Availability count Lambdaが正常終了しなかった回数を計測したもの
Availabilityは%で表示される
Throttles count Throttleの発生回数
アカウントにおけるLambdaの同時起動数超過が発生している
IteratorAge ms ストリーム(kinesis/dynamoDB)でのみ利用。バッチサイズ分取得し
たレコード終端の時刻とLambdaがイベントとして受信した時刻差で
表示される
DeadLetterErrors count DLQを設定し、そのDLQへの書き込みが失敗すると増加する。

metricsのdurationの意味
1. （ENIの作成）
2. コンテナの作成
3. デプロイパッケージのロード
4. デプロイパッケージの展開
5. ランタイム起動・初期化
6. 関数/メソッドの実行
• VPCを利用する場合だけ
• 10秒〜30秒かかる
• Durationには含まれない

• 指定されたランタイム
• S3からのダウンロードとZIP
ファイルの展開

• 各ランタイムの初期化処理
• グローバルスコープの処理もこ
のタイミングで実行される

• ハンドラーで指定した
関数/メソッドの実行
• Durationの値はここの実行時
間

すべてを実行するのがコールドスタート

基本的に毎回同じ内容が実行される
再利用することで省略して効率化
（ウォームスタート）

イベントベースでのAWS Lambda注意事項
AWS Lambdaは呼び出されれば最低一回は実行することを保証している。
呼び出し側が呼び出さない、複数回呼び出すことは発生する。
この事象はAWS Lambdaでは監視/検知ができないので全体の仕組みで検
討する必要がある
対処例
• アプリケーション側での冪等性の確保
• 例えばS3であればイベント発火用バケットと処理済みバケットを作成
することで、イベント発火漏れを検知するなど

ストリームベースのLambda
同時実行数
ストリーム
シャード1
シャード2
シャード3

ストリームベースはerrorを検知したら要注意
https://aws.amazon.com/jp/lambda/faqs/
異常データ
Stream
Batch
size 2
2件read /処理
し、正常終了
続きの2件をread、
1件目のデータで
exception 終了
checkpointが進ま
ないので、同じ
データを読む
（有効期限まで)
これを防ぐには、不正データは
ログ、queueなどに通知、
Lambdaは正常終了させる
checkpoint
正常終了に合わせて
checkpointが進む
Lambdaが正常終了ではないの
で、checkpointが進まない

ストリーム型での監視事項
▲shard分割で
Lambda起動数が倍
5分約300
= 1act/sec
で計算どおり
5分のなかの
metrics max
が表示されて
いる
0.3秒間隔でdataをkinesis streamsへ送信し、途中でshard分割を実行した
Lambdaのモニタ画面例
▲shard分割でLambda新規
分の起動遅延

先程のIteratorAgeをCloudwatch metricsでみると
意味を間違うと大違いになるので、表示の意味を理解することが重要

ストリームベースでの監視/運用ポイント
IteratorAgeの”Average”が大きくなっている場合は処理遅れが想定される。
• Lambda実行環境のスペックにより実行時間の短縮を考える
• Kinesis Streamsのshardを分割
• shardを分割することで並行処理数が増える
• 東京リージョンの場合1 stream/200shard分割まで可能
Error metricsが上がった場合は、処理がロックされている可能性がある。
• Lambdaのプログラム改修
• kinesis streamsの読み込みをlatest/timestampベースで再設定
• データを読まずに捨てることになるので注意
Streamの場合、Errorを挙げないように設計/テストをすることが重要

SQS型起動のLambdaでのmetrics
0.5秒間隔でqueueを送信した場合。metricsは標準の5min
5分580回の実行で
きるまでスケール
queueの送信を止めたことで
並行起動のLambdaが減少

LambdaのSQS起動における注意事項
メッセージ到達時の挙動: 5つのパラレルロングポーリング接続を使用し
てSQSキューのポーリングを開始、メッセージ数 > 処理量の傾向が続き、
最終的に処理が追いつかない場合、コンカレンシーリミットまでスケール
する。
Lambda単位にコンカレンシーを制限しない場合アカウントの上限までス
ケールする可能性があり、他のLambdaの起動を妨げる可能性があるので、
大規模に使用する際にはコンカレンシーの設定も検討する

AWS Lambda共通で気をつける事項
Throttleを観測した場合
• どのAWS Lambdaが大量に使っているかの特定
• CloudWatchのAll across accountでアカウント全体での使用状況と個別Lambdaの使用状況を確認
• Limit increaseの申請
Error metricsが増加している
• 権限設定漏れ
• SQS/ストリームであり得るパターン、バッチサイズとプログラム処理時間とLambdaのタイマ値の関
係を確認
• 1処理時間 x バッチサイズ > タイマ値となるこれも処理が進まないパターンになる
Dead Letter Queueが増え続ける
• 後段処理、連携システムのダウンなど、システム系としての障害の確認などを実施
リトライ処理の考慮
• 非同期型であれば1回の実行、2回のリトライが行われ、すべて失敗した場合に、（設定していれ
ば） Dead Letter Queueへ送られる

X-Rayの利用

AWS X-Ray
リクエスト実行状況の確認
アプリケーションを構成する
個々のサービスやリソースの
実行結果ステータスを集計し、
アプリケーションの実行状況を
エンドツーエンドで確認可能
アプリケーションの問題の検出
アプリケーションの実行状況に
ついての関連する情報を収集し、
問題の根本原因を調査可能
アプリケーションのパフォーマンス向上
サービスやリソースの関係をリアルタイムで
表示し、レイテンシ増加やパフォーマンス低下
などのボトルネックを特定可能
AWSとの連携
Amazon EC2, Amazon ECS,
AWS Lambda, AWS Elastic Beanstalk
と連携
さまざまなアプリケーション向けの設計
非同期のシンプルなイベント呼び出し、
３層のウェブアプリケーション、数千の
サービスから構成される複雑なマイクロ
サービスも分析可能

AWS X-Ray コンポーネント
User
Amazon API
gateway
AWS Lambda
Amazon
DynamoDB
Amazon
SQS queue

AWS LambdaでX-Rayを利用するためには、、
Lambda用パッケージにX-Ray SDKを追加し、アクティブトレースをONに
する。IAM roleも必要、Managed policyが容易されている
• Pythonの場合
• Python 2.7, Python3.6以降
• Node.jsの場合
• Node.js 4.3以降
• Javaの場合
• Java8以降
• Goの場合
• Go1.7以降
• .NETの場合
• .NET Core 2.0以降
https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-usage.html#xray-usage-languages
CLIであれば、
--tracing-config オプション

実装例
import boto3
import json
import requests
from aws_xray_sdk.core import xray_recorder
from aws_xray_sdk.core import patch_all
patch_all()
def main(event, cotext):
xray_recorder.begin_segment(‘main segment’)
(main処理)
xray_recorder.begin_subsegment(‘sub segment’)
(処理A)
xray_recorder.end_subsegment(‘sub segment’)
xray_recorder.end_segment
return

実装例
import boto3
import json
import requests
patch_all()
(main処理)
(処理A)
return
対応しているライブラリにパッチ適用
pythonの場合
-botocore, boto3
-requests
-sqlite3
-mysq-connector-python
など
patch_allではなく patch(’boto3’)などとすることも可能

実装例
import boto3
import json
import requests
patch_all()
(main処理)
(処理A)
return
処理全体のセグメントを定義

実装例
import boto3
import json
import requests
patch_all()
(main処理)
(処理A)
return
処理の中でセグメントブロックを着ることも可能

実装例
import boto3
import json
import requests
patch_all()
(main処理)
(処理A)
xray_recorder.end_subsegment()
xray_recorder.end_segment()
return
処理をとじる

サービスグラフ
各ノードの呼び出しの結果を
色で分類し、割合を円グラフに
• グリーン成功した呼び出し
• レッド 5xx errors
• イエロー 4xx errors
• パープル 429 Too Many Requests
(スロットリングエラー)
・平均レイテンシ (ms)
・トレース数 (trace/min)
・サービス名
・サービスの分類

CloudWatch Logsとの連携

CloudWatch Logs filter pattern
filter patternの仕様
• 大文字、小文字は区別される
• 正規表現は利用できない
• 簡単なパターンマッチのみ利用可能
• JSON形式、スペース区切りは利用可能

パターンマッチングの利用例
ログが正規化されていなくても一致する文字列の検索も可能。アプリケーション
が出力するローグフォーマットと利用ルールを明確化することでmetric filterも作
成できる。printで出力するのではなく、logger関数などを利用してログ出力する
ことがおすすめ

他サービスに連携してログの活用
CloudWatch
Logs
Lambda
Function
Amazon ESサブスクライブ
より複雑な解析処理の実装
各種 AWS サービスと連携：
アラート、スケーリング、
Blacklisting、etc…
自由に処理を実装

細かい部分で
Lambdaのログ保管期間はデフォルトが無期期限
必要な期間に圧縮することを忘れがち

例えば、Lambdaのログ保管周期を定期チェック
import boto3
save_days = 30
clw_l = boto3.client('logs')
def describe_logs():
res = clw_l.describe_log_groups(
logGroupNamePrefix = “/aws/lambda”
)
log_groups = res['logGroups']
#-- get group name from all information
log_group_names = []
for log_group_info in log_groups:
if log_group_info['retentionInDays'] != save_days:
log_group_names.append(log_group_info['logGroupName'])
return log_group_names
def change_log_set(log_list):
for log_name in log_list:
try:
clw_l.put_retention_policy(
logGroupName = log_name,
retentionInDays = save_days
)
time.sleep(0.5)
except Exception as e:
pass
return
def main(event, context):
log_list = describe_logs()
change_log_set(log_list)

import boto3
save_days = 30
)
try:
)
time.sleep(0.5)
pass
return
CloudWatchのロググループを取得

import boto3
save_days = 30
)
try:
)
time.sleep(0.5)
pass
return
適切なログ期間をチェック

import boto3
save_days = 30
)
try:
)
time.sleep(0.5)
pass
return
適切なログ保存期間を変更
APIガスロットリングされないようにsleepも

API Gatewayの監視

Amazon API Gatewayのモリタリングの意味
項目単位意味
4xxError count Sumは4xxエラーの合計数、Averageは4xxエラー率
5xxError count Sumは5xxエラーの合計数、Averageは5xxエラー率
CacheHitCount count APIキャッシュからレスポンスした、
Sumはキャッシュヒットした数、Averageはキャッシュヒット率
CacheMissCount count キャッシュを有効にしているが、バックエンドから応答した数
Sumはキャッシュミスヒット数、Averageはキャッシュミス率
Count count APIのリクエスト数
IntegrationLatency ms API Gatewayが、バックエンドへリクエストして、バックエンドから
レスポンスが返却されるまでの時間
Latency ms API Gatewayがクライントからリクエストを受け取り、クライントに
返却するまでの時間。API Gatewayのオーバヘッドも含まれる

Amazon API Gatewayのメトリクスフィルタで使えるディメンション
項目意味
ApiName 指定したAPI名のメトリクスのフィルタリング
ApiName,
Method, Resource,
Stage
指定したAPI名、メソッド、リソース、ステージのフィルタリング
※：詳細なCloudWatchメトリクスを有効にする必要がある
ApiName,
Stage
指定したAPI名とステージのフィルタリング

まとめ

まとめ
AWS Lambdaの使用に関わる考え方やmetricsは存在するが、
アプリケーション開発、運用においては一般的な知識と経験は活用できる。
CloudWatch Logsや3rd partyツールなどの監視ツールの要件に合わせた
ログ設計なども通常のアプリケーション設計と変わらない。
AWSの制約や仕様を理解し、今までのアプリケーション開発経験とあわせ
ることで従来のアプリケーションよりも、柔軟なアプリケーション開発/
運用もできる可能性がある。
（Serverlessが合わないユースもあるので、見極めは必要)

開発者におくるサーバーレスモニタリング

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 開発者におくるサーバーレスモニタリング

Similar a 開発者におくるサーバーレスモニタリング (20)

Más de Amazon Web Services Japan

Más de Amazon Web Services Japan (20)

Último

Último (9)

開発者におくるサーバーレスモニタリング