毎年参加しているServerless Conf Tokyoです。3回目になります。
http://tokyo.serverlessconf.io/tokyo.serverlessconf.io
他のセッション
引用は私のコメントです。
目次
- 目次
- Title
- Speaker
- Slide
- 従来のインフラ監視
- Serverless 監視
- マルチクラウドでG2S は提供
- Datadog でどう監視するのか
- 想定外の例外が検出時の対応
- サービスマップ
- Q&A
Title
Game Server Service サーバーレスアプリケーションの監視・運用
Speaker
丹羽一智
Slide
従来のインフラ監視
- Load Average
- CPU Average
- Memory Usage
- Disk IO
を見てきた
Serverless 監視
これらは不要だけど、サービスは正しく動いているのか、コンポーネントが動いているのかを確認していくのが重要になる。 つまり
- サービス監視
- サービスが正しく提供されているか判断する指標
- コンポーネント監視
- コンポーネントが動いているのか
レイヤがインフラ生からサービスの要素に変わっているので、そうなりますね。
コンポーネント監視
キャパシティ管理、上限革の必要な項目
- Lambda の同時実行数
- API GAteway へのRequest/Sec
- DynamoDB のキャパシティ使用率
障害発生時に障害店を特定するための項目
- API Gateway の応答時間
- Lambda の実行時間
- DynamoDBの処理時間
などが重要
マルチクラウドでG2S は提供
AWS/GCPで提供される視覚表示は、折れ線グラフになっており指標とあってないこともおおい。
そのため、Datadog に大型モニタに表示して席から見てる。
監視内容
かなりDatadog の利用方法にそった監視方法になってる
基本メトリック
- 秒間アクセス数
- サービス利用者起因のエラー数 : User Error
- GS2 のエラー数 : Backend Error
- 想定外の例外発生数 : Fatal
- Google App Engine のクォーターリミット
サービスパフォーマンス
所要時間が重要。
- API GAtewya Response
- Lambda Reponse
- Lambda Code Response
- Auth Duration
- DunamoDB IO
Datadogのしきい値、色変化で見てる。
キャパシティ監視
- DynamoDB で最もキャパシティを消費しているテーブルの使用率
- 個別のテーブルはどうでもよくて、一番使っているやつを知る必要がある
- Lambda の同時実行数のアカウント上限値に対する使用率
- 同時実行の多いやつはどれだ！
- Lambda/DynamoDB のスロットル発生回数
アラーム状態
- アラームがすべてOKな状態か
直近4時間のAPIコール数
- 点線は1週間前の同時間帯のグラフ
- 直線は直近4時間におけるトレンド
- 今どの程度のアクセスがあるかを可視化
Datadog のフィルタ機能で、移動平均やトレンドを出してる
一週間前の、とかトレンド、とか自分がやってるのと同じことやってる....
直近4時間のAPIランキング
- 利用されているマイクロサービスランキング
- レスポンスタイムのワーストランキング
ここも全く同じ....
直近一週間のAPI ランキング
期間を変えると見る要素かわりますからねぇ
直近1ヶ月のAPIコール数
- 点線は1ヶ月前の同時間帯のグラフ
- 直線は直近一ヶ月におけるトレンド
- 跳ね上がっているのは、クライアントの実装ミスによってビジーになったこと
インフラのコスト
サービスの提供にかかっているインフラコストの可視化
異常な増え方をしていないかを視覚化
売上
サービスの売上可視化
- 24h
- 一ヶ月
ここまで、 黒騎士と白の魔王を支えるDatadogを使ったモニタリングで書いた内容とほぼ同じ
Datadog でどう監視するのか
プラグインの設定
- AWS アカウントと、AssumeRoleに使用するロールの設定
- どのサービスのメトリックを収集するか設定
- どのサービスにどのタグを設定
コンポーネントの追加
どのようそを関しするよ、とかをScreen Bpard に投げてる
メトリックの設定
どのメトリックのをせてい
- レンダリングするデータソースを設定
- SelectyaGroupBy もできる
- フィルタで移動平均とかもだせる
値の範囲でダッシュボードに表示する色を設定可能
- 異常値になったときには色が変わるようにすることええ、すぐに異常でアルことを認識できるように
想定外の例外が検出時の対応
どのアカウントで何が発生しているの....?
- Lambda の CloudWatch Logs は厳しい
- Lmabda が実行されたコンテナごとに別れている
- そこでDatadog Logs
- すべてのアカウント、プロジェクトのエログを集約
- フィルタリングも爆速
たとえば、マイクロサービスを絞り込んだり、ファンクションで絞り込んだり、ステータスコードで絞り込んだり、レコードを選ぶと詳細が見られる。ここで、リクエストの内容やレスポンスの内容を埋め込んでいる。
ダッシュボードのメトリックからログに飛ぶことが可能。
- API Error -> View related logs > タグで絞り込んだ状態のログを見られる
ログの取り込み方
TCPでつないで投げ続けるだけ
サービスマップ
X-Ray の100倍まし。
ノードを選択するとより細かい利用が見られる。
何がいいかというと、プラットフォーマーが提供しうるサービスとは異なり、クラウドをまたげる。 (が、サービスマップはサーバーレスからは利用できない、エージェントインストールが必要)
Q&A
インシデントがあったときに連動方法は?
異常はダッシュボードで確認。 ここからDynamoDB用など詳細のダッシュボードでわかるようになっている。 あとは、じょじょに上がっているのであればキャパシティ問題。 スパイクなら、異常が発生しているのかの確認。 スパイクを起こしているテーブルから、そのテーブルを使っている関数をたどる。
ダッシュボードドリブン + Slack での通知でハンドルしている。 異常 -> 正常化は、マニュアルでやっている(運用自動化はしていない)
キャパシティなどは、日常的に上がっているとき -> 日常的に改善が必要と認識。
Slack 通知 = 異常 = 人間が対処するしかないという認識。
インシデント管理
スクリーンボード 以外に、タイムボードでメモを残している。 あとは、 Confluence にメモ残している。(フルマネージドなので、クラウド障害じゃないと障害にナリにくいのでノウハウが溜まりにくい)
ちょっとインシデント管理厳しいですよねぇ。Datadogのメモはこういうの弱いので、Timeline に流して、自動的にesaにpostあたりがいいかなぁ。 GitHub Issueもインシデント管理にそこまで強くいないしなぁ。(悪い選択じゃないので、こっちでもいい)
