Googleや「京」に見るエラー訂正技術

故障を許容するシステム構成

デュアルやデュプレックスシステムも一方のサーバが故障しても運転を続けられるシステムであるが、多数のサーバを使うシステムでは、別のやり方も行われる。

Googleは、大量のサーバで分散して処理を行っているが、そのやり方として「MapReduce」という方法を考案した。Mapのマスタノードとなるサーバは、処理を細かい単位に分割し、大量のワーカノードとなるサーバに送って、分散して処理を行わせる。各ワーカノードは割り当てられた処理が終わると処理結果を返し、マスタノードはそれらを受け取ってReduceステップを行う。

このようなやり方で、多数のサーバがそれぞれの分担部分の検索を行って検索結果をマスタノードに返し、マスタノードがそれらを纏めて最終的に表示する検索結果を生成する。

図2.23に示すように、このMapReduce処理においてワーカノード3から処理結果が返ってこないと、マスタノードはワーカノード3は故障とみなして、別のワーカノード(この図ではワーカノード2)にその処理を割り当てて実行させる。

このような処理とすることで、ワーカノード2が再割り当てされた処理を終わって結果をマスタノードに返すと、結果の生成にかかる時間は伸びてしまうが、ワーカノード3が故障した状態でもシステム全体としては正常に処理を続けることができるようになる。

Map-Reduceのステップで、どのような問題でもうまく分散処理ができる訳では無いが、Googleの検索に限らず、大規模な並列分散処理ができReduceすべき結果のデータ量があまり多くないという問題ではMapRecudeはうまく動作する。そして、それぞれが独立の並列分散処理となっているシステムでは、ノードが故障して処理が終わらなかった仕事を別のノードに再実行させるというリカバリ処理が使える。

Googleは100万台以上のサーバを使っていると言われ、サーバの故障率が100年に1回としても、少なくとも年間1万台、毎日300台のサーバが故障する計算となり、このようにワーカノードのサーバ故障を許容するシステムでないとやっていけない。

また、「京」スパコンも9万に近い計算ノードからなる巨大システムである。計算ノードはCheckpoint-Restart機能を持ち間欠エラーを自動的に訂正し、水冷でチップ温度を下げて信頼度を高めているが、それでも計算ノードが故障という事態は発生する。このため、「京」スパコンのノード間をつなぐTofuインタコネクトは6次元メッシュ・トーラスという独自のインタコネクトを使っている

X、Y、Zの3軸はグローバルのトーラスであるが、a、b、cの3軸は図2.24に見られるローカルな12ノードクラスタ内部の接続を担当している。上側の(a)の図では左端の0と書かれたノードからスタートして8と書かれたノードまで3クラスタにわたる長さ9のノード列の接続が描かれている。この図の赤線の矢印は1つの経路しか書かれていないが、左端の12ノードクラスタの4つの0のノードから同じ接続が並列に存在する。

ここで(b)の図のように中央の12ノードクラスタの中のb=1のノードが故障すると、故障ノードを含むリンクは切れてしまう。しかし、b軸を使って(b)の図の赤線のようにルートを変更すると中央の12ノードクラスタのb=1のノードを通らない長さ8のノード列を作ることができる。そして、この図には書かれていないが隣接した予備のノードを組み込めば、故障ノードを避けて元と同じ長さ9のノード列を作ることもできる。

スパコンではノードの故障に備えて、計算の中間結果をチェックポイントとして定期的にディスクに保存するのが一般的であり、「京」システムでは、ノード故障が検出された場合はb軸を使って故障ノードを避けて元のトーラス構造を再現し、ディスクからのチェックポイントデータを新たな接続に対応するノードに復元することにより、中断した計算を再開することができるように工夫されている。

このように製造不良を取り除いて、製品として正常に動作するプロセサを作ることや、そのプロセサを使ってエラーなく動作するコンピュータシステムを作りあげることは、より高性能なプロセサを作ることと比べると華やかさの点では劣るが実用的にはより重要であり、そのために様々な工夫が行われ、その結果として信頼できるシステムが作られていることを理解して戴ければ幸いである。