본문으로 건너뛰기
J
0
r/jeffnews • HN • • 약 4분

Cloudflare Gen 13 서버: 캐시를 코어로 바꿔 성능 2배 달성한 이야기

backend

요약

Cloudflare가 AMD Turin 9965(192코어) 기반 Gen 13 서버를 배포함. 코어당 L3 캐시가 6배 줄어 레거시 NGINX 스택(FL1)으로는 레이턴시 50% 악화가 불가피했으나, Rust로 전면 재작성한 FL2로 전환해 Gen 12 대비 처리량 2배, 성능/와트 50% 개선을 달성함.

기사 전체 정리

Cloudflare Gen 13 서버: 캐시를 코어로 바꿔 성능 2배 달성한 이야기

문제: 캐시가 6분의 1로 줄었음

  • Gen 12는 AMD Genoa-X 프로세서로 3D V-Cache 덕에 코어당 L3 캐시가 12MB였음
  • Gen 13 후보인 Turin 9965는 192코어로 코어 수가 2배지만, 코어당 L3는 2MB에 불과함. 캐시가 6배 줄어든 셈
  • L3 캐시 히트는 약 50사이클인데 미스 나면 DRAM까지 가야 해서 350사이클 이상 소요. 7배 페널티임

FL1(레거시 스택)으로는 안 됐음

  • FL1은 NGINX + LuaJIT 기반 레거시 요청 처리 레이어임
  • Turin 9965에서 FL1 성능: 처리량은 +62%였지만 고부하 시 레이턴시가 50% 이상 악화 — 서비스 품질 기준 미달
  • AMD와 협업해서 하드웨어 프리페처 조정, 워커 스케일링, CPU 피닝 등 다양한 최적화를 시도했지만 효과가 미미했음
  • AMD PQOS로 CCD 전체를 FL1에 전담 할당하니 의미 있는 개선이 나왔지만 근본 해결은 아니었음

FL2: Rust 전면 재작성이 답이었음

  • FL2는 15년 된 NGINX/LuaJIT 코드를 Pingora/Oxy 프레임워크 기반 Rust로 완전 재작성한 것
  • 원래 캐시 문제를 풀려고 만든 게 아님. 메모리 안전성, 개발 속도, 모듈성을 위해 시작한 프로젝트였음
  • 그런데 FL2의 깔끔한 메모리 접근 패턴이 대용량 L3 캐시 의존도를 없애버림

FL2 + Turin 9965 결과

  • CPU% 대비 요청 처리량: FL1 대비 50% 향상
  • Gen 12 대비 레이턴시: 70% 감소
  • Gen 12 대비 처리량: 2배 (FL1으로는 62%가 한계였음)
  • 성능/와트: Gen 12 대비 50% 개선
  • 랙당 처리량: Gen 12 대비 60% 증가 (동일 전력 예산 내)

배포 현황

  • AMD EPYC Turin 9965(192코어/384스레드)를 Gen 13 공식 프로세서로 확정함
  • 하드웨어 검증 완료, 글로벌 엣지 네트워크에 대규모 배포 중
  • 하드웨어-소프트웨어 공동 설계의 중요성을 잘 보여주는 사례임

핵심 포인트

  • Gen 12(Genoa-X) 대비 Gen 13(Turin 9965)은 코어 수 2배(192코어)지만 코어당 L3 캐시가 12MB에서 2MB로 6배 감소
  • NGINX+LuaJIT 기반 FL1은 L3 미스 시 50→350+사이클 페널티로 고부하 시 레이턴시 50% 이상 악화
  • 하드웨어 튜닝, PQOS 등으로는 근본 해결이 안 돼서 Pingora/Oxy 기반 Rust 전면 재작성(FL2)으로 해결함
  • FL2로 전환 후 Gen 12 대비 처리량 2배, 레이턴시 70% 감소, 성능/와트 50% 개선 달성
  • Gen 13 서버는 글로벌 엣지 네트워크에 대규모 배포 중

인사이트

하드웨어 세대 교체에서 소프트웨어 스택이 병목이 되는 전형적인 사례임. 캐시 의존적인 레거시 코드가 새 하드웨어의 잠재력을 절반밖에 못 끌어냈고, Rust 재작성이 메모리 접근 패턴 자체를 바꿔서 하드웨어와 소프트웨어 양쪽의 이점을 동시에 실현함. 15년 된 NGINX 스택을 걷어내는 결단이 인프라 비용에 직접적 영향을 준 케이스임.

#cloudflare#amd#rust#performance#infrastructure
원문 보기
댓글 뒤로가기
이전 기사 (p) 다음 기사 (n)

댓글

댓글

댓글을 불러오는 중...

관련 기사

backend

Redis 8.0 출시 — I/O 스레딩 갈아엎고 처리량 3배, 2.1M ops/sec 달성

Redis 8.0이 I/O 스레딩 모델을 완전히 재설계해서 16코어 기준 2.1M ops/sec를 달성함 (7.4 대비 3배). Hash field expiration, Vector search HNSW, Client-side caching v2, Redis Functions 2.0 async 실행 등 굵직한 기능이 추가되고, jemalloc 통합으로 메모리 fragmentation도 25% 줄어듦.

backend

Go 1.26의 타입 생성(Type Construction)과 순환 감지(Cycle Detection) 개선

Go 1.26에서 타입 체커의 타입 생성 알고리즘을 개선해 재귀 타입과 배열 크기 계산 시 발생하던 순환 감지 문제를 체계적으로 해결했다. 불완전한 값이 다운스트림으로 퍼지기 전에 업스트림에서 차단하는 새로운 접근법으로 여러 컴파일러 패닉을 수정.

backend

칩셋 레이턴시를 측정해봤더니 — 쓸모는 없지만 재밌는 실험

Vulkan GPU 벤치마크로 여러 세대 마더보드 칩셋의 PCIe 레이턴시를 측정한 실험. CPU 직결 대비 칩셋 경유 시 수백 ns 레이턴시가 추가되며, 의외로 2012년 Skylake Z170이 가장 낮은 추가 레이턴시를 보임.

backend

ForgeKV — Rust로 만든 멀티코어 Redis 대체제

Rust로 만든 Redis 드롭인 대체제. 64-샤드 잠금 아키텍처로 멀티코어 스케일링 지원. 2코어 환경에서 Redis 7 대비 41% 빠른 SET 처리량(158K ops/s). 고동시성에서는 약점 있음. Source-available 라이선스.

backend

AI 바이브 코딩에 Go를 쓰는 이유 — Rust도 Python도 아닌

AI가 코드의 90%를 쓰는 바이브 코딩 시대에 Go가 최적의 언어라는 주장. Python은 안전장치가 없고, Rust는 언어 자체의 문제까지 인간에게 떠넘기지만, Go는 중요한 것만 잡고 비켜준다는 논리. 실제로 한 세션에 3도메인 풀스택 블로그를 7커밋으로 완성한 사례 제시.