OpenCensusと歩んだ7年間

Observability Conference Tokyo 2025 / Track C
https://o11ycon.jp/#timetable?session=82c3d062-0233-442b-888d-5eacd325e834

Transcript

1. © 2025 Wantedly, Inc. OpenCensusと歩んだ7年間 Observability Conference Tokyo 2025 / Track C Oct.27 2025 - Atsushi Tanaka @bgpat
2. © 2025 Wantedly, Inc. ウォンテッドリーでは2018年から分散トレーシングを利⽤ 7年間のオブザーバビリティに関する取り組みを紹介 • オブザーバビリティ、分散トレーシングは今が始めどき • 分散トレーシング運⽤の⼼得 • 今後流⾏るか分からない技術や仕組みを導⼊するコツ 2 話すこと
3. 田中 篤志 / @bgpat ウォンテッドリー株式会社 Infrastructure Engineer / Squad Leader 2018年入社直後に OpenCensus 導入を担当 2024年からチームリーダー 全社横断のチームで Kubernetes を 中心としたマイクロサービス基盤を 構築運用している 3 自己紹介
4. © 2025 Wantedly, Inc. 01 ウォンテッドリーについて 02 ウォンテッドリーと OpenCensus 03 OpenCensus による恩恵 04 OpenCensus との戦い 05 まとめ CONTENTS
5. © 2025 Wantedly, Inc. ウォンテッドリーについて 01
6. © 2025 Wantedly, Inc. 社名 代表者 設⽴ 社員 上場区分 本社 ウォンテッドリー株式会社 代表取締役 仲 暁⼦ 2010年9⽉ 120名 東証グロース市場 東京都港区⽩⾦台5-12-7 MG⽩⾦台ビル4F 会社概要 6
7. © 2025 Wantedly, Inc. ウォンテッドリーは、⾃律‧共感‧挑戦のある適材適所を、 ⼀時的でも、局所的でもなく、構造的に⽣み出し続けることによって、 あらゆる⼈がシゴトに没頭し成果を上げ、その結果成⻑を実感できるような 「はたらくすべての⼈のインフラ」を構築していきます。 究極の適材適所により シゴトでココロオドル ひとをふやす ミッション 7
8. © 2025 Wantedly, Inc. ATS 採⽤サービス 福利厚⽣ マネジメントツール 社内報 提供サービス 8
9. © 2025 Wantedly, Inc. 提供サービス
10. © 2025 Wantedly, Inc. ウォンテッドリーの Infra Squad の役割 10
11. © 2025 Wantedly, Inc. 1. EKS 中⼼のマイクロサービス構成 運⽤と開発を同じ環境で⾏うために EKS を利⽤ ひとつのクラスタに全てのマイクロサービスをデプロイ 2. シンプルな構成セットを使いまわす コンピューティング: Deployment + Service / CronJob RDB  : RDS / Aurora Redis  : ElastiCache ネットワーク  : EKS の Ingress により ALB を作成 3. 各マイクロサービスで必要な機能は 共通ライブラリで実装 内製ライブラリ “servicex” によりマイクロサービス運⽤に 必須のモニタリング, トレーシング, ロギング等の機能を提供 Ruby, Node.js, Go, Python の実装を⽤意 4. 監視や分析のための基盤は Datadog を中⼼に利⽤ 複数サービスを使い分けていたが 利便性向上とコスト削減のため2024年に集約統合を実施した ウォンテッドリーのインフラの特徴
12. © 2025 Wantedly, Inc. 2011/09 サービス開始 
 インフラは Heroku を利用 2014/?? AWS に移行
 自律的なデプロイのため Docker を採用
 2015/11 マイクロサービス化を検討 
 k8s の採用前は内製 PaaS を開発していた
 2016/11 Kubernetes 本番導⼊ 一つのマイクロサービスから運用開始 当時は EC2 上にクラスタを構築 2018/01 共通ライブラリ “servicex” 誕⽣ マイクロサービスが備えるべき機能を 扱いやすい・統一的な形で提供 2018/07 分散トレーシングの導⼊ マイクロサービス化により重要度が増した
 2020/04 kube fork による開発が開始 自分だけのクラスタで開発できる体験 初めは特定のサービスでしか利用できなかった 2021/05 PR 毎のプレビュー環境 
 PR に対して fork を実行する仕組みが登場
 2024/12 監視サービスを Datadog に統一
 役割の被っていた New Relic を廃止
 ウォンテッドリーのインフラ変遷
13. © 2025 Wantedly, Inc. ウォンテッドリーと OpenCensus 02
14. © 2025 Wantedly, Inc. OpenCensus とは OpenTracing + OpenCensus = OpenTelemetry
15. © 2025 Wantedly, Inc. OpenCensus とは • Google が主体となって開発していた OSS ◦ Stackdriver (現 Cloud Trace) で利⽤が推奨されていた • ベンダー中⽴な分散トレーシングのフレームワーク • 分散とレーシングだけでなくメトリクスの収集等 Observability 全般をカバーする⽬的も含まれていた • 開発は活発に⾏われていたが OpenTelemetry に統合され2023年7⽉31⽇でサポート終了
16. © 2025 Wantedly, Inc. OpenCensus 導⼊までの道のり • 新規サービスで Ruby on Rails が苦⼿な並列処理や機械学習が必要に • ⾼速に開発とリリースのサイクルを回すためにも 既存サービスとリリースサイクルの分離が必要だった • 結果、既存サービスと分離して開発を進められるメリットが⼤きく 社内でマイクロサービス化が活発に⾏われるようになった • ⼀⽅で基盤となる API は既存のものが流⽤されていた なぜ分散トレーシングが必要だったのか = マイクロサービス化
17. © 2025 Wantedly, Inc. OpenCensus 導⼊までの道のり • 既存 API への負荷が増え問題が顕在化 • New Relic により改善に取り組んだがサービス分断により調査が難航 例→ • 不安定な状態が改善しないまま開発は進み新しい問題が⼭積みに • 既存サービスも巻き込む事態に発展 なぜ分散トレーシングが必要だったのか = マイクロサービス化
18. © 2025 Wantedly, Inc. そこで分散トレーシング
19. © 2025 Wantedly, Inc. OpenCensus 導⼊までの道のり • トレーシングのフレームワークに何を使うか • トレーシングのバックエンドに何を使うか 導⼊にあたり検討したこと
20. © 2025 Wantedly, Inc. OpenCensus 導⼊までの道のり • フレームワーク = トレースを収集‧送信するための仕組み • 複数⾔語での運⽤前提なのでエコシステムに乗る⽅針 ◦ バックエンドサービスの変更容易性は維持 ◦ 成熟度合いを考えてベンダーロックインは避ける • 選定基準 ◦ 仕様や実装への理解のしやすさ ◦ ドキュメンテーションが整備されているか ◦ 対応するインテグレーションのサポート状況は⼗分か ▪ ない場合は⾃作できるか トレーシングのフレームワークに何を使うか
21. © 2025 Wantedly, Inc. OpenCensus 導⼊までの道のり • 両⽅とも実装とベンダーを分離するという⽬的は同じ • 将来性を⾒込んで選定した ◦ 技術的なスコープ ▪ OpenTracing は利⽤者は多いが分散とレーシングのみ ▪ OpenCensus は Metrics や Stats にも対応すると表明 ◦ コミュニティ ▪ Google が⾃社サービスでの利⽤を推奨していた ▪ 国内のユーザーコミュニティが存在していた OpenTracing と OpenCensus のどちらを使うか
22. © 2025 Wantedly, Inc. OpenCensus 導⼊までの道のり • バックエンド = トレースを分析‧可視化するためのサービス • ⾃前運⽤は導⼊運⽤のコストが⾼いため除外 • クラウドサービスを実際に試して検討した ◦ Datadog APM ◦ Google Stackdriver Trace ◦ Amazon X-Ray • 2018年時点では判断できないという結論に ➡ Datadog APM と Stackdriver Trace を併⽤して試すことに トレーシングのバックエンドに何を使うか
23. © 2025 Wantedly, Inc. OpenCensus 導⼊までの道のり トレーシングのバックエンドに何を使うか
24. © 2025 Wantedly, Inc. OpenCensus 導⼊までの道のり • 最速で効果が感じられるサービスに対して計装 ◦ 障害やエラーが多く困っているサービスで検証 ◦ Ruby と Go のアプリ間の通信が⼀番問題になっていたので 両⽅の実装を進めた • 期待を満たせそうなことが分かったのでほぼ全サービスに計装 ◦ 共通ライブラリ “servicex” に実装を移植 ◦ 社内標準化で利⽤する技術の種類が少なく⼊れやすかった • 全社で利⽤されるように整備 ◦ ドキュメント執筆, 速習会の実施 どうやって導⼊したか
25. © 2025 Wantedly, Inc. OpenCensus による恩恵 03
26. © 2025 Wantedly, Inc. OpenCensus による恩恵 • サービスの信頼性が⼤幅に向上した • 技術に対する深堀りと発信の機会が作れた
27. © 2025 Wantedly, Inc. OpenCensus による恩恵 • 頻発していた障害の抑制 • 放置されていたエラーの対処 • 今まで⾒えていなかった問題の検知 サービス信頼性の向上
28. © 2025 Wantedly, Inc. OpenCensus による恩恵 - 頻発していた障害の抑制①
29. © 2025 Wantedly, Inc. OpenCensus による恩恵 - 頻発していた障害の抑制①
30. © 2025 Wantedly, Inc. OpenCensus による恩恵 - 頻発していた障害の抑制②
31. © 2025 Wantedly, Inc. OpenCensus による恩恵 - 放置されていたエラーの対処
32. © 2025 Wantedly, Inc. OpenCensus による恩恵 - 今まで⾒えていなかった問題の検知
33. © 2025 Wantedly, Inc. OpenCensus による恩恵 • 整備されていない状態だからこそ基礎力をつけやすい ◦ 揃うまで待つとキャッチアップするハードルが高くなる ◦ 初期はコア機能の周辺から開発されることが多く 追加の機能もキャッチアップしやすい ◦ (やるしかない状況で技術と精神を鍛えられる) • 発信のハードルが下がり機会増加に繋がった ◦ ネタがあることによる心理的ハードル ▪ 新しいものは注目を得やすい ▪ 発表の題材を考えやすい ◦ 運用し続ければ誰よりも長く使っていることになる = 無限に話せる 技術に対する深堀りと発信の機会
34. © 2025 Wantedly, Inc. OpenCensus との戦い 04
35. © 2025 Wantedly, Inc. OpenCensus との戦い • 事例が少なく試⾏錯誤に時間がかかった ◦ まだ運⽤している⼈が少なかったので情報も少ない ◦ attribute が各サービスでどう表⽰されるか調べた例→ • 実装が実⽤レベルに追いついていない状態だった ◦ 特に Ruby はメンテナ不⾜が顕著だった ◦ 仕⽅なくしばらく fork して利⽤していた ◦ Ruby ⽤の Datadog Exporter がなく⾃作した • 実装がないだけではなくバグもたくさん踏んだ ◦ 例: ⾮同期処理のバグがありパフォーマンス悪化 導⼊時 (2018年当時) の困りごと
36. © 2025 Wantedly, Inc. OpenCensus との戦い • 公式提供された実装や仕組みに置き換えるのが⼤変 ◦ 独⾃仕様や独⾃実装が多く存在しなかなか移⾏できない期間が続いた ◦ 共通ライブラリのおかげで負担を軽減できた • トレースが途切れる問題 ◦ 何もしていないのに勝⼿に壊れる (依存パッケージのバージョン更新等) ◦ トレースが途切れていても気付けない ◦ 分散トレーシングの仕組み⾃体が使われなくなっていく 運⽤中の困りごと
37. © 2025 Wantedly, Inc. いつの間にか壊れるトレース トレースが壊れる 使いづらい 利⽤者減 メンテされない
38. © 2025 Wantedly, Inc. OpenCensus との戦い 基本的には2023年のサポート終了後に発⽣した問題 • 依存関係が解決できず他のパッケージがあげられない ◦ サポート終了に伴ないパッケージ更新ができなくなった ◦ 移⾏ステップとして shim や bridge は⽤意されているが... • トレーシングフレームワークの並⾏運⽤による競合 ◦ 複数パッケージを⼊れると⽚⽅がトレースできなくなる ◦ テスト環境で無効のはずが有効化されてテスト実⾏を失敗させる • 公式実装が提供されなくなる ◦ トレースが途切れる問題に対処しようとして気付いた OpenTelemetry に統合されたことによる廃⽌対応
39. © 2025 Wantedly, Inc. まとめ 05 Section Sub Title
40. © 2025 Wantedly, Inc. まとめ • オブザーバビリティ、分散トレーシングは今が始めどき ◦ OpenTelemetry や TraceContext 等のエコシステムが充実してきた ◦ ⾃動計装によって⽐較的⼿軽に始めることもできるようになってきた • 分散トレーシング運⽤の⼼得 ◦ もれなく⼊れるのが⼤事なので共通ライブラリや⾃動計装を活⽤する ◦ ⼊れて終わりではなく継続的なメンテナンスが必要 ◦ 分散トレーシングはあくまでツール、活⽤するにはデザインが必要 • 今後流⾏るか分からない技術や仕組みを導⼊するコツ ◦ 効果の⼤きいところを後回しにせず使えるものを増やしていく ◦ 後の⼤きな仕様変更や標準化により作り直しが発⽣する可能性を考慮しておく ◦ 先駆者になる覚悟を持つ
41. © 2025 Wantedly, Inc. https://www.wantedly.com/projects/522096
42. © 2025 Wantedly, Inc. 毎⽉⾃社イベントを開催 - Wantedly Tech Night https://wantedly.connpass.com
43. © 2025 Wantedly, Inc. 開発組織と技術についてのドキュメントを公開中 - Wantedly Engineering Handbook https://wantedly.dev