서버 부팅 4시간 → 3분, 클라우드플레어의 UEFI 네트워크 부팅 최적화 전략

들어가며: 펌웨어 업데이트가 만든 4시간의 악몽

클라우드플레어의 코어 서버는 전 세계에 분산된 엣지(Edge)와 달리 중앙 데이터 센터에서 제어 플레인(Control Plane), 빌링(Billing), 분석(Analytics)과 같은 핵심 역할을 담당합니다. 이들은 대부분 베어메탈(Bare Metal) 서버로, 부팅 과정은 UEFI(Unified Extensible Firmware Interface)가 하드웨어를 초기화하고 운영체제에 제어권을 넘기는 표준 방식을 따릅니다.

문제는 일상적인 펌웨어 업데이트 이후 발생했습니다. 업데이트를 마친 일부 코어 서버의 부팅 시간이 기존 '수 분'에서 '4시간'으로 늘어난 것입니다. 당연히 예정된 하루짜리 업데이트 작업이 며칠로 늘어졌고, 엔지니어들은 자동화되어야 할 업그레이드 과정을 하염없이 지켜봐야 했습니다. 단순한 펌웨어 회귀(Regression) 버그를 의심했지만, 실제 원인은 더 근본적이었습니다.

이 글에서는 부팅 시간을 지연시킨 'UEFI 네트워크 부팅 인터페이스의 순차 탐색' 문제를 추적하고, 이를 해결하기 위해 적용한 전략을 단계별로 공유합니다. 특히 단순히 iPXE 설정 몇 줄 바꾼 수준이 아니라, 벤더와의 협업부터 내부 도구 개발까지 포함된 종합적인 접근이었다는 점을 강조하고 싶습니다.

참고자료: 이 글의 내용은 클라우드플레어 공식 블로그의 사례 연구를 기반으로 작성했습니다.

본론 1: 문제의 핵심, 부팅 인터페이스의 '순차 탐색'

PXE와 UEFI HTTPS 부팅, 왜 여러 개가 필요할까?

서버가 네트워크를 통해 운영체제를 부팅하는 방식은 크게 두 가지입니다. 첫째는 전통적인 PXE(Preboot Execution Environment) 방식이고, 둘째는 보안이 강화된 UEFI HTTPS 부팅 방식입니다. 클라우드플레어는 오픈소스 네트워크 부팅 펌웨어인 iPXE를 사용하여 이 두 방식을 모두 지원하고, 하드웨어 구성에 따라 적절한 인터페이스를 선택합니다.

문제는 이 '선택' 과정에 있었습니다. 부팅 시 서버가 사용 가능한 모든 네트워크 부팅 인터페이스를 하나씩 시도하고, 각 시도가 실패할 때까지 약 5분간 대기한 후 다음 인터페이스로 넘어가는 방식이었습니다.

# 부팅 시도 순서 (문제 발생 상황)
[1] IPv4 HTTPS 부팅 시도 → 5분 대기 후 실패
[2] IPv4 iPXE 부팅 시도 → 5분 대기 후 실패
[3] IPv6 HTTPS 부팅 시도 → 5분 대기 후 실패
[4] IPv6 iPXE 부팅 시도 → 5분 대기 후 실패
[5] 올바른 인터페이스 도달 (예: 특정 NIC의 HTTPS 부팅)

# 총 소요 시간: 약 20분 (단순 부팅 시)

단순 부팅 한 번에 20분이 소요되는 것은 치명적입니다. 더 큰 문제는 펌웨어 업그레이드 자동화입니다. 부팅 순서를 개선하기 전에는 펌웨어 업그레이드가 여러 번의 재부팅을 필요로 했고, 각 재부팅마다 위와 같은 20분의 시간이 소요되었습니다. 그 결과 총 업그레이드 시간이 약 4시간에 달했던 것입니다.

본론 2: 해결책, '선언적 부팅 순서'와 자동화 도구

1. 부팅 자동화 워크플로우 재구성

클라우드플레어의 부팅 자동화는 펌웨어 초기화 → 사전 부팅(PXE) → 커널 시작의 3단계로 나뉩니다. 문제가 발생한 지점은 사전 부팅 단계에서 네트워크 인터페이스를 탐색하는 부분이었습니다. 이를 해결하기 위해 하드웨어와 사용 사례에 맞는 정확한 부팅 인터페이스 순서를 사전에 선언하도록 워크플로우를 변경했습니다.

이를 위해 두 가지 제약을 극복해야 했습니다.

• 레거시 지원 문제: 오래된 UEFI 버전은 부팅 순서 설정을 지원하지 않습니다.
• 설정 휘발성 문제: UEFI 펌웨어 업그레이드 시 설정값이 초기화될 수 있습니다.

이를 해결하기 위해 상태 검증 단계(State Validation) 를 도입했습니다. 펌웨어 자동화는 설정 변경 후 이를 검증하고, 만약 설정이 리셋되었다면 다시 적용하고 재부팅을 트리거합니다. 첫 부팅은 조금 느릴 수 있지만, 이후 모든 부팅은 20분에서 1분 미만으로 단축됩니다.

2. 벤더 잠금 해제: 숨겨진 설정 찾기

문제를 더 깊이 파고들자, 벤더가 제공하는 UEFI 설정 중 'Force Priority Httpv4 Httpv6 Pxev4 Pxev6' 라는 불변(Immutable) 값이 부팅 순서 변경을 막고 있었습니다. 이 설정은 EFI_IFR_REF3 데이터 구조로 저장되는데, 이 구조는 지연 로딩(Lazy Loading) 방식이라 프로그램적으로 접근하기 전까지 BIOS 설정 화면에 나타나지 않았습니다.

// UEFI 네트워크 부팅 설정의 내부 데이터 구조
// (이 구조는 GUI 콜백을 통해서만 초기화됨)
typedef struct _EFI_IFR_REF3 {
  EFI_IFR_OP_HEADER Header;
  EFI_IFR_QUESTION_HEADER Question;
  EFI_QUESTION_ID QuestionId;
  EFI_GUID FormSetId;
} EFI_IFR_REF3;

클라우드플레어는 벤더와 협력하여 'Boot Order Module' 내 특정 토큰을 활성화함으로써, GUI 없이도 네트워크 부팅 인터페이스를 자동으로 감지하고 순서를 변경할 수 있게 했습니다.

3. NIC 벤더별 문자열 차이 극복

부팅 순서를 iPXE에서 설정할 때 또 다른 문제가 발생했습니다. 네트워크 인터페이스 카드(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

이를 통해 전체 문자열을 몰라도 프로토콜, 전송 방식, 포트 번호, 물리적 슬롯 인덱스만으로 올바른 부팅 인터페이스를 선택할 수 있게 되었습니다. 현재는 벤더와 협력하여 MAC 주소 같은 제품 세부 정보를 제거하고 표준화된 문자열만 사용하도록 노력 중입니다.

4. iPXE 설정 검증 문제: HEX 비교

iPXE는 UEFI 변수를 HEX 값으로 읽기 때문에 설정이 올바르게 적용되었는지 확인하기 어려웠습니다. 이 문제를 해결하기 위해 uefi-same-hex라는 불리언 플래그를 구현했습니다.

# iPXE 스크립트: 설정 변경 및 검증 자동화
# 설정 변경 후 변경 여부를 확인하여 재부팅 여부를 결정

# 설정 변경 명령 실행
imgexecset ${uefi-setting}=${uefi-value}

# 변경된 변수와 기대값을 비교하여 변경 확인
# 변경되었다면 로컬 변수에 재부팅 신호를 설정
iseq ${uefi-same-hex} ${${var-upd-path}} || set has-changed ${uefi-diff-hex}

이 플래그를 통해 매번 show 명령으로 변수를 출력하고 비교하는 대신, 단 한 번의 set 명령으로 설정과 검증을 동시에 수행할 수 있게 되어 부팅 시간을 더욱 단축했습니다.

본론 3: 결과 및 주의사항

개선 효과: 4시간 → 3분

이 결과는 단순히 iPXE 설정 몇 줄을 바꾼 것이 아니라, UEFI 내부 구조에 대한 깊은 이해, 벤더와의 협업, 그리고 자동화 도구 개발까지 포함된 종합적인 노력의 결과입니다.

주의사항 및 한계

• 벤더 의존성: 이 문제를 해결하는 과정에서 특정 하드웨어 벤더의 UEFI 펌웨어 수정이 필요했습니다. 모든 환경에서 동일한 방식으로 해결될 수는 없습니다.
• 초기 설정 시간: 상태 검증 단계로 인해 첫 부팅은 이전보다 약간 더 오래 걸릴 수 있습니다.
• 정규식 매칭의 위험성: .*HTTP.*IPv4.*P1 같은 와일드카드 매칭은 설정이 잘못된 인터페이스와 매칭될 가능성이 있습니다. 지속적인 표준화 노력이 필요합니다.

결론 및 다음 단계

클라우드플레어의 사례는 베어메탈 서버를 운영할 때 '부팅 시간'이 단순한 대기 시간이 아니라, 운영 효율성과 직결되는 중요한 최적화 대상임을 보여줍니다. 특히 펌웨어 업데이트처럼 여러 번의 재부팅이 필요한 작업에서는 부팅 시간이 전체 작업 시간을 좌우할 수 있습니다.

이 글에서 다룬 핵심은 '무작정 기다리는 대신, 부팅 인터페이스를 선언적으로 제어하자'는 것입니다. 이 개념은 클라우드플레어의 인프라뿐 아니라, 베어메탈 서버를 다루는 모든 환경에서 유용하게 적용될 수 있습니다.

다음 단계로 추천하는 학습 방향:

1. iPXE 스크립팅 심화: 공식 문서를 통해 다양한 부팅 시나리오와 스크립트 작성법을 익혀보세요.
2. UEFI 내부 구조 학습: EFI_IFR_REF3와 같은 데이터 구조를 이해하면 벤더 잠금 문제를 더 쉽게 해결할 수 있습니다.
3. 부팅 자동화 도구 구축: 이 글에서 소개된 CfHIIConfig_App처럼 자체 설정 도구를 만들어 보는 것도 좋은 연습이 됩니다.

함께 보면 좋은 글:

• AWS 유럽 소버린 클라우드, 디지털 주권을 위한 교차 파티션 장애 조치 설계 가이드
• 넷플릭스 MAPS 멀티모달 임베딩으로 콜드 스타트를 정복한 추천 시스템의 진화