11月某日

京都オフィス

その日、ウェブライダーでは、システム担当の宮本と広江が、メンバーに何かの情報を共有しようとしていた。

話す宮本

ウェブライダー 宮本

皆さん、集まっていただきありがとうございます。
今日ミーティングを開かせていただいたのは、今回、うちがCPIさんのレンタルサーバーへ乗り換えた経緯について、あらためて社内でも共有しておきたかったからです。

ウェブライダー 広江

今後、すべてのメンバーが自社サイトの管理を担当する可能性があるので、今回借りるサーバーの仕様や特長について、しっかり知っておいてもらいたいと思います。

ウェブライダー 松尾

レンタルサーバーの知識を全社的に深めておくことは大事だよね。
例の「CSD事件」の苦い記憶もあるから・・・。

説明しよう!

「CSD事件」とは、以前、ウェブライダーが巻き込まれた、レンタルサーバーを巡るトラブルのことである。
そのサーバートラブルの頭文字をとって、ウェブライダー社内では「CSD事件」と呼ばれている。
事件の詳細は、後ほど宮本の口から語られるので、このまま読み進めてほしい。

ウェブライダー 広江

・・・そうなんです。
「CSD事件」の悲劇を繰り返さないためにも、皆にサーバーの知識を共有しておきたいと思いました。

ウェブライダー 宮本

では早速、今回のレンタルサーバーの乗り換えの経緯について、順を追って説明していきます。

ウェブライダーはなぜ、レンタルサーバーをCPIサーバーに乗り換えたのか?

ウェブライダー 宮本

今回、うちがレンタルサーバーの乗り換えを検討した理由は、次のような目的を達成するためでした。

ウェブライダーがレンタルサーバーの乗り換えを検討した理由

  1. サイトの立ち上げ・更新といった運用を効率化したい
    (例:テスト環境を準備しやすくする)
  2. 更新時に起こりうる人的トラブルを未然に防ぎたい
    (例:誤ってファイルを上書きしてしまったとき、迅速に復旧できるように)
  3. サーバーに詳しい担当者がいなくても、さまざまな設定ができるようにしたい
  4. 万が一のサーバートラブル時の被害を最小限にしたい
    (例:メールサーバーとWebサーバーを分けておきたい)
  5. アクセス集中時、「503エラー」が出るリスクを下げたい
ウェブライダー 宮本

そして、これらの目的を達成するために、サーバーに求めた要件は次のようなものです。

ウェブライダーが求める、理想的なレンタルサーバーの要件

  1. テスト環境をすぐに用意できるだけでなく、本番環境への反映がラクになる仕組みがある
  2. 毎日、データが自動でバックアップされる
  3. バックアップされたデータは本体とは別の場所へ保存される
  4. コントロールパネルが使いやすい
  5. メールサーバーとWebサーバーが分けられている
  6. サーバートラブル時のサポート対応が充実している
  7. アクセスが集中したとき、「503エラー」が出にくい
ウェブライダー 宮本

図で表すとこんな感じですね。

サイト制作で使用するサーバーの図

ウェブライダー 広江

結論からいうと、今回乗り換えを決めたCPIさんの共用レンタルサーバー「SV-Basic」には、うちが必要とする要件がすべて揃っていました。

話す広江

ウェブライダー 宮本

まるでうちのために設計されたのでは・・・と思うくらいに、今回のサイトリニューアルの要件にピッタリ合っています。

ウェブライダー 広江

ただ、私たちがもともと借りていたレンタルサーバーよりも、月々の費用が2,000円くらい上がります。
・・・とはいえ、月3,800円なので、その価格でいろいろな要件を満たせるのなら、とてもリーズナブルだと思います。

ウェブライダー 松尾

なるほど。

ウェブライダー 宮本

そして何より、トラブル発生時の不安をかなり取り除けます。

デフォルトで10GBまで「30世代の自動バックアップ」が対応されている点、バックアップデータが別の筐体(きょうたい)に格納される点、さらにはWebサーバーとメールサーバーが分けられている点などが、とにかく安心です。

ウェブライダー 広江

Webサーバーとメールサーバーが一緒だと、Webサーバーにトラブルが起きたとき、メールも送れなくなってしまうんです。

普段うちはGmailを使っていて、案件に合わせてドメインの違うメールアドレスや、専用のメールサーバーを使ってますよね。
たとえば、●●●@web-rider.comと●●●@web-rider.jp、さらには●●●@seo-keni.jpがあるように。

うちのようにいろいろなメールアドレスを使っている場合、Webサーバーとメールサーバーが分かれているレンタルサーバーだと安心です。

ウェブライダー 松尾

そうか、そういう点も考慮しておく必要があるんだね。
たしかに、有事のときにメールが送れなくなってしまうのは大変だ・・・。

ウェブライダー 宮本

はい。
Webサーバーとメールサーバーが一緒だと、Webサーバーにトラブルが起きたときに大変なことになります。

一般的なレンタルサーバーは、Webサーバーとメールサーバーが一緒になっているケースが多いのですが、Webサーバーと連動してメールサーバーに起こるトラブルってあまり知られていないんです。

ウェブライダー 広江

そう。
だから今日、みんなに伝えたいのは、起こりうるトラブルを知らずにレンタルサーバーを選ぶと、あとで想定外のトラブルに巻き込まれるということ。

実は多くの人が、後々トラブルが起きてから「なぜ、もっと慎重にレンタルサーバーを選ばなかったんだろう・・・」と後悔しがち。

そうなる理由のほとんどは、多くの人が「レンタルサーバーってどれを使っても、あまり変わらないのでは?」という考えをもっていることにあります。

ウェブライダー 松尾

たしかに。

僕もよく「サイトを作りたいけれど、サーバーを借りるとしたら、どこが一番安いですか?」という質問をされることがある。
そんな質問をされる理由はきっと、価格以外はどこのサーバーもあまり変わらないと思っているからだと思う。

ウェブライダー 広江

そうなんですよね。
レンタルサーバーの理解って、専門的な知識が必要になるから、多くの人があまりよくわからずに選んでしまっている気がします。

意外と多いパターンが、制作会社から「サーバーはこのレンタルサーバーでいいですか?」と提案されて、よくわからずに契約してしまうパターン。

もちろん制作会社は、自社のお客さまにとってベストだと思うレンタルサーバーを提案しているはずですが、制作会社がレンタルサーバーにあまり詳しくないケースもあるので注意が必要です。

ウェブライダー 松尾

そうだね。
うちも「CSD事件」で大変な目に遭ってからというもの、レンタルサーバー選びには今まで以上に敏感になったし。

あとは「いまどきのSEOはページの表示スピードが大事だと聞いたから、とにかく、ページの表示スピードが早いレンタルサーバーでお願いします!」という理由で決めるケースなんかもあるね。

このケースはとても危ない。

そもそもSEOについて「ページ表示スピード」だけを軸にして語るのも気になるんだけど、いまどき、そこそこの金額帯のレンタルサーバーを選べばページの表示スピードにはそんなに差がなかったりするし、大事なのは、有事のときにそのサーバー会社がどんな対応をしてくれるかということだからね。

多くの人が、レンタルサーバーで起きる不慮のトラブルまで想定して選んでいないから、いざトラブルが起きると、てんやわんやになるという・・・。

「まさか、自分たちの会社に限って、そんなトラブルに巻き込まれないだろう・・・」という根拠のないバイアスがかかっているとマズイ。

話す松尾

ウェブライダー 宮本

とてもよくわかります。
レンタルサーバー選びって、ある種の保険選びに近い気がします。

ウェブライダー 広江

というわけで、そういった不安を防ぐためにも、今日はさっきから話に出ている「CSD事件」について、あらためて振り返っておきます。
ここ1年の間に入社したメンバーは初めて聞く話だと思うので、しっかり聞いておいてくださいね。

サイト制作において、レンタルサーバーをなんとなくで選んでしまうと、こんな大変なことに巻き込まれてしまうかも・・・という実話です。

サーバーエラーのイメージ

「CSD事件」・・・。

またの名を「クラウドサーバーダウン事件」。
それは数年前、私たちが巻き込まれた悲劇の出来事。

当時ウェブライダーでは、あるサーバー会社が提供していたクラウドサーバーを借り、そこで「賢威」や「文賢」といった、自社の各種サービスを提供していました。

そんなある日の休日、私は実家に帰省して、のんびりと休んでいました。
まさかあんなトラブルが起きるなんて、つゆほども思わずに・・・。

その日の夜、トラブルは突然起きました。

私宛ての緊急メールアドレスに、サーバーのエラー時に自動で送られるメールが届いたのです。
「サーバーに何か異常が起きた?」私は即座に各サービスのページを見に行きました。

すると、どのサービスのページも開きません。

同じタイミングで、「賢威」や「文賢」のお客さまから「サービスのページへアクセスができない」という問い合わせメールがたくさん届き始めました。

一時的なサーバー障害はよくあること。
よって私はまず、サーバー会社のサイトの「障害情報」を見に行き、状況を確認しようと思いました。

しかし、状況を確認しに行った結果、私は唖然とします。
なぜなら、サーバー会社が発表していた障害情報は「現在状況を確認しています」というシンプルな言葉のみだったからです。

やがて、同じクラウドサーバーを借りている他のユーザーさんたちが、SNSでざわざわと発言し始めました。

  • ・明らかに大規模なトラブルなのに、サーバー会社から詳しい状況説明がないんだけど・・・。
  • ・復旧の目途に関する情報がなかなか公開されないので、対処のしようがないな・・・。
  • ・うちは制作会社なんだけど、サイトを納品したお客さまから「自社のサイトが開かなくなっているので、すぐに状況を報告してほしい」という電話がかかってきた。
    でも、サーバー会社からの状況報告がない以上、どう報告すればいいかわからない・・・。
  • ・深夜なのに、まさか会社に出社する羽目になるとは思っていなかった・・・。
    出社したはいいけれど、サーバー会社からの報告がないので、さっきからずっと待機中・・・。

障害発生から数時間が経っているにもかかわらず、ホスティング会社からの状況報告はほとんどありませんでした。
そのため、何が起きているのかがまったくわからず、混乱は広まる一方。

状況がわからずに待たされている人の中には、上司とクライアントの間に板挟みになり、針のむしろ状態で時間を過ごしていた人も多かったと思います。

私もそんなひとりでしたが、うちの場合、社内メンバーや外部パートナーと連携しながらトラブルと向き合えていたので、まだ救われました。

結局、私たちが借りていたクラウドサーバーの一部が復旧したのは数日後でした。
その間、ホスティング会社からの状況報告は数時間おきの断片的なものばかり。

数日間、私たちはお客さまへの謝罪や問い合わせ対応に追われました。

そして事態は、最悪の形で収束します。

トラブル発生後から数日後、サーバー会社からようやく今回の障害の原因が発表されました。
その原因は「ストレージのハードウェア障害」というもの。

サーバーのイメージ

どうやらトラブルの原因は、サーバーのデータが格納されたSSDストレージ(すなわちディスク)が物理的に壊れ、アクセスできなくなったことにあるようでした。

どんな機械も必ず壊れます。
物理的な破損ということで「サーバー会社さんも運が悪かったのだろう・・・」と私は同情したのですが、問題はそこからでした。

ハードウェアが物理的に壊れたため、「SSDストレージの中にあるデータの復旧がほとんどできない」ことがわかったのです。

「え・・・」

私を含め、ウェブライダーの全メンバーが言葉を失いました。

なぜなら、売上げの根幹となっている各種サービスのデータは、そのクラウドサーバーの中にあったからです。
データが復旧できないとなると大損害です。
会社がつぶれるかどうかの危機的な事態となりかねません。

しかし、うちの場合は最悪な事態を逃れることができました。

というのも、うちの開発体制では複数のテスト環境を利用しており、GitHubも使っています。
そのため、私たちは障害のさなか、別のサーバーにて新たに本番環境を準備し、データ移行を進めることができたのです。

ただし、新たな本番環境の準備やデータ移行に伴い、イレギュラーな作業が発生しました。
作業にともない、慌ただしい日々が3日ほど続きました。

もし、外部にテスト環境を用意していなかったらと思うと、今もぞっとします。

ウェブライダー 赤木

怖いですね・・・。

ウェブライダー 藤原

データが復旧できてよかったです・・・。

もし復旧できていなかったら、うちのサービスを使ってくださってるお客さまにサービスを提供し続けることができなくなってしまいますし、会社もつぶれていたかもしれないんですよね・・・。

話す藤原

ウェブライダー 宮本

そうですね・・・。

ウェブライダー 広江

正直なところ、どんなサーバーも機械である以上、何らかのトラブルは起きると考えておいたほうがいいです。

ただ、大事なのは、サーバー会社はサーバーという「筐体」だけを提供しているわけでなく、契約者を不安にさせないという「サービス」も提供しているはずだということです。

「CSD事件」は情報が錯綜(さくそう)し、多くの人が困惑した出来事でした。
当時、上司やクライアントとの板挟みになった方は、大変だったろうと思います。

もちろん一番大変だったのは、そのサーバー会社のエンジニアですが、障害発生時は、その原因がわからないにしても、状況報告はもっとあったほうがありがたいと感じました。

有事のときの配慮ひとつで、契約者の安心感は大きく変わると思います。

ホスティング会社はサーバーという「筐体」だけを提供しているわけではない

ウェブライダー 宮本

ちなみに、今回乗り換えるCPIさんの場合、障害が起きたときは、可能なかぎり細かく通知することを目標としているそうです。

ウェブライダー 広江

それはありがたいですね。
状況報告がこまめにあるだけでも、どれだけ精神的に救われるか・・・。

ちなみに、24時間365日電話サポートのオプションがあるのもいいなと思いました。

電話で状況を聞けるだけで、担当者は上司やクライアントへの報告が可能になります。
とくに、普段から上司やクライアントの板挟みになりやすい人は助かるのではないかと。

ウェブライダー 宮本

そうですね。
あと、もう一点、CPIさんから教えてもらったことがあります。

筐体のメンテナンス時、ハードウェアに怪しいところがあったときは、ハードウェアを部分的に入れ替えるのではなく、筐体そのものを入れ替えるようにしているそうです。

ウェブライダー 広江

筐体そのものを入れ替える・・・!?
それは安心ですね。

ウェブライダー 宮本

はい。
細かくハードウェアを入れ替えて様子を見るよりも、筐体そのものを入れ替えるほうが、ほかのハードウェアに原因があった場合のリスクを取り除けるとか。
ただ、その分、コストはかかっていそうですが・・・。

ウェブライダー 松尾

・・・なるほどね。

レンタルサーバーの事業って、正直、どの会社も差別化しづらいように感じていたけれど、細かな配慮の積み重ねで差別化できるんだなって気がついた。
この話、ビジネスにおける価値のつくりかたにおいても、すごく参考になるなあ。
まさに「機能的価値」と「情緒的価値」の融合だ。

話す松尾

ウェブライダー 宮本

そうですね。
我々のビジネスにも参考になることが多いです。

ウェブライダー 宮本

さて、少し話を戻そうと思います。

今回、広江さんから「CSD事件」について共有してもらった理由は、皆さんに「バックアップの大切さ」を知ってもらうことです。

あのとき、テスト環境やバックアップがあったからよかったものの、実は一部のデータは最新ではありませんでした。

だから、バックアップの仕組みを導入するのであれば、日常的にバックアップされること。
そして、サイトが公開されているサーバーの筐体とは「別の筐体」にバックアップされることが重要です。

バックアップに必要な条件1.バックアップは手動ではなく、自動で毎日おこなわれるほうがよい2.バックアップは、別の筐体のディスクに保存されるほうがよい

ウェブライダー 広江

宮本さんの話を繰り返すけれど、大事なのは、バックアップが「別の筐体」のディスクに保存されるってこと。

なぜなら、バックアップ用のディスクが存在していたとしても、そのディスクが同じ筐体の中にある場合、その筐体ごと壊れてしまうと元も子もなくなるから。
だから、あくまでも「別の筐体」のディスクに保存されることが大前提。

ウェブライダー 宮本

その点、CPIさんの共用サーバーは安心です。
CPIさんに確認したところ、CPIサーバーの自動バックアップ機能は、別の筐体のディスクにバックアップされるとのことです。

ウェブライダー 広江

そして、CPIサーバーの場合、Webサーバーとメールサーバーも別々の筐体だから、一台のサーバーを借りているようで、ある意味、複数台のサーバーを借りているのと同じともいえる、と。
よくよく考えたら、すごく贅沢な構成・・・。

ウェブライダー 藤原

すみません・・・。
さっきから気になっていることがあって・・・。

先ほど教えていただいた「CSD事件」のとき、うちのサービスが一時的に止まったということなんですが、その間の損害って、サーバー会社が補償してくれたんでしょうか?

ウェブライダー 広江

いやいや、補償はされていない。
というのも、一般的なレンタルサーバーの利用規約では、そういった損害の補償は限定的になるから。

サーバー会社によって利用規約は違うけれど、だいたい月額費用の範囲で、「保証稼働率」を下回ったときのみ、稼働できなかった時間分の費用を返金するという形なんだよね。

ウェブライダー 藤原

え・・・。
じゃあ、たとえ1,000万円の損害が発生したとしても、実際に補償してもらえる金額は、月額のサーバー利用費の一部だけということになるんですね・・・。
場合によっては数百円とか・・・。

ウェブライダー 広江

そのとおり。

だから、レンタルサーバーは本当に気をつけて選んでね。

何度も言うとおり、レンタルサーバーは機械だから、障害は起こりうるものとして捉えておこう。
そのためにも、バックアップや保守運用に目を向けておくほうがいいんだ。

レンタルサーバーは機械なので障害はつきものだと考える だからこそバックアップや保守運用に目を向けておく

ウェブライダー 藤原

わかりました・・・!
私の友人がネットショップを運営しているので、バックアップには気をつけるよう伝えておきます。

ウェブライダー 宮本

ここでもう一度、先ほど取り上げた、我々にとって理想的なレンタルサーバーの要件を見てみます。

ウェブライダーが求める、理想的なレンタルサーバーの要件

  1. テスト環境をすぐに用意できるだけでなく、本番環境への反映がラクになる仕組みがある
  2. 毎日、データが自動でバックアップされる
  3. バックアップされたデータは本体とは別の場所へ保存される
  4. コントロールパネルが使いやすい
  5. メールサーバーとWebサーバーが分けられている
  6. サーバートラブル時のサポート対応が充実している
  7. アクセスが集中したとき、「503エラー」が出にくい
ウェブライダー 宮本

このうち、まだ話せていないのが、「1」と「4」と「7」あたりですね。

まず、「7」の「アクセスが集中したとき、503エラーが出にくい」については、松尾さんが以前、CPIさんのサイト内で書いたこの記事を読んでもらうといいでしょう。

トラフィックが多く集まりそうなサイトを運用する上では、503エラーに関する知識は必須です。

503エラーに関する記事

503エラーを防ぐ!Web屋が知っておくべき503エラーの原因と対処

ウェブライダー 藤原

はい!
読んでおきます。

ウェブライダー 宮本

続いて、「1」の「テスト環境をすぐに用意できるだけでなく、本番環境への反映がラクになる仕組みがある」についてですが、実はこの点もCPIさんのサーバーを借りることで解決します。

というのも、CPIさんには、テスト環境と本番環境の同期がカンタンにできる「SmartRelease(スマートリリース)」という機能があるからです。

スマートリリースのスクリーンショット

SmartRelease(スマートリリース)について

ウェブライダー 宮本

詳しい説明は、CPIさんのサイトにあるページを読んでおいてほしいのですが、カンタンに言えば「テスト環境でつくったサイトを、カンタンな操作で本番環境に反映できる」という機能です。

うちは今まで、テスト環境の構築は、Basic認証を使ったり別契約のサーバーを使ったり、さらにはサブドメインを設定したりと、案件ごとに手間をかけて用意していました。

ただ、その方法だと、サーバーまわりに詳しくない人がテスト環境を用意しづらく、制作のフットワークに支障が出ていました。

今回、CPIさんのサーバーに移行することで、その手間も解消できます。

ウェブライダー 広江

「SmartRelease(スマートリリース)」を使ったサイトの更新については、実際に制作を進める中でみんなに試してもらうつもり。
多分、すぐに慣れると思うけど、前もってページに書かれている内容を確認しておいてね。

ウェブライダー 赤木

わかりました!

話す赤木

ウェブライダー 宮本

では、最後の「4.コントロールパネルが使いやすい」についても説明しておきます。

CPIサーバーは昨年、コントロールパネルが一新されて、かなり使いやすくなりました。
また、使いやすいだけでなく、コントロールパネル上で、さまざまな設定がカンタンにできます。

今回、広江さんが、CPIサーバーのコントロールパネル上でさまざまな設定をするためのマニュアルをつくってくれました。

このマニュアルの内容は「外部サーバーからCPIサーバーへの移行」に関する内容が中心になっていますが、参考になると思います。

今後、うちのお客さまの案件で、CPIさんの共用サーバーへ移行する場合には、ぜひこのマニュアルをもとに移行作業を進めるようにしてください。

ウェブライダー 伊藤

私、レンタルサーバーのコントロールパネルに苦手意識があったから、使いやすいのはうれしい。

話す伊藤

ウェブライダー 広江

では、私がつくったマニュアルを見せますね。

これですぐに乗り換えられる!
他社サーバーからCPIの共用サーバーへ乗り換える手順

ウェブライダー 広江

私が用意したマニュアルは、こんなふうにスライド形式になっています。

CPIサーバーへのサイト移行の具体的な手順

ウェブライダーが今回実行した、旧サーバーからCPIへの移行手順

ウェブライダー 広江

他社のサーバーからCPIの共用サーバーへ移転したい場合は、このマニュアルを読んでもらえればカンタンにできると思います。

他社サーバーからCPIサーバーへの「移転マニュアル」をダウンロードする

ウェブライダー 広江

今日はせっかくなので、マニュアルの中で取り上げている内容をこの場で解説しておきますね。

CPIサーバーへのサイト移行の手順(ウェブライダー編)

  1. CPIサーバーの申し込みと設定
    1. これまでに使っていたドメインを用いて、CPIサーバーを契約する
    2. コントロールパネルにログインする
    3. FTPアカウントを作成
    4. WAFを有効にしておく
    5. マイページにログインし、SSLを申し込む
  2. 旧サイトからのデータの移行
    1. 旧サーバーのファイルをFTP経由でダウンロード
    2. FTPを経由して、CPIサーバーのテストサイトにアップロード
    3. 旧サーバーから「データベース」のデータをエクスポート
    4. CPIサーバー内にデータベースをつくり、データをインポート
    5. WordPress上で「データベース」を設定する
  3. 各種の細かな調整
    1. WordPressの「wp-config.php」でデータベース情報を更新
    2. Basic認証をかける
  4. テストサイトで動作確認する
  5. SmartReleaseを使って、テストサイトのデータを本番サイトへコピー
    1. テストサイトから公開サイトへコピーする
    2. Basic認証の削除
  6. 既存のメールアカウントを作り直す
    1. メールアカウントとパスワードを整理する
    2. CPIサーバーでメールアカウントを作成する
  7. ドメインの切り替え
    1. DNS切り替え
    2. メールサーバーの再設定

1.CPIサーバーの申し込みと設定

1-1.これまでに使っていたドメインを用いて、CPIサーバーを契約する

まずは、CPIのサイトで「法人向け共用レンタルサーバー(シェアードプラン)」である「SV-Basic」を契約する流れを説明します。

これまでに使っていたドメインを用いて、CPIサーバーを契約する1

これまでに使っていたドメインを用いて、CPIサーバーを契約する2

今回のウェブライダーの場合、サイトの引越しなので、ドメインは既に取得済み。
そのため、ドメイン所有の有無は「レンタルサーバーのみのご契約」を選択します。
ドメインも取得したい場合は「ドメイン取得代行+レンタルサーバーご契約」を選択しましょう。

申し込みをして、しばらく待つと、CPI側でサーバーの設定が完了したというメールが届きます。

これまでに使っていたドメインを用いて、CPIサーバーを契約する3

1-2.コントロールパネルにログインする

次に、メールに記載の情報を使って、コントロールパネルと呼ばれる画面に入ります。
この画面で諸々の設定を進めていきます。

1-2.コントロールパネルにログインする

1-3.FTPアカウントをつくる

ファイルをアップロードするために、FTPアカウントを作成します。
サイドメニューの「Web」のアイコンをクリックします。

1-3.FTPアカウントをつくる1

すると、「公開サイト」のFTPアカウントの設定画面に移るので、「FTPアカウントを作成」をクリック。

1-3.FTPアカウントをつくる2

1-3.FTPアカウントをつくる3

必要な項目を入力し、「登録する」をクリック。
ここで登録した情報は、あとでFTPクライアントからCPIサーバーに接続するときに使用します。
よって、入力した情報はメモしておきましょう。

「公開サイト」のFTPアカウントの作成が完了したら、続いて、「テストサイト」のFTPアカウントを作成します。
上部のタブの「テストサイト」をクリックし、「FTPアカウントを作成」をクリック。
先ほどと同じようにFTPアカウントを作り、入力した情報はメモしておきます。

1-3.FTPアカウントをつくる4

1-4.WAFを有効にしておく

続いて「WAF」を有効にしておきます。
「WAF」とは、 Web Application Firewallの略語で、Webアプリケーションへの攻撃に対するセキュリティ対策のひとつです。
「公開サイト」と「テストサイト」、両方のWAFの設定を「ON」にしておくのがオススメです。

1-4.WAFを有効にしておく

1-5.マイページにログインし、SSLを申し込む

次はSSLを申し込みましょう。
SSLを申し込みするために、「マイページ」にログインします。
(ひとつ目のSSLは無料で契約できます。SSLについての詳しい解説はこちらの記事をお読みください)

1-5.マイページにログインし、SSLを申し込む1

マイページに入ると、このような画面が表示されます。

1-5.マイページにログインし、SSLを申し込む2

1-5.マイページにログインし、SSLを申し込む3

マイページ上部にある「ご契約一覧」をクリックし、ご契約一覧の画面を表示。
プラン情報上部にある「詳細」をクリックします。

1-5.マイページにログインし、SSLを申し込む4

契約内容が表示されるので、下部にあるメニューから、「オプション申し込み」をクリック。

1-5.マイページにログインし、SSLを申し込む5

オプション申し込み画面のオプション詳細から、SSLサーバー証明書のエリアの「このオプションを申し込む」をクリック。
下のラジオボタンは自動的にチェック状態になるので、画面下部の「次の画面へ進む」をクリック。

1-5.マイページにログインし、SSLを申し込む6

ご利用料金の確認画面になるので、「同意する」をクリックし、「次の画面へ進む」をクリック。

1-5.マイページにログインし、SSLを申し込む7

続いて、認証用のメールアドレスをプルダウンで選びます。

1-5.マイページにログインし、SSLを申し込む8

1-5.マイページにログインし、SSLを申し込む9

ドメインの登録担当者情報を入力します。

1-5.マイページにログインし、SSLを申し込む10

1-5.マイページにログインし、SSLを申し込む11

ドメインの登録担当者情報を入力後、「CP/CPSに同意する」にチェックを入れ、「次の画面へ進む」をクリック。

1-5.マイページにログインし、SSLを申し込む12

1-5.マイページにログインし、SSLを申し込む13

確認画面にて、内容を確認したあと、「お申し込み」をクリック。

1-5.マイページにログインし、SSLを申し込む14

1-5.マイページにログインし、SSLを申し込む15

その後、先ほど選択した管理者用メールアドレスに、申し込み確認のメールが届きます。
以下の件名のメールが届いたら、メール内にある長いURLをクリックし、アクセスしたページにある「承認」ボタンをクリック。

(件名の例:ドメイン認証型(DV)サーバー証明書発行手続きのご案内 [web-rider.jp])

1-5.マイページにログインし、SSLを申し込む16

以下の画面が表示されれば、SSLの申し込みは完了です。

1-5.マイページにログインし、SSLを申し込む17

2.旧サイトからのデータの移行

では続いて、旧サーバー(旧サイト)から新サーバーへデータを移行します。

2-1.旧サーバーのファイルをFTP経由でダウンロード

旧サーバーにFTP接続し、CPIサーバーへ移行したいファイルをすべてダウンロードします。
(FTP接続には、FTPクライアントと呼ばれるソフトが必要ですので、任意のソフトを使ってください)

2-1.旧サーバーのファイルをFTP経由でダウンロード1

2-2.FTPを経由して、CPIサーバーのテストサイトにファイルをアップロード

先ほど作ったテストサイト用のFTPアカウントを使って、CPIサーバーのテストサイトにFTP接続。
ダウンロードした旧サーバーのファイルを、CPIサーバーのテストサイトにアップロードします。

2-2.FTPを経由して、CPIサーバーのテストサイトにファイルをアップロード

2-3.旧サーバーから「データベース」のデータをエクスポート

今回、ウェブライダーのサイトでは、旧サイトで運用していたWordPressのデータベースも移行します。
旧サーバーのデータベースに、phpMyAdminなど使用可能なツールを使って接続。
まずは、データベースのデータをエクスポートします。
(phpMyAdminは、MySQLのデータベースの中身を視覚的に操作できるWebアプリケーションです)

2-3.旧サーバーから「データベース」のデータをエクスポート

2-4.CPIサーバー内にデータベースをつくり、データをインポート

旧サーバーのデータベースからエクスポートしたデータを、CPIサーバーに移します。
CPIサーバーのコントロールパネルにアクセスしたのち、「Web」メニューをクリックし「データベース」を選択。
そのあとで「MySQL」をクリックします。

2-4.CPIサーバー内にデータベースをつくり、データをインポート1

2-4.CPIサーバー内にデータベースをつくり、データをインポート2

「新規追加」をクリック。

2-4.CPIサーバー内にデータベースをつくり、データをインポート3

新規データベース名に任意のアルファベットを入れて、「追加する」をクリック。
ここで作成したデータベースの名前は、WordPressのデータベースの情報を更新する際に使うので、メモしておきましょう。

2-4.CPIサーバー内にデータベースをつくり、データをインポート4

MySQLの一覧画面に戻りますので、右上にある「MySQL***管理画面」をクリック。
(***にはバージョン名が入ります)

2-4.CPIサーバー内にデータベースをつくり、データをインポート5

すると、CPIサーバー内にあるphpMyAdminのツールへ移動します。
先ほど旧サーバーからエクスポートしたファイルを選択し、インポートします。
これでWordPressのデータベースの移行は半分完了です。
(のちほど、WordPressに新しいデーターベース情報を設定します)

2-4.CPIサーバー内にデータベースをつくり、データをインポート6

このようなメッセージが表示されれば、インポートは成功です。

3.各種の細かな調整

ここからはサイト運用に備えた細かい設定をしていきます。

3-1.WordPressの「wp-config.php」でデータベース情報を更新

WordPressの設定ファイルである「wp-config.php」を編集します。
サーバーを移行すると、データベースの情報が新しくなるため、ファイル内の情報を更新します。
テストサイトのFTPに接続し、WordPressのあるディレクトリに移動。

3-1.WordPressの「wp-config.php」でデータベース情報を更新1

「wp-config.php」をダウンロードし、中に書かれているデータベース情報を、CPIサーバーのデータベース情報に書き換えます。

3-1.WordPressの「wp-config.php」でデータベース情報を更新2

データベース名は、本説明の「手順2-4」でメモした内容です。
また、ユーザー名とパスワードは「手順1-1」でCPIサーバーから届くメールに記載されています。
書き換えたあと、上書き保存します。

これで、WordPressのデータベース情報の更新は完了です。

ちなみに、WordPressのデータベース情報を変えたこのままの状態では、テストサイトでのWordPressの表示確認はできません。
なぜなら、WordPress内部で設定されているドメイン(URL)が、テストサイトのドメイン(URL)と異なるからです。

テストサイト上でWordPressの表示を確認したい場合は、データベースを直接編集するか、CPIサーバー上で新規のWordPressを立ち上げ、データだけを移行するなど、データベースやWordPressの一定の知識が必要となります。

このあたりはサイトの運用状況によって最適な方法が変わるため、詳しい手順は省略します。

3-2.Basic認証をかける

テストサイトで動作確認をするにあたり、念のためBasic認証(アクセス制限)をかけます。
Basic認証をかければ、URLにアクセスした際に、ユーザー名とパスワードを求められるようになります。

Basic認証のためには「.htaccess」というファイルをつくる必要がありますが、CPIサーバーでは、そのファイルをコントロールパネルからカンタンにつくれます。

もし、CPIサーバーからアップロードしたファイルに「.htaccess」ファイルが含まれていた場合は、FTPで接続してファイル名を変更しておきましょう。

なぜなら、すでに「.htaccess」が存在している場合、コントロールパネルで設定したBasic認証が正常に動作しない場合があるからです。

まずは、CPIサーバーのコントロールパネルに移動しましょう。

3-2.Basic認証を再度つくる1

コントロールパネルの「Web」へ移動し、テストサイト「アクセス制限(Basic認証)」「アクセス制御の追加」をクリックします。

3-2.Basic認証を再度つくる2

アクセス制限をしたいディレクトリを入力するなど、必須な項目を入力したあと、「追加する」をクリックすれば、Basic認証の設定は完了です。
ここで入力した情報はテストサイトでの動作確認に必要です。
ユーザー名とパスワードをメモしておきましょう。

.htaccessの編集についての注意点

「.htaccess」というファイルには、Basic認証だけでなく、リダイレクトの設定や、プログラムに関わる設定など、サイトにとって重要な設定が記述されている場合があります。

旧サーバーとCPIサーバーとでは、「.htaccess」の記述方法が違うことがあるため、注意しましょう。
もし、旧サーバーで使っていた「.htaccess」をそのまま使いたい場合は、CPIサーバーの「.htaccess」を、CPIサーバーでの記述に合わせて書き換えてください。

書き換える際は、「手順3-2」で新しく作られた「.htaccess」に、Basic認証以外の設定情報を追記します。
また、旧サーバーから引き継がれた設定の中で、不要な設定があれば削除します。

4.テストサイトで動作確認する

CPIの共用レンタルサーバー「SV-Basic」では、テスト環境を標準搭載し、テストサイトから公開サイトへのファイルのアップロードをカンタンに実現する「SmartRelease(スマートリリース)」というツールが用意されています。
この「SmartRelease」を用いて、テストサイトを確認しましょう。

SmartRelease

テストサイトのURLは「手順1-1」で届く【重要 CPIより】サーバー設定が完了いたしましたという件名のメールに記載されていますが、コントロールパネル内の「SmartRelease」の画面にも記載されています。

4-1.テストサイトで動作確認する1

サイドバーの「SmartRelease」をクリックすると、SmartReleaseの画面が開きます。

4-1.テストサイトで動作確認する2

一番上のテストサイトのリンクをクリックすると、テストサイトが開きます。
その際、「手順3-2」で設定したBasic認証がかかっていますので、メモしておいたユーザー名とパスワードを入力しましょう。

5.SmartReleaseを使って、テストサイトのデータを本番サイトへコピー

テストサイトでの動作確認が完了したら、SmartReleaseの画面で、テストサイトから公開サイトにコピーします。

5-1.テストサイトから公開サイトへコピーする

5-1.SmartReleaseでテストサイトから公開サイトにコピーする1

「手順4-1」と同じようにコントロールパネルから「SmartRelease」をクリックします。

5-1.SmartReleaseでテストサイトから公開サイトにコピーする2

SmartReleaseの画面が開くので、「今すぐ公開する」をクリック。
(※このあとの「手順7-1」のDNSの切り替え作業をするまでは、CPIサーバーではなく以前のサーバーが公開されたままですので、ご安心ください)

5-1.SmartReleaseでテストサイトから公開サイトにコピーする3

もし、テストサイトから公開サイトにコピーしたくないファイルやディレクトリがある場合は、この段階で「除外リストに追加」しておきましょう。

5-1.SmartReleaseでテストサイトから公開サイトにコピーする4

「すべてリリース」をクリックすると、テストサイトの、除外リストを除いたすべてのファイルが公開サイトにコピーされます。

5-1.SmartReleaseでテストサイトから公開サイトにコピーする5

5-1.SmartReleaseでテストサイトから公開サイトにコピーする6

しばらくして、「リリース完了しました」というメッセージが表示されたら、公開サイトへのコピーは完了です。
(※このあとの「手順7-1」のDNSの切り替え作業をするまでは、以前のドメインではまだサイトは公開されていません)

5-2.Basic認証の削除

SmartReleaseで「すべてリリース」をクリックした際、「.htaccess」が除外リストに含まれていない場合、Basic認証の設定も公開サイトにコピーされます。
そのためこのままだと、DNSを切り替えた際に、公開サイトにBasic認証がかかった状態になります。
よって、コントロールパネルからBasic認証を削除しておきます。

ウェブライダーのサイトの場合は、「.htaccess」の中にBasic認証以外のいろいろな設定を記述しているため、SmartReleaseで「すべてリリース」をクリックしたあとに、 「手順3-2」で設定したBasic認証の記述だけを削除します。

では、公開サイトからBasic認証を削除する手順についてお教えします。
Basic認証を削除する場合は、「.htaccess」を直接編集するのもありですが、コントロールパネルからカンタンに削除できます。

5-2.Basic認証の削除

コントロールパネルの「Web」メニューをクリック、「公開サイト」を選び、「アクセス制御(Basic認証)」をクリック。
削除したいBasic認証の「×」をクリックすれば削除できます。

6.既存のメールアカウントを作り直す

旧サーバーで使っているメールアカウントを、CPIサーバーに移行します。

メールアカウントの移行は、スケジュールを決めて慎重におこなう必要があります。
DNS切り替え後に、「メールが受信できなくなった」、「数日間受信できていなかったことがあとでわかった」などのトラブルが起きないようにするためです。

切り替え後は、それぞれが普段使っているメールアプリ(GmailやThunderbirdなど)でも、再設定の作業が必要です。
そのため、Web制作会社やメールの設定に詳しい人と連携して作業しましょう。

以下では、ウェブライダーがおこなった手順をカンタンに紹介します。

6-1.メールアカウントとパスワードを整理する

メールアカウントを移行する際は、使用するメールアドレスだけを移行しましょう。

また、移行には、各メールアドレスのアカウント名(メールアドレスの@より前の部分)とそれぞれのパスワードが必要です。
(例:●●●●●@web-rider.jpの場合は、●●●●●がアカウント名です)

移行アカウントの数が多い場合は、CPIサーバーの「メールアドレスをCSVファイルから一括登録する機能」を使うのもありです。

詳しくは、メール機能に関する解説ページをご確認ください。

6-2.CPIサーバーでメールアカウントを作成する

6-3.CPIサーバーでメールアカウントを作成する1

コントロールパネルにログインして、サイドメニューから「Mail」を選び、「メールアカウント作成」をクリック。
もし一括登録したい場合は「一括登録・編集」をクリックします。

6-3.CPIサーバーでメールアカウントを作成する2

メールアカウントとパスワードなどを入力し、「追加する」をクリック。
パスワードは普段使うメールソフトでの設定に必要なので、メモをしておきましょう。
(メールアプリのメールサーバー情報を書き換えないと、以前のメールアドレスでの送受信ができないので、ご注意ください)

このあと、使用しているメールアプリ上で、メールサーバー、メールアカウント名、パスワードの再設定を行います。
詳しくは「手順7-2」で説明します。

7.ドメインの切り替え

7-1.DNS切り替え

DNSとは、Domain Name Systemの略で、ドメインとサーバー側のIPアドレスを関連付けるために使用されるシステムです。
このDNSを切り替えないと、CPIサーバーのIPアドレスが、ドメインに割り当てられません。

DNSの切り替えをおこなえば、ドメインに割当てられたIPアドレスが、旧サーバーからCPIサーバーのものに変わります。
DNS切り替えをおこなってから、完全に切り替わるまで数時間~3日ほどかかります。
その時間が過ぎれば、CPIサーバーで準備したサイトの内容が公開され、サーバー移行が完了します。

それでは、DNSの切り替え作業を進めましょう。

7-1.DNS切り替え1

まず、CPIサーバーの「ネームサーバー」をメモします。
ネームサーバーは「手順1-1」で確認した【重要 CPIより】サーバー設定が完了いたしましたという件名のメールに記載されています。

次に利用しているドメイン管理サービスで、先ほどメモしたネームサーバーを設定すれば完了です。
(お使いのドメイン管理サービスごとに管理画面が異なるため、詳しくはお使いのドメイン管理サービスの管理画面をご確認ください)

7-1.DNS切り替え2

7-2.メールサーバーの再設定

各個人の使用しているメールアプリ(GmailやThunderbird)で、メールアカウント名、パスワード、メールサーバーの再設定をおこないます。
組織全体でメールアプリの再設定をおこなう場合は、担当者を決めて、全社で取り組むことがオススメです。

6-4.CPIサーバーのメールサーバーを確認しておく

まず、メールサーバーの情報を確認しましょう。
メールサーバーの情報は、「手順1-1」で確認した【重要 CPIより】サーバー設定が完了いたしましたという件名のメールに記載されています。

次に、各個人の使用しているメールアプリ(GmailやThunderbird)で、「手順6-2」で作成したメールアカウント名とパスワード、先ほど確認したメールサーバーの情報を用いて、メールアドレスの再設定をおこないます。

設定方法については、各メールアプリによって異なるため、ここでは個々の設定方法については割愛させていただきます。

注意点としては、「手順7-1」で説明したように、DNS切り替えが完了するまで数時間~3日程度はかかるということです。
その間は、旧サーバー・新サーバーの両方またはどちらか一方にメールが届きます。
メールアドレスを再設定したあとは、必ず、何度かテストメールを送受信して、無事にメールアドレスが使えているかを確認しましょう。

ウェブライダー 松尾

広江さん、ありがとう。
具体的なサーバー移転の流れが理解できたよ。

ウェブライダー 広江

こういったバックヤードまわりの情報は、共有できるときに共有しておくと、いざというとき安心ですね。

ウェブライダー 宮本

レンタルサーバーまわりもスッキリしたことですし、あとは新サイトの完成を待つのみですね・・・!

ウェブライダー 松尾

よし・・・!!
頑張るしかないっ!!!

次回予告

レンタルサーバーの移転を完了させたウェブライダーの面々。
サーバーを移転すること、それはすなわち、ビジネスの砦を変えるということでもあった。
自分たちが理想とする地盤を手に入れた彼らは、果たして、どこまで高く飛び上がることができるのか・・・!?
彼らの自社サイトリニューアルはいよいよクライマックスを迎えようとしていた・・・!

次回、大改善!劇的Webリニューアル
第六話「サイトが変われば会社も変わる。サイトリニューアルが教えてくれたこと」

第六話「サイトが変われば会社も変わる。サイトリニューアルが教えてくれたこと」のイメージ図

今夜も我々のインデックスが加速するッ・・・!
今夜も我々のインデックスが加速するッ・・・!