毎年参加しているServerless Conf Tokyoです。3回目になります。
http://tokyo.serverlessconf.io/tokyo.serverlessconf.io
他のセッション
引用は私のコメントです。
目次
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でID関連で組めないかなぁっていうのもあり.... 処理ごとにってなると手間だけど地道にいくしかないかなぁ
