ネット界隈騒然とした今回の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からサーバを移転したら良い」と安直な選択で課題解決したと考えるのではなく、どうすれば障害が起こってもサービスを維持できるのか、どうすれば即座に復旧できる環境を作れるのか、という視点での見直しを図ってみられることをお勧めします。

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

上場企業オフィシャルサイトにおける常時SSL化対応状況レポートの6月版をお届けまします。調査条件は以下の通りです。

• 東京証券取引所が公開する2018年5月末時点の上場銘柄一覧から全上場企業3620社を抽出
• 2018年6月25日時点での全企業Webサイトで常時SSL化してるかどうかを判断

条件含めて、レポートの詳細はこちらをご覧下さい。

少しずつ青色領域が増えていますので良い傾向です。今回、対応サイトは 1.6%増 となりました。ここ3ヶ月は毎月約50,60社ずつ増えていってますので、恐らく来月には2000社達成となるでしょう。

自治体の常時SSL化対応状況の調査

常時SSL化調査のレポートをきっかけに今月は少し動きがありました。

一般財団法人日本情報経済社会推進協会(JIPDEC)さんから地方自治体のSSL/TLSサーバ証明書利用状況の調査結果を公表しましたというプレスリリースが出ています。

一般財団法人日本情報経済社会推進協会（所在地：東京都港区、会長：杉山　秀二、以下： JIPDEC）は、株式会社フィードテイラー（所在地：大阪府大阪市、代表者：大石 裕一、以下：フィードテイラー社）との共同調査により、全国の自治体サイト（都道府県と市区町村を合わせた全1,788団体）における常時SSL/TLS（以下、「常時SSL」）化の状況を調査したので、結果を発表します。

と書かれている通り共同調査です。他社様のプレスに自社がのるのは久しぶり。

昨年11月からやってる常時SSL化レポートをご覧頂いた先方様から連絡がありまして、先方の持ってる自治体URLの一覧で同様に調べてみましょうって事になりました。何ごともアウトプットすべきですね。何に繋がるか分からないものです。

それなりに反応もあったようで、ZDNetさんにも自治体サイトの「常時SSL化」率、トップは愛媛県というタイトルで取り上げられています。

面白いのは都道府県別の対応状況。愛媛県が1位なのは、恐らく、県内で自治体サイトを担当してる制作会社様の意識が高いからではないか…との推測だそうですよ。

だとしたら、証明書関係者はやっぱり制作会社様を啓蒙するっていう活動に注力しなくちゃいけないってことなんでしょうね。弊社も何かやっていきたいと思います。レポートを出し続けるのも活動の一環なので来月もまたレポート致します。

(所要時間:約4〜5分)

6/18の地震発生時、僕は大阪市北区のオフィスに、奥さんは同じ区内の自宅に、従業員もまだ自宅にいました。幸いオフィス内では本棚に置いてるiPadの空箱が落ちたぐらいでした。

停電もなく社内サーバ含むインフラはびくともせず被害は皆無。揺れが落ち着いて真っ先に、LINEで家族の安否を確認、更にslackで従業員の安否確認を行いました。

有事の際のオフィシャル情報

無事が確認できて安堵。次は、next action を行う為に必要な情報収集です。幸い、オフィスのiMacの前だったのでググって検索しました。

早々に直面した問題が、一部のサイトはトラブっててほぼ使いものにならなかったってこと。サイトが激重状態ならまだしも 503 エラーでサイトが落ちてるサイトもあり、情報を得られないもどかしさに当事者として大変困惑しました。緊急時にこそオフィシャルの情報が必要なのに…と。

行政、鉄道、バス、ガス、電気、水道、消防、

有事の際は、様々な種類のオフィシャル情報が欲しくなります。しかし、肝心のWebサイトが不調な所がちょいちょいありました。僕は仕方なく、Twitterの断片的情報を元に判断。(大阪メトロがもう復旧したという嘘の情報もありました)

本日は特別休業にしました。

自然災害時は定めがなければ、強制で有給消化させたり、No Work No Pay の原則を適用する例もあるようですが、特別有給休暇を特別付与する扱いで。(一切何も変わらない)

と言いながら、社長の僕は変わらず仕事中ですのでメール返信等やります :-)

— yuichi oishi (@oishi) 2018年6月18日

結局、このあと臨時休業に切り替え、更に今週はリモートワークのみとすることを決めました。3月から働き方をリモート主体に切り替えていたのも奏功し、業務の停止は基本的にありません。

それはともかく、やはり有事にオフィシャル情報をサイトから得られない・得にくい状況はなんとかして欲しいと思います。以下に紹介するのは、当日10時〜11時頃の行政・インフラ系サイトの状態。地震発生から約2,3時間後の記録です。開発者向けツール等で詳細を見ましたが、改善できそうなポイントは各社それぞれですが幾つか見えました。

大阪市

直後から 軽量版 なるページに切り替わっていて、対応が素晴らしかった大阪市のサイト。

(地震直後の大阪市サイトの軽量版。TOPにアクセスしようとするとこちらに誘導される)

しかし「軽量」とはいえ、体感で普通に遅かったです。5秒とか。10秒とか。

何が原因かと Chrome の Developer Tools を使って見たところ、htmlの生成に3,4秒を要してしまっていました。「このページくれ！」とサーバに伝わってから「あいよ！」とページを返してくれるまでの時間(専門用語でTTFBと言います。参考)に、3,4秒は待たせてるってことですね。

正直、Webの世界ではだいぶ遅いです。サクサク感とはほど遠い。

軽量版と言うぐらいだから、静的ページ(htmlファイル直置き)なのかな？とも思いましたが、TTFBに3,4秒を要するのは明らかにおかしい。静的ページなら普通は100〜500ミリ秒とかで余裕で返ってきますから。

大阪市は平成28年に新たなCMSを使ってサイトリニューアルをしていて、恐らく当該のCMSで転送容量が小さくなるページを用意、CMSサーバが頑張っていたのだとは思います。それか、静的な配信だけどサーバの設定がおかしいか…ですね。

軽量版という発想は素晴らしいと思いますが、転送容量が小さいだけでは負荷対策として不十分です。有事の時こそ最低でもTTFBは100ミリ秒以下であって欲しい。ページ全体でも1,2秒で返して欲しいところです。市のサイトは消防や水道のページも内包してますから尚更ですね。ですから、サイトの静的化を検討するか、既にしているなら明らかに遅いのでサーバの設定等を見直すべきだと思いました。

大阪メトロ

時間も時間だっただけに多くの人が殺到したであろうサイト。

(画像の取得に失敗してメニュー部分がロゴしか出ていない)

ページのhtml取得に20秒近くかかってました。こちらは大阪市のTTFBが長いのとは違い、接続すらままならない状況。Initial Connetion(画面下部のバーのオレンジ色部分)の値が大きく、接続確立にまず時間がかかっていました。

大阪メトロのサイトは、サーバからネットに抜ける上流回線に余りお金をかけてなさそうに見えます。今回の事態を教訓に是非とも回線/帯域をしっかり検討して貰いたいと思いました。だいぶ改善される筈ですから。

同じことを思ってたようで、さくらインターネットの田中社長が地震直後にこんなtweetをしてました。

大阪メトロのサイトが、アクセス多すぎて繋がらない。
すぐに、さくらインターネットへ乗り換えてもらいたい。
地下鉄は大阪企業のインフラだし、安くでもなんでもするので、ちゃんとサポートするから、とにかく災害時こそサイトは止めないでおいて欲しい。

— 田中邦裕 (@kunihirotanaka) 2018年6月17日

だそうなので、さくらのクラウドにサーバを設置してネットワークは回線太めの契約をされると良いかと。国内で有事のトラフィックに加えお金も気になる場合、さくらさんは良いチョイスだと思います。弊社も使わせて貰ってますが、従量課金のAWSとは安心感の次元が違います。

ちなみに他の大阪府内主要私鉄、阪急・阪神・近鉄・南海・京阪の各サイトはいずれもビクともしてませんでした。至って平常運転、さすがです。

大阪メトロはこの4月に民営化されたばかりってのもあり、webサイトへの投資はまだまだこれからなのかも知れません。Web関連に投資する時は、まず上流回線の見直しをお願いします。

大阪ガス

ほぼほぼガスが停止されていたこともあり、メトロ以上のアクセスが長時間続いた可能性もあります。想像以上のアクセスにCMSサーバが耐えられなくなったのか、

このようにダウンしちゃってました。ただ、リロードしたら表示されて、また上図のエラー画面に戻って…と特徴的な表示切り替えも発生してました。表示された瞬間はこんな感じで。

(表示されることもあったが、CSSが読めずに崩れてしまっていた。この表示でさえ数十秒かかっていた)

見えたり見えなかったり。恐らく複数台でロードバランスして運用しているうちの1台が死んでいるような状況だったのでしょう。

ロードバランスして複数台CMS運用するぐらいなら、アクセス集中しやすいページだけを静的化してロードバランスしたフロントに配備、それ以外をバックに控えたCMSにプロキシするってのが良いでしょうね。きちんと構成すれば、ある程度の攻撃対策にもなるので一石二鳥です。

関西電力

恐らく問題ないだろうと思いながら確認したのが、関西電力のページ。

ちょっとしたご縁で、関電のサイトが少し前から(?) 静的化 に特徴を持つ専用CMSを導入しているのは知っていました(かなり高いですが…)。導入事例として公開もされてます。

弊社もWebサイトは静的化推進派で、実際、静的化による爆速化と負荷対策をさせて貰ってますので静的化の効果を日々実感してる立場です。だから、同じ静的化という意味で、関西電力のサイトは相当アクセスがあっても(一時17万戸が停電していた)、絶対に落ちてないし遅くもなってないと確信してました。

案の定、ビクともしておらずTTFBは常に数十ミリ秒の高水準。今回、電気関係のオフィシャル情報を求めてサイト閲覧で困った人は皆無だった筈です。当事者であった僕もその一人。

止まってはいけないWebサイト

今回、当事者となって改めて感じましたが、公的インフラを支える企業のサイトは、有事の時こそ止まってはいけないWebサイトなのだと思います。

この業界で仕事をさせて貰ってるので、止めないことが如何に難しいかは重々承知の上です。それを承知の上で…ですが、やっぱり止めてはいけないです。遅くなってもいけません。そして万が一、そのような状態になってもすぐに復旧できるようにしておくべきです。

なぜなら、有事にオフィシャルな情報を最短で得られれば、地域住民の安心感は少なからず高まるし、人々の行動は最短で最適化されるからです。それが、本当に困った人向けに公的リソースが配分されることにも繋がる筈です。

弊社は最近、Webサイトの高速化・負荷分散・可用性確保という課題に、静的化という切り口でお応えする事業をしているだけに、今回の体験は非常に考えさせられました。

国内の地震は活動期に入っている、誰もがそう思ってます。全国例外なく今回の大阪と全く同じ状況になりえます。例外はありません。

したがって、全国の都道府県市区町村や、各地域のインフラを支える企業におかれましては、「地域住民のため」を言うのであれば、Webサイトの静的化と上流回線見直しを検討し、止まらないサイト作りを目指されることを強く推奨します。一人一台スマホ時代。有事にWebサイトへ膨大なアクセスが集中しない訳がないからです。できれば物理的な位置でも冗長化をする Disaster Recovery も検討されると良いのではないかと思います。

大阪では、特定の地域に限られるものの依然として地震の影響が残っています。被害にあわれた皆さまにお悔やみ・お見舞いを申し上げます。生活インフラの復旧に身骨を砕かれる関係者の皆さまに感謝すると共に、未復旧地域の一刻も早い回復を願う次第です。また、一個人として一事業主として、何ができるだろうかと考え続け行動に移していきたいと思っています。

(所要時間 : 約1〜2分)

毎月恒例の上場企業の常時SSL化対応レポート2018年5月版をお送りします。今回で6回目。早いものでもう半年続けていることになります。継続は力なりなのか、レポートを見ましたよ〜と問い合わせを頂く事もあって、今後常時SSL化関連で新しいことを始めれそうな予感です。

例によって調査の内容は以下の通り。

• 東京証券取引所が公開する2018年3月末時点の上場銘柄一覧から全上場企業3618社を抽出
• 2018年5月21日時点での全企業Webサイトで常時SSL化してるかどうかを判断

というルールです。上場会社は毎月増えていってます。調査日が少しブレるのは弊社都合ですが、いずれ完全自動化して毎月3営業日目とかにする予定です。

さて、前回はめでたく常時SSL化対応が50%を越えましたが、今回はどれぐらい増えたでしょうか。

今月は上記の通り。先月から1.4ポイント増えています。先月の1.7ポイント増につぐ増加率で、なかなか良い感じです。あと、対応企業が1900社 を越えました。素晴らしい。是非この勢いが収まることなく、いやむしろ加速する勢いで！、各社様におかれましては進めて頂きたいと思います。

次のマイルストーンは2000社越えですかね。あと95社なので2,3ヶ月後ぐらいには達成でしょう。

崖っぷちに追い詰められる前に

ネット界隈をwatchしてますと、常時SSL化のニュースを見ることが増えてきました。時間ないですからね、もうホントに。

かねてより2018年7月から、ブラウザシェア3,4割を占める Chrome では、常時SSL化対応していなければ「Not Secure」と表示されるようになるとしていましあが、更に2018年10月のChrome70では、「Not Secure」が赤色表示になることも明らかになっています。

(Marking HTTP As Non-Secureより引用)

パスワード欄とかに限らず、chromeで http ページの入力欄に何かを入力すると、問答無用に赤色で Not Secure と表示されるようになります。日本語だと赤色で 保護されていない通信 です。

こんな感じ。入力欄であれば全部該当しますので、特にTOPページに検索窓を置いているサイトは早々に常時SSL化したほうが良いですね。もっと見たいなぁと思ってキーワード入力した閲覧者に、ウチは不信なサイトですと言っちゃうようなものですから。

そしていずれ、httpサイトであれば無条件に上図のような表示になるそうです。詳しい計画はこちらのリンク先をご覧頂ければと。

という訳で常時SSL化の5月度レポートでした。また来月もレポート致します。

(所要時間 : 約1〜2分)

恒例となりました上場企業の常時SSL化対応状況調査レポート、5回目の調査となる2018年4月版をお届けします。調査は至ってシンプル。

• 東京証券取引所が公開する2018年3月末時点の上場銘柄一覧から全上場企業3609社を抽出
• 2018年4月11時点での全企業Webサイトで常時SSL化してるかどうかを判断

というルールで統計を取ったものです。11日というのは単に弊社都合です。ホントは毎月決まった日が良いのですけどね。

さて、今回はなんと言っても！！！ででんっ。

(遂に半分を超えた！)

上場会社の常時SSL化対応サイトが半数を超えたということでしょう。いぁ実にめでたい！

調査開始した2017年12月時点で4割台だった頃から考えると、上場企業様や制作会社様の意識も向上してきてるのだと思います。常時SSL化推進派としては純粋に嬉しい結果です。願わくば数年のうちに対応サイトが100%になりますように。上場企業なのですから、情報発信側として身元ぐらい明らかにして貰いたいものです。

レポートでは例によって、業種ごと(17分類/33分類)や、証明書の種類ごとに統計を細かく取っていますので、詳しいことはレポートページをご覧下さい。過去分も見れます。

(Thanks! the photo on flickr by Dennis Skley / CC BY-ND 2.0)

さて、あと3ヶ月もすればChrome68の配布が始まって、ChromeでHTTPサイトを表示すると即座に注意喚起がされるようになります。こんな感じ。

(HTTPサイトは表示するだけで、このような表示になる)

そのことを知ってか知らずか、はたまた知ってるが無視しているのか、諸事情で対応できないのか…。7月にどれぐらいの上場企業が重い腰を上げるかが気になりますね。

どうせ対応しなくちゃならないので早いほうが良いです。既存サイトの常時SSL化はホント大変ですし。

もし常時SSL化でお悩みのようでしたら、DNSを切り替えるだけで常時SSL化が済んでしまう弊社 espar がおすすめです。手前味噌ですが(笑) どんな選択肢よりも作業負荷が少なく且つスピーディに常時SSL化できることをお約束します。

どさくさ紛れて最後に宣伝でしたね。来月もまたレポート致します。