본문으로 건너뛰기
피드

메타, 낡은 DDR4 메모리를 새 서버에서 재활용하려고 CXL 칩까지 만들었다

backend 약 8분
vote
0
댓글
북마크

메타가 기존 서버에서 빼낸 DDR4 메모리를 새 DDR5 기반 서버에 붙이기 위해 자체 CXL ASIC ‘Vistara’를 만들었다. 수백만 대 규모 서버 플릿 중 약 40%는 메모리 증설이 어려운데, 메모리 자체의 수명은 서버보다 길다는 점을 활용한 접근이다. Vistara는 DDR4를 별도 NUMA 노드로 노출하고, 머신러닝 추론·빅데이터·DB·캐시·CI/CD 워크로드에서 메모리 부족으로 인한 실패와 재시작 부담을 줄이는 데 쓰인다.

  • 1

    메타 서버 플릿의 약 40%는 메모리 증설이 어려워 일부 워크로드를 처리하기 힘들다

  • 2

    Vistara ASIC은 DDR4를 CXL 2.0/1.1 기반 PCIe Gen5 x16 인터페이스로 호스트 CPU에 연결한다

  • 3

    칩 하나당 72비트 DDR4 채널 2개, 최대 3,200MT/s, 64GB DIMM 기준 최대 256GB를 지원한다

  • 4

    메타는 이 방식으로 OOM에 따른 작업 실패, 재시작, 리소스 파편화 오버헤드를 33% 줄였다고 밝혔다

  • 메타가 낡은 DDR4 메모리를 새 서버에서 다시 쓰려고 자체 CXL ASIC을 만들었음. 이름은 Vistara

    • 기존 서버에서 DDR4 DIMM을 빼내 새 DDR5 기반 서버에 꽂고, 이를 공유 가능한 메모리 풀처럼 활용하는 구조
    • 메타는 이 내용을 ISCA 2026에서 발표할 예정이고, 논문이 먼저 공개됨
    • 포인트는 ‘재활용’이지만, 실제 구현은 커스텀 칩·리눅스 드라이버·서버 섀시 설계까지 들어간 꽤 하드코어한 작업임
  • 왜 이렇게까지 하냐면, 메타의 거대한 서버 플릿 중 약 40%는 메모리 증설이 안 되는 상태라고 함

    • 서버 기대 수명은 보통 35년인데, 메모리는 710년까지 쓸 수 있음
    • 즉 서버는 갈아야 하는데 메모리는 아직 쓸 만한 자산으로 남아 있음
    • 수백만 대 서버 규모에서는 이 차이가 그냥 회계 항목이 아니라 인프라 설계 문제가 됨
  • 메타가 원한 건 서로 다른 세대의 메모리를 한 서버 안에서 섞어 쓰는 것임. 그런데 기존 CXL 제품은 이 요구를 못 맞췄다고 함

    • 많은 CXL 솔루션은 DRAM과 컨트롤러가 묶여 있어 기존 DIMM 재사용이 어려움
    • DDR4 지원이 빠진 제품도 많았는데, 메타 입장에서는 DDR4 재활용이 핵심 요구사항임
    • 전력 소비와 비용도 하이퍼스케일 운영에 맞지 않았다고 지적함

중요

> Vistara의 핵심은 CXL로 ‘새 메모리’를 붙이는 게 아니라, 이미 보유한 DDR4 자산을 새 서버에서 다시 쓰는 것임. 하이퍼스케일에서는 이 차이가 서버 수명, 비용, 전력, 폐기 계획까지 건드린다.

  • Vistara ASIC은 DDR4 메모리를 CXL 2.0/1.1 호환 PCIe Gen5 x16 인터페이스로 호스트 프로세서에 연결함

    • 칩 하나에 독립적인 72비트 DDR4 메모리 채널 2개가 들어감
    • 최대 속도는 3,200MT/s
    • 64GB DIMM 기준 칩당 최대 256GB까지 지원함
    • ASIC 내부 동작은 커스텀 RISC-V 프로세서 2개가 담당함
  • 실제 장비는 메타가 MemServer라고 부르는 서버에 들어감

    • MemServer는 AMD Turin 프로세서를 쓰고, 158코어와 316스레드를 제공함
    • 기본으로 768GB DDR5 메모리를 갖고, 여기에 Vistara ASIC을 통해 256GB DDR4를 추가로 연결함
    • Vistara CXL 카드는 서버 뒤쪽에서 접근 가능한 전용 슬롯에 장착됨
    • 고밀도 메모리와 CXL 장치의 발열 때문에 고용량 팬과 지향성 공기 흐름으로 모듈을 직접 식힘
  • 소프트웨어에서는 이 DDR4가 로컬 DRAM이 아니라 ‘CPU 없는 별도 NUMA 노드’로 운영체제에 보임

    • 메타 플랫폼은 먼저 로컬 DDR4를 모두 쓰고, 필요할 때 CXL로 붙은 메모리를 사용함
    • 리눅스 CXL 드라이버도 커스텀 수정이 들어갔지만, 메타는 사용 중인 코드가 이미 업스트림 커널에 있거나 업스트림 예정이라고 설명함
    • 운영체제에 별도 NUMA 노드로 보이게 하는 건 지연시간 차이를 숨기기보다, 메모리 계층을 명시적으로 다루는 쪽에 가까움
sequenceDiagram
    participant 워크로드
    participant 리눅스커널
    participant 호스트CPU
    participant 비스타라ASIC
    participant DDR4메모리
    워크로드->>리눅스커널: 추가 메모리 요청
    리눅스커널->>호스트CPU: 별도 NUMA 노드 접근
    호스트CPU->>비스타라ASIC: CXL 경유 메모리 요청
    비스타라ASIC->>DDR4메모리: DDR4 채널 접근
    DDR4메모리-->>비스타라ASIC: 데이터 반환
    비스타라ASIC-->>호스트CPU: CXL 응답
    호스트CPU-->>워크로드: 확장 메모리 사용
  • 적용 대상도 꽤 넓음. 메타는 이미 수백만 서버 규모의 하이퍼스케일 인프라에서 이 CXL 구성을 다양한 프로덕션 워크로드에 쓴다고 밝힘

    • 추천 시스템의 임베딩 테이블을 다루는 분산 머신러닝 추론
    • Spark, Hive 같은 빅데이터 처리
    • 데이터베이스, 분산 캐시, CI/CD 빌드 시스템
    • 특히 테라바이트·페타바이트급 데이터셋을 다루고 작업당 수백 GB 메모리를 요구하는 워크로드가 대상임
  • 효과는 메모리 여유분 확보에 있음. 메타는 CXL로 메모리 헤드룸을 늘려 OOM 관련 비용을 줄였다고 함

    • 메모리 부족으로 작업이 실패하면 비즈니스 분석과 머신러닝 파이프라인이 깨질 수 있음
    • 논문은 CXL이 OOM 이벤트 위험을 낮춰 작업 실패, 재시작, 리소스 파편화 관련 오버헤드를 33% 줄였다고 설명함
    • 결국 Vistara는 ‘느린 메모리라도 있는 게 낫다’가 아니라, 특정 워크로드에서 실패를 줄이는 안정성 장치로 쓰이는 셈

기술 맥락

  • 메타가 고른 선택은 기존 DDR4를 버리지 않고 CXL로 새 서버에 붙이는 방식이에요. 왜냐하면 서버 수명은 35년인데 메모리는 710년 쓸 수 있어서, 규모가 커지면 메모리만 따로 남는 문제가 생기거든요.

  • 시중 CXL 장비를 그대로 쓰지 않은 이유도 명확해요. DRAM과 컨트롤러가 묶인 제품은 기존 DIMM 재사용이 안 되고, DDR4 지원도 빠져 있는 경우가 많았어요. 메타 입장에서는 새 메모리를 사는 솔루션이 아니라, 이미 가진 DDR4를 운영에 다시 투입하는 솔루션이 필요했던 거죠.

  • 구현은 하드웨어와 커널 양쪽을 같이 건드립니다. Vistara ASIC은 PCIe Gen5 x16 기반 CXL 인터페이스로 DDR4 채널을 호스트에 연결하고, 리눅스는 이 메모리를 CPU 없는 별도 NUMA 노드로 봐요. 이렇게 해야 로컬 DDR5와 CXL DDR4의 지연시간 차이를 운영체제와 런타임이 의식할 수 있어요.

  • 이 방식은 모든 워크로드를 빠르게 만드는 마법이 아니에요. Spark, Hive, 임베딩 테이블, 분산 캐시처럼 메모리 부족으로 작업이 죽는 비용이 큰 워크로드에서 의미가 커요. 메타가 말한 33% 감소도 성능 가속보다는 OOM 실패와 재시작 오버헤드 감소에 가까워요.

  • 한국 인프라 팀 입장에서도 재미있는 대목은 ‘CXL을 어디에 쓰는가’예요. 단순히 최신 서버 스펙 경쟁이 아니라, 레거시 자산 재활용과 워크로드 안정성 확보라는 현실적인 목표가 CXL 도입 이유가 될 수 있다는 걸 보여주거든요.

하이퍼스케일에서는 ‘낡은 메모리 좀 아껴 쓰자’가 곧 커스텀 ASIC과 리눅스 커널 드라이버 수정으로 이어진다. CXL이 왜 데이터센터에서 계속 언급되는지, 그리고 범용 제품이 실제 운영 요구를 얼마나 못 맞추는지 보여주는 꽤 실전적인 사례다.

댓글

댓글

댓글을 불러오는 중...

backend

왜 아직도 Lisp를 배워볼 만한가

Lisp는 괄호가 많은 이상한 언어처럼 보이지만, 핵심은 문법이 아니라 언어 자체를 확장할 수 있다는 점에 있음. 매크로, 코드-데이터 동일성, REPL 중심 개발이 합쳐지면 프로그램을 '작성'한다기보다 살아 있는 시스템을 계속 진화시키는 방식으로 개발하게 됨.

backend

EDB 포스트그레스 AI, 포레스터 멀티모델 데이터 플랫폼 리더 선정

EDB의 AI 데이터 플랫폼 EDB 포스트그레스 AI가 2026년 2분기 포레스터 웨이브 멀티모델 데이터 플랫폼 보고서에서 리더로 선정됐음. 트랜잭션, 분석, AI 워크로드를 하나의 플랫폼에서 다루는 흐름이 강해지는 가운데, EDB는 전략과 현재 제공 기능 모두에서 높은 평가를 받았다고 밝힘.

backend

Bun, Zig에서 Rust로 갈아탔다: 11일짜리 초대형 런타임 포팅 실험

Bun 팀이 53만 줄이 넘는 Zig 코드베이스를 Rust로 기계적으로 포팅했고, Bun v1.4.0부터 Rust 기반으로 전환될 예정임. 핵심 이유는 성능보다 안정성이었고, use-after-free, double-free, 메모리 누수 같은 문제를 컴파일러와 타입 시스템으로 더 빨리 잡기 위해서였음. Claude Code 워크플로 64개를 병렬로 돌려 11일 만에 전 플랫폼 테스트 통과까지 밀어붙인 사례라, LLM 기반 대규모 코드 마이그레이션의 꽤 강한 신호탄임.

backend

시카고 미술관 API에 숨어 있는 ‘조회수 낮은 작품’ 필드

시카고 미술관 API에는 웹사이트에서 거의 조회되지 않은 작품을 표시하는 불리언 필드가 있다. 기준은 2010년 1월 1일 이후 조회수 200회 미만으로, API 설계 안에 꽤 인간적인 큐레이션 포인트가 숨어 있는 셈이다.

backend

유엔넷 DB 관리 솔루션, 오라클에서 PostgreSQL로 가는 일본 시장 노린다

유엔넷이 일본 PostgreSQL 기술지원 기업 뮤텍과 독점 공급 계약을 맺고 DB 성능 분석 솔루션 타란튜너를 일본에 공급해. 오라클에서 PostgreSQL로 전환하는 기업이 늘면서 SQL 지연, 잠금 경합, 실행 계획 비교 같은 운영 관리 수요를 겨냥한 움직임이야.