物理SSDの限界を突破し、秒間27.6GB（実測約1,303倍！）という異次元の超高速インフラを実現するWordPressのRAMディスク（tmpfs）化。
画像アップロードや記事の自動保存が目に見えて爆速になり、「これで最強のサーバーが完成した！」と胸を張りたいところですが……実は、RAMディスク運用には避けては通れない「唯一の弱点」が存在します。
それは、「サーバーが再起動（または停電などでシャットダウン）すると、メモリ上のデータだけでなく、作ったフォルダ構造そのものが完全に消滅する」というtmpfsの絶対的な仕様です。
サーバー再起動後に待っている「フォルダ消滅」の恐怖
せっかくPHP-FPMのプール設定で、 php_admin_value[sys_temp_dir] = "/mnt/ramdisk/php_tmp/main/" のように専用の一時フォルダを指定していても、再起動後のRAMディスク内は文字通り「空っぽ（まっさらな状態）」になります。
器となる /main/ や /sub/ といったフォルダ自体が消え去ってしまうため、再起動後にWordPressを動かそうとすると、
「一時フォルダーが存在しません。パーミッションを確認してください」
というエラーを吐き出し、画像のアップロードやプラグインの更新、記事の保存がすべて強制ストップしてしまいます。
これでは、サーバーのメンテナンスや不意の停電のたびに、手動で mkdir を叩いて、chown www-data:www-data で権限を付与し直すという、おそろしく面倒な不毛ロードを歩むことになってしまいます。
「Systemd」を使って、起動時に100%自動でフォルダを完全復旧させる！
そこで今回は、サーバーが起動した瞬間に、RAMディスク内に必要なフォルダ構造を自動で作成し、WordPress（www-data）が読み書きできる正しい権限（パーミッション）をミリ秒単位で一発設定する「最強の起動スクリプト（Systemdサービス）」の構築手順を徹底解説します！
複数サイト（マルチドメイン）運用でフォルダを分けている環境でも、バッティングすることなく完全に自動復旧。一度設定しておけば、停電が起きようが、OSを再起動しようが、何事もなかったかのように「ヨシ！」と爆速インフラが立ち上がる堅牢なシステムを完成させましょう！
Step 1：自動生成用のSystemdサービスファイルを作成する
Linuxが起動する際、RAMディスクがマウントされるよりも前にフォルダを作ろうとするとエラーになってしまいます。
そのため、ローカルファイルシステムのマウント（/mnt/ramdisk の準備）が完了した直後に、WordPress、Nginx、MariaDB用の一時フォルダを最優先で自動生成するサービスファイルを作成します。
① サービスファイルの新規作成
以下のコマンドを実行し、nanoエディタで新しいサービスファイルを作成します。
sudo nano /etc/systemd/system/ramdisk-init.service② 設定コードの貼り付け
ファイルが開いたら、以下の内容をそのままコピーして貼り付けます。
[Unit]
Description=Initialize RAM Disk Temp Directories for WordPress, Nginx and MariaDB
DefaultDependencies=no
# RAMディスクを含むローカルファイルシステムがマウントされたら即座に実行
After=local-fs.target
[Service]
Type=oneshot
RemainAfterExit=yes
# 1. 必要な親フォルダを一括作成
ExecStartPre=/usr/bin/mkdir -p /mnt/ramdisk/php_tmp /mnt/ramdisk/nginx /mnt/ramdisk/mysql
# 2. WordPress用およびNginx用の各子フォルダを作成
ExecStart=/usr/bin/mkdir -p /mnt/ramdisk/php_tmp/main /mnt/ramdisk/php_tmp/tech /mnt/ramdisk/nginx/client_body /mnt/ramdisk/nginx/proxy /mnt/ramdisk/nginx/fastcgi /mnt/ramdisk/nginx/uwsgi /mnt/ramdisk/nginx/scgi
# 3. WordPress・Nginx用フォルダの権限を www-data に変更
ExecStartPost=/usr/bin/chown -R www-data:www-data /mnt/ramdisk/php_tmp /mnt/ramdisk/nginx
ExecStartPost=/usr/bin/chmod -R 775 /mnt/ramdisk/php_tmp /mnt/ramdisk/nginx
# 4. MariaDB用フォルダの所有者を mysql に変更
ExecStartPost=/usr/bin/chown -R mysql:mysql /mnt/ramdisk/mysql
ExecStartPost=/usr/bin/chmod -R 750 /mnt/ramdisk/mysql
[Install]
WantedBy=multi-user.target💡 コードの解説と調整のポイント：
DefaultDependencies=no&After=local-fs.target:
OS起動時の極めて早い段階（マウント直後）に実行をねじ込みます。これにより、PHP-FPM、Nginx、MariaDBなどの各サービスが立ち上がるよりも前に、一時フォルダを確実に先回りして生成できます。ExecStartPre&ExecStart:
RAMディスク直下に、PHP用、Nginx用、MariaDB用の各親フォルダを作成し、さらにWordPress（本館main、別館sub）やNginxのキャッシュ用子フォルダを掘り進めています。ご自身の環境に合わせてフォルダ名は自由に変更・追加してください。ExecStartPostによる複数権限の付与:
Webサーバーを動かすwww-dataユーザーと、データベースを動かすmysqlユーザーのそれぞれに対して、必要なフォルダの所有権（chown）とアクセス権限（chmod）を個別に割り当て、権限競合を防ぎます。
貼り付けが終わったら、Ctrl + O ➔ Enter で保存し、Ctrl + X でエディタを閉じます。
Step 2：自動起動サービスを有効化する
ファイルを作成したら、システムに新しいサービスを認識させ、OS起動時に自動実行されるように設定します。
① Systemdのデーモンをリロードする
新規追加したサービスファイルをOSに読み込ませます。
sudo systemctl daemon-reload② サービスを自動起動（有効化）にする
これで、次回以降のサーバー再起動時に自動でスクリプトが走るようになります
sudo systemctl enable ramdisk-init.service③ 手動でサービスをテスト実行してみる
一度サーバーを再起動する前に、このスクリプトが正しく動くか手動でテストしてみましょう。
sudo systemctl start ramdisk-init.serviceエラーが出なければ成功です！ 実際にフォルダが作られ、所有者が www-data になっているか確認してみます。
ls -la /mnt/ramdisk/php_tmp/以下のように、main と sub の所有者が www-data www-data になっていれば完璧です！
drwxrwxr-x 4 www-data www-data 80 Jul 16 14:32 .
drwxrwxrwt 5 www-data www-data 120 Jul 16 08:42 ..
drwxrwxr-x 2 www-data www-data 40 Jul 16 14:32 main
drwxrwxr-x 2 www-data www-data 40 Jul 16 14:32 subStep 3：【最終確認】OSを再起動して「ヨシ！」を確かめる
ここまで設定できたら、いよいよ「不意の再起動や停電」を想定したテストを行います。 実際にサーバーを再起動してみましょう！
sudo rebootサーバーが立ち上がったら、再びログインして以下のコマンドを実行します。
ls -la /mnt/ramdisk/php_tmp/再起動してRAMディスク（メモリ）の中身は一度完全に消滅したはずですが、ログインしたときにはすでに main と sub のフォルダが完璧な権限で自動復旧されているはずです。
もちろん、WordPress側を開いてもエラー（赤帯）が出ることはなく、Site Kitや記事の保存、画像のアップロードも、立ち上がった瞬間から何事もなかったかのように「ヨシ！」の状態で爆速処理が開始されます。
💡 よくある疑問：再起動でデータは消えないの？
「RAMディスクは再起動すると中身が完全に消える」と聞くと、「せっかく書いた記事や、アップロードした画像まで消えてしまうのでは？」と不安になりますよね。
結論から言うと、記事や画像などの大切な本データは1ミリも消えません。
なぜ消えないのか、その仕組みを解説します。
データ保存先の「住み分け」一覧
| データの種類 | 保存場所（デバイス） | 再起動後の状態 | データの具体例 |
|---|---|---|---|
| 本データ （消えては困るもの） | 物理ストレージ（SSD/HDD） | 完全に残る | 投稿した記事テキスト アップロードした画像 （完成品） |
| 一時データ （消えていいもの） | RAMディスク （メモリ領域） | 完全に消える | 画像処理中のキャッシュ 一時的な計算用のメモ キャッシュデータ |
各フォルダが裏側で行っていること
今回RAMディスクに移行した一時フォルダは、あくまで一時的な「作業用（計算用紙）」として使われているだけです。
1. WordPressの一時フォルダ (php_tmp)
画像をブログにアップロードした際、一時的にRAMディスク（php_tmp）に画像が置かれます。WordPressはその一時フォルダ上で画像の圧縮やリサイズ処理（作業）を爆速で行い、処理が完了した完成品データを即座に物理ストレージ（wp-content/uploads/）へ書き移します。 作業が終わったゴミだけがRAMディスクに残る仕組みなので、再起動しても本データに影響はありません。
2. MariaDBの一時フォルダ (mysql/)
記事のテキストデータなどは、保存ボタンを押した瞬間に直接物理ストレージ（/var/lib/mysql）に書き込まれます。 RAMディスク側の /mnt/ramdisk/mysql は、データベースが複雑な検索や並び替え処理（ソート）をするときに、メモリに入り切らない大きなデータを一時的に並べる「計算用紙」として使っているだけです。そのため、ここが消えてもデータ自体が破損することは絶対にありません。
3. Nginxの一時キャッシュ (nginx/)
読者がアクセスした際に、表示速度を上げるための一時的なコピー（キャッシュ）を作成する場所です。 再起動でキャッシュがクリアされても、大元のデータ（記事）は物理ストレージに無傷で残っているため、再起動後にアクセスがあった時点で自動的にキャッシュが作り直されます。
まとめ：メモリの速さと物理ディスクの安心感を両立した「完全体」へ
今回の自動復旧スクリプト（Systemdサービス）を導入したことで、RAMディスク運用における「再起動時に一時フォルダが消えて各サービスが動作を停止してしまう」という唯一にして最大の弱点が完全に克服されました。
大切な本データ（記事や画像）は物理ストレージに即時保存されて安全に守られつつ、負荷の重い一時処理やキャッシュだけをRAMディスクが引き受ける。この美しい住み分けが完成したことになります。
- 物理SSDへの書き込み負荷を極限まで抑えて寿命を延ばす
- 実測1,303倍（秒間27.6GB/s）のメモリ直結による圧倒的な爆速表示
- OS再起動や不意の停電が発生しても、100%全自動で安全に復旧する堅牢性
この3つが揃い、あなたのWordPressサーバーはまさに非の打ち所がない「完全体」の高速インフラへと進化を遂げました。
一度設定してしまえば、あとはシステムがすべて全自動で管理してくれます。メンテナンスフリーで稼働する極上の爆速WordPress環境を、ぜひ末永くお楽しみください！
最後まで読んでいただきありがとうございました！
コメント