画像：pixabay

Ｊストリーム社は2016年から日本国内のCDNシェアの調査結果を公開しています。

CDNとはコンテンツデリバリーネットワーク（Content Delivery Network）の略で、Webコンテンツをキャッシュし配信するネットワークのことです。
CDNサービスではAkamai（アカマイ）が老舗であり有名です。

Ｊストリーム社の調査によると、JPドメインサイトのCDNシェア推移では2016年11月以降Akamaiは下降傾向です。
一方シェアを伸ばしているのはAmazon CloudFrontです。

CDN自体はWebサーバーを高速化するための仕組みではありませんが、CDNでキャッシュして配信することでユーザーにコンテンツを早く届けることが可能になります。

Webページの高速化が求められている今、CDNの利用を検討している方も多いと思います。CDNサービスにはどんなものがあって今の主流が何か、参考になるデータかもしれません。

国内CDNシェア(2018年10月) | J-Stream CDN情報サイト

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

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

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

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

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

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

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

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

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

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

事前準備

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

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

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

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

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

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

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

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

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

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

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

1. サーバーを借ります。できれば既存サーバーとは違う会社、もしくは別リージョン（別の場所）のサーバーを借りましょう。
2. ヘルプを見ながら、通常通りwebtan-tsushin.comとしてドメインのセットアップをしていきます。
   例）エックスサーバーにおけるマルチドメインの設定方法　※ドメインは新規取得しなくてOK
   www.xserver.ne.jp/manual/man_domain_setting.php
3. ただし2の作業でhttpsの新規セットアップは通常できません。理由は、SSLサーバー証明書をインストールするには、そのサーバーがwebtan-tsushin.comであることを証明しなくてはいけませんが、webtan-tsushin.comは通常本番サーバーに繋がり、スタンバイ機には繋がらないため、スタンバイ機を証明することができないからです。
   この対策は３つありますが、そもそも暫定対応ページなのでhttpで運用するのがオススメです。
   • httpで運用する（楽なのでオススメ！） 
   • 既存で使用しているサーバー証明書をインストールしておく（オススメだけど要インフラ知識）
   • 夜間などに本番とスタンバイを切り替えてインストールする（知識はそれほどいらないがメンドクサイ）
4. 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】障害復旧後に元に戻す

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

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

しばらくすると本番に切り替わります。

【5】影響を調べる

無事、復旧が完了し一段落したら、最後に、今回の障害の影響を調べておきましょう。
Googleアナリティクスにはスタンバイ機で動いていたときのデータがたまっているはずです。そこから影響範囲を調べて、今後の対応を考えましょう。

まとめ

今回は、万が一の時にWeb担当者が行うべき具体的な準備や作業についてお伝えしました。

とはいえ文中にも記載しましたが、やはりこのような状態を招かないよう、信頼が高い会社のサービスを使うのが一番の対策です。

手間を考えると、サーバーに対する投資額は、毎月数千円程度しか違わないということも多いです。
つまりアルバイトさんの数時間よりも安いのです。サーバーに対しては、少し高めでもよいので、ぜひ信頼度の高いサービスを利用されることをお勧めします。

画像：PictArts ピクトアーツ

ウェブ通で連載中の「【プレミアム】ゼンロジック（Zenlogic）とGCPの障害から考えるウェブ担の必須サーバー知識」でも書いていますが、レンタルサーバーなど外部のサービスを利用している以上、何らかの予期せぬトラブルにより自社のサービス提供に影響が及ぶことがあります。
ウェブ担当者として最低限必須のサーバーに関する知識を身につけ、適切なリスクへの対処をしていくことが求められます。

今回取り上げている記事「レンタルサーバーを選定比較する際に、考えておきたいリスク低減について | レンタルサーバーのCPIスタッフブログ」では、レンタルサーバーを選定する比較項目のひとつとしての「リスク低減」についてまとめられています。
レンタルサーバーのリスク低減項目として4つあげられています。

バックアップの取得先

ウェブサーバーと別のサーバーにバックアップを取得する

サーバー構成

バックアップサーバー同様にウェブサーバーとメールサーバーを分離することが望ましい

サポート体制

電話サポートがあると緊急対応がやりやすい

過去の障害状況

できるだけ障害が少ない会社を選ぶ

レンタルサーバーを選定比較する際に、考えておきたいリスク低減について | レンタルサーバーのCPIスタッフブログ

前回は、なぜZenlogicやCGP（Google Cloud Platform）のようなサーバーで障害が発生してしまうのか、その根本原因について考えました。

一言で言うと「サーバー自体が難しいから障害は発生してしまうし、対応できるエンジニアも限られている」というのが結論でした。

第二回目の今回は、上記の根本原因をおさえた上で、ウェブ担当者として最低限必須のサーバー知識をお伝えし、どのようにサーバー障害を回避し、サービス継続性を確保すべきかについて考えてみます。

ウェブ担当者として必須のサーバー知識

ウェブ担当者として、最低限どのようなサーバー知識を得ればよいでしょうか。 特にサーバー技術は難しいわけですから、全部を理解することは難しいはずです。

これは、医療に似ているかも知れません。

一般自には医学の勉強までは難しいですが、例えばケガと疾病の違いや、どの部位に病気が起こるのか、また病院の運営体制など基本的な知識があれば、病院やお医者さん選びに主体性がでますし、判断力もあがります。

サーバーにおいても、基礎的な知識を得ることで、サーバー選びや、万が一の時の判断力があがります。

サーバーについて知っておきたいこと

サーバーについて知っておきたいことは、下記2つです。

1. サーバーの基本的な仕組み
2. サーバー障害の種類

以下、順にご説明します。

1.サーバーの基本的な仕組み

そもそも、サーバーと言うと何をイメージするでしょうか？ 大きなコンピューターをイメージする人もいれば、Webサーバーという言葉をイメージする人もいるかも知れません。

サーバーをイメージするには、具体的なモノをみてもらった方が早いと思います。

データセンター

まずサーバーはデータセンターと呼ばれるビルに入っていることが多いです。データセンターの場所は、地盤が強く災害に強い地域が選ばれますが一般的には公表されません。爆破などされたら大変なことになりますからね。

イメージ画像：pixabay

データセンターの中

そして、データセンターの中には、コンピューターだけではなく、ネットワーク回線や、大きなハードディスクなど、様々な機器が設置されており、それらが回線で接続されています。

イメージ画像：pixabay

ここまではクラウドサーバーであっても、一般的なレンタルサーバーであっても一緒です。 クラウドとレンタルサーバーの違いは、それら機器をつなぐ回線接続の仕方や、稼働しているソフトウェアの違いです。

レンタルサーバー

たくさんあるコンピューターの中から、一台のコンピューターをユーザーに貸し出しています。共有サーバーと呼ばれる場合には、特殊なソフトウェアを使って、その一台をさらに複数人に貸し出しています。

イメージ画像：pixabay

結局一台のコンピューターなので、自分が間借りしているマシンが壊れてしまえば、サービスは停止します。 しかし、データが喪失することはまれです。なぜなら、通常コンピューターにはハードディスクが2個以上搭載されており、データをコピーしているからです(Raid構成といいます)。

コンピューターが壊れてしまった場合は、サービス停止してしまいますが、その間にレンタルサーバー会社が、新しい機器に入れ替えて再稼働してくれます。データは消えていないので、普通にサービス再開ができるという仕組みです。

クラウドサーバー

クラウドサーバーの場合は、コンピューターにクラウド化するソフトウェアが入っています。まずこれが大きな違いです。 各クラウド会社は、そのクラウド化ソフトウェアを使って柔軟なマシン構成をとっています。 複数台のマシンで冗長構成をとり、マシン内部にハードディスクを設置するのではなく、外付けにして巨大なストレージにまとめているところもあります。ユーザーはたくさんあるマシンのどこかでサービスを稼働することになります。

イメージ画像：pixabay

イメージを見ると、一見クラウドの方が障害に強そうにみえるかも知れません。 でも実際は、根幹を支えるクラウド化するソフトウェアにバグが出る可能性もありますし、どれかのマシンで稼働しているのは変わらないので、そのマシンが壊れてしまえばサービスが停止するのは一緒です。 ただし、他のマシンに乗り換えて運用を再開するスピードが速くなるのがクラウドサーバーの利点ではあります。代替機器が近くにたくさんあるからです。

2.サーバー障害の種類

サーバーの物理的なイメージがわかったところで、そのどの箇所に障害がでる可能性があるかを考えてみましょう。 想像がつくかも知れませんが、下記のような障害が考えられます。

【物理障害】

• データセンターが災害にあってしまう
• ネットワークケーブルが断線する（全体・一部）
• ネットワーク機器が壊れてしまう（ルーターやスイッチ）
• コンピューターが壊れてしまう
• ハードディスクが壊れてしまう

ビル全体が災害にあうことなんてあるの？と思う方もいらっしゃるかも知れませんが、時々あります。 たとえばGoogleのデータセンターは不定期で災害にあっていて、雷によってデータセンターが止まることもあるのです。

▼グーグルのデータセンターに4回も雷が直撃して顧客データが消失 -GIZMODO Japan www.gizmodo.jp/2015/08/post_18055.html

【ソフトウェア系の障害】

• サイバー攻撃をうけて、ネットワークが遅くなってしまう
• セキュリティホールをつかれてウィルス感染してしまう
• 基幹ソフトウェアのバグで高負荷になってしまう
• コンピューターのスペックが低くて、高負荷で遅くなってしまう
• etc..

【人的障害】

• バックアップを取得するつもりが、逆にファイルを消してしまった
• 設定ミスで必要なファイルを消してしまった
• システムで重要なファイルの設定を書き換えたら、サーバーが不安定になった
• ルーターの設定をいじったら、逆に遅くなった
• etc..

ソフトウェア系や人的障害は、それこそ無数に発生する可能性があります。これはご自身のパソコンを思い浮かべてもらってもイメージがつきやすいと思います。

低スペックのパソコンで、作業が遅くなることはよくありますし、原因不明でエクセルなどが固まることもあるでしょう。設定ミスやウィルスなどで、取り返しのつかないことになることもあると思います。

サーバーも一緒です。

サービス停止リスクを回避する方法

サーバーの仕組みがわかってくると、以下のようなことがわかってくると思います。

• 全てのサーバー障害を防ぐことは不可能である
• 優秀なサーバーエンジニアがいる会社を選んだ方が安心である
• 低スペックのサーバーはより高負荷リスクが高い

上記は全て正しいです。

いくらその会社がSLA（サービスレベルアグリーメント：99%など稼働率の約束）を発表していても、本当にその通りになるかは別です。 現に今回のZenlogicもGoogleもSLAはありますが、その通りには稼働しませんでした。SLAはサービス停止時にいくらかの保証してくれるというだけです。

上記のように考えると、ウェブ担当者が考えるべきは、障害をなくする方法ではなく 「どうやって障害のリスクを下げ、それでも万が一の時には素早く復帰するか」 という観点であることがわかります。

そのためにリスク計算を下げる方法と、速やかに復旧する方法の二つを記載します。

サーバー障害のリスクを下げる方法

障害が0にはならないとはいえ、サーバー会社選定を間違えなければ、多くのリスクヘッジはサーバー側でやってくれますし、仮にサービスダウンしたとしても、復旧までがとても早いです。従ってサーバー会社選びは最優先事項です。

サーバー障害のリスクを下げるには、下記3つを心がけるとよいでしょう。

1. 技術者のレベルが高いサーバー会社を使う
2. 実績のあるサーバー会社を使う
3. サーバースペックが高いサーバー会社を使う

1.技術者のレベルが高いサーバー会社を使う

リスクを下げるために、最も重視した方がよい項目だと思っています。

この場合、意外と影響力があると感じるのは、会社の代表（意思決定する人。株主の場合もあり）が元エンジニアかどうかです。代表者の名前でGoogle検索すれば、だいたいバックグラウンドがわかります。 嘘みたいな話ですが、だいたい当たります。自社で何を重視するか？という投資判断が違うからだと思っています。AmazonやGoogleもエンジニア出身です。 

北海道地震における「さくらサーバー」の連続稼働

先に震度７を記録した北海道胆振東部地震において、さくらサーバーの石狩データセンターが奇跡の連続稼働をみせて話題になりました。そのさくらサーバーの代表者もエンジニア出身です。ASCIIの記事でもいかにさくらのエンジニアが優秀かに触れられています。

▼約60時間を非常用電源設備で乗り切った石狩データセンターの奇跡 -ASCII.jp
ascii.jp/elem/000/001/738/1738515/

その他の技術レベルの判断方法

あとは、内部の技術者のレベルは、サポートページの内容に現れていることが多いです。 ポイントとして、見てくれや内容の丁寧さが重要なのではなく、効率的に情報をまとめようという姿勢がある会社は、エンジニアのレベルが高いことが多いです。効率的というところがポイントです。

イメージで近いのはエックスサーバー社ですね。
www.xserver.ne.jp/support/

またサポートに電話をかけてみたり、問い合わせをしたりしてみます。 ここで重要なのが、愛想が良く丁寧ということに惑わされず、要点に的確に答えてくれるかどうかを判断します。

なぜかというと、ハイレベルなエンジニアの人は傾向として、事実のみを伝えたがる傾向があります。逆にいえば、正直だけどそっけないことも多いのです。

余談ですが、私はマーケティングがうますぎるエンジニア会社や医院はすぐには信頼しないようにしています。 通常のサービスであれば、愛想が良くマーケティングがうまいにこしたことはないのですが、技術者で腕が良い人というのは、得てしてそういうことが後回しになる（興味がない！？）ことも多いからです。

2.実績のあるサーバー会社を使う

次に重要なのが、実績のあるサーバー会社です。 この実績は、運用年数ということではなく「問題点」や「障害に対する対応実績」を見ます。

ですから、「XXサーバー　障害」「XXサーバー　不満」といったキーワードで検索してみることをオススメします。 そうすると、過去に大きな問題を出してしまったところがわかります。

一番凄いのは、長年（10年くらいとか）運用されているサーバーなのに、あまり大きな不満や障害が出ていないところです。これは、未然に防ぐリスクコントロールに長けているということであり、相当優秀な人達が運用していると考えられます。

とはいえ、どれだけ腕のよい会社でも、マンパワーが足りず、経験不足などで一回くらいは大問題が発生することはあります。ですから一回くらい発生しているのは問題ないと思います。大切なのは、その問題に対してどのように対処したか、です。

この時も、マーケティングがうまいと口では何とでもいえますから、あまり中の人がいう対処を信じすぎないようにします。周りの人がどう評価しているか、です。

3.サーバースペックが高いサーバー会社を使う

これは説明するまでもありませんが、スペックが良いサーバーを使いましょう。 サービスのアップデートを頻繁に行っている会社は、サーバースペックも最新で、そもそも信頼できることが多いです。

あと、パソコンでもそうですが、サーバースペックをケチると、スピードをあげるのに苦労します。 エクセルが固まりやすくなって、パソコンを買い換えたらすごく快適になったという人も多いのではないでしょうか。 細々がんばるより、思い切って毎月千円くらいコストをかけた方が快適というのがサーバーの世界です。

速やかにサービス復旧するための施策

速やかにサービスを復旧するためにまず大事なのは「ドメイン」の知識です。

最低限知りたいドメインの知識

ドメインを取得する時には、お名前ドットコムなど「ドメインレジストラ」と呼ばれる事業者で取得すると思います。 ドメインレジストラは「そのドメインの代表者は誰か？どのサーバーが管理サーバー（以下ネームサーバーといいます）か？」といったことを管理してくれます。

ネームサーバーは、そのドメインのホームページがあるサーバーや、メールデータがあるサーバーのIPアドレスを管理しています。 従って、もしホームページのサーバーに障害が発生した場合は、別のサーバーを指し示すことで、スタンバイ機に切り替えることが可能です。

詳しくは第三回で触れます。

バックアップを用意する

ドメイン以外の速やかな復旧の基本はバックアップです。 バックアップと一口にいっても様々あります。

• スタンバイ機の用意
• データ（ファイルやDB、メールアドレス一覧など）のバックアップ
• サーバーイメージのバックアップ（※クラウドのみ）

速やかに復旧するという意味では、スタンバイ機をどのように用意するか？ということがポイントです。 スタンバイ機があれば、「障害発生中」などなんらかの情報を提示できますし、下層ページアクセス時にGoogleが推奨する503エラー（障害発生中を示す）を返すこともできます。

まず一歩目は、現在のサーバーレンタル会社に問い合わせをして、バックアップ体制がどうなっているのか、またスタンバイ機を用意したい場合はどうすればよいのかを確認することでしょう。

またデータバックアップは、なるべく定期的に物理的に別の箇所に保存しておくと安心です。

もし仮にデーターセンターレベルで災害があった時にも、対処することができます。

障害はいつ起きるかわからない。備えてリスクヘッジを

今回は、ウェブ担当者として知っておきたいサーバー障害についてお伝えしました。お伝えしてきたとおり、まず間違いないサーバー会社を選ぶことでリスクは格段に下がりますので、その選定はしっかり行いましょう。

またどれだけ優秀なサーバー会社を使ったとしても、優秀なエンジニアがいたとしても、頻度と停止期間は下げることができますが、障害と無縁でいることはできません。

ぜひ、今回お伝えしたことを中心に、データバックアップだけは定期的に取得するようにしましょう。 またできればスタンバイ機で復旧するための手順を整えておきましょう。

最終回の第三話目では、今回お伝えした原則を中心に、万が一の時に速やかにサービス復旧するための、具体的なスタンバイ機の用意や、ネームサーバーの設定方法などについて触れます。

ゼンロジックサーバー障害の原因は何だったのか？

2018年6月19日から7月9日までのおおよそ20日間、ソフトバンクの子会社であるファーストサーバ社が提供するZenlogicサーバーに障害が発生しました。

同サーバーを使っていた政府や公共交通機関などのサイトやメールが停止してしまい、社会的にも大きな問題となりました。

直接の原因は「ストレージ障害」だが長期化は「設定ミス」がポイント

Zenlogicの公式サイトに本障害の報告書が出ています。

▼本障害の概要と原因についてのご報告
zenlogic.jp/news/status/syogai/cause/

結論からいうと、直接の原因は「ストレージ障害」です。 しかし、なぜ20日間という長期間ほぼ停止してしまう状況になってしまったかというと、そのポイントは「設定ミス」であったとあります。つまり二次災害だったのですね。

流れとしては、下記のようです。

1. 6月に入りストレージシステムが高負荷になってきた（この時点でパフォーマンスは一部悪化）
2. そこで、ストレージシステムを高負荷にしていたプロセス（ネットワーク帯域を使ってしまう）に対し対処をしようと考えたが、その設定をミスしてしまった
3. システム全体がスローダウンしたため、物理的なストレージ増強や設定値変更などを行ったが、2の作業とバッティングしてしまい、結局時間がかかった

報告書の中には データ移動完了まで時間を要した とありますので、現在のストレージから増強した新しいストレージや別箇所にデータ移動を試みたのだろうと想定されます。この作業でさらに高負荷になったと思われますが、途中で止めてしまうと、データ消失の恐れがあるので、もうどうしようもなかったのだろうと考えられます。

じゃあそもそも、なぜ6月から高負荷になってしまったのかというと、2番の内容から想像するに、おそらく設置当初は気づかなかったプロセスのバグが発見され、その対処を間違ううちに、次々と問題に繋がっていったのだろうと推測します。

Google(Google App Engine)でも発生したサーバー障害

太平洋標準時で7月17日お昼ごろ、1時間程度にわたって発生したGoogleのサーバー障害も衝撃的でした。 幸い日本では早朝の出来事だったために、あまり大きな影響は及ばなかったようですが、世界中のポケモンGOや音楽ストリーミングサービスのSpotify、写真共有アプリのSnapchatが停止し、世界中の人が影響をうけました。

公式サイトに報告書が出ています。

▼Google Cloud Networking Incident No.18012
status.cloud.google.com/incident/cloud-networking/18012

上記によると、原因はロードバランサー（ネットワークのアクセス振り分けをする機器）に新機能を追加した際のバグだったそうです。 Zenlogicサーバーも最初のきっかけはバグだった可能性があることを考えると、その部分は似ているのかもしれません。

なぜ障害が発生してしまうのか

そもそも、なぜインフラ障害は発生してしまうのでしょうか。

※インフラ障害とは、レンタルサーバーなど基幹インフラの障害を指しますが、一般的には「サーバー障害」や「サーバーが停止した」といった表現もされるため、以降「サーバー」という言葉はインフラの意味でも使用します。

サーバー関連ソフトウェアのバグ

まず今回の問題に限っていうと、両者ともソフトウェアのバグがきっかけです。 特にクラウドサーバーは、裏で高機能なソフトウェアが動いていますので、レガシーなレンタルサーバーよりバグは発生しやすいかもしれません。

ZenlogicはYahoo!のサーバー管理チームが担当しているようです。 しかし仮にそのレベルだとしても、Googleだとしても、残念ながらソフトウェアのバグは発生してしまいます。

当然事前にテストはしているはずですが、本番使用されて条件が厳しくなると突然発生するバグもあり、基本的にソフトウェアのバグを100%防ぐことはできません。

人的な二次災害も怖い

その後、Zenlogicでは人的な設定ミスによる二次災害が発生してしまいました。 ここがGoogleと違うわけですが、設定ミスというと、ファーストサーバ社が2012年6月に起こした大規模障害も思い出されます。この時は、ストレージのデータを担当のミスにより消してしまうというものでした。

バグというきっかけは一緒だったとしても、その後に人的な災害を引き起こしたか否かで、Google社とファーストサーバ社には違いがあります。

「サーバーは難しい」ことが諸悪の根源

そもそも、サーバーエンジニアはハイレベルな総合力が求められる業種です。

なぜなら、根本的な部分では物理的なハードウェアの知識と、その上で動いているソフトウェアについての総合的な知識、および緊急事態に素早く対応できる論理的推察力も必要となるからです。

緊急病棟のお医者さんのようなものをイメージしてもらうと、普通の町医者とは違う仕事だというイメージがつきやすいのではないかと思います。つまり「サーバーは難しい」が故に「エンジニアはハイレベルが求められる」のです。

しかし、24時間サーバーを管理する場合に、そのような手練ればかりがちゃんと運用する体制を作ることは、とても難しいことです。 なぜなら、難しい作業をこなせる彼らは高給取りであるし、24時間体制で常時働かなくても仕事がたくさんあります。 そのような状況下において、さらに多くのサーバー会社は低価格を競う必要があるため、なかなか体制を完璧に整備することは難しいでしょう。

その結果、特に緊急時において適切な対処を素早く行っていくことは、思いのほか難しいのです。

どうすれば運営側のリスクヘッジができるか

たとえGoogleやAmazonなど、どんなサーバー会社であれ、裏では人がやっている作業であることは避けられません。 またサーバー会社の裏ではハードウェアとソフトウェアが稼働しており、必ずいつかは障害が発生することからも避けられません。

つまりヒューマンエラーやサーバー障害から逃れることはできないのです。 そうであれば、ウェブ担当者としては、最低限必須のサーバーに関する知識を身につけた上で、適切なリスク対処をしていくことが有効です。

そこで次回は、ウェブ担当者として必須のサーバー知識と、その知識を前提としたリスクヘッジについて考えたいと思います。

画像：pixabay

ファーストサーバが提供するホスティングサービス「Zenlogic」が、Webサーバーやメールなど提供しているサービスを停止して緊急メンテナンスを行い、終了予定から遅れて復旧する、という大規模障害がありました。

障害の経緯は以下のような感じだったようです。
6月19日からストレージシステムが不安定となりサーバーが高負荷状態に陥り、サービスが利用困難な状態が断続的に発生。
7月6日（金）20時ごろから7月9日（月）8時ごろまでの予定で、メール送受信、サイト閲覧、サーバーへのファイル転送、コントロールパネルの利用ができなくなくなる。
7月9日（月）8時に復旧せず、同日23時ごろにサービス復旧。

サービス停止の連絡が緊急メンテナンスだったからなのか直前だったそうです。
歌舞伎座やエレコム、YCATなど大企業も利用しており、Zenlogicを利用しているサイトは対応が間に合わず、メンテナンス期間中サイトが落ちている状態が続いていました。

今回障害が発生したのはヤフーのインフラ上に構築されたZenlogicであり、分散ストレージCephのキャパシティプランニングのミスが発端で高負荷状態となっていた、とのこと。

このニュースを見て、障害を被ったサイト運用をしていた方は「なんとかしろっ！」と言われ続けたのかも・・・と思い、胃がきゅーっとなってしまいました。
レンタルサーバーや外部システムを利用してサービスを提供している以上、いつ自分の身に降りかかってもおかしくないかも、と思います。

たとえば、メールとWebは分けておく、DNSサーバーを分けておく、バックアップをとっておく、など事前にできる対策もあります。
対策にかかる費用やサービスレベルなど、万が一のときを考えてリスク対策をやっておかないといけないとあらためて感じた事案でした。

ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 － Publickey

Zenlogicの障害から学ぶべきこと – WebサイトやCMSの静的化を御支援するfeedtailor社長ブログ

画像：Pixabay

プライム対象エリアは南米などが含まれないので、8億人程度と試算されるネット人口のうち、1億人が会員なので、平均12.5%はプライム会員ということですね。

インドでサービスを開始したことも大きかったのかも知れません。

Amazonは無理せずに着実に会員が増やせそうなエリアから、しっかり会員数を伸ばしてきています。

Amazonはユーザーの心理障壁をとる施策がかなり得意で、送料無料や見放題などかなり大胆な施策をうってきます。
そうする結果、やはり伸びていくということが証明されますね。

あまりに人間心理の計算ができていて隙がないので、愛される企業になるのは難しいかも知れませんが、インフラ企業としては、十分だと感じます。

米アマゾン「プライム会員」が１億人突破　会員数を初めて公表　　：日本経済新聞

私たちウェブ担当者通信は、KDDIウェブコミュニケーションズさんのCPIサーバーの共用サーバープラン（ACE01プラン）を使用しています。
2011年にウェブ担当者通信がスタートしてからNTTコミュニケーションズさんのBizメール＆ウェブを使用していました。その後、2013年3月のサイトリニューアルから現在までCPIサーバーを使用しています。

画像：CPI の共用サーバーサービス「シェアードプラン ACE01

この記事では、実際にCPIサーバーを使って感じている率直な感想をお伝えしたいと思います。

サイトリニューアル時にCPIサーバーを選んだ理由

2013年サイトリニューアル時の要件

私たちウェブ担当者通信は、メディアと会員向けサービス（ECサイトのようなもの）を展開しています。

システムは既にWordPressをベースに一部をカスタマイズして構築していたため、下記の条件で新サーバーを検討していました。

• 【システム】
  • WordPressが問題なく稼働すること
  • PHPで独自に開発したショッピングカートプログラムやeラーニングシステムが稼働すること
  • 新しい（当時5.X系）のMySQLのデータベースに対応していること
• 【セキュリティ】
  • 共用サーバーだとしてもスパム業者などがあまり借りていないこと
  • セキュリティポリシーがしっかりしており、弊社側で殆ど考慮しなくてもよいこと
  • 万が一があった時も電話などサポートが充実していること
• 【コスト】
  • 月額１万円はきること
• 【パフォーマンス】
  • サーバーのパフォーマンスが良いこと（瞬間100セッション程度に耐えること）
• 【サーバー運用】
  • データベースに外部から接続できること（データ分析などが楽になるため） 
  • テスト環境が無料で構築できる＝マルチドメインに対応していること
  • メンテナンスフリーに近く、電話サポートが充実していること
  • 誰でも安心して管理画面を触れること（マニュアルが充実しているなど）
• 【数年後の予測】
  • サービスが成長した場合も、移行しなくても良いようなある程度スペックの良いサーバーであること
  • 万が一の時は、移行が簡単なサーバーであること

なぜBizメール＆ウェブからの変更を考え、CPIサーバーを調査したのか？

それまで使っていたBizメール＆ウェブは素晴らしいサービスでした。
ただ１点だけ「マルチドメインに対応していない＝テストサーバーを無料で構築できない」という問題がありました。

テストサーバーがないというのは、ウェブ上でサービスを展開する企業にとっては死活問題です。

この問題について悩んでいた当時、とあるセミナーでご一緒した方から「CPIサーバー」というレンタルサーバーがあることを教えてもらいました。
そして、そのレンタルサーバーの売りは「テストサーバーが標準でついてくる」ということだったのです。

当時CPIサーバーについては未調査だったので、帰ってから早速調査してみた結果、下記のことがわかりました。

【CPIサーバーの良い点】

• 自分で準備しなくてもテストサーバー機能がついてくる唯一のサーバー
• バックアップも自動で取得してくれるらしい
• セキュリティ意識が高く、電話サポートも充実しているらしい
• システム的な設定（htaccessなど）の柔軟性が高い。
• その他要件はほとんど満たしている

【CPIサーバーが要件を満たせない点】

• ネットで検索してもあまり情報がでてこないので誰でも触れるかはわからない
• セキュリティポリシーのため、外部からデータベースには接続できない

最終的にCPIサーバーを選んだ理由

CPIサーバーの調査の結果、完全に要件を満たすわけではなく、いろいろ他サーバーとの◯☓表をつけることも考えました。

しかし正直なところ、ほとんどの共用サーバーは使ったことがありますがどこも似たり寄ったりだと感じていましたし、それぞれ良いサービスだと感じていました。

そう感じていながらも１点、CPIサーバーが良いと思ったのは「ECなどウェブ上でサービスを展開する人のことを考えて作られている」ということでした。

他のレンタルサーバーにおいては汎用性を感じるのに対し、CPIサーバーは「ウェブ上でサービスを展開する企業」に特化してサービスを構築しているように感じました。

特にテストサーバーにこだわっていた私たちにとっては、痒い所に手が届くサービスのように感じ、またサービス運営元のKDDIウェブコミュニケーションズさんという信頼性も手伝い「これならばずっと継続したサービスを構築できるかもしれない」と判断しました。

要件を満たさない点には運用でカバーすることで目をつむることができたので、CPIサーバーを選んでまずは１年間運用してみることにしました。

それから2017年の今でも継続して使い続けています。

当初の「このサーバーであればずっと使い続けられる」という予想は当たっていたことになります。

実際にCPIサーバーを使ってみてどうなのか？

これは一言でいえば「満足」といえるかと思います。
大きく３つ理由がありますので、それぞれご説明したいと思います。

１．フルバックアップを自動で取得してくれる＆リカバリが簡単

CPIサーバーは自動で毎日バックアップが深夜に取得されます。
取得される世代数はどんどん増えて、今では１ヶ月分あるように思います。
私たちは直近に戻すこと以外でバックアップからのリカバリをしたことがありませんが、これが本当にありがたいですし、何度かお世話になっています。

前述したように、ウェブ担当者通信のサイトはWordPressで作成されています。有料メンバー向けサービスもありますのでかなりカスタマイズをしており、安意にWordPressのバージョンアップができません。
適当にバージョンアップをすると動かなくなってしまうこともあります。

しかし一方、ご存じの方も多いと思いますが、WordPressはセキュリティ面の強化という意味でもバージョンアップは必須となっており、特に脆弱性が発見されたときは急いで対応しなくてはなりません。

こういった緊急時で作業ミスをしてしまった場合などにも、バックアップがあれば元に戻すことができます。

「簡単に戻る」のがポイント

バックアップを自動取得しているレンタルサーバーは他にもいくつかあります。
CPIサーバーのバックアップ機能の良さは「誰でも簡単にボタン１つで戻せる」ことだと思います。この簡単さは他に見たことがありません。

▼SmartReleaseという機能名です。

▼ボタンひとつでバックアップもリストアもできます。

バックアップの心理的障壁は「元に戻るのか？」「ちゃんとバックアップを取得できているのか？」という点です。
ウェブ担当者通信には過去にインフラのエンジニアをしていた人間もいますが、その人間でもバックアップから手動で戻すのは緊張します。
それが「ボタン一つで自動で戻る」ところにCPIサーバーの価値があると感じています。

正直このバックアップ機能だけでもサーバー費用の元がとれたと思うことが多いです。

２．電話サポートがある

サーバーを運用していると、なぜか急にレスポンスが悪くなったり、どのようにサーバーを設定すべきかわからなくなる時があります。

そういったサーバートラブルが発生したときに、CPIサーバーであれば電話で問合せすることができます。
しかも電話が繋がらないということがなく、結構早く電話に出てくれます。

電話サポートの受付時間は、平日の10:00〜18:00ですが、サーバー知識のある方が対応してくれるので、ある程度技術的な質問に対しても概ね満足のいく回答をもらえます。

これがメールで問合せをしなくてはいけないと、質問の仕方がまずければ無駄なメールを何回もしなくてはいけない可能性もあり、特に緊急時は非常に時間の無駄になります。

これと同様のレベルを電話問合せを実現しているレンタルサーバーは、知っているところだと「スピーバー」と「エックスサーバー」になりますが、そちらと比べてもかなりレベルの高いサポートをしてもらえると感じています。

３．マルチドメイン対応とテスト環境

CPIサーバーはマルチドメインに対応しています。ドメイン追加に費用はかかりません。

したがって、いくつでもサイトをもつことができるので、それを利用してウェブ担当者通信では開発サーバーを設置しています。

マルチドメイン対応自体は珍しいことではなく、他のレンタルサーバーも対応していることが多いです。そのなかでもCPIサーバーは、どのドメインもパフォーマンスが良いように感じます。
ただし、これは厳密に計測をしているわけではないですし、共用サーバーに同居している他のサイトにもよると思いますので一概にはいえません。

テスト環境

またCPIサーバー独自の機能として、テスト環境がついてくるというものがあります。
これはマルチドメインとは違い、一つのドメインを作成すると勝手にテストサーバーが作成されるという機能です。

▼詳しい説明は公式ページから。
www.cpi.ad.jp/shared/smartrelease/

このテストサーバーのイメージは下記の構成に近いです。
データベースは本番サーバーと共通ですが、HTMLは別に設置できます。

このテストサーバー機能により、WordPressの本番データを使ったサイトリニューアルのテストなどが実施できます。

ただし注意点としては、データベースが共通ですので、テスト環境といえどもデータベースに影響のある作業は一切実行してはいけません（例えばプラグインやテンプレートの変更など）。
あくまでファイルを上書きする形でリニューアルのテストを実行していきます。

このあたりの機能を有効に使っていくには、ある程度WordPressのシステム的な知識があることが前提になってくると思います。

ウェブ担当者通信の環境

ウェブサイトでは、開発環境、ステージングサーバー（本番アップ前の確認用）、本番サーバーの３つを用意すると運用がうまくいきやすいです。

ウェブ担当者通信では、マルチドメイン機能を使って開発環境を作成し、テスト環境を使ってステージングサーバーを設置しています。
つまり追加コストなしで３つの環境を簡単につくれることがCPIサーバーのメリットだと感じてます。

他のサーバーと比べてどうなのか？

さて、大きく３つの機能をお伝えしましたが、この機能が他のレンタルサーバーにないかというと、完全に調べ尽くせてはいません。
ウェブ担当者通信の編集部が把握しているレンタルサーバーとしては下記があります。

• エックスサーバー
• さくらインターネット
• ロリポップ
• お名前ドットコムサーバー
• アルファメール
• Bizメール＆ウェブ
• スピーバー

把握している理由は、実際に他のサイト制作で使用していたり、相談をうけたことがあるからです。
どのレンタルサーバーも良いサービスだと感じていますので、オススメは用途によって違うと思います。

※プレミアムメンバーの方は相談サービス「1on1相談」で相談してもらえればご回答します。

ウェブ担当者通信のサービス内容・使用用途の場合であれば、CPIサーバーを選択して良かったと思っています。

「運用後」が重要

ウェブ担当者通信はウェブ上のサービスですので、開発を続けていかなくてはなりませんし、その開発で長期間停止するわけにもいきません。

そのためには開発環境が用意できたり、バックアップから戻せることが何よりも重要でした。

また語弊があるといけませんが、CPIサーバーは他のレンタルサーバーと比べて安価ではありません。
しかし、安価ではないからこそ、それほど多くのユーザーがスパム的に使う可能性は低く、ビジネスで使っていて安心感があります。

また、セキュリティアップデートもちゃんと対応されていて、サーバーの安全性という意味でも有利な気がします。

実はこのことには、CPIサーバーに移行してサービス開始・運用してから気づきました。

総じてなのですが、CPIサーバーは運用後のことをより重視しているサービスに感じます。
使ってみてはじめてわかる「よかった」が多いレンタルサーバーだと思います。

CPIサーバーの不満点は？

概ね満足しているCPIサーバーにも不満点はあります。
大きくは３つです。

１．一般のブログに情報が少ない

CPIサーバーは比較的プログラマーに優しい設計で、PHPのバージョン指定などマニアックな設定が柔軟に対応可能です。

ところが残念ながら、そのマニアックな設定情報がなかなかウェブ検索をしても見つかりません。
情報が見つからない場合は、電話サポートに聞いたり、一般的なサーバー知識をもとに解決したりする必要があります。

ただし、これは初期設定の時がほとんどですので、運用中はあまり気にならないかもしれません。

ブログに情報が少ない理由は、CPIサーバーをビジネスで利用されていることが多いせいかもしれません。
ビジネス利用している人はわざわざブログに技術情報をアップしないことが多いからです。

２．激安ではない

ウェブ担当者通信が使用しているCPI の共用サーバーサービス「シェアードプラン ACE01」は、月額3,800円（税別）のサービスです。
オプションになっているSSL証明書などの設定は、年間数万円かかります。
また、DNSの設定に関してネームサーバーをレンタルした場合、やはり年間数万円がかかってきます。

何かカスタマイズしようと思ったときに、年間数万円単位で費用がかかってしまうので、判断に悩みやすいサーバーだといえます。

多くのオプションサービスが無償から用意されているような月額1,000円程度の安価なレンタルサーバーを選択すれば、単純なサーバー維持費という意味では費用を抑えることができます。

３．データベースに外部から接続できない

CPIサーバーは設定が柔軟で、PHP周りの細かい設定など含めて多くのことができます。

その分欲も出てくるのですが、1点だけデータベース周りの操作については、管理画面のphpMyAdminを使って操作しなくてはなりません。

データベースに貯まったデータを分析したり、開発効率をあげるためにデスクトップ上のアプリケーションからデータベースに接続して作業をしたいところなのですが、CPIサーバーの場合にはこのようなことは行えず、管理画面のphpMyAdminを使ってデータベースに接続します。

これは共用サーバーなので、セキュリティ面からみると幾分しかたがないところがあると思います。
しかし、ウェブサービスを構築する場合にかなり良い選択肢になり得るCPIサーバーだからこそ、このデータベース周りの仕様が残念になります。

CPIサーバーを勧めたいユーザーは？

総じてですが、CPI の共用サーバーサービス「シェアードプラン ACE01」は「今後、毎月10万人くらいまでの人にウェブ上でサービスを展開したい」と考える人にとっては良い選択肢ではないかと思います。

特に、WordPressを含めてデータベースやPHPを使ったプログラムが稼働する場合に、使ってから「良かった」といえるサービスが多くありますし、サーバーパフォーマンスもなかなか良いのでおすすめです。
他に運用後をここまで見据えたサーバーをしりません。

逆に、飲食店のホームページなど、毎月3,000人程度の人に見てもらうサイトや、多少停止しても信用に問題ないサービス、一回作って終わりといったウェブサイトの場合は、CPIサーバーを使うメリットがあまりないかもしれません。

やはりCPIサーバーは、運用後を見据えたサポートの良さを活用し、耐久性のある「サービス」を継続して展開していきたい場合に、設定の柔軟さを含めて向いていると思います。

別の言い方をすれば、「開発は多少絡むが、AWSなど専用サーバーを設定したりメンテナンスするほどの手間をかけたくない」といったニーズにはとてもマッチしているレンタルサーバーだと思います。

スタートアップのサーバーを探しており、サービスが大きくなってきたら別サーバーを検討するといった場合にも、かなり安価で質のよい選択肢となるのではないかと思います。

最新のおすすめプラグインはこちら
→Web運用本の著者にも聞いた！WordPressサイトで絶対導入すべきおすすめプラグイン3選と注意するポイント【2021年版】

最後に

この記事では、我々が使用しているCPI の共用サーバーサービス「シェアードプラン ACE01」について率直な感想をお伝えいたしました。
もし記事でよくわからないことがある場合は、コメント欄に記載頂ければ回答いたします。

なお、今後も我々が使用しているツールに関しては、折を見て率直な感想をレビューしていきたいと思っています。
楽しみにしていてください。