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

Observabilityチームは2022年に発足し、現在まで活動してきました。
限られたコストの中、どうやって運用を最適化していくか？
本セッションでは、EKS→さくら→Mackerelと移り変わる監視・運用の変遷を軸に、情熱とともに走り抜けてきた現場のリアルをお届けします。
Sentryの自前運用で直面した苦悩や、実際のイベント運用時のトラブル体験談も紹介。
インフラに求める『本質的なオブザーバビリティ』とは？
今後見据えるSLO運用やOpenTelemetryトレーシングの導入も含め、実践者の視点で情熱的に語ります。

Transcript

1. 情熱と工夫で走り抜け！ コミュニティをささえるObservability実践録 CloudNative Days / Observabilityチーム さっちゃん 株式会社はてな @ne_sachirou 岡本 泰典 株式会社IDCフロンティア @taisuke_bigbaby
2. AGENDA • 自己紹介 • Observabilityチームの誕生までの歴史 • Observabilityチームの挑戦 • Observabilityチームの現在の取り組み • Observabilityチームのこれから 2
3. 自己紹介 岡本泰典（株式会社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
4. 自己紹介 井上幸亨郎（株式会社はてな） 　Mackerel開発チームテックリード 　CloudNative Days Observability Teamメンバー X：@ne_sachirou はてなID: ne-sachirou .｡oO(さっちゃんですよヾ(〃l _ l)ﾉﾞ☆) Mackerelでオブザーバビリティープラットフォームを作っています。 MackerelがCloudNative Daysにツールスポンサーしたのを縁に、 CNDS2024からObservabilityチームに参加しました。 4
5. CNDS2025 実行委員チーム紹介 Dreamkast Broadcast Observability Promotion Secretariat Contents Creators Hands-On 5
6. Observabilityチーム誕生までの歴史 6
7. ここで皆さんに質問です！ Observabilityっていつからみんな知り始めましたか？？ 7
8. ソフトウェアにおけるObservabilityとは 1960年 制御理論で使用 「システムの出力からその状態をどれだけ正確に把握できるかを測定するもの」 • 3つの柱 ◦ 『メトリクス』・『ログ』・『トレース』 • 監視(Monitoring)との違い ◦ 監視 ▪ 事前に定義された指標、閾値ベースのアラート、専門知識に依存 ◦ 可観測性 ▪ 事前に定義しなくても探索が可能、未知の問題発見に強い 8
9. Meetupでも取り上げられ始める 2018 NoOps Meetup Tokyo #2 • (おそらく) connpass上で初めての「Observability」 9 https://noops.connpass.com/event/103846/
10. コミュニティなども誕生 2019 Observability Meetup #1 @New Relic 2020 Observability Japan Online • クラウドネイティブの技術の進化と共にObservabilityの重要視され始める 10 https://connpass.com/event/145976/ https://observability.connpass.com/event/168837/
11. 時は進むこと2022年... • CNDにて「Observability Conference 2022」を開催 ◦ 『Observe the Observability 〜知らないことを知り、見えていないものを見る〜』 • 開催と共にObservabilityチームを発足 ◦ 「色んなものを可視化していくぞ🔥🔥」 https://x.com/antiberial/status/1502114852084408320 11
12. Observabilityチームの『Passion』 「実行委員内外問わず、ありとあらゆるものを計測可能にしたい」 → クラウドネイティブにおける第一歩 • 内部 ◦ 進捗フォローなどのための実行委員の状況可視化 ◦ データに基づくカンファレンス設計 ◦ アクセス数, セッション数, CFP etc… • 外部 ◦ カンファレンスに関するメトリクスの常時公開 ◦ 参加者とともにカンファレンスを創り上げていく ◦ カンファレンスを通じて、新しい気づきを得てほしい 12
13. Observabilityチームの挑戦 13
14. 時代と共に変化するイベント配信基盤 • 配信基盤である「Dreamkast」も時代と共に形を変化させてきました • それと同時にObservabilityチームを様々な挑戦をしてきました 14 EKS ~ 2023 Heroku ~ 2020 ECS 2024 -
15. 時代と共に変化するイベント配信基盤 • Observabilityチームが発足した当初はEKSを運用していました • では、どのような可視化をしていたのでしょうか？ 15 EKS ~ 2023 Heroku ~ 2020 ECS 2024 -
16. 開発 メトリクス リアルタイム メトリクス 日時 メトリクス EKS時代の挑戦 - ver1.0 16 Dreamkast DB Replica DB SNS メトリクス 現地 メトリクス Dreamkast Exporter Telegraf Spring Boot Push Gateway Telegraf
17. Observability Conference 2022の様子 Xを通じていいね数、リツイート数、感情分析結果を可視化してみたり 17
18. CloudNative Days Tokyo 2022の様子 Xでのつぶやきを収集し、WordCloudとして可視化もしてみたり 18 https://x.com/minorun365/status/1594606835340050436
19. CloudNative Days Tokyo 2022の様子 AIカメラを使った画像認識で現地の状況を可視化したりしていました 19 https://x.com/cloudnativedays/status/1594497533384224769
20. 変化と共に現れる壁 • カンファレンスメトリクスはある程度、可視化できた • しかし、肝心の配信基盤自体の可視化は不十分だ ◦ 大事なことはシステムを最適化していくこと ◦ チームとしてカンファレンス全体に貢献できていない 20 意思決定に必要なデータを適切なタイミングで収集・可視化し、 実際のアクションにつなげる仕組みづくり
21. アプリケーション ログ EKS時代の挑戦 - ver2.0 21 リアルタイム/日時 メトリクス Dreamkast Exporter ランタイム セキュリティ エラートラッキング パフォーマンス Exporterを拡張する ことで、管理を簡素化 クラウド版を 利用
22. 闇雲なチャレンジが招くもの • 「あらゆるものを可視化するんだ！！」とは言ったものの... ◦ 「誰が管理するの？」 ◦ 「このメトリクスをどう活用するの？」 • 時代と共に変化するものはシステムだけではない ◦ カンファレンスを取り巻く環境 ◦ メンバーが割けるリソース ◦ 配信基盤自体のリソース etc… 22 「データに基づく改善」と「運営の負担」のバランスを取りながら、 チーム自身も持続可能な形で運営していく必要がある
23. アプリケーション ログ EKS時代の挑戦 - ver2.1 23 リアルタイム/日時 メトリクス Dreamkast Exporter エラートラッキング パフォーマンス Self-Hosted Sentryを コンテナで運用開始
24. Self-Hosted Sentryでの運用、基盤の移行 24 Export Docker Composeを一部分離し、 個々をExporterを用いて監視 これまでObservability基盤も リソースの節約のために移行
25. Self-Hosted Sentryでの運用での戦い • Docker Composeの分離の目的 ◦ パフォーマンスの最適化 ◦ スケーラビリティの向上 ◦ データの永続性と管理 • 挑戦と同時に課題も多く発生 ▪ CNDF2023 当日、突然のPrometheus爆死事件 • 十分な負荷試験を実施できていなかった ▪ CNDW2024 未曾有のエラー、前日の再構築 • 当日は安定稼働をしたものの原因はわからず... 25
26. Self-Hosted Sentryでの運用、基盤の移行 (最終) 26 Export Docker Composeの分離を撤廃 Observability基盤も1つの Docker Composeに内包 • リソース制約への対応 • リソース配分の最適化
27. アプリケーション ログ ECS時代の挑戦 (ver1.0) 27 リアルタイム/日時 メトリクス Dreamkast Exporter エラートラッキング パフォーマンス Export
28. 変化と共に学んだ教訓 💪 マンパワーが足りない • コミュニティの作業はフルタイムではない • 限られた時間の中で、価値を提供しなければならない 🔄 人が入れ替わり知見が伝承されない • 最小限のドキュメンテーションは用意した • でも、変化が激しい中だとすぐ陳腐化してしまう 💰 確かにお金などのリソース節約はできた • 運用コストが多く、バランスがとれていない 28 「費用対効果」より「運用負担対効果」の視点が重要
29. Observabilityチームの現在の取り組み 29
30. アプリケーション ログ CNDS2024の頃の構成 30 リアルタイム/日時 メトリクス Dreamkast Exporter エラートラッキング パフォーマンス Export
31. Observability基盤の課題 💪 マンパワーが足りない • コミュニティの作業はフルタイムではない • 限られた時間の中で、価値を提供しなければならない 🔄 人が入れ替わり知見が伝承されない • 最小限のドキュメンテーションは用意した • でも、変化が激しい中だとすぐ陳腐化してしまう 💰 確かにお金などのリソース節約はできた • 運用コストが多く、バランスがとれていない 31 「費用対効果」より「運用負担対効果」の視点が重要
32. Observability基盤の課題 💪 マンパワーが足りない→運用工数の少ない構成へ移行する • コミュニティの作業はフルタイムではない • 限られた時間の中で、価値を提供しなければならない 🔄 人が入れ替わり知見が伝承されない→よくある標準的な構成へ移行する • 最小限のドキュメンテーションは用意した • でも、変化が激しい中だとすぐ陳腐化してしまう 💰 確かにお金などのリソース節約はできた→金よりも未来にマンパワーを当て る • 運用コストが多く、バランスがとれていない 32
33. Observability基盤の課題 💪 マンパワーが足りない→運用工数の少ない構成へ移行する • コミュニティの作業はフルタイムではない • 限られた時間の中で、価値を提供しなければならない 🔄 人が入れ替わり知見が伝承されない→よくある標準的な構成へ移行する • 最小限のドキュメンテーションは用意した • でも、変化が激しい中だとすぐ陳腐化してしまう 💰 確かにお金などのリソース節約はできた→金よりも未来にマンパワーを当て る • 運用コストが多く、バランスがとれていない 33
34. アプリケーション ログ マンパワーが足りない 34 リアルタイム/日時 メトリクス Dreamkast Exporter エラートラッキング パフォーマンス Export 大量のspanが送られるために、 高いパフォーマンスと高い可用性が 求められ、運用負荷が大きい 管理するものが 多い
35. 運用工数の少ない構成へ移行する Grafana+Prometheus • アプリケーションのメトリックを見る役割は別の構成に置き換えられる • 公開しているダッシュボード(CloudNativeDays Deep Dive等)は置き換え先が　　　 見つからないのでそのまま Grafana+Loki • 置き換え先が見つからないのでもう暫くがんばる(๑´◕﹏◕`) Self-Hosted Sentry • 大量のspanが送られるために、高いパフォーマンスを高い可用性が求められ、　　　 運用負荷が大きい • 積極的に別の構成に置き換える 35
36. メトリクスをMackerelに移行する Grafana+Prometheus • 運用工数を減らすには、SaaSに置き換えるのが一つの策 • ちょうどMackerelがツールスポンサーし、Mackerelを自由に使えるように なった ◦ Mackerel開発者がObservabilityチームに参加しているので、　　　　 トラブルを解決しやすいという事情もある → Mackerelに移行しよう!! 36
37. Mackerelの仕組み 37 mackerel-agent mackerel-container-agent OpenTelemetry
38. アプリケーション ログ メトリクスをMackerelに移行する 38 リアルタイム/日時 メトリクス Dreamkast Exporter エラートラッキング パフォーマンス ※以後、カンファレンス メトリクスについては省略する
39. メトリクスをMackerelに移行する Observabilityチームが管理しているサーバーを観測する • さくらのクラウドで動いているVMと、VM上で動いているミドルウェアを観測する dreamkastを観測する • Amazon ECSで動いているアプリケーションを観測する 39
40. メトリクスをMackerelに移行する 『Observabilityチームが管理しているサーバーを観測する』 • サーバーの死活を監視する ◦ さくらのクラウドのシンプル監視は、他へ移行する理由がないのでそのまま使う ◦ Mackerelの外形監視を設定する • VMのリソースを観測する ◦ mackerel-agentを入れる • Sentryのミドルウェアの動作を観測する ◦ PostgreSQL : mackerel-plugin-postgresを設定 ◦ Redis : mackerel-plugin-redisを設定 ◦ Kafka : mackerel-plugin-prometheus-exporterをラップしたプラグインを自作 • 監視ルール・カスタムダッシュボードを作る ◦ PostgreSQLやRedisを運用してきた経験から、観測するとよいメトリクスを　　　 ピックアップ 40
41. メトリクスをMackerelに移行する 『dreamkastを観測する』 • サービスの稼働を観測する ◦ 外形監視を設定する ◦ AWSインテグレーションでALBとSQSのメトリクスを観測する ▪ レスポンスタイム・エラーレートに監視ルールを設定する • アプリケーションのリソースを観測する ◦ mackerel-container-agentを設定する ◦ AWSインテグレーションでRDSとElastiCacheのメトリクスを観測する ◦ 障害対応やふりかえりの参考情報と考え、監視ルールはあまり設定しない • カスタムダッシュボードを作る ◦ カスタムダッシュボードおまかせ生成機能におまかせする 41
42. メトリクスをMackerelに移行する 42
43. トレースをSelf-Hosted Sentryから移行する • 最も運用の負担になっているSelf-Hosted Sentryから移行したい ◦ クラウド版Sentryへ一時的に戻した ◦ Mackerelへ移行中(後述) ▪ ツールスポンサーの下で自由に使える ▪ OpenTelemetryへ移行したい 43
44. アプリケーション ログ トレースをMackerelに移行する 44 リアルタイム/日時 メトリクス Dreamkast Exporter エラートラッキング パフォーマンス
45. Observability基盤の課題 💪 マンパワーが足りない→運用工数の少ない構成へ移行する • コミュニティの作業はフルタイムではない • 限られた時間の中で、価値を提供しなければならない 🔄 人が入れ替わり知見が伝承されない→よくある標準的な構成へ移行する • 最小限のドキュメンテーションは用意した • でも、変化が激しい中だとすぐ陳腐化してしまう 💰 確かにお金などのリソース節約はできた→金よりも未来にマンパワーを当て る • 運用コストが多く、バランスがとれていない 45
46. 人が入れ替わり知見が伝承されない 初めは各々の頭の中にしか知見がなかった Notionにナレッジを溜め始めた • しかしナレッジを整備し続けるマンパワーも足りない 伝承すべき知見を減らしたい 46
47. よくある標準的な構成へ移行する Observability基盤をOpenTelemetryへ移行する • 標準的な構成は、ナレッジが世間(Web・書籍・同僚の経験・LLM)にある ◦ 一方でself-hosted Sentryのナレッジはほとんど無い • Observabilityチームとしては新しい学ぶ価値のある技術である ◦ 本業でも使える 47
48. OpenTelemetryメトリクスを計装する Observabilityチームが管理しているサーバーを計装する • ocb (OpenTelemetry collector builder)でotelcol (OpenTelemetry collector)を　 ビルドして、デーモンを設定する • Mackerelのカスタムダッシュボードを作る dreamkastを計装する • ocb (OpenTelemetry collector builder)でotelcol (OpenTelemetry collector)を　 ビルドして、サイドカーを設定する • Mackerelのカスタムダッシュボードを作る 細かいやり方はここには書かない。なぜならばWebに書いてあるから! 48
49. OpenTelemetryメトリクスを計装する 49
50. アプリケーション ログ OpenTelemetryメトリクスを計装する 50 リアルタイム/日時 メトリクス エラートラッキング パフォーマンス
51. 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
52. アプリケーション ログ OpenTelemetryメトリクスを計装する 52 リアルタイム/日時 メトリクス エラートラッキング パフォーマンス
53. 現在の取り組みのまとめ 💪 マンパワーが足りない→運用工数の少ない構成へ移行する • SaaSへ移行する ◦ Mackerelへ移行する ▪ メトリックは移行した ▪ トレースはこれから移行する • 一時的にクラウド版Sentryに移行している 🔄 人が入れ替わり知見が伝承されない→よくある標準的な構成へ移行する • OpenTelemetryへ移行する ◦ メトリックは移行した ◦ トレースはこれから移行する 53
54. Observabilityチームのこれから 54
55. Observability基盤の課題 💪 マンパワーが足りない→運用工数の少ない構成へ移行する • コミュニティの作業はフルタイムではない • 限られた時間の中で、価値を提供しなければならない 🔄 人が入れ替わり知見が伝承されない→よくある標準的な構成へ移行する • 最小限のドキュメンテーションは用意した • でも、変化が激しい中だとすぐ陳腐化してしまう 💰 確かにお金などのリソース節約はできた→金よりも未来にマンパワーを当て る • 運用コストが多く、バランスがとれていない 55
56. 確かにお金などのリソース節約はできた 遮二無二に構築した初期。それを維持するのにお金もマンパワーもかかり続ける 　　　↓ インフラを移行してお金を節約し、課題がマンパワーに移ってきた 　　　↓ SaaSに移行してマンパワーの課題も改善し始めた 時は来た。未来の課題について話そう 56
57. 金よりも未来にマンパワーを当てる Mackerel/OpenTelemetryへの移行を完遂する • Observabilityチームがこれらに慣れて、自信を持つ 57
58. 金よりも未来にマンパワーを当てる 観測+緊急対応はまぁまぁできてる 観測を、緊急ではないが重要な意志決定に繋げたい • 何を意志決定するべきか炙り出したい ◦ フレームワークを適用する ▪ SREingのフレームワークを適用する 58
59. SREingのフレームワークを適用する ユーザーの体験を分析し、何を守るべきか探る • ユーザーの体験に信頼性を与えるのがSREing ◦ 惰性でSLO/SLIを定めない ◦ まずCUJ (critical user journey)を分析する 59
60. SREingのフレームワークを適用する ユーザーの体験を分析し、何を守るべきか探る • 仮説 : Dreamkastの状態は会期中と会期外とで全く異なる ◦ 会期中の数日は多くのユーザーが登壇を視聴する ▪ 高い可用性・性能が必要 ◦ 会期外のアクセスは多くない ▪ リソースの節約が重要 • それぞれの状態にSLI/SLOを設定するべきだろう ◦ 会期中に設定したSLOを達成できるように、事前に準備し事後にふりかえる ▪ 当日はSLOなんて気にしてる暇は無い ◦ 会期外は普通にerror budgetを管理する 60
61. SREingのフレームワークを適用する 開発・運用チームと連携する • SLOはdevopsに使われなければならない ◦ 約束・協力が最も重要 ▪ (技術よりも重要) 61
62. Observabilityチームのこれから • お金・マンパワーの課題は解決し始めた • まずはMackerel/OpenTelemetryへの移行を完遂する • 観測・緊急対応の先へゆきたい ◦ SREingのフレームワークを適用しようと考えている 62 未来への情熱 AIの考えた「金よりも未来にマンパワーを当てる」