トラブルに強いウェブサイトのキーワード「可用性（かようせい）」とは
ネットワークやサーバーの運用業務に携わっていない方には、あまり馴染みのない単語かもしれませんので、最初に「可用性」について少し解説しておきます。
「可用性」は英語の availability（アベイラビリティ） の日本語訳で、利用者から見て「使用できる度合い」を示します。一般的に「可用性」という言葉は、データセンターのサーバーの「稼働状態（使用可能な状態）」の指標などに使われる事が多いです。例えば、「トラブルに強い、高可用性クラウドサーバー。年間稼働率99.9％」といった具合です。
しかし、ここで説明している「可用性」は、単にサーバーの性能を示す狭義な意味ではなく、「ウェブサイト」の稼働状態（ユーザーが使用可能な状態）を示す広義の意味での「可用性」について解説しています。
高可用性（ウェブサイトが継続して稼働できる能力）が必要な理由
あえて書かせていただきますと、ウェブサイトにおける「サーバーダウン」は言わば、「レストランに入って注文をしようと思ったら、突然の停電や調理機器の故障で無理やり店を追い出された」ようなものです。
ウェブにおける「機会」は非常に重要です。機会とは、一人のユーザーが公開されているウェブサイトに訪れるという機会です。インターネット中心の時代となった今日、ブログやインスタグラム、ツイッターなどのSNSをはじめ、１つの機会がもたらす影響力や伝播力は、検索エンジンの比ではありません。
一人のユーザーのアクセスがきっかけとなってビジネスが急成長したり、傾いた経営が再建されてゆく場面を私は幾つも見てきました。今の時代、１つのアクセスがその先の企業の未来を大きく左右する状況は、決して珍しい事ではないのです。
したがって、ウェブ上で「集客」や「サービスの提供」や「求人」を行っている企業にとって、「ウェブサイトのダウン」は、“信頼”と“利益”を得る機会を失う言わば「致命的なダメージ」以外の何者でもありません。ビジネスチャンスを掴み損ねない為に、24時間365日、ウェブサイトが存在する限り、半永久的にアクセスできる状態、つまり、「高可用性」を保っておきたい理由がここにあります。
では、どうやって「可用性」を手に入れればよいのでしょうか？
割合としては、レンタルサーバー会社と契約してワードプレスを運用している企業が多いかと思います。この場合はレンタルサーバー会社が可用性（ロードバランサー、多重化、冗長化など）の環境を整えていて、その環境の中にあるサーバーのスペースを間借りしている訳ですから、レンタルサーバー会社で用意された環境に依存するという事になります。サーバー会社にもよりますが、提供されるサーバー環境にはウェブサイトにアクセスする為の標準的な可用性はあります。
ただし、一般的なレンタル共有サーバーには１台のサーバーに１００ユーザー（１００サイト）以上が割り当てられている場合があり、その中の１つのサイトに高トラフィック（大きな負荷）が発生すると、残りの９９サイトにも影響が出て表示が遅くなったりと、価格が安い分、それなりのリスクがあります。そのリスクを回避するには専用サーバー（１台１ユーザー）という選択種もありますが当然高額になります。
また、専用サーバーを用意しても、そのサーバー自体がクラッシュする事もあるため、全く同じ専用サーバーを複数台用意して冗長化して、回線を二重化して･･･。と、高可用性を追求するとキリがなく、高額なコスト（数十万円～）が企業の利益を圧迫することになります。
仮に、このような「高可用性」の高額なクラウドサーバーを契約してサーバーダウン（停電や故障）を防げたとしましょう。しかし、「ウェブサイトの可用性」で考えると、サーバートラブルよりも、例えば「ワードプレスのプラグインの自動アップデートでシステムに不具合」が発生したり、「プラグイン同士の干渉」でエラーが発生しり、それ以外の様々な原因で結果的にサービスを丸１日止めてしまうといったケースの方が多いのです。
つまり、本当の意味で「ウェブサイトに必要な高可用性」はハード機器だけでは実現出来ないのです。
ウェブサイトに必要な「本当の」可用性（継続して稼働できる能力）とは
長年、企業のサーバーを実際に運用し、様々な「高可用性」を謳うシステムを試し、よりベストな構成を追及して辿り着いた答えは「サーバーのみの可用性を追及するのではなく、クラッシュしたシステムを如何に早く再構築するか」という事です。こんな事を言ってしまうと元も子も無いと思われるかもしれませんが、誤解が無い様に申し上げますと、サーバー環境においては、当然、標準的な可用性は必要ですし、無いと話しになりません。サイトの規模によっても必要な構成は変わってきます。
ですが、どんなサーバーでも、どんな優れた環境を構築しても、１０年に１度ぐらいは「想定外」のトラブルで復旧が不可能な状況が起こります。「100％の通信とデータの保障」をするデータセンターやサービスが世界で１社も存在しないのがその証拠です。10,000台の機器で構成されたクラウドサーバーが、更に国内外で冗長可されていたとしても、「絶対の保障」は一切ありません。大切な事は、「 いつか “必ず” 壊れる 」と言う前提で備える事です。そして、その時に「どんな状況でも必ず復旧できる準備」を整えとく事が重要です。
一般的に、サーバートラブルの際、サーバー会社の復旧を待っていれば元に戻ると思われている方が結構おられますが、実は壊滅的な障害の場合「復旧不可能」なケースもありますし、サーバー会社が突然倒産してすべてのサーバーが差し押さえられてアクセス出来なくなったりするケースもあります。それによって顧客やデータを失い、サイト閉鎖、倒産に追い込まれた企業もあるほどです。
下記のニュースはかなり大きく報じられたのでご存知の方もいらっしゃるかと思いますが、まさに障害から復旧不可能になった最悪の事例と言えるでしょう。
ウェブ魚拓版
「こんなレアなケースはそうそう起こるはずが無い」と、備えをしていなかった企業がサイト閉鎖や倒産に追い込まれてしまった現実から学ぶことは大切な事です。月額で数十万円の高可用性のインフラを構築しても、何重にもバックアップを取っていても「ダメな時はダメ」なのです。
では、一体どうすれば良いのか？実は、その答えはとてもシンプルです。
どうすれば良いのか？現実的な運用に対する可用性の答え
拍子抜けするかもしれませんが、ウェブサイトの高可用性を達成するには１つの考え方と、１つの構成に尽きます。
現行のシステムは「必ず復旧不能の障害が発生する」という考え方と、「別環境への移行を前提とした１サービスに依存しない構成」にしておく事です。
先の例の通り、「これだけの構成を組んでおけば大丈夫だろう。」という１社に依存した考え方だと、ファーストサーバーの障害の二の舞です。
今回はWordPressサイトを前提とした記事ですが、大規模システムであろうと、ミニマムなWordPressサイトであろうと「ウェブサイトの高可用性」という観点からは同じです。システムの大小に関らず、移行を前提とした同じ環境（統一性のあるプラットフォーム）を複数社で用意しておき、可能であれば複数サイトを別環境で同時運用しておきます。
その上で、稼働率99.99％のウェブサーバー、DNS、リアルタイム監視、バックアップ（耐久率99.999999999%の海外のクラウドストレージ）、パッケージ化された復旧プログラムを用意しておき、新たな別サーバーの環境へ俊敏なに移行を実現できる環境を整えます。
１社のサービスに依存せず、日頃から備えをしておく事で、先のファーストサーバーの障害のような絶望的な状況でも、一定の条件下では障害告知（対象ドメインへのアクセスに対しての一時表示）まで１５分程度、およそ３０分～１時間程度で、wordpressやec-cubeの受注データまで全データベースもまるごと別会社のサーバー上で完全復旧が可能です（「ワードプレス・保守管理サービス」）。
この仕組みは当社が数年間運用しており、復旧作業につきましても十分な実績がございます。
繰り返しになりますが、月数十万円の高可用性の環境を構築しても、何重にもバックアップを取っても「ダメな時は本当にダメ」なものです。意地になって一社依存の高度で高額な環境を構築するよりも、駄目になったら躊躇なくさっさと他社サーバーへ移行して、あっという間に運用を再開するのと、どちらが賢明でかは言うまでもありません。
ウェブサイトに依存したビジネスをされておられる企業様にとって、サーバーダウン、サーバークラッシュは死活問題です。可用性に不安があるお客様は是非当社スタッフにお声掛け下さいませ。
おまけ
皆さんは、もしもこの瞬間、自社のウェブサイトがクラッシュしたらどう対処しますか？
色々な状況が考えられますが、「最も最悪な状況」を想定してみましょう。
想定される設定は以下の通りです。
- 現在、深夜の午前３時です。
- あなたは海外の旅行先で熟睡中です。
- 大型連休（1/1）のど真ん中です。
- 契約中ウェブサイト、ウェブサーバーにも一切アクセスできません。
- 契約会社のメールサーバーも全てダウンしています。
- サーバー会社は対応に追われ、サポートには電話、チャット、メールも一切繋がらない状況です。
- 唯一、障害情報サイトに「原因調査中、復旧の見通し不明」とい掲載されている。
- ３日後、サーバー会社側から復旧不可能という正式に発表があった。
かなりシビアな状況です。
さて、あなたはこの状況からサイトを復旧できるでしょうか？また、復旧が可能な場合はどれぐらいの時間で作業を終えてウェブサイトを通常稼動させられるでしょうか？
作業手順も非常に大切です。
ヒントはこちら
ヒント
ヒント
- トラブルを知る（分単位の死活監視）
- 別サーバーでの障害告知を出す（DNS切り替えによる告知表示）
- 他社のサーバーの準備（復旧ばっケージのアップロード）
- 復旧作業する（半自動復旧プログラム）
- 復旧済みサイトの公開（DNS切り替え）
