大谷イビサのIT業界物見遊山 第27回

改めて浮き彫りになるストレージ設計と事業者連携の難しさ

ファーストサーバはなぜ2度目の障害を起こしたのか？

　ファーストサーバのクラウド型レンタルサーバー「Zenlogic」が4日間に渡って全面停止した。2018年2月時点のZenlogicのユーザー数は中小企業や官公庁など約2万社とされており、4日間のサービス停止は影響も大きい。2012年6月の大規模障害を受けて、再発防止策を講じた同社がなぜ再び障害を起こしたのだろうか？

サービスの全面停止でユーザーの阿鼻叫喚があふれる

　4日間に渡ってサービスが全面停止した今回のファーストサーバの障害を受け、ネット上ではZenlogicユーザーの阿鼻叫喚であふれている。会社の顔であるコーポレートサイトが消えた会社、商売が続けられなくなった通販サイト、メールやWebが利用できる上司から詰められる担当者の声などなど。同社の問い合わせ窓口に問い合わせが殺到し、つながりにくい状態が続いていることもあり、怨嗟の声は止まらない。

　まずは事故の経緯を追ってみよう。

• 2018年6月19日（火）：午前9時15分からZenlogicホスティングのサービスの一部において、メールの送受信やWebサイトの閲覧、サーバへのファイル転送ができないなどの障害が断続的に発生。ストレージへの高負荷が発生していたため、7月6日（金）までの間、クラウド基盤を管理するヤフーにてシステムの増設やパラメータ変更などを実施したが、7月6日の時点で障害が解消せず。
• 7月6日（金）：午後8時から障害対象のサービスを全面停止し、7月9日までメンテナンスを実施。
• 7月9日（月）：メンテナンス完了予定の午前8時を過ぎても、高負荷な状態だったため、メンテナンスは続行。午後10時20分に「再び高負荷状態になった場合には、サービスを停止する場合がある」という条件付きでサービス再開。
• 7月10日（火）：午前11時時点で安定稼働を確認
• 7月17日（火）：午前8時30分、「6月19日より発生した高負荷障害に関するご報告」を公開

　ちなみに、アスキーでサービス全面停止を記事化したのは、メンテナンスが予定通り終了せず、プレスリリースが出された7月9日の夕方。その後、7月10日にはメンテナンスが終了し、安定稼働が確認されていると発表されている。また、7月17日（火）には「6月19日より発生した高負荷障害に関するご報告」が公開されるとともに、障害期間中の利用料金が既存の品質保証制度(SLA)の基準とは別の基準で返金する旨が通知されている。

アキレス腱「ストレージ」で多くの事業者はつまづく

　ご存じの通り、ファーストサーバは2012年6月に大規模な顧客データ削除の事故を起こしている。そして、事故から2年後に総括と再発防止の取材記事を書いたのはほかならぬ私である。そういった立場もあり、今回の事故に関する気持ちは複雑だ。「あんなに再発防止策を講じていたのに、なぜ？」という気持ちが正直だが、「あのときの取材に問題はなかったのだろうか？」という自責の念もある。

■関連記事

• データ消失事故から2年！ファーストサーバ、再生への第一歩

　なぜ事故は再発したのだろうか？　一連の情報をあたってみて感じたのは、やはりクラウドサービスにおけるストレージ設計の難しさだ。今回の障害も「ストレージシステムのキャパシティプランでの想定を上回る負荷上昇による一時的な高負荷状態」と説明されており、6月19日以降にパラメータ変更やサーバーの増強などさまざまな対策が施されたものの、功を奏することなく、サービスの全面停止に至っている。

　データを格納するストレージは、クラウドにおけるアキレス腱である。絶対に消失してはならないユーザーデータを安全に保管し、安定した性能でサーバーが利用できるようシステムを設計する必要がある。もちろん、ストレージ自体を冗長化したり、バックアップを何重にもとることで、信頼性や可用性は確保できるが、コストは無尽蔵にかけられるわけではない。また、クラウドサービスとして提供している限り、ユーザーやデータ、アクセスの増加などに耐えうる拡張性も確保しなければならない。リソースを共用することで、割り勘効果を出すクラウドにおいては、信頼性、可用性、コスト、拡張性などさまざまな要件を同時に満たすストレージの設計と安定運用は困難を極める。

　実際、国内外問わず、多くの事業者がこのストレージの設計に頭を悩ませ、過去にさまざまな障害を起こしてきた。多くのWebサービスが影響を受けた2017年3月のAmazon S3の大規模障害は記憶に新しいし、2017年9月にはさくらインターネット、2018年1月には富士通クラウドテクノロジーズのニフクラ、2月にはGMOクラウドがそれぞれストレージ障害を起こしている。過去をさかのぼれば、規模の大小を問わず、ストレージ障害に見舞われていない事業者の方が少ないとすら言える。

　裏を返せば、AWSがここまで台頭した要因の1つは、10年以上の実績を持つAmazon S3の安定性がエンジニアの高い評価を得たからだと思っている。設計や運用に失敗すればサービスの信頼を失わせ、きちんと実績を重ねていけばユーザーを引きつける「諸刃の刃」となるのが、クラウドサービスにおけるストレージだ。

クラウド基盤を担当するヤフーとの連携に問題はなかったのか？

　もう1つ指摘しておきたいのは、ファーストサーバとヤフーとの連携に問題はなかったのか？という点だ。個人のFacebookコメントで気がついたことだが、Zenlogicはサービス開始当初から毎月のように障害が発生しており、その原因も高負荷やストレージ障害が多かった。つまり、ファーストサーバからすれば、今回の障害は十分予見できたはずで、さらに言えばシステム設計自体が根本的に間違っていた可能性が高いわけだ。

　振り返ってみればZenlogicは前回の大規模障害を受けて、インフラをヤフーに任せるという形でスタートしている。つまり、ハードウェアを含めたクラウド基盤はヤフーが設計・運用しており、サービスを開発するファーストサーバ側と一定の責任分界点で担当領域を分けていたはずなのだ。こうした役割分担の中で起こった今回の障害だけに、両社の連携ミスや齟齬が長期的に起こっていたと推測されてもおかしくないだろう。折しも2018年3月に、ファーストサーバの親会社はクラウド基盤を提供していたヤフーから、ソフトバンクグループに移っている。親の母屋を借りて商売していたのが、いわば叔父の母屋に移ったわけで、以前に比べて連携が希薄になったのでは？と考えるのはそれほど論理の飛躍でもないはずだ。

　今回のファーストサーバの障害も年に何回か起こるクラウド障害の1つではあるが、2度目の大規模障害という点が他社と大きく異なっている。あれほど大きな障害の後でもついてきた顧客の期待を裏切ってしまったわけで、厳しい言い方になるが、やはり2度目はない。同社の事業に大きな影響を与えるのは避けられないだろう。

　一方、ここまで書いておきながら、再起記事を担当した者としてファーストサーバを応援したいという気持ちもある。どのような結果になるにせよ、最後までユーザーに対して誠意のある対応を貫いてほしい。そして、他山の石とするためにも、障害がなぜ起こったのか、顧客対応やクラウド事業者との連携に問題はなかったのか、いずれ聞いてみたいと思う。

■関連サイト

• ファーストサーバ