How we reduced core unit boot time from hours to minutes

🖼️ 인포그래픽

How we reduced core unit boot time from hours to minutes 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

클라우드플레어는 코어 서버가 네트워크 부팅 인터페이스를 순차적으로 탐색하느라 재부팅마다 긴 타임아웃을 겪던 문제를, 올바른 부팅 인터페이스를 사전에 선언하고 펌웨어·벤더 제약을 자동화로 처리해 수시간 걸리던 부팅·업그레이드를 수분 수준으로 줄였다.

📌 핵심 요약

클라우드플레어의 코어 서버는 제어 평면, 과금, 분석을 담당하는 중앙 데이터센터의 베어메탈 장비이며, 펌웨어 업데이트 이후 일부 장비가 기존처럼 몇 분 안에 돌아오지 못하고 최대 네 시간 가까이 지연되는 문제가 발생했다.
조사 결과 서버는 실제로 성공할 네트워크 부팅 인터페이스에 도달하기 전까지 IPv4 HTTPS, IPv4 iPXE 등 실패할 인터페이스를 순서대로 시도했고, 각 시도마다 수분씩 타임아웃을 기다리면서 단일 부팅에 약 20분의 낭비가 누적되고 있었다.
펌웨어 업그레이드 자동화는 여러 구성요소마다 순차 재부팅을 요구했기 때문에, 이 20분짜리 지연이 반복되어 전체 업그레이드 시간이 거의 네 시간까지 늘어났다.
해결의 핵심은 부팅 과정에서 추측과 선형 탐색을 없애고, 하드웨어와 사용 사례별로 올바른 네트워크 부팅 인터페이스 순서를 사전에 선언하도록 자동화 흐름을 바꾸는 것이었다.
이 과정에서 오래된 UEFI의 부팅 순서 미지원, 펌웨어 업그레이드 후 설정 초기화, 벤더의 비활성화된 설정, NIC 벤더별 문자열 차이, iPXE의 HEX 변수 처리 문제를 각각 우회하거나 자동화해 최종적으로 펌웨어 업그레이드는 약 3분, 이후 단일 부팅은 1분 미만으로 줄었다.

🧩 주요 포인트

클라우드플레어의 코어 서버는 제어 평면, 과금, 분석을 담당하는 중앙 데이터센터의 베어메탈 장비이며, 펌웨어 업데이트 이후 일부 장비가 기존처럼 몇 분 안에 돌아오지 못하고 최대 네 시간 가까이 지연되는 문제가 발생했다.
조사 결과 서버는 실제로 성공할 네트워크 부팅 인터페이스에 도달하기 전까지 IPv4 HTTPS, IPv4 iPXE 등 실패할 인터페이스를 순서대로 시도했고, 각 시도마다 수분씩 타임아웃을 기다리면서 단일 부팅에 약 20분의 낭비가 누적되고 있었다.
펌웨어 업그레이드 자동화는 여러 구성요소마다 순차 재부팅을 요구했기 때문에, 이 20분짜리 지연이 반복되어 전체 업그레이드 시간이 거의 네 시간까지 늘어났다.
해결의 핵심은 부팅 과정에서 추측과 선형 탐색을 없애고, 하드웨어와 사용 사례별로 올바른 네트워크 부팅 인터페이스 순서를 사전에 선언하도록 자동화 흐름을 바꾸는 것이었다.
이 과정에서 오래된 UEFI의 부팅 순서 미지원, 펌웨어 업그레이드 후 설정 초기화, 벤더의 비활성화된 설정, NIC 벤더별 문자열 차이, iPXE의 HEX 변수 처리 문제를 각각 우회하거나 자동화해 최종적으로 펌웨어 업그레이드는 약 3분, 이후 단일 부팅은 1분 미만으로 줄었다.

🧠 상세 정리

1. 코어 서버 부팅 지연의 배경

클라우드플레어의 코어는 사용자 트래픽을 처리하는 전 세계 엣지와 달리 제어 평면, 과금, 분석 같은 중앙 기능을 담당하는 데이터센터 환경이다. 이 서버들은 베어메탈 장비이기 때문에 재부팅 중 문제가 생기면 단일 서버의 지연을 넘어 운영 절차와 유지보수 일정 전체에 영향을 줄 수 있다. 문제가 드러난 계기는 일상적인 펌웨어 업데이트였고, 일부 서버가 원래처럼 몇 분 안에 온라인 상태로 돌아오지 않고 네 시간가량 걸리는 현상이 발생했다. 특히 오랫동안 꺼져 있던 노드들은 펌웨어가 오래되어 여러 번 업데이트가 필요했고, 여기에 일부 위치에서 사용되는 부팅 프로토콜 변화가 겹치며 지연이 더 크게 나타났다.

2. 네트워크 부팅과 iPXE의 역할

네트워크 부팅 인터페이스는 서버가 로컬 저장장치 대신 네트워크를 통해 운영체제를 시작할 수 있게 하는 방식이다. 클라우드플레어처럼 다양한 위치와 목적의 서버를 대규모로 운영하는 환경에서는 중앙화된 자동화와 확장 가능한 시작 절차가 중요하므로, 네트워크 부팅은 필수적인 기반이 된다. 글에서는 주요 방식으로 PXE와 UEFI HTTPS 부팅을 설명하며, 클라우드플레어는 자동화상의 이유로 일반적으로 PXE 경로를 활용한다고 밝힌다. 또한 오픈소스 iPXE를 사용해 HTTP와 HTTPS 같은 현대적 프로토콜로 운영체제 이미지를 가져오고, 부팅 과정을 스크립트 가능한 워크플로로 다룰 수 있게 했다.

3. 초기 가설과 실제 관찰

첫 보고는 서버가 온라인으로 돌아오지 않는다는 내부 알림과, 장비가 운영체제 이전 단계에 오래 머물러 있다는 모니터링 결과에서 시작됐다. 처음에는 펌웨어 업데이트 자체가 부팅 과정을 멈추게 하는 회귀 버그를 만들었을 가능성을 의심했다. 이를 확인하기 위해 영향을 받은 장비의 시리얼 콘솔에서 부팅 과정을 직접 관찰했고, 전원 인가 후 자기 진단과 하드웨어 초기화는 정상적으로 완료되는 것을 확인했다. 문제는 그 다음 단계에서 발생했으며, 서버는 운영체제 이미지를 빠르게 가져오지 못한 채 네트워크 부팅 시도를 반복하며 기다리고 있었다.

4. 선형 탐색이 만든 20분 지연

콘솔 출력은 서버가 올바른 인터페이스를 바로 사용하지 못하고 여러 네트워크 부팅 인터페이스를 순서대로 시도하고 있음을 보여주었다. 시스템은 IPv4 HTTPS 부팅을 시도하다가 몇 분 뒤 타임아웃되고, 다시 IPv4 iPXE를 시도해 또 타임아웃된 뒤, 같은 과정을 반복한 다음에야 실제로 성공할 IPv6 HTTPS 부팅 인터페이스에 도달했다. 실패한 네트워크 부팅 시도 하나마다 약 5분이 소모되었고, 올바른 인터페이스에 도달하기 전 네 번의 실패가 쌓이면서 단일 부팅 주기마다 약 20분이 낭비됐다. 일반 재부팅에서도 큰 손실이지만, 여러 펌웨어 구성요소마다 순차 재부팅이 필요한 자동화에서는 이 지연이 누적되어 거의 네 시간의 대기 시간이 되었다.

5. 올바른 부팅 인터페이스를 사전에 선언하는 전략

근본 원인은 서버가 사용 가능한 네트워크 부팅 인터페이스를 모두 순차적으로 탐색하며 실패를 기다리는 데 있었다. 따라서 해결 방향은 추측을 없애고, 각 하드웨어와 사용 사례에 맞는 올바른 부팅 인터페이스 순서를 사전에 지정하는 것이었다. 클라우드플레어의 부팅 자동화는 펌웨어 초기화, 프리부트, 커널 시작의 큰 단계로 구성되며, 네트워크 인터페이스 탐색은 PXE 기반 프리부트 단계에서 일어났다. 자동화 흐름을 재구성해 이 단계 초기에 올바른 네트워크 부팅 인터페이스 순서를 선언함으로써, 각 펌웨어 업그레이드마다 반복되던 20분 탐색 비용을 제거하고 전체 시간을 크게 줄일 수 있었다.

6. UEFI 설정 지속성과 구형 지원 문제

부팅 순서를 선언하는 방식은 단순해 보였지만 실제 적용에는 두 가지 제약이 있었다. 첫째, 오래된 UEFI 버전에서는 부팅 순서 지정 기능이 지원되지 않았고, 둘째, UEFI 펌웨어 업그레이드 이후 설정값이 초기화되는 경우가 있었다. 이 때문에 한 번 설정했다고 끝나는 방식으로는 안정적인 자동화가 어려웠다. 클라우드플레어는 설정 변경 뒤 상태를 검증하는 단계를 추가해, 설정이 바뀌었거나 사라졌다고 판단되면 구성을 다시 적용하고 재부팅을 유도하도록 했다. 첫 부팅은 약간 길어질 수 있지만, 이후 부팅에서는 약 20분 걸리던 과정을 1분 미만으로 줄이는 효과가 있었다.

7. 벤더별 펌웨어 제약과 숨겨진 설정

또 다른 장애물은 네트워크 부팅 설정의 내부 데이터 구조가 지연 로딩되는 방식으로 구현되어 있었다는 점이다. 해당 설정은 EFI_IFR_REF3 구조와 관련되어 있었고, 일반적인 BIOS 부팅 시간을 줄이기 위해 GUI 콜백을 통해 명시적으로 접근되기 전까지는 데이터가 실제로 준비되지 않았다. 이 방식 자체는 업계에서 쓰이는 관행이지만, 자동화 도구가 네트워크 부팅 인터페이스 우선순위를 프로그램적으로 탐색하지 못하게 만들었다. 클라우드플레어는 장비 벤더와 협력해 고정된 부팅 순서 모듈 안의 특정 토큰을 활성화했고, 수동 GUI 조작 없이 부팅 과정에서 네트워크 부팅 인터페이스를 발견할 수 있도록 했다. 또한 변경을 막던 고정 우선순위 설정 때문에 새 BIOS 버전과 디버그 세션도 필요했다.

8. NIC 문자열 차이와 iPXE 변수 처리 개선

NIC 벤더에 따라 네트워크 부팅 인터페이스를 나타내는 문자열 형식이 서로 달랐던 것도 자동화의 불안정성을 키웠다. 어떤 문자열은 어댑터 모델이나 슬롯 정보를 포함했고, 다른 문자열은 MAC 주소 같은 제품별 세부 정보를 포함해 동일한 의도를 가진 설정도 서로 다르게 표현됐다. 이를 우회하기 위해 CfHIIConfig_App 도구에 전체 문자열 없이도 패턴으로 설정을 지정할 수 있는 기능을 추가했고, 예를 들어 프로토콜, IPv4, 포트 정보를 포함한 패턴을 허용해 적절한 부팅 순서를 선택하게 했다. 동시에 iPXE가 관련 변수를 HEX로 읽는 특성 때문에, 설정 변경 여부를 확인하기 위한 불리언 플래그를 도입했다. 이로써 매번 변수를 출력하고 비교한 뒤 설정하는 과정을 줄이고, 단일 설정 명령과 변경 여부 판단만으로 더 빠른 흐름을 만들었다.

9. 결과와 운영상 의미

최종 결과는 네트워크 부팅 과정에서 불필요한 탐색을 제거해 수시간 걸리던 절차를 수분 단위로 되돌린 것이다. 펌웨어 업그레이드 자동화는 거의 네 시간에서 약 3분으로 줄었고, 이후 단일 부팅은 약 20분에서 1분 미만으로 감소했다. 이 변화는 수동 BIOS 조작 없이 기존 릴리스 파이프라인과 iPXE 기반 워크플로 안에서 구성 업데이트를 확장 배포할 수 있게 했다는 점에서도 중요하다. 글은 이 성과가 UEFI 내부 동작을 깊이 파악하고, OEM 벤더와 협력해 프로그램적 부팅 순서 제어를 가능하게 하며, iPXE 같은 오픈소스 도구를 자동화 기반으로 활용한 결과라고 정리한다. 베어메탈 인프라를 운영하는 조직이라면 느린 부팅 문제를 단순한 펌웨어 지연으로만 보지 말고, 실패하는 네트워크 부팅 경로와 타임아웃 누적을 구체적으로 추적할 필요가 있음을 보여준다.

🧾 핵심 주장 / 시사점

대규모 베어메탈 운영에서 부팅 지연은 단일 장비 문제가 아니라 펌웨어 업그레이드, 유지보수 창, 자동화 신뢰성 전체를 흔드는 병목이 될 수 있다.
문제 해결의 핵심은 더 빠른 하드웨어를 쓰는 것이 아니라, 실패할 경로를 반복해서 기다리는 선형 탐색을 제거하고 의도한 부팅 경로를 명시적으로 선언하는 데 있었다.
펌웨어 자동화는 표준 인터페이스만으로 끝나지 않으며, 벤더별 UEFI 구현, 지연 로딩된 설정, 문자열 형식 차이, 설정 지속성까지 검증해야 실제 운영 환경에서 안정적으로 작동한다.

✅ 액션 아이템

부팅 실패를 유발한 IPv4 HTTPS·IPv4 iPXE의 순차 탐색을 제거하고, 하드웨어·용도별 정답 부팅 인터페이스 순서를 사전 선언하는 자동화를 구축한다.
펌웨어 업그레이드가 구성요소별 순차 재부팅을 반복할 때 누적되는 20분 지연을 막기 위해 각 재시작 구간의 인터페이스 타임아웃 상한과 성공 판정 조건을 점검한다.
UEFI 미지원 부팅순서, 설정 초기화, 비활성 벤더 설정, NIC 문자열 편차, iPXE HEX 처리까지 커버하도록 예외맵을 자동화에 반영해 업그레이드는 3분, 단일 부팅은 1분 미만 기준으로 맞춘다.