Meta’s Hyperscale Infrastructure. Overview and Insight.

Meta’s Hyperscale Infrastructure: Overview and Insights

Meta의 전 지구적 규모의 컴퓨팅 인프라를 살펴보고, “모든 글로벌 데이터센터를 하나의 컴퓨터처럼 운영한다”는 비전을 실현하는 과정에서 얻은 주요 교훈을 소개합니다.

Alibaba, Amazon, ByteDance, Google, Meta, Microsoft, Tencent와 같은 하이퍼스케일러들은 전 세계 사용자에게 클라우드, 웹, 또는 모바일 서비스를 제공하기 위해 지구 규모의 인프라를 구축해 왔습니다. 대부분의 실무자들이 이러한 하이퍼스케일 인프라를 직접 구축하지는 않지만, 이에 대해 조금이라도 배우는 것이 유익하다고 생각합니다. 역사적으로, 많은 널리 사용되는 기술들이 고급 환경에서 비롯되었습니다. 1960년대의 메인프레임과 최근 20년간의 하이퍼스케일 인프라가 그 예입니다. 예를 들어, 가상 메모리는 메인프레임에서 처음 등장했으며, 현재는 스마트워치에서도 일반적으로 사용되고 있습니다. 마찬가지로, Kubernetes는 Google에서, PyTorch는 Facebook에서 개발되었지만, 현재는 규모를 불문하고 다양한 조직에서 채택하고 있습니다. 이러한 특정 기술들뿐만 아니라, 하이퍼스케일 인프라에서 얻을 수 있는 원칙과 교훈은 실무자들이 더 나은 시스템을 구축하는 데 도움이 될 수 있습니다. 이 글에서는 Meta의 하이퍼스케일 인프라에 대한 개요를 제공하며, 특히 시스템 소프트웨어 개발 과정에서 얻은 주요 통찰을 중점적으로 다룹니다. 관련된 부분에서는 퍼블릭 클라우드와의 차이점을 강조하며, 서로 다른 제약 조건이 어떻게 차별화된 최적화를 이끌었는지 설명합니다. 이 글에서 다루는 많은 지식들은 이미 업계와 연구 커뮤니티에서 공유되고 실천되어 왔으며, Meta의 이전 연구에서도 다룬 바 있습니다. 그러나 이 글의 주요 기여는 하이퍼스케일 인프라를 종합적으로 이해할 수 있도록 전체적인 관점을 제공하는 것입니다.

Key insight

• Meta의 엔지니어링 문화는 신속한 개발, 기술 개방성, 실제 환경에서의 연구, 그리고 공유 인프라를 중시합니다.
• 개발자의 생산성을 높이기 위해 Meta는 보편적으로 지속적 배포(Continuous Deployment)를 도입했으며, 전통적인 서비스 코드 대신 서버리스(Serverless) 함수를 더 많이 작성할 수 있도록 지원하고 있습니다.
• 하드웨어 비용 절감을 위해 Meta는 데이터센터 규모에서 하드웨어-소프트웨어 공동 설계를 활용하며, 개별 클러스터에 국한되지 않고 글로벌 데이터센터 전체에서 워크로드 마이그레이션을 포함한 자원 할당을 자동으로 최적화합니다.
• Meta의 AI 전략은 PyTorch부터 AI 가속기, 네트워크, 그리고 Llama와 같은 머신러닝 모델까지 전체 스택을 공동 설계하는 것을 포함합니다.

1. Engineering Culture

Meta의 인프라를 자세히 살펴보기 전에, 먼저 회사의 엔지니어링 문화의 몇 가지 중요한 측면을 강조하려 합니다. 조직의 문화는 기술에 큰 영향을 미치기 때문입니다.

Move fast

Facebook은 창립 초기부터 “빠르게 움직이기(move-fast)” 문화를 깊이 뿌리내리고 유지해 왔으며, 민첩성과 빠른 반복(iteration)을 강조합니다. 이 철학은 지속적 소프트웨어 배포(continuous deployment)에 대한 강한 의지에서 분명하게 드러납니다. 이를 통해 최신 코드를 가능한 한 빨리 프로덕션 환경에 배포합니다. 또한, 제품 엔지니어들은 주로 PHP, Python, Erlang에서 상태를 가지지 않는(stateless) 서버리스(serverless) 함수를 사용하여 코드를 작성합니다. 이는 코드의 단순성, 생산성, 그리고 반복 속도를 높이는 데 유리하기 때문입니다. 팀은 긴 재계획(replanning) 과정 없이도 실행 우선순위를 신속하게 변경할 수 있으며, 애매한 문제들은 반복적인 실행 과정에서 해결해 나가는 방식을 취합니다. 이러한 방식은 팀이 변화하는 시장 상황에 빠르게 적응하고, 새로운 제품을 신속하게 출시할 수 있도록 합니다.

Technology openness

Meta는 내부적으로나 외부적으로 기술 개방성을 적극적으로 추구합니다. 내부적으로, Meta는 모노레포(monorepo) 방식을 채택하여 모든 프로젝트의 코드를 단일 리포지토리에 저장합니다. 이를 통해 코드 검색과 재사용을 용이하게 하고, 팀 간 협업을 촉진합니다. 다른 조직들도 모노레포를 사용하지만, 개방성의 정도는 조직마다 다릅니다. 일부 조직에서는 각 프로젝트에 지정된 소유자가 있어, 코드 변경을 승인할 수 있는 권한이 오직 소유자에게만 주어집니다. 다른 사람들은 변경을 제안할 수는 있지만, 최종 결정권은 소유자가 갖습니다. 반면, Meta의 대부분의 프로젝트는 이러한 엄격한 소유권 규칙을 적용하지 않습니다(일부 예외를 제외하고). 이러한 개방성은 팀 간 협업과 코드 재사용을 장려하며, 유사한 기술을 중복 개발하는 것을 방지합니다.

Meta에서는 엔지니어들이 모노레포의 메인라인(mainline)에 직접 코드 변경 사항을 커밋하며, 소프트웨어 배포도 안정적인 브랜치가 아니라 최신 코드가 포함된 메인라인에서 컴파일됩니다. 예를 들어, RPC 라이브러리와 같은 널리 사용되는 라이브러리가 업데이트되면, 이를 사용하는 모든 애플리케이션의 다음 릴리즈는 자동으로 최신 버전의 라이브러리와 함께 컴파일됩니다.

외부적으로, Meta의 기술 개방성에 대한 노력은 Open Compute Project를 통한 오픈소스 하드웨어 디자인과, PyTorch, Llama, Presto, RocksDB, Cassandra와 같은 오픈소스 소프트웨어 프로젝트를 통해 나타납니다. 또한, Meta의 많은 인프라 기술들은 연구 논문을 통해 공유되었으며, 이 글에서 참고할 수 있는 여러 사례가 포함되어 있습니다.

Research in production

실제 환경에서의 연구. Meta의 하이퍼스케일 인프라는 지속적인 혁신을 요구하지만, 대부분의 하이퍼스케일러들과 달리 Meta는 전담 시스템 연구소를 운영하지 않습니다. 대신, Meta의 모든 시스템 연구 논문은 실제 운영 시스템을 개발하는 팀에 의해 작성됩니다. 이 팀들은 대규모 운영 환경에서의 도전적인 문제들을 해결하는 과정에서 최첨단 기술을 발전시키며, 이러한 경험을 바탕으로 효과적인 해결책을 연구 논문으로 정리합니다. 이러한 접근 방식은 연구에서 다루는 문제가 실제 문제이며, 해결책이 대규모 환경에서도 효과적으로 작동한다는 점을 보장합니다. 이는 성공적인 시스템 연구의 핵심 기준과 잘 부합합니다.

Common infrastructure

일부 조직들은 개별 팀이 자체적으로 기술 스택을 결정하도록 권한을 부여합니다. 그러나 Meta는 표준화와 글로벌 최적화를 우선시합니다. 하드웨어 측면에서, 다양한 제품을 지원하는 서버들은 모두 공유 서버 풀에서 할당됩니다. 또한, AI가 아닌 일반 컴퓨팅 워크로드의 경우, 단일 서버 유형만을 제공하며, 하나의 CPU와 동일한 용량의 DRAM(이전에는 64GB, 현재는 256GB)을 탑재하고 있습니다. 다양한 고객 애플리케이션을 지원하기 위해 여러 종류의 서버를 제공해야 하는 퍼블릭 클라우드와 달리, Meta는 애플리케이션을 하드웨어에 맞게 최적화할 수 있어, 서버 유형의 불필요한 확산을 방지할 수 있습니다.

소프트웨어 측면에서도 표준화가 적용됩니다. 예를 들어, 과거에는 Meta의 다양한 제품이 키-값 저장소로 Cassandra, HBase, ZippyDB를 사용했지만, 현재는 모두 ZippyDB로 통합되었습니다. 또한, 소프트웨어 배포, 구성 관리, 서비스 메시, 사전 성능 테스트, 운영 중 성능 모니터링, 운영 중 부하 테스트와 같은 공통 기능들은 모두 보편적으로 사용되는 도구를 통해 지원됩니다.

표준화 외에도, 공통 인프라를 구축하는 데 있어 핵심 원칙은 단일(monolithic) 솔루션보다 재사용 가능한 구성 요소를 선호하는 것입니다. 이러한 원칙의 좋은 예는 Meta의 분산 파일 시스템인 Tectonic에서의 구성 요소 재사용 체계입니다. Tectonic은 메타데이터를 저장하기 위해 분산 키-값 저장소인 ZippyDB를 사용함으로써 확장성을 향상시킵니다. ZippyDB는 데이터 샤드를 관리하기 위해 공통 샤딩 프레임워크인 Shard Manager를 사용하며, Shard Manager는 다시 샤드 검색과 요청 라우팅을 위해 Meta의 서비스 메시인 ServiceRouter에 의존합니다. 마지막으로, ServiceRouter는 사이트의 지속적인 운영에 필수적인 서비스 검색 및 구성 데이터를 고신뢰성, 무의존성(zero-dependency)의 데이터 저장소인 Delos에 저장합니다. 따라서, 구성 요소 재사용 체계는 Tectonic → ZippyDB → Shard Manager → ServiceRouter → Delos로 이루어집니다. 이 모든 재사용 가능한 구성 요소들은 다양한 다른 용례에서도 활용됩니다. 반면, 널리 사용되는 오픈소스 분산 파일 시스템인 HDFS는 이러한 모든 구성 요소를 내부적으로 구현하는 단일(monolithic) 시스템입니다.

Culture case study: The Threads app

Twitter/X와 자주 비교되는 Threads 앱의 개발 과정은 앞서 언급한 Meta의 문화를 잘 보여줍니다. “빠르게 움직이기” 문화를 강조하며, 소규모 팀이 스타트업과 같은 환경에서 단 5개월의 기술 개발을 통해 Threads를 완성했습니다. 게다가, 개발이 완료된 후 인프라 팀은 프로덕션 배포를 준비할 시간이 단 이틀밖에 주어지지 않았습니다. 대부분의 대기업에서는 수십 개의 상호 의존적인 팀이 참여하는 프로젝트 계획을 작성하는 데만도 이틀 이상이 걸리며, 실행까지는 훨씬 더 오랜 시간이 소요됩니다. 그러나 Meta에서는 분산된 여러 지역에 즉시 ‘워룸(war room)’을 마련하여 인프라 팀과 제품 팀을 한자리에 모으고 실시간으로 문제를 해결했습니다. 이처럼 촉박한 일정에도 불구하고, Threads는 출시 후 단 5일 만에 1억 명의 사용자를 확보하며 역사상 가장 빠르게 성장한 앱이 되었습니다.

공통 인프라는 팀이 Threads를 신속하게 구현하고 안정적으로 확장하는 데 중요한 역할을 했습니다. Threads는 Instagram의 Python 백엔드를 그대로 재사용했으며, 소셜 그래프 데이터베이스, 키-값 저장소, 서버리스 플랫폼, 머신러닝(ML) 학습 및 추론 플랫폼, 그리고 모바일 앱의 구성 관리 프레임워크와 같은 Meta의 공통 인프라 구성 요소를 활용했습니다.

Meta의 내부 기술 개방성, 즉 모노레포(monorepo) 방식을 활용함으로써 Threads는 Instagram의 일부 애플리케이션 코드를 재사용하여 개발 속도를 높일 수 있었습니다. 외부 기술 개방성 측면에서, Threads는 다른 애플리케이션과의 상호 운용성을 위해 오픈 소셜 네트워크 프로토콜인 ActivityPub과의 통합을 목표로 하고 있습니다. 또한, 우리는 Threads를 신속하게 개발한 경험을 공개적으로 공유했습니다.

Insight 1: 많은 도전 과제가 있음에도 불구하고, 대규모 조직에서도 ‘빠르게 움직이는’ 문화를 유지하면서, 공통 인프라를 활용하고, 엄격한 코드 소유권 규칙 없이 모노레포를 공유하는 것이 가능하다는 점이 입증되었습니다.

End-to-End User Request Flow

이제 Meta의 인프라 기술을 자세히 살펴보겠습니다. Meta의 제품들은 공통 서비스 인프라에 의해 지원됩니다. 이 인프라의 전체적인 개요를 제공하기 위해, 사용자 요청이 처음부터 끝까지 어떻게 처리되는지 설명하며, 이 과정에서 사용되는 모든 구성 요소를 자세히 다룹니다.

Request Routing

사용자가 facebook.com에 요청을 보낼 때, Meta의 DNS 서버는 해당 요청을 Meta가 운영하는 소규모 엣지 데이터센터(POP, Point of Presence)로 매핑된 IP 주소를 동적으로 반환합니다. 이는 그림 1에 나와 있습니다. 이 동적 DNS 매핑은 선택된 PoP가 사용자와 가까운 위치에 있도록 보장하며, 동시에 여러 PoP 간 부하를 균형 있게 분산시킵니다. 사용자의 TCP 연결은 PoP에서 종료되며, PoP는 Meta의 데이터센터와 별도의 장기 지속적인 TCP 연결을 유지합니다. 이러한 분할 TCP(split-TCP) 설정은 여러 가지 이점을 제공합니다. 특히, PoP와 데이터센터 간에 미리 설정된 연결을 재사용함으로써 TCP 연결 설정 지연 시간을 줄일 수 있습니다. 일반적으로 PoP는 수백 대의 서버를 보유하고 있으며, 일부 PoP는 수천 대의 서버를 갖추고 있을 수도 있습니다. 전 세계에 수백 개의 PoP가 배치되어 있어, 대부분의 사용자가 가까운 PoP를 통해 서비스받을 수 있도록 하여 네트워크 지연 시간을 최소화합니다.

Static-Content Caching

사용자가 이미지나 동영상과 같은 정적 콘텐츠를 요청하면, 해당 콘텐츠가 이미 PoP에 캐시되어 있는 경우 PoP에서 직접 제공될 수 있습니다. 또한, 정적 콘텐츠는 콘텐츠 전송 네트워크(CDN)에서 캐시될 수도 있으며, 이는 그림 1에 나타나 있습니다. Meta 제품의 트래픽이 특정 인터넷 서비스 제공업체(ISP) 네트워크에서 대량으로 발생하는 경우, Meta는 해당 ISP와 상호 이익이 되는 파트너십을 구축하려 합니다. 이를 위해, ISP 네트워크 내에 Meta 네트워크 장비를 배치하여 정적 콘텐츠를 캐싱하도록 하고, 이를 통해 CDN 사이트를 형성합니다. 일반적인 CDN 사이트는 수십 대의 서버를 보유하고 있으며, 일부 사이트는 100대 이상의 서버를 운영하기도 합니다. 전 세계 수천 개의 CDN 사이트가 Meta의 CDN을 구성하여 정적 콘텐츠를 배포하는 역할을 합니다.

Meta의 제품들은 URL 재작성(URL rewrite) 기법을 사용하여 사용자 요청을 가까운 CDN 사이트로 리디렉션합니다. Meta의 제품이 사용자가 정적 콘텐츠에 접근할 수 있도록 URL을 제공할 때, URL을 재작성하여 예를 들어 facebook.com/image.jpg를 CDN109.meta.com/image.jpg로 변경합니다. 사용자가 해당 이미지를 요청했을 때, CDN109에 이미지가 캐시되어 있지 않다면, CDN109는 요청을 가까운 PoP로 전달합니다. PoP는 이후 요청을 데이터센터 지역에 있는 로드 밸런서로 전달하며, 로드 밸런서는 스토리지 시스템에서 해당 이미지를 가져옵니다. 반환 경로에서는 PoP와 CDN 사이트가 모두 해당 이미지를 캐싱하여 향후 재사용할 수 있도록 합니다.

Dynamic-Content Request Routing

사용자가 뉴스피드와 같은 동적 콘텐츠를 요청하면, PoP는 이를 데이터센터 지역으로 전달합니다. 대상 데이터센터 지역의 선택은 트래픽 엔지니어링 도구에 의해 결정되며, 이 도구는 데이터센터의 용량과 네트워크 지연 시간과 같은 요소를 고려하여 PoP에서 데이터센터로의 글로벌 트래픽을 최적 분배하도록 주기적으로 계산합니다.

PoP에서 데이터센터로 가는 트래픽은 Meta의 사설 광역 네트워크(WAN)를 통해 이동하며, 이 WAN은 전 세계의 Meta PoP와 데이터센터를 연결하는 수만 마일 길이의 광섬유 네트워크로 구성됩니다. Meta의 데이터센터와 PoP 간 내부 네트워크 트래픽은 사용자와 PoP 간의 외부 트래픽보다 몇 배나 더 많으며, 이는 주로 데이터센터 간 데이터 복제 및 마이크로서비스 간의 상호작용 때문입니다. 사설 WAN은 내부 트래픽을 처리하기 위해 높은 대역폭을 제공합니다.

Insight 2: Meta의 글로벌 인프라는 CDN 사이트, 엣지 데이터센터, 그리고 메인 데이터센터로 구성됩니다. 데이터센터 간 내부 트래픽의 양이 매우 크기 때문에, Meta는 공용 인터넷에 의존하는 대신 데이터센터를 연결하는 사설 WAN을 구축했습니다.

Infrastructure topology

아래 표는 앞서 언급한 인프라 구성 요소들을 요약한 것입니다. 전 세계적으로 수십 개의 데이터센터 지역, 수백 개의 엣지 데이터센터(PoP), 그리고 수천 개의 CDN 사이트가 존재합니다. 각 데이터센터 지역에는 반경 몇 마일 내에 여러 개의 데이터센터가 위치해 있습니다. 각 데이터센터는 전력 분배를 위해 최대 12개의 메인 스위치보드(MSB)를 사용하며, 이들은 주요 하위 데이터센터 장애 도메인 역할도 합니다. MSB가 고장 나면 1만~2만 대의 서버가 사용 불가능해질 수 있습니다.

Edge Network

PoP는 인터넷상의 여러 개의 자율 시스템(Autonomous Systems, AS)과 연결되어 있으며, 일반적으로 사용자 네트워크에 도달할 수 있는 여러 개의 경로를 가집니다. PoP와 사용자 간 경로를 선택할 때, 기본적으로 BGP(Border Gateway Protocol)는 네트워크 용량과 성능을 고려하지 않습니다. 그러나 PoP 네트워크는 이러한 요소들을 고려하여 최적의 경로를 네트워크 프리픽스(prefix)에 광고합니다.

Datacenter Network

데이터센터 내의 서버들은 데이터센터 패브릭(datacenter fabric)으로 상호 연결되며, 네트워크 스위치는 3계층 Clos 토폴로지를 형성합니다. 이 구조는 최상위 레벨에 더 많은 스위치를 추가함으로써 점진적으로 확장할 수 있습니다. 충분한 수의 최상위 스위치를 갖춘 경우, 이 패브릭 구조는 블로킹 없는(non-blocking) 및 초과 가입(over-subscription) 없는 네트워크를 제공하여, 모든 서버 간의 통신이 최대 NIC 대역폭에서 원활하게 이루어질 수 있도록 합니다. 우리는 데이터센터 내에서 네트워크 초과 가입을 제거하는 방향으로 나아가고 있습니다.

Regional Network

패브릭 애그리게이터(fabric aggregator)는 지역 내 여러 데이터센터를 연결하며, 이를 Meta의 사설 WAN과도 연결합니다. 패브릭 애그리게이터는 ‘Fat Tree’와 유사한 토폴로지를 사용하며, 점진적으로 더 많은 스위치를 추가하여 대역폭을 확장할 수 있도록 합니다. 우리는 지역 내 데이터센터 간 통신이 병목 현상을 일으키지 않도록, 지역 네트워크에서 네트워크 초과 가입을 대폭 줄이는 것을 목표로 하고 있습니다. 이러한 구조를 통해, 머신러닝(ML) 학습을 제외한 대부분의 서비스는 성능 저하를 걱정하지 않고 지역 내 여러 데이터센터에 분산될 수 있습니다.

Request Processing

사용자의 요청이 데이터센터 지역에 도착하면, 그림 2에 나타난 경로를 따라 처리됩니다. 로드 밸런서는 사용자 요청을 수만 대의 서버에 분산하며, 이 서버들은 ‘프론트엔드 서버리스 함수(frontend serverless functions)’를 실행합니다. 사용자 요청을 처리하기 위해, 프론트엔드 서버리스 함수는 여러 백엔드 서비스를 호출할 수 있으며, 일부 백엔드 서비스는 추가적으로 ‘ML 추론(ML inference)’을 실행하여 광고나 뉴스피드 콘텐츠 추천을 가져올 수도 있습니다.

프론트엔드 서버리스 함수는 실행 도중 ‘이벤트 큐(event queue)’에 이벤트를 추가할 수 있으며, 이는 ‘이벤트 기반 서버리스 함수(event-driven serverless functions)’가 비동기적으로 처리합니다. 예를 들어, 사용자가 사이트에서 특정 작업을 수행한 후 확인 이메일을 보내는 것이 하나의 이벤트가 될 수 있습니다. 프론트엔드 서버리스 함수는 사용자 경험에 직접적인 영향을 미치므로 엄격한 지연 시간 서비스 수준 목표(SLO)를 따릅니다. 반면, 이벤트 기반 서버리스 함수는 사용자 응답 시간에 영향을 주지 않고 비동기적으로 실행되며, 지연 시간보다는 처리량과 하드웨어 활용도를 최적화하는 데 초점을 맞춥니다. 프론트엔드 서버리스 함수를 실행하는 서버와 이벤트 기반 서버리스 함수를 실행하는 서버의 비율은 대략 5:1입니다.

Offline Processing

그림 2의 오른쪽에 있는 구성 요소들은 다양한 오프라인 처리를 수행하며, 이는 왼쪽의 온라인 처리를 보조하는 역할을 합니다. 온라인 처리와 오프라인 처리를 분리하면, 각각의 작업 부하 특성에 따라 독립적인 최적화가 가능해집니다. 사용자 요청을 처리하는 동안, 프론트엔드 서버리스 함수와 백엔드 서비스는 광고 클릭률(ad-click-through)이나 동영상 시청 통계(video-watch metrics)와 같은 다양한 데이터를 ‘데이터 웨어하우스(data warehouse)’에 저장합니다. 이 데이터는 다양한 오프라인 처리 과정에서 활용됩니다. 예를 들어, ‘ML 학습(ML training)’은 이 데이터를 활용하여 머신러닝 모델을 업데이트하고, ‘스트림 처리(stream processing)’는 데이터를 이용해 사이트에서 가장 많이 논의되는 주제를 업데이트한 후, 이를 ‘데이터베이스(databases)’ 및 ‘캐시(caches)’에 저장합니다. 이러한 데이터는 이후 온라인 사용자 요청을 처리할 때 사용됩니다. 또한, Spark와 Presto를 기반으로 하는 ‘배치 분석(batch analytics)’은 사이트에서 발생하는 새로운 활동에 따라 친구 추천을 업데이트하는 등의 작업을 주기적으로 수행할 수 있습니다. 마지막으로, 데이터 웨어하우스에서 이루어지는 데이터 업데이트는 이벤트 기반 서버리스 함수를 실행하는 주요 이벤트 소스로 활용됩니다.

Insight 3: 데이터 웨어하우스를 중간 계층으로 활용하여 온라인 처리와 오프라인 처리를 분리하면, 아키텍처가 단순해지고 각각의 처리를 독립적으로 최적화할 수 있습니다.

Boosting Developer Productivity

공유 인프라의 주요 목적 중 하나는 개발자의 생산성을 향상시키는 것입니다. 지속적인 소프트웨어 배포와 서버리스 함수가 개발자의 생산성을 높이는 데 도움이 된다는 것은 널리 알려져 있지만, Meta는 이러한 접근 방식을 극한까지 발전시켰습니다.

Continuous Deployment

Meta의 ‘빠르게 움직이기(move-fast)’ 문화에 맞춰, 우리는 코드와 구성(configuration)의 지속적 배포를 극도로 빠르고 대규모로 운영합니다. 이를 통해 개발자는 새로운 기능과 버그 수정 사항을 신속하게 배포하고, 즉각적인 피드백을 받아 빠르게 반복(iterate)할 수 있습니다. 구성 변경의 경우, Meta의 구성 관리 도구(configuration-management tool)는 매일 10만 개 이상의 실시간 변경 사항을 프로덕션 환경에 배포하며, 이는 약 10,000개의 서비스와 수백만 대의 서버에 영향을 미칩니다. 이러한 변경 사항은 로드 밸런싱, 기능 롤아웃(feature rollout), A/B 테스트, 과부하 보호(overload protection) 등의 다양한 작업을 지원합니다. Meta에서는 코드를 작성하는 거의 모든 엔지니어가 프로덕션 환경에서 실시간으로 구성 변경을 수행합니다. Meta는 ‘코드로서의 구성(Configuration-as-Code)’ 패러다임을 따르며, 수동 구성 변경 사항은 코드 리포지토리에 커밋되기 전에 동료 코드 리뷰(peer code review)를 거칩니다. 변경 사항이 커밋되면 즉시 지속적 배포 파이프라인(continuous deployment pipeline)에 들어갑니다. 몇 초 안에 업데이트된 구성은 수백만 개의 구독된 Linux 프로세스로 푸시될 수 있으며, 이를 통해 업콜(upcall) 알림이 트리거됩니다. 이러한 프로세스는 재시작 없이 즉시 런타임 동작을 조정할 수 있습니다. 수동 변경뿐만 아니라, 로드 밸런싱과 같은 작업을 위해 자동화 도구도 구성 변경을 수행합니다. 코드 변경 사항의 경우, Meta의 배포 도구는 30,000개 이상의 파이프라인을 관리하며 소프트웨어 업그레이드를 배포합니다. Meta에서 97%의 서비스는 수동 개입 없이 완전 자동화된 소프트웨어 배포 방식을 채택하고 있습니다. 이 중 55%는 지속적 배포(Continuous Deployment)를 활용하여 자동화된 테스트를 통과한 모든 코드 변경 사항을 즉시 프로덕션에 배포하며, 나머지 42%는 주로 매일 또는 매주 고정된 일정에 따라 자동 배포됩니다. 그림 2에 나오는 프론트엔드 서버리스 함수를 예로 들어 보겠습니다. 이 함수들은 50만 대 이상의 서버에서 실행되며, 10,000명 이상의 제품 개발자가 매일 코드를 변경하고, 하루에도 수천 건의 코드 커밋이 이루어집니다. 이처럼 매우 역동적인 환경에서도, 모든 서버리스 함수의 새로운 버전은 3시간마다 프로덕션에 배포됩니다. Meta의 네트워크 소프트웨어도 일반적인 서비스처럼 설계되었으며, 빈번한 업데이트를 위해 최적화되어 있습니다. 예를 들어, Meta의 사설 WAN은 네트워크 토폴로지를 여러 개의 병렬 평면(plane)으로 나누며, 각 평면은 일정 부분의 트래픽을 담당하고 자체 컨트롤러를 갖추고 있습니다. 이를 통해 컨트롤러 소프트웨어를 자주 업데이트할 수 있습니다. 개발자는 특정 평면의 트래픽을 우회시켜 해당 평면에서만 새로운 제어 알고리즘을 배포하고 실험할 수 있으며, 다른 평면에는 영향을 주지 않습니다. 마찬가지로, Meta의 네트워크 스위치 소프트웨어도 일반적인 서비스처럼 자주 업데이트됩니다. 네트워크 스위치의 ASIC에서 제공하는 ‘웜 부트(warm boot)’ 기능을 활용하면, 스위치 소프트웨어가 업데이트되는 동안에도 데이터 플레인은 트래픽을 계속 전달할 수 있습니다. 빈번한 코드 및 구성 업데이트는 애자일 소프트웨어 개발을 가능하게 하지만, 사이트 장애 발생 위험도 증가시킵니다. 이러한 위험을 해결하기 위해, Meta는 테스트, 단계적 롤아웃(staged rollouts), 그리고 업데이트 과정에서의 상태 점검(health checks)에 많은 투자를 하고 있습니다. 과거에 Meta는 코드 배포 자동화를 강화하는 회사 차원의 캠페인을 진행했으며, 상태 점검(health checks)으로 보호되는 완전 자동화 코드 배포의 채택률을 12%에서 97%로 끌어올렸습니다. 비슷하게, 모든 구성 변경 사항이 자동화된 카나리아 테스트(canary tests)를 거치도록 하는 새로운 정책을 도입하여 구성 안전성을 보장했습니다. 결과적으로, 지속적 배포(Continuous Deployment)에 대한 이러한 투자는 개발자의 생산성을 크게 향상시키므로 충분히 가치 있다고 판단됩니다.

Insight 4 1만 개 이상의 서비스를 운영하는 대규모 조직에서도, 지속적 배포(Continuous Deployment)를 극단적인 규모와 속도로 적용하는 것이 충분히 가능하다는 것이 입증되었습니다.

Serverless Functions

서버리스 함수(Function-as-a-Service, FaaS)의 광범위한 사용은 개발자 생산성을 향상시키는 또 다른 핵심 요소입니다. 전통적인 백엔드 서비스는 임의적인 복잡성을 가질 수 있는 반면, FaaS는 상태를 유지하지 않으며 단순한 함수 인터페이스를 구현합니다. 각 FaaS 호출은 독립적으로 관리되며, 외부 데이터베이스에 저장된 상태를 제외하면 다른 동시 실행 중인 호출에 영향을 주지 않습니다. FaaS는 상태를 유지하지 않기 때문에, 데이터베이스 접근 시 우수한 성능을 확보하기 위해 외부 캐싱 시스템에 크게 의존합니다. 개발자는 FaaS 코드를 작성한 후, 코드 배포 및 부하 변화에 따른 자동 확장(auto-scaling)과 같은 나머지 작업을 자동화된 인프라가 처리하도록 맡깁니다. 이러한 단순성 덕분에 Meta의 10,000명 이상의 제품 개발자는 인프라 관리에 대한 걱정 없이 제품 로직에만 집중할 수 있습니다. 또한, 제품 개발자가 과도하게 자원을 할당(over-provisioning)하여 발생하는 하드웨어 낭비를 방지할 수 있습니다. Meta는 개발자 생산성을 극대화하기 위해 FaaS 활용을 극한까지 끌어올렸습니다. Meta의 약 10,000명 이상의 엔지니어 중, FaaS 코드를 작성하는 엔지니어의 수는 자체 운영하는 일반 서비스 코드를 작성하는 엔지니어보다 약 50% 더 많습니다. 이러한 성공은 제품 엔지니어가 인프라 관리를 신경 쓰지 않도록 한 점뿐만 아니라, FaaS에 최적화된 통합 개발 환경(IDE)의 높은 사용성 덕분이기도 합니다. 이 IDE는 고수준(high-level) 언어 구조를 통해 소셜 그래프 데이터베이스 및 다양한 백엔드 시스템에 쉽게 접근할 수 있도록 지원합니다. 또한, 지속적 통합 테스트(Continuous Integration Tests)를 통해 빠른 피드백을 제공합니다. 그림 2에서 볼 수 있듯이, Meta는 두 개의 FaaS 플랫폼을 운영합니다. 하나는 프론트엔드 서버리스 함수(Frontend Serverless Functions)용이고, 다른 하나는 이벤트 기반 서버리스 함수(Event-Driven Serverless Functions)용입니다. 이 두 플랫폼을 각각 FrontFaaS와 XFaaS라고 부릅니다. FrontFaaS 함수는 PHP로 작성되며, Meta는 Python, Erlang, Haskell을 지원하는 FaaS 플랫폼도 운영하고 있습니다. 수십억 명의 사용자로 인해 발생하는 높은 부하를 처리하기 위해, Meta는 50만 대 이상의 서버를 운영하며 PHP 런타임을 항상 실행 상태로 유지합니다. 사용자 요청이 도착하면, 요청은 즉시 처리할 수 있도록 이러한 서버 중 하나로 라우팅되며, 콜드 스타트(cold start) 지연이 발생하지 않습니다. 사이트의 부하가 낮을 때는 자동 확장(auto-scaling) 기능을 사용하여 일부 FrontFaaS 서버를 해제하고, 이를 다른 서비스에서 사용할 수 있도록 합니다. XFaaS는 FrontFaaS와 여러 가지 유사한 점을 가지지만, 가장 큰 차이점은 사용자와 직접 연결되지 않는(non-user-facing) 함수를 실행하며, 서브초(subsecond) 응답 시간이 필요하지 않지만 부하가 급격하게 변하는 패턴을 보인다는 점입니다. XFaaS는 최대 부하 상태에서 자원을 과도하게 할당(overprovisioning)하는 것을 방지하기 위해 여러 최적화 기법을 적용합니다. 여기에는 지연을 허용할 수 있는 함수 실행을 비혼잡 시간대로 연기하는 것, 전역적으로 지역 간 함수 호출 부하를 분산하는 것, 그리고 할당량(quota)에 기반한 제한(throttling) 구현이 포함됩니다. Meta의 제품 개발자들은 2000년대 후반부터 FaaS를 주요 코딩 패러다임으로 사용해 왔으며, 이는 ‘FaaS’라는 용어가 널리 알려지기 전부터 적용되어 왔습니다. 업계의 다른 서버리스 플랫폼과 비교했을 때, Meta의 서버리스 플랫폼이 가지는 독특한 점은 여러 개의 함수를 동일한 Linux 프로세스에서 동시에 실행할 수 있도록 한다는 것입니다. 이는 퍼블릭 클라우드가 서로 다른 고객 간 격리 강화를 위해 가상 머신당 하나의 함수만 실행하는 방식과는 차별화됩니다. 이 방식은 하드웨어 효율성을 극대화하는 데 기여합니다.

Insight 5: 서버리스 함수는 Meta의 제품 개발에서 기본적인 코딩 패러다임이 되었습니다. Meta의 10,000명 이상의 엔지니어가 서버리스 함수를 작성하며, 이는 일반적인 서비스 코드를 작성하는 엔지니어 수보다 50% 더 많습니다.

Reducing Hardware Costs

공유 인프라의 또 다른 주요 목적은 개발자 생산성을 향상시키는 것뿐만 아니라 하드웨어 비용을 절감하는 것입니다. 이 섹션에서는 소프트웨어 솔루션이 하드웨어 비용 절감에 어떻게 기여하는지 몇 가지 사례를 소개합니다.

All Global Datacenters as a Computer

대부분의 인프라는 지리적으로 분산된 데이터센터의 복잡한 관리를 사용자에게 맡깁니다. 사용자는 서비스의 복제본 개수를 수동으로 결정하고, 배포할 지역을 선택하며, 동시에 서비스 수준 목표(SLO)를 충족해야 합니다. 이러한 복잡성은 과도한 자원 할당(overprovisioning), 지역 간 부하 불균형, 그리고 워크로드 변화 및 데이터센터 자원 공급에 맞춘 적절한 마이그레이션 부족으로 인해 하드웨어 낭비를 초래합니다. 반면, Meta는 ‘데이터센터를 하나의 컴퓨터처럼 운영(The Datacenter as a Computer, DaaC)’하는 방식을 넘어서 ‘모든 글로벌 데이터센터를 하나의 컴퓨터처럼 운영(All Global Datacenters as a Computer, Global-DaaC)’하는 비전을 향해 발전하고 있습니다. Global-DaaC에서는 사용자가 단순히 서비스의 글로벌 배포를 요청하면, 인프라가 모든 세부 사항을 자동으로 관리합니다. 즉, 서비스 복제본의 최적 개수를 결정하고, 서비스 수준 목표와 사용 가능한 하드웨어를 고려하여 복제본을 적절한 데이터센터 지역에 배치하며, 최적의 하드웨어 유형을 선택하고, 트래픽 라우팅을 최적화하며, 워크로드 변화에 따라 서비스 배치를 지속적으로 조정합니다. 퍼블릭 클라우드와 비교했을 때, Meta는 모든 애플리케이션을 직접 소유하고 있어 필요할 때마다 지역 간 이동이 가능하므로 Global-DaaC를 더 쉽게 구현할 수 있습니다. 반면, 퍼블릭 클라우드는 고객 애플리케이션을 직접 이동할 수 없기 때문에 이러한 유연성이 부족합니다. Global-DaaC를 구현하기 위해, Meta의 도구들은 글로벌, 지역, 개별 서버 수준에서 자원 할당을 원활하게 조정합니다. 먼저, Meta의 글로벌 용량 관리 도구(global capacity-management tool)는 RPC 추적을 사용하여 서비스 간 종속성을 식별하고, 자원 소비 모델을 구축한 후, 혼합 정수 프로그래밍(mixed-integer programming)을 적용하여 서비스의 글로벌 용량 요구 사항을 지역별 할당량으로 분할합니다. 다음으로, 지역 용량 관리 도구(regional capacity-management tool)는 지역별 할당량에 따라 서버 자원을 할당하여 가상 클러스터(virtual clusters)를 형성합니다. 물리적 클러스터와 달리, 가상 클러스터는 동일한 지역 내 여러 데이터센터의 서버로 구성될 수 있으며, 크기가 동적으로 확장되거나 축소될 수 있습니다. 실행 시간 동안, Meta의 컨테이너 관리 도구(container-management tool)는 이러한 가상 클러스터 내에 컨테이너를 할당하며, 고장 허용성을 향상시키기 위해 하나의 작업을 여러 데이터센터에 분산 배치하는 경우가 많습니다. 마지막으로, 서버 수준에서는 Meta의 커널 메커니즘(kernel mechanisms)이 개별 컨테이너에 할당된 메모리 및 I/O 자원의 적절한 공유와 격리를 보장합니다. 데이터베이스와 같은 상태 저장(stateful) 서비스는 Global-DaaC의 이점을 누릴 수 있습니다. 이러한 서비스는 일반적으로 샤딩(sharding) 구조를 가지며, 각 컨테이너는 효율성을 위해 여러 개의 데이터 샤드를 포함하고 있습니다. Meta의 글로벌 서비스 배치 도구(GSP, Global Service Placer)는 제약 최적화(constrained optimization)를 사용하여 각 데이터 샤드의 최적 복제본 개수와 지역별 배치를 결정합니다. 그 후, Meta의 샤딩 프레임워크는 GSP가 설정한 제약 조건을 기반으로 샤드 복제본을 컨테이너에 할당하며, 부하 변화에 따라 이를 동적으로 마이그레이션합니다. 유사하게, 머신러닝(ML) 워크로드도 Global-DaaC의 혜택을 받을 수 있습니다. ML 추론(inference)의 경우, 모델은 데이터 샤드와 유사하게 관리되며, GSP가 모델 복제본의 개수와 배치 위치를 결정합니다. ML 학습(training)의 경우, 학습 데이터와 GPU가 동일한 데이터센터 지역에 함께 배치되어야 합니다. 각 팀은 글로벌 GPU 용량 할당량을 받으며, 학습 작업을 글로벌 작업 큐(global job queue)에 제출합니다. Meta의 ML 학습 스케줄러는 자동으로 데이터 복제 및 GPU 할당 지역을 선택하여, 데이터와 GPU가 함께 배치되도록 보장하면서 GPU 활용도를 극대화합니다.

Insight 6: Meta는 “데이터센터를 하나의 컴퓨터처럼 운영(DaaC, Datacenter as a Computer)”하는 방식에서 “모든 글로벌 데이터센터를 하나의 컴퓨터처럼 운영(Global-DaaC, Global Datacenter as a Computer)”하는 방향으로 발전하고 있습니다. 이 모델에서는 인프라가 작업 부하 변화에 따라 자동으로 글로벌 데이터센터 간 배포를 결정하고 마이그레이션하며, 이를 위해 사용자의 개입이 필요하지 않습니다. Meta는 이 접근 방식을 데이터베이스, ML 시스템, 그리고 10만 대 이상의 서버 및 10만 개 이상의 GPU 규모로 운영되는 다양한 서비스에서 성공적으로 적용했습니다.

Hardware and Software Co-Design

단일 서버 내에서 하드웨어와 소프트웨어의 공동 설계(co-design)는 일반적이지만, Meta는 이를 글로벌 수준으로 확장하여 소프트웨어 솔루션을 활용해 저비용 하드웨어의 한계를 극복하고 있습니다.

Low-Cost Fault Tolerance

퍼블릭 클라우드는 일반적으로 높은 가용성을 제공하는 하드웨어를 사용합니다. 이는 퍼블릭 클라우드 고객의 애플리케이션이 충분한 내결함성을 갖추지 못한 경우가 많기 때문입니다. 반면, Meta는 모든 애플리케이션을 직접 제어할 수 있으므로, 낮은 가용성을 보장하는 저비용 하드웨어에서도 실행될 수 있도록 애플리케이션을 내결함성이 강한 방식으로 구현할 수 있습니다. 예를 들어, 퍼블릭 클라우드의 서버 랙은 높은 가용성을 보장하고 실행 중인 워크로드에 영향을 주지 않도록 유지보수를 수행하기 위해 이중 전원 공급 장치(dual power supplies)와 이중 ToR(Top-of-Rack) 스위치를 사용할 수 있습니다. 반면, Meta의 서버 랙은 이중 전원 공급 장치나 이중 ToR 스위치를 사용하지 않습니다. 대신, 하드웨어 이중화는 훨씬 더 큰 범위에서 이루어지며, 각 전력 메인 스위치보드(MSB)가 약 10,000~20,000대의 서버를 담당합니다. 6개의 MSB마다 하나의 예비 MSB만 백업으로 존재합니다. 또한, 퍼블릭 클라우드의 가상 머신(VM)은 일반적으로 네트워크 연결 블록 디바이스(network-attached block devices)를 사용하여 라이브 VM 마이그레이션을 수행할 수 있습니다. 반면, Meta의 컨테이너는 루트 디스크로 저비용의 직접 연결 SSD(directly attached SSD)를 사용하므로, 데이터센터 유지보수 중 라이브 컨테이너 마이그레이션이 어렵습니다. Meta는 저비용 하드웨어의 한계를 극복하기 위해 소프트웨어 솔루션을 활용합니다. 첫째, Meta의 자원 할당 도구는 서비스의 컨테이너와 데이터 샤드가 서로 다른 데이터센터 하위 장애 도메인(MSB)에 충분히 분산되도록 하여 내결함성을 향상시킵니다. 둘째, 컨테이너의 라이프사이클 관리를 서비스가 제어할 수 있도록 하는 협력 프로토콜(cooperative protocol)을 통해, 동일한 데이터 샤드의 두 개 복제본이 동시에 종료되지 않도록 하는 등 애플리케이션 수준의 제약 사항을 유지보수 작업에서도 준수하도록 합니다. 마지막으로, Global-DaaC는 전체 데이터센터 지역의 손실, 각 지역의 MSB 한 개 손실, 그리고 각 지역에서 임의의 일부 서버 손실에도 서비스가 정상적으로 운영될 수 있도록 보장합니다. Meta는 이러한 내결함성이 유지되는지 확인하기 위해 프로덕션 환경에서 정기적으로 테스트를 수행합니다.

Global-DaaC는 전체 데이터센터 지역의 장애, 각 지역의 MSB(Main Switch Board) 하나의 장애, 그리고 각 지역에서 일정 비율의 무작위 서버 장애가 발생하더라도 서비스가 지속적으로 운영될 수 있도록 배포됩니다.

Meta의 인프라는 전체 데이터센터 지역이 장애를 겪더라도 사용자에게 영향을 미치지 않도록 설계되어 있지만, 데이터센터 지역의 수가 증가하면서 허리케인과 같은 대규모 자연재해로 인해 인접한 두 지역이 동시에 영향을 받을 가능성이 커지고 있습니다. 두 개의 지역이 동시에 장애를 겪을 가능성에 대비해 용량을 과도하게 할당(over-provisioning)하는 대신, Meta는 소프트웨어 기반 접근 방식을 채택합니다. 여러 지역이 동시에 장애를 겪을 경우, 중요도가 낮은 기능을 비활성화하고, 동영상 품질을 낮추는 등의 방식으로 서비스 품질을 점진적으로 저하시켜 시스템 부하를 줄입니다.

Eliminating the Costs of Routing Proxies

일반적인 서비스 메시(service mesh)는 RPC 요청을 라우팅하기 위해 사이드카 프록시(sidecar proxy)를 주로 사용하지만, Meta의 서비스 메시는 전체 RPC 요청 중 단 1%만 프록시를 사용하여 라우팅합니다. 나머지 99%의 RPC 요청은 서비스 실행 파일에 직접 연결된 라우팅 라이브러리를 사용하여 클라이언트에서 서버로 직접 연결되며, 중간 프록시를 우회합니다. 이러한 비전통적인 방식 덕분에 Meta는 약 10만 대의 프록시 서버 비용을 절감할 수 있지만, 라이브러리가 약 1만 개의 서비스에 컴파일되어 각기 다른 배포 일정으로 운영되기 때문에 배포 과정에서 도전 과제가 발생합니다. Meta의 소프트웨어 배포 및 구성 관리 도구는 이러한 문제를 효과적으로 관리할 수 있도록 지원합니다.

Tiered Storage and Local SSDs

Meta는 데이터 접근 빈도와 지연 시간 요구 사항에 따라 데이터를 핫(hot), 웜(warm), 콜드(cold) 데이터로 분류하고, 각 유형에 적합한 스토리지 시스템을 사용하여 비용 효율성을 최적화합니다. 소셜 그래프 데이터베이스와 같은 핫 데이터베이스와 캐시는 데이터를 메모리와 SSD(Solid State Drive)에 저장합니다. 비디오, 이미지 및 데이터 웨어하우스(예: 사용자 활동 로그)와 같은 웜 데이터는 분산 파일 시스템에 저장되며, 주로 HDD(Hard Disk Drive)를 사용하여 데이터를 보관합니다. 각 스토리지 서버에는 하나의 CPU, 36개의 HDD, 그리고 메타데이터 캐싱을 위한 2개의 SSD가 장착되어 있습니다. 10년 이상 된 고해상도 비디오와 같은 거의 접근하지 않는 콜드 데이터는 고밀도(high-density) HDD 서버에 아카이빙되며, 각 서버에는 하나의 CPU와 216개의 HDD가 탑재되어 있어, 총 소유 비용(TCO)과 데이터 복구 속도 간의 균형을 맞춥니다. 이 HDD들은 대부분의 시간 동안 전원이 꺼져 있으며, 필요할 때만 활성화됩니다. SSD에 데이터를 저장하는 워크로드 중 일부는 긴 꼬리 지연 시간(tail latency)을 허용할 수 있으며, SSD 활용도를 극대화하기 위해 SSD 기반의 공유 원격 스토리지를 선택합니다. 하지만, 지연 시간 요구 사항이 엄격한 워크로드는 여전히 직접 연결된 로컬 SSD를 사용합니다. 다른 하이퍼스케일 인프라와 비교했을 때, Meta는 비용 절감을 위해 로컬 SSD를 더 자주 활용하지만, 이는 관리 복잡성을 증가시킬 수 있습니다. 예를 들어, 부하 분배가 불균형할 경우 로컬 SSD가 제대로 활용되지 못하고 유휴 상태로 남아 있을 수 있습니다. 또한, 장애 복구 과정에서 실패한 서버의 SSD에 데이터가 갇혀 복구가 어려워지는 문제가 발생할 수 있습니다. 이러한 문제를 해결하기 위해, Meta는 공통 샤딩 프레임워크를 사용하여 로컬 SSD 기반의 상태 저장 서비스(stateful service)를 구현하며, 이 솔루션을 한 번 구축한 후 여러 서비스에서 재사용합니다.

Insight 7: Meta는 하드웨어 비용을 절감하기 위해 소프트웨어 솔루션을 활용하여 저비용 하드웨어의 한계를 극복합니다. 이 접근 방식은 소프트웨어 스택의 복잡성을 증가시키지만, 비용 절감 효과가 크기 때문에 충분히 가치 있는 선택이라고 판단됩니다.

In-House Hardware Design

Meta는 비용 절감과 전력 효율성을 극대화하기 위해 자체적으로 데이터센터와 하드웨어(서버, 네트워크 스위치, 비디오 가속기, AI 칩)를 설계합니다. 데이터센터에서 전력은 가장 제한적인 자원입니다. 데이터센터를 건설할 때 전력 용량이 고정되며, 데이터센터의 20~30년 수명 동안 이를 확장하는 것은 어렵기 때문입니다. 반면, 네트워크와 서버는 필요에 따라 업그레이드할 수 있습니다. 데이터센터의 전력은 종종 과잉 할당(oversubscription)됩니다. 작업 부하가 급증할 때 전력 사용이 초과되지 않도록, 자동화 도구가 전력 공급 계층 전체에서 전력 제한(power-capping) 조치를 조정합니다. Meta의 하드웨어 설계는 하드웨어/소프트웨어 공동 설계를 통해 비용과 전력 소비를 절감합니다. 예를 들어, AI 칩의 SRAM 사용을 작업 부하에 맞게 최적화하거나, 불필요한 구성 요소(예: 압축 냉각 시스템이 포함된 에어컨)를 제거하는 방식이 있습니다. 또한, Meta는 자체적으로 네트워크 스위치와 관련 소프트웨어를 개발하여, 스위치 소프트웨어를 일반 서비스처럼 다룰 수 있으며, 이를 자주 업데이트할 수 있습니다. Meta의 대부분의 하드웨어 설계는 Open Compute Project를 통해 오픈 소스로 공유됩니다.

Insight 8: Meta는 하드웨어 비용과 전력 소비를 줄이기 위해 자체적으로 데이터센터, 서버, 랙, 네트워크 스위치를 설계하며, 이러한 설계를 오픈 소스로 공유합니다.

Designing Scalable Systems

하이퍼스케일 인프라에서 반복적으로 등장하는 핵심 주제 중 하나는 확장 가능한 시스템을 설계하는 것입니다. BGP, BitTorrent, 분산 해시 테이블(DHT)과 같은 인터넷 환경을 위해 설계된 분산 시스템은 종종 확장성이 뛰어나다는 평가를 받습니다. 그러나, 데이터센터 환경에서는 자원 제한이 덜하고 단일 조직이 전체 시스템을 제어할 수 있기 때문에, 중앙 집중식 컨트롤러가 충분한 확장성을 제공할 뿐만 아니라 더 단순하고 높은 품질의 결정을 내릴 수 있다는 것이 Meta의 경험입니다.

Deprecating Decentralized Controllers

이 섹션에서는 중앙 집중식 컨트롤러와 분산 컨트롤러 간의 트레이드오프(trade-off)에 대한 몇 가지 사례를 다룹니다. Meta의 데이터센터 패브릭(fabric) 내 네트워크 스위치는 여전히 호환성을 위해 BGP를 사용하지만, 네트워크 혼잡(network congestion) 또는 링크 장애(link failure) 발생 시 경로를 재설정할 수 있는 중앙 집중식 컨트롤러를 갖추고 있습니다. BGP를 제외하고, Meta는 대부분의 분산 컨트롤러를 중앙 집중식 컨트롤러로 전환했습니다. 예를 들어, Meta의 사설 WAN에서는 기존의 분산형 RSVP-TE에서 중앙 집중식 컨트롤러로 전환하여 최적의 트래픽 경로를 계산하고, 일반적인 장애 시나리오에 대비한 백업 경로를 사전에 설정할 수 있도록 했습니다. 이러한 전환을 통해 네트워크 자원을 더 효율적으로 사용할 수 있게 되었으며, 네트워크 장애 발생 시 더 빠르게 복구할 수 있었습니다. 키-값 저장소(key-value store)에서, DHT는 다중 홉 라우팅(multi-hop routing)을 사용하여 특정 키를 담당하는 서버를 결정하며, Cassandra는 일관성 해싱(consistent hashing)을 사용합니다. 두 시스템 모두 중앙 집중식 컨트롤러 없이 동작합니다. 반면, Meta는 더 나은 부하 분산(load balancing)을 위해 중앙 집중식 컨트롤러를 활용하여 키가 포함된 샤드(shard)를 서버에 동적으로 재할당하도록 설계된 샤딩 프레임워크를 사용합니다. 대량 데이터 분배 시스템에서는 BitTorrent에서 Owl로 전환했으며, Owl은 피어(peer)가 데이터를 어디에서 가져올지를 중앙에서 결정하여 다운로드 속도를 크게 향상시켰습니다. Owl과 Meta의 사설 WAN은 더 나은 의사 결정을 위해 제어 평면(control plane)을 중앙 집중화하지만, 실제 데이터 전송이나 다운로드를 수행하는 데이터 평면(data plane)은 여전히 분산된 방식을 유지합니다. 소규모 메타데이터 분배를 위해, 초기에는 Java로 구현된 3단계 분배 트리(distribution tree)를 사용했습니다. 이 트리의 중간 노드는 전용 프록시 서버(proxy server)였으며, 리프 노드(leaf node)는 애플리케이션 구독자로, 동적으로 가입 및 탈퇴할 수 있었습니다. 그러나, 이 구현 방식이 확장성의 한계에 도달하자, Meta는 중간 노드도 애플리케이션 구독자로 구성된 P2P(peer-to-peer) 분배 트리로 전환하였습니다. 이 구독자들은 다른 구독자에게 데이터를 전달하는 역할을 수행했습니다. 하지만 수백만 개의 애플리케이션 구독자 중 일부는 전용 서버가 아니었기 때문에 성능 변동이 심한 문제가 발생했습니다. 결과적으로, 이러한 구독자를 중간 노드로 활용하여 트래픽을 전달하는 방식은 신뢰성이 낮아졌으며, 이에 따라 빈번하고 시간이 많이 소요되는 디버깅이 필요하게 되었습니다. 결국, Meta는 몇 년간의 운영 경험 끝에 P2P 분배 트리를 폐기하고, 전용 프록시 서버를 사용하는 기존 아키텍처로 돌아갔습니다. 또한, 기존 Java 구현을 성능이 더 뛰어난 C++ 구현으로 대체하여 수천만 명의 구독자 규모에도 원활하게 확장될 수 있도록 개선했습니다.

Insight 9: 데이터센터 환경에서는 중앙 집중식 컨트롤러가 더 단순하며, 더 높은 품질의 결정을 내릴 수 있기 때문에 Meta는 분산형 컨트롤러보다 중앙 집중식 컨트롤러를 선호합니다. 많은 경우, 중앙 집중식 제어 평면(control plane)과 분산형 데이터 평면(data plane)을 결합한 하이브리드 접근 방식이 최적의 솔루션을 제공합니다.

Case Study: Scalable Service Mesh 이 섹션에서는 Meta의 서비스 메시(Service Mesh)인 ServiceRouter를 사례 연구로 사용하여 확장 가능한 시스템 설계 방식을 설명하고, 중앙 집중식 컨트롤러와 분산형 데이터 평면(data plane)이 결합된 아키텍처가 데이터센터 환경에서 효과적으로 확장될 수 있음을 보여줍니다.ServiceRouter는 초당 수십억 개의 RPC를 수백만 개의 L7(Application Layer) 라우터를 통해 라우팅합니다. 그림 3은 업계에서 일반적으로 사용되는 서비스 메시 구조를 보여주며, 여기서 각 서비스 프로세스에는 RPC 요청을 라우팅하는 L7 사이드카 프록시(sidecar proxy)가 함께 실행됩니다. 예를 들어, 서버 1에서 실행 중인 서비스 A가 서비스 B에 요청을 보낼 때, 서버 1의 프록시는 해당 요청을 서버 2, 3, 4에 분산하여 부하를 균형 있게 배분합니다. 이 방식은 널리 사용되고 있지만, 하이퍼스케일 인프라에서는 확장성이 부족합니다. 그 이유는 중앙 컨트롤러가 수백만 개의 사이드카 프록시의 라우팅 테이블을 직접 관리하기에는 부담이 크기 때문입니다. 중앙 컨트롤러는 글로벌 라우팅 메타데이터를 생성하는 기능과 각 L7 라우터를 관리하는 기능을 동시에 수행합니다. 확장성을 확보하기 위해, Meta는 글로벌 라우팅 메타데이터 생성 기능은 중앙 컨트롤러에 유지하고, 개별 L7 라우터 관리 기능은 L7 라우터 자체가 수행하도록 이전하여, 각 라우터가 스스로 설정하고 관리할 수 있도록 하였습니다. 그림 4는 ServiceRouter의 확장 가능한 아키텍처를 보여줍니다. 상위 계층에서는 서로 다른 컨트롤러들이 독립적으로 개별 기능을 수행합니다. 예를 들어, 서비스 등록, 네트워크 지연(latency) 측정값 업데이트, 그리고 서비스별 지역 간 라우팅 테이블 계산 등을 담당합니다. 각 컨트롤러는 중앙 라우팅 정보 데이터베이스(RIB, Routing Information Base)를 독립적으로 업데이트하며, 개별 L7 라우터의 설정 및 관리는 수행하지 않습니다. RIB는 Paxos 기반의 데이터베이스이며, 샤딩(sharding)을 통해 확장 가능합니다. RIB 덕분에 컨트롤러는 상태를 유지하지 않는(stateless) 방식으로 동작할 수 있으며, 샤딩을 통해 쉽게 확장할 수 있습니다. 예를 들어, 여러 개의 컨트롤러 인스턴스가 동시에 다양한 서비스의 지역 간 라우팅 테이블을 계산할 수 있습니다. 그림 4의 중간 계층에서, 분배 계층(distribution layer)은 수천 개의 RIB 복제본(replica)을 활용하여 수백만 개의 L7 라우터로부터 발생하는 읽기 트래픽을 처리합니다. 하위 계층에서는, RIB의 지시에 따라 각 L7 라우터가 스스로 설정을 구성하며, 제어 평면(control plane)이 직접 개입할 필요가 없습니다. 이 시스템은 다양한 유형의 L7 라우터를 지원하며, 여기에는 로드 밸런서(load balancer), 라우팅 라이브러리가 포함된 서비스, 그리고 사이드카 프록시가 포함됩니다. ServiceRouter의 사례에서 볼 수 있듯이, Meta는 중앙 집중식 컨트롤러를 사용하면서도 확장성을 확보할 수 있습니다. 이를 위해 상태를 유지하지 않는(stateless) 컨트롤러, 컨트롤러 샤딩, 그리고 개별 L7 라우터 관리를 중앙 컨트롤러에서 제거하는 등의 기술을 활용합니다.

Future Directions

Meta의 하이퍼스케일 인프라는 매우 복잡하지만, 본 문서에서는 주요 개발 인사이트를 중심으로 간략하고 상위 개념 위주의 개요를 제공하였습니다. 마지막으로, 하이퍼스케일 인프라의 잠재적인 미래 트렌드에 대한 Meta의 견해를 공유하고자 합니다.

AI

AI 워크로드는 현재 데이터센터에서 가장 큰 비중을 차지하는 워크로드 카테고리가 되었습니다. Meta는 이번 10년이 끝나기 전에 데이터센터 전력 소비의 절반 이상이 AI 워크로드에 할당될 것으로 예상합니다. AI는 높은 자원 소모(resource-intensive)와 고대역폭 네트워크 요구 사항 등 독특한 특성을 가지므로, 인프라의 모든 측면을 근본적으로 변화시킬 것으로 예상됩니다. 지난 20년 동안 하이퍼스케일 인프라는 저비용 범용 서버를 대량으로 활용하는 스케일 아웃(scale-out) 접근 방식을 통해 성공을 거두었습니다. 하지만 향후 AI 클러스터는 과거 슈퍼컴퓨터에서 사용된 스케일 업(scale-up) 방식으로 발전할 가능성이 높습니다. 예를 들어, 대규모 머신러닝 학습을 위해 RDMA(Remote Direct Memory Access)를 Ethernet을 통해 활용하여 높은 대역폭과 낮은 지연 시간을 제공하는 방식이 이에 해당합니다. Meta는 AI를 위한 전체 스택을 공동 설계(co-design)하는 접근 방식을 택하고 있으며, 여기에는 PyTorch, 머신러닝 모델, AI 칩, 네트워크, 데이터센터, 서버, 스토리지, 전력 및 냉각 시스템이 포함됩니다.

Domain-Specific Hardware

2000년대 이후 감소했던 하드웨어 다양성이 다시 증가할 것으로 예상되며, AI 학습 및 추론, 가상화, 비디오 인코딩, 암호화, 압축, 계층형 메모리(tiered memory), 네트워크 내 및 스토리지 내 처리와 같은 다양한 목적을 위한 맞춤형 및 특수 하드웨어가 확산될 것입니다. 이러한 변화는 규모의 경제(economies of scale)로 인해 하이퍼스케일 기업들이 대량의 특수 하드웨어를 설계하고 배포하여 비용을 절감할 수 있기 때문입니다. 그러나, 이는 매우 이질적인(homogeneous) 하드웨어 구성을 관리하고 활용해야 하는 소프트웨어 스택에 새로운 도전 과제를 제시할 것입니다.

Edge Datacenters

Meta는 메타버스(Metaverse) 및 사물인터넷(IoT) 애플리케이션의 사용이 상당히 증가할 것으로 예상합니다. 예를 들어, 클라우드 게임(Cloud Gaming)은 그래픽 렌더링을 사용자 기기에서 엣지 데이터센터(Edge Datacenter)의 GPU 서버로 이동시키며, 이 과정에서 25ms 이하의 네트워크 지연 시간이 필요합니다. 실시간 응답성에 대한 수요 증가로 인해 엣지 데이터센터의 수량과 규모가 크게 성장할 가능성이 높습니다.이에 따라, 인프라 제어 평면(control plane)은 더욱 분산된 데이터센터를 효과적으로 관리할 수 있도록 적응해야 하며, 이상적으로는 Global-DaaC를 개선하여 애플리케이션 개발자가 분산된 인프라의 복잡성을 신경 쓰지 않도록 보호해야 합니다.

Developer Productivity

지난 20년 동안 자동화 도구는 시스템 관리자(System Administrator)의 생산성을 크게 향상시켜, 서버 대비 관리자 비율이 상당히 증가했습니다. 반면, 일반적인 소프트웨어 개발은 여전히 노동 집약적이며, 상대적으로 생산성 향상이 느린 편입니다. 이번 10년 동안 이러한 추세에 변화가 있을 것으로 예상되며, 두 가지 이유로 인해 개발자의 생산성이 급격히 향상될 것입니다. 첫째, AI 기반 코드 생성 및 디버깅(AI-powered code generation and debugging), 둘째, 특정 산업(vertical domains)에서 완전히 통합된 서버리스(serverless) 프로그래밍 패러다임입니다. Meta의 FrontFaaS는 후자의 예시이며, 앞으로 다양한 산업 분야에서 생산성을 극대화하는 프로그래밍 패러다임이 등장할 것으로 예상됩니다. 지난 20년 동안 하이퍼스케일 인프라에서 이루어진 빠른 혁신은 앞으로도 계속될 것으로 예상되며, 특히 AI의 발전이 이를 주도할 것입니다. Meta는 하이퍼스케일 기업들이 인사이트를 공유함으로써, 커뮤니티 전체가 발전 속도를 더욱 가속화할 수 있기를 기대합니다.

Acknowledgments

본 문서는 10년 이상에 걸쳐 수천 명의 Meta 인프라 엔지니어들이 수행한 작업을 요약한 것입니다. 이 문서에 설명된 일부 시스템에는 저자가 직접 기여했지만, 직접 관여하지 않은 시스템도 많이 포함되어 있습니다.

References

1. Abhashkumar, A. et al. Running BGP in data centers at scale. In Proceedings of the 18th USENIX Symp. on Networked Systems Design and Implementation. USENIX, (2021), 65–81.
2. Andreyev, A. Introducing data center fabric, the next-generation Facebook data center network. Engineering at Meta, (2014); https://engineering. fb.com/production-engineering/introducing-data- center-fabric-the-next-generation-facebook-data- center-network/
3. Balakrishnan, M. et al. Virtual consensus in Delos. In Proceedings of the 14th USENIX Symp. on Operating Systems Design and Implementation. USENIX, (2020), 617–632.
4. Barroso, L.A., Hölzle, U., and Ranganathan, P. The Datacenter as a Computer: Designing Warehouse- Scale Machines. Springer Nature, (2019).
5. Bronson, N. et al. TAO: Facebook’s distributed data store for the social graph. In Proceedings of the 2013 USENIX Annual Technical Conf. USENIX, (2013), 49–60.
6. Campbell, L. and Tang, C. How Meta built the infrastructure for Threads. Engineering at Meta, (2023); https://engineering.fb.com/2023/12/19/core- infra/how-meta-built-the-infrastructure-for-threads/
7. Chen, G.J. et al. Realtime data processing at Facebook. In Proceedings of the 2016 Intern. Conf. on Management of Data. ACM, (6), 1087–1098.
8. Choi, S. et al. FBOSS: Building switch software at scale. In Proceedings of the 2018 Conf. of the ACM Special Interest Group on Data Communication. ACM, (2018), 342–356.
9. Chou, D. Tajji: Managing global user traffic for large- scale Internet services at the edge. In Proceedings of the 27th Symp. on Operating Systems Principles. ACM, (2019), 430–446.
10. Choudhury, A. et al. MAST: Global Scheduling of ML Training across Geo-Distributed Datacenters at Hyper- scale. In Proceedings of the 18th USENIX Symp. on Operating Systems Design and Implementation. USENIX, (2024).
11. Chow, M. et al. ServiceLab: Preventing tiny performance regressions at hyperscale through pre- production testing. In Proceedings of the 28th Symp. on Operating Systems Principles. ACM, (2024).
12. Denis, M. et al. EBB: Reliable and evolvable express backbone network in Meta. In Proceedings of the ACM SIGCOMM 2023 Conf. ACM, (2023), 346–359.
13. Eriksen, M. et al. Global capacity management with Flux. In Proceedings of the 17th USENIX Symp. on Operating Systems Design and Implementation. USENIX, (2023).
14. Ferreira, J. et al. Fabric Aggregator: A flexible solution to our traffic demand. Engineering at Meta, (2014); https://engineering.fb.com/data-center- engineering/fabric-aggregator-a-flexible-solution-to- our-traffic-demand/
15. Firoozshahian, A. et al. MTIA: First generation silicon targeting Meta’s recommendation systems. In Proceedings of the 50th Annual Intern. Symp. on Computer Architecture. ACM, (2023), 1–13.
16. Flinn, J. et al. Owl: Scale and flexibility in distribution of hot content. In Proceedings of the 16th USENIX Symp. on Operating Systems Design and Implementation. USENIX, (2022), 1–15; https://www. usenix.org/conference/osdi22/presentation/flinn
17. Frachtenberg, E. et al. Thermal design in the open compute datacenter. In Proceedings of the 13th InterSociety Conf. on Thermal and Thermomechanical Phenomena in Electronic Systems. IEEE, (2012), 530–538.
18. Gangidi, A. et al. RDMA over Ethernet for distributed training at Meta scale. In Proceedings of the ACM SIGCOMM 2024 Conf. ACM, (2024), 57–70.
19. Grubic, B. et al. Conveyor: One-tool-fits-all continuous software deployment at Meta. In Proceedings of the 17th USENIX Symp. on Operating Systems Design and Implementation. USENIX, (2023).
20. Guo, M. et al. MobileConfig: Holistic configuration management for mobile apps. In Proceedings of the 21st USENIX Symp. on Networked Systems Design and Implementation. USENIX, (2024).
21. Heo, T. et al. IOCost: Block io control for containers in datacenters. In Proceedings of the 27th ACM Intern. Conf. on Architectural Support for Programming Languages and Operating Systems. ACM, (2022), 595–608.
22. Kumar, N. et al. Optimizing resource allocation in hyperscale datacenters: Scalability, usability, and experiences. In Proceedings of the 18th USENIX Symp. on Operating Systems Design and Implementation. USENIX, (2024).
23. Lee, S. et al. Shard Manager: A generic shard management framework for geodistributed applications. In Proceedings of the 28th Symp. on Operating Systems Principles. ACM, (2021).
24. Masti, S. How we built a general purpose key value store for Facebook with ZippyDB. (2021); https:// engineering.fb.com/2021/08/06/core-data/zippydb/
25. Meza, J.J. et al. Defcon: Preventing overload with graceful feature degradation. In Proceedings of the 17th USENIX Symp. on Operating Systems Design and Implementation. USENIX, (2023), 607–622.
26. Newell, A. et al. RAS: Continuously optimized region- wide datacenter resource allocation. In Proceedings of the 28th Symp. on Operating Systems Principles. ACM, (2021).
27. Nishtala, R. et al. Scaling Memcache at Facebook. In Proceedings of the 10th USENIX Symp. on Networked Systems Design and Implementation. USENIX, (2013), 385–398.
28. Open Compute Project. (2024); https://www. opencompute.org/
29. Pan, S. Facebook’s Tectonic filesystem: Efficiency from exascale. In Proceedings of the 19th USENIX Conf. on File and Storage Technologies. USENIX, (2021), 217–231.
30. Sahraei, A. et al. XFaaS: Hyperscale and low cost serverless functions at Meta. In Proceedings of the 29th Symp. on Operating Systems Principles. ACM, (2023), 231–246.
31. Saokar, H. et al. ServiceRouter: A scalable and minimal cost service mesh. In Proceedings of the 17th USENIX Symp. on Operating Systems Design and Implementation. USENIX, (2023).
32. Schlinker, B. et al. Engineering egress with Edge Fabric: Steering oceans of content to the world. In Proceedings of the Conf. of the ACM Special Interest Group on Data Communication. ACM, (2017), 418–431.
33. Tang, C. et al. Holistic configuration management at Facebook. In Proceedings of the 25th Symp. on Operating Systems Principles. ACM, (2015), 328–343.
34. Tang, C. et al. Twine: A unified cluster management system for shared infrastructure. In Proceedings of the 14th USENIX Symp. on Operating Systems Design and Implementation. USENIX, (2020), 787–803.
35. Veeraraghavan, K. et al. Kraken: Leveraging live traffic tests to identify and resolve resource utilization bottlenecks in large scale web services. In Proceedings of the 12th USENIX Symp. on Operating Systems Design and Implementation. USENIX, (2016), 635–651.
36. Veeraraghavan, K. et al. Maelstrom: Mitigating datacenter-level disasters by draining interdependent traffic safely and efficiently. In Proceedings of the 13th USENIX Symp. on Operating Systems Design and Implementation. USENIX, (2018), 373–389.
37. Weiner, J. et al. TMO: Transparent memory offloading in datacenters. In Proceedings of the 27th ACM Intern. Conf. on Architectural Support for Programming Languages and Operating Systems. ACM, (2022), 609–621.
38. Wu, Q. et al. Dynamo: Facebook’s data center- wide power management system. ACM SIGARCH Computer Architecture News 44, 3 (2016), 469–480.
39. Yoon, D.Y. et al. FBDetect: Catching tiny performance regressions at hyperscale through in-production monitoring. In Proceedings of the 30th Symp. on Operating Systems Principles. ACM, (2024).
40. Yu, K. and Kumar, R. Viewing the world as a computer: Global capacity management. Engineering at Meta, (2022); https://engineering.fb.com/2022/09/06/data- center-engineering/viewing-the-world-as-a-computer- global-capacity-management/