毎年参加しているServerless Conf Tokyoです。3回目になります。
他のセッション
引用は私のコメントです。
Title
What We Should All Worry About When Monitoring Serverless Applications
Speaker
Nitzan Shapira @nitzanshapira
Slide
[]
Complexity and Monitoring
Serverlessは複雑.... Resourceは管理したい、Applicationはどんどん複雑になっていく..... 管理不可能になる前に関しを...。
Functionは大事 (貴重)
- Out of Memory
- Cold start
- Timeout
でもみたいのは、Serviceですよー。
System > Function
これは重要で、Systemは、Functions + APIs + Transactionsなので、Functionの集合がサービスではない。
Functionだけでは不十分、かつ、非同期イベントの関しまでトラブルシュートと修正には必要になる。
Distributed Tracing
Micro Serviceは、ロジックが個別に構成されている。 ロジックがどのように接続されているのかを把握する必要がある。
Jaegerで可視化できるが、必要なのはどうやってそのデータを得るのか。
Manual Traces/Instrurentaion
このあたりをつかってやったり...。
- OpenTracing
- OpenCensus
やらないといけないことは多い。
- Before and after call
Serverelss apps are very distributed
Complex Systems have thousands of functions What about the developer velopcity?
Exisiing Solutions?
- AWS Cloud WatchLogs : ログは見られるけどそこまで
- AWS X-Rays : Distributedではあるけど、Lambdaまで、AWS Serviceのプロファイリングに過ぎない
- いわゆるDistributed Tracingではない
- 非同期イベントもおえない
縦串に処理を負えない、中途半端なTracing、APMになっている。起因がなにかを判別するのが難しいのがとてもじゃないけど、コレでは足りない。
Quick Look が重要
Serverlessでスピードアップするので、Developer体験もスピードアップが必要。 そのため、Quick Loockとして、トランザクション全体のリソース間の処理時間がぱっと見えるなどのレベルで簡単さが重要になる。
では、マニュアルでCloudWatch LogsをLamndaで5分毎にスキャンしてRDSへ?
* CloudWatch がHighly Throttleに
* Request が時間かかるように
* 5K 同時Lambda for 5min はむりぽよ。
当然コストもべらぼうに高くなる。
まったくで、この常時起動 + Fanout手法でのServerless は地獄一直線なぁ
Obervability
ということで、X-Rayもだめ、マニュアルも厳しいのでEpasgonですよ。
Dynamic Service Map ビジネスフローを乗っけている。
Transaction の流れ、があるのはかなりいいのでは。 グラフDB使わないと関連クムのだるそうだな
ログインはこっちから
まとめ
トランザクションの流れは注目したいと思いつつ「どうやるかアイデアがわかなかった」ので学びでした。けど、正直StackDriverで組めないかなぁっていうのもあり、処理ごとにってなると手間だけど地道にいくしかないかなぁ
