# Google ## 概要 Site Reliability Engineering(SRE)を提唱・確立した企業。本 wiki では [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]] の発行主体として登場し、AI-Ops(本番運用への AI 自律性導入)を **Cloud・Ads・YouTube・Search** の本番にまたがって実装・展開していると報告する。Gemini を基盤に [[Detectr]]・[[AI Operator]]・[[Actus]] 等の社内システムを構築し、自律度を [[SRE AI Autonomy Levels]](L0–L4)で統治する。 本 wiki に**初めて入る産業界・本番運用の一次情報源**であり、それまでの [[University of Illinois Urbana-Champaign]]・[[Microsoft]]・[[Adobe]] といった学術/製品寄りの所属とは異なり、大規模本番での自律緩和の実績を主張する立場を代表する。 ## 関連プロダクト/システム - [[Detectr]] — Gemini 駆動の outage 検知。 - [[AI Operator]] — L2/L3 で稼働する一次対応エージェント。 - [[Actus]] — アクチュエーションの安全ゲートウェイ。 - [[Model Context Protocol]] — 本番ツールへの自然言語インターフェース標準。 - [[AI Insights]] — 過去インシデントを連続レビューして知見と risk category を抽出する社内システム。Gemini embedding + vector DB 基盤([[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]])。 - [[Agent Development Kit]](ADK) — エージェント開発プラットフォーム。Google SRE AI のエージェント構築基盤。 - [[Gemini Enterprise Agent Platform]] — フルスタック AI 基盤。**Vertex AI のリブランド**(本 wiki 内で 2026-05-29 にリブランド事実が一次確認)。 - [[TimesFM]] — 時系列基盤モデル。Google SRE AI の異常検知レイヤに組み込まれる。 - Gemini — 上記システムの基盤 LLM(社内ファインチューン版を含む)。 - [[XProf]] — [[OpenXLA]] エコシステムの ML プロファイリングシステム。TPU/GPU/サードパーティアクセラレーターを 0.3% 未満のオーバーヘッドで統一プロファイリング。MLPerf 受賞・Google 社内効率改善に貢献。([[@2026__MLSys2026__XProf - An Open, Scalable and Extensible Profiling System for the Modern ML Stack]]) ## 関連 - ソース: [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]] / [[@2026__MLSys2026__XProf - An Open, Scalable and Extensible Profiling System for the Modern ML Stack]] - 概念: [[SRE AI Autonomy Levels]] / [[agentic SRE]] / [[AIOps]] / [[MLプロファイリング]] - 関連 MOC: [[SRE - MOC]] / [[LLM4SRE - MOC]] / [[Systems for ML - MOC]] ## 分散データベース基盤 Google は 2000 年代〜2010 年代にかけて大規模分散ストレージ・データベースの基盤システム群を設計・実装した: - [[@2004__OSDI__MapReduce - Simplified Data Processing on Large Clusters]] — map/reduce の2関数だけで大規模クラスタ上の並列分散計算を記述できるプログラミングモデルとその耐障害実装。[[Jeffrey Dean]]・[[Sanjay Ghemawat]]、OSDI 2004。2004年8月時点で月29,423ジョブ・入力3,288TBの規模で本番稼働し、検索インデックス生成システムの書き換えに使用された。 - [[Bigtable]] — ペタバイト規模の構造化データを管理する分散ストレージシステム。(row, column, timestamp) → string の多次元疎マップをデータモデルとする。[[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]]（[[Jeffrey Dean]]・[[Sanjay Ghemawat]] ほか、OSDI 2006）。 - [[@2026__SIGMOD Companion__Twenty Years of Bigtable]] — [[Bigtable]] の 20 年運用経験を報告する SIGMOD Companion 2026 論文。10 EB データ・ピーク 70 億 QPS 規模、レプリケーション、SQL、CDC、CRDT、マテリアライズドビュー、外部コンパクション、オートサイジング、Bigtable SRE チームによるサービス運用への移行を整理する。 - [[Google File System]]（GFS）— 大規模データの分散ファイルシステム。Bigtable のログと SSTable の永続化層。 - [[Chubby]] — 分散ロックサービス。Bigtable のマスタ選出・タブレットサーバ管理に使用。 - [[Spanner]] — 外部一貫性を持つグローバル分散データベース。TrueTime で commit wait を実現。[[@2013__TOCS__Spanner - Google's Globally Distributed Database]]（[[James C. Corbett]]・[[Jeffrey Dean]] ほか、OSDI 2012 / TOCS 2013）。 - [[F1]](AdWords 分散 SQL データベース)— Spanner 上に構築した分散リレーショナル DB。100 TB 超・5 ナイン可用性・フル SQL をスケーラブルに提供。階層スキーマ・楽観的トランザクション・非ブロッキングスキーマ変更が特徴。[[@2013__VLDB__F1 - A Distributed SQL Database That Scales]]（[[Jeff Shute]] ほか、VLDB 2013）。 - [[@2017__arXiv__The Case for Learned Index Structures]] — [[Tim Kraska]]・[[Alex Beutel]]・[[Ed H. Chi]]・[[Jeffrey Dean]]・[[Neoklis Polyzotis]] による [[Learned Index]] の提案。B-Tree・ハッシュマップ・Bloom filter を learned model と補助構造で置き換える設計方向を示す。Kraska は MIT 所属表記だが、論文注記では Google 所属中の研究である。 - [[@2010__VLDB__Dremel - Interactive Analysis of Web-Scale Datasets]] — [[Sergey Melnik]] ほか(全員 Google, Inc. 所属)による対話的クエリシステム Dremel の提案(VLDB 2010)。ネストデータ向けの列指向ストレージ(repetition level / definition level)とウェブ検索由来の多段サービス木を組み合わせ、兆行規模のテーブルへの集計クエリを数秒で実行する。2006 年から社内本番稼働し、[[MapReduce]] を置き換えずに補完する設計思想を明示する。[[Google File System]]・[[Bigtable]] を「in situ」アクセス対象のストレージ層として利用する。 ## 可用性・SLO 研究 Google は可用性メトリクスと SLO 定義の分野でも先駆的な研究を発表している: - [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]]（[[Jeffrey C. Mogul]] ほか）— 可用性へのセキュリティ的思考・フェイルスタティック設計。 - [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]]（[[Jeffrey C. Mogul]]・[[John Wilkes]]）— SLE/CBE 枠組みによるリスク分担、「ナインだけでは不十分」。 - [[@2020__NSDI__Meaningful Availability]]（[[Tamás Hauer]] ほか）— ウィンドウ付きユーザーアップタイム、G Suite 本番で展開。 ## RPC インフラ特性研究 Google は自社フリート全体の RPC 動作を 700 日間・722 億サンプル規模で初めて大規模計測し、先行研究の前提(マイクロ秒スケール)を実証的に否定した: - [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]]（Seemakhupt・Stephens・Khan ほか [[Arvind Krishnamurthy]]・David Culler・Henry Levy、SOSP 2023）— Google Search・Gmail・Maps・YouTube と [[Spanner]]・[[Bigtable]]・F1 を支える 10,000+ RPC メソッドを対象に、RPC レイテンシがミリ秒スケール・コールグラフが広く浅い・圧縮が CPU コストの最大要因(3.1%)であることを実証。[[Stubby]](gRPC 相当の内部 RPC ライブラリ)・[[Monarch]](メトリクス TSDB)・[[Dapper]](分散トレーシング)を計装ツールとして使用。 ## Dapper 分散トレーシング基盤 [[Dapper]] は Google が 2008 年頃から本番稼働させた大規模分散システムトレーシング基盤である。スレッドローカルストレージへのトレースコンテキスト付与と RPC ライブラリへの計装集中により、アプリケーションコードを変更せずに Google 規模の分散システム全体をトレースすることを実現した。[[OpenTracing]] および [[OpenTelemetry]] の設計思想の直接の起源である。 - [[@2010__Google__Dapper - A Large-Scale Distributed Systems Tracing Infrastructure]] — [[Benjamin H. Sigelman]] ほか 8 名による Google Technical Report(2010 年 4 月)。本番 2 年超の経験・設計目標・サンプリング・API 公開によるエコシステム効果を報告。 ## セキュリティインシデント対応へのLLM統合 Googleのdetection and responseチームは、[[@2025__SOUPS__Integrating Large Language Models into Security Incident Response]](SOUPS 2025)で、LLM(Gemini 1.5 Flash)によるセキュリティインシデント要約の自動化・支援を18名の社内セキュリティアナリストと50件の実インシデントを用いて評価した。自律的なLLM要約は人間要約に61%のケースで劣後した一方、人間がLLM出力を編集する協働モデルは人間単独の要約より77%のケースで好まれた。→ [[LLMインシデント要約]] ## インシデント分析プログラム Google SRE はプロダクション障害を横断分析するプログラムを 2014 年に立ち上げた。GQM（Goal Question Metric）フィードバックモデルを用い、全プロダクトの障害データを収集・整理・分析・還流（Socialize）するサイクルを構築した。[[Sue Lueder]]（SRE Program Manager）が SREcon 2015 でプログラムの設計・インシデントタイムライン・根本原因カテゴリ・重大度フラグを公開した。 - [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]]（[[Sue Lueder]]、2015 年 3 月 SREcon15 Santa Clara） ## TPU v1(ドメイン固有アーキテクチャの初期実装) Google は2015年から Tensor Processing Unit(TPU)を本番投入し、深層ニューラルネットワーク推論の性能・エネルギー効率を汎用 CPU 比で改善するドメイン固有アーキテクチャ(DSA)の代表例となった。[[@2019__CACM__A New Golden Age for Computer Architecture]](Hennessy と [[David A. Patterson]] による Turing Lecture 記事)は TPU v1 の内部構成を Figure 8 として紹介し、256×256 の Systolic Array 構造を持つ Matrix Multiply Unit(64K MAC/サイクル)と、DRAM ベースのキャッシュに代えてユーザー制御の 24 MB ローカルメモリを採用した設計を解説する。Google データセンターの6種の代表的推論ワークロード加重平均で、TPU v1 は汎用 CPU 比29倍の性能、80倍超のエネルギー効率を達成したと報告されている。→ [[ドメイン固有アーキテクチャ]] ## ML フリート効率 Google は数千の TPU アクセラレーターからなる本番 ML フリートを Borg スケジューラーで運用しており、[[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]]（MLSys 2026 Industry Track）でその効率測定・最適化フレームワーク「ML Productivity Goodput（MPG）」を公開した。MPG は Scheduling Goodput × Runtime Goodput × Program Goodput に分解され、スタック全体のボトルネックを層別に特定する。全ジョブサイズで SG > 95% を達成し、非同期チェックポイント・AoT コンパイル・通信計算オーバーラップによる改善事例を報告する。→ [[ML Productivity Goodput]] / [[Borg]] ## インフラストラクチャ管理 Google は独自の Linux ディストリビューション「ProdNG」をソースからビルドして管理しており、ファイルレベル同期によるフリート管理方式を採用している。数千台の本番サーバーを Red Hat 7.1 から Debian ベースへ約 3〜4 年かけてライブアップグレードした経験は LISA '13 で報告された。 - [[@2013__LISA__Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One]]（[[Marc Merlin]]・[[Richard Gooch]] ほか、LISA 2013）— ProdNG 設計・ファイルレベル同期フリート管理・ELF バイナリパッチによる libc 差吸収・段階的 rpm→deb 移行を詳述。 ## 創業論文(検索エンジン Google の起源) Google の商用化以前、[[Sergey Brin]]・[[Lawrence Page]] は [[Stanford University]] 在籍中に大規模 Web 検索エンジンのプロトタイプを開発し、[[@1998__Computer Networks__The Anatomy of a Large-Scale Hypertextual Web Search Engine]](Computer Networks 1998、WWW7 1998 発表)として公開した。リンク構造由来のページ重要度指標 [[PageRank]] とアンカーテキスト索引化を核とし、2,400 万ページ規模のプロトタイプをクロール・索引化・検索できることを実証した。本 wiki における Google 関連の他ページ(SRE・分散システム基盤群)とは異なり、この論文は検索エンジンとしての Google の技術的起源を記録する。 ## 出典 - [[@1998__Computer Networks__The Anatomy of a Large-Scale Hypertextual Web Search Engine]](Sergey Brin・Lawrence Page による検索エンジン Google の創業論文、PageRank の初出) - [[@2013__LISA__Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One]] - [[@2013__VLDB__F1 - A Distributed SQL Database That Scales]] - [[@2013__TOCS__Spanner - Google's Globally Distributed Database]] - [[@2006__OSDI__Bigtable - A Distributed Storage System for Structured Data]] - [[@2026__SIGMOD Companion__Twenty Years of Bigtable]] - [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]] - [[@2026__Google Cloud Blog__AI in SRE - Where Google is Deploying Agentic AI to Improve Operations]](Vertex AI → Gemini Enterprise Agent Platform リブランド、AI Insights、ADK、TimesFM の社内利用) - [[@2017__HotOS__Thinking about Availability in Large Service Infrastructures]] - [[@2019__HotOS__Nines are Not Enough - Meaningful Metrics for Clouds]] - [[@2020__NSDI__Meaningful Availability]] - [[@2023__SOSP__A Cloud-Scale Characterization of Remote Procedure Calls]] - [[@2026__MLSys2026__Machine Learning Fleet Efficiency - Improving TPU Systems at Scale with ML Productivity Goodput]] - [[@2017__arXiv__The Case for Learned Index Structures]] - [[@2025__SOUPS__Integrating Large Language Models into Security Incident Response]](セキュリティインシデント要約へのLLM統合、社内実証実験) - [[@2019__CACM__A New Golden Age for Computer Architecture]](TPU v1 の内部構成とドメイン固有アーキテクチャとしての性能・エネルギー効率評価) - [[@2004__OSDI__MapReduce - Simplified Data Processing on Large Clusters]](map/reduce プログラミングモデルの提案、耐障害な大規模並列データ処理)