情熱と工夫で走り抜け！コミュニティをささえるObservability実践録

Slide 1

Slide 1 text

情熱と工夫で走り抜け！コミュニティをささえるObservability実践録 CloudNative Days / Observabilityチームさっちゃん株式会社はてな @ne_sachirou 岡本泰典株式会社IDCフロンティア @taisuke_bigbaby

Slide 2

Slide 2 text

AGENDA ● 自己紹介 ● Observabilityチームの誕生までの歴史 ● Observabilityチームの挑戦 ● Observabilityチームの現在の取り組み ● Observabilityチームのこれから 2

Slide 3

Slide 3 text

自己紹介岡本泰典（株式会社IDCフロンティア）　CloudNative Days Co-chair / Observability Team Leader 　Grafana Meetup Japan オーガナイザー X：@taisuke_bigbaby 自社クラウド上のKubernetes as a Serviceのエンジニアとして、 Network、Storage領域をメインとしたコンポーネント開発に従事。また、SREとして複数のプロダクトを横断的に支援している。 CloudNative Days Tokyo のCo-chairを努めながら、Observabilityチームのリーダーも牽引しておりカンファレンスメトリクスの可視化などに努める。最近は、コミュニティ活動やOSSへのコントリビュート活動を徐々に開始中。 3

Slide 4

Slide 4 text

自己紹介井上幸亨郎（株式会社はてな）　Mackerel開発チームテックリード　CloudNative Days Observability Teamメンバー X：@ne_sachirou はてなID: ne-sachirou .｡oO(さっちゃんですよヾ(〃l _ l)ﾉﾞ☆) Mackerelでオブザーバビリティープラットフォームを作っています。 MackerelがCloudNative Daysにツールスポンサーしたのを縁に、 CNDS2024からObservabilityチームに参加しました。 4

Slide 5

Slide 5 text

CNDS2025 実行委員チーム紹介 Dreamkast Broadcast Observability Promotion Secretariat Contents Creators Hands-On 5

Slide 6

Slide 6 text

Observabilityチーム誕生までの歴史 6

Slide 7

Slide 7 text

ここで皆さんに質問です！ Observabilityっていつからみんな知り始めましたか？？ 7

Slide 8

Slide 8 text

ソフトウェアにおけるObservabilityとは 1960年制御理論で使用「システムの出力からその状態をどれだけ正確に把握できるかを測定するもの」 ● 3つの柱 ○ 『メトリクス』・『ログ』・『トレース』 ● 監視(Monitoring)との違い ○ 監視 ■ 事前に定義された指標、閾値ベースのアラート、専門知識に依存 ○ 可観測性 ■ 事前に定義しなくても探索が可能、未知の問題発見に強い 8

Slide 9

Slide 9 text

Meetupでも取り上げられ始める 2018 NoOps Meetup Tokyo #2 ● (おそらく) connpass上で初めての「Observability」 9 https://noops.connpass.com/event/103846/

Slide 10

Slide 10 text

コミュニティなども誕生 2019 Observability Meetup #1 @New Relic 2020 Observability Japan Online ● クラウドネイティブの技術の進化と共にObservabilityの重要視され始める 10 https://connpass.com/event/145976/ https://observability.connpass.com/event/168837/

Slide 11

Slide 11 text

時は進むこと2022年... ● CNDにて「Observability Conference 2022」を開催 ○ 『Observe the Observability 〜知らないことを知り、見えていないものを見る〜』 ● 開催と共にObservabilityチームを発足 ○ 「色んなものを可視化していくぞ🔥🔥」 https://x.com/antiberial/status/1502114852084408320 11

Slide 12

Slide 12 text

Observabilityチームの『Passion』「実行委員内外問わず、ありとあらゆるものを計測可能にしたい」 → クラウドネイティブにおける第一歩 ● 内部 ○ 進捗フォローなどのための実行委員の状況可視化 ○ データに基づくカンファレンス設計 ○ アクセス数, セッション数, CFP etc… ● 外部 ○ カンファレンスに関するメトリクスの常時公開 ○ 参加者とともにカンファレンスを創り上げていく ○ カンファレンスを通じて、新しい気づきを得てほしい 12

Slide 13

Slide 13 text

Observabilityチームの挑戦 13

Slide 14

Slide 14 text

時代と共に変化するイベント配信基盤 ● 配信基盤である「Dreamkast」も時代と共に形を変化させてきました ● それと同時にObservabilityチームを様々な挑戦をしてきました 14 EKS ~ 2023 Heroku ~ 2020 ECS 2024 -

Slide 15

Slide 15 text

時代と共に変化するイベント配信基盤 ● Observabilityチームが発足した当初はEKSを運用していました ● では、どのような可視化をしていたのでしょうか？ 15 EKS ~ 2023 Heroku ~ 2020 ECS 2024 -

Slide 16

Slide 16 text

開発メトリクスリアルタイムメトリクス日時メトリクス EKS時代の挑戦 - ver1.0 16 Dreamkast DB Replica DB SNS メトリクス現地メトリクス Dreamkast Exporter Telegraf Spring Boot Push Gateway Telegraf

Slide 17

Slide 17 text

Observability Conference 2022の様子 Xを通じていいね数、リツイート数、感情分析結果を可視化してみたり 17

Slide 18

Slide 18 text

CloudNative Days Tokyo 2022の様子 Xでのつぶやきを収集し、WordCloudとして可視化もしてみたり 18 https://x.com/minorun365/status/1594606835340050436

Slide 19

Slide 19 text

CloudNative Days Tokyo 2022の様子 AIカメラを使った画像認識で現地の状況を可視化したりしていました 19 https://x.com/cloudnativedays/status/1594497533384224769

Slide 20

Slide 20 text

変化と共に現れる壁 ● カンファレンスメトリクスはある程度、可視化できた ● しかし、肝心の配信基盤自体の可視化は不十分だ ○ 大事なことはシステムを最適化していくこと ○ チームとしてカンファレンス全体に貢献できていない 20 意思決定に必要なデータを適切なタイミングで収集・可視化し、実際のアクションにつなげる仕組みづくり

Slide 21

Slide 21 text

アプリケーションログ EKS時代の挑戦 - ver2.0 21 リアルタイム/日時メトリクス Dreamkast Exporter ランタイムセキュリティエラートラッキングパフォーマンス Exporterを拡張することで、管理を簡素化クラウド版を利用

Slide 22

Slide 22 text

闇雲なチャレンジが招くもの ● 「あらゆるものを可視化するんだ！！」とは言ったものの... ○ 「誰が管理するの？」 ○ 「このメトリクスをどう活用するの？」 ● 時代と共に変化するものはシステムだけではない ○ カンファレンスを取り巻く環境 ○ メンバーが割けるリソース ○ 配信基盤自体のリソース etc… 22 「データに基づく改善」と「運営の負担」のバランスを取りながら、チーム自身も持続可能な形で運営していく必要がある

Slide 23

Slide 23 text

アプリケーションログ EKS時代の挑戦 - ver2.1 23 リアルタイム/日時メトリクス Dreamkast Exporter エラートラッキングパフォーマンス Self-Hosted Sentryをコンテナで運用開始

Slide 24

Slide 24 text

Self-Hosted Sentryでの運用、基盤の移行 24 Export Docker Composeを一部分離し、個々をExporterを用いて監視これまでObservability基盤もリソースの節約のために移行

Slide 25

Slide 25 text

Self-Hosted Sentryでの運用での戦い ● Docker Composeの分離の目的 ○ パフォーマンスの最適化 ○ スケーラビリティの向上 ○ データの永続性と管理 ● 挑戦と同時に課題も多く発生 ■ CNDF2023 当日、突然のPrometheus爆死事件 ● 十分な負荷試験を実施できていなかった ■ CNDW2024 未曾有のエラー、前日の再構築 ● 当日は安定稼働をしたものの原因はわからず... 25

Slide 26

Slide 26 text

Self-Hosted Sentryでの運用、基盤の移行 (最終) 26 Export Docker Composeの分離を撤廃 Observability基盤も1つの Docker Composeに内包 ● リソース制約への対応 ● リソース配分の最適化

Slide 27

Slide 27 text

アプリケーションログ ECS時代の挑戦 (ver1.0) 27 リアルタイム/日時メトリクス Dreamkast Exporter エラートラッキングパフォーマンス Export

Slide 28

Slide 28 text

変化と共に学んだ教訓 💪 マンパワーが足りない ● コミュニティの作業はフルタイムではない ● 限られた時間の中で、価値を提供しなければならない 🔄 人が入れ替わり知見が伝承されない ● 最小限のドキュメンテーションは用意した ● でも、変化が激しい中だとすぐ陳腐化してしまう 💰 確かにお金などのリソース節約はできた ● 運用コストが多く、バランスがとれていない 28 「費用対効果」より「運用負担対効果」の視点が重要

Slide 29

Slide 29 text

Observabilityチームの現在の取り組み 29

Slide 30

Slide 30 text

アプリケーションログ CNDS2024の頃の構成 30 リアルタイム/日時メトリクス Dreamkast Exporter エラートラッキングパフォーマンス Export

Slide 31

Slide 31 text

Observability基盤の課題 💪 マンパワーが足りない ● コミュニティの作業はフルタイムではない ● 限られた時間の中で、価値を提供しなければならない 🔄 人が入れ替わり知見が伝承されない ● 最小限のドキュメンテーションは用意した ● でも、変化が激しい中だとすぐ陳腐化してしまう 💰 確かにお金などのリソース節約はできた ● 運用コストが多く、バランスがとれていない 31 「費用対効果」より「運用負担対効果」の視点が重要

Slide 32

Slide 32 text

Observability基盤の課題 💪 マンパワーが足りない→運用工数の少ない構成へ移行する ● コミュニティの作業はフルタイムではない ● 限られた時間の中で、価値を提供しなければならない 🔄 人が入れ替わり知見が伝承されない→よくある標準的な構成へ移行する ● 最小限のドキュメンテーションは用意した ● でも、変化が激しい中だとすぐ陳腐化してしまう 💰 確かにお金などのリソース節約はできた→金よりも未来にマンパワーを当てる ● 運用コストが多く、バランスがとれていない 32

Slide 33

Slide 33 text

Slide 34

Slide 34 text

アプリケーションログマンパワーが足りない 34 リアルタイム/日時メトリクス Dreamkast Exporter エラートラッキングパフォーマンス Export 大量のspanが送られるために、高いパフォーマンスと高い可用性が求められ、運用負荷が大きい管理するものが多い

Slide 35

Slide 35 text

運用工数の少ない構成へ移行する Grafana+Prometheus ● アプリケーションのメトリックを見る役割は別の構成に置き換えられる ● 公開しているダッシュボード(CloudNativeDays Deep Dive等)は置き換え先が　　　見つからないのでそのまま Grafana+Loki ● 置き換え先が見つからないのでもう暫くがんばる(๑´◕﹏◕`) Self-Hosted Sentry ● 大量のspanが送られるために、高いパフォーマンスを高い可用性が求められ、　　　運用負荷が大きい ● 積極的に別の構成に置き換える 35

Slide 36

Slide 36 text

メトリクスをMackerelに移行する Grafana+Prometheus ● 運用工数を減らすには、SaaSに置き換えるのが一つの策 ● ちょうどMackerelがツールスポンサーし、Mackerelを自由に使えるようになった ○ Mackerel開発者がObservabilityチームに参加しているので、　　　　トラブルを解決しやすいという事情もある → Mackerelに移行しよう!! 36

Slide 37

Slide 37 text

Mackerelの仕組み 37 mackerel-agent mackerel-container-agent OpenTelemetry

Slide 38

Slide 38 text

アプリケーションログメトリクスをMackerelに移行する 38 リアルタイム/日時メトリクス Dreamkast Exporter エラートラッキングパフォーマンス ※以後、カンファレンスメトリクスについては省略する

Slide 39

Slide 39 text

メトリクスをMackerelに移行する Observabilityチームが管理しているサーバーを観測する ● さくらのクラウドで動いているVMと、VM上で動いているミドルウェアを観測する dreamkastを観測する ● Amazon ECSで動いているアプリケーションを観測する 39

Slide 40

Slide 40 text

メトリクスをMackerelに移行する『Observabilityチームが管理しているサーバーを観測する』 ● サーバーの死活を監視する ○ さくらのクラウドのシンプル監視は、他へ移行する理由がないのでそのまま使う ○ Mackerelの外形監視を設定する ● VMのリソースを観測する ○ mackerel-agentを入れる ● Sentryのミドルウェアの動作を観測する ○ PostgreSQL : mackerel-plugin-postgresを設定 ○ Redis : mackerel-plugin-redisを設定 ○ Kafka : mackerel-plugin-prometheus-exporterをラップしたプラグインを自作 ● 監視ルール・カスタムダッシュボードを作る ○ PostgreSQLやRedisを運用してきた経験から、観測するとよいメトリクスを　　　ピックアップ 40

Slide 41

Slide 41 text

メトリクスをMackerelに移行する『dreamkastを観測する』 ● サービスの稼働を観測する ○ 外形監視を設定する ○ AWSインテグレーションでALBとSQSのメトリクスを観測する ■ レスポンスタイム・エラーレートに監視ルールを設定する ● アプリケーションのリソースを観測する ○ mackerel-container-agentを設定する ○ AWSインテグレーションでRDSとElastiCacheのメトリクスを観測する ○ 障害対応やふりかえりの参考情報と考え、監視ルールはあまり設定しない ● カスタムダッシュボードを作る ○ カスタムダッシュボードおまかせ生成機能におまかせする 41

Slide 42

Slide 42 text

メトリクスをMackerelに移行する 42

Slide 43

Slide 43 text

トレースをSelf-Hosted Sentryから移行する ● 最も運用の負担になっているSelf-Hosted Sentryから移行したい ○ クラウド版Sentryへ一時的に戻した ○ Mackerelへ移行中(後述) ■ ツールスポンサーの下で自由に使える ■ OpenTelemetryへ移行したい 43

Slide 44

Slide 44 text

アプリケーションログトレースをMackerelに移行する 44 リアルタイム/日時メトリクス Dreamkast Exporter エラートラッキングパフォーマンス

Slide 45

Slide 45 text

Slide 46

Slide 46 text

人が入れ替わり知見が伝承されない初めは各々の頭の中にしか知見がなかった Notionにナレッジを溜め始めた ● しかしナレッジを整備し続けるマンパワーも足りない伝承すべき知見を減らしたい 46

Slide 47

Slide 47 text

よくある標準的な構成へ移行する Observability基盤をOpenTelemetryへ移行する ● 標準的な構成は、ナレッジが世間(Web・書籍・同僚の経験・LLM)にある ○ 一方でself-hosted Sentryのナレッジはほとんど無い ● Observabilityチームとしては新しい学ぶ価値のある技術である ○ 本業でも使える 47

Slide 48

Slide 48 text

OpenTelemetryメトリクスを計装する Observabilityチームが管理しているサーバーを計装する ● ocb (OpenTelemetry collector builder)でotelcol (OpenTelemetry collector)を　ビルドして、デーモンを設定する ● Mackerelのカスタムダッシュボードを作る dreamkastを計装する ● ocb (OpenTelemetry collector builder)でotelcol (OpenTelemetry collector)を　ビルドして、サイドカーを設定する ● Mackerelのカスタムダッシュボードを作る細かいやり方はここには書かない。なぜならばWebに書いてあるから! 48

Slide 49

Slide 49 text

OpenTelemetryメトリクスを計装する 49

Slide 50

Slide 50 text

アプリケーションログ OpenTelemetryメトリクスを計装する 50 リアルタイム/日時メトリクスエラートラッキングパフォーマンス

Slide 51

Slide 51 text

OpenTelemetryトレースを計装する Sentryのトレースの役割 → OpenTelemetryのトレースに置き換えられる Sentryのエラー管理の役割 → spanの属性にエラーの情報を載せればMackerelで見ることができる ● Exception | OpenTelemetry https://opentelemetry.io/docs/specs/semconv/attributes-registry/exception/ ● トレース - 問題を素早く解決する - Mackerel ヘルプ https://mackerel.io/ja/docs/entry/tracing/features/solve-issues 移行作業中　ｴｯﾎ(っ〃l _ l)っｴｯﾎ 51

Slide 52

Slide 52 text

アプリケーションログ OpenTelemetryメトリクスを計装する 52 リアルタイム/日時メトリクスエラートラッキングパフォーマンス

Slide 53

Slide 53 text

現在の取り組みのまとめ 💪 マンパワーが足りない→運用工数の少ない構成へ移行する ● SaaSへ移行する ○ Mackerelへ移行する ■ メトリックは移行した ■ トレースはこれから移行する ● 一時的にクラウド版Sentryに移行している 🔄 人が入れ替わり知見が伝承されない→よくある標準的な構成へ移行する ● OpenTelemetryへ移行する ○ メトリックは移行した ○ トレースはこれから移行する 53

Slide 54

Slide 54 text

Observabilityチームのこれから 54

Slide 55

Slide 55 text

Slide 56

Slide 56 text

確かにお金などのリソース節約はできた遮二無二に構築した初期。それを維持するのにお金もマンパワーもかかり続ける　　　↓ インフラを移行してお金を節約し、課題がマンパワーに移ってきた　　　↓ SaaSに移行してマンパワーの課題も改善し始めた時は来た。未来の課題について話そう 56

Slide 57

Slide 57 text

金よりも未来にマンパワーを当てる Mackerel/OpenTelemetryへの移行を完遂する ● Observabilityチームがこれらに慣れて、自信を持つ 57

Slide 58

Slide 58 text

金よりも未来にマンパワーを当てる観測+緊急対応はまぁまぁできてる観測を、緊急ではないが重要な意志決定に繋げたい ● 何を意志決定するべきか炙り出したい ○ フレームワークを適用する ■ SREingのフレームワークを適用する 58

Slide 59

Slide 59 text

SREingのフレームワークを適用するユーザーの体験を分析し、何を守るべきか探る ● ユーザーの体験に信頼性を与えるのがSREing ○ 惰性でSLO/SLIを定めない ○ まずCUJ (critical user journey)を分析する 59

Slide 60

Slide 60 text

SREingのフレームワークを適用するユーザーの体験を分析し、何を守るべきか探る ● 仮説 : Dreamkastの状態は会期中と会期外とで全く異なる ○ 会期中の数日は多くのユーザーが登壇を視聴する ■ 高い可用性・性能が必要 ○ 会期外のアクセスは多くない ■ リソースの節約が重要 ● それぞれの状態にSLI/SLOを設定するべきだろう ○ 会期中に設定したSLOを達成できるように、事前に準備し事後にふりかえる ■ 当日はSLOなんて気にしてる暇は無い ○ 会期外は普通にerror budgetを管理する 60

Slide 61

Slide 61 text

SREingのフレームワークを適用する開発・運用チームと連携する ● SLOはdevopsに使われなければならない ○ 約束・協力が最も重要 ■ (技術よりも重要) 61

Slide 62

Slide 62 text

Observabilityチームのこれから ● お金・マンパワーの課題は解決し始めた ● まずはMackerel/OpenTelemetryへの移行を完遂する ● 観測・緊急対応の先へゆきたい ○ SREingのフレームワークを適用しようと考えている 62 未来への情熱 AIの考えた「金よりも未来にマンパワーを当てる」