要約

  • Greenberg の経歴は、通信事業者のトラフィック測定、ハイパースケールのデータセンターネットワーク、Uber のプラットフォームインフラを結んでいる。各段階でネットワークは、全体として測定・制御すべきシステムとして扱われてきた。
  • 4D アーキテクチャ、VL2、DCTCP、Ananta、SWAN、Pingmesh はそれぞれ異なる層を対象としたが、いずれも共同プロジェクトであり、本番環境への影響を一人だけに帰属させることはできない。
  • Uber の2026年のフェイルオーバー研究は、一部サービスを一律の 2x 予備容量から移行した後、対象システムで 99.97％の可用性を維持しながら利用率が向上したと報告した。
  • Greenberg の影響力を長期的に測る基準は、彼が形成に関わった制御ループが、説明可能性と説明責任を失わずに、新しいハードウェア、AI ワークロード、組織変更、障害に耐えられるかどうかである。

1.3x のフェイルオーバー目標がアーキテクチャを可視化する

Albert Greenberg の経歴を理解するうえで有用な入口は、役職や受賞歴ではなく、容量に関する判断である。Uber が発表した2026年の NSDI 論文は、一部サービスを一律の 2x 予備モデルから、1.3x 前後を基準とする差別化された計画へ移行したフェイルオーバー計画システムについて説明し、利用率の向上と、対象システムにおける 99.97％の可用性維持を報告した。この成果は多数の著者と Uber の本番アーキテクチャに属するもので、一人の幹部だけのものではない。それでも、Greenberg の仕事に数十年にわたり付きまとってきた問いを浮き彫りにする。信頼性を希望ではなく設計された特性にするには、プラットフォームにどれほどの予備容量、制御、測定が必要なのか。

この問いは比率が示す以上に難しい。予備容量は障害への備えになる一方、資本、電力、空間を消費する。予備を減らせるのは、サービスが正しく分類され、依存関係が理解され、フェイルオーバー経路が実際に独立し、トラフィックが想定どおり移動したかを組織が観測できる場合に限られる。したがって、容量目標は単なる財務上の最適化ではない。トポロジー、テレメトリー、制御ソフトウェア、運用規律に対して、プラットフォームがどれほど確信を持っているかを示す表明でもある。

Greenberg の現在の Uber での役割は、この問題に近い位置にある。ただし公開記録には、異論のない単一の役職名は示されていない。2026年の ARCS Foundation のプロフィールは Senior Vice President and Chief Architect Officer と記し、University of Minnesota のイベント略歴は Vice President of Platform Engineering と記している。いずれも制度的な信頼性を持つ情報源であるため、この相違を暗黙に解消せず、明示したままにすべきである。両者の一致点の方が、このプロフィールには有用だ。Greenberg はインフラ全体に関わる上級プラットフォーム・アーキテクチャ幹部であり、単一の孤立したプロトコルだけを研究する立場ではない。

同じシステム全体を見る視点は、経歴のかなり早い段階にも現れている。AT&T と Bell Labs では、単一インターフェースのカウンターから重要な状態を読み取れない通信事業者ネットワーク全体で、需要と異常をどう測定するかが課題だった。Microsoft では、データセンターファブリック、トランスポートプロトコル、ロードバランサー、広域ネットワーク、テレメトリーシステムを、一つのクラウドプラットフォームの構成要素として機能させることが課題になった。Uber では、世界規模のプラットフォームサービス、AI インフラ、差別化されたレジリエンスへと運用環境が再び変化した。技術は変わったが、繰り返される規律は変わらない。全体を観測し、制御判断を明示し、安全に適用し、現実がモデルどおりになったかを測定することである。

通信事業者ネットワークは、制御の前に測定することを Greenberg に教えた

Greenberg は Dartmouth College で数学を学んだ後、1983年に University of Washington でコンピューターサイエンスの博士号を取得し、初期の経歴の多くを AT&T と Bell Labs のネットワーク研究で築いた。この歴史で重要なのは役職の順序ではない。彼が直面したシステムの性質である。それは顧客、プロトコル、障害、トラフィックパターンを抱える稼働中の通信事業者バックボーンであり、研究者がネットワークの状態を調べている間も停止できなかった。

バックボーン計画には、トラフィックマトリクス、障害の証拠、多数のルーターにまたがる需要の把握が必要になる。リンクカウンターは一点の負荷を、ルーティングテーブルは選択された経路を、フロー記録は別の部分的な視点を示すが、どれ一つとして、入口と出口の間をどれほどのトラフィックが移動しているか、ルーティング変更がその流れをどう変えるかを単独では説明できない。AT&T のチームは、バックボーンをより実証的な工学対象にする測定・トラフィックエンジニアリング手法を開発した。公開記録にはすべての本番システムやデータセットが示されていないため、擁護できる主張は、独自ツールの完全な一覧ではなく、その工学的アプローチに関するものである。

トラフィックマトリクスが有用なのは、散在する大量の証拠を、容量計画担当者が行動に移せるモデルへ変換するからである。ネットワークの二つの部分の間でトラフィックが増えれば、事業者は既存経路で十分か、障害時にボトルネックが生じるか、ルーティング方針が需要を誤ったリンクへ押し出していないかを検討できる。ただし推定は不完全なままである。サンプリング、集約、ルーティング変更、暗号化されたアプリケーションはいずれも解釈をゆがめ得る。そのため測定は絶対的な真実を示すものとしてではなく、履歴や運用状況と組み合わせて扱う必要がある。

この限界は、Greenberg の後の仕事で測定が単なる報告層以上のものになった理由を説明する。制御システムが経路を最適化するには、信頼できるトポロジーと需要のモデルが必要である。ロードバランサーがリクエストを分散するには、どのバックエンドと経路が正常かを把握しなければならない。フェイルオーバー計画で予備容量を減らすには、拠点、リンク、サービスが消失したときに何が起きるかを、訓練とテレメトリーが示す必要がある。繰り返されるループは表現するのは簡単だが、運用は難しい。観測し、判断し、適用し、測定し、修正する。

年代が明らかな記録は、この進展を英雄的な起源物語に変えることなく裏付けている。Greenberg は1983年に博士号を取得し、Clean Slate 4D Approach to Network Control and Management は2005年、VL2 は2009年、データセンター TCP は2010年、Ananta と SWAN は2013年、Pingmesh は2015年に発表された。AT&T と Bell Labs での仕事は1980年代から2000年代初頭まで、Microsoft と Azure は2000年代後半からその後の10年間における主要な組織的環境となり、2020年代には Uber が現在の文脈となった。各段階で新たな共同研究者と本番環境の制約が加わったため、継続性があるのはシステム上の問題であり、一人が完成済みの設計図を勤務先から勤務先へ運んだという主張ではない。

4D アーキテクチャは推論と転送を分離した

2000年代半ばに共同研究者と開発・発表した 4D アーキテクチャは、ルーター中心の管理に見られた一般的な特徴に異議を唱えた。各装置がローカル設定、分散プロトコル、転送動作を組み合わせていたため、ネットワーク全体の方針や障害を推論することが難しかった。提案は制御を、decision、dissemination、discovery、data の四つのプレーンに分けた。discovery はトポロジーと状態の情報を収集し、decision プレーンはネットワーク全体の制御を計算し、dissemination はその結果となる状態を適用し、data プレーンはパケットを転送する。

重要だったのは分離そのものである。方針に関する推論を独立した論理機能として扱うことで、転送を物理的に集中させることなく、ネットワーク全体を見渡すコントローラーを検討できるようになった。方針をより広いモデルと照合し、得られた状態を管理された仕組みで配布できる。このアーキテクチャは、後にソフトウェア定義ネットワークと関連付けられる考え方を先取りしたが、SDN の唯一の起源と表現すべきではない。この分野には複数の思想的系譜があり、提示された証拠が裏付けるのは、4D が影響力のある先駆的成果かつ貢献の一つだったということであり、単独の発明だったということではない。

制御の分離はリスクの位置も変える。decision サービスは障害を起こしたり、古い discovery データに基づいて動作したりする可能性がある。dissemination は変更の一部しか適用できない場合がある。論理的に集中した方針エンジンは、緩やかに連携するルーター群より速く、誤った判断を広げる可能性がある。移行中は従来のプロトコルや装置とも共存しなければならない。このため、アーキテクチャは複雑性を取り除いたのではなく、その一部を明示し、責任の一部をソフトウェアと運用プロセスへ集中させた。

このトレードオフは、その後のクラウドシステムで中心的な問題になった。問いはもはや、ネットワーク全体の推論を転送から分離できるかではなく、その推論を利用可能で、複製され、観測可能で、分散データ経路と互換性のあるものにするにはどうすべきかへ移った。段階的展開、ロールバック、健全性確認、ローカル転送動作が重要なのは、コントローラーの視野が広いほど影響範囲も広くなるからである。Greenberg の後の Microsoft での仕事は、万能な一つの制御プレーンではなく、具体的なシステムを通じてこれらの問いに取り組んだ。

VL2 はサービス配置をネットワーク設計の問題に変えた

Greenberg が Microsoft のデータセンターネットワーク研究へ移ると、規模と障害モデルが変わった。大規模オンラインサービスは、サーバーの場所ごとにネットワークを再設計せずにワークロードを配置・移動することを求めていたが、従来の階層型ネットワークは帯域幅を制約し、アドレスを物理トポロジーへ過度に結び付ける可能性があった。Microsoft の多数の著者によって開発された VL2 は、folded-Clos ファブリック、アドレスの間接化、Valiant ロードバランシングを組み合わせ、予測しにくいサービス配置とトラフィックパターンに対応した。

この発想で有用だったのはサービス目標である。ワークロードは安定したサービス識別情報を維持し、その下では物理ファブリックが拡張可能なレイヤー3構造を使えるようにすべきだった。データセンター内に複数の経路を作るマルチパス Clos トポロジーの下で、ディレクトリと制御の仕組みがサービスアドレスを場所へ対応付ける。これによりネットワークは固定された通路の集合から、サービスの移動に応じて容量をより柔軟に利用できるファブリックへ変わる。

Valiant ロードバランシングは直感に反する仕組みを加える。すべてのトラフィックマトリクスについて最適な端末間経路を予測しようとする代わりに、無作為に選んだ中間地点を通じてトラフィックを分散し、未知の一つの需要パターンが同じリンクを支配しないようにする。個々のフローは一見遠回りな経路を取る場合があるが、ネットワーク全体では多様な負荷の下で予測可能性が高まる可能性がある。ただし、経路長の増加、ハッシュの偏り、巨大フロー、障害などの限界があり、個別の結果に影響し得る。

VL2 の影響は、固定された本番設計図ではなく、設計上の系譜として説明すべきである。Azure が研究論文を変更せずそのまま導入し、進化を止めたわけではない。ハードウェア世代、仮想ネットワーク、ホストソフトウェア、制御システム、運用要件は変化を続けた。擁護できる主張は、VL2 がハイパースケールネットワークの中心となった語彙、すなわち Clos ファブリック、アドレスと場所の分離、マルチパス利用、ソフトウェア支援制御の確立に貢献したということである。

アーキテクチャからは経済性も生じる。汎用またはモジュール式スイッチで構築する均一なファブリックは、少数の大型シャーシに依存する設計より段階的に拡張しやすい場合がある。しかし個別機器への依存を減らしてもコストは消えない。支出と技能の重点が、制御ソフトウェア、テレメトリー、自動化、障害管理へ移る。クラウド事業者がある層で節約するには、その代わりとなる分散システムの運用能力を高めなければならない。

DCTCP は輻輳をスイッチとホストの共有問題にした

データセンターのトラフィックには、短く遅延に敏感なフローと大規模転送が混在する。従来の TCP は送信ウィンドウを縮小する前に深いキューを形成することがあり、リンク利用率が高く見えても、短いジョブが蓄積したパケットの後ろで待たされる可能性がある。やはり複数著者によるシステムである DCTCP は、浅いスイッチキューで Explicit Congestion Notification を使い、マークされたパケットの割合に応じて送信側を調整した。目的はスループットを犠牲にせず、キューを低く保つことだった。

重要な結果は、輻輳制御がネットワーク装置とエンドポイントの協調ループになることである。スイッチには導入環境に適したマーキングしきい値が必要であり、ホストには互換性のある輻輳制御動作が必要になる。トラフィック構成、トポロジー、ハードウェアはいずれも結果に影響する。しきい値の選択を誤った場合や混在導入では公平性や遅延が変わる可能性があるため、DCTCP は一台のサーバーだけで独立して有効にできる単純なアルゴリズムではない。

この研究は、データセンターの輻輳を独立した運用課題として定着させることに貢献した。開かれたインターネットには長い経路、多様な事業者、共通管理がほとんどないエンドポイントがある一方、クラウド事業者はサーバーとスイッチの双方を管理できる場合が多い。その管理範囲は、世界規模では調整が難しい仕組みを可能にする。同時に、エンドポイントのバージョン、スイッチ設定、テレメトリーを一体で進化させなければ制御ループがずれるという、プラットフォーム上の責任も生む。

この境界が重要なのは、後続システムが同じ目的を競い合い、または拡張するからである。新たな輻輳制御アルゴリズム、高速ファブリック、異なるバッファ設計が登場しても、キューがどこで発生し、エンドポイントがどう認識し、どのチームが設定を所有するのかという問いは消えない。Greenberg の貢献は、こうした層をまたぐ依存関係こそが実際の問題だと繰り返し捉えた研究・工学上の成果群に属する。

Ananta、SWAN、Pingmesh はループの異なる部分を閉じた

トポロジーとトランスポートは、クラウドネットワーク問題の一部にすぎない。サービスには拡張可能な入口が必要であり、データセンター間では広域容量を共有しなければならず、運用者にはネットワーク障害とアプリケーション症状を区別するだけの証拠が必要だった。Microsoft のチームは、Ananta、SWAN、Pingmesh などを通じてこれらの問題に取り組んだ。それぞれ著者と導入範囲は異なる。

Ananta はクラウド規模のレイヤー4ロードバランシングに取り組んだ。パケット処理を一台の装置に集中させる代わりに、多数のマシンへパケット処理、経路管理、サービス制御を分散した。このアーキテクチャはデータ経路を水平に拡張できる一方、分散によって状態、整合性、バックエンドの健全性、障害処理に関する新たな要件が生じた。ロードバランサーはネットワーク端部の箱ではなく、インフラサービスになる。

SWAN は論理的に集中した最適化を広域ネットワークへ適用した。データセンター間リンクは高価で、需要は変動し、障害によって容量が突然失われることがある。広い視野を持つコントローラーは、サービス優先度とネットワーク状態に応じて経路を割り当て、輻輳からトラフィックを移し、希少な長距離リンクをより計画的に利用できる。同じ集中視点は、需要推定が誤っている場合、更新が安全でない場合、コントローラーがネットワークの一部へ到達できない場合にリスクを生む。

Pingmesh は別の問題、すなわち可視性に取り組んだ。エージェントが大規模な機器群全体で遅延とパケット損失の測定を生成・収集し、合成された証拠の継続的なメッシュを作った。リンクが管理上は稼働中でも、経路の性能が悪いことがある。どの単独チームも所有しないネットワーク区間が原因でサービスが失敗する場合もある。全体規模の測定は、合成プローブがすべてのアプリケーション経路、キュー、依存関係を再現できないという限界を持ちながらも、障害対応に共通基準を与える。

この三つを合わせて見ると、Greenberg の実績を著名なトポロジー論文一つに還元できない理由が分かる。Ananta はサービスのトラフィックを資源へ対応付け、SWAN は広域容量を割り当て、Pingmesh は経路が想定どおり動作したかを測定する。DCTCP はファブリック内のキューフィードバックを管理し、VL2 はファブリック自体の設計を提供する。信頼性はこれらの仕組みの相互作用から生じる。それゆえ、成果の帰属もチーム単位で維持しなければならない。

Azure ネットワークは、それらの仕組みを取り巻くオペレーティングシステムになった

Greenberg が Azure Networking の上級職を務める頃には、中心課題は一つの論文が定義された実験で機能するかどうかではなくなっていた。Azure は物理ファブリック、仮想ネットワーク、ロードバランサー、ゲートウェイ、広域リンク、テレメトリー、展開システムを一つのクラウドサービスとして運用しなければならなかった。顧客は、その下にあるハードウェアや制御プロセスを理解しなくても、分離、プログラム可能性、可用性を期待した。

仮想ネットワークはこの抽象化を具体化する。顧客が見るのはアドレス、経路、セキュリティ規則、サービスエンドポイントであり、クラウドはその意図を、他のテナントと共有するホスト、スイッチ、ゲートウェイへ対応付ける。制御プレーンは、一顧客の設定が他の顧客へ影響しないようにしながら、急速な変更を処理しなければならない。データプレーンは高速転送を継続する必要がある一方、API、監査ログ、ロールバック機構、地域間の整合性によって、ネットワークはパケット転送と同じ程度にソフトウェアライフサイクルの問題になる。

そのライフサイクルはアーキテクチャの意味を変える。機能リリースは多数の顧客のルーティングやセキュリティ動作を変える可能性がある。制御プレーン障害では、既存フローが継続する一方、新しい設定ができなくなる場合がある。テレメトリーの欠落により、利用者が障害を経験していてもインフラが正常に見えることがある。容量計画では通常の成長と地域フェイルオーバーの両方に備える必要がある。したがって、顧客が隠れたシステムの大半を検査・修復できない以上、工学組織そのものがサービス契約の一部になる。

Greenberg の2015年の SIGCOMM 基調講演期が重要なのは、クラウドネットワークを、決定的な一つのファブリックを探す試みではなく、相互依存するシステム群として位置付けたからである。トポロジー、トランスポート、仮想化、ロードバランシング、広域トラフィックエンジニアリング、監視、運用は、基盤が変化する間も整合性を保たなければならない。この枠組みは個別の実装詳細より長く有効であり、複数チームにまたがる Greenberg の仕事の記録とも一致する。

Microsoft での正式な権限はリーダーシップに関する主張を支えるが、技術の単独所有を意味しない。公開記録は、彼を Azure Networking の Corporate Vice President および Technical Fellow と記している。過去の AT&T 資料にも executive director や AT&T Fellow などの上級職が記されているが、正確な役職は時期によって異なる。これらの組織に関連する主要システムには、多数の共同著者と本番担当技術者がいる。したがって最も確実な帰属方法はプロジェクトごとに、共同執筆された成果を示し、勤務先を本番運用組織として特定し、個人への主張を文書化されたアーキテクチャ上の指導と著者としての貢献に限定することである。

リーダーシップは単独発明ではなく、チームを通じて働く

Greenberg の経歴は、システム史を英雄物語へ変えやすい略記を引き寄せる。より慎重な記録の方が興味深い。VL2、DCTCP、Ananta、SWAN、Pingmesh、Uber のフェイルオーバー研究はいずれもチームによって構築された。4D アーキテクチャも複数の貢献者を含む研究コミュニティから生まれた。Azure ネットワークは長年の製品・運用作業によって進化し、その全体を一つの論文や幹部略歴で捉えることはできない。

一方、公開証拠は、これらのチームをまたぐ異例の継続性を示している。Greenberg は通信事業者の測定から白紙状態の制御アーキテクチャへ、ハイパースケールのデータセンターネットワークからクラウドプラットフォームの指導へ、さらに Uber のプラットフォーム組織へ移った。したがって彼の影響は技術的であると同時に組織的でもある。ネットワーク全体の状態をどう測定し、制御をどう分離し、トラフィックをどう割り当て、チームが障害をどう推論すべきかを問う仕事に、彼は繰り返し登場する。

同業者からの評価はその幅を反映するが、受賞歴をプロジェクトの証拠の代わりにしてはならない。Greenberg は2015年に ACM SIGCOMM Award と IEEE Koji Kobayashi Computers and Communications Award を受賞し、2016年に US National Academy of Engineering の会員に選出され、ACM Fellow にもなっている。これらの栄誉は、分野が彼の仕事を重要と評価しているとの結論を支える。ただし、単独発明、現在の運用権限、特定システムの正確な本番系譜を証明するものではない。

Uber での役職の相違は、同じ規律を思い出させる有用な例である。2026年の ARCS Foundation のプロフィールは Senior Vice President and Chief Architect Officer とし、2025～2026年期の University of Minnesota のイベント資料は Vice President of Platform Engineering と記す。一方を選んで記録を不自然に整えるのではなく、情報源の日付を示し、共通点を説明すべきである。Greenberg は上級プラットフォーム・アーキテクチャ職にあるが、その内部的な意思決定権限は完全には公開されていない。現在の正確な人事上の役職は確認事項であり、責任に関するより大きな証拠を弱める理由ではない。

これは、アーキテクチャが一部には権限の配分だからこそ重要である。chief architect やプラットフォーム幹部は、共通原則を設定し、レビューを要求し、共有機構を承認し、容量方針へ影響を与えられるかもしれない。しかし、すべてのスイッチを個人的に設定し、すべての制御サービスを書くわけではない。ネットワークチーム、サービスチーム、セキュリティ技術者、容量計画担当者、財務部門、幹部は、それぞれ異なる意思決定権を持つ。アーキテクチャ上のリーダーシップの価値は、それらが一人へ集約されるかのように装うことではなく、共通の障害モデルと両立させることにある。

Uber は同じ規律を異なる需要パターンへ適用する

Uber のインフラは、地域と時間によってトラフィックや計算需要が大きく変化するモビリティ、配送、その他のサービスを支える。公式略歴は Greenberg の責任を、データセンター、計算資源、ネットワーク、ストレージ、データ、検索、監視、開発者の生産性、社内 IT、AI と自動運転車を支えるインフラに結び付けている。この幅広さはプラットフォーム上の文脈を示すが、彼がすべての記載システムや、その上で動くアプリケーションモデルを個人的に設計したことを示すものではない。

Uber は自社のアプリケーション群を管理しながら、世界規模のリアルタイムサービスと大規模な社内データシステムを支えるため、その運用課題はパブリッククラウドとは異なる。ネットワーク、ストレージ、計算資源に関する判断は、サービスの信頼性、機械学習ワークロード、地域運用と相互作用する。したがってプラットフォームアーキテクチャは、どのインフラを共有し、どの障害領域を本当に独立と扱えるか、各アプリケーションチームが同じ仕組みを再構築せず共通サービスを利用するにはどうすべきかを判断しなければならない。

2026年のフェイルオーバー研究は、この問題を測定可能な例に変えた。一部サービスを一律の 2x 容量から、1.3x 前後の差別化された計画へ移すことでインフラを解放できるのは、その変更を支えるモデルが正確な場合に限られる。報告された 99.97％の可用性は、指定された Uber のシステムと期間に属するものであり、Uber の全サービスや他社へ一般化すべきではない。この結果が有用なのは、管理されている交換条件を示すからである。予備容量を減らせば利用率を改善できるが、そのためには分類、依存関係の把握、テレメトリー、訓練の質を高めなければならない。

これは技術的な制御ループであると同時に、経済的な制御ループでもある。予備のマシン、ネットワーク経路、電力、データセンター容量には、いずれも機会費用がある。障害要件に応じてサービスを区別できるプラットフォームは、すべてのワークロードを同一に扱う場合より、待機容量を少なくできる可能性がある。利益が実在するのは、障害によって、独立しているはずのゾーンやサービス間の隠れた結合が露呈しない場合だけである。このため、試験と障害後の学習も財務上の根拠の一部になる。

現在の AI と自動運転車のワークロードは、これらの判断をさらに厳しくする。学習と推論は大規模な東西方向トラフィックを生み、アクセラレーターの配置を制約し、末尾遅延の重要性を高める可能性がある。車両とモビリティのデータは、ストレージ、転送、地域処理への需要を加える。提示された略歴によってこれらの分野は Greenberg のプラットフォーム職に関連付けられるが、彼が AI モデルや自動運転ソフトウェアを設計しているとの主張は裏付けられない。インフラに関する主張はより限定的である。プラットフォームは、それらのアプリケーションが依存するデータを移動し、保護し、復旧できなければならない。

信頼性は形容詞ではなく配分に関する判断である

クラウドやプラットフォーム組織は、システムをレジリエント、高可用、耐障害性があると日常的に表現する。こうしたラベルは、容量、地域、ソフトウェアの複雑性、人員の注意力の配分を覆い隠す。ネットワークファブリックには一定の経路多様性があり、WAN には一定の予備容量があり、ロードバランサーには固有の状態と障害モデルがあり、テレメトリーシステムは一部の経路を観測し、他は観測しない。信頼性はこれらの選択の結果であり、設計文書で使う形容詞によって付与される性質ではない。

集中型または論理的に集中した制御は、広い視野から推論できるため、こうした配分を改善できる。SWAN は独立したローカル判断より計画的に広域容量を調整でき、仮想ネットワークコントローラーは多数のホストへ一貫した方針を適用できる。トレードオフは集中である。誤った方針、破損した状態、不具合のある展開は、より広い範囲へ急速に影響し得る。そのため集中化の妥当性は、複製、段階的導入、ロールバック、制御中断時にもローカル転送を継続できる能力に依存する。

同じ原則は容量にも当てはまる。一律の 2x 予備は説明しやすいが、高価になり得る。差別化された予備は利用率を改善できるが、サービス分類と障害モデルの正確性への依存を高める。どちらの設定も本質的に慎重とは限らない。適切な値は、何が同時に障害を起こすか、トラフィックをどれほど速く移動できるか、どのサービスが性能低下を許容できるか、組織がどれだけの不確実性へ資金を投じる意思があるかによって決まる。

このためアーキテクチャレビューは、技術だけでなく権力の配分にもなる。サービスチームは遅延と可用性の要件を示す。ネットワーク・プラットフォームチームは共有機構を選ぶ。容量計画担当者と財務部門は、どれだけの予備に資金を出すかを決める。セキュリティチームは分離要件を定義し、幹部はリスク許容度を設定する。アーキテクトは共通言語を作り、各設計が一貫したモデルに適合するよう求められるが、本番システムを形作る個別の動機と責任を消すことはできない。

Greenberg の一連の仕事は、こうしたレビューに有用な基準を示す。設計は需要、判断、転送、証拠の間のループを閉じているか。VL2 は配置とトポロジー、DCTCP はキューフィードバック、Ananta と SWAN はトラフィック配分、Pingmesh は継続的な観測を扱った。Azure と Uber はこれらの仕組みを組織的システムへ変えた。ネットワークが分散コンピューターのように振る舞うのは、こうしたループが変化の中でも整合性を保つ場合に限られる。

成果群は最も有名なラベルより広い

Greenberg はデータセンターネットワークとの関連が最も強く語られることが多いが、その記録には、一つのカテゴリーへまとめるべきでない複数の仕事が含まれる。通信事業者のトラフィック測定は需要と異常を運用者に見えるようにした。4D アーキテクチャは制御機能を概念的に分離した。VL2 はファブリックトポロジーとサービス配置を扱い、DCTCP はエンドポイントとスイッチのフィードバックでキューを制御した。Ananta はサービス入口、SWAN は広域配分、Pingmesh は大規模な可観測性を扱った。Azure の仮想ネットワークは、その後これらの考え方のいくつかを顧客向けクラウドプラットフォームへ組み込んだ。

各層では利用者と証拠が異なる。通信事業者の測定は主としてネットワーク運用者と計画担当者に利益を与えるが、本番環境の詳細の多くは非公開のままである。4D アーキテクチャは研究設計であり、その影響は一つの普遍的な導入を証明するものではなく、概念的なものである。VL2 と DCTCP には公開された仕組みと評価がある一方、その後の本番システムは Microsoft 内部で進化した。Ananta、SWAN、Pingmesh は、それぞれ独自のチーム、依存関係、限界を持つプラットフォームサービスを説明している。

共通項は一つの製品ではない。異なる判断を明示する一連の仕組みである。トラフィック測定は需要を推定し、制御アーキテクチャは方針に関する推論をどこに置くかを決め、ファブリックは経路を提供する。輻輳制御はエンドポイントによる経路利用を調整し、ロードバランシングはサービスのトラフィックを資源へ対応付け、WAN エンジニアリングは希少な拠点間容量を配分する。テレメトリーは結果が想定と一致したかを報告し、幹部のアーキテクチャ職は、これらのループを維持する組織を調整する。

この区別は、Greenberg の仕事を隣接するシステムと比較する際に有用である。VL2 は Clos ファブリック、PortLand、SEATTLE、Google の Jupiter、その他のデータセンターアーキテクチャの系譜に位置する。DCTCP は輻輳制御研究、SWAN は広域トラフィックエンジニアリング、Pingmesh は可観測性の領域に属する。ソフトウェア定義ネットワークと OpenFlow は、プログラム可能な制御に関する並行した系譜を形成する。商用ロードバランサーやネットワーク可観測性製品は、異なる製品・運用モデルを通じて関連問題を解決できる。

比較の目的は個人を順位付けしたり、一つのアーキテクチャを勝者と宣言したりすることではない。Jupiter や B4 などの Google のシステム、Meta のデータセンターファブリック、商用 Clos・leaf-spine 製品、OpenFlow 時代の SDN 研究、装置型または管理型ロードバランサー、可観測性事業者は、異なる組織境界の下で重なり合う制御問題を解いている。製品へ責任を集中させることで一つの運用課題を簡素化できる装置もあれば、ホスト、スイッチ、ソフトウェアを管理することでより多くの層を統合できるクラウドプラットフォームもある。研究アーキテクチャは有用な抽象概念を示せるが、それを運用する組織を容易に構築できることまでは証明しない。

これらのシステムは研究組織、事業者、運用者を結ぶ

Greenberg の仕事は、一つの連続した組織ではなく、複数機関のネットワーク内に位置する。AT&T Labs は、トラフィック測定とネットワーク管理が中心課題になった通信事業者研究環境を提供した。Microsoft Research と Azure は、データセンター研究をハイパースケールの本番環境へ結び付けた。Uber は現在のプラットフォーム上の文脈を提供する。Dartmouth College と University of Washington は学術的形成に属し、ACM SIGCOMM、IEEE、National Academy of Engineering は、成果を評価した専門的記録の一部を構成する。

これらの関係はそれぞれ意味が異なる。雇用は組織的な文脈を示すが、インフラの個人所有を意味しない。共著は研究成果への参加を示すが、本番実装の単独管理を意味しない。受賞は同業者の評価を示すが、システムの現在の状態を示すものではない。会議講演やアーキテクチャコミュニティは影響や交流を示せるが、商業関係を証明するものではない。

ハイパースケールインフラでは、多くの本番詳細が非公開であるため、この区別が特に重要になる。公開論文は仕組み、前提、選択された測定結果を示すが、クラウド事業者は発表後にハードウェア、制御ソフトウェア、運用方法を変更する可能性がある。したがって論文は、ある時点でチームが構築・評価したものを示せても、現在の Azure や Uber のネットワークを完全に説明する資料にはならない。

同じ注意は現在の役職説明にも当てはまる。上級職は正式な権限を示すが、内部の意思決定権限が公開されることはまれである。アーキテクチャコミュニティ、設計レビュー、プラットフォーム組織は、どのインターフェース、障害モデル、展開プロセスを共通慣行にするかを決めることで、大きな非公式権限を生み得る。証拠は Greenberg がこうした仕組みの中でリーダーだったことを裏付けるが、彼が利用できるすべての拒否権、報告系統、予算判断を示すものではない。

そのため、最も確実なプロフィールでは共同研究者を見える状態に保つ。VL2、DCTCP、Ananta、SWAN、Pingmesh、Uber のフェイルオーバー研究の共同著者は技術的な物語の一部であり、勤務先は本番運用の物語の一部である。Greenberg 個人の重要性は、これらの文脈をまたいでアーキテクチャ上の問いが継続していることであり、それに答えたチームを消すことではない。

資金と地理が主張できる範囲を定める

Greenberg の仕事は主に、彼を雇用した企業の研究・工学組織を通じて資金提供されてきた。提示された資料は、個人的な収益モデル、株式価値の推定、純資産額、監査済みの製品単位の財務貢献を裏付けない。上級職や影響力のあるシステムを根拠に、報酬を推定したり、Azure や Uber の収益を一人のアーキテクトへ帰属させたりすることはできない。

本番システムに関する論文は効率性や可用性の指標を報告でき、Uber のフェイルオーバー研究はその一例である。これらの数値は、固有のアーキテクチャと期間に関する前提を伴い、指定されたシステムと著者チームに属する。財務開示がない限り、全社的な削減額へ変換したり、Greenberg 個人の実績に関する主張へ転用したりすべきではない。学術引用や受賞も、収益ではなく評価を測る。

地理的には、Greenberg の教育と主要な勤務先は米国にある一方、関連するインフラは世界規模である。AT&T のバックボーン研究、Azure の地域、Uber のサービス提供範囲は、それぞれ異なる容量、規制、障害上の制約に直面する。設計原則がそれらをまたいで機能しても、すべての地域が同一のハードウェア、トポロジー、予備方針を使っていることにはならない。

現在の AI とモビリティの文脈では、この世界的な広がりが重要になる。学習、推論、ストレージ、車両群のデータは、アーキテクチャの指導拠点が一国にあっても、地域をまたぐデータセンター、ネットワーク、供給網に依存する。公開記録にはすべてのトポロジーや供給者関係が示されていないため、このプロフィールはより確実な主張にとどめるべきである。Greenberg の仕事は、研究が最初に発表された組織をはるかに越えて運用上の影響が広がるインフラに関わっている。

反対論は、統合された制御が障害も統合し得るということだ

このアーキテクチャに対する最も強い反論は、その魅力の内部にある。ネットワーク全体の視点は、孤立した装置の集合より方針、容量、復旧をうまく調整できるが、一つのソフトウェアエラーへはるかに大きな影響範囲を与える可能性もある。4D の提案はこれを概念的に可視化し、その後のクラウドシステムは本番環境で向き合う必要があった。制御が分離され論理的に集中すると、コントローラー、その入力、展開機構が重要インフラになる。

観測は不完全であるため、テレメトリーもこの問題を取り除かない。Pingmesh は遅延と損失の強力な基準を作れるが、合成プローブはすべてのアプリケーション経路やキューを再現しない。トラフィックマトリクスは需要を推定するが、サンプリングや経路変更によってゆがむ可能性がある。ネットワーク、ホスト、サービス信号の相関は障害範囲を狭められても、根本原因を確定できるとは限らない。テレメトリーを過信するシステムは、人間のチームより速く誤った説明を自動化する可能性がある。

容量最適化にも同じ非対称性がある。Uber のフェイルオーバー研究が示唆するように、より良いモデルは無駄を減らせるが、予備を減らす価値は独立性と復旧に関する前提に依存する。二つのゾーンが隠れた依存関係を共有している場合、別々だと扱うモデルは実際の障害に必要な容量を過小評価する可能性がある。予備資源を積極的に最適化するほど、その節約が依存するシナリオを試験する重要性が高まる。

研究から本番環境への隔たりも誤りの原因になる。公開されたアーキテクチャは、既知の著者一覧、ワークロード、評価方法を持つ一時点の記録である。本番システムには、ハードウェア改訂、ソフトウェア移行、互換層、緊急例外、公開されない組織慣行が蓄積する。VL2 を現在の Azure アーキテクチャとみなしたり、2026年の Uber の研究を全サービスに永久適用される方針とみなしたりすれば、一システムの証拠を、その証拠では支えられない主張へ変えてしまう。

人物プロフィールにおける同種のリスクは、過度の個人化である。Greenberg の記録は異例に広いため、ソフトウェア定義制御から現代の AI インフラまでの全経緯を彼へ帰属させたくなる。証拠はそれを裏付けない。彼は主要システムを単独で執筆しておらず、AT&T、Microsoft、Uber のインフラを個人的に所有していない。また、プラットフォームの略歴にそうしたワークロードが記載されているだけで、アプリケーションモデルや自動運転ソフトウェアの設計者とみなすこともできない。

こうした限界は貢献を弱めるものではない。むしろ、より正確に位置付ける。Greenberg の影響は、ネットワーク動作をトポロジー、トランスポート、制御、測定、組織的対応の組み合わせとして扱うシステムの設計と指導に関わったことにある。反対論が示すのは、統合する層が増えるたびに、障害、ずれ、外部からの検証困難を生む別の依存関係も増えるということである。

トラフィックマトリクスはネットワークを設計可能な対象にした

通信事業者ネットワークは膨大な運用上の証拠を生成するが、需要を簡潔には説明しない。リンクカウンターはインターフェースが混雑していることを示せても、どの端末間需要が負荷を生んだか、別の経路が障害を起こしたら何が起きるかを説明できない。フロー記録、ルーティングテーブル、過去の性能はいずれも部分的な視点を提供する。トラフィックマトリクスは、それらを入口・出口間で移動する需要量のモデルへ統合しようとする。

容量計画担当者にとって、このモデルは検討できる問いを変える。過負荷のリンクは局所的な問題かもしれず、ルーティング方針の結果かもしれず、別の場所での構造的成長を示しているかもしれない。計画停止は通常需要では安全でも、相関するピーク時には危険な場合がある。ネットワーク全体の推定により、新たな容量や経路方針を確定する前に、こうした可能性を試験できる。

ネットワークデータは完全ではないため、推定には条件が付く。サンプリングはバーストを見逃し、集約は個々のフローを隠し、暗号化はアプリケーションレベルの解釈を制限する。経路変更でトラフィックが急速に移動すれば、昨日の需要マトリクスは今日のリスクを示す参考にならない場合がある。運用上の価値は、一つの測定システムに決定的な答えを期待することではなく、複数の不完全な信号を時間を通じて比較することから生じる。

この実証的アプローチは、その後のクラウド研究の基礎にある。VL2 がファブリック全体へフローを分散するにはトラフィック需要の把握が必要である。SWAN が広域容量を割り当てるには予測と現在状態が必要である。差別化されたフェイルオーバー計画には、サービスの依存関係と復旧動作に関する証拠が必要になる。仕組みは異なるが、いずれも観測を、現実と一致しないときに修正できるモデルへ変換することに依存する。

ファブリックは周囲の制御を安全に変更できて初めて有用になる

folded-Clos トポロジーがハイパースケールデータセンターにとって魅力的になったのは、サーバーからファブリックの他の部分まで多数の経路を作り、拡張をよりモジュール化できるためである。VL2 はその物理構造をアドレスの間接化とトラフィック分散へ結び付け、厳格な場所の階層に制約されずにサービスを移動できるようにした。基盤ネットワークがスイッチとリンクの分散集合であるにもかかわらず、アプリケーションに広く均一な接続性を体験させることを目指した。

この抽象化は責任を制御ソフトウェアへ移す。システムはサービス識別情報を場所へ対応付け、経路を選択またはトラフィックを分散し、リンクやスイッチの障害へ対応しなければならない。これらの仕組みが古い、または不整合であれば、ファブリックに十分な物理帯域があっても、サービス品質は低下し得る。したがってトポロジーは容量資源であって、信頼性の保証ではない。

仮想ネットワークも同様である。顧客が見るのはプログラム可能なネットワークであり、事業者はその意図をホスト規則、経路、トンネル、ゲートウェイ、共有物理容量へ変換する。顧客には隠れた状態のすべてが見えないため、変更にはバージョンを付け、安全に展開しなければならない。制御プレーンの不具合が新しい設定へ影響する一方、既存のデータプレーンフローは継続する場合があり、ワークロードが作成・移動された時期によって症状が異なる障害を生み得る。

ここでアーキテクチャは運用上の契約になる。プラットフォームチームはアプリケーションチームから複雑性を引き取り、その代わりに互換性、可観測性、復旧への責任を負う。共有された抽象化は組織全体を速くできるが、それを運用するチームが限界を説明し、抽象化が失敗したときの回避経路を用意できる場合に限られる。

輻輳制御は、チーム間の境界も設計の一部であることを示す

DCTCP は、組織が別々に扱いがちな境界を仕組みが横断するため、有用な例である。キューがしきい値を超えるとスイッチがパケットへ印を付け、エンドポイントは印の付いたパケットの割合に応じて送信動作を調整する。どちらか一方だけでは意図した結果を出せない。ネットワークチームとホストまたはオペレーティングシステムのチームは、動作、しきい値、展開、測定について合意しなければならない。

データセンター規模では、こうした合意は一度限りの設定ではない。ハードウェア世代が変わればバッファリングも変わり得る。ホストイメージには異なるトランスポートコードが導入される可能性がある。ワークロードは短い要求応答型トラフィックから、大規模ストレージ転送や AI 通信パターンへ移る可能性がある。ある構成で機能した設定が、別の構成では不公平や遅延を生むことがあるため、周囲のシステムが変化する間も制御ループを監視しなければならない。

これは研究と本番環境の区別が重要な理由でもある。論文は仕組みを切り出し、管理された前提の下で結果を示せる。本番チームはその前提を維持するか、成立しなくなった時点を認識しなければならない。優れたアーキテクチャは、アップグレードを全体へ展開する前に試験できる程度まで、こうした依存関係を可視化する。

Greenberg の成果群はこの問題へ繰り返し戻っている。Ananta は、装置がかつて集中させていた機能を分散する。SWAN は、転送が分散されたままの WAN について推論を集中させる。Pingmesh は、障害がネットワークとアプリケーションのどちらにあるかについて意見が分かれ得るチーム間に共通の証拠を作る。各システムは技術的な境界を変え、それとともに、誰が連携しなければならないかという組織境界も変える。

可観測性は判断を変えるときにだけ価値を持つ

大規模プラットフォームは、一人では直接確認できない量のテレメトリーを収集できる。課題は単に測定を増やすことではなく、測定を行動へ結び付けることである。Pingmesh の貢献は、多数のエンドポイントの組み合わせで遅延と損失を継続的に観測可能にし、障害時に比較できる基準を運用者へ与えたことだった。装置の健全性は正常に見えても、利用者が経路レベルの問題を経験している場合に役立つ。

合成測定には重要な利点がある。アプリケーションが利用されていないときも継続的に実行できる。一方、合成測定はアプリケーションそのものではないという重要な限界もある。プローブは異なる経路を通り、キュー状態を見逃し、症状の原因となるアプリケーション依存関係を避ける場合がある。したがって運用上の判断は、合成されたネットワークの証拠を、サービスのテレメトリー、トポロジー状態、展開履歴と組み合わせることから生まれる。

同じ論理はトラフィックマトリクスと障害試験にも当てはまる。測定は、反復可能な意思決定ループへ参加するときにインフラになる。需要の証拠がボトルネックを示したため、容量計画担当者が拡張計画を変更する。現在の状態が障害を示したため、コントローラーがトラフィックを移す。テレメトリーが変更と損失パターンを結び付けたため、障害対応チームが展開を戻す。判断へ影響できない指標は報告にすぎない。判断を変えられる指標は制御の一部になる。

この区別は、ネットワークのソフトウェア定義が進む中で Greenberg が引き続き重要である理由を説明する。プログラム可能性が高まるほど、迅速に行える判断が増え、その判断が機能したかを示す証拠の価値も高まる。測定のない自動化は盲目である。変更へつながらない測定は受動的である。両者を結び付けつつ、一つの誤信号でシステムが不安定になるほどフィードバックループを攻撃的にしないとき、アーキテクチャは有用になる。

AI インフラは制御ループを誤るコストを高める

現在の AI インフラは過去の教訓を無効にするのではなく、その重要性を高める。学習システムはアクセラレーター、ストレージ、計算ノード間に持続的な東西方向トラフィックを生み得る。推論は遅延に敏感なサービス経路を追加する可能性がある。アクセラレーターの配置、データ移動、障害復旧によって、ネットワークは背景的な設備ではなく、ワークロードスケジューリングの一部になる。容量を孤立させたり輻輳を生んだりする制御判断は、ネットワーク帯域だけでなく高価な計算資源も浪費し得る。

提示された証拠は、Uber における Greenberg の現在のプラットフォーム上の担当範囲を AI・自動運転車インフラへ結び付けているが、すべてのシステムを挙げたり、個人の設計責任を割り当てたりするところまでは達していない。この隔たりは明示したままにすべきである。関連する結論は、同じアーキテクチャ上の規律、すなわちトポロジー、容量、ロードバランシング、テレメトリー、障害領域がこれらのワークロードにも重要だということであり、一人の幹部が上位のアルゴリズムへ責任を負うということではない。

専用 AI ファブリックは、一般的なクラウドネットワークから分岐する可能性もある。学習クラスターは、通常のアプリケーションを運ぶ Ethernet/IP サービスネットワークとは異なる、厳密に管理された相互接続やスケジューリング前提を使う場合がある。技術が分かれても、根本的な制御上の問いは変わらない。需要は何か、方針をどこに置くか、状態をどう適用するか、どの障害が独立しているか、意図した動作が起きたことをどの証拠が示すか。

ここでは、特定の製品名より Greenberg の統合的な視点の方が有用である。この歴史が示すのは、トポロジー、トランスポート、ロードバランシング、WAN 容量、テレメトリーを無関係な専門分野として扱わなくなったとき、インフラが改善するということである。AI は断片化のコストを可視化する。利用されないアクセラレーター、失敗したジョブ、遅延したデータ移動によって、ネットワーク制御の誤りが大きな計算・資本損失へ変わり得るからだ。

アーキテクチャは組織が運用できて初めて存続する

技術論文は、本番作業が始まる場所で終わることが多い。トポロジーが説明され、アルゴリズムが評価され、一連の測定によって仕組みが機能し得ることが示される。長年の運用には別の仕組みが必要である。所有責任、リリースプロセス、当番体制、容量計画、ハードウェア更新、セキュリティレビュー、互換性方針、サービスを止めずに設計を変更する方法である。

Greenberg の経歴はこの境界を繰り返し横断している。AT&T での仕事は、研究のためにトラフィックを止められない稼働中の通信事業者環境で行われた。Microsoft の研究上の発想は、ハードウェア世代と地域をまたいで顧客を支える必要がある Azure 組織へ入った。Uber のプラットフォームチームは、信頼性と性能の要件が異なるアプリケーション部門を支えなければならない。仕組みは変わっても、組織上の試験は似ている。ネットワーク全体の発想を、多数のチームが行う反復可能な判断へ変換できるか。

共通の抽象化は専門作業を集中させるため役立つ。均一なファブリックは拡張へ一貫した形を与える。仮想ネットワークは、事業者が物理ネットワークを変更する間も顧客へ安定した制御面を提供する。共有ロードバランシングサービスは、各アプリケーションチームが独自の入口アーキテクチャを作ることを防ぐ。共通テレメトリーは障害対応者へ共有された視点を与える。標準化されたフェイルオーバークラスにより、容量計画担当者はすべてのサービスを個別交渉せずにワークロードを区別できる。

集中にはその見返りとして義務が生じる。プラットフォームチームは限界を公開し、互換性を守り、抽象化が破れたときに証拠を提供しなければならない。顧客だけでは、隠れたファブリックや制御プレーンを修復できない。集中した推論が正当化されるのは、中央チームが複製、段階的変更、ロールバック、明確な障害責任によって、より広い影響範囲を支えられる場合だけである。

ハイパースケールの経済性はこの点を強める。利用率、キューイング、負荷分散、予備容量を数％改善するだけでも、大規模な機器群へ影響する。同じ規模は誤りも増幅する。誤った輻輳しきい値、経路配布エラー、テレメトリーの死角は、多数のサービスへ一度に影響し得る。技術パラメーターが事業上の判断になるのは、それが企業の資金負担となるインフラ量と、引き受ける運用リスクの双方を変えるからである。

制御ループは設計者より長く存続しなければならない

大規模ネットワークシステムは、一度導入して変えないものではない。ハードウェア世代は交代し、ワークロードは変化し、製品には新たな要件が加わり、組織は責任を再配分する。最初の設計者がいる間だけ機能するアーキテクチャは、永続的なインフラではない。より難しい試験は、新しいチームが需要、判断、転送、障害に関する理解可能な説明を維持しながらシステムを変更できるかどうかである。

Greenberg の主要プロジェクトは、この継続性の異なる部分を明示する。トラフィックマトリクスは需要を計画可能な形で可視化する。4D アーキテクチャは制御上の役割を分離し、方針に関する推論を転送から独立して検討できるようにする。VL2 はサービス配置を物理的な場所から切り離す。DCTCP は輻輳をスイッチとエンドポイントが共有するフィードバックへ変える。Ananta と SWAN はサービス・広域規模でトラフィックを割り当て、Pingmesh は遅延と損失に関する継続的な証拠を作る。

本番運用は、これらの仕組みを組織の記憶へ変える。インターフェースにはバージョンが必要であり、アップグレードを経てもテレメトリーを比較可能に保ち、ワークロードの変化に応じて容量モデルを再調整しなければならない。障害訓練では、独立性と予備に関する前提を検証すべきである。独立しているはずの経路が依存関係を共有していた場合や、展開によって制御プレーンの弱点が露呈した場合、障害レビューはコードだけでなくアーキテクチャも変えるべきである。

これは Greenberg 個人の役割について最も明確な境界でもある。彼がソフトウェア定義ネットワーク、クラウドネットワーク、AT&T、Microsoft、Uber に関連するすべてのシステムを発明したわけではない。証拠が裏付けるのは、ネットワークを、トポロジー、トランスポート、制御、テレメトリー、運用組織を一体で設計すべき統合された分散コンピューターとして扱うことへの、継続的な貢献である。その影響は、確立に関わった人物を越えて規律が存続するときに最も強くなる。

したがって観測可能な基準は、別の受賞歴や広範な役職名ではない。このアプローチの影響を受けたプラットフォームが、意図したこと、適用したこと、利用者が実際に経験したことのつながりを失わずに変化し続けられるかどうかである。新しい AI ワークロード、新しいハードウェア、新しい障害モデルによって目標は動き続ける。永続的なアーキテクチャは、その変化を試験できるほど説明可能にし、運用できるほど可逆的にし、責任がシステム内へ消えないほど明示的にする。