# 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 へ配信。 ## 関連ソース - [[@2013__SIGMETRICS__Root Cause Detection in a Service-Oriented Architecture]]（MonitorRank の評価基盤・共著者所属） - [[@2021__SREcon21__Spike Detection in Alert Correlation at LinkedIn]]（アラート相関のスパイク検知） ## 関連エンティティ - [[Myunghwan Kim]]（Stanford インターン、第一著者） - [[Nishant Singh]]（シニア SRE、Production-SRE チーム）