トップページ > ストック > 【プレミアム】ゼンロジック（Zenlogic）とGCPの障害から考えるウェブ担の必須サーバー知識（3）

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

2018-10-05 ：事務局

ZenlogicサーバーやGoogleサーバー（GCPの中のGAE）に発生した障害から、ウェブ担当者として最低限知っておきたいサーバーの知識と、サービスを継続するための対処方法を考えます。第三話では具体的な準備や設定方法をお伝えします。

前回まで、サーバー障害によるサービス停止リスクをなるべく下げるため、良いサーバー会社を選ぶ方法などをお伝えしました。

しかしそうはいっても、「障害は発生するもの」というのも、お伝えした通り。

最終回の今回は、万が一障害が発生してしまった時の対応手順についてご説明します。

最初に知っておくべきこと

そもそもですが、サーバー障害が発生した場合、あなたの会社にとって“何”が問題になるのでしょうか？言われてみると考えたことがない、という人が多いのではないではないかと思います。

万が一の時、素早くサービスを復旧するために最初に知るべきことは、「誰に何の影響があるのか？」を事前に考えておくことです。やったことがない人は、せっかくなので今から一緒に考えてみましょう。

とはいえ、難しいことはありません。基本として抑えたいのは下記の３つ。

ウェブサイトを閲覧しているユーザーへの影響
社内システム（メールなど）に対する影響
GoogleやFacebookなど外部サービスへの影響

ぜひ事前に想定し、「なんとなくの損失額」まで想定しておくことがオススメです。

以下、上記を検討済みという前提で、サーバー障害時に時系列でどのように対応するかをお伝えします。

事前準備

まず、障害に備えて事前準備をしましょう。このとき、どこまで準備をすべきかは組織によって違います。

先にお伝えしたようにサービス停止時の損失見込額でとるべき対応も変わり、基本的にはWeb用のスタンバイ機と、メール用のスタンバイ機の2つを考えておきます。

Web用スタンバイ機の事前準備

1時間の停止あたり数十万円〜数百万円の損失が見込まれる場合

サービスを停止させないための代替機（スタンバイ機）を用意することが多いでしょう。

一般的には同じサーバーを２台契約し、データベースサーバーを共通化し、ロードバランサーで負荷分散をします。また、サーバーの冗長化や、ディザスタリカバリといった対応をとります。

この作業は、上記の言葉がわかるインフラエンジニアや企業と契約して進めましょう。1時間あたり数十万円からの損失がでるようなサービスであれば、万が一の時に相談できるインフラエンジニアがいないのは非常に危険です。

サポートできる企業を探したい場合は、「AWS 運用保守大阪」などと検索すれば出てきます。

1時間停止しても損失が数万円程度と小さい場合

安くても他のサーバーの間借りでもよいので、できればスタンバイ機を用意しましょう。一番の目的は、障害発生時に切り替えて「障害が発生し、サービスが停止している」ことを外部に正しく伝えるためです。また今回のZenlogicのように万が一障害が長引く場合は、キャンペーンページだけHTMLで自作するなど臨機応変な対応が可能です。

スタンバイ機の用意は下記手順で進めます。（以下、webtan-tsushin.comのスタンバイ機を作るという想定でお伝えします）

サーバーを借ります。できれば既存サーバーとは違う会社、もしくは別リージョン（別の場所）のサーバーを借りましょう。
ヘルプを見ながら、通常通りwebtan-tsushin.comとしてドメインのセットアップをしていきます。
例）エックスサーバーにおけるマルチドメインの設定方法　※ドメインは新規取得しなくてOK
www.xserver.ne.jp/manual/man_domain_setting.php
ただし2の作業でhttpsの新規セットアップは通常できません。理由は、SSLサーバー証明書をインストールするには、そのサーバーがwebtan-tsushin.comであることを証明しなくてはいけませんが、webtan-tsushin.comは通常本番サーバーに繋がり、スタンバイ機には繋がらないため、スタンバイ機を証明することができないからです。
この対策は３つありますが、そもそも暫定対応ページなのでhttpで運用するのがオススメです。
- httpで運用する（楽なのでオススメ！）
- 既存で使用しているサーバー証明書をインストールしておく（オススメだけど要インフラ知識）
- 夜間などに本番とスタンバイを切り替えてインストールする（知識はそれほどいらないがメンドクサイ）
3の設定が完了したら、障害発生の告知用のHTMLファイルを作成し、Googleアナリティクスのタグ（本番と同じもの）を設置して、FTPでアップロードします。ファイル名は何でもOK。その後、サーバーの設定ファイル（.htaccessなど）に503エラードキュメントとして設定を記載します。
例）Web サイトのメンテナンス中画面の出し方 -dogmap.jp
dogmap.jp/2014/03/28/web-maintenance/

以上で準備は完了です。

スタンバイ機はどのレベルで準備すべきか？

せっかくスタンバイ機が用意できるなら、503暫定ページではなく、本番と同様のセットアップをした方がよいのではないか？と考える人もいるでしょう。

しかし、サイトのタイプにもよりますが、それは労力の割に合わないことが多いです。それはなぜか。そもそもサーバーが1日以上停止する可能性がとても低いからです。仮に３日間停止するとして損失額を計算すると面白いことがわかります。実際にやってみましょう。

例) サービス停止1日の最大損失額20万円 x 3日停止する発生確率0.002% x 3日間 = 1200円

1200円のために、スタンバイ機を本番状態にする（つまりシステムや情報を最新状態に保つ）ための大変な作業をすべきか？というと、ほとんどの人がNOだと思います。

ですから、シンプルで手間がかからないなら別ですが、それ以外は「今サーバー障害中です」という暫定告知でよいと割り切った方が割にあいますし、そもそも3日以上停止しそうなサーバー会社からは、さっさと乗り換える投資をした方が一番の対策になります。

バックアップは必ず取得する

スタンバイ機の用意にかかわらず、本番データのバックアップは必ず定期的（できれば毎日）に取得しましょう。

スタンバイ機で暫定告知をするにしても何にしても、最新データを失ってしまうと、復旧作業は大変時間がかかることが多いのです。最悪、人の記憶に頼るしかなくなります。

WordPressであればバックアップ専門プラグインもありますし、サーバーによってバックアップサービスがついているものも多いです。またFTPによる手動バックアップでも良いでしょう。とにかく定期的に取得しましょう。

メール用スタンバイ機の事前準備

そもそもメールサーバーって何？

メールサーバーとは、メールの送受信ソフトがインストールされたマシンのことを指します。

レンタルサーバー会社によってウェブサーバーと同じマシンにインストールされていることもあれば、別マシンにインストールされていることもあります。

同じマシンにインストールされているかどうかは、以下のサイトでドメイン名をいれてみるとわかります。

seo.atompro.net/webtoolfree_mxrchk_.html

別ドメイン名が表示されれば別マシン、そうじゃなければ同じマシンにインストールされています。

同じマシンだった場合は？

さくらサーバーなど、メールサーバーとウェブサーバーを分けることができるレンタルサーバー屋さんもあります。

knowledge.sakura.ad.jp/4604/

こういった場合、メールサーバーに関するマニュアルがしっかりしているかが一つのポイントになります。なぜなら、万が一障害が発生した場合、メールサーバーをなおすのはエンジニアでないと難しいからです。

結局メールサーバーはどう用意すべきか？

私自身は、メールサーバーはあまり深く考えず、レンタルサーバー会社が標準で用意しているものか、有料にはなりますが障害に強いGoogleのGSuiteを使うのがよいのではないかと考えます。

なぜなら、先にも記載しましたが「メールサーバーの独自セットアップはエンジニアでないと難しいし、データー同期の問題があるので運用後に変更することも難しい」からです。

インフラエンジニアがいない場合にメールサーバーを分けたいならば、情報がたくさん出ていて安心できるサービス≒GSuiteを最初から活用した方がわかりやすいでしょう。

もしくは標準のメールサービスを使っておいて、後述するGmailなどのバックアップ手段をもつ方がはるかにコストも安くすみます。

メール用スタンバイ機の準備について

メールのスタンバイ機の用意はほぼ不可能だと考えましょう。スタンバイ状態では受信ボックスやアカウントのデータ同期ができないので、スタンバイの役目を果たさないからです。

考え方をかえよう！障害時に何が問題なのか？

そもそも本番やスタンバイのメールサーバーの用意が難しい以上、考え方をかえる必要があります。

障害がおこった時、一番よくないのは「メールを送ったのに返事がない」とお客様が感じてしまうことです。最悪「メールが消えてしまう」という問題も発生しますが、その場合も再送をお願いすればよいので、やはり大切なのは「障害時はそもそもお客さんにメールを送らせない」ということです。

したがって、ウェブ担当者が一番に考えるべきは「どのように障害をお客様に告知すべきか？」という点です。

障害告知のための事前準備

障害が発生した場合も、下記が動いていれば様々に障害告知が可能です。

電話
Web用のスタンバイ機
メール送信サーバー
FacebookやTwitterなどのSNS

特にTwitterは連絡窓口として侮れないので活用しましょう。

個人のGmailをバックアップとして活用する

またメール送信サーバーも、会社のセキュリティポリシーが許せばGmailの送信サーバーを使えるようにしておくと便利です。普段からGmailでも受信しておくと、万が一の時にもデータが消えずにすみます。

Gmailで会社のメールをセットアップする方法はこちらが詳しいです。

▼意外と知らないGmail！外部メールをGmailで送受信する方法 – tanweb.net
tanweb.net/2016/05/07/8229/

Gmailをシステムからの臨時送信だけに使ってもＯＫ

会社の代表的なアカウントを１つだけGmailで作成しておき、万が一の時はシステムからのメール送信をそちらに切り替える方法もあります。万が一返信されてもそのGmailアドレスであれば受信もできますので、一石二鳥です。ECサイトなどを提供している時には便利だと思います。

問い合わせ対応が必須であれば、専用のメール問い合わせ管理サービスを使っても良いでしょう。

本番Webサーバーに503ページを用意する

本番サーバーにも503ページだけ用意しておきましょう。万が一の時はそちらのページが表示されます。

例）Web サイトのメンテナンス中画面の出し方 -dogmap.jp

dogmap.jp/2014/03/28/web-maintenance/

サービス停止時の具体的な対応手順(5step)

事前準備が終わったところで、ここからは、サービス停止の検知から対応策までの手順をお伝えします。

【1】サービス停止の検知

サービス停止を知る経路は様々だと思いますが、できればユーザーからのクレーム連絡で知るのは避けたいところです。

大企業でIT部門を保有している会社ではモニタリング（監視）という業務があり、監視ソフトウェアなどに費用を投じていますが、一般的な中小企業であれば、ウェブ担当者がその役割を兼任していることが多いと思います。

予算が潤沢ではない中小企業のウェブ担当者にオススメなのは、Googleアナリティクスをフル活用することです。
下記のようにすることで、障害発生時に気づける確率がぐっと上がるでしょう。

【業務時間内】

Googleアナリティクスのリアルタイムレポートを余っているパソコンで常時表示しておく。

【時間外】

Googleアナリティクスのカスタムアラートで、アクセス数が20%以上変動したらメールを飛ばすようにする。

▼カスタムアラート
support.google.com/analytics/answer/1033021?hl=ja

メールなど社内システム障害の検知

社内システムの障害については、社内の誰かが気づくパターンが大半です。
あまり神経質にならず連絡が来てから対処を考えるので良いでしょう。

【2】障害発生時の初動調査

障害がどこで発生しているのか調査をしていきます。障害発生箇所を知れば、そちらの会社に問い合わせることや復旧方法や告知内容を検討することができるからです。

なお、サーバー調査に慣れている方は、下記以外の項目も調査して障害の原因を探りましょう。

1.ウェブサイトを閲覧しているユーザーへの影響

ウェブサイト閲覧者への影響範囲を調べます。
運営しているサイトごとに以下の観点で調べると良いでしょう。

共通

サーバー会社からのメールや連絡は来ているかどうか
電話サポートがあれば自分から電話した方がよい
FTPは使えるかどうか

コーポレートサイト

サイトが表示できるかどうか
問い合わせフォームが稼働するかどうか

ECサイト

サイトが表示できるかどうか
問い合わせフォームが稼働するかどうか
決済フォームは表示できるかどうか
ECシステムにログインできるかどうか？
決済システムにログインできるかどうか？

2.社内システム（メールなど）に対する影響

社内システムのトラブル時は、特に社外の人へのアナウンスがポイントになります。
個別には電話やメールで連絡をとり、公にはウェブサイトで障害を告知することがほとんどでしょう。

従って、まずメールが稼働するかどうかを調べましょう。
レンタルサーバー障害が発生すると、メールが停止することも多いからです。

社外にメールを送信できるか？
社外からメール受信できるかどうか
社内から社内へメール送受信できるかどうか

3. GoogleやFacebookなど外部サービスへの影響

特に広告を出しているかどうかを確認しましょう。出稿している場合は停止すべきか判断します。

【3】障害発生時のウェブサイト対策

障害が1時間程度で終わりそうか、本番環境でFTPが稼働していて正しく503ページが表示されそうであれば、わざわざスタンバイ機に切り替える必要はないことがほとんどです。

サーバー会社に問い合わせても、まったく状況がわからず障害が長引きそうであれば、スタンバイ機に切り替える用意をします。

スタンバイ機に切り替える方法

ドメインを管理しているお名前ドットコムなどにログインし、ドメインのネームサーバーをスタンバイ機のネームサーバーに切り替えます。

ネームサーバーセッティング

上記はXserverのネームサーバーが設定されている画面ですが、こちらをさくらサーバーに切り替えるのであればns1.dns.ne.jpとns2.dns.ne.jpに切り替えます。ネームサーバーのドメイン名は、スタンバイ機を借りているレンタルサーバー会社のヘルプに必ず記載してあります。復旧後は元に戻せるよう、現在の設定は覚えておきましょう。

ネームサーバーを切り替えると、いろいろな端末からのアクセスが順次スタンバイ機に切り替わるはずです。（最大３日程度かかることもあります）

スタンバイ機で告知や暫定対応を行う

スタンバイ機で、現状や復旧見込に関してHTMLに書き込み、アップロードしましょう。
またキャンペーンを実施している最中であれば、そのキャンペーンページだけ本番のバックアップから作成し、サービスとして提供してもよいでしょう。

【4】障害復旧後に元に戻す

サーバー障害が完了したら、また先ほどのネーム-サーバーを元に戻します。