これまでの監視とクラウド時代の監視 / Monitoring the Past and the Cloud

Slide 1

Slide 1 text

これまでの監視とクラウド時代の監視株式会社 mediba Tomoya Kitaura 2022/5/18 とある企業様の社内勉強会乱入編

Slide 2

Slide 2 text

自己紹介 Tomoya Kitaura @kitta0108 mediba inc. SRE Unit ■勉強会運営 - - JAWS-UG コンテナ支部 - JAWS-UG SRE支部 - NRUG SRE支部 2 2

Slide 3

Slide 3 text

今回お話すること - システム監視の課題 - オブザーバビリティとは - オブザーバビリティ導入戦略 - 実現したい世界観の話 3

Slide 4

Slide 4 text

システム監視の課題 4 システム監視の課題

Slide 5

Slide 5 text

システム監視の課題 5 その1 ハードウェアの状態あんまり興味ない説

Slide 6

Slide 6 text

システム監視の課題 6 従来のシステムアーキテクチャ Web3階層モデル(オンプレ運用) Web Server App Server DB Server 物理サーバーの死 = サービスの死 = ユーザー影響

Slide 7

Slide 7 text

システム監視の課題 7 Web Server App Server DB Server CPU使用率 90%だおやべぇ筐体交換しないといけないかもこのアーキテクチャ上のシステム監視の関心軸ハードウェアが正常に動作するかどうか

Slide 8

Slide 8 text

システム監視の課題 8 現在のシステムアーキテクチャクラウドネイティブ(※色々省略してます) CloudFront ALB Fargate Aurora

Slide 9

Slide 9 text

システム監視の課題 9 CloudFront ALB Fargate Aurora １台CPU使用率90%やでーつまり、CPUが90%であるということは CPUが90%であるということです。

Slide 10

Slide 10 text

システム監視の課題 10 CloudFront ALB Fargate Aurora - ハードウェアの管理責任をクラウドベンダーに移譲 - AWS責任共有モデル - 例）FargateのSLA 月間稼働率99.99% - 仮想化技術の発展により、オートヒーリングが可能になった。 - ハードウェア障害の影響はシステム設計に落とし込まれる形となった。

Slide 11

Slide 11 text

システム監視の課題 11 その2 トラブルシュートつらすぎる問題

Slide 12

Slide 12 text

システム監視の課題 12 CloudFront ALB Fargate Aurora ハードウェアの障害に関する関心は薄くはなったものの、ユーザー影響に関しては、むしろより詳細を求めるようになった。

Slide 13

Slide 13 text

システム監視の課題 13 CloudFront ALB Fargate Aurora 5xxエラーをユーザーに返し続けているでーどこが問題なんだ？

Slide 14

Slide 14 text

システム監視の課題 14 問題ありませんでした! 問題ありませんでした! 問題ありませんでした! 閃光のフロントエンジニア鈴木不死身のインフラエンジニア田中業火のバックエンドエンジニア山田

Slide 15

Slide 15 text

システム監視の課題 15 閃光のフロントエンジニア鈴木不死身のインフラエンジニア田中業火のバックエンドエンジニア山田 Sentryで確認 Datadogでメトリクスを確認 Datadogでアプリケーションログを確認

Slide 16

Slide 16 text

システム監視の課題 16 例えば以下のような解決方法を選択肢とした場合どちらが最適？ - Infraのスペックアップリクエスト量 ≒ 処理量と比較して性能が低いときに検討される方法 ※または一時的な暫定回避策 - バックエンドのアルゴリズム改修今後のスケールリング性能に影響を及ぼすと考えられる時に検討される方法フラットな目線で最適を検討する難しさ

Slide 17

Slide 17 text

Observabilityとは 17 Observabilityとは

Slide 18

Slide 18 text

Observabilityとは 18 - 直訳すると可観測性 - システムを観測する能力そのもののこと - 省略系でo11yと表現されることが多い - 直近ではo11y Conferenceが開催されるなど業界注目度も高い

Slide 19

Slide 19 text

Observabilityとは 19 o11y 導入後のイメージ Client Backend Infra Client ユーザーリクエスト・どんなリクエストを渡されたか・どんなレスポンスを返したか・関数の処理にどれくらい時間かかったか・エラーが起きた具体的な関数の場所はどこか・どんなユーザーだったか・どのようなレスポンスを返したか・Backendにどのような要素を渡したか・Backendからはどんなレスポンスが返ってきたか・エラーが起きたその時インフラの状態はどうだったか

Slide 20

Slide 20 text

Observabilityとは 20 閃光のフロントエンジニア鈴木不死身のインフラエンジニア田中業火のバックエンドエンジニア山田インフラでエラーが起きてるなインフラでエラーが起きてるなインフラでエラーが起きてるな o11y 導入後の理想イメージ

Slide 21

Slide 21 text

オブザーバビリティ導入戦略 21 オブザーバビリティ導入戦略

Slide 22

Slide 22 text

オブザーバビリティ導入戦略 22 ■ちょっとずつ導入する作戦 - 新しいことを始める時のベストプラクティス ■ちょうどいい感じの労力投資とそれに見合った効果が得られるところを狙っていく - 多くの製品において、デキることがいっぱいある。 ■構築設計フェーズで頑張りすぎない。 - 最適なo11yは運用のフェーズでわかっていくものも多い - 運用フェーズで必要に応じて拡充していく気持ちを持つ

Slide 23

Slide 23 text

オブザーバビリティ導入戦略 23 投資効果 ■狙っていきたい状況を雑に表現したやつ投資効果 ■避けたい状況を雑に表現したやつ

Slide 24

Slide 24 text

実現したい世界観の話 24 実現したい世界観の話

Slide 25

Slide 25 text

実現したい世界観の話 25 すこし話す内容のカラーを変えます。

Slide 26

Slide 26 text

実現したい世界観の話 26 プロダクト開発のサイクル Biz （企画） Dev （開発） Ops （運用）プロダクトがうまく機能しなくなって、大きな改革を求められるときの原因ってだいたいこのサイクルの機能不全じゃないですかね？

Slide 27

Slide 27 text

実現したい世界観の話 27 Bizの機能不全例 DevOpsが守りに入りすぎて新しい機能開発を差し込めなくなる等 Devの機能不全例必要なリファクタ作業を怠った結果、機能追加が困難になる等 Opsの機能不全例運用が複雑になり、安全なデプロイが実施できない等

Slide 28

Slide 28 text

実現したい世界観の話 28 Biz Dev Ops 限りある工数どのような比率で分配するのか、難しすぎる問題

Slide 29

Slide 29 text

実現したい世界観の話 29 一つの案 BizDevOps全員がシステムの健全性という一つの指標をベースに意思決定すればよいのでは？システムが健全であるならば、ガンガン新規開発やっていこう。システムが不健全であるならば、リファクタ作業・運用の改善に投資しよう。

Slide 30

Slide 30 text

実現したい世界観の話 30 そのために事実ベースのデータが必要 -> o11yプラットフォームに情報を集めていく＜参考＞・ネガティブな解釈をされがちなエラーバジェットの誤解を解いてみる https://bit.ly/3k44QMe ・エンタープライズにおけるSRE立ち上げとNew Relic選定に至った背景とは https://speakerdeck.com/tomoyakitaura/sre-startup-and-new-re lic-in-the-enterprise

Slide 31

Slide 31 text

まとめ 31 ■解決したい課題 - ユーザー影響にフォーカスした監視を行うのが難しい - トラブルシュートとその解決方法の最適化が難しい ■o11yの実装により上記の課題を解決できる確度が高い (と僕は思ってる) ■o11yの導入は構築設計フェーズで頑張りすぎない ■o11yはシステム監視の課題のみならず、プロダクトの健全性を担保するという意味でも効果を発揮する可能性を秘めている

Slide 32

Slide 32 text

さいごに 32 より高みを目指した開発をみんなで楽しんでいきましょう！！ご静聴ありがとうございました！！