Webque * Weblog

1. サーバー移設に至った経緯（現状の問題点）

問題点①：ストレージが慢性的に逼迫してきた

• 使用量 100GB
• 空きが 30%未満（＝余裕が小さい）
  コンテンツは今後も増え続ける想定で、ボトルネックが「ストレージ」だと経験的に分かっている状況。

問題点②：Plesk が高額で、維持コストが割に合わない

現状の年額

• VPS：16,800円/年
• Plesk：22,800円/年
• DNS hosting：8,640円/年 (6 domains)
• 合計：48,240円/年

Pleskは便利だが、無くても何とかなる。rootで自由度を確保しつつ、学習しながら運用していく。あと、追加の DNS も高め。

2.前提条件

前提①：稼働率

• 数分の停止は許容
• 半日停止は事故レベル
  つまり「学習のために本番で試行錯誤する」には、失敗時に戻れる仕組みが必要。

前提②：重要サイトが複数あり、移設の順序設計が必須

• 高：ドメインA（CakePHP多数）、ドメインB、ドメインC
• 中：ドメインD、E、F、G、H、I
• 低：ドメインJ（実験用、サブドメイン多数）
  段階移設できる契約期限（〜2026/02/26）があるため、「練習台 → 中 → 高」の順に安全に進められます。

3. 問題を解決する手段（選択肢の整理）

今回の課題（容量・コスト・自由度・事故回避）に対して、現実的な手段は主に以下である。

手段A：現状維持（Plesk継続）＋ストレージだけ増やす

• メリット：運用の変化が少ない
• デメリット：Pleskコストが残り、追加ストレージのコストが増える

手段B：Plesk代替の管理パネルへ移行（安価なパネル等）

• メリット：管理は楽、Pleskより安い可能性
• デメリット：パネル依存が残り、将来また乗り換え課題が出やすい

手段C：共有レンタルサーバーへ戻す

• メリット：運用が簡単、バックアップ等が整っている場合が多い
• デメリット：root前提の自由度が失われる／CakePHP多数構成との相性・制約が読みにくい

手段D：VPSへ移行し、Pleskなしで自前運用（今回の選択）

• メリット：root自由度、Plesk固定費を外せる、学習が資産になる
• デメリット：運用は自分（ただし、段階移設＋保険で事故率を下げられる）

私の希望（rootで自由に、スキルアップしながら、ただし事故は避けたい）から、手段Dが最も整合性が高い。

4. 手段Dの中で「XServer VPS 6GB 」に収束した理由（意思決定の道筋）

VPSなら何でもよいわけではなく、さまざまなVPSプランには「落とし穴」がある。

• 2GB級の小さいVPS：コストは安いが、本番一本運用だと“余裕のなさ”が事故要因になりやすい
• 大容量プラン：安心だが、総額削減の目的とぶつかる
• DNS費用：縛りがないなら、無料DNSや別管理に逃がせる（＝削減余地が大きい）

そこで「容量の初期値」「性能の余裕」「戻れる仕組み」「価格」のバランスが良い点として、6GBが“真ん中の勝ち筋”である。

5. XServer VPS 6GB を選ぶべき理由7個

理由1：NVMe 150GB が、いまの容量課題に応えている

6GBプランは NVMe SSD 150GB。容量不足の解消に最短距離である。

理由2：vCPU 4コア／メモリ6GBで「本番一本運用」の事故率が下がる

6GBは vCPU 4コア・メモリ6GB。複数ドメイン＋Apache＋DBを載せても余裕を残しやすい構成である。

理由3：Plesk固定費を外しやすく、総額削減の設計が取りやすい

XServer VPS は「VPSとしての費用」に寄せられるため、Pleskのような固定費を切り離しやすい。料金体系も公式ページで確認でき分かりやすい。

理由4：料金の“入口”が明確（契約期間で最適化しやすい）

公式の料金表で、6GBが月額いくらかを簡単に確認できる（契約期間等で変動）。

理由5：「イメージ保存」が、本番一本運用の“戻り道”になる

Xserver VPSは イメージ保存（標準で50GBまで無料） が明記されています。大きな作業前に“丸ごと戻せる状態”を作りやすい。
（自前バックアップ方針だが、「作業直前の保険」として）

理由6：Pleskなしでも最低限の管理導線がある

機能一覧として、VPS運用に必要な各機能が整理されているようだ（= Pleskほどではないが、運用の入口が用意されている）。

理由7：上位プランへのスケールが同一サービス内で繋がる

もし将来「150GBでは足りない」となっても、同一サービス内で上位プラン（より大容量）へ移る道が用意されている。

6. 実際に「6GBを選ぶ」までのロードマップ（順を追って）

ここまでの意思決定を、移設手順に落とすとこうなります。

1. 練習台を決める
   　ドメインJ を“壊してよい検証環境”として使う（心理的抵抗なし）
2. 旧サーバー側に検証用WPを作る（/wp-test/）
   　目的は「移設成否を客観判定できる対象」を作ること
   　（空ディレクトリ前提でも、将来の並列検証のためにサブディレクトリ化）
3. 新サーバーは Xserver VPS 6GB を契約
   　Ubuntu LTS + Apache で開始（CakePHPの移行難度を上げないため）
4. 移設方式は “手動” で統一（rsync + DBダンプ/リストア）
   　これを ドメインJ/wp-test/ で一回通せば、そのまま重要ドメインへ展開できる
5. 段階移設（低→中→高）
   　公告用静的ドメイン（中）は移行が軽いので中盤で片付く
   　最後に ドメインA、B、C を詰める
   　（旧契約期限 2026/02/26 まで二重稼働できる前提）

まとめ

今回の移設は、“事故らない”手順でPlesk依存を外し、容量不安を解消し、運用スキルを資産化する のが正解である。

その観点で、XServer VPS 6GB は

• 容量（NVMe 150GB）
• 余裕（4コア・6GB）
• 戻り道（イメージ保存）
• 価格の見通し（公式料金表）

が同時に揃う、「この案件に対する実務的な最適点」と言える。

Docker に Sass をビルドする仕組み（以下の2つ）を追加する必要があります。

1. Node.js
2. Dart Sass

アプローチは二通りあり、 A. ホスト側でビルドするか B. Sass ビルド用の Docker コンテナを追加するか。B. は、定義さえすれば様々な環境で再現できる利点がありますが、コンテナの構成が複雑になるので今回はシンプルに A. で進めます。

Node.js のインストール

Sass の導入および実行は npm コマンドで行われるため Node.js のインストールが必要です。

Dart Sass のインストール

Dart 言語で実装された Dart Sass が現在唯一の公式実装。以前主流だった node-sass は開発が終了しています。

ディレクトリ構成

Sass は定義ファイルを解析し、css ファイルをビルドします。

ディレクトリ構成を考慮する対象は次の3つ。

1. package.json
2. Sass ファイル
3. css ファイル

ディレクトリ構成の一例

例えば次のような構成が考えられます

my-project/
├─ package.json         ← Sass プロジェクトを定義
├─ src/
│  └─ scss/             ← Sass ファイル設置ルート
└─ html/
   └─ assets/
      └─ css/
         └─ style.css   ← 出力

上記の scss/ ディレクトリの下に、任意に（例えば以下のように） Sass ファイルを設置していきます。

my-project/
├─ package.json
├─ src/
│  └─ scss/
│     ├─ foundation/
│     │   ├─ _variables.scss
│     │   ├─ _mixins.scss
│     │   └─ _index.scss
│     ├─ object/
│     │   ├─ component/
│     │   │   ├─ _button.scss
│     │   │   └─ _index.scss
│     │   └─ _index.scss
│     └─ style.scss
└─ html/
   └─ assets/
      └─ css/
         └─ style.css

Sassファイルの拡張子には.scss と .sass の2種類がありそれぞれ記法が異なりますが、一般的に.scss が用いられいます。

package.json の設定

package.json は、Node.js を用いた開発で必須のファイルで、プロジェクトの説明を json で記述します。

例えば次のように記述します。

{
  "name": "my-project",
  "private": true,
  "version": "0.1.0",
  "description": "Sass の最小サンプルプロジェクト",
  "scripts": {
    "build": "sass src/scss/style.scss html/assets/css/style.css --style=expanded",
    "watch": "sass --watch src/scss/style.scss:html/assets/css/style.css --style=expanded"
  },
  "devDependencies": {
    "sass": "^1.80.0"
  }
}