その日、ウェブライダーでは、システム担当の宮本と広江が、メンバーに何かの情報を共有しようとしていた。
皆さん、集まっていただきありがとうございます。
今日ミーティングを開かせていただいたのは、今回、うちがCPIさんのレンタルサーバーへ乗り換えた経緯について、あらためて社内でも共有しておきたかったからです。
今後、すべてのメンバーが自社サイトの管理を担当する可能性があるので、今回借りるサーバーの仕様や特長について、しっかり知っておいてもらいたいと思います。
レンタルサーバーの知識を全社的に深めておくことは大事だよね。
例の「CSD事件」の苦い記憶もあるから・・・。
「CSD事件」とは、以前、ウェブライダーが巻き込まれた、レンタルサーバーを巡るトラブルのことである。
そのサーバートラブルの頭文字をとって、ウェブライダー社内では「CSD事件」と呼ばれている。
事件の詳細は、後ほど宮本の口から語られるので、このまま読み進めてほしい。
・・・そうなんです。
「CSD事件」の悲劇を繰り返さないためにも、皆にサーバーの知識を共有しておきたいと思いました。
では早速、今回のレンタルサーバーの乗り換えの経緯について、順を追って説明していきます。
ウェブライダーはなぜ、レンタルサーバーをCPIサーバーに乗り換えたのか？
今回、うちがレンタルサーバーの乗り換えを検討した理由は、次のような目的を達成するためでした。
ウェブライダーがレンタルサーバーの乗り換えを検討した理由
- サイトの立ち上げ・更新といった運用を効率化したい
（例：テスト環境を準備しやすくする） - 更新時に起こりうる人的トラブルを未然に防ぎたい
（例：誤ってファイルを上書きしてしまったとき、迅速に復旧できるように） - サーバーに詳しい担当者がいなくても、さまざまな設定ができるようにしたい
- 万が一のサーバートラブル時の被害を最小限にしたい
（例：メールサーバーとWebサーバーを分けておきたい） - アクセス集中時、「503エラー」が出るリスクを下げたい
そして、これらの目的を達成するために、サーバーに求めた要件は次のようなものです。
ウェブライダーが求める、理想的なレンタルサーバーの要件
- テスト環境をすぐに用意できるだけでなく、本番環境への反映がラクになる仕組みがある
- 毎日、データが自動でバックアップされる
- バックアップされたデータは本体とは別の場所へ保存される
- コントロールパネルが使いやすい
- メールサーバーとWebサーバーが分けられている
- サーバートラブル時のサポート対応が充実している
- アクセスが集中したとき、「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事件」について共有してもらった理由は、皆さんに「バックアップの大切さ」を知ってもらうことです。
あのとき、テスト環境やバックアップがあったからよかったものの、実は一部のデータは最新ではありませんでした。
だから、バックアップの仕組みを導入するのであれば、日常的にバックアップされること。
そして、サイトが公開されているサーバーの筐体とは「別の筐体」にバックアップされることが重要です。
宮本さんの話を繰り返すけれど、大事なのは、バックアップが「別の筐体」のディスクに保存されるってこと。
なぜなら、バックアップ用のディスクが存在していたとしても、そのディスクが同じ筐体の中にある場合、その筐体ごと壊れてしまうと元も子もなくなるから。
だから、あくまでも「別の筐体」のディスクに保存されることが大前提。
その点、CPIさんの共用サーバーは安心です。
CPIさんに確認したところ、CPIサーバーの自動バックアップ機能は、別の筐体のディスクにバックアップされるとのことです。
そして、CPIサーバーの場合、Webサーバーとメールサーバーも別々の筐体だから、一台のサーバーを借りているようで、ある意味、複数台のサーバーを借りているのと同じともいえる、と。
よくよく考えたら、すごく贅沢な構成・・・。
すみません・・・。
さっきから気になっていることがあって・・・。
先ほど教えていただいた「CSD事件」のとき、うちのサービスが一時的に止まったということなんですが、その間の損害って、サーバー会社が補償してくれたんでしょうか？
いやいや、補償はされていない。
というのも、一般的なレンタルサーバーの利用規約では、そういった損害の補償は限定的になるから。
サーバー会社によって利用規約は違うけれど、だいたい月額費用の範囲で、「保証稼働率」を下回ったときのみ、稼働できなかった時間分の費用を返金するという形なんだよね。
え・・・。
じゃあ、たとえ1,000万円の損害が発生したとしても、実際に補償してもらえる金額は、月額のサーバー利用費の一部だけということになるんですね・・・。
場合によっては数百円とか・・・。
そのとおり。
だから、レンタルサーバーは本当に気をつけて選んでね。
何度も言うとおり、レンタルサーバーは機械だから、障害は起こりうるものとして捉えておこう。
そのためにも、バックアップや保守運用に目を向けておくほうがいいんだ。
わかりました・・・！
私の友人がネットショップを運営しているので、バックアップには気をつけるよう伝えておきます。
ここでもう一度、先ほど取り上げた、我々にとって理想的なレンタルサーバーの要件を見てみます。
ウェブライダーが求める、理想的なレンタルサーバーの要件
- テスト環境をすぐに用意できるだけでなく、本番環境への反映がラクになる仕組みがある
- 毎日、データが自動でバックアップされる
- バックアップされたデータは本体とは別の場所へ保存される
- コントロールパネルが使いやすい
- メールサーバーとWebサーバーが分けられている
- サーバートラブル時のサポート対応が充実している
- アクセスが集中したとき、「503エラー」が出にくい
このうち、まだ話せていないのが、「1」と「4」と「7」あたりですね。
まず、「7」の「アクセスが集中したとき、503エラーが出にくい」については、松尾さんが以前、CPIさんのサイト内で書いたこの記事を読んでもらうといいでしょう。
トラフィックが多く集まりそうなサイトを運用する上では、503エラーに関する知識は必須です。
503エラーを防ぐ！Web屋が知っておくべき503エラーの原因と対処
はい！
読んでおきます。
続いて、「1」の「テスト環境をすぐに用意できるだけでなく、本番環境への反映がラクになる仕組みがある」についてですが、実はこの点もCPIさんのサーバーを借りることで解決します。
というのも、CPIさんには、テスト環境と本番環境の同期がカンタンにできる「SmartRelease（スマートリリース）」という機能があるからです。
詳しい説明は、CPIさんのサイトにあるページを読んでおいてほしいのですが、カンタンに言えば「テスト環境でつくったサイトを、カンタンな操作で本番環境に反映できる」という機能です。
うちは今まで、テスト環境の構築は、Basic認証を使ったり別契約のサーバーを使ったり、さらにはサブドメインを設定したりと、案件ごとに手間をかけて用意していました。
ただ、その方法だと、サーバーまわりに詳しくない人がテスト環境を用意しづらく、制作のフットワークに支障が出ていました。
今回、CPIさんのサーバーに移行することで、その手間も解消できます。
「SmartRelease（スマートリリース）」を使ったサイトの更新については、実際に制作を進める中でみんなに試してもらうつもり。
多分、すぐに慣れると思うけど、前もってページに書かれている内容を確認しておいてね。
わかりました！
では、最後の「4．コントロールパネルが使いやすい」についても説明しておきます。
CPIサーバーは昨年、コントロールパネルが一新されて、かなり使いやすくなりました。
また、使いやすいだけでなく、コントロールパネル上で、さまざまな設定がカンタンにできます。
今回、広江さんが、CPIサーバーのコントロールパネル上でさまざまな設定をするためのマニュアルをつくってくれました。
このマニュアルの内容は「外部サーバーからCPIサーバーへの移行」に関する内容が中心になっていますが、参考になると思います。
今後、うちのお客さまの案件で、CPIさんの共用サーバーへ移行する場合には、ぜひこのマニュアルをもとに移行作業を進めるようにしてください。
私、レンタルサーバーのコントロールパネルに苦手意識があったから、使いやすいのはうれしい。
では、私がつくったマニュアルを見せますね。
これですぐに乗り換えられる！
他社サーバーからCPIの共用サーバーへ乗り換える手順
私が用意したマニュアルは、こんなふうにスライド形式になっています。
他社のサーバーからCPIの共用サーバーへ移転したい場合は、このマニュアルを読んでもらえればカンタンにできると思います。
他社サーバーからCPIサーバーへの「移転マニュアル」をダウンロードする
今日はせっかくなので、マニュアルの中で取り上げている内容をこの場で解説しておきますね。
CPIサーバーへのサイト移行の手順（ウェブライダー編）
-
CPIサーバーの申し込みと設定
- これまでに使っていたドメインを用いて、CPIサーバーを契約する
- コントロールパネルにログインする
- FTPアカウントを作成
- WAFを有効にしておく
- マイページにログインし、SSLを申し込む
- 旧サイトからのデータの移行
- 旧サーバーのファイルをFTP経由でダウンロード
- FTPを経由して、CPIサーバーのテストサイトにアップロード
- 旧サーバーから「データベース」のデータをエクスポート
- CPIサーバー内にデータベースをつくり、データをインポート
- WordPress上で「データベース」を設定する
- 各種の細かな調整
- WordPressの「wp-config.php」でデータベース情報を更新
- Basic認証をかける
- テストサイトで動作確認する
- SmartReleaseを使って、テストサイトのデータを本番サイトへコピー
- テストサイトから公開サイトへコピーする
- Basic認証の削除
- 既存のメールアカウントを作り直す
- メールアカウントとパスワードを整理する
- CPIサーバーでメールアカウントを作成する
- ドメインの切り替え
- DNS切り替え
- メールサーバーの再設定
1.CPIサーバーの申し込みと設定
1-1．これまでに使っていたドメインを用いて、CPIサーバーを契約する
まずは、CPIのサイトで「法人向け共用レンタルサーバー（シェアードプラン）」である「SV-Basic」を契約する流れを説明します。
今回のウェブライダーの場合、サイトの引越しなので、ドメインは既に取得済み。
そのため、ドメイン所有の有無は「レンタルサーバーのみのご契約」を選択します。
ドメインも取得したい場合は「ドメイン取得代行＋レンタルサーバーご契約」を選択しましょう。
申し込みをして、しばらく待つと、CPI側でサーバーの設定が完了したというメールが届きます。
1-2．コントロールパネルにログインする
次に、メールに記載の情報を使って、コントロールパネルと呼ばれる画面に入ります。
この画面で諸々の設定を進めていきます。
1-3．FTPアカウントをつくる
ファイルをアップロードするために、FTPアカウントを作成します。
サイドメニューの「Web」のアイコンをクリックします。
すると、「公開サイト」のFTPアカウントの設定画面に移るので、「FTPアカウントを作成」をクリック。
必要な項目を入力し、「登録する」をクリック。
ここで登録した情報は、あとでFTPクライアントからCPIサーバーに接続するときに使用します。
よって、入力した情報はメモしておきましょう。
「公開サイト」のFTPアカウントの作成が完了したら、続いて、「テストサイト」のFTPアカウントを作成します。
上部のタブの「テストサイト」をクリックし、「FTPアカウントを作成」をクリック。
先ほどと同じようにFTPアカウントを作り、入力した情報はメモしておきます。
1-4．WAFを有効にしておく
続いて「WAF」を有効にしておきます。
「WAF」とは、 Web Application Firewallの略語で、Webアプリケーションへの攻撃に対するセキュリティ対策のひとつです。
「公開サイト」と「テストサイト」、両方のWAFの設定を「ON」にしておくのがオススメです。
1-5．マイページにログインし、SSLを申し込む
次はSSLを申し込みましょう。
SSLを申し込みするために、「マイページ」にログインします。
（ひとつ目のSSLは無料で契約できます。SSLについての詳しい解説はこちらの記事をお読みください）
マイページに入ると、このような画面が表示されます。
マイページ上部にある「ご契約一覧」をクリックし、ご契約一覧の画面を表示。
プラン情報上部にある「詳細」をクリックします。
契約内容が表示されるので、下部にあるメニューから、「オプション申し込み」をクリック。
オプション申し込み画面のオプション詳細から、SSLサーバー証明書のエリアの「このオプションを申し込む」をクリック。
下のラジオボタンは自動的にチェック状態になるので、画面下部の「次の画面へ進む」をクリック。
ご利用料金の確認画面になるので、「同意する」をクリックし、「次の画面へ進む」をクリック。
続いて、認証用のメールアドレスをプルダウンで選びます。
ドメインの登録担当者情報を入力します。
ドメインの登録担当者情報を入力後、「CP/CPSに同意する」にチェックを入れ、「次の画面へ進む」をクリック。
確認画面にて、内容を確認したあと、「お申し込み」をクリック。
その後、先ほど選択した管理者用メールアドレスに、申し込み確認のメールが届きます。
以下の件名のメールが届いたら、メール内にある長いURLをクリックし、アクセスしたページにある「承認」ボタンをクリック。
（件名の例：ドメイン認証型（DV）サーバー証明書発行手続きのご案内 [web-rider.jp]）
以下の画面が表示されれば、SSLの申し込みは完了です。
2.旧サイトからのデータの移行
では続いて、旧サーバー（旧サイト）から新サーバーへデータを移行します。
2-1．旧サーバーのファイルをFTP経由でダウンロード
旧サーバーにFTP接続し、CPIサーバーへ移行したいファイルをすべてダウンロードします。
（FTP接続には、FTPクライアントと呼ばれるソフトが必要ですので、任意のソフトを使ってください）
2-2．FTPを経由して、CPIサーバーのテストサイトにファイルをアップロード
先ほど作ったテストサイト用のFTPアカウントを使って、CPIサーバーのテストサイトにFTP接続。
ダウンロードした旧サーバーのファイルを、CPIサーバーのテストサイトにアップロードします。
2-3．旧サーバーから「データベース」のデータをエクスポート
今回、ウェブライダーのサイトでは、旧サイトで運用していたWordPressのデータベースも移行します。
旧サーバーのデータベースに、phpMyAdminなど使用可能なツールを使って接続。
まずは、データベースのデータをエクスポートします。
（phpMyAdminは、MySQLのデータベースの中身を視覚的に操作できるWebアプリケーションです）
2-4．CPIサーバー内にデータベースをつくり、データをインポート
旧サーバーのデータベースからエクスポートしたデータを、CPIサーバーに移します。
CPIサーバーのコントロールパネルにアクセスしたのち、「Web」メニューをクリックし「データベース」を選択。
そのあとで「MySQL」をクリックします。
「新規追加」をクリック。
新規データベース名に任意のアルファベットを入れて、「追加する」をクリック。
ここで作成したデータベースの名前は、WordPressのデータベースの情報を更新する際に使うので、メモしておきましょう。
MySQLの一覧画面に戻りますので、右上にある「MySQL***管理画面」をクリック。
（***にはバージョン名が入ります）
すると、CPIサーバー内にあるphpMyAdminのツールへ移動します。
先ほど旧サーバーからエクスポートしたファイルを選択し、インポートします。
これでWordPressのデータベースの移行は半分完了です。
（のちほど、WordPressに新しいデータベース情報を設定します）
このようなメッセージが表示されれば、インポートは成功です。
3.各種の細かな調整
ここからはサイト運用に備えた細かい設定をしていきます。
3-1．WordPressの「wp-config.php」でデータベース情報を更新
WordPressの設定ファイルである「wp-config.php」を編集します。
サーバーを移行すると、データベースの情報が新しくなるため、ファイル内の情報を更新します。
テストサイトのFTPに接続し、WordPressのあるディレクトリに移動。
「wp-config.php」をダウンロードし、中に書かれているデータベース情報を、CPIサーバーのデータベース情報に書き換えます。
データベース名は、本説明の「手順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サーバーのコントロールパネルに移動しましょう。
コントロールパネルの「Web」へ移動し、テストサイトの「アクセス制限（Basic認証）」→「アクセス制御の追加」をクリックします。
アクセス制限をしたいディレクトリを入力するなど、必須な項目を入力したあと、「追加する」をクリックすれば、Basic認証の設定は完了です。
ここで入力した情報はテストサイトでの動作確認に必要です。
ユーザー名とパスワードをメモしておきましょう。
.htaccessの編集についての注意点
「.htaccess」というファイルには、Basic認証だけでなく、リダイレクトの設定や、プログラムに関わる設定など、サイトにとって重要な設定が記述されている場合があります。
旧サーバーとCPIサーバーとでは、「.htaccess」の記述方法が違うことがあるため、注意しましょう。
もし、旧サーバーで使っていた「.htaccess」をそのまま使いたい場合は、CPIサーバーの「.htaccess」を、CPIサーバーでの記述に合わせて書き換えてください。
書き換える際は、「手順3-2」で新しく作られた「.htaccess」に、Basic認証以外の設定情報を追記します。
また、旧サーバーから引き継がれた設定の中で、不要な設定があれば削除します。
4．テストサイトで動作確認する
CPIの共用レンタルサーバー「SV-Basic」では、テスト環境を標準装備し、テストサイトから公開サイトへのファイルのアップロードをカンタンに実現する「SmartRelease（スマートリリース）」というツールが用意されています。
この「SmartRelease」を用いて、テストサイトを確認しましょう。
テストサイトのURLは「手順1-1」で届く【重要 CPIより】サーバー設定が完了いたしましたという件名のメールに記載されていますが、コントロールパネル内の「SmartRelease」の画面にも記載されています。
サイドバーの「SmartRelease」をクリックすると、SmartReleaseの画面が開きます。
一番上のテストサイトのリンクをクリックすると、テストサイトが開きます。
その際、「手順3-2」で設定したBasic認証がかかっていますので、メモしておいたユーザー名とパスワードを入力しましょう。
5．SmartReleaseを使って、テストサイトのデータを本番サイトへコピー
テストサイトでの動作確認が完了したら、SmartReleaseの画面で、テストサイトから公開サイトにコピーします。
5-1．テストサイトから公開サイトへコピーする
「手順4-1」と同じようにコントロールパネルから「SmartRelease」をクリックします。
SmartReleaseの画面が開くので、「今すぐ公開する」をクリック。
（※このあとの「手順7-1」のDNSの切り替え作業をするまでは、CPIサーバーではなく以前のサーバーが公開されたままですので、ご安心ください）
もし、テストサイトから公開サイトにコピーしたくないファイルやディレクトリがある場合は、この段階で「除外リストに追加」しておきましょう。
「すべてリリース」をクリックすると、テストサイトの、除外リストを除いたすべてのファイルが公開サイトにコピーされます。
しばらくして、「リリース完了しました」というメッセージが表示されたら、公開サイトへのコピーは完了です。
（※このあとの「手順7-1」のDNSの切り替え作業をするまでは、以前のドメインではまだサイトは公開されていません）
5-2．Basic認証の削除
SmartReleaseで「すべてリリース」をクリックした際、「.htaccess」が除外リストに含まれていない場合、Basic認証の設定も公開サイトにコピーされます。
そのためこのままだと、DNSを切り替えた際に、公開サイトにBasic認証がかかった状態になります。
よって、コントロールパネルからBasic認証を削除しておきます。
ウェブライダーのサイトの場合は、「.htaccess」の中にBasic認証以外のいろいろな設定を記述しているため、SmartReleaseで「すべてリリース」をクリックしたあとに、 「手順3-2」で設定したBasic認証の記述だけを削除します。
では、公開サイトからBasic認証を削除する手順についてお教えします。
Basic認証を削除する場合は、「.htaccess」を直接編集するのもありですが、コントロールパネルからカンタンに削除できます。
コントロールパネルの「Web」メニューをクリック、「公開サイト」を選び、「アクセス制御（Basic認証）」をクリック。
削除したいBasic認証の「×」をクリックすれば削除できます。
6．既存のメールアカウントを作り直す
旧サーバーで使っているメールアカウントを、CPIサーバーに移行します。
メールアカウントの移行は、スケジュールを決めて慎重におこなう必要があります。
DNS切り替え後に、「メールが受信できなくなった」、「数日間受信できていなかったことがあとでわかった」などのトラブルが起きないようにするためです。
切り替え後は、それぞれが普段使っているメールアプリ（GmailやThunderbirdなど）でも、再設定の作業が必要です。
そのため、Web制作会社やメールの設定に詳しい人と連携して作業しましょう。
以下では、ウェブライダーがおこなった手順をカンタンに紹介します。
6-1．メールアカウントとパスワードを整理する
メールアカウントを移行する際は、使用するメールアドレスだけを移行しましょう。
また、移行には、各メールアドレスのアカウント名（メールアドレスの@より前の部分）とそれぞれのパスワードが必要です。
（例：●●●●●@web-rider.jpの場合は、●●●●●がアカウント名です）
移行アカウントの数が多い場合は、CPIサーバーの「メールアドレスをCSVファイルから一括登録する機能」を使うのもありです。
詳しくは、メール機能に関する解説ページをご確認ください。
6-2．CPIサーバーでメールアカウントを作成する
コントロールパネルにログインして、サイドメニューから「Mail」を選び、「メールアカウント作成」をクリック。
もし一括登録したい場合は「一括登録・編集」をクリックします。
メールアカウントとパスワードなどを入力し、「追加する」をクリック。
パスワードは普段使うメールソフトでの設定に必要なので、メモをしておきましょう。
（メールアプリのメールサーバー情報を書き換えないと、以前のメールアドレスでの送受信ができないので、ご注意ください）
このあと、使用しているメールアプリ上で、メールサーバー、メールアカウント名、パスワードの再設定をおこないます。
詳しくは「手順7-2」で説明します。
7.ドメインの切り替え
7-1．DNS切り替え
DNSとは、Domain Name Systemの略で、ドメインとサーバー側のIPアドレスを関連付けるために使用されるシステムです。
このDNSを切り替えないと、CPIサーバーのIPアドレスが、ドメインに割り当てられません。
DNSの切り替えをおこなえば、ドメインに割当てられたIPアドレスが、旧サーバーからCPIサーバーのものに変わります。
DNS切り替えをおこなってから、完全に切り替わるまで数時間～3日ほどかかります。
その時間が過ぎれば、CPIサーバーで準備したサイトの内容が公開され、サーバー移行が完了します。
それでは、DNSの切り替え作業を進めましょう。
まず、CPIサーバーの「ネームサーバー」をメモします。
ネームサーバーは「手順1-1」で確認した【重要 CPIより】サーバー設定が完了いたしましたという件名のメールに記載されています。
次に利用しているドメイン管理サービスで、先ほどメモしたネームサーバーを設定すれば完了です。
（お使いのドメイン管理サービスごとに管理画面が異なるため、詳しくはお使いのドメイン管理サービスの管理画面をご確認ください）
7-2．メールサーバーの再設定
各個人の使用しているメールアプリ（GmailやThunderbird）で、メールアカウント名、パスワード、メールサーバーの再設定をおこないます。
組織全体でメールアプリの再設定をおこなう場合は、担当者を決めて、全社で取り組むことがオススメです。
まず、メールサーバーの情報を確認しましょう。
メールサーバーの情報は、「手順1-1」で確認した【重要 CPIより】サーバー設定が完了いたしましたという件名のメールに記載されています。
次に、各個人の使用しているメールアプリ（GmailやThunderbird）で、「手順6-2」で作成したメールアカウント名とパスワード、先ほど確認したメールサーバーの情報を用いて、メールアドレスの再設定をおこないます。
設定方法については、各メールアプリによって異なるため、ここでは個々の設定方法については割愛させていただきます。
注意点としては、「手順7-1」で説明したように、DNS切り替えが完了するまで数時間～3日程度はかかるということです。
その間は、旧サーバー・新サーバーの両方またはどちらか一方にメールが届きます。
メールアドレスを再設定したあとは、必ず、何度かテストメールを送受信して、無事にメールアドレスが使えているかを確認しましょう。
広江さん、ありがとう。
具体的なサーバー移転の流れが理解できたよ。
こういったバックヤードまわりの情報は、共有できるときに共有しておくと、いざというとき安心ですね。
レンタルサーバーまわりもスッキリしたことですし、あとは新サイトの完成を待つのみですね・・・！
よし・・・！！
頑張るしかないっ！！！
レンタルサーバーの移転を完了させたウェブライダーの面々。
サーバーを移転すること、それはすなわち、ビジネスの砦を変えるということでもあった。
自分たちが理想とする地盤を手に入れた彼らは、果たして、どこまで高く飛び上がることができるのか・・・！？
彼らの自社サイトリニューアルはいよいよクライマックスを迎えようとしていた・・・！
次回、大改善！劇的Webリニューアル
第六話「サイトが変われば会社も変わる。サイトリニューアルが教えてくれたこと」
