YAHOO!のサーバーの問題点とは何か。これはGoogle型サーバーにはない、一般的なサーバーの特徴から来る問題です。
つまり、前回のエントリーで述べた、
一般的なインターネットサーバーと言うのは、一次的な障害対策として、ハードディスクの障害に対してはRAIDを、CPUダウンに対してはクラスターを採用しています。
このRAIDとクラスターと言う二つの技術に大きな問題があります。
私たちも当然がごとくRAIDサーバーを利用していますが、以前はRAID5であったものを、現在RAID1に統一しています。これは、私たちが体験した信じられないトラブルから、この設定にしたものです。
信じられないトラブルとは。私たちの製品であるERPパッケージを、ASPサービスではなくパッケージ販売していた時代のある日、あるユーザーのサーバーがダウンしました。サーバーベンダーのCEが、ユーザーの事務所にかけつけ調査し、復旧作業を行いましたが、結果的に48時間たっても回復できませんでした。当然RAID構成ですのでダウンそのものが発生しないはずのサーバーが丸2日、まったく動かないと言う異常事態です。
どうしようもないため、ハードウェア自体を全とっかえした上、私たちのSEが、たまたま別のサーバーに保管していた1週間前のバックアップデータを使用して復旧させました。
通常、RAIDと言う二重化だけでなく、万一のためのバックアップを、1日1回別の外部記憶装置にとる仕掛けになっていますが、なんと最悪なことに、RAIDで切り替わったはずの障害状態のディスクの内容をそのまま、正常な前日のバックアップに上書きしていたのです。
原因は、後日のサーバーベンダーからの報告書では明らかになっていませんが、RAID5のファームウェアと言うソフトウェアのバグであるのは間違いありません。RAID5とRAID1の違いは、ハードウェアではなくソフトウェアの違いです。ですので、現在バグの心配の少ないと思われるRAID1を採用していると言う訳です。
次に、クラスターの問題です。
これについては@ITに「フェイルオーバーの仕組みと問題点」と言う題で分かりやすい説明があります。
クラスタソフトウェアが業務引き継ぎの最後に行う仕事は、アプリケーションの引き継ぎです。フォールトトレラントコンピュータ（FTC）とは異なり、一般的なフェイルオーバークラスタでは、アプリケーション実行中のメモリ内容を含むプロセス状態などを引き継ぎません。すなわち、障害が発生していたサーバで実行していたアプリケーションを健全なサーバで再実行することでアプリケーションの引き継ぎを行います。
要はクラスターと言っても、FTCではないと言うことです。
これでは実際問題使い物にならない（恐らく今回のYAHOO!サーバーダウンの問題はこれと思われます）のは明らかです。つまり、業務アプリケーションにおいて一体どこにリアルタイムに「リラン」がきくプログラムなど存在すると言うのでしょうか。
まさに検索系でしかクラスターは使えないと言っているだけです。
これらの問題が「アーキテクチャ」の問題に帰するということを含めて次回以降に論じますが、そもそもインターネットのアーキテクチャそのものが、RAIDやクラスターと言う概念と折り合いが付いていないことが、今回指摘する問題点の根本の問題なのです。 KAI