▲

GN⁺: Meta의 하이퍼스케일 인프라에 대한 개요 및 통찰

 (cacm.acm.org)
21P by neo 9일전 | ★ favorite | 댓글 3개
  • Meta의 엔지니어링 문화는 빠른 실행, 기술 개방성, 생산 환경에서의 연구, 그리고 공유 인프라를 강조함
  • 개발자 생산성을 높이기 위해 지속적 배포를 채택하고, 더 많은 개발자가 전통적인 서비스 코드 대신 서버리스 함수를 작성할 수 있도록 함
  • 하드웨어 비용 절감을 위해 데이터센터 규모에서 하드웨어-소프트웨어 공동 설계를 활용하고, 개별 클러스터에 제한하지 않고 전 세계 데이터센터 간의 자원 할당을 자동으로 최적화
  • Meta의 AI 전략은 PyTorch에서 AI 가속기, 네트워크, Llama와 같은 ML 모델까지 전체 스택을 공동 설계

# [엔지니어링 문화]

빠른 실행 (Move Fast)

  • Meta는 민첩성과 빠른 반복을 강조하는 "빠른 실행" 문화를 유지하고 있음
  • 최신 코드를 가능한 한 빨리 프로덕션에 배포하는 지속적 배포(Continuous Deployment)를 강력히 지지함
  • 제품 엔지니어들은 PHP, Python, Erlang과 같은 언어를 사용하여 상태 비저장 서버리스 함수를 작성함
  • 긴 계획 수립 과정 없이도 우선순위를 변경할 수 있으며, 반복적 실행을 통해 불확실한 문제를 해결함
  • 이러한 방식은 빠른 시장 대응과 신속한 제품 출시를 가능하게 함

기술 개방성 (Technology Openness)

  • 내부 개방성: 모노레포(Monorepo) 접근 방식을 사용하여 모든 프로젝트의 코드를 단일 저장소에 저장함
    • 코드 검색, 재사용, 팀 간 협업이 용이함
    • 대부분의 프로젝트에서 엄격한 코드 소유권 제한이 없음, 개발자들이 자유롭게 기여할 수 있음
  • 외부 개방성: 오픈소스 하드웨어 및 소프트웨어 프로젝트를 적극적으로 공유함
    • Open Compute Project를 통해 하드웨어 디자인을 공개함
    • PyTorch, Llama, Presto, RocksDB, Cassandra 등 다양한 오픈소스 소프트웨어 프로젝트를 운영함
    • 연구 논문을 통해 인프라 기술을 공유함

프로덕션에서의 연구 (Research in Production)

  • Meta는 전용 시스템 연구소 없이 실제 운영 환경에서 연구를 수행함
  • 프로덕션 시스템을 개발하는 팀이 직접 연구 논문을 작성하여 실제 문제를 해결하고, 대규모 운영 환경에서 검증된 솔루션을 제공함
  • 이 접근 방식은 실용적이며, 성공적인 시스템 연구의 핵심 기준을 충족함

공통 인프라 (Common Infrastructure)

  • 개별 팀이 자유롭게 기술 스택을 선택하는 대신, 표준화와 글로벌 최적화를 우선시함
  • 하드웨어:
    • 모든 서버는 공유 서버 풀에서 할당됨
    • 비 AI 컴퓨팅 워크로드에는 단일 서버 유형(기본적으로 1개 CPU, 256GB DRAM)을 제공하여 서버 유형의 복잡성을 줄임
  • 소프트웨어:
    • 기존에는 Cassandra, HBase, ZippyDB 등 다양한 키-값 저장소를 사용했으나, 현재는 ZippyDB로 통합됨
    • 소프트웨어 배포, 설정 관리, 서비스 메쉬, 성능 테스트 등은 공통 도구로 통합됨
  • 재사용 가능한 구성 요소 선호:
    • Tectonic 파일 시스템 → ZippyDB(메타데이터 저장) → Shard Manager(데이터 샤딩 관리) → ServiceRouter(샤드 탐색 및 요청 라우팅) → Delos(고신뢰 데이터 저장소) 로 구성된 컴포넌트 재사용 체인을 구축함
    • HDFS 같은 모놀리식 시스템 대신 모듈화된 재사용 가능한 구성 요소를 사용하여 확장성을 극대화함

문화 사례 연구: Threads 앱 개발 (Culture Case Study: The Threads App)

  • Threads 앱 개발 사례는 Meta의 엔지니어링 문화를 잘 보여줌
  • 단 5개월 만에 기술 작업을 완료하고, 2일 전 사전 공지 후 인프라 팀이 프로덕션 배포 준비를 완료함
  • 대부분의 대기업에서는 이틀 만에 프로젝트 계획서를 작성하는 것도 어려움. 하지만 Meta는 실시간 문제 해결을 위해 워룸을 구축하고 신속한 대응을 진행함
  • 결과적으로, 출시 5일 만에 1억 명의 사용자 돌파, 역사상 가장 빠르게 성장한 앱이 됨
  • Threads는 기존 인프라를 재사용하여 빠르게 확장할 수 있었음:
    • Instagram의 Python 백엔드
    • Meta의 공유 인프라 (소셜 그래프 데이터베이스, 키-값 저장소, 서버리스 플랫폼, ML 플랫폼, 모바일 앱 설정 관리 등)
  • 내부 개방성: 모노레포를 활용하여 Instagram 코드 일부를 재사용하여 개발 속도를 높임
  • 외부 개방성: ActivityPub을 활용하여 다른 앱과의 상호운용성을 목표로 함
  • 개발 경험 공유: 빠른 개발과 배포 경험을 공개적으로 공유함

# [엔드투엔드 사용자 요청 흐름 (End-to-End User Request Flow)]

  • Meta의 인프라 기술을 심층적으로 살펴보기 위해, 사용자 요청이 처리되는 전체 과정을 설명
  • Meta의 제품은 공유 서비스 인프라에서 지원되며, 여기에는 다양한 핵심 컴포넌트가 포함

요청 라우팅 (Request Routing)

  • 동적 DNS 매핑 (Dynamic DNS Mapping)
    • 사용자가 facebook.com에 접속하면 Meta의 DNS 서버는 동적으로 **가장 가까운 PoP(Point of Presence)**의 IP 주소를 반환함
    • PoP는 소규모 엣지 데이터센터로, 사용자와 가까운 위치에서 네트워크 부하를 분산함
    • PoP는 Meta의 데이터센터와 장기적인 TCP 연결을 유지하여, TCP 연결 설정 시간을 줄이고 네트워크 성능을 향상시킴
    • 전 세계에 수백 개의 PoP가 배치되어 있어, 대부분의 사용자에게 짧은 네트워크 지연 시간을 제공함
  • 정적 콘텐츠 캐싱 (Static-Content Caching)
    • 이미지, 동영상 등 정적 콘텐츠는 PoP에서 캐싱하여 직접 제공 가능
    • 또한, Meta는 **CDN(콘텐츠 전송 네트워크)**을 운영하며, ISP(인터넷 서비스 제공업체)와 협력하여 CDN 사이트를 구축함
    • 사용자의 요청이 facebook.com/image.jpg라면, Meta는 이를 CDN109.meta.com/image.jpg로 재작성하여 가까운 CDN 사이트에서 콘텐츠를 제공함
    • 만약 CDN에 해당 콘텐츠가 없으면, PoP → 데이터센터 로드 밸런서 → 스토리지 시스템으로 요청이 전달됨
  • 동적 콘텐츠 요청 라우팅 (Dynamic-Content Request Routing)
    • 뉴스피드 같은 동적 콘텐츠 요청은 PoP에서 데이터센터로 전달됨
    • 트래픽 엔지니어링 도구가 데이터센터 용량과 네트워크 지연 시간을 고려하여 최적의 데이터센터를 선택함
    • PoP에서 데이터센터까지의 트래픽은 **Meta의 프라이빗 WAN(광역 네트워크)**을 통해 전송됨
    • 데이터센터 간 트래픽은 사용자-PoP 트래픽보다 훨씬 많으며, 이는 데이터 복제 및 마이크로서비스 간 상호작용 때문임

인프라 토폴로지 (Infrastructure Topology)

  • Meta의 글로벌 인프라는 다양한 계층의 인프라 구성 요소로 이루어져 있음
  • 각 구성 요소는 특정 역할을 수행하며, 다음과 같은 규모로 운영됨:
    • 데이터센터 지역(Region): 전 세계에 약 10개의 데이터센터 지역이 있으며, 각 지역은 최대 100만 개의 서버를 운영할 수 있음
    • PoP(Point of Presence, 엣지 데이터센터): 약 100개 이상의 PoP가 있으며, PoP당 보통 100~1,000대의 서버를 포함함. 사용자와 가까운 위치에서 트래픽을 처리하여 지연 시간을 줄이는 역할을 함
    • CDN 사이트: 1,000개 이상의 CDN 사이트가 있으며, 보통 10대 이상의 서버를 포함하고, 일부 큰 사이트는 100대 이상의 서버를 운영함. 정적 콘텐츠(이미지, 동영상 등)를 캐싱하여 빠르게 제공함
    • 데이터센터(Datacenter): 각 데이터센터 지역에는 여러 개의 데이터센터가 위치하며, 각 데이터센터는 약 10만 개 이상의 서버를 운영할 수 있음
    • MSB(메인 스위치보드, Main Switchboard): 데이터센터 내 최대 12개의 MSB가 존재하며, 각 MSB는 1만~2만 개의 서버를 담당함. 전력 분배 역할을 하며, 데이터센터 내 주요 장애 도메인으로 작용함. MSB가 고장 나면 최대 2만 대의 서버가 다운될 수 있음
  • 엣지 네트워크:
    • PoP는 여러 인터넷 자율 시스템(AS)과 연결되며, **BGP(Border Gateway Protocol)**를 사용하여 최적의 경로를 선택함
  • 데이터센터 네트워크:
    • 서버들은 3단계 Clos 토폴로지를 사용하여 연결됨
    • 네트워크 혼잡을 방지하고, 서버 간 최대 대역폭을 제공하도록 설계됨
  • 지역 네트워크:
    • 데이터센터들은 패브릭 애그리게이터로 연결되며, WAN과 통신할 수 있도록 함
    • Fat-Tree 토폴로지를 사용하여 점진적으로 확장 가능

요청 처리 (Request Processing)

  • 온라인 처리 (Online Processing)
    • 사용자의 요청은 로드 밸런서를 통해 **수만 개의 서버리스 프론트엔드 함수(FrontFaaS)**로 분배됨
    • 프론트엔드 함수는 여러 백엔드 서비스를 호출할 수 있으며, ML 추론 서비스(예: 광고 추천, 뉴스피드 콘텐츠 추천)를 호출할 수도 있음
    • 실행 중, 프론트엔드 함수는 이벤트 큐에 이벤트를 추가하여 **이벤트 기반 서버리스 함수(XFaaS)**가 비동기적으로 실행되도록 함
    • 프론트엔드 함수와 이벤트 기반 함수의 서버 비율은 약 5:1로 운영됨
  • 오프라인 처리 (Offline Processing)
    • 오프라인 처리 시스템은 온라인 시스템을 보조하며, 데이터 분석 및 머신러닝 훈련을 수행함
    • 프론트엔드 함수 및 백엔드 서비스는 다양한 로그 데이터를 데이터 웨어하우스에 저장
      • ML 훈련: 로그 데이터를 활용하여 머신러닝 모델을 업데이트함
      • 스트림 프로세싱: 사이트 내 가장 많이 논의되는 주제를 업데이트하여 데이터베이스 및 캐시에 저장
      • 배치 분석: Spark 및 Presto를 사용하여 친구 추천 시스템을 업데이트
      • 이벤트 기반 서버리스 함수 실행: 데이터 업데이트가 이벤트 트리거 역할을 수행하여 자동으로 서버리스 함수를 실행함

# [개발자 생산성 향상 (Boosting Developer Productivity)]

  • Meta의 공유 인프라는 개발자 생산성을 극대화하는 것을 목표로 함
  • 이를 위해 지속적 배포(Continuous Deployment)와 서버리스 함수(Serverless Functions)를 극한까지 활용하고 있음

지속적 배포 (Continuous Deployment)

  • Meta는 코드 및 설정(Configuration) 변경 사항을 빠르게 배포할 수 있도록 최적화됨
  • 새로운 기능 및 버그 수정 사항을 즉시 배포하여 빠른 피드백과 반복적인 개선 가능
  • 설정 변경 (Configuration Changes)
    • Meta의 설정 관리 도구는 매일 10만 개 이상의 실시간 변경 사항을 프로덕션에 배포
    • 약 1만 개 이상의 서비스와 수백만 개의 서버에서 설정이 자동으로 업데이트됨
    • 로드 밸런싱, 기능 롤아웃, A/B 테스트, 과부하 방지 등 다양한 작업이 자동으로 수행됨
    • 설정 변경은 코드 변경처럼 리뷰를 거쳐 코드 저장소에 커밋되며, 변경 사항은 몇 초 내에 전체 시스템에 전파됨
  • 코드 변경 (Code Changes)
    • Meta의 배포 도구는 3만 개 이상의 배포 파이프라인을 운영하여 소프트웨어 업데이트를 관리
    • 97%의 서비스가 완전 자동화된 배포를 채택하여 수동 개입 없이 업데이트됨:
      • 55%는 **완전 지속적 배포(CD)**를 사용하여 코드 변경이 자동으로 프로덕션에 반영됨
      • 42%는 고정된 일정(일별 또는 주별)으로 자동 배포됨
    • 프론트엔드 서버리스 함수(FrontFaaS)는 50만 대 이상의 서버에서 실행되며, 1만 명 이상의 개발자가 매일 수천 개의 코드 커밋을 수행함
    • 이처럼 동적인 환경에서도 모든 서버리스 함수는 3시간마다 새로운 버전이 프로덕션에 배포됨
  • 네트워크 및 인프라 소프트웨어 업데이트
    • Meta의 **프라이빗 WAN(Private WAN)**은 여러 개의 병렬 네트워크 플레인을 유지하여, 새로운 네트워크 알고리즘을 독립적으로 테스트 가능
    • 네트워크 스위치 소프트웨어도 자주 업데이트되며, 스위치의 "Warm Boot" 기능을 활용하여 네트워크 트래픽을 중단하지 않고 소프트웨어를 업데이트할 수 있음
    • 자주 업데이트되는 코드와 설정 변경은 사이트 장애 위험을 증가시키므로, Meta는 테스트, 단계적 배포, 헬스 체크에 많은 투자를 진행함
      • 코드 배포 자동화를 12%에서 97%로 증가시키는 사내 캠페인을 진행
      • 모든 설정 변경에 대해 자동 Canary 테스트를 수행하여 안정성을 보장

서버리스 함수 (Serverless Functions)

  • 서버리스 함수(또는 FaaS, Function-as-a-Service)는 개발자 생산성을 높이는 또 다른 핵심 요소
  • 전통적인 백엔드 서비스와 달리, 서버리스 함수는 상태를 저장하지 않고 단순한 함수 인터페이스를 구현함
  • 각 함수 호출은 독립적으로 실행되며, 외부 데이터베이스나 캐시 시스템을 활용하여 상태를 관리함
  • 서버리스 함수의 장점
    • 개발자는 인프라 관리 없이 제품 로직만 작성하면 됨
    • 자동으로 코드 배포 및 부하 변화에 따른 자동 확장(Auto-Scaling)이 수행됨
    • 하드웨어 낭비를 방지하고, 개발자들이 과도한 리소스를 할당할 필요가 없음
  • Meta의 서버리스 플랫폼
    • Meta의 1만 명 이상의 개발자 중, 서버리스 함수를 작성하는 개발자의 수가 전통적인 서비스 코드를 작성하는 개발자보다 50% 더 많음
    • Meta의 서버리스 개발 환경(IDE)은 소셜 그래프 데이터베이스 및 다양한 백엔드 시스템에 쉽게 접근할 수 있도록 지원하며, 지속적 통합 테스트(CI)를 제공하여 빠른 피드백을 가능하게 함
  • Meta의 서버리스 플랫폼: FrontFaaS와 XFaaS
    • FrontFaaS: PHP 기반의 프론트엔드 서버리스 함수, 50만 대 이상의 서버에서 실행됨
      • 항상 PHP 런타임을 유지하여 콜드 스타트 문제 없이 즉시 요청을 처리할 수 있음
      • 서버 부하가 낮을 때는 자동 스케일링을 통해 일부 서버를 해제하고 다른 작업에 활용함
    • XFaaS: 비동기적으로 실행되는 이벤트 기반 서버리스 함수
      • 즉각적인 응답이 필요하지 않은 백그라운드 작업을 처리함
      • 부하가 높은 작업을 피하기 위해, 실행을 지연시키거나, 글로벌 로드 밸런싱, 할당량 기반 스로틀링을 적용함
  • Meta의 서버리스 혁신
    • 2000년대 후반부터 서버리스 방식을 기본 개발 패러다임으로 사용
    • 퍼블릭 클라우드의 서버리스 플랫폼과의 차이점:
      • 퍼블릭 클라우드는 강한 격리를 위해 하나의 함수당 하나의 가상 머신을 사용
      • 반면, Meta는 하나의 Linux 프로세스에서 여러 개의 함수가 동시 실행될 수 있도록 설계하여 하드웨어 효율성을 극대화함

# [하드웨어 비용 절감 (Reducing Hardware Costs)]

  • Meta의 공유 인프라는 개발자 생산성을 높이는 것뿐만 아니라 하드웨어 비용 절감에도 중요한 역할을 함
  • 이를 위해 소프트웨어 최적화를 활용하여 하드웨어 효율성을 극대화하는 전략을 사용

글로벌 데이터센터를 하나의 컴퓨터처럼 운영 (All Global Datacenters as a Computer)

  • 기존 클라우드 환경에서는 사용자가 직접 서비스 복제본(replica) 수, 배포 지역 등을 설정해야 했음
  • 이런 수동 관리 방식은 자원 낭비, 부하 불균형, 데이터센터 간 마이그레이션 부족 등의 문제를 야기함
  • Meta는 "데이터센터를 하나의 컴퓨터로 운영"하는 기존 방식(DaaC, Datacenter as a Computer)에서 발전하여, "전 세계 데이터센터를 하나의 컴퓨터처럼 운영"하는 Global-DaaC를 구현
  • Global-DaaC의 주요 특징:
    • 사용자가 단순히 글로벌 배포 요청만 하면, 인프라가 자동으로 최적의 복제본 수, 배포 지역, 하드웨어 유형, 트래픽 라우팅을 결정함
    • 필요에 따라 서비스의 위치를 변경하며, 공급 변화 및 부하 변화에 적응 가능
    • 퍼블릭 클라우드와 달리, Meta는 모든 애플리케이션을 자체적으로 운영하므로 더 유연하게 워크로드 이동 가능
  • Global-DaaC 구현 방식
    • 글로벌, 지역, 개별 서버 수준에서 자원 할당을 자동화:
      • 글로벌 용량 관리 도구: RPC 트레이싱을 활용하여 서비스 간 의존성을 분석하고, **혼합 정수 프로그래밍(MIP)**을 통해 최적의 용량 배분을 결정
      • 지역 용량 관리 도구: 데이터센터별 서버 자원을 할당하여 가상 클러스터(Virtual Cluster)를 형성
      • 컨테이너 관리 도구: 가상 클러스터 내 컨테이너를 배치하며, 여러 데이터센터에 분산 배치하여 내결함성(Fault Tolerance) 확보
      • 커널 관리 기법: 컨테이너 간 메모리 및 I/O 자원을 적절히 공유하고 격리함
  • Global-DaaC의 적용 사례
    • 데이터베이스 및 상태 저장 서비스:
      • 각 컨테이너는 여러 데이터 샤드(shard)를 호스팅하여 효율성을 극대화
      • **Global Service Placer(GSP)**는 최적의 샤드 복제본 수 및 배치 지역을 결정
      • 샤딩 프레임워크가 이를 기반으로 샤드를 컨테이너에 할당하고 동적으로 마이그레이션함
    • 머신러닝(ML) 워크로드:
      • ML 추론(Inference) 작업은 데이터 샤드처럼 모델 복제본을 관리
      • ML 훈련(Training)은 데이터와 GPU가 동일한 데이터센터에 배치되어야 함
      • 글로벌 GPU 용량 할당을 받고, ML 훈련 스케줄러가 최적의 데이터 복제 및 GPU 배치를 수행함

하드웨어-소프트웨어 공동 설계 (Hardware and Software Co-Design)

  • 단일 서버 수준에서 하드웨어-소프트웨어 공동 설계(Co-Design)를 적용하는 것은 일반적이지만, Meta는 이를 글로벌 규모로 확장하여 저비용 하드웨어의 한계를 소프트웨어 최적화를 통해 극복함
  • 저비용 장애 내성 (Low-Cost Fault Tolerance)
    • 퍼블릭 클라우드는 가용성이 높은 하드웨어를 제공하지만, Meta는 소프트웨어를 통해 장애를 극복하는 방식을 채택하여 더 저렴한 하드웨어를 활용
    • 주요 차이점:
      • 퍼블릭 클라우드의 서버 랙(Rack)은 듀얼 전원 공급 장치 및 듀얼 ToR(Top-of-Rack) 스위치를 사용하지만, Meta는 단일 전원 및 단일 ToR 스위치 사용
      • 퍼블릭 클라우드의 가상 머신(VM)은 네트워크 연결된 블록 스토리지를 사용하여 라이브 마이그레이션 가능, 반면 Meta의 컨테이너는 저비용 로컬 SSD를 사용
    • 소프트웨어 기반 장애 극복 전략:
      • 리소스 할당 도구: 서비스의 컨테이너와 데이터 샤드를 데이터센터 내 다른 장애 도메인으로 분산
      • 협력 프로토콜: 애플리케이션이 컨테이너의 라이프사이클 관리에 개입할 수 있도록 하여, 데이터 샤드 복제본이 동시에 중단되지 않도록 보호
      • 다중 데이터센터 내구성 보장: 한 지역 전체가 중단되더라도 서비스가 유지되도록 설계되었으며, 정기적으로 실전 테스트를 수행하여 신뢰성을 검증
  • 라우팅 프록시 비용 절감 (Eliminating Routing Proxy Costs)
    • 기존 서비스 메시는 **사이드카 프록시(Sidecar Proxy)**를 사용하여 RPC 요청을 라우팅하지만, Meta는 99%의 RPC 요청을 직접 클라이언트-서버 라우팅 방식으로 처리
    • 이 방법을 통해 약 10만 대의 프록시 서버를 절약할 수 있음
    • 단, 라우팅 라이브러리를 1만 개 이상의 서비스에 컴파일하여 배포해야 하는 과제가 존재하지만, Meta의 소프트웨어 배포 및 설정 관리 도구를 통해 이를 해결함
  • 계층형 스토리지 및 로컬 SSD 활용 (Tiered Storage and Local SSDs)
    • 데이터 접근 빈도와 지연 시간 요구 사항에 따라 스토리지를 구분하여 비용 효율성을 극대화:
      • 핫 데이터(Hot Data): 메모리 및 SSD에 저장 (예: 소셜 그래프 데이터베이스)
      • 웜 데이터(Warm Data): HDD 기반의 분산 파일 시스템에 저장 (예: 동영상, 이미지, 로그 데이터)
      • 콜드 데이터(Cold Data): 대용량 HDD 서버에 저장 (예: 오래된 고해상도 동영상)
        • 저전력 모드로 유지하여 비용 절감
    • 로컬 SSD 활용:
      • 일부 워크로드는 공유 원격 스토리지(Remote Storage)보다 로컬 SSD가 더 나은 성능을 제공
      • 하지만, 불균형한 부하 분배로 인해 SSD 활용도가 낮아질 위험 존재
      • Meta의 공통 샤딩 프레임워크를 사용하여 불균형 문제 해결 및 SSD 효율성 극대화

자체 하드웨어 설계 (In-House Hardware Design)

  • Meta는 비용 및 전력 효율성을 위해 데이터센터, 서버, 네트워크 스위치, AI 칩을 자체 설계함
  • 전력은 데이터센터에서 가장 제한적인 자원이므로, 전력 사용량을 최적화하는 자동화 도구를 운영
  • 하드웨어-소프트웨어 공동 설계를 통해 비용 및 전력 절감:
    • AI 칩의 SRAM 사용 최적화
    • 데이터센터에서 압축 냉각 장치 제거
  • 네트워크 스위치와 소프트웨어도 자체 개발하여 정기적인 업데이트가 가능하며, 대부분의 하드웨어 디자인을 Open Compute Project를 통해 오픈소스로 공유함

# [확장 가능한 시스템 설계 (Designing Scalable Systems)]

  • 하이퍼스케일 인프라에서는 확장 가능한 시스템 설계가 핵심적인 요소임
  • 인터넷 환경에서 설계된 **분산 시스템(BGP, BitTorrent, DHT 등)**은 확장성이 뛰어나지만, 데이터센터 환경에서는 중앙 집중형 컨트롤러가 더 높은 확장성과 효율성을 제공할 수 있음

분산형 컨트롤러 폐지 (Deprecating Decentralized Controllers)

  • Meta는 기존의 분산형 컨트롤러에서 중앙 집중형 컨트롤러로 전환하는 방향을 선택함
  • 예외적으로 네트워크 스위치는 BGP를 유지하지만, 트래픽 혼잡 또는 링크 장애 발생 시 중앙 컨트롤러가 경로를 재설정할 수 있도록 설계됨
  • 중앙 집중형 컨트롤러는 더 나은 부하 분산 및 빠른 장애 대응이 가능하며, 데이터센터 환경에서 더 적합한 방식임

기존 분산형 시스템을 중앙 집중형으로 전환한 사례

  • 프라이빗 WAN(Private WAN)
    • 기존에는 RSVP-TE(분산형 경로 설정)를 사용했으나, 중앙 컨트롤러 기반 시스템으로 전환
    • 최적의 트래픽 경로를 자동으로 계산하고, 장애 발생 시 백업 경로를 사전 설정하여 빠른 복구 가능
  • 키-값 저장소(Key-Value Store)
    • 기존 DHT(분산 해시 테이블) 기반 멀티홉 라우팅을 사용하던 방식에서 중앙 컨트롤러 기반 샤딩 프레임워크로 변경
    • 중앙 컨트롤러가 샤드(Shard) 재배치를 동적으로 조정하여 부하 균형을 최적화
  • 대용량 데이터 분배
    • 기존에는 **BitTorrent(분산형 P2P 다운로드)**를 사용했으나, Meta의 Owl이라는 중앙 집중형 분배 시스템으로 전환
    • 데이터 다운로드 경로를 중앙에서 결정하여 훨씬 빠른 다운로드 속도 제공
  • 소규모 메타데이터 분배
    • 초기에는 **3계층 분산 트리 구조(Java 기반)**를 사용했으나, 확장성 문제로 P2P 기반 트리 구조로 변경
    • 하지만 일부 노드의 불안정한 성능이 전체 성능을 저하시켜, 최종적으로 고성능 C++ 기반 중앙 집중형 프록시 서버 아키텍처로 회귀

사례 연구: 확장 가능한 서비스 메쉬 (Scalable Service Mesh)

Meta는 ServiceRouter라는 자체 **서비스 메쉬(Service Mesh)**를 운영하며,
이 시스템을 통해 확장 가능한 중앙 집중형 아키텍처의 효과를 입증함.

  • 기존 서비스 메쉬 아키텍처의 문제점
    • 일반적인 서비스 메쉬는 각 서비스 프로세스가 L7 사이드카 프록시(Sidecar Proxy)를 통해 RPC 요청을 라우팅함
    • 하지만 하이퍼스케일 환경에서는 중앙 컨트롤러가 수백만 개의 사이드카 프록시를 직접 관리하는 것이 비효율적
    • Meta는 사이드카 프록시 방식 대신, 서비스 자체가 라우팅을 처리하는 구조로 변경
  • Meta의 ServiceRouter 아키텍처
    • 라우팅 메타데이터는 중앙 컨트롤러에서 생성하지만, 각 L7 라우터는 자체적으로 라우팅 테이블을 구성
    • Paxos 기반 데이터베이스(RIB, Routing Information Base)를 사용하여 확장성을 확보
      • 컨트롤러를 샤딩(Sharding)하여 부하를 분산하고, 특정 서비스에 대한 라우팅 테이블을 여러 컨트롤러가 병렬로 계산 가능
    • 배포 계층(Distribution Layer)은 수천 개의 RIB 복제본을 활용하여, 수백만 개의 L7 라우터에서 읽기 요청을 처리
    • 최종적으로, 각 L7 라우터는 중앙 컨트롤러의 직접 개입 없이 독립적으로 구성 가능
  • ServiceRouter의 확장성 확보 방법
    1. 상태 비저장(Stateless) 컨트롤러 채택: 컨트롤러가 특정 라우터를 직접 관리하지 않고, 단순히 전역적인 라우팅 정보를 유지
    2. 컨트롤러 샤딩(Sharding): 여러 컨트롤러가 서로 독립적으로 운영되며, 서로 다른 서비스의 라우팅 정보를 병렬로 처리 가능
    3. 비필수 기능 제거: 개별 L7 라우터 관리 기능을 컨트롤러에서 제거하고, 각 라우터가 자체적으로 관리하도록 설계
  • 결과 및 교훈
    • 중앙 집중형 컨트롤러와 분산형 데이터 플레인(Data Plane)을 결합한 아키텍처가 최적의 확장성 제공
    • 불필요한 사이드카 프록시 제거를 통해 운영 비용 및 성능 최적화
    • 전략적인 샤딩 및 상태 비저장 설계를 통해 수백만 개의 서비스 라우팅을 효과적으로 관리 가능

# [미래 전망 (Future Directions)]

  • Meta의 하이퍼스케일 인프라는 매우 복잡하지만, 본 문서에서는 핵심적인 기술적 인사이트를 요약하여 제공
  • 마지막으로, 하이퍼스케일 인프라의 미래 트렌드에 대한 전망을 공유

AI (인공지능)

  • AI 워크로드는 현재 데이터센터에서 가장 큰 비중을 차지하는 워크로드가 되었음
  • 2030년 이전에는 데이터센터 전력 소비의 절반 이상이 AI 워크로드에 사용될 것으로 예상
  • AI는 고성능 네트워크 및 높은 자원 소모량 때문에 기존 인프라 구조를 근본적으로 변화시킬 가능성이 큼
  • 과거 하이퍼스케일 인프라는 스케일 아웃(Scaling-Out) 방식(저비용 서버 대량 배치)으로 발전해왔으나,
    미래의 AI 클러스터는 스케일 업(Scaling-Up) 방식(슈퍼컴퓨터 구조)으로 변화할 가능성이 큼
    • 예: RDMA(Remote Direct Memory Access) 기반 이더넷 네트워크를 활용하여 대규모 머신러닝(ML) 훈련에 최적화
  • Meta는 PyTorch → ML 모델 → AI 칩 → 네트워크 → 데이터센터 → 서버 → 스토리지 → 전력 및 냉각까지 포함하는 풀스택 공동 설계(Co-Design)를 진행 중

도메인 특화 하드웨어 (Domain-Specific Hardware)

  • 2000년대에는 하드웨어가 점점 표준화되었지만,
    앞으로는 AI 훈련/추론, 가상화, 비디오 인코딩, 암호화, 압축, 계층형 메모리 등 다양한 특화 하드웨어가 증가할 전망
  • 하이퍼스케일 기업들은 대량 생산을 통해 맞춤형 하드웨어를 경제적으로 설계 및 배포 가능
  • 하지만, 이러한 하드웨어 다양성 증가로 인해 소프트웨어 스택의 복잡성이 커지고, 이질적인 환경을 관리하는 도전 과제가 발생할 것

엣지 데이터센터 (Edge Datacenters)

  • 메타버스(Metaverse) 및 사물인터넷(IoT) 애플리케이션 증가로 인해 엣지 데이터센터의 확장이 예상됨
  • **클라우드 게이밍(Cloud Gaming)**은 그래픽 렌더링을 사용자 기기가 아닌 엣지 데이터센터의 GPU 서버에서 수행하며,
    25ms 이하의 낮은 네트워크 지연 시간이 필수
  • 실시간 응답성이 중요한 애플리케이션의 증가로 인해 엣지 데이터센터의 수와 규모가 크게 증가할 가능성이 큼
  • 이를 효과적으로 운영하기 위해, Global-DaaC(전 세계 데이터센터를 하나의 컴퓨터처럼 운영하는 개념)를 확장하여 개발자들이 복잡한 인프라 관리를 신경 쓰지 않도록 최적화할 필요가 있음

개발자 생산성 향상 (Developer Productivity)

  • 지난 20년간 자동화 도구는 시스템 관리자의 생산성을 크게 향상시켜 서버 1대당 관리자가 담당하는 비율이 급격히 증가
  • 하지만, 소프트웨어 개발은 여전히 노동집약적이며 생산성 향상이 더딘 편
  • 앞으로는 두 가지 요인으로 인해 개발자 생산성이 급격히 증가할 전망:
    1. AI 기반 코드 생성 및 디버깅 도구 발전
    2. 도메인 특화된 완전 통합형 서버리스 프로그래밍 패러다임의 등장
  • Meta의 FrontFaaS는 이러한 서버리스 프로그래밍 방식의 예시이며,
    향후 특정 산업(예: 금융, 의료 등)에 최적화된 새로운 프로그래밍 패러다임이 등장할 것으로 예상됨

결론

  • AI를 중심으로 한 인프라 혁신이 향후 10년간 빠르게 진행될 것
  • 하이퍼스케일 기업들은 자신들의 인사이트를 공유함으로써, 커뮤니티 전체가 더 빠르게 발전할 수 있도록 기여해야 함
▲
secret3056 8일전  [-]

저 PoP는 BGP4 아니면 TCP anycast고 그걸 개인이 사용할 방법은 없겠죠..?ㅠㅜ

답변달기
▲
pribess 8일전  [-]

PoP이 BGP4 혹은 TCP anycast라는 서술이 정확히 어떤 말인지 잘 모르겠습니다만 자체 AS를 운영하냐는 말이면 맞고요
보통 일반적인 multi-region 서비스들은 geolocation based balancing에 anycast dns를 더 주로 사용합니다
네 현재로선 없습니다 멀티리전 PoP이 필요하시다면 다른 프로바이더를 이용하시면 됩니다

답변달기
▲
neo 9일전  [-]
Hacker News 의견

  • Threads 개발 후, 인프라 팀은 출시 준비를 위해 단 이틀의 공지를 받았음. 대부분의 대규모 조직은 수십 개의 상호 의존적인 팀을 포함하는 프로젝트 계획을 작성하는 데만 이틀 이상 걸림. 그러나 Meta에서는 분산된 사이트에 전쟁실을 신속히 구축하여 인프라와 제품 팀을 실시간으로 문제를 해결하도록 함. 이 앱은 출시 후 5일 만에 1억 명의 사용자에 도달하며 역사상 가장 빠르게 성장한 앱이 되었음

  • 빠르게 제품을 출시할 수 있는 능력을 유지하는 것이 인상적임. 관료주의가 증가하지 않도록 하고, 법무팀이나 다른 부서가 승인 게이트를 만들지 않도록 많은 노력이 필요함. 또는 전쟁실을 통해 신속하게 작업을 완료할 수 있는 능력이 필요함

  • FB에 있을 때, 인프라가 얼마나 강력한지 경험했음. 제품 엔지니어들이 며칠 만에 대규모 프로젝트를 구축함. 여러 팀의 기술 리더로 일했으며, 여기서 언급된 팀 중 일부는 HBase와 ZippyDB 팀임

  • ZippyDB가 처음으로 공개적으로 언급된 것이 멋짐. 개발자 효율성 향상이 언급된 것도 매우 멋짐. 매일 10,000개의 서비스가 푸시되거나 모든 커밋이 이루어짐

  • FB를 떠난 후, 비슷한 것을 찾을 수 없었음. 그래서 스타트업으로 내가 필요했던 인프라를 구축하고 있음. Batteries Included

  • 이 댓글들에 많은 냉소와 부정적인 반응이 있어 아쉬움. 많은 사람들이 Meta를 싫어하지만, 실제 기사는 나에게 경이로움. 현대 디지털 세계를 지탱하는 인프라가 얼마나 광범위하고 복잡한지 몰랐음. 이 기사를 읽고 그 규모를 보는 것이 놀라움

  • 회사가 여러 면에서 나쁠 수 있지만, 기사에 나오는 모든 것이 나에게는 놀라움

  • 나는 여러분처럼 엔지니어가 아니어서 이 기사가 여러분에게는 오래된 뉴스일 수 있지만, 나는 "와우"라고 말하지 않을 수 없었음

  • 과거의 SF 작가들에게 이 기사를 보여주면 그들도 경이로워할 것 같음

  • 놀라움. 이 모든 놀랍고 인상적인 기술과 세계 최고의 엔지니어들이 단지 사람들의 눈에 더 많은 광고를 넣기 위해 사용됨. 한숨

  • PHP 웹 프론트엔드를 "서버리스" 또는 "서비스로서의 함수" 아키텍처로 설명하는 것이 흥미로움. 관점의 문제인 것 같음. 이는 많은 엔드포인트가 배포된 단일 코드베이스를 가진 서비스임. 엔드포인트 유지보수자의 관점에서는 "서버리스"일 수 있지만, 모든 추상화가 그렇듯이 누출이 있음

  • 데이터센터 환경에서는 단순성과 고품질 의사결정 능력 때문에 중앙 집중식 컨트롤러를 선호함. 많은 경우, 중앙 집중식 제어 평면과 분산 데이터 평면을 결합한 하이브리드 접근 방식이 가장 최적임

  • 이 접근 방식은 대규모 서버 수를 가진 조직의 소프트웨어 네트워킹(서비스 메쉬) 및 스토리지(데이터베이스 운영)에 가장 최적의 설계 중 하나로 보임. IP 네트워킹이 BGP에 주로 의존하지 않고 같은 모델을 따르는 것이 놀라움

  • 로컬 캐싱을 사용하여 L7 라우터의 부하를 줄이고 데이터베이스 쿼리의 지연 시간을 개선할 것으로 예상됨. 클라이언트는 캐시를 무효화하고 합리적인 시간 초과 후 서비스 메쉬에 다시 조회할 수 있음

  • 빠르게 개발된 서버리스 함수와 지속적인 배포가 결합되어, 누구나 전체 코드베이스에서 편집할 수 있는 것이 디스토피아적 악몽처럼 들림. 디버깅과 버그 찾기에 필요한 로깅의 양이 극단적임

  • 서버리스 함수를 작성하는 데 Erlang을 사용하는 것은 BEAM이 제공할 수 있는 모든 큰 이점을 피하는 것 같음

  • 제품 엔지니어들은 주로 PHP, Python, Erlang에서 상태 없는 서버리스 함수로 코드를 작성함. 이는 단순성, 생산성, 반복 속도에서 이점이 있음

  • 개발자 생산성을 높이기 위해 Meta는 지속적인 배포를 보편적으로 채택하고, 더 많은 개발자가 전통적인 서비스 코드보다 서버리스 함수를 작성할 수 있도록 함

  • 비 AI 컴퓨팅 작업에 대해, 단일 서버 유형만 제공하며, 하나의 CPU와 동일한 양의 DRAM(이전에는 64GB, 현재는 256GB)을 장착함. 이것이 업계 전반에 걸쳐 일반적인 것인지, Meta에만 일반적인 것인지 궁금함

  • 이미지가 CDN109에 캐시되지 않았을 때, 사용자가 요청하면 CDN109는 요청을 인근 PoP로 전달함. PoP는 요청을 데이터센터 지역의 로드 밸런서로 전달하고, 로드 밸런서는 스토리지 시스템에서 이미지를 가져옴

  • 1MB 이미지를 요청할 때, 느린 연결로 100ms 지연 시간으로 1MB 이미지를 제공하는 것이 여러 번의 왕복과 증가하는 지연 시간을 거치는 것보다 빠르지 않을까?

  • Meta의 시스템을 통해 요청한다고 가정하면, 결국 같은 데이터센터로 가고 FTL 기술이 없다고 가정할 때

  • 하이퍼스케일러와의 명시적인 비교가 특히 흥미로움. 그들이 자체 퍼블릭 클라우드를 출시하기 위한 준비인지 궁금함. Meta의 누군가가 의견을 말해주길 바람

답변달기