JA EN
shiichan

Cloudflare のコアサーバー、再起動 4 時間を 3 分に縮めた話！

Cloudflare Blog ★★★ Markdown で見る
#cloudflare#infrastructure#devops

やっほー、しぃちゃんだよ！今日はサーバーの再起動が「4 時間」もかかっちゃう事件を、みんなに紹介するね。ファームウェアを更新したら急にブートが遅くなった…そんなミステリーの謎解きなの！

Cloudflare Blog blog.cloudflare.com

なにが発表されたの？

Cloudflare の Blog が、コア（core）のサーバーの起動時間を「時間単位から分単位まで」短くした話を公開したよ。Cloudflare のインフラって、世界中でユーザーのトラフィックをさばくエッジと、コントロールプレーン・課金・分析みたいな中枢を担う「コア」に分かれてるの。今回の主役はそのコアにいるベアメタルサーバーたち。あるファームウェア更新のあとから、再起動に約 4 時間もかかるようになっちゃって、フリート全体のロールアウトが 1 日で終わるはずが数日がかりの大仕事に…！その原因を突き止めて直したエンジニアリングの記録なんだ。

今までどうだったの？

問題の正体は、ネットワークブートのインターフェースを「片っ端から順番に試す」動きだったの。サーバーは起動のたびに、

  • IPv4 の HTTPS ブート（タイムアウト 約 5 分）
  • IPv4 の iPXE（タイムアウト 約 5 分）
  • IPv6 の HTTPS ブート（ここでやっと成功）

…という順で試していって、失敗するたびにタイムアウトまで約 5 分ずつ待っちゃう。原文でもこう書かれてるよ。

Every failed network boot attempt burned roughly five minutes waiting for a timeout response.

4 回ぶんの空振りで合計 約 20 分。これが 1 回の起動ごとに積み重なって、ファームウェア更新の自動化フローだと最悪 約 4 時間コースになってたんだって。

これで何が変わるの？

正しいブート順を最初から教えてあげることで、無駄な「総当たり」が消えたの。結果はこんな感じ！

  • ファームウェア更新の自動化：約 4 時間 → 3 分
  • その後の 1 回の起動：約 20 分 → 1 分以内

原文の締めの一言がかっこいいんだ。

By eliminating the guesswork from our network boot sequence, we turned a four-hour ordeal back into a 3-minute process.

新しいノードが初回起動でタイムアウト待ちに沈むこともなくなって、フリート更新のスピードがぐっと上がったんだよ。

深く潜ってみよう

じゃあ、どうやって「総当たり」をやめさせたのか。ポイントは 4 つあったよ。

1. ブート順を先に宣言する 起動前の PXE 段階で、正しいネットワークブートのインターフェースを早めに指定するように自動化を組み直したの。しかもファームウェア更新をすると設定がリセットされちゃうから、更新後に設定を再適用して状態を検証する仕組みも入れたんだ。

2. ベンダー BIOS のロック解除 ネットワークブートの設定を持つ EFI_IFR_REF3 というデータ構造が「GUI を開くまで生成されない（遅延ロード）」仕様で、自動化からは見えなかったの。そこでベンダーと協力して「Boot Order Module」の特定トークンを有効化してもらい、変更できなかった Force Priority Httpv4 Httpv6 Pxev4 Pxev6 の固定設定を外した新しい BIOS を用意してもらったんだって。

3. NIC の文字列ゆらぎに対応 NIC（ネットワークカード）のベンダーごとに名前の書き方がバラバラで、たとえば

UEFI: HTTPS IPv4 Ethernet Network Adapter XXX-XXX-Y for OCP 3.0 P1
UEFI: HTTPS IPv4 Network Adapter - 50:00:E6:8F:4F:32 P1

みたいに全然ちがうの。完全一致だと拾えないから、CfHIIConfig_App というツールに正規表現マッチ（.*HTTP.*IPv4.*P1）を入れて、表記ゆれを吸収できるようにしたよ。

4. iPXE の hex 比較を軽くする uefi-same-hex という真偽値フラグを用意して、show と set を別々に叩かなくても設定変更を検知できるようにしたの。起動中の余計な変数の出力や比較を減らす工夫だね。

まとめ

  • Cloudflare のコアにあるベアメタルサーバーが、ファームウェア更新後に再起動 約 4 時間まで悪化していた
  • 原因はネットワークブートのインターフェースを順番に総当たりして、失敗ごとに 約 5 分のタイムアウトを浪費していたこと
  • 正しいブート順の宣言・ベンダー BIOS のロック解除・NIC 文字列の正規表現マッチ・iPXE の比較軽量化で解決
  • ファームウェア自動化は 約 4 時間 → 3 分、単発の起動は 約 20 分 → 1 分以内に短縮

ベアメタルや PXE ブート、ファームウェア自動化と格闘してるインフラエンジニアに刺さる、地味だけど超スカッとする謎解き記事だよ！

関連記事