OpenCensusと歩んだ7年間

© 2025 Wantedly, Inc. OpenCensusと歩んだ7年間 Observability Conference Tokyo 2025 /
Track C Oct.27 2025 - Atsushi Tanaka @bgpat

© 2025 Wantedly, Inc. ウォンテッドリーでは2018年から分散トレーシングを利⽤ 7年間のオブザーバビリティに関する取り組みを紹介 • オブザーバビリティ、分散トレーシングは今が始めどき • 分散トレーシング運⽤の⼼得
• 今後流⾏るか分からない技術や仕組みを導⼊するコツ 2 話すこと

田中篤志 / @bgpat ウォンテッドリー株式会社 Infrastructure Engineer / Squad Leader
2018年入社直後に OpenCensus 導入を担当 2024年からチームリーダー全社横断のチームで Kubernetes を中心としたマイクロサービス基盤を構築運用している 3 自己紹介

© 2025 Wantedly, Inc. 01 ウォンテッドリーについて 02 ウォンテッドリーと OpenCensus 03
OpenCensus による恩恵 04 OpenCensus との戦い 05 まとめ CONTENTS

© 2025 Wantedly, Inc. 社名代表者設⽴社員上場区分本社
ウォンテッドリー株式会社代表取締役仲暁⼦ 2010年9⽉ 120名東証グロース市場東京都港区⽩⾦台5-12-7 MG⽩⾦台ビル4F 会社概要 6

© 2025 Wantedly, Inc. ウォンテッドリーは、⾃律‧共感‧挑戦のある適材適所を、⼀時的でも、局所的でもなく、構造的に⽣み出し続けることによって、あらゆる⼈がシゴトに没頭し成果を上げ、その結果成⻑を実感できるような「はたらくすべての⼈のインフラ」を構築していきます。究極の適材適所によりシゴトでココロオドル
ひとをふやすミッション 7

© 2025 Wantedly, Inc. ATS 採⽤サービス福利厚⽣マネジメントツール社内報提供サービス
8

© 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年に集約統合を実施したウォンテッドリーのインフラの特徴

© 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 を廃止  ウォンテッドリーのインフラ変遷

© 2025 Wantedly, Inc. OpenCensus とは OpenTracing + OpenCensus =
OpenTelemetry

© 2025 Wantedly, Inc. OpenCensus とは • Google が主体となって開発していた OSS
◦ Stackdriver (現 Cloud Trace) で利⽤が推奨されていた • ベンダー中⽴な分散トレーシングのフレームワーク • 分散とレーシングだけでなくメトリクスの収集等 Observability 全般をカバーする⽬的も含まれていた • 開発は活発に⾏われていたが OpenTelemetry に統合され2023年7⽉31⽇でサポート終了

© 2025 Wantedly, Inc. OpenCensus 導⼊までの道のり • 新規サービスで Ruby on
Rails が苦⼿な並列処理や機械学習が必要に • ⾼速に開発とリリースのサイクルを回すためにも既存サービスとリリースサイクルの分離が必要だった • 結果、既存サービスと分離して開発を進められるメリットが⼤きく社内でマイクロサービス化が活発に⾏われるようになった • ⼀⽅で基盤となる API は既存のものが流⽤されていたなぜ分散トレーシングが必要だったのか = マイクロサービス化

© 2025 Wantedly, Inc. OpenCensus 導⼊までの道のり • 既存 API への負荷が増え問題が顕在化
• New Relic により改善に取り組んだがサービス分断により調査が難航例→ • 不安定な状態が改善しないまま開発は進み新しい問題が⼭積みに • 既存サービスも巻き込む事態に発展なぜ分散トレーシングが必要だったのか = マイクロサービス化

© 2025 Wantedly, Inc. OpenCensus 導⼊までの道のり • トレーシングのフレームワークに何を使うか • トレーシングのバックエンドに何を使うか
導⼊にあたり検討したこと

© 2025 Wantedly, Inc. OpenCensus 導⼊までの道のり • フレームワーク = トレースを収集‧送信するための仕組み
• 複数⾔語での運⽤前提なのでエコシステムに乗る⽅針 ◦ バックエンドサービスの変更容易性は維持 ◦ 成熟度合いを考えてベンダーロックインは避ける • 選定基準 ◦ 仕様や実装への理解のしやすさ ◦ ドキュメンテーションが整備されているか ◦ 対応するインテグレーションのサポート状況は⼗分か ▪ ない場合は⾃作できるかトレーシングのフレームワークに何を使うか

© 2025 Wantedly, Inc. OpenCensus 導⼊までの道のり • 両⽅とも実装とベンダーを分離するという⽬的は同じ • 将来性を⾒込んで選定した
◦ 技術的なスコープ ▪ OpenTracing は利⽤者は多いが分散とレーシングのみ ▪ OpenCensus は Metrics や Stats にも対応すると表明 ◦ コミュニティ ▪ Google が⾃社サービスでの利⽤を推奨していた ▪ 国内のユーザーコミュニティが存在していた OpenTracing と OpenCensus のどちらを使うか

© 2025 Wantedly, Inc. OpenCensus 導⼊までの道のり • バックエンド = トレースを分析‧可視化するためのサービス
• ⾃前運⽤は導⼊運⽤のコストが⾼いため除外 • クラウドサービスを実際に試して検討した ◦ Datadog APM ◦ Google Stackdriver Trace ◦ Amazon X-Ray • 2018年時点では判断できないという結論に ➡ Datadog APM と Stackdriver Trace を併⽤して試すことにトレーシングのバックエンドに何を使うか

© 2025 Wantedly, Inc. OpenCensus 導⼊までの道のり • 最速で効果が感じられるサービスに対して計装 ◦ 障害やエラーが多く困っているサービスで検証
◦ Ruby と Go のアプリ間の通信が⼀番問題になっていたので両⽅の実装を進めた • 期待を満たせそうなことが分かったのでほぼ全サービスに計装 ◦ 共通ライブラリ “servicex” に実装を移植 ◦ 社内標準化で利⽤する技術の種類が少なく⼊れやすかった • 全社で利⽤されるように整備 ◦ ドキュメント執筆, 速習会の実施どうやって導⼊したか

© 2025 Wantedly, Inc. OpenCensus による恩恵 • 整備されていない状態だからこそ基礎力をつけやすい ◦ 揃うまで待つとキャッチアップするハードルが高くなる
◦ 初期はコア機能の周辺から開発されることが多く追加の機能もキャッチアップしやすい ◦ (やるしかない状況で技術と精神を鍛えられる) • 発信のハードルが下がり機会増加に繋がった ◦ ネタがあることによる心理的ハードル ▪ 新しいものは注目を得やすい ▪ 発表の題材を考えやすい ◦ 運用し続ければ誰よりも長く使っていることになる = 無限に話せる技術に対する深堀りと発信の機会

© 2025 Wantedly, Inc. OpenCensus との戦い • 事例が少なく試⾏錯誤に時間がかかった ◦ まだ運⽤している⼈が少なかったので情報も少ない
◦ attribute が各サービスでどう表⽰されるか調べた例→ • 実装が実⽤レベルに追いついていない状態だった ◦ 特に Ruby はメンテナ不⾜が顕著だった ◦ 仕⽅なくしばらく fork して利⽤していた ◦ Ruby ⽤の Datadog Exporter がなく⾃作した • 実装がないだけではなくバグもたくさん踏んだ ◦ 例: ⾮同期処理のバグがありパフォーマンス悪化導⼊時 (2018年当時) の困りごと

© 2025 Wantedly, Inc. OpenCensus との戦い • 公式提供された実装や仕組みに置き換えるのが⼤変 ◦ 独⾃仕様や独⾃実装が多く存在しなかなか移⾏できない期間が続いた
◦ 共通ライブラリのおかげで負担を軽減できた • トレースが途切れる問題 ◦ 何もしていないのに勝⼿に壊れる (依存パッケージのバージョン更新等) ◦ トレースが途切れていても気付けない ◦ 分散トレーシングの仕組み⾃体が使われなくなっていく運⽤中の困りごと

© 2025 Wantedly, Inc. OpenCensus との戦い基本的には2023年のサポート終了後に発⽣した問題 • 依存関係が解決できず他のパッケージがあげられない ◦
サポート終了に伴ないパッケージ更新ができなくなった ◦ 移⾏ステップとして shim や bridge は⽤意されているが... • トレーシングフレームワークの並⾏運⽤による競合 ◦ 複数パッケージを⼊れると⽚⽅がトレースできなくなる ◦ テスト環境で無効のはずが有効化されてテスト実⾏を失敗させる • 公式実装が提供されなくなる ◦ トレースが途切れる問題に対処しようとして気付いた OpenTelemetry に統合されたことによる廃⽌対応

© 2025 Wantedly, Inc. まとめ • オブザーバビリティ、分散トレーシングは今が始めどき ◦ OpenTelemetry や
TraceContext 等のエコシステムが充実してきた ◦ ⾃動計装によって⽐較的⼿軽に始めることもできるようになってきた • 分散トレーシング運⽤の⼼得 ◦ もれなく⼊れるのが⼤事なので共通ライブラリや⾃動計装を活⽤する ◦ ⼊れて終わりではなく継続的なメンテナンスが必要 ◦ 分散トレーシングはあくまでツール、活⽤するにはデザインが必要 • 今後流⾏るか分からない技術や仕組みを導⼊するコツ ◦ 効果の⼤きいところを後回しにせず使えるものを増やしていく ◦ 後の⼤きな仕様変更や標準化により作り直しが発⽣する可能性を考慮しておく ◦ 先駆者になる覚悟を持つ

OpenCensusと歩んだ7年間

OpenCensusと歩んだ7年間

More Decks by Atsushi Tanaka

Other Decks in Technology

Featured

Transcript