# Netflix グローバル動画ストリーミング企業。数千のマイクロサービスからなる大規模分散システムを運用し、SRE・オブザーバビリティ・マイクロサービスアーキテクチャの実践知を Netflix TechBlog やオープンソースプロジェクト(Hystrix、Eureka 等)で広く公開している。 ## wiki 内の言及 - [[@2026__Netflix TechBlog__GenRec - Towards LLM-native Recommendation at Netflix]]: 内製の基盤LLMをNetflix固有データでpost-trainしたLLMバックエンド推薦ランカー「GenRec」の事例。ユーザー履歴・アイテムメタデータ・文脈を自然言語へ言語化し(特徴量エンジニアリングからコンテキストエンジニアリングへの転換)、カタログ対応スコアリングヘッドとprefill-only推論でフルカタログランキングを行う。大規模A/Bテストで、成熟した本番ランカーに比べPhase-2ラベルを約40分の1しか使わずに短期・長期双方のオンライン指標で統計的有意な改善を達成した。[[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]]が報告する内製vLLM/Tritonサービング基盤の上で動く応用事例にあたる。新規 concept [[LLMネイティブ推薦]]。 - [[@2011__a16z__Why Software Is Eating the World]]: [[Marc Andreessen]] のエッセイは、契約者数で当時最大の動画サービスであった Netflix を「ソフトウェア企業」の代表例として挙げ、Netflix が Blockbuster を駆逐した経緯を、伝統的な動画・娯楽産業がソフトウェアに置き換えられる現象の典型例として言及する。 - [[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]]: 既存の統合サービングシステム(MSS/Triton)上でLLM推論を内製運用する事例。TensorRT-LLMから[[vLLM]]へのpaved-pathエンジン移行、[[Triton Inference Server]]のvLLMバックエンド採用、OpenAI互換APIの追加、Red-Black/Versionedデプロイ戦略、vLLM V0→V1移行によるlogits processorのバッチレベル化を報告。 - [[@2026__Netflix TechBlog__From Silos to Service Topology - Why Netflix Built a Real-Time Service Map]]: リアルタイムサービス依存マップ「Service Topology」の構築経緯と技術アーキテクチャを解説。eBPF・IPC メトリクス・分散トレースの 3 層統合。 - [[@2016__SREcon16__Incident Management and Chatops @ Netflix Feat Scorebot]]: [[Al Tobey]] による SREcon16 発表。Go 製チャットボット Scorebot を使った ChatOps によるインシデント管理自動化。Hipchat から Slack への移行直後の 2016 年 3 月の実践報告。 - [[@2022__KDD__Rapid Regression Detection in Software Deployments through Sequential Testing]]: [[Michael Lindon]]・[[Chris Sanden]]・[[Vaché Shirikian]] による KDD '22 発表。既存のカナリア分析システム [[Kayenta]] が抱える固定-$n$統計検定の「peeking」問題を、逐次検定(sequential testing)と anytime-valid な confidence sequenceで解決するフレームワークを提案。PlayDelay劣化・Successful Play Starts減少という2つの実運用ケーススタディで数十秒〜十数秒での検知を実証。 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]]: [[Brendan Gregg]]が2017年当時Netflixのパフォーマンスエンジニアとして、クラウドパフォーマンスチームで誰でも使えるパフォーマンスツール作りやマイクロサービス・SREチーム支援に従事していたと紹介される。同章はNetflixがブルー・グリーンデプロイメントを「red-black deployment」と呼んでいると脚注で注記しており、この用語は[[@2026__Netflix TechBlog__In-House LLM Serving at Netflix]]が報告するRed-Black/Versionedデプロイ戦略と同一の企業内用語法である。 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]]: Netflix のあるマイクロサービス(顧客推奨度を計算するJavaアプリケーション)をAWS EC2上のVMからコンテナプラットフォームTitusへテスト移行した際、要求レイテンシが3、4秒から1秒へ短縮した事案の実務調査。ロードバランサ(AWS ELB)によるトラフィック分割を利用した比較分析、[[USE メソッド]]・PMC・トレーシングによる原因分析の結果、パフォーマンス差はコンテナに"隣人"がいなかったこと・LLCサイズとワークロードの違いによる[[Instructions Per Cycle]]差(2.6倍)・CPU負荷の違いという3要因の重なりだったと結論づけられ、テスト条件依存の効果であり本番では持続しないと注記された。 - [[@2021__OReillyJapan__SREの探求 - Chapter 1 SREにおけるコンテキストとコントロール]]: [[Coburn Watson]](当時 Netflix のサイトリライアビリティ・性能エンジニアリング・クラウドインフラストラクチャ部門責任者)が、Netflix の SRE 実践を「コントロールベースモデル」よりも「コンテキスト駆動型モデル」を重視するものとして解説。イミュータブルデプロイ(レッド/ブラック)・動的プロパティ更新の Fast Properties・継続的デプロイプラットフォーム [[Spinnaker]] によるガードレール・レイテンシ/フォールトトレランスフレームワーク [[Hystrix]] のバルクヘッドパターンを技術基盤として紹介し、マイクロサービス可用性スコアカードフレームワークによるジャストインタイムなコンテキスト提供、Netflix SRE を「中枢神経系」と位置づける組織論を語る。 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]]: Netflix が[[障害注入]](fault injection)の本番適用——意図的にプロセスを終了させる等の障害をあえて注入し、システムの実際の挙動を検証する手法——を Chaos Monkey ツールで普及させたパイオニアとして紹介される。本番環境での障害注入は一般に*chaos engineering*と呼ばれる。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "Fault injection") - [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]]: Netflix で3年間カオスチームの責任者を務めた [[Casey Rosenthal]] による当事者記録。マイクロサービス間の正常な意思決定の積み重ねがシステム全体の障害を生む仮想例、2010〜2011年のクラウド移行に伴う [[Chaos Monkey]] 導入経緯とその効果(SPOF起因障害が4年間で1回のみ)、リージョン単位停止の [[Chaos Kong]] への拡大、2015年末の PrinciplesofChaos.org 定式化までの経緯を詳述する。DDIA 2E([[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]])が第三者視点で紹介する「Chaos Monkey パイオニア」という位置づけを、当事者本人の一次資料として裏付ける。 - [[@2021__OReillyJapan__SREの探求 - Chapter 24 イミュータブルなインフラストラクチャとSRE]]: 元 Netflix・Stripe の [[Jonah Horowitz]] による執筆。Netflix が独自に公開したオープンソースツール Aminator を、アプリケーションコードをベースイメージへインストールするツールの例として言及し、[[Chaos Monkey]] を「イミュータブルなインフラストラクチャがあれば、システム内で障害を誘発させる作業を安心して行える」文脈で再度参照する(§24.2, §24.11)。 - [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 2 データマネジメント]]: Netflix を「データを資産に変える」ことに成功した組織の代表例として言及する。高品質な番組・映画を顧客に推薦できることが初期の差別化要因であり、コンテンツ制作段階に入ってからは、視聴者が何を見たいかの詳細な理解をもとにどの視聴者にどの番組を作るべきかを判断するためにこのデータを利用したと言われている、とされる。(Source: [[@2024__OReillyJapan__信頼性の高い機械学習 - Chapter 2 データマネジメント]] §2.1) - [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 11 機械学習の人的側面]]: Stitch Fixと並んで、フルスタックデータサイエンティスト(モデル開発から本番運用までをエンド・ツー・エンドで担当するデータサイエンティスト)の成功にはツール・インフラが不可欠であることを示す事例として引用される。Netflixのモデルでは、まず専門家がビルドツール・デプロイパイプライン・指標とアラート・インサイトツールをそれぞれ自動化し、データサイエンティストがそのツールを駆使してプロジェクト全体(設計・開発・テスト・デプロイ・サポート・オペレーション)を担当する「開発者の全体サイクル」が紹介される。(Source: [[@2023__OReillyJapan__機械学習システムデザイン - Chapter 11 機械学習の人的側面]] §11.2.2.2) - [[@2022__OReillyJapan__カオスエンジニアリング - Introduction カオスの誕生]]: カオスエンジニアリングの成立史を Netflix 内部の視点で辿る。2008年のクラウド移行発表直後に発生したデータベース障害と、未成熟だった当時の AWS でインスタンスが警告なく消滅する事象への対処から [[Chaos Monkey]] が生まれ、2012年のクリスマスイブの AWS ELB 障害を契機にリージョン単位の [[Chaos Kong]] へ拡張された経緯を詳述する。2015年に [[Bruce Wong]] がカオスエンジニアリングチームを結成し [[Casey Rosenthal]] に定義策定を委ね、Principles of Chaos Engineering が定式化された後、[[カオスコミュニティデー]] を通じた業界コミュニティ形成と [[Nora Jones]] の2017年 AWS re:Invent 基調講演がこの分野を業界の主流舞台へ押し上げたと記す。 - [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 7 End-to-End Data]]: 動画オンデマンドサービスの代表例として、[[適応ビットレートストリーミング]]の実務説明に登場する。複数の品質レベル×セグメントのチャンク群をあらかじめ符号化しておき、受信側の再生キューの充填状況に応じて次に要求するチャンクの品質をHTTP経由で切り替える方式(HTTPアダプティブストリーミング、DASH/HLS)の典型例として言及される。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 7 End-to-End Data]] §7.2.4) - [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 9 先見性を生み出す]]: 著者([[Casey Rosenthal]])が2017年にNetflixで携わった故障注入自動化プラットフォーム [[ChAP]] の開発経験を描く。ChAP は本番トラフィックの一部を実験(カナリア)クラスタとコントロール(ベースライン)クラスタへ振り分け、故障注入シナリオを適用する仕組みを持つ。ChAP の Runs ページで実行者を分析した結果、実際にツールを使い続けていたのは作成者であるカオスエンジニア4人にとどまっていたことが判明し、実験を自動生成するアルゴリズム開発のため組織横断で約30人にインタビューを実施した経緯を記す。最終的に、自動化そのものより副産物のダッシュボードがチームのメンタルモデル更新に最大の価値をもたらしたと総括される。 - [[@2022__OReillyJapan__ソフトウェアアーキテクチャの基礎 - Chapter 6 アーキテクチャ特性の計測と統制]]: [[Chaos Monkey]] を含む Simian Army の他メンバーを、アーキテクチャ特性の統制を自動検証する「適応度関数」の実例として紹介する。Conformity Monkey は各サービスがRESTful動詞にうまく応答すべきといった本番環境の統制ルールを、Security Monkey は既知のセキュリティ上の欠陥がないかを、Janitor Monkey はどのサービスからもアクセスされなくなった孤児インスタンスを検出し本番環境から切り離す役割を担うと説明される。