月620円でWP高速化＆Docker本番！シンVPS移行完全ガイド

共有サーバーで「表示が遅い」「Dockerが使えない」とモヤモヤしていませんか？

私も WordPress を5サイト運営しながら副業で Rails アプリを作る身。1台で両方をこなしたいのに、従来サーバーでは混雑タイムにレスポンスが落ち、CI もまともに回りませんでした。

――そこで乗り換えたのが シンVPS。オール NVMe SSD 採用で一般 SSDの約5.7倍という爆速 I/Oを実測しながら、月額620円から root 権限まで手に入る “丁度いい” VPS です。

この記事では 「ブログ高速化」×「Docker本番環境」 を同時に実現するステップを、ADHD 気質でもミスなく進められるチェックリスト形式で解説します。

3. WordPressをダウンタイムなしで移行する手順

3-1 移行前チェックリスト：プラグイン・PHP互換を確認

1. プラグイン互換
   • Site Health で「推奨PHPバージョン」を確認。
   • 古いClassic EditorなどPHP8非対応プラグインが残っていれば更新か代替案を検討。
2. ディスク使用量を把握
   • du -sh public_html で総容量、wp db size でDBサイズを確認。
   • 画像が肥大化していれば、移行前に「未使用メディア一括削除」を実施するとコピー時間を短縮できる。
3. PHPバージョン合わせ
   • 現行サーバーが7.4、シンVPSは8.2などギャップがある場合は、まず現行環境で8系テストを行い致命的エラーを先につぶす。

3-2 ステージング環境構築とバックアップ取得

• ステージングの目的：本番環境と同一条件で動作確認し、DNS切替前に不具合を検出。
• 手順
  1. シンVPS側でサブドメイン stg.example.com を作成し、Let’s EncryptでSSLを先に取得。
  2. BackWPup などで ファイル＋DBをzip化、S3/ローカルに二重保存。
  3. MySQLは mysqldump --single-transaction でロックを回避しつつエクスポート。

3-3 新VPSへのWPコピー：rsync / wp-cli / All-in-One比較

• 大容量サイトは rsync が最速。rsync -avz --progress で差分コピーを繰り返せば、DNS切替直前の“追い込み同期”が数十秒で済む。
• URL置換は wp search-replace 'https://example.com' 'https://stg.example.com' --skip-columns=guid が鉄板。

3-4 SSL設定とDNSカットオーバーの最適タイミング

1. Let’s Encrypt発行
   • 80番ポートを一時解放 → certbot --nginx -d example.com。
2. TTL短縮
   • 24時間前までにDNSのTTLを 300秒 に下げておくと“切替の実感”がほぼない。
3. ピーク外でAレコード変更
   • 夜間帯 PV が少ない時間（例23:00-01:00）にAレコードを新IPへ。
4. 混在コンテンツチェック
   • curl https://example.com -I で 301/200 を確認→WhyNoPadlock テストで残存HTTPリソースを洗い出す。

3-5 移行後チューニング：キャッシュ・画像圧縮・cron最適化

• Object Cache：Memcached/Redisを docker-compose.yml に同居させ、wp config set WP_REDIS_DISABLED false。
• 画像圧縮：Imagify で一括WebP変換→Cache-Control: max-age=31536000 をNginxで付与。
• cron整備：DISABLE_WP_CRON を true にし、OS側の crontab -e で5分おきに wp cron event run --due-now。

3-6 ロールバックプランとトラブルシューティング

• hostsファイル切替で自分だけ新サーバーを指し、問題なければDNS公開。
• 旧環境は 最低72時間保持。即戻せるように Aレコードを旧IPに書き戻す手順書を残しておくと安心。

4. Docker × シンVPS：本番デプロイまでの最短ワークフロー

4-1 Docker Compose ひな形：WP＋Rails を共存させる最小構成

version: "3.9"
services:
  db:
    image: mariadb:11
    environment:
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PW}
    volumes:
      - db_data:/var/lib/mysql

  wordpress:
    image: wordpress:6.5-php8.2-fpm
    depends_on: [db]
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: root
      WORDPRESS_DB_PASSWORD: ${DB_ROOT_PW}
    volumes:
      - wp_data:/var/www/html
    networks: [frontend]

  rails:
    build: ./rails
    env_file: .env
    depends_on: [db]
    networks: [frontend]
    command: bundle exec puma -C config/puma.rb

  nginx:
    image: nginx:alpine
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d
      - wp_data:/var/www/html
    depends_on: [wordpress, rails]
    ports:
      - "80:80"
      - "443:443"
    networks: [frontend]

volumes:
  db_data:
  wp_data:
networks:
  frontend:

• 単一ネットワークで WP と Rails を束ね、Nginx がポートとパスで振り分け。
• .env に API キーなどシークレットを置き、リポジトリには入れない。
• シンVPS 1GB プランなら上記 4 サービスで メモリ 600 MB 台、CPU 30 % 程度に収まり、ブログ PV 3万/月 ＋ 個人 SaaS の同居まで余裕。

4-2 CI/CD 自動化：GitHub Actions で push ⇒ 本番デプロイ

name: Deploy to VPS
on:
  push:
    branches: [ main ]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build images
        run: docker compose build
      - name: Push via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.VPS_IP }}
          username: root
          key: ${{ secrets.VPS_SSH_KEY }}
          script: |
            cd /srv/app && git pull
            docker compose up -d --build

• SSH 鍵を secrets に登録、IP 固定だから固定費不要。
• ビルドをローカル runner で済ませれば VPS 側は pull のみ、I/O 負荷が小さく速い。

4-3 ゼロダウンタイム更新：Blue-Green デプロイ手法

1. docker-compose.blue.yml に rails_blue / rails_green の2サービスを定義。
2. 新イメージを green 側で起動し、healthcheck が pass したら Nginx upstream を切替。
3. 旧 blue コンテナを graceful-stop。

upstream app {
  server rails_green:3000;
  # server rails_blue:3000;  # 切替時にコメントアウト
}

• 切替は nginx の reload だけで完了、TCP セッションは切れずダウンタイム 0。

4-4 ログ・監視までワンセット：Grafana Loki & Promtail

services:
  loki:
    image: grafana/loki:2.9
    command: -config.file=/etc/loki/local-config.yaml
  promtail:
    image: grafana/promtail:2.9
    volumes:
      - /var/log:/var/log
    command: -config.file=/etc/promtail/config.yml

• Loki はディスク書込みが少なく NVMe の高速 I/O を生かせる。
• Grafana でエラーレートが 1 % を超えたら Discord Webhook に通知するアラートを設定。

4-5 コスト＆パフォーマンス最適化：vCPU 負荷とメモリ上限を監視

• コンテナに --cpus="0.8" --memory="512m" を設定、Rails の peak 時 vCPU 利用率を 70 % に抑制。
• スケール指針：
  • Load average > vCPU ×1.2 が 5 分継続 → 2GB プランへ。
  • メモリ使用率が 80 % を超えるとスワップ発生、レスポンスが 2 倍遅延。

5. よくある失敗とADHD流“ミス防止チェックリスト”

5-1 メモリ不足でコンテナ落ち：swap発生前にできる対策

• free -h / docker stats でメモリ使用率を 70 % を越えたら即増設アラート。
• vm.swappiness=10 に設定し、swap 侵入を遅らせる。
• OOM 回避策として --memory="512m" --memory-swap="512m" を明示――これで 上限超過→即再起動 という最悪パターンを防止。
• Grafana アラート例：avg(node_memory_MemAvailable_bytes) < 300000000 を 5 分継続で Discord 通知。

5-2 権限まわりの躓き：rootとwww-dataの住み分け

• うっかり root 権限でアップロード → WP が 403 はお約束。
• 解決策は単純で RUN adduser -u 1000 appuser && chown -R appuser:appuser /app を Dockerfile に書くだけ。
• ホスト側マウント時は :cached オプションを付け I/O を高速化しつつ権限ズレを抑制。

5-3 SSL自動更新エラー：cron＆証明書更新の見逃し防止

• certbot renew --dry-run を週1 cron で実行し、失敗時のみ | mail -s "renew failed" で自分にメール。
• --reuse-key を付ければ一部の API 速度制限を回避。
• Nginx ごと Docker 化している場合は ボリューム共有で live フォルダを保持。再起動しても証明書が消えない。

5-4 バックアップ忘れ防止：3世代＋外部ストレージ戦略

• Notion に 「バックアップ＋リストア演習」 タスクを月1で登録 → 完了するまで毎朝リマインド。
• "取っただけ" のバックアップは エラーで復元できずに詰む。必ずテスト復元を行う。

5-5 DNS TTL の戻し忘れ：移行後72時間でやるべきタスク

1. Cloudflare などで TTL を 300 → 3600 秒 に戻し、無駄なキャッシュ再取得を防止。
2. 旧サーバーは systemctl stop httpd でサービス停止 → さらに 48 時間保留してから解約。
3. Google Search Console に新 IP の crawl stats が正常かを確認し、404 スパイクが無いかをチェック。

5-6 ADHDでもミスらない移行フロー：チェックリスト雛形

- [ ] TTL を 300 に設定
- [ ] 直前 rsync
- [ ] SSL 発行（certbot）
- [ ] A レコード切替
- [ ] Cache & 画像最適化
- [ ] Grafana アラート閾値セット
- [ ] TTL を 3600 に戻す
- [ ] 旧サーバー停止予約

• Notion テンプレ：「期限 × チェックボックス × 自動リマインド」 の3点セットでうっかり忘れを根絶。
• ステップ完了ごとに GitHub の Issue コメントで “証跡” を残せば、後で振り返りやすい。

シンVPS移行の最適プランの選び方

【公式】シンVPS

6-1 シーン別おすすめプラン早見表

6-2 スケールアップ／ダウンのタイミング指標

• CPU平均使用率が vCPU ×0.8 を 5分継続 したらアップを検討。
• メモリ使用率80％超＋swap発生で即アップ、70％を超えた段階で翌月プラン変更予約が安全圏。
• 逆に PV 減少や機能整理で CPU<30％・Mem<50％が1か月 続くならダウンでコスト最適化。
• I/O wait が 5％超→NVMe × CPU のバランスが崩れているサイン。vCPU増設よりもメモリ追加かCDN導入が先手。

6-3 月額コストと性能を最適化するチェックリスト

1. 年間一括払い割引：シンVPSは12か月払いで5〜8％OFF。アップサイジング見込みが薄い場合は早めに切替。
2. 再契約ペナルティなし：ダウンサイズ時は残期間を月割返金 → 余剰リソースを抱え込まない。
3. キャンペーン＋ドメイン取得セット：初年度0円ドメインやSSLオプション無料を活用し、周辺コストを圧縮。
4. バースト課金が無い：時間課金のクラウドVPSと違い、月額上限固定。CPU100%でも請求は変わらないので、突発アクセスは“太っ腹で助かる”反面、常時負荷が高いと“割安感”が薄れる点に注意。

6-4 迷ったときのQ&Aフローチャート

   +─月3万PV未満？── Yes ─→ 1GB
   |                               |
   |                               No
   |                               ↓
   +─Eコマース/予約システム？─ Yes─→ 4GB
   |                               |
   |                               No
   |                               ↓
   +─Docker×複数サービス？─ Yes─→ 2GB
   |                               |
   |                               No
   |                               ↓
   +─TensorFlow/PyTorch推論？─ Yes─→ 8GB+
                                   |
                                   No
                                   ↓
                                2GB

• 迷ったら2GBが無難。月額1,180円でvCPU×2・メモリ2GB・帯域500Mbpsなら、“WordPress＋副業開発”どちらも快適ライン。
• 8GB以上はコア単価が最も下がるため、長期的にマイクロサービスを束ねる予定があるなら早めに移行すると割安。

【公式】シンVPS