エンドユーザー Q&A シリーズ: Farfetch での OTel の活用

By Adriana Villela (Lightstep) |

Blog posts are not updated after publication. This post is more than a year old, so its content may be outdated, and some links may be invalid. Cross-verify any information before relying on it.

Rynn Mancuso（Honeycomb）と Reese Lee（New Relic）の協力のもと作成。

2023年5月25日（木）、OpenTelemetry（OTel）End User Working Group は 2023 年第 3 回の エンドユーザー Q&A セッションを開催しました。 KubeCon Europe のため少し間が空きましたが、戻ってきました！ このシリーズは、本番環境で OpenTelemetry を使用しているチームとの月例カジュアルディスカッションです。 チームの環境、成功事例、直面している課題について学び、コミュニティと共有することで、ともに OpenTelemetry をより良いものにしていくことを目的としています。

今月は、Farfetch のプラットフォームエンジニアである Iris Dyrmishi 氏にお話を伺いました。

概要

Iris 氏はオブザーバビリティと OpenTelemetry の熱烈なファンであり、彼女のこれら 2 つのトピックへの情熱は非常に感染力があります。

このセッションで Iris 氏が共有した内容は以下のとおりです。

  • Farfetch の OpenTelemetry への道のり
  • メトリクスとトレースの計装方法
  • OpenTelemetry Collector のデプロイと設定

Q&A

あなたの役割を教えてください

Iris 氏は、Farfetch 全体のエンジニアリングチームにサービス監視ツールを提供する中央チームに所属しています。 トレース、メトリクス、ログ、アラートなどを対象としています。 チームはオブザーバビリティツールの保守、オブザーバビリティツールに関連するデプロイの管理、OpenTelemetry を使用したコードの計装についてチームを教育する責任を担っています。

Iris 氏はソフトウェアエンジニアとしてキャリアをスタートし、バックエンド開発に注力していました。 その後、DevOps エンジニアリングの役割に移り、そこで Amazon CloudWatch や Azure App Insights などの製品を通じてクラウド監視に出会いました。 監視について学ぶほど、それが彼女の情熱になっていきました。

その後、別の役割に移り、OpenTelemetry、Prometheus、Grafana に出会い、オブザーバビリティの世界をより深く探求する機会を得ました。 この役割が、1年以上前から担当している Farfetch での現在の役割への足がかりとなりました。

OpenTelemetry をどのように知りましたか

Iris 氏が初めて OpenTelemetry を知ったのは LinkedIn でした。 当時勤めていた会社はトレースを使用しておらず、トレースの使用を検討し始め、トレーシングソリューションを探していました。 OpenTelemetry について読んだ後、Iris 氏はマネージャーのために小さな概念実証（POC）を作成しました。 その役割では POC から先に進むことはありませんでしたが、Iris 氏が Farfetch に入社し、OpenTelemetry が再び話題になったとき、彼女はこの機会に飛びつきました。

Farfetch のアーキテクチャはどのようなものですか？ OpenTelemetry はどのように役立っていますか？

Farfetch には現在 2000 人のエンジニアがおり、クラウドネイティブ、Kubernetes、3 つの異なるクラウドプロバイダー上で動作する仮想マシンを含む、複雑で多様なアーキテクチャを持っています。 あらゆるところから大量の情報が流れ込んでおり、この情報を収集する方法の標準化が不足していました。 たとえば、Prometheus はメトリクス収集の標準として主に使用されていましたが、場合によっては Prometheus がニーズに合わないことをエンジニアが見つけることもありました。 OpenTelemetry の導入により、Farfetch はメトリクスとトレースの両方の収集を標準化でき、以前はシグナル収集ができなかったサービスからもテレメトリーシグナルを収集できるようになりました。

Farfetch のビルドとデプロイのプロセスを説明してください

Farfetch は CI/CD に Jenkins を使用しており、これを管理する専門チームがあります。

どのようなオブザーバビリティツールを使用していますか

Iris 氏のチームは主にオープンソースツールを使用しており、チームが作成した社内ツールも併用しています。 オープンソースツールとしては以下のとおりです。

  • Grafana をダッシュボードに使用
  • OpenTelemetry をトレースの送信に使用し、Grafana Tempo をトレーシングバックエンドとして使用
  • Jaeger は、一部のチームがまだ OpenTelemetry でのトレース計装に完全に移行していないため、トレースの送信とトレーシングバックエンドとして引き続き使用されているケースがある（Jaeger の OpenTracing API 実装経由）
  • Prometheus Thanos（高可用性 Prometheus）をメトリクスの収集とストレージに使用
  • OpenTelemetry もメトリクスの収集に使用

Farfetch の OpenTelemetry への道のりについて教えてください

Farfetch は非常にオブザーバビリティを重視する組織であり、シニアリーダーシップが OpenTelemetry の組織への導入を提案したとき、組織全体から圧倒的な支持を得ました。 OpenTelemetry に関する最大の課題は実装のタイミングでしたが、OpenTelemetry の作業が始まると、全員がそれを受け入れました。

あなたとチームはどのように OpenTelemetry を通じてオブザーバビリティを実現しましたか

Iris 氏が Farfetch に入社したころには、オブザーバビリティに関する大きな苦労や課題はほとんど解決されていました。 オブザーバビリティが組織内で初めて導入されたとき、多くのエンジニアにとってそれは非常に新しく未知のものであり、あらゆる新しいものと同様に学習曲線がありました。

Iris 氏とチームが組織全体で OpenTelemetry を有効にする作業に取り組んだとき、オブザーバビリティの概念はすでに受け入れられていました。 Farfetch に OpenTelemetry を導入する上での最大の課題は、エンジニアの業務に大きな混乱を与えないようにしながら、OpenTelemetry を導入するメリットを享受できるようにすることでした。 OpenTelemetry が Jaeger や Prometheus を含む既存のオブザーバビリティスタックの多くのツールと互換性があることが助けになりました。

Iris 氏と Farfetch のアーキテクトである同僚の一人が示した熱意、推進力、後押しにより、Iris 氏は現在 OpenTelemetry を本番環境で使用していることを誇らしげに共有しました。

チームが OpenTelemetry を本番環境に導入するまでどのくらいかかりましたか

Iris 氏とチームは 2023 年 1 月に OpenTelemetry の使用を開始する計画を立てました。 これには初期調査と情報収集が含まれていました。 3 月中旬までに、最初のコンポーネントを本番環境に導入しました。

まだ完全には達成されていません。

  • メトリクスとトレースの生成について、Prometheus と Jaeger への依存が依然として多い
  • すべてのアプリケーションが OpenTelemetry で計装されているわけではない

それにもかかわらず、Iris 氏とチームは OpenTelemetry Collector の力を活用して、メトリクスとトレースをさまざまなオブザーバビリティバックエンドに収集・送信しています。 OpenTelemetry の使用を開始して以来、より多くのトレースを計装するようになりました。 実際、現在のセットアップにより、1 秒あたり 1,000 スパンの処理から 1 秒あたり 40,000 スパンの処理へと拡大したことを Iris 氏はうれしそうに報告しました。

現在、トレースはどのように収集していますか

トレースは手動計装と自動計装の組み合わせで収集されています。

一部のアプリケーションは OpenTelemetry で手動計装されており、その他はレガシーの OpenTracing を使用して計装されています。 shim の使用により移行が行われています。

OpenTelemetry Operator は Java と .NET コードの自動計装を実装するために使用されています。 特に、OTel Operator はインジェクションと .NET、Java、Python、Node.js での自動計装の設定をサポートしています。 Iris 氏は Go の自動計装が近い将来利用可能になることを期待しています。 Go での自動計装の進捗を追跡するには、OpenTelemetry Go Automatic Instrumentation を参照してください。

これは長期にわたる時間のかかるプロセスになりますが、チームの目標はすべてのアプリケーションを OpenTelemetry で計装することです。

チームは手動計装にどのようなサポートを提供していますか

設計上、Iris 氏とチームは他のチームのコードを計装しません。 かわりに、手動計装に関するドキュメントとガイドラインを提供し、必要に応じて OpenTelemetry のドキュメントを参照するようチームに案内しています。 また、エンジニアとのセッションを行い、自分たちのコードを計装するためのベストプラクティスを紹介しています。 チームスポーツです！

OTel Operator の使用経験を共有してください

OTel Operator は本番環境で部分的にのみ使用されており、現在はすべてのユーザーに提供されていません。 Iris 氏とチームは OTel Operator をとても気に入っていますが、慣れるまでに少し時間がかかりました。 Iris 氏とチームは、cert-manager と OTel Operator の間に密結合があることに気づきました。 独自のカスタム証明書を使用することができず、クラスターで cert-manager をサポートしていなかったため、クラスターで Operator を使用するのが難しいと感じました。 これを解決するために PR を提出しました。 opentelemetry-helm-charts PR #760！

彼女が OpenTelemetry を気に入っている点の 1 つは、Prometheus が Collector にメトリクスを送信しない問題のトラブルシューティング中に、アラートを作成できなくなった際のことでした。 そのとき、同僚が OpenTelemetry を使って OpenTelemetry をトラブルシュートすることを提案しました。

あなたやチームのメンバー、Farfetch の誰かが OTel Logging を試し始めていますか

Iris 氏は OTel のロギングを少し試しており、主に Kafka トピックからログを消費しています。 この実験にはログ相関は含まれていませんが、今後探求したいと考えています。

ログはまだ安定版ではないため、Iris 氏は Farfetch で OTel ロギングがすぐに本番環境に入ることは期待していません。 Farfetch には膨大な量のログ（トレースよりも多い）があるため、状況がより安定するまで OTel ロギングへの変換を開始したくないとのことです。

Note: OTel ログの一部は安定版です。 詳細は仕様ステータス概要を参照してください。

メトリクスシグナルはどのように収集していますか

自動計装がいくつかの OTLP メトリクスを出力していますが、メトリクスの大部分はまだ Prometheus から取得しています。

チームは現在、Prometheus レシーバーを使用して Consul からメトリクスをスクレイプしています。 具体的には、Consul を使用してターゲットとスクレイプ先のポートを取得しています。 レシーバーのスクレイプ設定は Prometheus と同じであるため、Prometheus から Prometheus レシーバーへの移行（リフト・アンド・シフト）は比較的容易でした。

また、Kubernetes から OTLP メトリクスを収集する計画もあります。 これは Prometheus レシーバーが OTel Operator の Target Allocator をサポートしていることで容易になります。

Prometheus はその他の領域でもメトリクス収集に引き続き使用されており、特に仮想マシンからメトリクスを収集する場合はおそらくこのまま使われ続けるでしょう。

いくつの Kubernetes クラスターを監視していますか

監視している Kubernetes クラスターは 100 個あり、仮想マシンは数千台あります。 Iris 氏とチームは、これらすべてのクラスターにおける OTel Operator の管理を担当しており、クラスター上のスタックを維持できるよう Kubernetes のトレーニングも受けています。

Kubernetes の OTel 実験的機能を試しましたか

この質問は、Kubernetes コンポーネントが OTLP トレースを出力し、OTel Collector で消費できる機能に関するものです。 詳細は Traces For Kubernetes System Components を参照してください。 この機能は現在ベータ版であり、Kubernetes 1.25 で初めて導入されました。

Iris 氏とチームはこのベータ機能を試していません。

OTel Collector はどのようにデプロイしていますか

Kubernetes クラスターが多数あるため、単一の OTel Collector ではロードとシングルポイントオブフェイルの観点からボトルネックになります。 チームは現在、Kubernetes クラスターごとに 1 つの OpenTelemetry Collector エージェントを配置しています。 最終的な目標は、これらのエージェントを OTel Operator に置き換えることです。 OTel Operator により、OTel Collector のデプロイと設定、および自動計装のインジェクションと設定が可能になります。

すべてのデータはデータセンターごとの集中型 OTel Collector（すなわち OTel Collector ゲートウェイ）に送信されます。 ここでデータマスキング（transform プロセッサーまたは redaction プロセッサー）、データサンプリング（たとえば tail sampling プロセッサーまたは probabilistic sample プロセッサー）などの処理が行われます。 その後、トレースを Grafana Tempo に送信します。

集中型 OTel Collector は、Farfetch のオブザーバビリティチーム専用の別の Kubernetes クラスター上に配置されており、Collector とチームに属する他のアプリケーションを実行しています。

集中型 Collector に障害が発生したらどうなりますか

チームにはフォールバッククラスターがあり、集中型 Collector に障害が発生した場合、フォールバッククラスターがかわりに使用されます。 サテライトクラスターはフォールバッククラスター上の集中型 Collector にデータを送信するよう設定されているため、集中型クラスターに障害が発生しても、OTel データフローを中断することなくフォールバッククラスターを立ち上げることができます。

オートスケーリングポリシーを設定して、Collector がデータ負荷を処理するのに十分なメモリと CPU を確保することも、システムの高可用性維持に役立っています。

OTel Collector のデプロイで経験した課題は何ですか

最大の課題は、Collector を理解し、効果的に使用する方法を習得することでした。 Farfetch はオートスケーリングに大きく依存しているため、チームが最初に行ったことの 1 つは Collector のオートスケーリングを有効にし、大量のデータを処理できるよう設定を調整することでした。

チームはまた、OTel Helm charts と OTel コミュニティに大いに頼りました。

現在 OTel Collector でプロセッサーを使用していますか？
チームは現在、プロセッサーを試験的に使用しています。主にデータマスキング（transform プロセッサーまたは redaction プロセッサー）のためです。 特に OTel ログの使用に移行するにあたり、オブザーバビリティバックエンドに送信したくない機密データが含まれるためです。 ただし、現時点では batch プロセッサーのみを使用しています。

スパンイベントを使用しているチームを知っていますか

スパンイベントは、トレース内の追加的なポイントインタイム情報を提供します。 基本的にはスパン内の構造化ログです。

現時点ではありませんが、今後探求したいと考えています。 オブザーバビリティチームが活動を開始した当初、トレーシングへの関心はあまりありませんでした。 OpenTelemetry とトレーシングの実装を開始すると、トレースをファーストクラスの要素として位置づけるようになり、エンジニアたちがトレースの有用性に気づき始めて関心が高まっています。

OpenTelemetry に抵抗する人に出会ったことはありますか

Farfetch は非常にオブザーバビリティを重視する文化があり、オブザーバビリティチームはオブザーバビリティや OpenTelemetry に反対する人にはほとんど出会っていません。 一部のエンジニアはどちらでもよいと思っているかもしれませんが、反対しているわけではありません。

あなたやチームは OpenTelemetry にコントリビューションしましたか

チームはアーキテクトの主導のもと、証明書に関する OTel Operator へのコントリビューションを最近行いました。 OTel Operator はカスタム証明書ではなく cert-manager の証明書に依存していました。 最初はフィーチャーリクエストを提出しましたが、その後自分たちで機能を開発することにし、プルリクエストを提出しました。

聴衆からの質問

メモリと CPU はどれくらいですか

Collector が 1 秒あたり約 30,000 スパンを処理していたとき、Collector のインスタンスは 4 つあり、約 8GB のメモリを使用していました。

メトリクスデータ、トレースデータ、ログデータ間の相関を行っていますか

現在検討中の内容です。 チームは OpenTelemetry を通じてトレースとメトリクスの相関（エグザンプラー）を探求しています。 ただし、この相関はトレーシングバックエンドの Tempo を通じた方がより容易に実現できることがわかりました。

生成、転送、収集するデータ量について懸念はありますか？ データ品質はどのように確保していますか？

これは懸念事項ではありません。データ量は変わっておらず、チームはこの大量のデータを処理できることを把握しています。 チームは単にデータの生成、転送、収集の方法を変更しているだけです。 Iris 氏はトレースデータの量が徐々に増加していることも認識しています。 ただし、データの増加は段階的であるため、チームはより大きなデータ量を処理するための準備ができます。

チームは品質の高いデータを取得することに注力しています。 これは特にメトリクスにおいて当てはまり、意味のあるデータを処理していることを確認するためにメトリクスデータをクリーンアップしています。 あるチームが出力するメトリクスの量を大幅に増加させる場合、増加が妥当かどうかを確認するために事前にオブザーバビリティチームに相談されます。

トレース量は当初少なかったため、トレースサンプリングについて心配する必要はありませんでした。 現在トレース量が増加しているため、注意深く監視しています。

チームはログのデータ品質と量にも注力しており、ニーズに合うログプロセッサーを調査しています。 最終的には、開発チームが従うべきガイドラインのセットを公開し、社内でプラクティスを広める予定です。

フィードバック

Iris 氏とチームは、OpenTelemetry と OpenTelemetry コミュニティに対して非常に良い経験をしています。

ドキュメント

Iris 氏は、ドキュメントがときに十分に明確でないことがあり、特定のコンポーネントがどのように動作するか、またはどのように設定すべきかを理解するためにエンジニアが追加の調査を必要とすることがあると共有しました。 たとえば、OpenTelemetry の Consul SD 設定に関するドキュメントを見つけるのに苦労しました。 とはいえ、Iris 氏はドキュメントの改善に貢献したいと考えています。

PR のターンアラウンドタイム

Iris 氏とチームは、OTel Operator PR の承認とマージが素早く行われたことに良い意味で驚きました。

その他のリソース

Iris 氏との会話の全編は YouTube で公開されています。

Iris 氏との会話を続けたい方は、#otel-user-research Slack チャンネルでご連絡ください！

また、6 月 8 日の OTel in Practice で発表する予定です。

おわりに

OpenTelemetry はコミュニティがすべてであり、コントリビューター、メンテナー、ユーザーなしでは今の私たちはありません。 OpenTelemetry が実際にどのように実装されているかのストーリーを聞くことは全体像の一部にすぎません。 ユーザーのフィードバックを大切にしており、すべてのユーザーの皆さんに体験を共有していただき、OpenTelemetry の改善を続けていくことを推奨しています❣️

あなたの組織で OpenTelemetry をどのように使用しているかのストーリーを共有していただける方は、ぜひお聞かせください！ 共有方法:

Mastodon と Twitter で OpenTelemetry をフォローし、#OpenTelemetry ハッシュタグを使ってあなたのストーリーを共有してください！

最終更新 June 21, 2026: [ja] add translation of content/en/blog/2023/end-user-q-and-a-03.md (#10493) (5d2e271a)