# LinkedIn Mountain View, CA を本拠とする大規模オンラインソーシャルネットワーク（Microsoft 傘下）。2013 年時点で約 400 のサービスを複数データセンターの数千台のマシン上で運用しており、サービス指向アーキテクチャ（SOA）運用の最前線にあった。 ## wiki での関連 ### 根本原因分析研究への貢献 - **MonitorRank 評価データ（SIGMETRICS 2013）**: Roshan Sumbaly・Sam Shah が在籍し、[[Myunghwan Kim]] とともに MonitorRank を提案。LinkedIn の本番異常ラベルデータ（レイテンシ 25 件・エラー数 71 件・スループット 35 件）で評価。LinkedIn の監視チームが収集したサービスコールグラフを実験基盤として提供した。 - **Kafka（メッセージングシステム）**: メトリクス収集パイプラインの核として使用。Kafka の原著論文（Kreps et al., NetDB 2011）は MonitorRank の引用文献に含まれる。 - **"People You May Know" フィーチャー**: コールグラフの具体例として挙げられる。ウェブサーバ → 推薦サービス → プロファイルサービス という 3 サービスのコールチェーンで構成される。 ## サービスアーキテクチャの特徴 本論文（2013 年時点）で言及された LinkedIn のアーキテクチャ: - サービス数: 約 400 - 稼働マシン数: 数千台 - データセンター数: 複数（世界各地） - センサー単位: `<サービス, API>` の組み合わせ（各サービスが複数 API を持つ） - メトリクス: レイテンシ・スループット・エラー数が標準 ### アラート相関のスパイク検知（SREcon21） - **修正 Z スコアによるスパイク分離**: [[Nishant Singh]] が SREcon21 Americas で発表。LinkedIn のアラート相関システム（AC Engine）の出力に対し、修正 Z スコア（MAD ベース）で一時的スパイクと真のアラートを分離する後段フィルタを実装。約 5 日間で 193 件中 71 件（36.4%）のスパイクを検出し、偽陽性率 1% 未満を達成。ML を使わない単純な統計手法でトイルを 30–40% 削減した。 - **インフラ構成（2021 年時点）**: Internet → Border Router → EDGE（IPVS → ATS + Stickyrouting Service）→ DATA CENTER。アラート源は Autoalerts、サービス依存関係は Callgraph から取得し、推奨結果は Slack・Iris・Web UI へ配信。 ### サードパーティ統合とベンダー協働（『SREの探求』5章） - **マルチ CDN・マルチ DNS の集中管理ツール**: [[Jonathan Mercereau]] のチームは何年にもわたり 6 社以上の CDN プロバイダおよび 3 社以上の DNS プロバイダと協力していた。プロバイダごとの手作業をボトルネックにしないため、コンテンツのパージ・DNS レコードの変更・データのレポートといったタスクをプロバイダ横断で統一的に処理する集中化システムを実装し、リクエストの抽象化とデータの正規化によって各プロバイダで最大限の実装効果を得た。 - **CDN 設定変更の回帰テストスイート**: 設定変更のたびにその前後、および定期的にも実行される回帰テストのスイートを整備した。静止画像・JavaScript・スタイルシートといったコンテンツプロファイルごとにキャッシュ可能性・保持ルール・ネガティブテスト(HTTP 404/500)・エラー処理・圧縮・プロトコルを検証し、オリジンとして機能する基礎サービスへの変更を検出して性能・信頼性の問題に先手を打てるようにした。 - **ベンダーロックインへの警戒**: DNS のジオステアリング(Geo-steering)や CDN/DSA の ESI(Edge Side Includes)のような、サードパーティ固有の優れた機能であっても競合ベンダーのソリューションと組み合わせられない場合があり、いったん独自機能を使い始めた後で標準的なワークフローに巻き戻すコストが、代替ソリューション実装のコストを上回ることがあるとして常に警戒していた。 - **合成モニタリングの大規模運用**: 合成モニタリングチームはすべてのプロダクトをカバーして問題を検出するために、テストのスイートを 15 倍にまで成長させ、CDN・DNS のコンテンツデリバリ問題の特定や設定変更に伴う問題の検知に活用した。 (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 5 サードパーティとの協力を円滑に進める重要性]] §5.1.3, §5.2.4.1, §5.2.4.3, §5.2.4.2) ### データセンターネットワークの100G Transformation(2016年) LinkedInは2016年、32x100Gスイッチ(各ポート25/50/100G対応)を用いた3-Stage Clos構成でデータセンターネットワークを刷新した。Top-Spineを4グループ(Plane 1〜4)に再配置し、Mid-Spineの各スイッチが対応するPlaneへのみ接続するマルチプレーン構成を採る。Leafで6:1のオーバーサブスクリプションを適用し、サーバー接続25G×48に対しアップリンクは50G×4=200Gbpsとする設計。この構成はFat-Tree(3-stage Clos)の理論的構造からSpine層を意図的にグルーピングし直すことで導出されている。(Source: [[@2022__SpeakerDeck__Clos Network Topology 再入門]], 出典: https://engineering.linkedin.com/blog/2016/03/the-linkedin-data-center-100g-transformation) ## 関連ソース - [[@2013__SIGMETRICS__Root Cause Detection in a Service-Oriented Architecture]]（MonitorRank の評価基盤・共著者所属） - [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]]（アラート相関のスパイク検知） - [[@2021__OReillyJapan__SREの探求 - Chapter 5 サードパーティとの協力を円滑に進める重要性]]（マルチベンダー CDN/DNS 統合の実務経験） - [[@2022__SpeakerDeck__Clos Network Topology 再入門]]（100G Transformationのデータセンターネットワーク設計事例） ### 成功の文化としてのSRE（『SREの探求』22章） - [[Kurt Andersen]] は LinkedIn のプロダクト SRE チームにおけるシニア IC(individual contributor)として、SRE を障害削減ではなくビジネスの成功実現に集中する活動として捉え直し、4つの文化的価値・5本のイネーブリング柱・4段階の実施フェーズ(消火活動/事後対応→門番→支持者/パートナー→触媒)という枠組みを提示した。同章ではオンコール支援ツールとして LinkedIn の SRE 部門がオープンソースで提供する Iris・Oncall や、コードコミットの責任を分散対応フレームワークに統合する手法(Project Star)にも言及される。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 22 成功の文化としてのSRE]] §22.3.2) ## 関連エンティティ - [[Myunghwan Kim]]（Stanford インターン、第一著者） - [[Nishant Singh]]（シニア SRE、Production-SRE チーム） - [[Jonathan Mercereau]]（元 SRE。マルチベンダー CDN/DNS 統合とツール管理を担当） - [[Kurt Andersen]]（プロダクト SRE チーム シニア IC。『SREの探求』22章の著者） - [[Logan Rosen]]（スタッフ SRE。クマムシプロジェクト創立メンバー、『カオスエンジニアリング』7章の著者） ### カオスエンジニアリングの導入（『カオスエンジニアリング』7章） - [[Logan Rosen]] は、組織にカオスエンジニアリングを導入した LinkedIn の SRE として、[[クマムシプロジェクト]](Waterbear project)の一環でリクエストレベルの故障注入フレームワーク [[LinkedOut]] を構築した。LinkedOut は Rest.li のプラガブルなフィルタチェーンを利用し、社内実験フレームワーク [[LiX]] と連携して実験対象を LinkedIn の従業員(同意した者)に限定してターゲティングする。ブラウザエクステンションによる高速な単発実験は影響範囲が従業員自身のセッションに閉じ、自動実験はサービスアカウント・合成ユーザのみを対象とすることで、実際の LinkedIn メンバーへの影響を回避しながらサービスの堅牢性を検証する。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 7 LinkedIn メンバーに対して配慮すること]] §7.4)