一般的なインターネットサーバーと言うのは、一次的な障害対策として、ハードディスクの障害に対してはRAIDを、CPUダウンに対してはクラスターを採用しています。二次的には、ロードバランサーによるファイアウォール、Webサーバー、キャッシュサーバー等の振り分けが考えられます。
これに対して、Googleのサーバーは、上記の二次的対策は一部を当然採用していますが、一次的対策の方はこれを実施しないでも障害対応ができる仕掛けになっています。しかも、サーバー自体、グリッドでも何でもないラックマウントのサーバーを、プラグインで交換できるようになっているだけです。
この両者のサーバーの仕掛けの違いは、その維持費用という形で、大きく影響を与えます。前者の仕掛けでは、数千万人レベルの大規模ユーザーに対応できるようにするためには1台億円単位のサーバーが必要になり、かつてサンが潤っていたのは、これが理由です。後者は1台せいぜい千ドル単位の費用しかかかりません。
更に後者は、アプリケーション自体の不具合に対する障害対策として、アプリケーションサーバー自体を物理的に世代管理することで、瞬間的に1世代前のアプリケーションに戻すことも可能です。
しかしながら、後者の仕掛けで対応できるのは「検索」と言う特殊用途に限られ、リアルタイムのアプリケーションなど「更新系」には対応できないのでは、と言う意見も根強くあります。
これについては、以前のエントリー「Googleの技術はオンラインゲーム用サーバーに適用できる！」で詳細に検討していますが、今回は視点を変えて、もう少し別の検討を行います。
Google型サーバーでリアルタイムのアプリケーションを実行する場合を考えます。
まず、Webサーバーによって起動されるアプリケーションサーバーであるプールマシンは、1トランザクション毎に最低2台以上割り当てられ、それぞれ全く同じ処理を実行します。一番最初に結果を返したプールマシンの結果のみを採用し、以降の他のマシンの応答は無視します。逆に応答のないマシンは、自動的に切り離されて、マシン自体のプラグイン交換リストに登録されます。データベースサーバーも細分化されたインデックスシャードの複製を最低2台以上保持していて、対応するプールマシンのアプリケーションによってデータベースの内容が更新されます。この時の処理方法にアイデアがあるのですが、複製マシンすべてに更新をかけ、この時、先の説明の通り、複数のプールマシンから同じ内容の更新がかかることになりますから、これもプールマシンの応答と同じく、一番最初の更新のみ反映させます。更新の応答のないシャードマシンが自動的に切り離されるのは、プールマシンの場合と同様です。
この仕掛けによって、ハードウェア、ソフトウェアいずれの障害に対しても、二重化、三重化されることになり、耐障害性が格段に向上します。
これらの処理方法をよくよく考えてみれば、RAIDやクラスターで実行している内容を、領域単位、処理単位に分割して、これをマシン単位に振り分けて実行すると言う、マシンレベルによる超並列処理を実現していると言うことが分かるはずです。
実は、この仕掛けが、自己組織化するアプリケーションを構築するためのアーキテクチャを考えるヒントになるのですが、これは次回にと言うことで。 KAI