본문으로 건너뛰기
피드

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

backend 약 4분
vote
0
댓글
북마크

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

  • 1

    Gen 12(Genoa-X) 대비 Gen 13(Turin 9965)은 코어 수 2배(192코어)지만 코어당 L3 캐시가 12MB에서 2MB로 6배 감소

  • 2

    NGINX+LuaJIT 기반 FL1은 L3 미스 시 50→350+사이클 페널티로 고부하 시 레이턴시 50% 이상 악화

  • 3

    하드웨어 튜닝, PQOS 등으로는 근본 해결이 안 돼서 Pingora/Oxy 기반 Rust 전면 재작성(FL2)으로 해결함

  • 4

    FL2로 전환 후 Gen 12 대비 처리량 2배, 레이턴시 70% 감소, 성능/와트 50% 개선 달성

  • 5

    Gen 13 서버는 글로벌 엣지 네트워크에 대규모 배포 중

문제: 캐시가 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 공식 프로세서로 확정함
  • 하드웨어 검증 완료, 글로벌 엣지 네트워크에 대규모 배포 중
  • 하드웨어-소프트웨어 공동 설계의 중요성을 잘 보여주는 사례임

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

댓글

댓글

댓글을 불러오는 중...

backend

잘못된 추상화보다 중복이 낫다는 샌디 메츠의 고전 조언

샌디 메츠는 중복을 없애려다 잘못된 추상화를 만들면 코드가 조건문과 파라미터로 부풀어 더 위험해진다고 말한다. 이미 틀어진 추상화는 억지로 보존하지 말고, 다시 호출부에 인라인해서 중복을 되살린 뒤 현재 요구사항에 맞는 새 구조를 찾는 편이 빠르다는 주장이다.

backend

리눅스 커널, 6년·360개 넘는 패치 끝에 strncpy 제거

리눅스 커널이 오랫동안 버그의 원인이던 strncpy API 사용을 Linux 7.2에서 제거했어. NUL 종료 동작이 직관적이지 않고 불필요한 zero-fill로 성능 문제도 있던 API를 6년 동안 약 362개 커밋으로 걷어낸 작업임.

backend

덕디비는 왜 빠를까: 서버 없는 분석 엔진의 내부 구조 뜯어보기

DuckDB가 단일 바이너리, 인프로세스 실행, 컬럼형 저장, 최적화 패스, Parquet 푸시다운으로 빠른 분석 쿼리를 처리하는 방식을 깊게 설명한 글이다. 6GB Parquet 파일을 노트북에서 바로 SQL로 읽는 경험 뒤에 어떤 설계가 깔려 있는지 따라간다.

backend

피지독, 포스트그레스를 수평 확장시키겠다고 550만 달러 투자 유치

피지독은 포스트그레스 앞단에 프록시를 두고 샤딩과 라우팅을 처리해 수평 확장을 가능하게 하겠다는 오픈소스 프로젝트다. 이미 프로덕션에서 초당 200만 건이 넘는 쿼리를 처리하고, 확인된 규모만 20테라바이트 이상을 샤딩했다고 밝히며 550만 달러 투자를 공개했다.

backend

펜타시스템, EDB 포스트그레SQL로 국내 엔터프라이즈 DB 전환 시장 공략

펜타시스템테크놀러지가 EDB와 파트너 계약을 맺고 국내에 EDB 포스트그레SQL 기반 데이터 플랫폼을 공급한다. 기존 상용 DBMS 정책 변화로 비용 부담이 커진 기업들을 겨냥해, 오픈소스 기반 엔터프라이즈 데이터 플랫폼 전환 수요를 잡겠다는 전략이다. 금융, 공공, 제조, 유통, 클라우드, AI 데이터 분석 환경까지 적용 범위를 넓히려는 움직임이다.