# Facebook Facebook（現 Meta Platforms）は、世界最大級のソーシャルネットワーキングプラットフォームを運営するテクノロジー企業である。数億のユーザと数万台のサーバを擁する大規模インフラストラクチャにおいて、分散システムの設計と運用に関する多数の貢献がある。 [[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System|Cassandra]] は Facebook の Inbox Search 基盤として開発され、1 日あたり数十億件の書き込みと地理分散データセンタ間のレプリケーションを処理する要件から生まれた。2008 年にオープンソース化され、後に [[Apache Cassandra]] として Apache Software Foundation のトップレベルプロジェクトとなった。 [[Gorilla]] は Facebook が設計・本番展開したインメモリ [[時系列データベース]]（TSDB）で、ODS（Operational Data Store）監視システムの直近 26 時間分のデータを全量 RAM に保持する write-through キャッシュとして機能する。デルタ・オブ・デルタとXOR 圧縮により 12 倍の圧縮を達成し、2015 年時点で 20 億の一意時系列・毎秒 1,200 万データ点を 80 台のマシンで処理している。（[[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]]） ## データウェアハウス基盤(SIGMOD 2010) Facebookは、[[Apache Hadoop]]・[[Apache Hive]]・[[Scribe]]を組み合わせ、15PB超のデータ(圧縮後2.5PB)を保持し、毎日60TB超の新規データ(圧縮後10TB)を取り込むデータウェアハウスを運用した。 WebログをScribe-Hadoopクラスタへ集約し、本番Hive-Hadoopクラスタへ移送したうえで、期限の厳しい処理と歴史データのアドホック分析を別クラスタへ分離した。 HiveのSQL・表・パーティション抽象化、HiPalのWeb UI、協調的なメタデータ編集、クエリログからの系譜抽出を組み合わせ、非エンジニアリング部門を含む大規模分析を支えた。(Source: [[@2010__SIGMOD__Data Warehousing and Analytics Infrastructure at Facebook]]) ## Canopy（SOSP 2017） [[Canopy]] は Facebook のエンドツーエンド性能トレース基盤として [[Jonathan Kaldor]]・[[Jonathan Mace]] ほかにより開発され、SOSP 2017 で発表された。ブラウザ・モバイルアプリ・バックエンドサービスを横断した 1 日 13 億件以上のトレースを処理する。計装とトレースモデルを分離した設計と、特徴量抽出パイプラインを通じた [[Scuba]] との統合が主要な技術的貢献。（[[@2017__SOSP__Canopy - An End-to-End Performance Tracing And Analysis System]]） ## Memcache（NSDI 2013） [[Rajesh Nishtala]] ほか 12 名が NSDI '13 に発表した論文で、Facebook が memcached を基盤に構築した分散キー値ストアの設計と大規模運用を詳述する。秒間数十億リクエスト・数兆アイテムを処理するシステムの構築経験をもとに、クラスタ内のレイテンシ削減（リースメカニズム・Gutter プール・UDP get）、リージョン内のキャッシュ整合性（mcsqueal・Regional Pool・Cold Cluster Warmup）、リージョン間整合性（Remote Marker・ベストエフォート結果整合性）の三層構造で整理されている。（[[@2013__NSDI__Scaling Memcache at Facebook]]） ## Production Engineering（SREcon15） [[Pedro Canahuati]]（Production Engineering ディレクター）が SREcon15 のトーク "Notes from Production Engineering" で開示した Facebook 社内の SRE 組織変革の記録。[[Jay Parikh]]（エンジニアリング責任者）の後ろ盾のもと、2009 年〜2015 年にかけて 5 段階の変革を実施した。 **組織の進化**: - SRE → SRO（Site Reliability Operations）＋ AppOps（各ソフトウェアチームに埋め込まれた Application Operations）の 2 分割 - AppOps → Production Engineering への改名（2012 年頃）。「ops」という語を外すことで認識を転換した - SRO は 2014 年 3 月 31 日に解散。集中型の 24 時間監視チームが各ソフトウェアチームの自立を阻む「クラッチ」になっていたと判断 **主要な自動化ツール**: - FBAR（障害自動修復）: 1 日 13,600 人時相当の作業を自動化。壊れたサーバの検出・除外・修復を完全自動化する階層型 Remediation プラグイン構造 - Cobalt（クラスター自動構築）: 新クラスターのソフトウェアスタックを自動展開するシステム - ODS（Operational Data Store）: 毎秒 8,300 万データポイントを処理する監視基盤 **ポストモーテム文化**: - 週次金曜 SEV レビューを制度化 - 「FIX MORE, WHINE LESS」をスローガンとしてTシャツ印刷・インフラ全員配布 - Jay Parikh が同席し、リソース不足時に即座に追加エンジニアをアサイン （Source: [[@2015__SREcon15__Notes from Production Engineering]]） ## SEV Process / Production Review（SREcon16 Europe） [[Gareth Eason]]（Production Review EMEA 運営者）が SREcon16 Europe（2016年7月）で開示した、Facebook のインシデント管理・学習プロセスの詳細。Canahuati の 2015 年講演が「週次金曜 SEV レビューを制度化した」という組織変革の事実を述べたのに対し、本ソースはそのレビューが実際にどう運営されているかを一段深く記述する。 - **Discoverer is the owner**: インシデントを発見した人がまず所有者になり、規模に応じて IMOC（Incident Manager On Call）にエスカレーションする。 - **SEV1/2/3 の意図的な過大分類バイアス**: リスクがあれば SEV1 に倒し、後から格下げする運用。 - **SEV Manager**: 進行中・過去のインシデントの単一の真実源となる中央プラットフォーム。 - **二段階レビューと3つの質問**: チーム深堀り→全社横断 Production Review（EMEA 版と米国メンロパーク版に分割運営）。「影響は何か」「どう起きたか」「次にどう防ぐか」を毎回問う。 - **メトリクスゲーミングへの警告**: SEV 数を単純な成功指標にすると、過小分類・過小報告のインセンティブを生むと明言。 - **カナリア事故の実例**: Production Review 1 回の共有で、少なくとも4チームが同種の事故を未然に防いだ。 （Source: [[@2016__SREcon16__Incident Response @ FB, Facebook's SEV Process]]） ## Production Engineering(『SREの探求』13章、Pedro Canahuatiの対談) 『SREの探求』13章は、[[Pedro Canahuati]]（当時 PE 担当バイスプレジデント）が編者 David N. Blank-Edelman と行った対談として、SREcon15講演で語られた組織変革史(SRE→SRO+AppOps→Production Engineering)を書籍インタビューという別媒体で振り返る。事実関係(SRO解散・FBAR・改称の経緯)は一致しつつ、講演には無かった詳細が追加される。 - **SWE:AppOps比率**: 変革前は1名のAppOpsエンジニアがサービス1つを担当するモデルで、SWEとの比率は1対10、場合により1対40に達していた。 - **集中型の報告構造+分散型の配属構造**: PEはエンジニアリング責任者に直属する独立した報告ラインを持ちつつ、物理的にはSWEチームのすぐ隣に配属される。柔軟性・モチベーション・説明責任の緊張の共有という3つの理由でこの組み合わせが選ばれた。 - **オンコール共有原則**: 「コードを書いてリリースした者が所有者」という原則のもと、SWEとPEが週単位でオンコールをローテーションする。PEが完全に構築・所有するインフラ(FBAR・Augmented Traffic Control等)のみPEが100%担当する。 - **サービスピラミッド**: プロダクションエンジニアの[[Andrew Ryan]]が考案した、マズローの欲求段階説に基づく優先順位付けモデル。 - **他組織のPE度を判定する4基準**: (1) 誰がオンコールを担当するか、(2) 運用とソフトウェアの対等性、(3) 機能と安定性のバランス、(4) 機能性・安定性に乏しい場合の説明責任の共有。「ops」を名称から外すだけでは文化的意味合いは伴わないと明言する。 (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 13 Facebookにおけるプロダクションエンジニアリング]] ch.13) ## SEER(自己教師あり画像認識、2021年) 『ディープラーニングを支える技術』第1章の「数字で見るディープラーニングの今」(図1.A)は、学習データ量の急拡大を示す例として、Facebookが発表したSEER(P. Goyal et al., "Self-supervised Pretraining of Visual Features in the Wild", CVPR 2021)を挙げる。SEERはInstagramに投稿された10億枚の画像を用いて自己教師あり学習(自己教師あり表現学習)を行っており、AlexNetが用いたImageNet(100万枚)からの規模拡大の代表例として位置づけられる。(Source: [[@2022__Gihyo__ディープラーニングを支える技術 - Chapter 1 ディープラーニングと人工知能]]) ## Parse買収とMongoDBストレージエンジンへの影響(Observability Engineering 2E 第30章) FacebookによるParse買収後、FacebookはParseの基盤である[[MongoDB]]を重要顧客として重視し始めた。この状況下で[[Mark Callaghan]]は、自身がMySQL向けプラガブルストレージエンジンを構築した技術的信用性を梃子に、Facebook社内の影響力とストレージエンジンコミュニティへの人脈を動員し、MongoDBのプラガブルストレージエンジン化と[[RocksDB]]のMongoDBサポートを両社のロードマップに乗せることに成功した。*Observability Engineering* 第2版第30章は、この事例を権威によらない技術的信用性が企業間のロードマップへ影響を与えた「ベンダーエンジニアリング(vendor engineering)」の実例として紹介する。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 30 The Art and Science of Vendor Partnerships]] "How to Influence Another Company's Roadmap") → [[ベンダーエンジニアリング]] ## 2021年10月の大規模障害(『ネットワークシステムについて語るときに我々の語ること』第6章) 2021年10月、Facebookは設定ミスに起因する大規模障害を起こし、DNSサーバのほとんどが到達不能に陥った。発端は「グローバルなバックボーンの容量について可用性を評価する」ことのみを意図した設定変更だったが、これが社内の監査ツールをすり抜けて実行され、BGP経路の消失とDNSによる名前解決の失敗として外部から観測された。DNSサーバはバックボーンとの接続性を失うとBGP経路広告を無効にする設計になっており、これが障害を連鎖させた。 再設定が必要なマシンへの物理アクセスも、入退室管理などの物理セキュリティシステム自体がネットワークの正常稼働に依存していたため困難になった。プライマリとアウトオブバンドのネットワークアクセスの両方が同時にダウンするという、設計時には想定しづらい形で障害が発生した。 著者(Bruce Davie)は、DNS・BGPという本来は障害耐性を備えた分散システムでも、たった一つの設定ミスがサービス全体(WhatsApp・Instagramなどの外部向けサービスから内部の物理セキュリティまで)を機能不全に陥らせうることの教訓として本事例を扱う。問題の設定変更を通過させてしまった「監査ツール」自体の堅牢性(誰が監査人を監査するのか)、およびBGP設定変更のデプロイ前テスト(Batfishのようなツール)の重要性が論点として挙げられる。Facebookの障害から数日後にはTeliaでも同種の障害が発生しており、著者はこれをネットワーク運用の自動化を進めつつもデプロイ前検証を強化すべきだという教訓の再確認として位置づける。 (Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 6 集権化と非集権化]] ch.6 §6.2) → [[集権化と非集権化]] ## 心理的安全性論(『SREの探求』27章) [[John Looney]] は Facebook のプロダクションエンジニアとして、データセンタープロビジョニングチームのマネージャーを務める(『SREの探求』27章執筆時点)。同章は、著者が Google 在職時に関わった Project Aristotle の知見をもとに、心理的安全性がチームの成功を予測する最重要指標であることを論じたものであり、Facebook はその執筆時点での著者所属先として言及される。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 27 SREにおける心理的安全性]]) ## 本番データセンターの高分解能ネットワーク計測(IMC 2017) Facebook, Inc. 所属の [[James Hongyi Zeng]] を共著者に、[[@2017__IMC__High-Resolution Measurement of Data Center Microbursts]] は Facebook の本番データセンター ToR スイッチを対象に、スイッチプラットフォーム搭載の汎用 CPU を用いて 25µs 粒度のカウンタ収集フレームワークを構築した。Web・Cache・Hadoop の3種のラック(各10ラック、24時間分)を計測し、輻輳の大半が 1ms 未満の µburst であること、90パーセンタイルのバースト持続時間が全ラック種別で 200µs 以下であることを定量的に示した。(Source: [[@2017__IMC__High-Resolution Measurement of Data Center Microbursts]]) ## 出典 - 岡野原大輔, 『ディープラーニングを支える技術』, 技術評論社, 2022, 第1章 §1.5補足. - [[@2021__OReillyJapan__SREの探求 - Chapter 27 SREにおける心理的安全性]] - [[@2010__SIGOPS_OSR__Cassandra - A Decentralized Structured Storage System]] - [[@2013__NSDI__Scaling Memcache at Facebook]] - [[@2015__VLDB__Gorilla - A Fast, Scalable, In-Memory Time Series Database]] - [[@2017__SOSP__Canopy - An End-to-End Performance Tracing And Analysis System]] - [[@2015__SREcon15__Notes from Production Engineering]] - [[@2016__SREcon16__Incident Response @ FB, Facebook's SEV Process]] - [[@2026__OReilly__Observability Engineering 2E - Chapter 30 The Art and Science of Vendor Partnerships]] - [[@2021__OReillyJapan__SREの探求 - Chapter 13 Facebookにおけるプロダクションエンジニアリング]] - [[@2017__IMC__High-Resolution Measurement of Data Center Microbursts]] - [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 6 集権化と非集権化]](2021年10月の大規模障害)