要約

  • 初期のFirehose 1.0では、特定の二つの上りリンク障害により、他の機械とは通信できるのに互いには通信できない状態が生じ得た。この構成は本番の通信を扱っていない。
  • 後の独立した接続ブロックは保守対象を小さくしたが、共通の制御ソフトウェアや設定操作による影響まで分離したわけではない。
  • Urs Hölzleの記録された基盤運営上の責任と共同執筆は、この集団的な仕事を理解する手掛かりであり、個々の設計をすべて本人に帰属させる根拠ではない。

ネットワークの一部を保守に回すとき、残りは何ができるのか。単に「機械が接続されている」と確認しても、答えにならない場合がある。ある機械群は別の機械と通信でき、もう一つの群も同様に通信できる。それなのに、その二つの群の間だけ通信が成立しない。

Googleの技術者による2015年のSIGCOMM原論文は、Firehose 1.0でこの問題を説明している。二つのラック上部スイッチで反対側の上りリンクが同じ修復期間内に故障すると、それぞれの配下にある機械は他の機械へ到達できても、互いには到達できないことがあった。接続に推移性がなくなり、アプリケーションには扱いにくい状態だったという。

これは現在のGoogleの障害報告ではない。著者らはFirehose 1.0が本番の通信を一度も運ばなかったと記している。稼働に至らなかった初期の試みから、次の構成に何を持ち越すべきかを学んだ記録である。

人物の責任と共同作業を分ける

Urs Hölzleは、この回顧論文の多くの共同著者の一人だ。Google Researchの紹介ではGoogle CloudのGoogle Fellowとされ、2023年までは技術基盤を担当する上級副社長だったと説明されている。当時の責任には、Googleのサービスを支えるサーバー、ネットワーク、データセンターの設計、設置、運営が含まれていた。

この範囲が重要なのは、交換網の設計を施設の建設や運用から切り離せないためだ。接続を描くだけでなく、配線し、仕事を配置し、交換や更新を続ける必要がある。一方、肩書と共同署名から、特定の仕組みを誰が考案したかまでは分からない。一人の発明物語にすれば、ハードウェアとソフトウェア、現場作業を結び付けたチームの学習が見えなくなる。

2013年5月の計算サービスに関する発表と、Hölzleによる2020年3月のネットワーク記事も、その時点の職責を示している。後者はGoogleのネットワークと、接続事業者が担う利用者側の最後の区間を区別している。利用者の通信に含まれるすべての依存先が同じ運営主体の管理下にあるわけではない。

故障を分散すると、通信は広がる

原論文は、仕事や記憶領域を複数の電源・故障領域に分散する理由を説明する。一つの局所的な停止に影響が集中しにくくなる反面、近くにまとめていれば短い範囲で済んだ通信が、機械群をまたぐようになる。アプリケーション側の耐障害性の選択が、ネットワーク側の広い帯域需要を生む。

複数段のClos構成は、多数の交換要素を使って多くの経路を用意する。巨大な単一筐体だけに依存せず、大きな接続網を組み立てられる。ただし、経路が多いことと、ある故障の組合せで必要な相手に到達できることは同義ではない。Firehose 1.0の事例は、その違いを具体的に示した。

Firehose 1.1では、接続構造と物理的な実装がともに変わった。交換チップを置く普通のサーバーに代えて専用筐体を使い、独立した帯域外制御網、対になったラック上部スイッチ、見直した集約構造を採用した。著者らはリンク障害への頑健性が向上したと述べる。同時に、配線には多くの作業と慎重な配置が必要だった。保守可能な設計は、再接続や部品交換という現実にも対応しなければならない。

四分の一を外す、という二つの意味

後のFreedomでは、典型的な接続層を四つの独立ブロックで構成した。一つのブロックから通信を退避させて更新する際、集計した容量は25％減ると記されている。保守の対象を接続層全体より小さくできる構成だ。

この数字はその構成に限られる。すべての仕事の性能が更新中も変わらないという意味ではない。残った資源に仕事が収まるか、特定の経路に負荷が偏らないかは別に確認する必要がある。

同じ論文の別の更新図では、Clos網の筐体を四組に分け、一組を無効にすると容量は56.25％まで下がる。段をまたぐ損失が重なるからだ。八組なら低下を穏やかにできるが、手順は長くなる。これはFreedomの四つの独立ブロックとは別の例であり、二つの割合を入れ替えてはいけない。

何台外すかだけでは、保守の影響を測れない。残る接続構造と通信の分布まで含めて、作業単位を決める必要がある。

別々の設備に残る共通部分

Firehose、Watchtower、Saturnについて、論文はFirepathによる制御を説明している。共通のトポロジーとリンク状態を配布し、転送表は各スイッチが手元で計算する。論理的に集中した状態管理であって、中央で一つ一つのパケットの経路を決める方式ではない。冗長な管理側の機能と別系統の制御網がこれを支える。Jupiterの詳細な制御構成は論文の対象外と明記されている。

Jupiter以前の構成管理では、少数のクラスターパラメーターから物品表、ラックとケーブルの計画、制御網の情報、監視データ、共通のスイッチ設定を生成した。選択肢を絞ることで同じ構成を繰り返し建設しやすくなる一方、共通仕様の正しさが多数の設備に影響する。

運用事例もその限界を示す。網全体の同時再起動では、稼働確認と経路計算が限られたスイッチCPUを奪い合った。劣化した内部リンクや制御網では、十分に監視していなかった状態が問題を表面化させた。FreedomのBGP設定変更中には、排他制御のない同時読み取りが書き込みと干渉し、不完全な設定を生んだ。チームは変更を戻し、道具を強化したと報告している。

これらの記述から、停止時間や顧客被害、一般的な故障率は分からない。得られるのは歴史的な仕組みの説明だ。物理的な分割を役立てるには、検知とソフトウェア遷移、設定手順も安全に扱わなければならない。

小さく変えられるという成果

2015年の会議版と2016年のCACM掲載版は同じ仕事の別版であり、独立した二つの検証ではない。運営者の詳細な回顧は学習を示すが、現在の実装や可用性までは証明しない。

この記録でHölzleに結び付けられるのは、文書で確認できる基盤上の責任と、巨大な網を限定した部分ごとに変更できるようにした共同作業である。次に一部を外すとき、何が本当に独立して残り、何が同じ変更や故障を共有するのか。その問いが、保守能力の実質を決める。

出典