コスト効率に優れたオープンなオブザーバビリティ：OcadoがGrafana Cloudに移行した理由
Ocado Technologyのオンライン食料品プラットフォームが4大陸12の小売パートナーへと拡大するにつれ、そのオブザーバビリティスタックも肥大化しました。
ある時点では、チームは7ベンダーの13ツールに加え、3つの社内システムを使用して100以上のアプリケーションを観測していました。これらを合わせると、毎日18TBのメトリクスと15TBのログが送信されていました。
この規模になると、APM（アプリケーションパフォーマンス監視）、ロギング、アラート、ダッシュボードのためのツールが継ぎ接ぎ状態となり、コストと複雑さが増大しました。さらに、チームの速度を低下させる摩擦も生じました。例えば、インシデントのトラブルシューティングを行う際、エンジニアは頻繁にツールを切り替え、一貫性のないユーザーインターフェース間でリクエストIDをコピー＆ペーストする必要がありました。
「私たちはオブザーバビリティを単一のプラットフォームに統合したいと考えていました。また、将来的にコントロールと柔軟性を高めるために、オープンソースで標準化したいとも考えていました」と、OcadoのエンジニアリングディレクターであるMirek Wierzba氏は述べています。
ObservabilityCON 2025のセッションで、Wierzba氏は同社が単一のプラットフォームであるGrafana Cloudに統合することで、どのようにこの課題に取り組んだかを共有しました。
断片化から集中へ
Ocadoのメトリクスとログは主にNew Relicに送られていましたが、クローズドソースのエージェントではデータに対する制御が限定的でした。このスタックをサポートするには、チーム間の緊密な調整と、オブザーバビリティパイプライン内での頻繁なトラブルシューティングが必要でした。
「アーキテクチャ全体とオブザーバビリティのエコシステム全体を稼働させ続けるために、多大な労力と時間、エネルギーを費やす必要がありました」とWierzba氏は語ります。「それが時に、運用上の脆弱性につながることもありました。」
彼のチームは、これらの問題を個別に解決するのではなく、アーキテクチャ全体を簡素化することに着手しました。同時に、コスト効率の向上、インシデントの影響軽減、そしてエンジニアがより迅速に動くために必要なツールの提供を目指しました。
テスト、トライアル、POC（概念実証）を経て、OcadoはGrafana Cloudを選定しました。オープンスタンダードへのコミットメントを持つGrafanaは、メトリクス、ログ、トレース、負荷テスト、インシデント対応ツールを一つに統合できる数少ないプラットフォームでした。また、そのコストガバナンス機能は、同社の社内財務慣行ともよく合致していました。
New RelicからGrafana Cloudへの移行
大規模な移行を行うために、Ocadoは3つの主要な社内プラットフォームを活用しました：
- 開発者ポータルであるOcado Technology Platform (OTP) は、共有パイプラインとデプロイの自動化を提供しました。エンジニアはOTP設定やTerraformモジュールを通じてGrafana Cloudサービスに簡単にアクセスでき、一方でオブザーバビリティチームは変更を一元的に展開し、導入状況を監視できました。
- FinOpsフレームワークは、オブザーバビリティスタック全体からコストデータを集約し、個々のサービスにコストをマッピングして、最適化の機会を特定しました。リアルタイムのアラートが異常を知らせ、プラットフォームのレコメンデーションエンジンが、未使用データ、過剰なリソース、重複ツールの排除による節約の機会を提示しました。
- 組織データウェアハウスであるOT Dataは、Jira、GitLab、Workday、ServiceNowなどのシステムからの運用データを保存しました。チームはこれを使用してダッシュボードを作成し、移行のタイムラインを追跡し、成果を測定することで、エンジニアリングのリーダーシップ層がより多くの情報に基づいた意思決定を行えるようにしました。
この基盤が整ったところで、OcadoはOpenTelemetryとMicrometerをインストルメンテーション（計装）に使用し、New RelicからGrafana Cloudへのメトリクス移行を開始しました。New Relicのエージェントがアプリケーションコードに埋め込まれていたため、各チームは手動で変更を加える必要がありました。オブザーバビリティチームは、明確な移行ガイドの公開、一元化された設定オプションの提供、関係者との定期的なチェックインを通じてこれらの取り組みを支援しました。素早く移行したチームもあれば、新しいセットアップに自信が持てるまで両方のスタックを並行して稼働させたチームもありました。
ログの移行は異なるアプローチをとりました。以前は、70の異なる環境にプロビジョニングされたOpenSearchクラスターにログが転送されていました。OcadoはこれをFluent Bitサイドカーモデルに置き換え、各アプリケーションと一緒にデプロイされた軽量のロギングエージェントを使用して、Lokiを搭載したGrafana Cloud Logsに直接ログを転送するようにしました。
移行中のエンジニアをサポートするために、OcadoはLokiのクエリ言語とインターフェースを効果的に使用する方法に関するワークショップを開催しました。移行はアプリの再デプロイと紐付けられており、多くのアプリはパッチ適用やライブラリ更新のために頻繁にリリースされていたため、導入は迅速に進みました。一部の環境では、1日で50%以上のアプリが切り替わり、ほとんどの環境で2週間以内に完全な導入が完了しました。
統合のメリット
このような周到な計画があったとしても、移行には、初期のサポートリクエストの急増や特定のサービスでの異常に大きなログ行など、予期せぬ課題がありました。しかし、以下のメリットは、そうした成長の痛みをはるかに上回るものでした：
- アーキテクチャの簡素化: Ocadoは管理すべきシステムの数を大幅に削減し、OpenSearchクラスターや複数のベンダーパイプラインを維持するオーバーヘッドを排除しました。
- コスト削減: 統合により、ベンダーへの支出と重複するツールの削減において意味のある成果が得られました。Grafana Cloudの透明性の高い価格設定とFinOpsとの連携により、エンジニアリングリーダーは使用量を最適化し、投資を正当化するための実質的な手段を得ました。
- トラブルシューティングの迅速化: ログ、メトリクス、トレースが一元化されたことで、エンジニアはインターフェースを切り替えたり検索クエリを再作成したりする時間を無駄にすることがなくなりました。統合されたワークフローにより、チームは問題により迅速に対応し、解決までのMTTR（平均特定時間）を短縮できました。
- 開発者のエンパワーメント: エンジニアは、断片化されたインターフェースではなく、共有された最新のツールキットを利用できるようになりました。多くのエンジニアがすでにGrafanaの機械学習ベースのアラートを試し、ユーザーに影響が出る前に異常を検知しようとしています。
- 将来を見据えたスタック: クローズドソースのエージェントを排除し、OpenTelemetryとMicrometerに標準化することで、Ocadoは長期的な柔軟性を手に入れました。特定のベンダーの実装に依存することなく、オブザーバビリティ戦略を進化させることができます。
「すべてのシグナルが一箇所にあることは、ユーザーにとって非常に簡単で便利です」とWierzba氏は言います。「私たちはエンジニアに対し、受動的な消火活動ではなく、よりプロアクティブ（能動的）に行動できるよう権限を与えました。」
今後の展望
Ocadoは現在、インシデント対応をPagerDutyからGrafana Cloud IRMへ移行中です。また、ログに使用したFluent Bitサイドカーモデルが、メトリクスに関するアーキテクチャの複雑さを排除するのにも役立つかどうかを検討しています。
OcadoのGrafana Cloudへの移行は、ベンダーの乱立を減らす方法として始まりました。それは同社にとって、大規模な運用、迅速な動き、そして独自の条件でオブザーバビリティの未来を築くための新たな始まりとなりました。
「これは私たちの旅の終わりではありません」とWierzba氏は語ります。「実際には最初の一歩です。私たちは現在、Grafanaと協力して、さらに活用し、より多くの価値を引き出すために何ができるかを模索しています。」
Grafana Cloudは、メトリクス、ログ、トレース、ダッシュボードなどを始めるための最も簡単な方法です。充実した永年無料枠と、あらゆるユースケースに対応するプランをご用意しています。今すぐ無料でアカウントを作成する