※2018/7/10 15:00 概ね復旧したとのこと
概要
ソフトバンク子会社のファーストサーバーが運営するクラウド型マネージドレンタルサーバー「Zenlogicホスティング」が、緊急メンテナンスのため、全サービスを最長60時間停止すると発表しました。
状況をまとめます。
経緯
2018年6月19日(火)より、ストレージサーバーの高負荷により、サービスが高負荷状態となる障害が断続的に発生していた模様です。
6月19日より一部のお客様で発生している高負荷障害に関するお詫びとお知らせ ｜Zenlogicサポートサイト[ファーストサーバ]
要約すると、
・一部ログの出力内容変更 → 効果なし
・一部サーバーの入れ替え → 効果なし
・ストレージシステムの緊急増強 x 3回と設定値変更 → 効果なし
・ストレージシステムの増強メンテナンス → 効果なし
・ストレージシステムの設定最適化 → 効果なし
・システム基盤管理のヤフージャパンと協議したところ、システムのバグを踏んだ可能性があるとのこと。不具合解消の準備をはじめる。
・7/3よりシステム設定値変更の反映をオンラインではじめる。
・なかなか設定値の変更が完了しないまま、高負荷状態が断続的に継続する。
・7/5にコントロールパネルを停止してメンテナンスに入る。
・7/6 20:00に、システム全停止を決定。
という具合のようです。
全停止はかなり急ぎで決めたようで、
Zenlogic！！！！19:53分のメールで20時〜全サービス停止とか正気か！そんな中でも請求メールだけ飛んでくるとかすごいわ。
— 三谷 健一 (@mitanin) 2018年7月6日
ということのようです。
障害の原因（ホームページより）
2018年7月3日時点で判明している障害の原因は、以下のとおりです。
冗長構成しているストレージシステム（データ記憶システム）において、データ入出力の処理が一部のシステムに偏ったことにより、高負荷が発生。該当ストレージシステムの再起動が発生し、サービスが断続的に利用できない状態が発生しました。
データ入出力の処理が一部のストレージシステムに偏るのは、以下の点が原因と推測しております。突発的なアクセス集中が発生した際のパフォーマンス不足
ストレージシステム構築時のパラメーター設定が適切でない
ストレージの「一番あかんやつ」ですね。ストレージサーバーを一度でも触った人はわかるはずです。こんなに大変なデバイスはありません。サービスインしたときは負荷がないので快適なのですが、仮想サーバーがたくさんつながってくると、一気に高負荷問題が起こる。仮想サーバー群も複数で同時に負荷が上がると倍増してストレージサーバーに負荷がやってきます。しかもその間のネットワーク帯域も十分な容量が必要であり、サイジングに関しては構築時に5年先ぐらいまで読んでおかないといけません。
私自身はこういう状況が嫌で、オンプレからクラウドに移ったエンジニアです。
サービスを止めることで、負荷を分散させる設定を早く終わらせ、この問題を切り抜けたいということだと思います。
ファーストサーバーと言えば思い出す
業界内では有名な2012年のあの件。今一度思い返します。
ASCII.jp：データ消失！あのとき、ファーストサーバになにが起こったか？ (1/2)｜データ消失事故から2年！ファーストサーバ、再生への第一歩
ASCII.jp：信頼を失ったファーストサーバが挑んだ事故調査と再発防止 (1/2)｜データ消失事故から2年！ファーストサーバ、再生への第一歩
ASCII.jp：ファーストサーバを救った顧客の声とコミュニケーションのパワー (1/2)｜データ消失事故から2年！ファーストサーバ、再生への第一歩
ヒューマンエラーでデータが消失する。そして復旧を断念。ファーストサーバーはそこから再出発しています。
2015年には、ヤフーのIaaS基盤を利用したZenlogicホスティングサービスを立ち上げています。
【インタビュー】データ消失事故から3年、変革を決意 ファーストサーバはサーバーを捨てて中小企業の救世主となる - クラウド Watch
2018年2月に、Zenlogicへの全サーバー移行が完了しています。
ファーストサーバ、約2万社向けサーバーをクラウド化 ：日本経済新聞
約2万社の物理サーバー移行でファーストサーバが得たもの - 週刊アスキー
全面移行から4か月。性能問題が早くも発生したということで、厳しい言葉ですが見通しが甘かったとしか言いようがありません。
Zenlogicの技術的側面について
ZenlogicはYahoo! JapanのIaaS基盤であり、OpenStackを使っているということは記事中からわかります。以前から、Yahoo! JapanがOpenStackを相当さわっていることは業界内で漏れ聞こえてきていました。
ガチで聞く！ヤフーのOpenStackプライベート・クラウドの実態とは
NetApp Innovation 2015 自由、そして自在へ
ヤフーが法人向けクラウド基盤に進出、子会社ファーストサーバがサービス提供 | 日経 xTECH（クロステック）
Yahoo! JAPAN のサーバー OS について - Yahoo! JAPAN Tech Blog
あくまでも記事からの推測です（Yahoo!のインフラをそのまま踏襲するなら）。
・Yahoo!のインフラと、Zenlogicの設計や実装は別
・ストレージはおそらくNetApp
・ネットワーク機器はBrocade
・OpenstackはKVMとVMwareの共用とありますが、おそらくコスト的に考えてZenlogicはKVMを使っていると思います。いわゆるVPSではなく、顧客ごとに仮想OSを用意することをアピールしています。
ということで、Yahoo! Japanのインフラを使っていながら、Yahoo! Japan本体のサービスには全く何の問題も起こっていないことから見ても、独立したシステムになっているようです。
バックアップまわりも、前回の件を受けてかなり神経質に取得しているようですね。
感想
2012年からの経緯があるだけに今回の件はかなりの信用失墜だと思います。スタッフもメディアにも積極的に出てPDCAをアピールした上に、インフラ基盤までヤフーのブランドに移動し、さあこれから、の矢先です。
Yahoo! Japanのアプリを動かすことに特化したOpenstack設計を、ホスティングサービスに転用する。一見合理的なように見えますが、落とし穴があると思います。ホスティングサービス上で動くエンドユーザーの仮想OSがどのように動くか全く読めないところです。アプリケーションの動作が読めればキャパシティー設計がやりやすいのですが、ホスティングサービスの場合は、顧客のアプリケーション次第ですので、出たとこ勝負の面が強いです。仮想化環境の設計についてはキャパシティープランニングを相当に余裕を持たせるべきで、かつできるだけ集中させず分散させる設計にしないといけません。１つのボトルネックですべてがスローダウンしてしまうのです（今回のように）。
既存顧客をZenLogicに載せ替えたら4か月そこそこですぐに性能上限を迎えたということですから、そもそもの計算が間違っていたことにほかなりません。
前回の問題は、運用ミス。今回の問題は設計ミス。です。問題のポイントが全く違います。負荷試験は事前に実施されていたでしょうが、想定していない負荷が発生したのでしょう。そしてそれは全面移行からそんなに時間が経っていないことから考えて、甘々だったと言えます。
ひとまず、再設計検討後の今回のメンテナンス反映で、問題が根本解決すれば良いなと思います。もしそれでも解決しない場合は、Zenlogicホスティング Powered by AWS、つまりAWSに一部のサーバーを逃がすことをお勧めします。
追記
進展がありましたら随時追記します。
2018/7/8 12:30
状況は変化していません。焦点は、明日(7/9)の8:00AMまでに本当にメンテナンスが終わるのかということになってきました。また、もし仮に予定通り進んだとしても現象が改善するかも重要です。
なお、ストレージ基盤について、オープンソースのcephを使っているという記載を見つけました。
cephについては、ニフクラのオブジェクトストレージでも今年問題を起こしています。
ニフクラのオブジェクトストレージ障害を考える - orangeitems’s diary
上記の件では回復に1か月を要しています。
Zenlogicを使っていた多数のサイトが現在つながらない状況にあるのも確認しており、予断を許さない状況が続いています。
2018/7/9 8:50
残念ながら、本日8:00に、メンテナンスの無期限延長が発表されています。
断続的に続いている高負荷状態改善のため、7月6日20時より、すべてのサービスのご利用を停止させていただくメンテナンスを実施しております。作業に著しい遅れが生じていることから、完了予定時間を延長させていただくこととなりました。
長時間に渡りお客様に大変ご不便をおかけしておりますことを、深くお詫び申し上げます。
メンテナンス終了時間につきましては、サポートサイトにて随時ご報告いたします。
2018/7/9 15:30
15:00の更新で、本日中の復旧はほぼないことが示されています。
現在も、原因・対応方法の調査、及び、別環境、そのほかの代替手段を準備検討しておりますが、時間を要しており、本日中に目途をお伝えするのは厳しい状況でございます。
cephのトラブルであり、かつその容量が大きいとすると、1日2日で修正できるような気はしませんでしたが、やはりそのような流れとなりそうです。
優先順位をつけるならば、
・ディスクのreadだけはできるようにし外部移行ができるようにすること
・ドメインレジストラの業務だけは早急にリカバリーし、ドメインの移管もしくはDNSの変更だけはできるようにすること。 →今でもできる
この2点が重要だと思います。
2018/7/9 16:46
移設の方法が下記に案内されていますね。
高負荷障害に関して多くのお客様からいただくお問合せ ｜Zenlogicサポートサイト[ファーストサーバ]
カスタマーポータルは、IDCFクラウドで動いているようで、こちらでドメイン関連の作業はできそうです。DNSサーバーの変更だけではなく、ドメインの移管までできるとあります。メンテナンスの終了が未定な以上、まずは代替サイトを立ち上げるべきでしょうね。
2018/7/10 10:16
昨夜7/9 22:20に動きがありました。
一時的に高負荷状態の緩和を確認しましたので、メンテナンスを終了し、サービスをご利用いただける状態にさせていただきました。再び高負荷状態になった場合には、サービスのご利用を停止させていただく場合があります。現在も、原因・対応方法の調査、及び、別環境、そのほかの代替手段を準備を進めております。
以上の通り、根本原因は解決していないものの、サービスは回復させるという形を取ったようです。移行を進める予定のユーザーは今がチャンスだと思います。
2018/7/10 15:38
下記のコメントが発表されました。
2018/7/10(火) 15:00現在
メンテナンス終了後の経過ご報告
2018年6月19日(火)より発生しているZenlogicホスティングの高負荷障害を改善するため、7月6日(金)20時00分よりすべてのサービスを停止し実施させていただいたメンテナンスについて、追加作業も含め、予定していた作業が完了しております。
当初予定していた終了時間を大幅に超過しましたこと、また、メンテナンス期間中はすべてのサービスをご利用いただけず、お客様に大変なご不便をおかけいたしましたことを、深くお詫び申し上げます。
メンテナンス終了後から現時点まで、稼働状態が安定していることを確認しております。引き続き監視を強化するとともに、経過を随時ご報告してまいります。
基盤全体としては稼働状態の安定を確認しておりますが、高負荷状態時の影響により、一部のお客様では、サービスを利用いただけない状態が続いておりますため復旧作業中でございます。詳細につきましては、メール・お電話にて個別にご連絡させていただいております。長時間に渡り、お客様に大変ご不便をおかけいたしておりますことを、深くお詫び申し上げます。
「概ね復旧」ということで理解しました。
もし何かあれば、後日追記していきます。
2018/7/17 14:30
正式な障害報告書がファーストサーバーより発行されました。コメントを入れました。
Zenlogic障害報告書から考察する分散ストレージCeph - orangeitems’s diary
