Zenlogic 障害のその後。

レンタルサーバサービスのZenlogicの障害について

rxjun.hatenablog.com

その後復旧は無事出来たようで、ようやく報告が出されたらしい。

報告の概要

[概要]

事象A：ストレージシステムのキャパシティプランでの想定を上回る負荷上昇による一時的な高負荷状態

事象B：事象Aへの対応に伴い、二次的に生じた長期間にわたる高負荷状態

[原因]

事象Aに対する原因

（1）2018年6月からストレージシステムに対する負荷が想定より高くなったことにより一時的な高負荷が発生し、サービス利用が困難となる状態が不定期に発生しました。事象Bに対する原因

（2）ストレージシステム最適化処理などで発生するシステム内部通信がネットワーク全体を飽和させる状況を回避するために、システム内部通信に対してネットワークトラフィック制限を実施しましたが、この際のネットワーク設定が一部、不適切な設定となっていたことにより、ストレージシステム全体がスローダウンしました。

（3）複数回のストレージシステム増強や、設定値変更に伴い、ストレージシステム内部でこれまでになく大量のデータ移動が発生したこと、および2項のネットワーク設定の一部が不適切な設定となっていたことにより、データ移動完了まで時間を要しました。このため、ストレージシステムの高負荷状態が当初見込みより長期化しました。

Zenlogicは自社インフラを持たず、クラウド事業者(Yahoo!/AWS)のリソースを利用してサービスを提供しているが、ストレージシステムで想定以上の負荷がかかっていたという報告だ。

クラウドを使う利点の一つとしては、スケーラビリティの自由度の高さに伴うユルいサイジングにあると思うが、そんな状況で「想定を超える負荷」が起きると言うのは一体どういう状態なのか・・・

帯域の不足？(巨大トラフィックのシーケンシャルIOが主体だったらあり得るが、通常の業務APであればあまり問題になることは少ないと思う)
iopsの不足？(コストを抑えるためにHDDベースのストレージだと余程キャッシュに余裕が無いと1000iopsも行かないので不足する。分散ストレージならまた話は別)

実態は分からないけど、恐らくこの時点でストレージサーバの追加によるスケールアウトを想定していたんだろうけど、スケールアウト時のデータ平準化処理で内部のストレージ用帯域を食い潰してしまった､と言うのはあり得そうな気はする。

再発防止策としてストレージのキャパシティブランの見直しとネットワークトラフィックの監視をするらしいけど、やはりこの辺の可用性、柔軟性はコストにモロに響く所だと思う。

レンタルサーバサービスとして事業を成り立たせるためのコストに見合ったキャパシティを実現できるのかどうかが、今後のZenlogicとインフラを提供するYahoo!側の課題だろう。今回の事態は、報告をみる限りでは不測の事態では無くてサイジングの想定不足と人為的な設定ミスが重なった物で、本来であれば回避できたであろう事象だったはずだ。

問題解決が長引いたことと、ファーストサーバ社の過去のトラブル等複数の要因で信用は失墜したと言っても良い。今後どのように立ち直ろうとしているのか気になる。