# 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]]） ## 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]]） ## 出典 - [[@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]]