あとで読む
前回は、なぜZenlogicやCGP（Google Cloud Platform）のようなサーバーで障害が発生してしまうのか、その根本原因について考えました。
一言で言うと「サーバー自体が難しいから障害は発生してしまうし、対応できるエンジニアも限られている」というのが結論でした。
第二回目の今回は、上記の根本原因をおさえた上で、ウェブ担当者として最低限必須のサーバー知識をお伝えし、どのようにサーバー障害を回避し、サービス継続性を確保すべきかについて考えてみます。
ウェブ担当者として、最低限どのようなサーバー知識を得ればよいでしょうか。 特にサーバー技術は難しいわけですから、全部を理解することは難しいはずです。
これは、医療に似ているかも知れません。
一般自には医学の勉強までは難しいですが、例えばケガと疾病の違いや、どの部位に病気が起こるのか、また病院の運営体制など基本的な知識があれば、病院やお医者さん選びに主体性がでますし、判断力もあがります。
サーバーにおいても、基礎的な知識を得ることで、サーバー選びや、万が一の時の判断力があがります。
サーバーについて知っておきたいことは、下記2つです。
以下、順にご説明します。
そもそも、サーバーと言うと何をイメージするでしょうか？ 大きなコンピューターをイメージする人もいれば、Webサーバーという言葉をイメージする人もいるかも知れません。
サーバーをイメージするには、具体的なモノをみてもらった方が早いと思います。
まずサーバーはデータセンターと呼ばれるビルに入っていることが多いです。データセンターの場所は、地盤が強く災害に強い地域が選ばれますが一般的には公表されません。爆破などされたら大変なことになりますからね。
イメージ画像：pixabay
そして、データセンターの中には、コンピューターだけではなく、ネットワーク回線や、大きなハードディスクなど、様々な機器が設置されており、それらが回線で接続されています。 
イメージ画像：pixabay
ここまではクラウドサーバーであっても、一般的なレンタルサーバーであっても一緒です。 クラウドとレンタルサーバーの違いは、それら機器をつなぐ回線接続の仕方や、稼働しているソフトウェアの違いです。
たくさんあるコンピューターの中から、一台のコンピューターをユーザーに貸し出しています。共有サーバーと呼ばれる場合には、特殊なソフトウェアを使って、その一台をさらに複数人に貸し出しています。 
イメージ画像：pixabay
結局一台のコンピューターなので、自分が間借りしているマシンが壊れてしまえば、サービスは停止します。 しかし、データが喪失することはまれです。なぜなら、通常コンピューターにはハードディスクが2個以上搭載されており、データをコピーしているからです(Raid構成といいます)。
コンピューターが壊れてしまった場合は、サービス停止してしまいますが、その間にレンタルサーバー会社が、新しい機器に入れ替えて再稼働してくれます。データは消えていないので、普通にサービス再開ができるという仕組みです。
クラウドサーバーの場合は、コンピューターにクラウド化するソフトウェアが入っています。まずこれが大きな違いです。 各クラウド会社は、そのクラウド化ソフトウェアを使って柔軟なマシン構成をとっています。 複数台のマシンで冗長構成をとり、マシン内部にハードディスクを設置するのではなく、外付けにして巨大なストレージにまとめているところもあります。ユーザーはたくさんあるマシンのどこかでサービスを稼働することになります。 
イメージ画像：pixabay
イメージを見ると、一見クラウドの方が障害に強そうにみえるかも知れません。 でも実際は、根幹を支えるクラウド化するソフトウェアにバグが出る可能性もありますし、どれかのマシンで稼働しているのは変わらないので、そのマシンが壊れてしまえばサービスが停止するのは一緒です。 ただし、他のマシンに乗り換えて運用を再開するスピードが速くなるのがクラウドサーバーの利点ではあります。代替機器が近くにたくさんあるからです。
サーバーの物理的なイメージがわかったところで、そのどの箇所に障害がでる可能性があるかを考えてみましょう。 想像がつくかも知れませんが、下記のような障害が考えられます。
ビル全体が災害にあうことなんてあるの？と思う方もいらっしゃるかも知れませんが、時々あります。 たとえばGoogleのデータセンターは不定期で災害にあっていて、雷によってデータセンターが止まることもあるのです。
▼グーグルのデータセンターに4回も雷が直撃して顧客データが消失 -GIZMODO Japan www.gizmodo.jp/2015/08/post_18055.html
ソフトウェア系や人的障害は、それこそ無数に発生する可能性があります。これはご自身のパソコンを思い浮かべてもらってもイメージがつきやすいと思います。
低スペックのパソコンで、作業が遅くなることはよくありますし、原因不明でエクセルなどが固まることもあるでしょう。設定ミスやウィルスなどで、取り返しのつかないことになることもあると思います。
サーバーも一緒です。
サーバーの仕組みがわかってくると、以下のようなことがわかってくると思います。
上記は全て正しいです。
いくらその会社がSLA（サービスレベルアグリーメント：99%など稼働率の約束）を発表していても、本当にその通りになるかは別です。 現に今回のZenlogicもGoogleもSLAはありますが、その通りには稼働しませんでした。SLAはサービス停止時にいくらかの保証してくれるというだけです。
上記のように考えると、ウェブ担当者が考えるべきは、障害をなくする方法ではなく 「どうやって障害のリスクを下げ、それでも万が一の時には素早く復帰するか」 という観点であることがわかります。
そのためにリスク計算を下げる方法と、速やかに復旧する方法の二つを記載します。
障害が0にはならないとはいえ、サーバー会社選定を間違えなければ、多くのリスクヘッジはサーバー側でやってくれますし、仮にサービスダウンしたとしても、復旧までがとても早いです。従ってサーバー会社選びは最優先事項です。
サーバー障害のリスクを下げるには、下記3つを心がけるとよいでしょう。
リスクを下げるために、最も重視した方がよい項目だと思っています。
この場合、意外と影響力があると感じるのは、会社の代表（意思決定する人。株主の場合もあり）が元エンジニアかどうかです。代表者の名前でGoogle検索すれば、だいたいバックグラウンドがわかります。 嘘みたいな話ですが、だいたい当たります。自社で何を重視するか？という投資判断が違うからだと思っています。AmazonやGoogleもエンジニア出身です。
北海道地震における「さくらサーバー」の連続稼働
先に震度７を記録した北海道胆振東部地震において、さくらサーバーの石狩データセンターが奇跡の連続稼働をみせて話題になりました。そのさくらサーバーの代表者もエンジニア出身です。ASCIIの記事でもいかにさくらのエンジニアが優秀かに触れられています。
▼約60時間を非常用電源設備で乗り切った石狩データセンターの奇跡 -ASCII.jp
ascii.jp/elem/000/001/738/1738515/
その他の技術レベルの判断方法
あとは、内部の技術者のレベルは、サポートページの内容に現れていることが多いです。 ポイントとして、見てくれや内容の丁寧さが重要なのではなく、効率的に情報をまとめようという姿勢がある会社は、エンジニアのレベルが高いことが多いです。効率的というところがポイントです。
イメージで近いのはエックスサーバー社ですね。
www.xserver.ne.jp/support/
またサポートに電話をかけてみたり、問い合わせをしたりしてみます。 ここで重要なのが、愛想が良く丁寧ということに惑わされず、要点に的確に答えてくれるかどうかを判断します。
なぜかというと、ハイレベルなエンジニアの人は傾向として、事実のみを伝えたがる傾向があります。逆にいえば、正直だけどそっけないことも多いのです。
余談ですが、私はマーケティングがうますぎるエンジニア会社や医院はすぐには信頼しないようにしています。 通常のサービスであれば、愛想が良くマーケティングがうまいにこしたことはないのですが、技術者で腕が良い人というのは、得てしてそういうことが後回しになる（興味がない！？）ことも多いからです。
次に重要なのが、実績のあるサーバー会社です。 この実績は、運用年数ということではなく「問題点」や「障害に対する対応実績」を見ます。
ですから、「XXサーバー 障害」「XXサーバー 不満」といったキーワードで検索してみることをオススメします。 そうすると、過去に大きな問題を出してしまったところがわかります。
一番凄いのは、長年（10年くらいとか）運用されているサーバーなのに、あまり大きな不満や障害が出ていないところです。これは、未然に防ぐリスクコントロールに長けているということであり、相当優秀な人達が運用していると考えられます。
とはいえ、どれだけ腕のよい会社でも、マンパワーが足りず、経験不足などで一回くらいは大問題が発生することはあります。ですから一回くらい発生しているのは問題ないと思います。大切なのは、その問題に対してどのように対処したか、です。
この時も、マーケティングがうまいと口では何とでもいえますから、あまり中の人がいう対処を信じすぎないようにします。周りの人がどう評価しているか、です。
これは説明するまでもありませんが、スペックが良いサーバーを使いましょう。 サービスのアップデートを頻繁に行っている会社は、サーバースペックも最新で、そもそも信頼できることが多いです。
あと、パソコンでもそうですが、サーバースペックをケチると、スピードをあげるのに苦労します。 エクセルが固まりやすくなって、パソコンを買い換えたらすごく快適になったという人も多いのではないでしょうか。 細々がんばるより、思い切って毎月千円くらいコストをかけた方が快適というのがサーバーの世界です。
速やかにサービスを復旧するためにまず大事なのは「ドメイン」の知識です。
ドメインを取得する時には、お名前ドットコムなど「ドメインレジストラ」と呼ばれる事業者で取得すると思います。 ドメインレジストラは「そのドメインの代表者は誰か？どのサーバーが管理サーバー（以下ネームサーバーといいます）か？」といったことを管理してくれます。
ネームサーバーは、そのドメインのホームページがあるサーバーや、メールデータがあるサーバーのIPアドレスを管理しています。 従って、もしホームページのサーバーに障害が発生した場合は、別のサーバーを指し示すことで、スタンバイ機に切り替えることが可能です。
詳しくは第三回で触れます。
ドメイン以外の速やかな復旧の基本はバックアップです。 バックアップと一口にいっても様々あります。
速やかに復旧するという意味では、スタンバイ機をどのように用意するか？ということがポイントです。 スタンバイ機があれば、「障害発生中」などなんらかの情報を提示できますし、下層ページアクセス時にGoogleが推奨する503エラー（障害発生中を示す）を返すこともできます。
まず一歩目は、現在のサーバーレンタル会社に問い合わせをして、バックアップ体制がどうなっているのか、またスタンバイ機を用意したい場合はどうすればよいのかを確認することでしょう。
またデータバックアップは、なるべく定期的に物理的に別の箇所に保存しておくと安心です。
もし仮にデーターセンターレベルで災害があった時にも、対処することができます。
今回は、ウェブ担当者として知っておきたいサーバー障害についてお伝えしました。お伝えしてきたとおり、まず間違いないサーバー会社を選ぶことでリスクは格段に下がりますので、その選定はしっかり行いましょう。
またどれだけ優秀なサーバー会社を使ったとしても、優秀なエンジニアがいたとしても、頻度と停止期間は下げることができますが、障害と無縁でいることはできません。
ぜひ、今回お伝えしたことを中心に、データバックアップだけは定期的に取得するようにしましょう。 またできればスタンバイ機で復旧するための手順を整えておきましょう。
最終回の第三話目では、今回お伝えした原則を中心に、万が一の時に速やかにサービス復旧するための、具体的なスタンバイ機の用意や、ネームサーバーの設定方法などについて触れます。
ウェブ担当者通信の発起人。
株式会社ウェブジョブズ代表。
コンサルティングの他、ウェブ担当者教育などにも力を入れ、株式会社インプレスビジネスメディア社の運営するウェブ担当者フォーラムにて「誰もが受けたい!アクセス解析5 分クリニック」を連載。
著書に無料でできる！ 世界一やさしいGoogle Analytics アクセス解析入門（秀和システム）
WPプラグインQA Heatmap Analyticsのプロダクトマネージャー
