- 会員限定
- 2018/07/19 掲載
ファーストサーバ「Zenlogic」の障害、原因は? 想定以上の負荷、設定ミス…
ITジャーナリスト/Publickeyブロガー。大学でUNIXを学び、株式会社アスキーに入社。データベースのテクニカルサポート、月刊アスキーNT編集部 副編集長などを経て1998年退社、フリーランスライターに。2000年、株式会社アットマーク・アイティ設立に参画、オンラインメディア部門の役員として2007年にIPOを実現、2008年に退社。再びフリーランスとして独立し、2009年にブログメディアPublickeyを開始。現在に至る。
報告によると、ストレージ障害の直接の原因は想定を上回る負荷上昇による高負荷状態であり、さらにその対策として行ったネットワーク設定にミスなどがあってストレージシステム全体がスローダウンしてしまったとのことです。
分散ストレージのキャパシティプランニングのミスが発端
ZenlogicはYahoo! JapanもしくはAWSのいずれかのインフラの上にファーストサーバがサービスを構築するアーキテクチャを採用しています。ファーストサーバは自社でインフラを保有しない戦略をとっているためです。今回障害が起きたのは、Yahoo! Japanのインフラ上に構築されたZenlogicであり、過去にファーストサーバが発表した内容から、ストレージは分散ストレージのCephで構築されていることが推測されます。
Cephは、ストレージサーバをネットワークでつなげて増やしていくほど性能と容量が向上していく、いわゆるスケールアウト可能な分散ストレージを実現するソフトウェアです。ただし、現実にはもちろん無限にスケールできるわけではありません。
このシステム構成の推測と、同社の報告を組み合わせて、なにが起きていたのかを観てみましょう。
まず、同社のストレージ障害の直接的な原因は「ストレージシステムのキャパシティプランでの想定を上回る負荷上昇による一時的な高負荷状態」と報告されています。
ストレージに求められる性能と容量をあらかじめ予測するキャパシティプランニングは難しいものです。ましてや、顧客がどんな用途で利用するか分からないレンタルサーバでのキャパシティプランニングは難しいものかもしれません。
だからこそ、あとからストレージの性能や容量をスケールさせられるスケールアウトストレージをZenlogicのバックエンドに採用したのではないかと考えられますが、その予想を上回る負荷が発生したことが今回の障害の発端でした。
同社は今回の長期メンテナンスに入る前に、何度か障害対策としてストレージの増強とネットワークパラメータの調整などを行ってきたことを明らかにしています。おそらくこれは予想を超えたストレージへの負荷を、Cephのスケールアウト機能を用いて対応させるためにストレージサーバを増やし、それにあわせて分散ストレージの構成について調整を行ったものと推測されます。
ネットワークの飽和を防ぐための設定にミス
しかしこれでは障害が解消しませんでした。今すぐビジネス+IT会員にご登録ください。
すべて無料!ビジネスやITに役立つメリット満載!
-
ここでしか見られない
1万本超のオリジナル記事が無料で閲覧可能
-
多角的にニュース理解
各界の専門家がコメンテーターとして活躍中!
-
スグ役立つ会員特典
資料、デモ動画などを無料で閲覧可能!セミナーにご招待
-
レコメンド機能
あなたに合わせた記事表示!メールマガジンで新着通知
関連タグ
関連コンテンツ
PR
PR
PR