誰でも分かるファーストサーバー(Zenlogic)障害事件まとめ

ファーストサーバーとは？

ファーストサーバーとは「Zenlogic」という、中小企業向けのレンタルサーバー・ドメイン・SSLサービスを行っている会社です。

これまで累計72000企業以上で利用(契約)があり、さらには官公庁(国や地方公共団体の役所)でも利用(契約)されています。

また、2004年～2018年2月まではyahoo(ヤフー)が親会社、2018年3月からはyahooに代わってソフトバンクが親会社となっています。

yahoo → ソフトバングが親会社という圧倒的ブランド力と72000社以上の利用実績を背景に躍進を続ける大手レンタルサーバー会社です。

Zenlogicサービスにおけるyahooの役割

ファーストサーバーでは2015年1月までは、サービスの契約～レンタルサーバーの管理までの全てを自社のみで行っていました。

しかし、2015年2月からサービス業1本に集中するため、レンタルサーバーの管理はyahooが行うようになりました。

また、それに合わせて今のサービス名であるZenlogicと名乗るようになりました。

■Zenlogicの概要

障害による影響範囲

Zenlogicには2つのサービスがあります。

今回障害が起こったのはyahooがサーバー管理をしている「Zenlogicホスティング」であり、「Zenlogicホスティング Powered by AWS」には障害が発生していません。

また、「Zenlogicホスティング」のほうが利用者が多いため、より多くのユーザーが障害による被害を受けることになりました。

障害事件でユーザーはどんな被害を受けたの

今回の障害事件によって「Zenlogicホスティング」を利用していたユーザーは以下の被害を受けることになりました。

■2018/6/19(火) ～ 2018/7/5(木)まで。

■2018/7/6(金)～ 2018/7/9(月)まで。

障害を復旧するためにファーストサーバー社がZenlogicにおける全サービスを停止してのメンテナンスを実施したことにより、ユーザーは以下4つの被害を受けた。

Zenlogic利用ユーザーによるツイート(Twitter)まとめ

■ユーザーによるツイート(Twitter)まとめ

https://t.co/s3ef0pOwGi
Zenlogic ここまで能力の無いクラウド業者も珍しいな。週間サーバートラブル。今日のメンテナンスも予定大幅遅れで、しかも完了未定ときたもんだ。勿論原因の説明は無し。これでもこの業者を選ぶ技術者がいたら、自殺願望があるとしか思えない

— 藤原＠かみら💨💸(･ω･´) (@Racer_Kamira) 2018年7月2日

急遽、サーバ会社を変更したけど、DNS変更できないって何なんだ！！！電話もつながらんし、メールフォームからメールしても自動応答だし。お願いだからせめてDNSだけでも変更させてくれ仕事にならん#zenlogic

— yucyunpa (@yuzu1113) 2018年7月4日

7/1 ログ出力が間違ってたぽい。修正したからOK
7/2 あ、ごめん直って無かった。助けて親会社Yahoo、つーかお前のせい。
7/3 徐々にいい感じ。5日の昼にはバッチリ
7/4 サーバーに負担がかかる時間帯はダメですが5日の昼にはバッチリ
7/5 あ、ごめんやっぱり6日でよろ～
7/6 今週中無理ぽ #zenlogic

— バイバイアンフォロワー (@bbu_app) 2018年7月6日

おはようございます…目覚めが悪い朝でした。
サーバーが全停止しているので当たり前ですが受注件数ゼロです。
こんな事は前代未聞、これが後48時間も続くと思うと死にそうです。
どうか皆様、私が生きているうちに先に香典をください🥶#Zenlogic #ファーストサーバ pic.twitter.com/yBY3WmOzDq

— 問屋＠ショップ (@tonya_at_shop) 2018年7月6日

Zenlogicなんとか普及したっぽいが、はっきり言っていつまた同じようなことがおきるかわからない。なんせ6年前の大規模障害から何も学んでないんだから。アホは死んでも治らないね。
このまま使い続けるとこちらの信用が落ちるのでさっさと他社に移行します。さようなら。#zenlogic #ファーストサーバ

— mashdogs (@mashdogs) 2018年7月11日

喜べない計測結果😰#Zenlogic #ファーストサーバ #Analytics pic.twitter.com/zyJIUQZWHD

— Amen0ma1 (@amen0ma1) 2018年7月18日

さらには著名者まで、この障害はさすがに「ひどい」とのツイートが

これはひどすぎ
ファーストサーバの「Zenlogic」全面停止3日間続く　再開は「未定」に (ITmedia NEWS) – https://t.co/6O3bQSe5xE

— 堀江貴文(Takafumi Horie) (@takapon_jp) 2018年7月9日

障害を受けた人への返金や損害賠償はどうなるのか？

レンタルサーバー会社のサービス品質規約SLAとは

SLA（サービスレベルアグリーメント）を一言でいうと、レンタルサーバー会社とユーザーとの間で結ばれるサービスの品質規約です。

また、ユーザーがファーストサーバー社のZenlogicサービスに契約した時点でSLAにも同意したとみなされます。

そして、サービスの品質規約とは「レンタルサーバー会社とユーザーにおける正常なサービスの提供条件と条件を満たさなかった場合の返金について」の約束事になります。

■ZenlogicサービスのSLAについて

上記のZenlogicサービスのSLAを要約すると以下のようになります。

原則としてレンタルサーバーを利用してのサイト運営で稼げたはずの金額をレンタルサーバ会社ーによる意図しないサーバー停止によって失っても、それがレンタルサーバー会社の故意または重過失が原因によるものだと認められない限り、SLAに記載されている金額しか返金されません。

重過失と重過失による返金額について

重過失とは

重大な過失、不注意ないし注意義務違反の程度がはなはだしいこと。

民法上は善良な管理者の注意義務を著しく欠くこと。

刑法上は通常人の払うべき注意義務を著しく欠くこと。

コトバンクより引用

このように重過失は著しい不注意や会社で定められたマニュアル(規定)以外のことを一部社員が独断で行ったことが原因によって障害事件が発生した場合でないと、重過失の障害事件とはみなされません。

後述はしていますが、今回の障害では技術的に明らかな問題があったのは事実です。

しかし、経営者やエンジニアの著しい不注意や独断行動で発生した障害ではなく、ユーザーの資産となるサイトやデータも消失したわけありません。

ですので、2週間に及ぶサービスの影響と3日間のサービス完全停止のみで重過失になるかは怪しいというわけです。

■Zenlogicホスティング利用契約約款より

上記のZenlogicホスティング利用契約の記載にあるとおり、重過失が認められても「過去12ヶ月分の利用料金額」しか損害賠償として請求できません。

結論としては、ファーストサーバー社が寛大で自分から今回の障害は重過失であったと認めない限り。

法人(企業)はともかく、個人契約での重過失による損害賠償の請求は厳しいのが現実です。

■参考サイト
ファーストサーバ社のレンタルサーバ「Zenlogic」で大規模障害。利用者は返金や損害賠償を請求できるのか – Stori法律事務所

障害発生～復旧までの時系列のまとめ

今回の障害でファーストサーバーが初めにユーザーへアナウンスを出したのが「2018年6月19日09時15分」で、完全に復旧を宣言をしたのは「2018年7月17日の08時30分」となっています。

では、ユーザーへ初めにアナウンスを出してから完全に復旧するまで、なにがあったのか順番に見ていきましょう。

2018/6/19(火)09：00 ～ 2018/6/19(火)09：30

ストレージシステムの高負荷が原因でレンタルサーバー全体が不安定となり。

その結果、ユーザーが作ったサイトの表示が遅くなったり、Zenlogicのコントロールパネルや契約しているレンタルサーバーへのFTP接続などが繋がりにくくなる現象が発生することをユーザーへアナウンスした。

2018/6/20(水)11:00 ～ 2018/6/20(水)11:30

ストレージシステムの高負荷が原因でのサーバーが不安定になる現象が自然解消したことをユーザーへアナウンス。

2018/6/21(水)12:30 ～ 2018/6/21(水)18:30

再びストレージシステムの高負荷が原因でレンタルサーバー全体が不安定となる現象が発生。

18:30頃に自然解消したことをユーザーへアナウンス。

2018/6/22(金)09:00 ～ 2018/6/22(金)14:00頃

ストレージシステムの高負荷が原因でのサーバーが不安定になる現象を根本的に解決するため、障害の兆候が見られたレンタルサーバーの入れ替えを行ったことをユーザーへアナウンス。

2018/6/23(土)02:00 ～ 2018/6/23(土)06/24(日)23:59

ストレージシステムの高負荷が原因でのサーバーが不安定になる現象の根本的な解決のために動き出す。

障害の原因となっているストレージシステムのキャパシティ(容量)不足を解消するため、ストレージシステムへサーバーの増強を行う。

2018/6/25(月)16:30 ～ 2018/6/28(木)15:40

しかし、またストレージシステムの高負荷が原因でレンタルサーバー全体が不安定となる現象が発生。

この期間中で少し時間をおいて現象が自然解決される現象は合計3回も繰り返された。

2018/6/27(水)13:35～2018/7/3(火)15:30

毎日、ストレージシステムの高負荷が原因でのサーバーが不安定になる現象が発生 → ストレージシステムの増強作業 → 「原因は解消」のやり取りが繰り返される。

2018/7/4(水)8:40～ 2018/7/6(金) 15:45

これまで行ったきたストレージシステムの増強作業だけでは障害を解消できなかったので、さらなる原因調査及び解消作業に乗り出す。

ちなみに、この日から障害はさらに悪化して明らかにサイトの表示が遅くなったり、Zenlogicのコントロールパネルや契約しているレンタルサーバーへのFTP接続などが繋がりにくくなる現象が多発するようになった。

2018/7/6(金)20:00 ～ 2018/7/9(金)23:00

完全な復旧にはサービス全体の停止が必要と判断されて、「2018/7/9(金)23:00」までサービス全体が停止しての超大規模メンテナンスが実施される。

そのあいだ、サイトの閲覧・コントロールパネルの操作・FTP接続などは一切できない状態となり、「Zenlogic」利用ユーザーは阿鼻叫喚状態となる。

ちなみに、サービス全体の停止がユーザーへアナウンスされたのはサービス停止の1時間前の「2018/7/6(金)19:00」だった。

2018/7/9(金)23:00 ～ 2018/7/17(火)08:30

「2018/7/9(金)23:00」にようやくメンテナンスが完了してサービスがようやく再開となる。

以後「2018/7/16(月)」まで経過観察とyahooによる障害報告のまとめが行われる。

「2018/7/17(火)08:30」に完全に復旧したことがユーザーへアナウンスされた。

また、yahooによる障害の原因と対応の報告書がZenlogicのホームページを通じてユーザーが閲覧できるようになる。

障害の原因と不味すぎた対応

今回の障害原因をまとめると以下のようになります。

※この記事で記載している障害の原因はファーストサーバーが出した自己報告書から推測結果ですので、100%正しい答えではないことをご了承ください。

また、以下で使っている画像は概要をイメージしたものですので、データ量などは実数値ではありません。

1.「Zenlogicホスティング」でサーバーを管理しているyahooではデータを複数のサーバーに格納していた。

データを複数サーバー(ストレージ)に分けて格納しておくことで、1つのサーバー(ストレージ)が障害でつぶれても素早く復旧することが出来るので障害に強くなるメリットがあります。

ただし、分散ストレージは正しく運用できないと今回のような大規模障害を起こしてしまうデメリットがあり、今回の障害はそのデメリットに該当する結果となりました。

2.ファーストサーバーやyahooが当初想定していたよりも多くのデータ量となり、用意していたサーバー(ストレージ)だけでは格納しきれなくなった。

また、この時点(2018年6月19日)でサイトやメールの送受信などが遅くなるような障害が発生しており、ユーザーへも障害としてのアナウンスが始まりました。

4.全てのデータを格納して障害を解決するためにサーバー(ストレージ)を増やした。

5.用意されたサーバー(ストレージ)へデータの再配置処理を行った。

6.データ再配置処理時のネットワークトラフィックの設定に失敗していた。

分散したサーバーにデータを再配置するために、ネットワーク回線を通じてそれぞれのサーバーへデータ転送が行われます。

当然、Zenlogicのように7万人以上のユーザーが利用しているような場合、そのデータ量は個人使用レベルではとうてい考えられない膨大なものとなります。

そのような膨大なデータ量を何も考えずにネットワーク回線を通じてデータ転送しようとすると、すぐにネットワークが混雑して異常を起こしてしまいます。

そこで、yahooではネットワークトラフィックの設定を事前に行っておき、ネットワークが混雑しないようにデータ転送を行えるようにしていたはずでした。

しかし、このネットワークトラフィックの設定にミスがあり、その結果ネットワークが混雑してしまいサーバー管理者もユーザーアクセス不能(著しくアクセスが遅い)になる事態となりました。

7.ネットワークが混在してしまい修復不能となったので、サービスを停止させてのメンテナンスを行った。
ネットワークが混雑して、どうしようも無くなったファーストサーバーとyahooはサービス全体を急遽停止させる決断をしました。

サービス停止後はネットワークトラフィックなどの設定を再度見直した後、再びデータを格納するサーバー(ストレージ)へデータの再配置処理を行いました。

その結果、障害が解消してサービス再開となり、以後は経過観察となりました。

ユーザーが使うデータ量の合計予測を見誤って、データを格納するサーバーの台数を少なくしてしまった。

ネットワーク設定のミスにより、データを格納するサーバーへのデータの再配置処理でネットワークを混雑させてしましった。

今回の障害の原因となった分散ストレージは、ここ数年で実用化の流れに入った技術であり、ベテランのエンジニアでも扱うのはまだまだ難しいとされている技術です。

サーバー管理者であるyahooの技術力を疑うわけではありません。

しかし、yahooが分散ストレージの扱いを甘く見ていた結果、起きてしまった障害であると考えれます。

サービス停止直前のアナウンスにユーザー大不満

障害に対して完全な復旧を行うにはサービス停止した上でメンテナンスをしなければならなかった事については、仕方が無かった事かもしれません。

しかし、サービスを停止する前のユーザーへアナウンスを行ったのが、サービス停止の1時間前という対応については弁解の余地も無いほどのひどい対応です。

このファーストサーバー社の対応には、当然のごとく利用ユーザーからも怒りの声が上がりました。

Zenlogicさんそれはほんとに、マズすぎるんですが。7/6 20:00停止のものを19:15に発表でメールが19:53とかお客様にアナウンスする時間すらありませんよね？？！ 7分でなにをしろと。。。バックアップも取れない。しかも最長月曜まで全停止ってあり得ない。 https://t.co/PEQ0zcE3VI

— eriko koide (@elico) 2018年7月6日

Zenlogic、本日20:00から全サービス停止の連絡を、19:53分にメールで送ってくるって、アホでしかない。
あと２分で社内アナウンスメールなんか書けへんし送れんやないか。
も、いいです。さようならｗ

— ちゃづけ☆華花推し (@chauzke) 2018年7月6日

また、Zenlogicを利用している長野電鉄でも、突然すぎるサービス停止のアナウンスに怒りの声をあげている。

「緊急メンテナンスの開始6分前に連絡が来るとは。何も手が打てないではないか」。

長野電鉄企画部の担当者はファーストサーバの対応にこう憤る。

システム障害対応に怒り、ファーストサーバ利用者に広がる不信感

長野電鉄では2018年7月6日に発生した集中豪雨に関する運行情報などをwebサイトやメールで利用者に通知しようとしていた。

しかし、突然のZenlogicサービス停止により通知ができず、急遽FAXで使った異例の対応を行う事態となった。

2012年には大規模データ消失事件を起こしていた

ファーストサーバーが今回のような大規模障害を起こしたのは初めてではありません。

実は2012年にもサイト・メール・顧客情報・バックアップといった多種多様なデータを消失させてしまう、こちらもレンタルサーバー業界では前代未聞の事件を起こしています。

データ消失の影響でユーザーは長期間にわたるサイトの閲覧不能・メールの消失・データの消失を被害を受けることになり。

最終的には当時の親会社であるyahooも協力して損害賠償28億4100万円を払う事態となりました。

ファーストサーバー障害事件を受けて我々ユーザーが学ぶべきこと

今回のファーストサーバー障害事件において、レンタルサーバーを利用する僕たちユーザーが学ぶべきことは以下の4つです。

どのレンタルサーバー会社でも大規模障害が発生する可能性はある

まず、今回のような障害事件はファーストサーバーだけでなく、どのレンタルサーバー会社でも起こる可能性は０ではありません。

それが例え「さくらインターネット」・「ロリポップ」・「エックスサーバー」などの信頼と実績が十分なレンタルサーバーであっても同じです。

なぜなら、レンタルサーバーもそれに付随するサービスも人間が作ったものである以上、故障したり更新時に失敗する可能性は常にあるからです。

ですので、大規模な障害が発生した場合のリスクを最小限におさえるための備えを日頃からしておくことが大切です。

バックアップを取る癖をつける

大規模な障害が発生した場合のリスクを最小限におさえるための備えの1つとして。

サイトなどの更新を行ったらバックアップを取って、自分のパソコンやGoogleドライブなどに保存しておく癖をつけましょう。

今回のファーストサーバー障害事件のように、ユーザーがバックアップを取る暇もなくサービスが停止する事態もあります。

ですので、更新を行ったらバックアップを取って、利用しているレンタルサーバー以外の場所に保存しておくことが大切です。

移行先候補のレンタルサーバー会社を探しておく

今自分が使っているレンタルサーバーが1社だけの場合。

そのレンタルサーバー会社が障害を起こして利用できなくなる可能性も考えて、移行先候補のレンタルサーバー会社を事前に1社以上探しておきましょう。

移行先候補のレンタルサーバー会社を見つけておけば、今使っているレンタルサーバー会社で大規模障害が発生した時でもスムーズな移行ができるので焦らなくて済みます。

Zenlogicとの契約は控える

今回の障害事件はひとまず終息しましたが、レンタルサーバーというものは1年～2年くらいは安定稼動していないと信用することはできません。

ですので、Zenlogicとの契約は最低でも1年半後となる2020年までは利用を控えるのが、レンタルサーバーを利用する上での最大のリスク回避になります。

まとめ

今回のファーストサーバーの大規模障害は3日間のサービス停止という、国内のレンタルサーバーにおいては類を見ない最悪レベルの障害となり、Zenlogicを利用していたユーザーは月額費用の返金程度はとうてい取り戻せない大損害を受けることになりました。

今回、被害を受けたZenlogicのユーザーは嫌というほどレンタルサーバーを借りる上でのリスクを感じ、既にリスク回避を実践されているかと思います。

しかし、Zenlogic以外のレンタルサーバーを利用しているユーザーであっても、今回の障害事件からレンタルサーバーにおけるリスクを改めて認識して。

サイトを更新したらバックアップを取る、移行先のレンタルサーバー会社を事前に探してキープしておくなど。障害が発生したときのリスク回避の備えをしておくことが、レンタルサーバーを利用していく上で非常に大切なことではないかと僕は思います。

この記事はここまです。

最後まで読んで頂きありがとうございました。