1768643581
2026-01-17 09:30:00
最近のクラウドフレア 共有 巨大な世界的フリートをどのように管理しているか ソルトスタック （塩）。彼らは、「砂粒」問題に必要なエンジニアリングのタスクについて話し合いました。この懸念は、何百万もの状態アプリケーションの中から 1 つの構成エラーを見つけることに関するものです。クラウドフレアの サイト信頼性エンジニアリング (SRE) チームは、構成の可観測性を再設計しました。彼らは失敗を展開イベントに結び付けました。この取り組みにより、リリースの遅延が 5% 以上減少し、手動によるトリアージ作業が減少しました。
構成管理 (CM) ツールとして、Salt は、数百のデータセンターにわたる数千のサーバーが望ましい状態に維持されることを保証します。 Cloudflareの規模では、YAMLファイル内の軽微な構文エラーや「Highstate」実行中の一時的なネットワーク障害でも、ソフトウェアのリリースが停止する可能性があります。
Cloudflareが直面した主な問題は、意図した構成と実際のシステム状態の間の「ずれ」でした。 Salt の実行が失敗した場合、影響を受けるのは 1 つのサーバーだけではありません。エッジ ネットワーク全体にわたる重要なセキュリティ パッチやパフォーマンス機能の展開を妨げる可能性があります。
塩は、 マスター/ミニオンの設定 と ゼロMQ。このため、特定のミニオン (エージェント) がそのステータスをマスターに報告しなかった理由を見つけることが困難になります。それは干し草の山から針を探すようなものです。 Cloudflareは、このフィードバックループを壊すいくつかの一般的な障害モードを特定しました。
- サイレント障害: ミニオンは状態の適用中にクラッシュまたはハングし、マスターが応答を無期限に待機したままになる可能性があります。
- リソースの枯渇: 大量のピラー データ (メタデータ) ルックアップや複雑な Jinja2 テンプレートは、マスターの CPU やメモリに負荷を与え、ジョブのドロップにつながる可能性があります。
- 依存地獄: 上流のリポジトリに到達できないためにパッケージの状態が失敗する可能性がありますが、エラー メッセージは数千行のログの奥深くに埋もれている可能性があります。
ソルトアーキテクチャ図
エラーが発生した場合、SRE エンジニアは候補ミニオンに手動で SSH 接続する必要がありました。彼らはマスター間でジョブ ID を追跡し、保持期間が限られていたログを選別しました。次に、彼らはそのエラーを変化や環境条件に関連付けようとしました。数千台のマシンと頻繁なコミットにより、プロセスは退屈で保守が困難になりました。それは永続的な工学的価値をほとんど提供しませんでした。
これらの課題に対処するために、CloudflareのビジネスインテリジェンスチームとSREチームが協力して新しい内部フレームワークを構築しました。目標は、サーバー、データセンター、特定のマシングループにわたる Salt 障害の根本原因を特定するための「セルフサービス」メカニズムをエンジニアに提供することでした。
- Git コミット: 構成リポジトリ内のどの変更が失敗の原因となったかを正確に特定します。
- 外部サービスの障害: Salt 障害が実際に依存関係 (DNS 障害やサードパーティ API の停止など) によって引き起こされたかどうかを判断します。
- アドホックリリース: スケジュールされたグローバル更新と開発者による手動の変更を区別します。
Cloudflareは、自動トリアージの基盤を構築することで、インフラストラクチャ障害の管理方法を変えました。システムは、リリースのブロックを引き起こしている特定の「砂粒」、コードの 1 行、または 1 つのサーバーに自動的にフラグを立てることができるようになりました。
事後対応型管理から事前対応型管理への移行により、次のような結果が得られました。
- リリース遅延の 5% 削減: エラーをより早く発見することで、「コードが完了」してから「エッジで実行」までの時間が短縮されました。
- 労力の削減: SRE は「反復的なトリアージ」に何時間も費やすことがなくなり、より高いレベルのアーキテクチャの改善に集中できるようになりました。
- 監査可能性の向上: Git PR からエッジ サーバーでの最終実行結果まで、ライフサイクル全体を通じてすべての構成変更を追跡できるようになりました。
Cloudflareエンジニアリングチームは、Saltは強力なツールである一方で、それを「インターネット規模」で管理するには、よりスマートな可観測性が必要であることに気づきました。構成管理を、相関関係と自動分析が必要な重要なデータの問題とみなすことで、他の大規模なインフラストラクチャ プロバイダーに模範を示しました。
Cloudflare が SaltStack で遭遇した課題に基づいて、次のような代替構成管理ツールが利用できることは注目に値します。 アンシブル、 人形、 そして シェフ それぞれが異なるアーキテクチャ上のトレードオフをもたらします。 Ansible は、SSH を使用するエージェントなしで動作します。これにより、Salt のマスター/ミニオンのセットアップよりも簡単になります。ただし、順次実行するため、大規模な場合はパフォーマンスの問題に直面する可能性があります。 Puppet はプルベースのモデルを使用し、エージェントがマスターサーバーにチェックインします。これにより、リソースの使用がより予測可能になりますが、Salt のプッシュ モデルに比べて緊急の変更が遅くなる可能性があります。 Chef もエージェントを使用しますが、Ruby DSL を使用したコード駆動型のアプローチに重点を置いています。これにより、複雑なタスクに対する柔軟性が高まりますが、学習曲線はより急になります。
Cloudflare の規模では、すべてのツールが独自の「砂粒」問題に遭遇します。ただし、重要な教訓は明らかです。何千ものサーバーを管理するシステムには堅牢な可観測性が必要です。また、コード変更と障害の関連付けを自動化し、スマートな優先順位付けメカニズムを備えている必要があります。これにより、手動による調査作業が実用的な洞察に変わります。
#CloudflareはSalt構成管理のデバッグを自動化しリリース遅延を削減します