Zenlogicの障害から学ぶべきこと

ネット界隈騒然とした今回のZenlogicの障害、ほぼ復旧したようで良かったです。復旧に全力を向けておられたエンジニアの皆さん、大変お疲れ様でした。連日ホント大変だったと思います。

さて、今回の障害で、

• Webサイトが見えなくなった！
• サーバからデータを取得できない！
• メールも使えない！

など、阿鼻叫喚の声が聞かれましたが、他社に移ってハイ終了！もうZenlogicなんて使わない！とか、今回は長かったけど次は大丈夫だろう…と言って終わりにすべきではないでしょう。

落ちたから引っ越す。復旧したから次回は無いことを祈る。それでは何の学びもありません。アプリに必ずバグがあるように、サーバは必ずトラブルものだからです。

利用者として事前にできることは無かったか

いつもこう思うんですよね。

弊社では障害に巻き込まれた時、はらいせに解約とか、サーバ引越して完了とか、復旧まで耐えて次回がないことを祈るとか、そういう対応はやりません。何も変わらないので。そこから学びを得て手を打ちます。万が一、同じ障害がまた起こってもビクともしないように、すぐに復旧できるように。開発会社・サービス運営会社として当然です。

今回の Zenlogic 障害では、やっておけば業務停止にならなくて済んだのに…と思う点が幾つもあります。それをせず「落ちた！Zenlogic許さん！解約する！」というのはちょっと違うと思うんですね。

そこで今回、レンタルサーバにおんぶにだっこではなく、今回のような障害から受ける被害を最小限にする為の、防災・減災の策を2つ提言させて貰いたいと思います。

 

1. メールサーバは分離する

まず、Webサイトと同じサーバでメールを使うのはやめるべきです。今すぐに。

投資の格言「卵は一つの籠（かご）に盛るな」に学びましょう。1つのかご(サーバ)に卵(機能)を盛るから、障害時に道連れで全く何もできなくなるのです。役割で分けるのが良いです。

メール機能を分離する方法としてお勧めなのは以下3つ。

• A) GoogleのGSuite(Gmail)に移行
• B) さくらのメールボックスを使う
• C) Zoho Mail に移行

弊社は A) です。Gmailを会社のメールサーバとして10年以上使ってます。お客様にも御提案したり、最近は移行の御支援もしています。別にGoogleのパートナーでもなんでもなく、現時点でメールに関しては費用対効果が最も高い最高の選択肢だと思っているのでオススメしている次第。

Gmailは独自ドメインを割り当てることができ、自社のメールサーバとして使えます。何が良いかって、レンタルサーバが用意するメール機能を使うのとは桁違いに安全なこと。それは設定を見ても分かります。

$ dig feedtailor.jp MX +short
1 aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
10 aspmx2.googlemail.com.
10 aspmx3.googlemail.com.

これは、弊社の feedtailor.jp ドメインのメールサーバ設定を見ている様子ですが、小難しい説明をすっ飛ばして簡単に言うと、5重に冗長化されたgoogleのシステムに弊社宛のメールをさばいて貰っていることを意味します。メール機能を分離できるだけでなく5重に守られたメールサーバ。

これに対して、レンタルサーバのメール機能を使う場合、多くは1重です。そしてWebサイトと共存。

どちらが安心かは明白ですね。

今回、Zenlogic の障害で被害を被った有名所のひとつに歌舞伎座があります。サイトこそ Zenlogic だったため落ちてしまったようですが(障害報告)、彼らのメール環境はどうだったでしょうか。

$ dig kabuki-za.co.jp MX +short
10 aspmx.l.google.com.
30 aspmx2.googlemail.com.
20 alt2.aspmx.l.google.com.
20 alt1.aspmx.l.google.com.
30 aspmx3.googlemail.com.

G suite ですね。分離されています。恐らくZenlogicのサーバにはWebサイトの機能しか持たせていません。だから、今回の障害でWebサイトこそ落ちてしまいましたが、歌舞伎座の関係者全員がメールを使えなくなるという事態は避けれていた筈です。

G Suite は1メアドあたり月額500円かかりますが、これを安いと見るか高いと見るか。G Suite から受けられる恩恵はメールだけじゃないので僕は激安だと思いますが、それでもお金をかけたくないという方には別の選択肢があります。

再掲になりますが、

• A) GoogleのGSuite(Gmail)に移行
• B) さくらのメールボックスを使う
• C) Zoho Mail に移行

のうち、BかCのいずれかが良いです。Cなら10メアドまで無料。Bならメアド無制限で月額100円切ります。

要するに、メールもWebサイトも大事なので、同じサーバに盛るのではなく、サーバ分離しましょうということです。そして、できれば分離したメールサーバは多重化されてる方が安心ですよと。

 

2. Webサイトは静的化する

3年前ぐらいから、僕は全てのWebサイトは静的化すべきという持論を持っています。今やっている静的化サービス espar もその文脈で展開しています。

静的化とは、Wordpressを始めとするCMSサーバをそのまま公開するのではなく、全ページ html に変換して公開用の別サーバにページ郡をホスティングするという技術です。1クッション置くわけですね。ミラーリングということもあります。

(CMSサーバではアクセスを受け付けない。html化した先のサーバで受け付ける)

静的化されたサイトは障害に強い

静的化のメリットとして高速化やセキュリティ向上はよくあがりますが、実は障害に強い・復旧を超絶楽にする、というメリットもあります。今回のような障害が発生しても恐らく復旧に15分もかかりません。

なぜなら、静的化とは、ファイルをサーバに置くだけでサイトが機能する状態にする ということを意味しているからです。なので、サーバを新たに用意してファイルコピーで復旧完了です。障害対応フローは、下図のようになりますね。

1. Webサイトが落ちます
2. 別のサーバを起動します
3. 手元にあるhtml化したファイル群をコピーします
4. DNSを新しいサーバに向けます

以上で復旧完了です。あとはDNSの伝搬を待つだけ。簡単ですね？ちなみに2.の新サーバは、例えばさくらVPSならオンライン申込みで10分かかりません。AWSのEC2だと手作業でも2,3分。

肝は3の部分。これが面倒なので、2のサーバを常時用意しておいて、CMSから静的化を行い常に予備用サーバにコピーを行っておくということをします。そうすれば、障害復旧に要する時間は実質 4. だけです。爆速。こんな感じですね。

余談ながら今回の zenlogic の障害では、DNSの変更もできないなんて噂もありましたが、それに備えてAWSのRuote53をネームサーバとして予め指定することで回避も可能でしょう。

静的化の技術

重要なのは、上記の復旧フローの3.にあるhtml化したファイル群。これを作らなきゃいけません。

弊社の espar は静的化を含めたややこしいことを全部やりますよ、というサービスですが、何も静的化は弊社の専売特許ではなく他の選択肢が沢山あります。自社に最適なものを選ぶのがいいと思います。

WordPress を使っているなら、無料の StaticPress や Simply Static などのプラグインがありますし、Movable Type と公開用サーバを組み合わせても良いでしょう。また PowerCMS や NOREN など、静的化を前提にしたシステムもあります。

問い合わせや検索は？

問い合わせフォームやサイト内検索はどうする？という声も聞こえてきそうですが、今やもう2018年です。CMSに頼らずとも静的化されたページで実現できる技術が沢山あります。

• 問い合わせフォームを AWS Cognito/S3/Lambda/SES で作りなおした
• algoria
• kintone や spreadsheet とAPI連携
• ECを静的サイトで実現する為のライブラリ

こういったものを使えば、Webサイト全体を静的化できます。つまり、公開用サーバにはPHPもDBも何にもいりません。

CMSという複雑なシステムをそのままネットに公開するから復旧が遅くなる(または出来ない)のです。新しいサーバを用意するにしても、環境を作り、設定を行い、データベースを移行する。普通はできません。

CMSはそもそも「コンテンツ管理」だけが仕事です。「公開」という役割は分離すべきです。

今回の zenlogic 障害を教訓に、是非 Web サイトの静的化を真剣に考えてみられることをオススメします。これ以上の障害時対策はありません。なんせコピーして完了ですから。少し工夫すればDNS変更だけで復旧する環境にできます。ちょっと強力なスペックのサーバを借りるより、低めのスペックのサーバを2台かりて静的化したほうがずっとコストパフォーマンスも良いので、財布にも優しいです。

無論、全てのサイトにおいて静的化が万能という訳ではありません。ただ、個人的な感触では7,8割のサイトが静的化だけで十分です。

 

という訳で、障害に強い環境づくりの提言2つご紹介しました。

Webサイトやメールをお使いの企業や組織、またそういった方々を支援する制作会社さんにおかれましては、今回の障害で「Zenlogicからサーバを移転したら良い」と安直な選択で課題解決したと考えるのではなく、どうすれば障害が起こってもサービスを維持できるのか、どうすれば即座に復旧できる環境を作れるのか、という視点での見直しを図ってみられることをお勧めします。

失敗から学ぶことは沢山あります。解約やサーバの引越しは問題の先送りでしかありません。トラブルから学びを得て障害に強い環境を作っていきたいものです。