Metaのハイパースケールインフラの概要と洞察

 (cacm.acm.org)
22 ポイント 投稿者 GN⁺ 2025-02-12 | 3件のコメント | WhatsAppで共有
  • 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以外のコンピューティングワークロードには、単一のサーバータイプ（基本的にCPU 1基、DRAM 256GB）を提供し、サーバータイプの複雑さを減らしている
  • ソフトウェア:
    • 以前はCassandra、HBase、ZippyDBなど複数のキー・バリューストアを使用していたが、現在はZippyDBに統合されている
    • ソフトウェアデプロイ、構成管理、サービスメッシュ、性能テストなどは共通ツールに統合されている
  • 再利用可能なコンポーネントを重視:
    • Tectonicファイルシステム → ZippyDB（メタデータ保存）→ Shard Manager（データシャーディング管理）→ ServiceRouter（シャード探索とリクエストルーティング）→ Delos（高信頼データストア）で構成されるコンポーネント再利用チェーンを構築している
    • HDFSのようなモノリシックシステムではなく、モジュール化された再利用可能コンポーネントを使うことで拡張性を最大化している

文化のケーススタディ: Threadsアプリ開発 (Culture Case Study: The Threads App)

  • Threadsアプリ開発事例は、Metaのエンジニアリング文化をよく示している
  • わずか5か月で技術作業を完了し、2日前の事前通知の後、インフラチームが本番デプロイ準備を完了した
  • ほとんどの大企業では、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）は、開発者の生産性を高めるもう1つの中核要素
  • 従来のバックエンドサービスとは異なり、サーバーレス関数は状態を保存せず、単純な関数インターフェースを実装する
  • 各関数呼び出しは独立して実行され、外部データベースやキャッシュシステムを活用して状態を管理する
  • サーバーレス関数の利点
    • 開発者は インフラ管理なしにプロダクトロジックだけを書けばよい
    • 自動的に コードデプロイと負荷変動に応じたオートスケーリング（Auto-Scaling）が行われる
    • ハードウェアの無駄を防止し、開発者が過剰なリソースを割り当てる必要がない
  • Metaのサーバーレスプラットフォーム
    • Metaの 1万人を超える開発者のうち、サーバーレス関数を書く開発者の数は、従来型のサービスコードを書く開発者より50%多い
    • Metaの サーバーレス開発環境（IDE）は、ソーシャルグラフデータベースやさまざまなバックエンドシステムに容易にアクセスできるよう支援し、継続的インテグレーションテスト（CI）を提供して迅速なフィードバックを可能にする
  • Metaのサーバーレスプラットフォーム: FrontFaaSとXFaaS
    • FrontFaaS: PHPベースのフロントエンド向けサーバーレス関数で、50万台以上のサーバーで実行される
      • 常にPHPランタイムを維持することで、コールドスタート問題なしに即座にリクエストを処理できる
      • サーバー負荷が低いときは オートスケーリング によって一部のサーバーを解放し、他の作業に活用する
    • XFaaS: 非同期で実行されるイベント駆動型サーバーレス関数
      • 即時の応答を必要としない バックグラウンドタスクを処理する
      • 高負荷な作業を避けるため、実行を遅延させたり、グローバルロードバランシング、クォータベースのスロットリングを適用する
  • Metaのサーバーレスにおける革新
    • 2000年代後半からサーバーレス方式を基本的な開発パラダイムとして使用
    • パブリッククラウドのサーバーレスプラットフォームとの違い:
      • パブリッククラウドは強い分離のため、1つの関数ごとに1台の仮想マシンを使用する
      • 一方、Metaは 1つのLinuxプロセスで複数の関数を同時実行できるように設計し、ハードウェア効率を最大化している

# [ハードウェアコスト削減（Reducing Hardware Costs）]

  • Metaの共有インフラは開発者の生産性を高めるだけでなく、ハードウェアコスト削減にも重要な役割を果たす
  • そのために ソフトウェア最適化を活用してハードウェア効率を最大化する戦略を用いている

グローバルデータセンターを1台のコンピュータのように運用（All Global Datacenters as a Computer）

  • 既存のクラウド環境では、ユーザーが自らサービスレプリカ（replica）数やデプロイ地域などを設定する必要があった
  • このような手動管理方式は、リソースの無駄、負荷の不均衡、データセンター間のマイグレーション不足などの問題を引き起こした
  • Metaは 「データセンターを1台のコンピュータとして運用」する従来の方式（DaaC, Datacenter as a Computer）を発展させ、「全世界のデータセンターを1台のコンピュータのように運用」する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を使用
    • ソフトウェアベースの障害対処戦略:
      • リソース割り当てツール: サービスのコンテナとデータシャードをデータセンター内の別の障害ドメインへ分散
      • 協調プロトコル: アプリケーションがコンテナのライフサイクル管理に介入できるようにし、データシャードのレプリカが同時に停止しないよう保護
      • 複数データセンターでの耐久性保証: 1つの地域全体が停止してもサービスが維持されるよう設計されており、定期的に実戦的なテストを実施して信頼性を検証
  • ルーティングプロキシのコスト削減 (Eliminating Routing Proxy Costs)
    • 従来のサービスメッシュはサイドカープロキシ (Sidecar Proxy) を使用してRPCリクエストをルーティングするが、MetaはRPCリクエストの99%を直接のクライアント・サーバールーティング方式で処理している
    • この方法により約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（世界中のデータセンターを1台のコンピューターのように運用する概念）を拡張し、開発者が複雑なインフラ管理を意識しなくて済むよう最適化する必要がある

開発者生産性の向上（Developer Productivity）

  • 過去20年間で自動化ツールはシステム管理者の生産性を大幅に向上させ、サーバー1台あたりで管理者が担う比率は急激に増加した
  • しかし、ソフトウェア開発は依然として労働集約的であり、生産性向上は比較的緩やか
  • 今後は2つの要因によって開発者生産性が急速に向上する見通し:
    1. AIベースのコード生成およびデバッグツールの進化
    2. ドメイン特化の完全統合型サーバーレスプログラミングパラダイムの登場
  • MetaのFrontFaaSはこうしたサーバーレスプログラミング方式の一例であり、
    今後は特定業界（例: 金融、医療など）に最適化された新たなプログラミングパラダイムが登場すると予想される

結論

  • AIを中心とするインフラ革新が今後10年間で急速に進む
  • ハイパースケール企業は自らのインサイトを共有することで、コミュニティ全体がより速く発展できるよう貢献すべきである

関連記事

3件のコメント

 
secret3056 2025-02-13

あのPoPはBGP4かTCP anycastなんでしょうし、それを個人で使う方法はないですよね……？（泣）
 
pribess 2025-02-13

PoP が BGP4 あるいは TCP anycast だという記述が正確にどういう意味なのかはよく分かりませんが、独自の AS を運用しているかという意味であれば、そのとおりです。
通常、一般的なマルチリージョンサービスでは、geolocation based balancing に anycast DNS を組み合わせて使うことのほうが多いです。
はい、現時点ではありません。マルチリージョン PoP が必要であれば、他のプロバイダーを利用してください。
 
GN⁺ 2025-02-12
Hacker Newsのコメント

  • Threadsの開発後、インフラチームはリリース準備のためにわずか2日間の通知しか受けなかった。大半の大規模組織では、数十の相互依存するチームを含むプロジェクト計画を作成するだけでも2日以上かかる。しかしMetaでは、分散した拠点にウォールームを迅速に構築し、インフラとプロダクトのチームがリアルタイムで問題を解決できるようにした。このアプリはリリースから5日でユーザー1億人に到達し、史上最速で成長したアプリとなった

  • 製品を素早くリリースできる能力を維持しているのは印象的だ。官僚主義が増えないようにし、法務チームや他部門が承認ゲートを作らないようにするには大きな努力が必要だ。あるいは、ウォールームを通じて迅速に仕事を完了させる能力が必要になる

  • FBにいたとき、インフラがどれほど強力かを体験した。プロダクトエンジニアたちは数日で大規模プロジェクトを構築していた。複数のチームでテックリードを務めたが、ここで言及されているチームの一部にはHBaseとZippyDBのチームが含まれる

  • ZippyDBが初めて公に言及されたのはすばらしい。開発者効率の向上に触れられているのもとてもよい。毎日10,000のサービスがプッシュされる、あるいはすべてのコミットが行われる

  • FBを離れた後、似たようなものは見つけられなかった。だからスタートアップとして、自分が必要としていたインフラを構築している。Batteries Included

  • これらのコメントに皮肉や否定的な反応が多いのは残念だ。多くの人がMetaを嫌っているが、実際の記事は私にとって驚嘆の対象だった。現代のデジタル世界を支えるインフラが、これほど広範で複雑だとは知らなかった。この記事を読み、その規模を見るのは驚きだった

  • 会社がいろいろな面で悪い存在であり得るとしても、記事に出てくることはどれも私には驚きだ

  • 私は皆さんのようなエンジニアではないので、この記事は皆さんにとっては古い話かもしれないが、それでも「すごい」と言わずにはいられなかった

  • 昔のSF作家たちにこの記事を見せたら、彼らも驚嘆すると思う

  • 驚きだ。こうした驚異的で印象的な技術や世界最高のエンジニアたちが、結局は人々の目にもっと多くの広告を押し込むためだけに使われている。はぁ

  • PHPのWebフロントエンドを「サーバーレス」または「Function as a Service」アーキテクチャとして説明するのは興味深い。視点の問題のように思える。これは多くのエンドポイントがデプロイされた単一のコードベースを持つサービスだ。エンドポイント保守担当者の観点では「サーバーレス」かもしれないが、あらゆる抽象化と同じく漏れはある

  • データセンター環境では、単純さと高品質な意思決定能力のため、中央集権型コントローラーが好ましい。多くの場合、中央集権型コントロールプレーンと分散データプレーンを組み合わせたハイブリッドアプローチが最適だ

  • このアプローチは、大量のサーバーを持つ組織のソフトウェアネットワーキング（サービスメッシュ）とストレージ（データベース運用）において、最適な設計の1つに見える。IPネットワーキングが主にBGPに依存せず、同じモデルに従っているのは驚きだ

  • ローカルキャッシュを使ってL7ルーターの負荷を下げ、データベースクエリのレイテンシを改善すると予想される。クライアントはキャッシュを無効化し、妥当なタイムアウト後にサービスメッシュへ再問い合わせできる

  • 急いで開発されたサーバーレス関数と継続的デプロイが組み合わさり、誰でもコードベース全体を編集できるというのは、ディストピア的な悪夢のように聞こえる。デバッグやバグ発見に必要なロギング量は極端だ

  • サーバーレス関数を書くのにErlangを使うのは、BEAMが提供できる大きな利点をすべて避けているように思える

  • プロダクトエンジニアは主にPHP、Python、Erlangで、ステートレスなサーバーレス関数としてコードを書く。これは単純さ、生産性、反復速度の面で利点がある

  • 開発者生産性を高めるため、Metaは継続的デプロイを全面的に採用し、より多くの開発者が従来のサービスコードよりもサーバーレス関数を書けるようにしている

  • AI以外の計算ワークロードについては、単一のサーバータイプしか提供せず、1つのCPUと同じ量のDRAM（以前は64GB、現在は256GB）を搭載している。これが業界全体で一般的なのか、それともMetaだけで一般的なのか気になる

  • 画像がCDN109にキャッシュされていない場合、ユーザーがリクエストするとCDN109はそのリクエストを近隣のPoPへ転送する。PoPはリクエストをデータセンターリージョンのロードバランサーへ渡し、ロードバランサーはストレージシステムから画像を取得する

  • 1MBの画像をリクエストする場合、遅い接続で100msのレイテンシがあっても、何度も往復してレイテンシが増えていくより、1MB画像をそのまま配信するほうが速いのではないか？

  • Metaのシステム経由でリクエストすると仮定し、結局同じデータセンターに行き着き、FTL技術がないと仮定した場合の話だ

  • ハイパースケーラーとの明示的な比較は特に興味深い。彼らが独自のパブリッククラウドを立ち上げる準備をしているのではないかと思う。Metaの誰かが見解を述べてくれるとよいのだが