# CircleCI [[Honeycomb.io]] が長年利用してきたCI/CDオーケストレーションプロバイダ。`Observability Engineering` 第2版 第18章のケーススタディの中心的な計測基盤として登場する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]]) **buildevents計装**: Honeycombは自社開発のレガシーツール `buildevents` でCircleCIのジョブ・ステップレベルのトレースを取得し、真のボトルネックがテストではなくバイナリビルド・成果物アップロード段階(中間ステップ間で約3.5GBのデータがgzip転送)にあることを特定した。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] "History of Improving Build Times at Honeycomb", "Build steps and data transfer") **Docker Layer Caching(DLC)の限界**: CircleCI built-inのDocker Layer Cachingは、CircleCIワークスペース経由のオブジェクトストレージ転送が遅く、期待したほどの高速化効果が出なかった。圧縮・解凍を伴う無差別なキャッシュデータの転送は、ゼロから状態を作り直すより遅い場合があったという。この経験からHoneycombは Docker Bake による単一ステップでの並列ビルドへ移行した。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] "Parallel builds") **machine executorへの移行**: 個別のCircleCIジョブ(Docker executor)で実行していたステップを、単一のCircleCI machine executor上でのDocker Bakeへ移行することで、Honeycombはビルド時間の「床」(理論的な最短時間)を確立した。テストは引き続きCircleCIの並列テストシャーディングヘルパーを使う標準の並列ランナー上で実行される。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] "Removing bottlenecks") ## 関連 - 実体: [[Honeycomb.io]](利用企業) / [[Docker]](Docker Bake移行先) / [[GitHub Actions]](競合CI/CDプラットフォーム) - 概念: [[CI-CDオブザーバビリティ|CI/CDオブザーバビリティ]] / [[アムダールの法則]](並列化限界の顕在化) - ソース: [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]] ## 出典 - [[@2026__OReilly__Observability Engineering 2E - Chapter 18 Observability for CI-CD Pipelines]]("History of Improving Build Times at Honeycomb" 〜 "Results")