障害をどう捉えるか
Design for Failureは「障害発生を前提としてシステムを設計しましょう」という、言葉だけでは当たり前のように聞こえる内容なのですが、それを驚くべき方法で実践している企業があります。米国を中心に郵送DVDレンタルや動画ストリーミングサービスを提供しているNetflix社です。
Netflix社はChaos Monkey参考1、2とよばれるプログラムを開発しています。このお猿さんは、あろうことか実運用システムのサーバの電源をランダムに落とす(クラウド上の仮想マシンを停止する)などの悪さを実施してしまいます。いったい何のメリットが?と思うところですが、これに対抗するため、システム側は自然とChaos Monkeyが悪事を働いても大丈夫なように冗長性を意識した構成になり、運用者の立場から見ても、「日常的に障害が発生しているが問題には至っていない」ことを実感でき安眠できる、というメリットがあるようです。
クラウドという柔軟なリソース払い出し/返却の仕組みを逆転の発想で利用して、毎日のように人工的に障害を発生させて復旧訓練をやっている、と考えると、愚直ですが理にかなった仕組みと捉えられるのではないでしょうか。
クラウドの障害とSLA(Service Level Agreement)のない世界
クラウドの障害の話題が上るたびに、「これだからクラウドは信用ならない」という意見と、「クラウドだから障害が発生したのではない、設計と運用の問題だ」という意見が平行線で繰り広げられるのを目にします。前者の意見は確かに短絡的ですが、専有できない構成要素であるクラウドの障害で業務に影響が出るとすれば、恨み節を口にしたくなるのも仕方ないかもしれません。
Design for Failureの考え方では、障害発生を前提とした上で、障害が発生しても問題なく運用できるような設計をつくることになります参考3。この時、クラウドの持つ柔軟性を活かせば、従来では困難であった設計が可能になり、障害に影響を受けないシステム実現の芽が生まれてきます。
もし、Design for Failureを素直にかつ簡単に実現する仕組みが世の中に広がれば、サーバの故障や負荷の増大、あるいはデータセンタが物理破壊されたとしても業務に影響が無くなり、「クラウドは信用ならない」といった話は忘れ去られることでしょう。
将来はSLAの存在しない、稼働率が限りなく100%の世界が見えてくるのかもしれません。
NTTデータでは、ハードウェア障害を当然起こりうるものとした上で、クラウド基盤そのものやクラウド上の情報システムを高信頼化する技術開発に取り組んでいます。