サービス再開から約1週間が経過した7月17日、同社はストレージ障害に関する原因およびメンテナンスによるサービス停止が長期化してしまった原因、再発防止策についての報告書を明らかにしました。


　報告によると、ストレージ障害の直接の原因は想定を上回る負荷上昇による高負荷状態であり、さらにその対策として行ったネットワーク設定にミスなどがあってストレージシステム全体がスローダウンしてしまったとのことです。

分散ストレージのキャパシティプランニングのミスが発端

　ZenlogicはYahoo! JapanもしくはAWSのいずれかのインフラの上にファーストサーバがサービスを構築するアーキテクチャを採用しています。ファーストサーバは自社でインフラを保有しない戦略をとっているためです。


　今回障害が起きたのは、Yahoo! Japanのインフラ上に構築されたZenlogicであり、過去にファーストサーバが発表した内容から、ストレージは分散ストレージのCephで構築されていることが推測されます。

　Cephは、ストレージサーバをネットワークでつなげて増やしていくほど性能と容量が向上していく、いわゆるスケールアウト可能な分散ストレージを実現するソフトウェアです。ただし、現実にはもちろん無限にスケールできるわけではありません。

　このシステム構成の推測と、同社の報告を組み合わせて、なにが起きていたのかを観てみましょう。

　まず、同社のストレージ障害の直接的な原因は「ストレージシステムのキャパシティプランでの想定を上回る負荷上昇による一時的な高負荷状態」と報告されています。

　ストレージに求められる性能と容量をあらかじめ予測するキャパシティプランニングは難しいものです。ましてや、顧客がどんな用途で利用するか分からないレンタルサーバでのキャパシティプランニングは難しいものかもしれません。

　だからこそ、あとからストレージの性能や容量をスケールさせられるスケールアウトストレージをZenlogicのバックエンドに採用したのではないかと考えられますが、その予想を上回る負荷が発生したことが今回の障害の発端でした。

　同社は今回の長期メンテナンスに入る前に、何度か障害対策としてストレージの増強とネットワークパラメータの調整などを行ってきたことを明らかにしています。おそらくこれは予想を超えたストレージへの負荷を、Cephのスケールアウト機能を用いて対応させるためにストレージサーバを増やし、それにあわせて分散ストレージの構成について調整を行ったものと推測されます。

ネットワークの飽和を防ぐための設定にミス

　しかしこれでは障害が解消しませんでした。