毎年参加しているServerless Conf Tokyoです。3回目になります。
昼を食べると眠くなるので、最近はランチを取らない様になってきました。サクッと集中してやって、さくっと、ね。
http://tokyo.serverlessconf.io/tokyo.serverlessconf.io
他のセッション
引用は私のコメントです。
目次
- 目次
- Title
- Speaker
- 資料
- サーバーレスシステム開発バックグラウンド
- サーバーレスシステムの運用監視の課題
- 第一次監視 : CloudWatch + 人力デバッグ
- 第二次監視 : CloudWatch Logs の内容から自動エラーチェック、X-Ray導入
- 第三次監視 : Observability
- 第四次監視 : IoT、機械学習
- まとめ
Title
サーバーレスなシステムの頑張らない運用監視 - Monitoring からObservabilityへ
Speaker
鈴木 貴典 @takanorig
資料
サーバーレスシステム開発バックグラウンド
AWS を利用している。 主にServerless Framework をつかっている。
サーバーレスシステムの運用監視の課題
サーバーレスはサーバーは見なくてもいいけど、アプリケーション監視としては変わってない、むしろモノリシックよりも大変。
- サーバーはなくても、ファンクションやサービスの時状況は関しが必要
- イベントドリブンなシステムは、どのようによびだされているか、どこで障害が発生しているのかトレースが大変
- どれだけリソースを消費しているか、わかりにくいので最適化しにくい
| 違い | メリット | ・デメリット |
|---|---|---|
| 従来 | アプリ構築簡単、デバッグ、運用もわかりやすい | 冗長化考慮必要、サーバー管理必要 |
| サーバーレス | 開発スピードUP、拡張性、冗長化は任せられる | デバッグ難しい、システム細分化、分散化する |
つまり、開発容易性、スピードは向上するけど、運用監視は複雑化する。
第一次監視 : CloudWatch + 人力デバッグ
デバッグ効率が悪い、原因特定、解決まで時間がかかる。 問題が発生しないと気づかない。 監視できていない内容も多い。
- 監視自体のメンテナンスに手間がかかる
- だんだんとダッシュボードなどをみなくなる
第二次監視 : CloudWatch Logs の内容から自動エラーチェック、X-Ray導入
CloudWatch Logs を使って、自前で監視アプリを作ってエラーチェックを開始した。 X-Ray でデバッグ構築や監視が向上。
from aws_xray_sdk.core import xray_recorder from aws_xray_sdk.core import patch_all patch_all()
X-Ray でサービスマップ、実行状況、トレース詳細がわかる。
実行状況では、処理時間のパーセンタイルやエラーの発生状況を確認できる。 トレース詳細では、処理ごとの時間が見える。
第三次監視 : Observability
重要なのは Observability = 可観測性
Monitoringの上位互換的に。 簡単にシステムの状態を把握したり、アプリケーションの動作を確認したりできること。 トレーシング(X-Ray)、メトリクス(CloudWatch)、ロギング(CloudWatch) を包括している。
- CloudWatch Logs -> ロギング は、Log Streams が別れていて間作しにくいしきつい
- Cloud Watch Metrics -> メトリクスは、Lambda 関数や DynamoDBのテーブル追加時に自分で追加する必要あって吊上
- X-Ray : トレーシングは、とりあえず有効化しておけ
Logging / Metrics / Tracingがあっても、Observability ではない。
アラート化 + 見せるか
- CloudWatch Logs に出力されるログを一定時間ごとにチェック
- メトリクスフィルタは正規表現使えない、サブすくしプションでも都合が合わない
- Lamnbda で横断的にチェック可能にした
- 特定のキーワードを正規表現でチェックし、その内容を検出した際に、該当部分のログをSlackに通知
- Slack には、Cloud Watch Logs へのリンクを設定をし、それをクリックしたらダイレクトにログの内容を確認できるようにしている
- 問題発生箇所、前後の動きがわかるように
当然ですが、リンクはだいじ。
リソースの監視として、 Lamnbda の関数実行時間(制限の80%超えたら)、DynamoDBのキャパシティの消費量(キャパシティの80%超えたら)を見て通知かけている。
サービスの正常性確認として、異常障害以外に、サービス正常可能確認もしている。 テキストでわかりにくいものは、ヘッドレスブラウザを利用して画面キャプチャを通知。(Lambda でキャプチャとって数値)
Datadog の利用を検討してやろうとしている。 Lambndaは、関数増えても自動追加される。時間は絶対時間になる。 DynamoDBも、テーブル増えると自動追加されるし、キャパシティみれる。
どのようなツールを導入するにしても、対象となるサーバーレスシステムに対して、重要なのは、継続的に活用、拡張していくことが重要。
当然DataDog 使うんだけどなぁ.... 考え方は基本のキですね。やり方が時前になるとやっぱりびみょいなぁ。なんというか、自前でやる時点で、(開発し続けないと)継続性が落ちるので厳しい
改善事例
想定外に時間がかかる処理の早期検出
バッチ処理にLambda を利用。 安全のため、5分(Lambda の上限) していた。
処理のどこが時間かかっているか、Step Functions の実行詳細から時間を確認、X-Ray のトレース詳細でどの処理か確認↓。 結果、DynamoDBのTTLの設定質を取得しており、1テーブルあたり3病時間がかかっていた。 全テーブルの処理をしていたので、処理時間がかかっていた。
DataDog で気づけるじゃん.... APM 使えば... はないな、ここはX-Ray のほうがいい。
キャパシティの最適化
Lambda 実行時に DynamoDBからスキャンで複数件のデータを取得。 Redis を使うほどの高速性は不要、コストをかけたくなかった。
Scan はもちろんなるべく使わないほうがいい(特にサーバーレスはスケールするので危険が危ない)
どの程度キャパシティを設定するのか予想しにくい。そのくせ、キャパシティ釣果でデータが取得できなくなったてサービスへの影響が大きい。
正常時 : 10ms 異常時 : 159msかかる。アクセスが増えると処理時間はより長くなり、サービス障害につながる。
この状況からキャパシティの最適化をおこなった。
普通の監視では、処理時間に気づけ無いけど気づけた！
気づけ無い....だと.....
ついでに、同時実行数が多いとLambda の初期化(AWSの準備)に待ちが発生する。 関数の実行実行数を制限して、必要以上にリソースを消費されないように調整。
いいプラクティス。AWSが同時実行数多いと時間かかるのが悪いw
第四次監視 : IoT、機械学習
やりたい
まとめ
普通のアプリ監視と同じで、監視するだけじゃだめなので可視化、気づける化は重要ですねぇ。X-Ray 以外だと、StackDriver ですねぇ。AzureがInsightだけど微妙すぎる。
