サーバー移行プロジェクト：Webサーバーの切り替え（DNS・メールは現状維持）

2025年11月5日（水）

実績内容: サーバー移行プロジェクト：Webサーバーの切り替え（DNS・メールは現状維持）
種別: IT・システム開発
目的: 業務効率化 / コスト削減
期間: 短期（1〜3カ月）

概要

a-blog cms で構築されたWebサイトのWebサーバー機能のみを自社管理の旧サーバーから新サーバー（さくらインターネット）へ移行。メール（Google Workspace）およびDNS管理（自社）は旧体制を継続し、サービス（特にメール）を無停止で切り替えるプロジェクト。同時にサイトのリニューアルも行った。

要した時間

3週間ほど。

リニューアル前

ドメイン→自社管理
メール→Google Workspace
Webサーバー→自社管理VPS
旧サイトデザイン

リニューアル後（赤字が変更箇所）

ドメイン→自社管理
メール→Google Workspace
Webサーバー→さくらのレンタルサーバーへ引越し、負荷対策
- CDN導入（CDN導入は別のものが担当）
新サイトデザイン実装

サイトリニューアルについて見る

Webサーバーのみ切り替えを要した理由

2025/11/18の全国区テレビ放送（平日21時〜）に控え、アクセスの集中を防ぐため。自社のVPSサーバーに収容している他のサイトに影響を及ぼしかねないため、該当のサイトのみ、さくらインターネットのサーバーへと複製し、WebサーバーのDNSを切り替えを計画した。

切り替え作業のおおまかなフロー

自社サーバーの開発環境にて、サイトをリニューアル。
さくらインターネットのサーバーにて、PHPやバージョンを考慮しつつa-blog cmsをセットアップ。
自社サーバーにてリニューアルしたサイトをさくらインターネットサーバーへ複製。
さくらインターネット側のサーバーへドメインを追加（今回ネームサーバーは切り替えないのでネームサーバーの指定はしていない）。
DNSレコードの切り替え（社外のVPSサーバー管理者へ、自社管理のドメインでさくらインターネット側のAレコードの追加を依頼）。
切り替え後、TOPページを静的化（開発ツールのソースをコピペ）、画像や動画の容量を減少させ、サーバーへの負荷を減少させた。
cms側でのキャッシュ設定を最適にし、さらに.envでキャッシュの保存先を database から file および apcu（メモリ）に分散・変更したことで、データベースへの不要なアクセスを削減し、サーバー負荷の軽減とサイトの高速化を実現。（Redisは脆弱性が出ていたので使用しなかった。）

ぶつかった問題

【問題1】新サーバー環境構築
- データ複製は容量が大きく旧サーバーへの負荷が高いので、ブログ単位でエクスポートができず、a-blog cmsを手動で複製した。
  - 新サーバー（さくらインターネット）へのa-blog cmsデータ移行（セットアップ〜全データ複製）を手動で行い、複製が終わったあと動作検証
【問題2】 CMSの復旧・正常化
- config.server.php 初期化による Connection refused エラーの解消 (DBホスト設定の修正)。旧サーバーのconfig.server.php とデータベース接続情報を参考にし、復旧。
- root blog is not found エラーの解消 (DBテーブル接頭辞 DB_PREFIX の修正)
【問題3】 SSL証明書の事前発行（DNS認証の採用）
- ファイル認証（HTTP-01）の失敗（原因：Aレコードが旧サーバーを参照するため Not Found が発生）
- Webサーバー設定に依存しないDNS認証（DNS-01）へ方式を変更し、Aレコード切り替え前にSSL発行を完了
【問題4】本番DNS切り替えとドメイン修正
- 切り替え前の 404 Not Found エラー（CMSのドメイン不一致）を解消
  - さくらインターネットサーバーの初期ドメインを使用していたため、IPアドレスとドメインが不一致だった。
    - a-blog cms「ドメイン修正機能」を実行し、システム内のドメイン情報（config.server.phpとデータベースの情報）を一括置換・正常化して解消。
【問題5】サーバー 500 エラーのトラブルシューティング（キャッシュドライバーの復旧）
- サイトが**「HTTP ERROR 500（内部サーバーエラー）」**で突然ダウン。前日までは正常に動作していた。
- サーバー側（さくらインターネットなど）の自動メンテナンスにより、PHP の動作モードが（apcu が使える）「モジュール版」から（apcu が使えない）「CGI版」に切り替わってしまった可能性を鑑みて、file ドライバーに戻したことで、サイトは一旦復旧。ですが結果としてはレンタルサーバー側の一時的な障害でした。

結果

12万回のリクエスト（Hit） と 2.39GBのデータ送信 をすべてCDNが「肩代わり」してくれたおかげで、オリジン（さくらサーバー）は無風状態でいられました。CDNの無料枠で収まったそうです。

12万Hit: CDNが捌いた（サーバー負荷回避）
2.39GB: CDNが配った（帯域制限回避）
動画排除: 事前に消した（コスト激増回避）
サイト内のクラウドファウンディングで募金（22万）があった。

後日談：Cloudflareも検討していましたが、放送日当日に障害が起きていたそうで、そちらにしていたら、全て水の泡でした。さくらインターネットのCDNで、良かったです。