アプリケーションに必要なソフトウェア、設定、リソースを共有環境で提供できず、サーバーを管理できる担当者がいる場合は、共有ホスティングからVPSへの移行を検討しましょう。アンマネージドVPSではゲストOSを自由に管理できます。その一方で、OSと内部のアプリケーションの保守もお客様の責任になります。
規模が大きくなったという理由だけで移行する必要はありません。具体的な制約、その影響を示す証拠、運用計画から検討を始めましょう。
共有ホスティングとは？WordPress・TYPO3・Joomlaホスティングを解説
共有ホスティングでは、複数のお客様のアカウントが事業者の運用するホスティング基盤とサーバーリソースを共有します。通常、サーバーOSを管理せずに、アカウント内でWebサイトを運営します。
プランにはWebホスティング、Webサイトホスティング、WordPressホスティング、TYPO3ホスティング、Joomlaホスティングなどの名称が使われます。CMS名は対応するアプリケーションを示すもので、必ずしもインフラを表しません。WordPressは共有ホスティングでもVPSでも動作します。名前だけでなくプランの内容を確認してください。
従来型のマネージドWebホスティングには、一般に次の機能が含まれます。
- WebサーバーとPHP：ページを配信し、対応するWebアプリケーションを実行します。
- データベースサービス：通常はMySQLまたはMariaDBを使い、CMSのコンテンツと設定を保存します。
- ファイルアクセス：プランに応じてFTP、FTPS、SFTP、ブラウザー上のファイル管理機能を提供します。暗号化された方法を選びましょう。
- メール（多くの場合付属）：IMAPまたはPOP3による受信、SMTPによる送信、場合によってはWebメールを利用できます。メールが別サービスの場合もあります。
事業者は付属するサーバーサービスを保守し、お客様はサイトのコンテンツ、利用者、設定を管理します。「フルマネージド」でも、CMS、プラグイン、拡張機能、テーマの更新、互換性テスト、サイトの復元まで含むとは限りません。各作業の担当を確認してください。WordPressのホスティングガイドでは、更新とバックアップを、事業者が提供する場合のある追加機能として扱っています。
アンマネージドVPSは運用方式が異なります。Web環境を自分で導入・保守するか、担当者を手配します。サイト用の管理パネルやメールサービスが自動的に付属するわけではありません。メールを別のサービスに残したまま、Webサイトだけを移行することもできます。
判断のための簡単な確認
- 共有ホスティングを継続：サイトが安定し、提供ソフトウェアが要件を満たし、ホスティング環境の保守を任せられる点を重視する場合。
- まず調査と最適化：症状がサイトの遅さだけなら、インフラを変更する前にキャッシュ、大きすぎる画像、プラグイン、データベースクエリ、外部サービスを確認します。
- VPSを検討：確認済みの制約が必要な作業を妨げており、ご自身または指定した管理者がセキュリティ、保守、復旧を担当できる場合。
共有ホスティングとアンマネージドVPSの比較
共有ホスティングの内容はさまざまです。現在の事業者の実際の制限とサービス範囲を確認してください。以下は一般的な構成の比較であり、すべての共有ホスティング製品について保証するものではありません。
| 項目 | 共有ホスティング | アンマネージドVPS |
|---|---|---|
| ソフトウェアの自由度 | 事業者が対応するソフトウェアとバージョンから選択。 | ゲストOSとサービスの制限内で、対応ソフトウェアを導入可能。 |
| rootアクセス | 通常は利用不可。アクセスは自分のアカウント内に制限。 | 仮想サーバーのOSに対する管理者権限。 |
| リソースの制約 | 事業者が定めるアカウント容量とプロセス制限。 | プランの割り当て量に加え、ソフトウェアと基盤による制限。 |
| 管理 | 事業者がホスティング基盤を、お客様がWebサイトを保守。 | お客様がゲストOS、サービス、アプリケーションを管理。 |
| セキュリティ更新 | 事業者が基盤を更新。アプリケーション更新には別途担当者が必要。 | お客様がゲストOSとアプリケーションの更新を計画・実行。 |
| バックアップ | 付属の有無、保存期間、復元方法はプラン次第。 | バックアップと復旧の手順を自分で用意し、テスト。 |
| 運用総費用 | 利用料に加え、追加機能とアプリケーション保守の費用。 | サーバー、管理作業、バックアップ、監視、ソフトウェアライセンスの費用。 |
VPSは仮想マシンであり、専用の物理サーバーではありません。vCPUの割り当てを、物理CPUコアの独占予約と解釈しないでください。基盤となるサービスを比較する際は、EDIS GlobalのKVM VPSの仕組みをご覧ください。
VPSが実際の問題を解決できる兆候
共有基盤にないソフトウェアが必要
必要なランタイム、システムパッケージ、Docker、データベース拡張をアカウントで利用できない場合があります。まずホストが対応しているか確認しましょう。対応する環境を自分で導入・設定する必要がある場合、VPSが適しています。
常時実行するプロセスが必要
共有環境では、バックグラウンドワーカー、キュー、常駐サービス、定期実行ジョブが制限される場合があります。VPSでは自分で設定し、障害を監視し、暴走したプロセスによるメモリ枯渇を防ぎます。
測定で確認したリソース上限が作業を繰り返し妨げる
繰り返すメモリエラー、プロセス制限、CPU負荷をログと測定結果で調べます。まず最適化し、その後に候補VPSで代表的な処理をテストしてください。サーバーを大きくしても、遅いクエリが自動的に改善するわけではありません。
デプロイをより細かく管理したい
独自のWebサーバー設定、再現可能なデプロイ、ステージング環境が必要なら、VPSを選ぶ理由になります。依存関係と設定を記録してください。同じVPS内のステージングはリソースと障害リスクを共有するため、独立した復旧用インフラにはなりません。
共有ホスティングを続ける方がよい場合
標準的なサイト機能で十分で、応答時間も許容範囲なら、移行によって問題を解決できず作業だけが増える場合があります。設定変更や別の共有プランで、実際の制約をもっと簡単に解消できないか確認しましょう。
保守できる人がいなければ、アンマネージドVPSは適していません。管理パネルは一部の作業を支援しますが、更新、障害、復元に責任を持ってくれるわけではありません。有能な管理者の費用を確保するか、必要な作業を管理契約に含むサービスを選んでください。
自由度が増すと継続的な管理も必要
EDIS Globalは基盤インフラを管理し、お客様はVPSのゲストOSとアプリケーションを管理します。明示されたサポート範囲にはインフラの支援とトラブルシューティングの案内が含まれますが、サーバーにログインしてソフトウェアを導入したり、移行を実施したりする作業は含まれません。
移行前に、OSとアプリケーションの更新、管理者アクセス、ファイアウォール規則、TLS証明書と更新確認の担当を決めます。監視通知の受信者と、サービス停止時の対応も定めてください。設定メモと復旧手順はVPSの外から参照できる場所に保管しましょう。
バックアップには独立した計画が必要です。自動バックアップや即時スナップショットが付属するとは限りません。復旧可能なコピーをサーバー外に保存し、アクセスを保護して復元をテストしてください。EDIS Globalのバックアップ資料で現在のサービス範囲を、アンマネージドVPSの責任範囲ガイドで作業分担を詳しく説明しています。
測定結果に基づいてVPSの規模を決定
通常時と繁忙時の処理を測定します。定期ジョブ、インポート、バックアップは通常のページ表示より多くのリソースを使う場合があるため、含めてください。共有ホストで十分な指標が得られない場合は、アプリケーションの処理時間とログを収集し、実際に近いコピーで契約前にベンチマークを行います。
- CPU：圧縮、レポート生成、並列ワーカーを含め、継続負荷と短時間のピークを確認します。
- RAM：OS、アプリケーション、データベース、同時実行プロセスの必要量を合計し、デプロイ作業と負荷増加の余裕を確保します。
- ストレージ：運用データ、データベースの成長、ログ、一時ファイル、バックアップの一時保存を見込みます。同じディスクにしかないバックアップは、独立した復旧用コピーではありません。
- 通信量：ダウンロード、レプリケーション、サーバー外バックアップを含め、双方向の転送を見積もります。付属通信量とホストのアップリンク速度は別々に比較してください。
訪問者数からRAM容量を確実に算出する式はありません。同じ訪問者数でも、キャッシュした静的ページとデータベース処理の多いアプリケーションでは必要量が大きく異なります。必要量を見積もったうえで、2 GB VPSと4 GB VPSのページで現在の基本構成を比較してください。アクセス処理能力の保証として扱わないでください。有料アップグレードは基本リソースに追加され、別料金がかかります。選択したプランと決済時の合計を確認しましょう。
DNSを変更する前に移行を計画
- 依存関係とメールを把握。ランタイム、拡張機能、データベース、定期ジョブ、ファイル権限、DNSレコード、メールボックスを一覧化します。メールをどこに残すか決めてください。サイト移行にメール移行は必須ではありません。
- バックアップと復元テスト。ファイル、データベースのエクスポート、設定を保存します。そのバックアップでアプリケーションを再構築できるか確認してから利用してください。
- VPSの準備と保護。対応OSを選び、アクセスとファイアウォールを設定し、更新を適用して監視とバックアップを整えます。アクセスと管理の流れは導入ガイドをご覧ください。
- アプリケーションとTLSをテスト。認証、フォーム、アップロード、ジョブ、メール送信、証明書更新を確認します。ステージング用ホスト名やローカルのhostsファイルを使い、非公開のテストデータを外部に公開しないようにしてください。
- DNS変更と最終データ同期を調整。書き込み停止が必要ならメンテナンス時間を設けます。DNSキャッシュを考慮し、最新の変更を同期して、両方の環境で競合する書き込みを受け付けないようにします。
- 元に戻せる手段を確保。新環境を検証するまで旧環境を維持します。ロールバックの条件と、切り替え後に書き込まれたデータを戻す前に保全する方法を決めてください。
移行の成功とは、アプリケーションが動き、データに整合性があり、担当者が復旧できることです。新しいトップページが表示されるだけでは十分ではありません。
よくある質問
自動的に速くなるわけではありません。性能はアプリケーション、設定、利用可能なリソースによって決まります。ボトルネックを診断し、移行先の環境でテストしてください。リソースを増やしても、非効率なクエリー、大きすぎる画像、遅い外部サービスが自動的に改善するわけではありません。
実測したメモリー使用量、ソフトウェア構成、同時に動作するプロセス数を基に検討してください。OSの使用量と余裕分も見込みます。VPSが適切かどうかを一律に決められるRAM容量や訪問者数の基準はありません。
はい。現在のメールサービスが単独で継続利用できる場合は可能です。必要なメール関連DNSレコードを維持し、ウェブサイトの移行後に送受信を確認してください。古いホスティング契約を解約する前に、パッケージ内の依存関係をご確認ください。
サーバー運用のスキル、または担当者が必要です。更新、監視、セキュリティ、復旧を担当する人がいない場合は、本番サイトをアンマネージドVPSへ移す前に管理体制を整えてください。
アプリケーションに必要な環境を選び、次にリソースを比較しましょう。Linux VPSプランでOSの選択肢を確認するか、VPSホスティングの概要から拠点とプランを選べます。移行の判断は、確認可能な要件に基づいて行ってください。