OpenCensusと歩んだ7年間

by Atsushi Tanaka

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Slide 40

Slide 40 text

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