【プレミアム】ゼンロジック（Zenlogic）とGCPの障害から考えるウェブ担の必須サーバー知識（1） あとで読む

ゼンロジックサーバー障害の原因は何だったのか？

2018年6月19日から7月9日までのおおよそ20日間、ソフトバンクの子会社であるファーストサーバ社が提供するZenlogicサーバーに障害が発生しました。

同サーバーを使っていた政府や公共交通機関などのサイトやメールが停止してしまい、社会的にも大きな問題となりました。

直接の原因は「ストレージ障害」だが長期化は「設定ミス」がポイント

Zenlogicの公式サイトに本障害の報告書が出ています。

▼本障害の概要と原因についてのご報告
zenlogic.jp/news/status/syogai/cause/

結論からいうと、直接の原因は「ストレージ障害」です。 しかし、なぜ20日間という長期間ほぼ停止してしまう状況になってしまったかというと、そのポイントは「設定ミス」であったとあります。つまり二次災害だったのですね。

流れとしては、下記のようです。

1. 6月に入りストレージシステムが高負荷になってきた（この時点でパフォーマンスは一部悪化）
2. そこで、ストレージシステムを高負荷にしていたプロセス（ネットワーク帯域を使ってしまう）に対し対処をしようと考えたが、その設定をミスしてしまった
3. システム全体がスローダウンしたため、物理的なストレージ増強や設定値変更などを行ったが、2の作業とバッティングしてしまい、結局時間がかかった

報告書の中には データ移動完了まで時間を要した とありますので、現在のストレージから増強した新しいストレージや別箇所にデータ移動を試みたのだろうと想定されます。この作業でさらに高負荷になったと思われますが、途中で止めてしまうと、データ消失の恐れがあるので、もうどうしようもなかったのだろうと考えられます。

じゃあそもそも、なぜ6月から高負荷になってしまったのかというと、2番の内容から想像するに、おそらく設置当初は気づかなかったプロセスのバグが発見され、その対処を間違ううちに、次々と問題に繋がっていったのだろうと推測します。

Google(Google App Engine)でも発生したサーバー障害

太平洋標準時で7月17日お昼ごろ、1時間程度にわたって発生したGoogleのサーバー障害も衝撃的でした。 幸い日本では早朝の出来事だったために、あまり大きな影響は及ばなかったようですが、世界中のポケモンGOや音楽ストリーミングサービスのSpotify、写真共有アプリのSnapchatが停止し、世界中の人が影響をうけました。

公式サイトに報告書が出ています。

▼Google Cloud Networking Incident No.18012
status.cloud.google.com/incident/cloud-networking/18012

上記によると、原因はロードバランサー（ネットワークのアクセス振り分けをする機器）に新機能を追加した際のバグだったそうです。 Zenlogicサーバーも最初のきっかけはバグだった可能性があることを考えると、その部分は似ているのかもしれません。

なぜ障害が発生してしまうのか

そもそも、なぜインフラ障害は発生してしまうのでしょうか。

※インフラ障害とは、レンタルサーバーなど基幹インフラの障害を指しますが、一般的には「サーバー障害」や「サーバーが停止した」といった表現もされるため、以降「サーバー」という言葉はインフラの意味でも使用します。

サーバー関連ソフトウェアのバグ

まず今回の問題に限っていうと、両者ともソフトウェアのバグがきっかけです。 特にクラウドサーバーは、裏で高機能なソフトウェアが動いていますので、レガシーなレンタルサーバーよりバグは発生しやすいかもしれません。

ZenlogicはYahoo!のサーバー管理チームが担当しているようです。 しかし仮にそのレベルだとしても、Googleだとしても、残念ながらソフトウェアのバグは発生してしまいます。

当然事前にテストはしているはずですが、本番使用されて条件が厳しくなると突然発生するバグもあり、基本的にソフトウェアのバグを100%防ぐことはできません。

人的な二次災害も怖い

その後、Zenlogicでは人的な設定ミスによる二次災害が発生してしまいました。 ここがGoogleと違うわけですが、設定ミスというと、ファーストサーバ社が2012年6月に起こした大規模障害も思い出されます。この時は、ストレージのデータを担当のミスにより消してしまうというものでした。

バグというきっかけは一緒だったとしても、その後に人的な災害を引き起こしたか否かで、Google社とファーストサーバ社には違いがあります。

「サーバーは難しい」ことが諸悪の根源

そもそも、サーバーエンジニアはハイレベルな総合力が求められる業種です。

なぜなら、根本的な部分では物理的なハードウェアの知識と、その上で動いているソフトウェアについての総合的な知識、および緊急事態に素早く対応できる論理的推察力も必要となるからです。

緊急病棟のお医者さんのようなものをイメージしてもらうと、普通の町医者とは違う仕事だというイメージがつきやすいのではないかと思います。つまり「サーバーは難しい」が故に「エンジニアはハイレベルが求められる」のです。

しかし、24時間サーバーを管理する場合に、そのような手練ればかりがちゃんと運用する体制を作ることは、とても難しいことです。 なぜなら、難しい作業をこなせる彼らは高給取りであるし、24時間体制で常時働かなくても仕事がたくさんあります。 そのような状況下において、さらに多くのサーバー会社は低価格を競う必要があるため、なかなか体制を完璧に整備することは難しいでしょう。

その結果、特に緊急時において適切な対処を素早く行っていくことは、思いのほか難しいのです。

どうすれば運営側のリスクヘッジができるか

たとえGoogleやAmazonなど、どんなサーバー会社であれ、裏では人がやっている作業であることは避けられません。 またサーバー会社の裏ではハードウェアとソフトウェアが稼働しており、必ずいつかは障害が発生することからも避けられません。

つまりヒューマンエラーやサーバー障害から逃れることはできないのです。 そうであれば、ウェブ担当者としては、最低限必須のサーバーに関する知識を身につけた上で、適切なリスク対処をしていくことが有効です。

そこで次回は、ウェブ担当者として必須のサーバー知識と、その知識を前提としたリスクヘッジについて考えたいと思います。