Atlassianは、当初サービスチームにメトリクスの送信方法の変更を求めることなく、OpenTelemetry Collectorを中心にメトリクスプラットフォームを再構築しました。古いパイプラインを削除してから数千のサービスを再設定するのではなく、同社はUDP経由のStatsDインターフェースを維持し、その背後にある収集、処理、ルーティングの各層を段階的に置き換えました。
以前のプラットフォームは、過去10年の大半にわたり、Atlassianが開発するオープンソースのStatsDアプリケーションであるgostatsdに依存していました。gostatsdはホスト上のサイドカーエージェントとして、また反対側の集約層として動作していました。このプラットフォームは、14のリージョンに分散する約10万台のホストから送られるメトリクスを、99.95%のサービスレベル目標と低いレイテンシーで処理していました。
契約を固定したままエンジンを変更する
Atlassianのチームは、インフラストラクチャーを変更する前にすべてのサービスをOpenTelemetry SDK向けに再設定することは、数年に及ぶ作業となり、アラートが依存するデータを失う可能性もあると判断しました。そこでプラットフォームのインターフェースと内部コンポーネントを分離しました。サービスは同じアドレスにStatsD形式で接続し続ける一方、内部層はOpenTelemetry Collectorのカスタムディストリビューションへ段階的に置き換えられました。
設計は、収集、受信、集約、ルーティングという4つの独立した段階で構成されました。また、収集層はStatsDとOTLPを同時に受信できるようにしました。これにより、チームにクライアントライブラリの切り替えを強いることなく移行を開始でき、OpenTelemetryを使用して最初から作成されたメトリクスへの道も開かれました。
実際に何が変わったのか
収集段階では、gostatsdのサイドカーエージェントを、以前トレーシングチームが使用していたOpenTelemetry Collectorのディストリビューションに置き換え、アプリケーションの従来の動作は維持しました。これにより、各ホストで2つのエージェントを実行するのではなく、メトリクスとトレーシングを1つのサイドカーエージェントに統合できました。
Atlassianによると、この統合により、コストの高いMicrosサービス群ではサービスあたり平均約3.9%のCPU使用量が削減され、フリート全体のサイドカーエージェント費用では約30%の削減に相当しました。また、収集層がOpenTelemetryのメトリクスを受信して直接転送できるよう、OTLPレシーバーも追加しました。
受信段階では、主な問題は時系列の状態に関係していました。同じ時系列に属するすべてのデータポイントを、1つの集約器へ送信する必要がありました。旧システムでは、nomadという内部エージェントを通じて、サービスと環境のペアに基づくシャーディングを採用していました。しかし、サービス規模のばらつきにより、負荷の高い集約器と利用の少ない集約器が生じていました。
Atlassianは、OpenTelemetryリポジトリのloadbalancingexporterコンポーネントを使用し、streamID、つまり個々の時系列の識別子に基づいてシャーディングすることでこの問題に対処しました。この方式により、大規模サービスのデータを集約器のグループ全体に分散しながら、1つの時系列は同じ集約器に保持できました。その結果、集約器間のCPU分布がより均衡し、自動スケーリング能力が向上し、高負荷アラートが減少しました。
集約層におけるデータとコストの削減
集約層は毎分約48億のデータポイントを処理しますが、保存するのは約2億2,000万ポイント בלבדであり、約96%の削減となります。大半のメトリクスがdelta temporalityを使用している一方、以前のコンポーネントはユーザーが期待する方法でこれらの差分を集約していませんでした。そのためAtlassianは、メトリクスのデルタを集約する専用プロセッサーを開発し、atlassian-labsの範囲でオープンソースとして公開しました。
移行後、集約層に必要なCPUは以前のおよそ半分になりました。情報源は、この改善を、gostatsd形式の解析の廃止、負荷分散の改善、OpenTelemetryコミュニティによる最適化の活用など、複数の要因に結び付けています。
最後の段階では、専用の内部ルーターを、同社がmetrics-gatewayと名付けたステートレスなCollectorディストリビューションに置き換えました。このディストリビューションはupstreamのエクスポーターを利用し、SignalFxやS3など複数の宛先への送信を、再試行、キュー、バックプレッシャー制御の機能とともにサポートします。公表された設計によれば、新しい宛先の追加は独立した統合プロジェクトではなく、設定の変更になります。
段階的な移行から得られた教訓
- 適切なチームから始める：Atlassianは、開発環境とテスト環境、そして問題の影響をより強く受けていたサービスを選び、より低い感度の範囲で早期のフィードバックを得ました。
- 本番環境を継続的に監視する：本番負荷下でのプロファイリングにより、小規模なテストや人工的なベンチマークでは得られない、コンポーネントの挙動とコストが明らかになりました。
- 運用の対称性を維持する：移行には数か月または数年かかり、その間は両システムを並行稼働させる可能性があるため、同社はツールと運用手順を可能な限り共通に保つことを推奨しました。
- 段階的に範囲を拡大する：デプロイでは1%から始め、10%、50%を経て100%に到達する段階的な比率を採用し、重要な経路に先立って、影響の少ないサービスで問題を検証しました。
なぜこのアプローチが重要なのか
この経験は、インフラストラクチャーに新しい標準を採用する際、すべての利用者のインターフェースを同じ瞬間に変更する必要は必ずしもないことを示しています。外部契約を維持することで、移行は全チームを巻き込む組織的なプロジェクトから、インフラストラクチャープラットフォームが主導するプロジェクトへと変わり、OTLPとOpenTelemetryコンポーネントを段階的に導入できるようになりました。
Atlassianによると、gostatsdとnomadは合わせてメトリクス・クラスターにおけるCPUリクエストの約38%を占め、nomadだけでも総リソースの約13%を占めていました。したがって移行の効果は、ツールの統一にとどまりません。高コストなカスタムコンポーネントを排除し、社内で保守する必要のある部品数を減らすことにも結び付いています。
ただし、これはサービスのinstrumentingのレベルで移行が完了したことを意味しません。同社が示した次のステップは、instrumentingツール自体をOpenTelemetry SDKへ移行し、現在も使用されているDatadogおよびDogStatsDのクライアントと、内部のStatsDライブラリを段階的に廃止することです。また、ここで示した性能結果と数値は、Atlassianの環境における同社の経験を説明するものであり、同じ値がすべての監視アーキテクチャーで再現されることを保証するものではありません。