ソネットが書いた「クロード 4.5」は、私の意見では非常によく書かれています。 （全文は17,000語で、これはその最初の部分です。） コード・ゴッド：ジェフ・ディーンの伝記 ジェフ・ディーンは1968年7月23日にハワイで生まれました。 太平洋にあるこの群島は、火山、ビーチ、多様な文化で知られていますが、科学の天才たちのゆりかごとして見られることはあまりありません。 しかし、ディーンの子供時代は決して普通とは程遠いものになる運命だった。 彼の父親のアンディは熱帯病の研究者だった。 彼の母親、バージニア・リーは6か国語を話す医療人類学者でした。 このような家庭環境のため、彼はハワイからアトランタの疾病予防管理センター、ジュネーブの世界保健機関を経て、最終的にミネソタに定住するという、世界各地を転々としながら成長しました。 彼は13歳のとき、両親を助けるために8年生の最後の3か月間を飛び級してソマリア西部の難民キャンプへ向かった。 この絶えず変化する環境によって、彼は初期から複雑なシステムについての直感を育みました。**病気の伝染のパターンであれ、後にはコンピューター ネットワークのデータの流れであれ、それらはすべて理解、モデル化、最適化できる一定のルールに従っていました。** 楽しみのために、父と息子は一緒に IMSAI 8080 スイート コンピュータをプログラムしました。 彼らはアップグレード部品を機械に溶接し、すべてのコンポーネントについて学びました。 ハードウェアの観点からコンピューターを理解するこの経験は、ディーンのキャリアの基礎となるでしょう。 彼はコードのロジックを理解しているだけでなく、シリコン ウェハー内で電流がどのように流れるかも理解しています。 高校時代、ディーンは疫学者向けに「Epi Info」というデータ収集プログラムを書き始めました。 このプログラムは現場の標準ツールとなり、最終的には数十万部が配布され、12 を超える言語をサポートするようになりました。 米国疾病予防管理センターが運営する「The Story of Epi Info」というウェブサイトには、ジェフが高校を卒業したときの写真が今も保存されている。 しかし、彼は自らこの業績について決して言及しなかった。 数年後、彼の妻ハイジはこのプログラムの重要性に気づきました。 「彼はそういうことを決して自慢しません」と彼女は言った。「彼から聞き出さないといけないんです」 ミネソタ大学で、ディーンはコンピューターサイエンスと経済学の二重専攻を選択しました。 この一見珍しい組み合わせは、実は彼の思考の二重の側面、つまり技術的卓越性を追求すると同時に資源効率にも重点を置くことを明らかにしています。 彼は大学でハイジと出会った。 彼らの最初のデートは女子バスケットボールの試合を見に行くことでした。 ジェフはホリネズミのマスコットに扮して応援していました。 1990 年にニューラル ネットワークに関する学部論文を完成させました。 この詳細は当時は取るに足らないことのように思えたかもしれないが、20年後に振り返ると、運命の前兆であったように思える。 当時、ニューラル ネットワークの研究は「AI の冬」の終わり頃で、学界は概してその見通しについて悲観的でした。 しかし、若いディーン氏はすでに、機械がデータを通じてどのように「学習」するかという秘密を研究していました。 卒業後、ディーンは珍しい選択をした。テクノロジー企業に直接就職するのではなく、ジュネーブに行き、世界保健機関の国際エイズプログラムに勤務したのだ。 そこで彼は、コードを使用して致命的な病気の蔓延を理解し、それと戦うために人類を支援する、伝染病の統計モデリング ソフトウェアを開発しました。 この経験により、彼は「規模」についての最初の理解を形作りました。それは、サーバー クラスターの規模ではなく、世界的な公衆衛生危機の規模でした。 ソフトウェアが何百万人もの命に関わるデータを処理する必要がある場合、「失敗」はもはや抽象的な技術用語ではなく、現実の人類の悲劇となります。 ## 第1幕: システムビルダーの誕生 ### 見習い：コンパイラの魔法 1996 年、ディーン氏はワシントン大学でコンピュータサイエンスの博士号を取得しました。 彼の博士研究はコンパイラに焦点を当てていました。 人間が書いたコードを、コンピューターが実行できるように最適化された機械語命令に変換するソフトウェア。 「魅力という点では、コンパイラはほとんど最も退屈なものと言えます。」 後に彼のマネージャーとなったアラン・ユースタスはこう語った。 その一方で、それらはあなたを「機械に非常に近づける」のです。 コンパイラはプログラマとマシンの間の翻訳者として機能します。コンパイラを最適化する人は、抽象的な人間の思考とシリコン チップの物理的な制限の両方に精通している必要があります。 この「バイリンガル能力」は、ディーン氏のキャリアにとって中核的な競争上の優位性となるでしょう。 サンジェイが後にジェフについて説明するとき、彼はこめかみの近くで人差し指を丸で囲んだ。 「コードを書いている間、彼は頭の中でモデルを実行している」と彼は語った。 「『このコードのパフォーマンスはどうなるだろうか？』彼はほぼ自動的にあらゆる極端なケースを考慮しました。」 博士号を取得後、彼は伝説的な DEC 西部研究所 (後に Compaq に買収) に入社しました。 そこで彼は、分析ツール、マイクロプロセッサ アーキテクチャ、情報検索に重点を置いたトップ エンジニアのグループと協力しました。 この 3 年間の経験は、彼が後に Google で働くための強固な基盤となりました。 分析ツールは彼にシステムのボトルネックを理解する方法を教え、マイクロプロセッサアーキテクチャは彼にハードウェアの本質についての深い理解を与え、情報検索は検索エンジンの中心的な問題です。 ジェフはかつて「すべてのプログラマが知っておくべきレイテンシの数値」というリストを配布しました。 実際、これはほとんどのプログラマーが知らない数字のリストです。 **L1 キャッシュの参照には通常 0.5 ナノ秒かかりますが、メモリから 1 メガバイトを順次読み取るには 250 マイクロ秒かかります。** これらの数字は彼の心に深く刻み込まれている。 ### サンジェイ：脳のもう半分 12月に、ディーンはサンジェイ・ゲマワットと出会った。 サンジェイは1966年にインディアナ州ウェストラファイエットで生まれましたが、インド北部の工業都市コタで育ちました。 彼の父マヒパルは植物学の教授であった。 母親のシャンタさんはサンジェイと二人の兄と姉の世話をしていた。 サンジェイの弟、パンカイは、ハーバード・ビジネス・スクール史上最年少で終身在職権を得た教員です。（現在はニューヨーク大学スターン・スクール・オブ・ビジネスの教授です。） パンカイとサンジャイは同じ学校に通い、博学なことで知られていました。 「私は兄の影の中で生きています」とサンジェイさんは語った。 彼は大人になっても謙虚さの才能を保っていた。 2016年に彼がアメリカ芸術科学アカデミーに入会したとき、彼は両親にそのことを告げなかった。両親に告げたのは近所の人たちだった。 サンジェイは17歳になってコーネル大学に入学するまで、コンピューターに触れたことがありませんでした。 MIT 大学院生だった頃、彼の指導教官は、複雑なコードベースの管理を研究対象とする影響力のあるコンピューター科学者、バーバラ・リスコフでした。 彼女の考えでは、最高のコードは優れた記事のようなものだという。 すべての単語が役割を果たす、よく考えられた構造が必要です。 このようにプログラミングするには、読者に対する共感が必要です。 これは、コードを単なる目的達成の手段としてではなく、それ自体が芸術作品として見ることも意味します。 「彼の最大の強みはシステムの設計だと思う」とグーグルの最初の従業員、クレイグ・シルバースタイン氏は語った。 「Sanjay が書いたコード ファイルを見ると、その美しさは均整のとれた彫刻のようです。」 DEC では、ジェフは自分の研究室からサンジェイの研究室まで 2 ブロック歩いていました。 「真ん中にイタリアンジェラートショップがありました」とジェフは思い出した。 サンジェイは興奮して叫びました。「それで、それはあのアイスクリームショップのせいなんだ！」 彼らは一緒にプログラミングを始めました。自分のコンピューターで作業するのではなく、1 台のコンピューターを共有し、1 人がキーボードを操作し、もう 1 人が指導して修正するのです。 この種のコラボレーションはソフトウェア開発では一般的ではありません。 社会学者マイケル・P・ファレルは、2001 年の著書『コラボレーション サークル: 友情と創造的な仕事のダイナミクス』の中で、次のように指摘しています。 「新しい視点の基盤となる繊細な洞察のほとんどは、グループ全体が集まったときやメンバーが単独で作業しているときではなく、ペアで協力し、お互いに反応したときに生まれます。」 1869 年の夏、モネとルノワールが並んで作業し、後に印象派となるスタイルを生み出しました。 キュビズムを生み出した6年間の共同作業の間、ピカソとブラックは、どの絵が誰によって完成したかを隠すために、キャンバスの裏側にのみ署名することが多かった。 「なぜもっと多くの人がこれをやらないのか分からない」とサンジェイ氏はパートナーとのプログラミングについて語った。 「ペアプログラミングをするには、自分と考え方が合う人を見つける必要があります。そうすれば、2人でお互いを補い合うことができます」とジェフは言います。 1999 年半ば、ドットコム バブルはピークに近づきました。 ジェフは DEC を辞めて、「Google」という小さな会社に入社しました。 当時、Google の従業員は数十人しかおらず、オフィスはカリフォルニア州マウンテンビューの目立たない建物にありました。 10ヵ月後、サンジェイもそれに続きました。 彼らの伝説的なコラボレーションは、インターネットの歴史を変えようとしています。 ### 2000年3月: 災害と再生 2000 年 3 月のある日、Google の優秀なエンジニア 6 人が仮設の戦略会議場に集まりました。 同社は前例のない緊急事態に直面している。 昨年 10 月、同社のコアシステム (Web ページをクロールして「インデックス」を構築するシステム) が機能しなくなった。 ユーザーは https://t.co/cHDYnkjtpa で引き続きクエリを入力できますが、5 か月前の古いデータが表示されます。 さらに悪いことに、Googleの共同設立者であるラリー・ペイジとセルゲイ・ブリンは、Yahooに検索エンジンのサポートを提供する契約を交渉しており、当時の10倍の規模のインデックスを提供することを約束していた。 彼らが失敗した場合、https://t.co/cHDYnkjtpa は過去にとらわれたままとなり、Yahoo との取引は失敗に終わる可能性が高く、会社は資金不足と倒産のリスクに直面することになるだろう。 階段近くの会議室では、エンジニアたちが製材所にドアパネルを設置し、コンピューターを設置していました。 グーグルの最初の従業員、クレイグ・シルバースタインは、向こうの壁の近くに座っていた。 彼とルーマニア人のシステムエンジニアであるボグダン・ココセルは4日間と4晩作業したが、成果はなかった。 「私たちの分析はすべて無意味でした」とシルバースタイン氏は振り返る。「すべてが壊れていて、その理由もわかりませんでした。」 シルバースタインは左後方にサンジェイ・ゴマウォーターがいることにほとんど気づかなかった。 サンジェイはジェフ・ディーンとともに DEC から移り、数か月前にこの会社に加わったばかりでした。 作戦室では、ジェフは自分の椅子をサンジェイの机の隣にスライドさせ、空席を作った。 サンジェイがキーボードを操作している間、ジェフは彼の近くに寄り添い、ニュースキャスターの耳元でささやくプロデューサーのように、サンジェイを訂正したり導いたりしていた。 ジェフとサンジェイは停滞している指数をさらに詳しく調べ始めました。 彼らは、いくつかの単語が欠落していることを発見しました。「mailbox」を検索しても結果は得られず、他の単語は順序が間違っていました。 彼らは何日もコードの欠陥を探し、そのロジックに没頭していた。 各セクションをチェックした後、すべて問題ないように見えました。 彼らはそのバグを見つけることができませんでした。 オペレーションルームに着任して 5 日目、ジェフとサンジェイは、自分たちが探していた問題は論理的なものではなく物理的なものだと疑い始めました。 彼らは、乱雑なインデックス ファイルを最も原始的な表現である **バイナリ コード** に変換しました。 彼らは、自分たちのマシンが何を見ているのかを知りたかったのです。 サンジェイのモニターには、1 と 0 が密集した列が表示され、各行は索引用語を表しています。 サンジェイは、0 であるはずが 1 になっている数字を指さしました。 ジェフとサンジェイが順序が間違っていた単語をすべてまとめてみると、それぞれの単語に同じ小さな間違いがあるというパターンに気づきました。 何らかの理由で、マシン内のメモリ チップが破損していました。 サンジェイはジェフを見た。 Google では、ここ数か月間、ハードウェア障害の発生件数が増加しています。 問題は、Google が成長するにつれて、そのコンピューティング インフラストラクチャも拡大することです。 コンピュータのハードウェアは、数が多すぎる場合を除いて、めったに故障しません。数が多すぎる場合は、頻繁に故障することになります。 ワイヤーの摩耗、ハードドライブの故障、マザーボードの過熱。 多くのマシンは最初から動作しません。中には不可解な理由で動作が遅くなるマシンもあります。 奇妙な環境要因も影響し始めました。 超新星が爆発すると、衝撃波によってあらゆる方向に飛び散る高エネルギー粒子が発生します。科学者たちは、宇宙線と呼ばれるこれらの迷走粒子が地球上のコンピューターチップに当たり、0を1に反転させる可能性が非常に低いと考えています。 NASA や金融会社が使用するような世界で最も堅牢なコンピュータ システムでは、ビット反転を許容できる特殊なハードウェアが使用されています。 しかし、当時の Google はまだスタートアップ企業のような運営をしており、その機能のない安価なコンピューターを購入していた。 グーグルはカリフォルニア州サンタクララのビルで、1,500枚のむき出しのマザーボードとハードドライブをサンドイッチのように積み重ね、高さ6フィートのタワーを建てた。 ハードウェア障害のため、稼働しているのは 1,200 ユニットのみです。 会社は転換点を迎えた。 同社のコンピューティング クラスターは非常に大規模になったため、まれに発生するハードウェア障害も避けられなくなりました。 ジェフとサンジェイは、故障したマシンを補うために一緒にコードを書きました。 その後まもなく、新しいインデックスが完成し、運用室は解散されました。 ### 週末の書き直し: エラスティックシステムの誕生 この危機は転換点となった。 ジェフとサンジェイは、Google が成長するにつれて、ハードウェアの故障は偶発的なものではなくなり、当たり前のものになるだろうと認識しました。 数千台または数万台のサーバーがある場合、マシンのクラッシュ、ハードドライブの障害、ネットワークの停止が毎日発生します。 システムがこれらの障害に対処できない場合、Google は拡張できません。 まったく新しいインフラストラクチャを構築する必要があります: **混沌の中で秩序を維持できるシステム**。 今週末の書き直しの背後にある中心的な設計哲学は、**失敗を予期する** ことです。 ハードウェアが完璧であると想定するよりも、ハードウェアは故障すると想定する方がよいでしょう。 システムは、破損したデータを自動的に検出し、障害のあるマシンにフラグを立て、それらをバイパスして動作を継続できる必要があります。 この「フォールト トレランス」という考え方は現在では分散システムでは常識となっていますが、2000 年当時は革新的なものでした。 3月のインデックス暴落以前、Googleのシステムは創業者たちがスタンフォード大学の大学院生だったときに書いたコードに根ざしていた。 Page 氏と Brin 氏はプロのソフトウェア エンジニアではありません。 彼らは検索技術に関する実験を行っている学者です。 Web クローラーがクラッシュしたとき、何らかの情報を提供する診断メッセージは表示されず、「うわあ、お馬さん！」というフレーズだけが表示された。 初期の従業員は、Page と Brin によって書かれた BigFiles というソフトウェアを BugFiles (エラーだらけのファイル) と呼んでいました。 重要なインデックス コードの完成には数日かかり、問題が発生した場合には最初からやり直さなければなりません。 シリコンバレーの専門用語で言えば、当時の Google には「スケーラビリティ」が欠けていた。 ウェイン・ロージング氏は、2000年11月にグーグルに入社し、100人のエンジニアからなるチームの管理職に就く前は、アップルでマッキントッシュコンピュータの前身となる製品の開発に携わっていた。 「彼らはリーダーだ」と彼は言った。 ジェフとサンジェイは協力して Google のインフラストラクチャを再構築しました。 彼らは、ハードドライブ 1 台の障害によってシステム全体がクラッシュすることがないよう、週に 90 時間かけてコードを書いています。 クローリングのプロセス中にチェックポイントを追加し、途中で再開できるようにしました。 新しいエンコードおよび圧縮方式を開発することで、システム容量は実質的に 2 倍になりました。 彼らは冷酷な最適化者です。 車が曲がるときは、外側の車輪がより多くの地面を走行しなければなりません。 同様に、回転するハードドライブの外側の端は内側の端よりも速く動きます。 Google は、データ ビットが読み取り/書き込みヘッドの下でより速く流れるように、最も頻繁にアクセスされるデータを外側に移動しましたが、内部は半分空になっています。 Jeff と Sanjay はこのスペースを使用して、一般的な検索クエリの前処理済みデータを保存しました。 2001 年の 4 日間で、彼らは Google のインデックスを、比較的遅いハード ドライブの代わりに高速なランダム アクセス メモリ (RAM) を使用して保存できることを証明しました。 この発見により、同社の経済モデルは大きく変化した。 ペイジ氏とブリン氏は、ユーザーが即座に回答を提供できるサービスに集まるだろうとわかっていました。 問題は、速度を上げるには計算能力が必要であり、計算能力にはコストがかかることです。 ジェフとサンジェイはソフトウェアを使って巧みに問題を解決しました。 2005年にロシン氏が退社した後、アラン・ユースタス氏がエンジニアリング チームの責任者となった。 「スケーリング問題を解決するには、逆説的ですが、細部まで理解する必要があります」とユースタス氏は語った。 Jeff と Sanjay はコンピューターをビットレベルで理解しています。 彼らが主導した Google のコアソフトウェアの数回にわたる書き換えの間に、システムの容量は桁違いに拡大しました。 一方、同社の巨大なデータセンターでは、技術者がソフトウェアが生成した指示に従って曲がりくねった経路を歩き、ハードドライブ、電源、メモリ モジュールを交換しています。 たとえコンポーネントが摩耗して故障したとしても、システムは正常に動作し続けます。 ### MapReduce: 混沌をシンプルに 2004 年に、Dean と Gemmawater は「MapReduce: 大規模クラスターでの簡素化されたデータ処理」と題する論文を発表しました。 この論文の著者はたった 2 人ですが、業界全体に変化をもたらすでしょう。 MapReduce の中心的な考え方は非常にシンプルです。**複雑な分散コンピューティングを 2 つの関数 (`Map` と `Reduce`) に抽象化します。** `Map` 関数は入力データを処理し、中間のキーと値のペアを生成します。 `Reduce` 関数は、同じキーを持つ値を集約して最終結果を生成します。 プログラマーはこれら 2 つの関数を定義するだけで、システムは並列化、タスクのスケジュール設定、マシン間通信、障害回復を自動的に処理します。 この抽象化の強みはその**シンプルさ**にあります。 MapReduce が登場する前は、分散プログラムを作成するには深いシステム知識が必要でした。つまり、スレッドを手動で管理し、ネットワーク通信を処理し、マシンの障害に対処する必要がありました。 これらの複雑さが、ほとんどのプログラマーを遠ざけています。 しかし、MapReduce はこれらの複雑さをシステム内に隠すため、分散システムの経験がないエンジニアでもテラバイト単位のデータを簡単に処理できます。 論文中の一例としては、多数の文書における各単語の出現回数を数えることが挙げられます。 `Map` 関数はドキュメントを読み取り、`(word, 1)` のキーと値のペアを出力します。 `Reduce` 関数は同じ単語の数を合計します。 プログラム全体に必要なのはわずか数行のコードだけですが、何千台ものマシンで並行して実行され、インターネット全体の Web ページを処理できます。 MapReduce のもう一つの重要な貢献は、**フォールト トレランス** です。 システムはタスクの実行を継続的に監視し、あるマシンでタスクが失敗した場合は、別のマシンでタスクを自動的に再実行します。 この「再実行」戦略が機能するのは、`Map` 関数と `Reduce` 関数が「機能的」になるように設計されているためです。つまり、入力データを変更せず、出力を生成するだけです。 つまり、タスクを再実行しても副作用は発生せず、結果は確定的になります。 この設計は、「2000 年の危機」の教訓から直接ヒントを得たものです。ハードウェアに障害が発生しても、システムは継続して動作する必要があります。 MapReduce は Google 内で急速に人気を博しました。 検索インデックスの構築、ログ データの処理、レポートの生成、機械学習モデルのトレーニングに使用されます。 2004 年にこの論文が発表された時点では、すでに何百もの MapReduce プログラムが Google 内で実行されていました。 さらに重要なのは、MapReduce の背後にあるアイデアが業界全体に広まったことです。 Yahoo はこの論文に基づいて MapReduce のオープンソース実装である Hadoop を開発し、これがビッグデータ時代の礎となりました。 ### Bigtable: ストレージの芸術 MapReduce が大規模計算の問題を解決するなら、Bigtable は大規模ストレージの問題を解決します。 2006 年、Dean と Gemmawater は他の Google エンジニア数名とともに、「Bigtable: 構造化データ用の分散ストレージ システム」を出版しました。 Bigtable は、高スループットのバッチ処理と低レイテンシのリアルタイム クエリをサポートしながら、ペタバイト単位の構造化データを管理するように設計されています。 これは一見矛盾する要件を示しています。**バッチ処理では大量のデータをスキャンする必要があるのに対し、リアルタイム クエリでは単一の結果をすばやく返す必要があります。** 従来のリレーショナル データベースでは、これら両方の要件を同時に満たすことはできません。 Bigtable のソリューションは、ユニークなデータ モデルです。つまり、「スパースで分散された永続的な多次元ソート マップ」です。 各データ項目は、行キー、列キー、タイムスタンプの 3 つの次元でインデックス付けされます。 この設計は優れた柔軟性を提供します。 - **行キー**: データは行キーでソートされて保存され、隣接する行キーは同じマシンに保存されます。これにより、データ範囲のスキャンが非常に効率的になります。 - **列ファミリー**：列は列ファミリーに編成され、各列ファミリーには独自のアクセス制御と圧縮ポリシーを設定できます。これにより、システムはさまざまなアクセスパターンに基づいてストレージを最適化できます。 - **タイムスタンプ**: 各データ項目は複数のバージョンを持つことができ、タイムスタンプによって区別されます。システムは最新のNバージョン、または過去T日間のバージョンを自動的に保持します。古いバージョンはガベージコレクションされます。 Bigtable のもう一つの重要な設計上の特徴は、リレーショナル データベースではないことです。 複雑な SQL クエリや行間トランザクションはサポートされていません。 これらの制限は意図的なものであり、**複雑な一貫性プロトコルに妨げられることなく、システムを数千台のマシンに水平に拡張できるようにします。** Google では、Bigtable を使用して、Web ページのインデックス、Google Earth の地理データ、Google Analytics のユーザー行動データなどを保存します。 その影響は業界全体にも及んでいます。Amazon の DynamoDB、Facebook の Cassandra、Apache の HBase はすべて Bigtable からインスピレーションを受けています。 ### Spanner: グローバル一貫性の頂点 MapReduce と Bigtable は Google のインフラストラクチャの基盤を築きましたが、どちらも共通の制限を抱えています。それは、主に単一のデータセンターで使用するように設計されていたことです。 Google が世界規模で事業を拡大するにつれて、データを大陸を越えて分散させる必要が出てきます。 データの一貫性を世界規模で維持することが次の課題となっています。 2012 年、Dean 氏と Gemmawater 氏は他のエンジニアとともに、「Spanner: Google のグローバル分散データベース」を出版しました。 Spanner は、「外部的に一貫性のある分散トランザクション」をサポートする世界初のグローバル分散データベースです。 Spanner の核となるイノベーションは **TrueTime API** です。 分散システムでは、時間は扱いにくい問題です。 異なるマシンのクロックが同期していない可能性があり、ネットワーク遅延により 2 つのイベントの実際の順序を確信できなくなります。 Spanner のソリューションは、GPS と原子時計を活用して、*クロックの不確実性を明らかに*できる API を構築することです。 TrueTime は、「現在は 12:00:00 です」と表示するのではなく、「現在は 12:00:00 で、誤差は ±7 ミリ秒以内です」と表示します。 この不確実性を正確に把握することにより、Spanner はグローバル トランザクションに意味のあるコミット タイムスタンプを割り当てることができます。 不確実性が大きすぎる場合、システムは積極的に「不確実性がなくなるまで待機」します。これは「コミット待機」と呼ばれます。 この待機には通常、数ミリ秒しかかかりませんが、トランザクションの外部一貫性が保証されます。トランザクション T1 がトランザクション T2 の前にコミットされる場合、T1 のタイムスタンプは T2 のタイムスタンプよりも小さくなければなりません。 Spanner の創設により、Dean の「システム三部作」は完成しました。 MapReduce (フォールト トレラント コンピューティング) から Bigtable (フォールト トレラント ストレージ)、そして Spanner (グローバル一貫性) へ。 これら 3 つのシステムが組み合わさって、Google の技術的な防御壁を形成します。 彼らは、検索、広告、Gmail といった Google のコアビジネスを支えただけでなく、その後の人工知能の波のためのインフラストラクチャも提供しました。 2025 年、Spanner は「リレーショナル データ管理を再考し、グローバル規模で外部一貫性を備えたシリアル化を実現した」として ACM SIGMOD システム賞を受賞しました。 これは、ディーン氏とジェマウォーター氏が 10 年以上前に行った仕事に対する最新の評価です。 ### 規模のテール効果：システム哲学の頂点 2013 年、ディーン氏とジェマウォーター氏はもう一つの影響力のある論文「The Tail at Scale」を発表しました。 この論文では、大規模システムでよく発生しながらも見落とされがちな問題、「テール レイテンシ」について説明します。 Google のシステムでは、1 回のユーザー リクエストで数百のサーバーへのアクセスが必要になる場合があります。 各サーバーの平均応答時間が高速であっても、サーバーの 1% が低速であれば (たとえば、ガベージ コレクション、ディスク I/O、ネットワークの輻輳などにより)、ほとんどのユーザー リクエストの速度が低下します。 これは、ユーザー リクエストはすべてのサーバーからの応答を待つ必要があり、最も遅いサーバーによって全体的な待ち時間が決まるためです。 この論文の深い洞察は、遅延の原因をすべて排除しようとするのは「非現実的」であるという点である。 ハードウェアは故障し、ネットワークは混雑し、OSは激しく動揺する。完璧さを目指すよりも、「テールトレラント」なシステムを構築する方が良い。これは、2000年の金融危機後の彼の「フォールトトレラント」なシステム構築の哲学を反映した概念だ。 この論文では、テールレイテンシに対処するための一連の技術を提案しています。 - **ヘッジリクエスト**: 同じリクエストを複数のレプリカに送信し、最も速い応答を使用します。 - **バインディング リクエスト**: 複数のレプリカにリクエストを送信しますが、1 つのレプリカが処理を開始すると、他のレプリカへのリクエストはキャンセルされます。 - **マイクロパーティショニング**: データを小さなパーティションに分割し、マシン間でワークロードをより柔軟に移行できるようにします。 - **選択的レプリケーション**: 頻繁にアクセスされるデータのレプリカをさらに作成して、負荷を分散します。 これらのテクノロジーの根底にある考え方は、冗長性とインテリジェントなスケジューリングを通じて、信頼性が低く速度が不均一なハードウェア上で高性能で弾力性のあるサービスを構築することです。 2025 年、「The Tail at Scale」は「時の試練に耐えた」として ACM SIGOPS 殿堂賞を受賞しました。 この論文は Google のシステム設計に影響を与えただけでなく、業界全体でも古典的な文書となりました。 ### ディーンとジェマウォーター：伝説のコラボレーション ディーンの物語を語るとき、サンジェイ・ゴームウォルトとのコラボレーションについて触れないわけにはいきません。 彼らは MapReduce 論文の唯一の 2 人の著者であり、Bigtable と Spanner のコア設計者であり、「The Tail at Scale」の共著者でもあります。 2人はDECで協力関係を開始し、Googleで「2000年の危機」を共に乗り越え、その後20年間にわたりGoogleの技術基盤を協力して構築した。 2012年、彼らは「Googleの革新的なソフトウェアインフラストラクチャの構想、設計、実装」が評価され、ACMコンピューティング賞を共同で受賞しました。 2009年、二人は米国工学アカデミーの会員に選出された。 彼らの協力は「Google を救い、現代のインターネットを発明した友情」と評されている。 しかし、このパートナーシップは、「ジェフ・ディーン事実」という興味深い文化的現象も生み出しました。 ### 「ジェフ・ディーン・ミーム」：賞賛と後悔 2007 年のエイプリルフールの頃、Google 社内で「チャック・ノリス ジョーク」を模倣したジェフ・ディーンに関する一連のジョークが出回り始めました。 これらのジョークはディーンの技術的能力を誇張していました。たとえば、 - 「ジェフ・ディーンはバイナリ コードを直接書きました。ソース コードは他の人が読むためのドキュメントにすぎませんでした。」 - 「ジェフ・ディーンのキーボードには Ctrl キーがありません。彼は常にコントロールを握っているからです。」 - 「コンパイラは Jeff Dean に警告しません。Jeff Dean がコンパイラに警告します。」 「真空中の光の速度はかつては非常に遅かったが、ジェフ・ディーンは週末だけでその物理的特性を最適化した。」 これらのミームは Google 内で急速に広まり、その後テクノロジー業界全体に浸透しました。 これらは、エンジニアたちがディーン氏を尊敬していたことを反映しています。彼は優れた技術者であっただけでなく、どんな問題でも解決できる「コードの神」でもありました。 しかし、これらのミームは問題も抱えています。それは、「ジェフはサンジェイより優れている」という印象を与えてしまうことです。 実際、ディーン氏とジェマウォーター氏の貢献は同等であり、彼らの協力は補完的なものでした。 伝えられるところによると、このミームの作者は後に後悔の意を表し、「唯一の理由は『ジェフ』という名前の方が『面白そう』に思えたからだ」と考えているという。 この詳細は、一般の認識と真の歴史との間のギャップを明らかにしています。 ディーンの伝説はワンマンショーではなく、20年以上続いたコラボレーションです。
スレッドを読み込み中
X から元のツイートを取得し、読みやすいビューを準備しています。
通常は数秒で完了しますので、お待ちください。