はじめに
現在、個人ブログを「さくらのレンタルサーバ + WordPress」で運営しています。
特に大きな不満があるわけではありません。
WordPressをインストールすればすぐ使えますし、データベースやファイル保存について普段それほど意識する必要もありません。
では、なぜCloud Runへ移行しようと思ったのか。
理由はかなり単純で、
私自身がGoogle Cloud推しだからです。
普段Google Cloudに触れる中でも、Cloud Runは特に好きなサービスの一つです。
コンテナを用意すればサーバを管理することなくアプリケーションを公開でき、アクセスに応じて自動的にスケールしてくれる。
Google Cloud公式でもCloud Runは、インフラストラクチャ管理を抽象化したフルマネージドなアプリケーションプラットフォームとして位置付けられています。WebアプリケーションやAPIなども代表的なユースケースです。
そんなCloud Runを触っているうちに、
自分が運営しているWordPressブログもCloud Runに載せられるのでは？
と思いました。
しかもWordPressにはコンテナイメージがあります。
「これは結構簡単に移行できるのでは？」
ということで、実際に検証してみることにしました。
先に結論を書いてしまうと、
今回はCloud Runへの移行を見送ることにしました。
ただ、実際に試してみることで、Cloud Runの特徴をかなり理解できました。
そして同時に、
レンタルサーバって、思っていた以上にいろいろやってくれているんだな
ということにも気付きました。
今回は、その過程を書いてみます。
現在のブログ環境
まず、現在の環境をかなり単純化すると次のようになります。
Internet
|
さくらのレンタルサーバ
|
+-- Webサーバ / PHP
|
+-- WordPress
|
+-- MySQL
|
+-- ファイル領域
普段WordPressを使っていると、この構成をそれほど意識することはありません。
記事を書けば保存されます。
画像をアップロードすれば保存されます。
WordPressのテーマやプラグインを追加しても保存されます。
当たり前のように使っていますが、Cloud Runへ持っていこうとすると、この「当たり前」を一つずつ考えることになります。
Step 1：WordPressコンテナをCloud Runに載せればよいのでは？
最初に考えた構成は単純です。
Internet
|
Cloud Run
|
WordPress Container
WordPressにはDockerイメージがあります。
ならば、
WordPressコンテナをCloud Runへデプロイすれば終わりでは？
と思いました。
Cloud Runの好きなところは、まさにここです。
VMを使う場合であれば、
- OS
- Webサーバ
- PHP
- ミドルウェア
- OSのパッチ
- サーバのスケール
などを考える必要があります。
Cloud Runでは、その多くをサービス側に任せることができます。
コンテナを作ってデプロイする。
このシンプルさはやはり魅力的です。
しかしWordPressを動かそうとすると、すぐに一つ目の問題にぶつかります。
Step 2：そういえばMySQLはどこに置く？
WordPressはWebアプリケーションだけで完結しているわけではありません。
記事本文やユーザー情報、WordPressの設定などはMySQLへ保存されています。
つまり、
Cloud Run
|
WordPress
|
？
|
MySQL
となります。
レンタルサーバでは最初から用意されていたMySQLを、自分で用意する必要があります。
そこでGoogle Cloudで考えると、まず候補になるのがCloud SQL for MySQLです。
構成はこうなります。
Internet
|
Cloud Run
|
WordPress
|
Cloud SQL for MySQL
Cloud RunからCloud SQLへ接続する方法はGoogle Cloud側でも正式に用意されています。
Cloud RunのサービスアカウントへCloud SQL Clientロールを付与し、Cloud RunからCloud SQLインスタンスへ接続できます。
Google CloudではCloud RunとCloud SQLを同一リージョンに配置することも推奨されており、レイテンシやネットワークコスト、リージョン障害時のリスクを抑えることにつながります。
WordPress側では、
WORDPRESS_DB_HOST
WORDPRESS_DB_USER
WORDPRESS_DB_PASSWORD
WORDPRESS_DB_NAME
などの情報を設定します。
検証段階なら環境変数でも動かせますが、本番環境ではデータベースのパスワードなどをSecret Managerで管理したほうがよいでしょう。
Google Cloudのドキュメントでも、SQL認証情報などの機密情報についてSecret Managerの利用が推奨されています。
これで、
Cloud Run
WordPress
|
v
Cloud SQL
MySQL
という構成になります。
ここまで来ると、
できた。WordPressをCloud Runで動かせそう。
という気持ちになります。
しかし、まだ終わりではありません。
Step 3：Cloud SQLを使えば永続化できる……と思った
Cloud SQLを用意したので、WordPressの記事や設定は永続化できます。
これでデータが消える問題も解決。
……と思ったのですが、WordPressにはデータベース以外にも保存するものがあります。
代表的なのがwp-contentです。
wp-content/
├── plugins/
├── themes/
└── uploads/
たとえばWordPressの管理画面から画像をアップロードすると、通常はuploads以下へ保存されます。
テーマやプラグインについてもファイルとして存在します。
では、これをCloud Runのコンテナに保存してよいのでしょうか。
答えは「本番用途ではダメ」です。
Cloud Runのコンテナファイルシステムは書き込み可能ですが、インメモリであり、インスタンスが停止すると書き込んだデータは保持されません。
つまり、
記事本文
|
v
Cloud SQL
|
+-- 残る
アップロード画像
|
v
Cloud Runのファイルシステム
|
+-- インスタンス終了時に消える可能性
となります。
これはWordPressではかなり困ります。
WordPressを載せることで「ステートレス」が急に分かりやすくなった
個人的には、ここが今回一番面白かったところです。
Cloud Runについて勉強すると、
「アプリケーションはステートレスにする」
という説明をよく目にします。
言葉としては理解できます。
ただ、自分が普段使っているWordPressを載せてみると、その意味が急に具体的になります。
「記事はどこ？」
「画像はどこ？」
「プラグインは？」
「テーマは？」
という疑問が次々と出てきます。
そして、
Compute
Database
Storage
を分離して考えなければならないことに気付きます。
Cloud Runが難しいというより、
レンタルサーバでは一つのサーバの中にまとまっていたものを、クラウドではそれぞれの役割に分解している
と考えたほうが分かりやすいかもしれません。
Step 4：画像をCloud Storageへ逃がす
次に考えられるのがCloud Storageです。
構成はこのようになります。
+------------------+
| Cloud SQL |
| 記事・設定など |
+------------------+
^
|
Internet ---> Cloud Run ------+
WordPress |
v
+------------------+
| Cloud Storage |
| 画像など |
+------------------+
Cloud RunではCloud Storageバケットをボリュームとしてマウントすることもできます。現在はCloud RunサービスからCloud Storageをボリュームとして利用する仕組みも提供されています。
ただし、これで普通のファイルシステムと完全に同じになるわけではありません。
Cloud StorageのボリュームマウントではCloud Storage FUSEが使われており、完全なPOSIX互換ファイルシステムではありません。また、同じファイルへの複数同時書き込みではロックが提供されないなどの制約もあります。
そのため、
wp-contentを全部Cloud Storageへ置けば解決
と単純に考えるより、
何を永続化するのかを整理したほうがよさそうです。
たとえば、
記事・設定
→ Cloud SQL
アップロード画像
→ Cloud Storage
WordPress本体
テーマ
プラグイン
→ コンテナイメージ
という考え方があります。
テーマやプラグインを管理画面から追加してよいのか問題
ここまで考えると、もう一つ気になることがあります。
WordPressでは普通、
WordPress管理画面
↓
プラグイン追加
という操作をします。
しかしCloud Run上でこれを行うと、コンテナのファイルシステムへ変更が入ります。
そのインスタンスがなくなれば、その変更もなくなります。
だったら、
Git
↓
Dockerfile
↓
WordPress
+ Theme
+ Plugin
↓
Container Image
↓
Cloud Run
としたほうがCloud Runらしい。
つまりテーマやプラグインの変更もコードとして管理し、コンテナイメージを作り直してCloud Runへデプロイするわけです。
GitHubとCloud Buildなどを連携させれば、CI/CDまで構成できます。
ここまで来ると、
もともと使っていたWordPressとは、運用スタイルまでかなり変わってきます。
ちょっと面白くなってきました。
今回は「本番環境完成」ではなく「まず動かす」
もちろん、今回の目的は大規模なWordPress基盤を作ることではありません。
Cloud RunでWordPressを動かしてみることが目的です。
そのため最初の検証としては、次の段階までで十分だと思います。
- WordPressコンテナを用意する
- Cloud SQL for MySQLを作成する
- Cloud RunへWordPressをデプロイする
- Cloud RunからCloud SQLへ接続する
- WordPressの初期セットアップをする
- 記事を投稿してみる
- 画像をアップロードして、永続化について考える
- 必要ならCloud Storageを試す
このくらいまで進めれば、
「Cloud RunでWordPressを動かすと何が問題になるのか」
を十分体験できます。
本番で使うなら、まだまだ考えることがある
一方、本当に現在のブログを移行するのであれば話は別です。
少なくとも、
- Cloud SQLのバックアップ
- Cloud SQLの可用性
- データベース接続数
- Secret Manager
- 独自ドメイン
- HTTPS
- WordPressアップデート
- PHPアップデート
- テーマ・プラグイン管理
- Cloud Storage
- キャッシュ
- CDN
- WAFなどのセキュリティ
- Cloud Logging
- Cloud Monitoring
- コンテナイメージの脆弱性管理
- CI/CD
- 障害時の復旧方法
あたりは考える必要があります。
特にCloud Runは負荷に応じてインスタンスが増えるので、Cloud SQLの接続数についても意識する必要があります。
Cloud RunからCloud SQLへの接続にはインスタンスごとの接続上限があり、Cloud Runがスケールすればデプロイメント全体の接続数も増えていきます。Google Cloudもコネクションプールの利用などを案内しています。
Cloud Run側だけを見て、
「勝手にスケールしてくれるから安心」
とはならないわけです。
ここでレンタルサーバを振り返ってみる
そして現在使っているレンタルサーバを振り返ります。
レンタルサーバでは、
Webサーバ
PHP
MySQL
ファイルストレージ
SSL
バックアップ
などが一つのサービスとして提供されています。
それをGoogle Cloudへ持ってくると、
Compute
→ Cloud Run
Database
→ Cloud SQL
Storage
→ Cloud Storage
Secrets
→ Secret Manager
Logging
→ Cloud Logging
Monitoring
→ Cloud Monitoring
というように分かれていきます。
ここで、
レンタルサーバって思っていた以上にいろいろ面倒を見てくれていたんだな……
となりました。
一方で、Google Cloudの場合は一つ一つを自分で選択できます。
データベースだけ性能を上げる。
Webアプリだけ大量にスケールする。
ストレージを独立させる。
監視を追加する。
この自由度は、クラウドならではです。
どちらが優れているというより、
求めているものが違う
ということだと思います。
レンタルサーバとCloud Run構成を比較してみる
今回のような個人WordPressブログという前提で比較すると、私は次のように感じました。
| 項目 | レンタルサーバ | Cloud Runベース |
|---|---|---|
| WordPress導入 | ◎ | ○ |
| サーバ管理 | ◎ | ◎ |
| DB | サービス内 | Cloud SQL |
| ファイル永続化 | 意識しなくてよい | 設計が必要 |
| 自動スケール | △ | ◎ |
| 構成の自由度 | △ | ◎ |
| CI/CD | △ | ◎ |
| 運用の手軽さ | ◎ | △ |
| インフラ学習 | ○ | ◎ |
| 個人ブログとの相性 | ◎ | △〜○ |
| API・Webアプリとの相性 | ○ | ◎ |
Cloud Runはフルマネージドなので、Cloud Runそのもののサーバ管理負荷はかなり小さいです。
ただし、
WordPressシステム全体として見ると、考えるサービスが増える
というのが今回のポイントです。
そして最後に料金問題
Cloud Runを使いたくなった理由の一つに、料金体系もあります。
Cloud Runではデフォルトのリクエストベース課金の場合、基本的にリクエスト処理中などを中心に課金されます。インスタンスベース課金を選択することもできます。
そのため、
アクセス数の少ない個人ブログなら、Cloud Runってものすごく安いのでは？
と思いました。
Cloud Run単体だけを見ると、その発想はそれほど間違っていないと思います。
ところがWordPressの場合、
Cloud SQLが必要です。
Cloud SQLはCPU・メモリ・ストレージなどに応じて料金が発生します。小規模な検証用途向けには共有コアのdb-f1-microなどもありますが、共有コアはCloud SQL SLAの対象外です。
さらに、
Cloud Run
Cloud SQL
Cloud Storage
Artifact Registry
ログ
ネットワーク
などを積み上げていく必要があります。
つまり、
Cloud Runが安い = WordPressを安く運用できる
とは限りません。
むしろアクセス数のそれほど多くない個人ブログの場合、
「定額でWordPressに必要なものが一通りそろっているレンタルサーバ」
はかなり合理的な選択肢です。
Cloud Runがダメだったのか？
では、
Cloud RunでWordPressを動かすのは失敗だったのか？
というと、まったく逆でした。
今回試してみたことで、
Cloud Runが得意なことが以前より分かりやすくなりました。
例えば、
- REST API
- Web API
- Webhook
- 小規模なWebアプリ
- 社内ツール
- 生成AIを利用したバックエンド
- イベント駆動処理
- バッチ処理
など。
特に、
アプリケーション
↓
コンテナ化
↓
Cloud Runへデプロイ
という使い方では、Cloud Runはとても便利です。
Cloud RunはWebサイトやWebアプリだけでなく、API、マイクロサービス、イベント処理、AI推論などもユースケースとして挙げています。
今回苦労した部分はCloud Runそのものというより、
WordPressがDBとファイルの両方に状態を持つアプリケーションだった
ことが大きかったのだと思います。
結論：Cloud Runには移行しない。でも試してよかった
今回、
「自分のWordPressブログもCloud Runへ移行したら面白そう」
というところから検証を始めました。
実際に考えてみると、
WordPress
↓
Cloud Run
↓
Cloud SQL
↓
Cloud Storage
と、次々に必要なサービスが見えてきます。
さらに本番運用となれば、
Secret Manager、バックアップ、監視、CI/CDなども考える必要があります。
そして現在の私のブログは、それほど大規模なサービスではありません。
それなら、
今使っているレンタルサーバをそのまま使うほうがシンプル
というのが今回の結論です。
ということで、
WordPressブログのCloud Runへの移行は見送ることにしました。
ただ、やってみてよかったと思っています。
Cloud RunへWordPressを載せようとしたことで、
普段レンタルサーバの中に隠れている、
Compute
Database
Storage
Security
Monitoring
といった要素が一つずつ見えてきました。
そして、
なぜCloud Runではステートレスなアプリケーションが扱いやすいのか
も実感できました。
Google Cloud推しとしては、
「せっかくだから自分のブログもCloud Runにしたい」
というところから始めた検証でしたが、
結果的には、
Cloud Runの良さと、レンタルサーバの良さを両方知ることができた
というのが一番の収穫でした。
Cloud Runを触ってみたいけれど題材に悩んでいる人は、あえてWordPressを動かしてみるのも面白いかもしれません。
すんなり動くアプリケーションを載せるよりも、
「なぜこれは簡単に移行できないのか？」を考えるほうが、Cloud Runについて学べることは多かったです。