Contents
どうもネトヲです。
私最近、引っ越ししようと本気で考えてまして色々と賃貸物件を探しているのですが、築年数が浅い物件ほど「インターネット無料」である率が高いのです。
エンジニアとしてはこういったインターネット無料物件、完全ブラックボックス化していて嫌いなのですが、まあそうも言ってられないので仕方ない。これも時代の流れってやつです。
インターネット無料物件のネットワークがどうなっているかは分かりませんが、恐らくアップリンク1~10Gbpsの回線をルータで受けてNAPTしVLANで各部屋にLANを渡しているのだと思います。しらんけど。
そうなるとオンプレで動いている当ブログ、終わってしまいます。
かなり頑張れば「ポートフォワードしてください」的なお願いができるかもですが、まあ現実的ではないので、今回クラウドに移行したという話です。
How toではなくただのブログであることご注意ください。
クラウドサービスなににするか
私は完全にオンプレしかやってきていない老害でして、日曜日の13時頃「ヒマだしクラウド触ってみるか」思ったのが事の始まりです。独身万歳。
コスパを考えばレンタルサーバ一択ですが、これもまたブラックボックスな部分が多く自分で設定したいという思いが強いからです。将来的にメールサーバも移行したいし。
クラウドサービスと言えば王者AWSということではありますが、なんとなくGoogle Cloud Platform（以下、GCP）にしました。
インスタンス立ち上げ
一旦本題に入る前にGCPの「課金」の考え方を記します。Gemini作です。
GCPの課金の基本的な考え方は、「確保したリソースと、消費したリソースに対する完全な従量課金」です。
Compute Engineを例にすると、課金対象は「コンピュート」「ストレージ」「ネットワーク」の3つの要素に完全に切り離して計算されます。
1. コンピュート（CPUとメモリ）
VMインスタンスが「起動中（Running）」の状態でのみ課金されます。 課金は秒単位（最小1分）で計算されます。 OS上からシャットダウン、またはコンソールからインスタンスを「停止」すれば、このコンピュート費用の課金は即座に止まります。
2. ストレージ（永続ディスク）
VMの起動・停止に関係なく、ディスクが存在している限り、確保した容量（GB）に対して24時間継続して課金されます。 VMを停止してもストレージの課金は止まりません。課金を完全に止めるには、ディスクそのものを削除する必要があります。
3. ネットワーク（トラフィックとIPアドレス）
通信料金は、サーバーから外に出ていく「外向き（Egress）」のデータ転送量に対してのみ課金されます。サーバーに入ってくる「内向き（Ingress）」は原則無料です。 外部IPv4アドレスは、確保している期間すべてが課金対象です。確保したままどのVMにも紐付けていない、または紐付けているVMを停止している状態の「未使用IP」は、IPv4枯渇対策のため、稼働中のVMに紐付けている状態よりも高いペナルティ料金が請求されます。
4. 継続利用と無料枠
コンピュートリソースには、1ヶ月のうち長期間起動し続けると自動的に単価が下がる継続利用割引（SUD）が適用されるマシンタイプがあります。 また、特定のUSリージョン（us-central1など）のe2-microインスタンスや、月1GBまでのネットワーク転送量など、毎月無料で使える「Always Free（無料枠）」の制度も存在します。
これらがGCPにおけるインフラ課金の原則です。無駄なコストを防ぐには「使わない時は停止する」のではなく「使わないリソースは完全に削除（解放）する」のが鉄則になります。
というワケで、天井はなくリソースに応じて従量課金ということになるわけですよね。
面白いのがout boundの通信量で課金されるところですかね。大量のHTTPリクエストがあったりファイルサーバ的な使い方していると途端に死亡しますね。
IPアドレス取得
どこもかしかも「グローバルIPv4アドレスが枯渇する」と言われている割には、ISPにIPv4アドレスくれっていうと普通に出てくるのが現状なわけですが、GCPも同じく簡単にIPv4アドレスを入手できました。
また、どのリージョンのIPアドレスを使うかも指定出来ます。
オンプレで言うところの固定IPアドレスプランに加入する、みたいなイメージですね。
インスタンス作成
インスタンスってなんぞやという話ですが、端的に言うとサーバですね。
このインスタンスはそれなりに種類があって、それらは「マシンシリーズ」と呼ばれいています。
仮想サーバなので、構築後にある程度リソースの再配分はできますが、マシンシリーズは恐らく変更できないので、予めスケラービリティを考えておかないといけないかもです。
WordPressごときにそんなスペックいらんだろ、ってことで一番しょぼい「E2」の
- e2-small
- vCPU：0.5～2 vCPU（1 個の共有コア）
- RAM：2 GB
にしました。
OSもインスタンス作成時に選択します。
ある程度名の知れたOSは予め用意されているのと、独自OSなんかもISOイメージ等でアップロードできるようです。
私は使い慣れたCentOS…ではなくRocky Linuxを選択。やっぱサーバとして使うならRHEL系統がいい。
どうやらOSによってストレージ容量が変わるようで、Rocky Linux（rocky-linux-10-optimized-gcp-v20260213）だと最低容量が20GB。もちろん増やすとその分課金されるので20GB。
あとバックアップやストレージタイプなど色々設定していきインスタンスの構築は終了。
BTOみたいに常に「いまの構成だとこんくらいかかるよ」と概算金額が出ているので、それを見ながら構成をあれこれするわけですが、従量課金なのであまりあてにはならないですね。
インスタンス作成はオンプレで言うところのサーバ構成を考えるフェーズと同じですね。動かすシステムから逆算して色々と構成を作っていく、みたいな。
インスタンス接続
そしたらインスタンスへアクセスします。
ファイアウォールポリシーにも依りますが、おそらく一旦はブラウザからターミナルへ入る必要があります。いきなりTeratermとかでアクセスは多分ムリ。
私はあまり不用意にポート開けたくないのと、出先でアクセスする時のソースIPを固定にするのは難しい（厳密にはDDNSの利用は可能だがfirewalldがFQDNでポリシーを書けない）ので、80/HTTPと443/HTTPS以外はblockしました。
ブラウザからのターミナル操作は散々iDRACとかで触っているので特に違和感はないでのすが、コピペができるので大分使い勝手はいいです。まあこだわり無ければコレで十分だと思います。
あとブラウザでSSHでアクセスする際はGoogleのアカウントとひもづけされているので、基本的にはGoogleへのログインが必須です。LDAPみたいなもんですね。
WordPress構築
ここまでできたら、あとの作業はオンプレと全く同じです。
WordPressの構築は死ぬほど記事が転がっていてチャッピーに聞けばだれでもできるので省略。
今回WordPressの移行には「All-in-One WP Migration and Backup」を使いました。
コレ使うとテーマとか画像とか記事とかをワンクリックでバックアップできて、全部簡単に移行できます。バックアップ容量にもよりますが私は700MBだったので無料。神ツール過ぎる。
DNSレコード更新
IPアドレスが変わったので、ドメイン「tuuzyouno3bai.com」のDNSレコードを更新しました。
私はお名前.comを使っているので、Webサイトからサクッと更新。
反映に3分くらいかかりましたが、トラブルはなく無事にFQDNで名前解決し、GCP上で動いているWordPressにアクセスできるようになりました。
動作確認
実は証明書周りでトラブったりしていたんですが、まあ無事に乗り越えて、動作確認がてら本ブログを書いています。
クソ雑魚最弱インスタンスにしたので内心不安だったのですが、何の問題もなし。使用感は移行前のi5-11400の16GBと全く同じです。
メモリも2GB中800MB位しか使っていません（一応swapで2GB追加してる）。
ただしメールサーバとzabbix-agentのインストールがまだなので、これらを入れると重たくなるかもですね。
そういえば、GCPのWebダッシュボードからインスタンスのリソースモニタリングができるのですが、
メモリが1.2GB使用中となっているんですよね。よくわからん。まあいいか
まとめ
ということで今回はブログ環境（WordPress）をGCPに移行したという話でした。
正直、一番手間取ると考えていたWordPressのデータ移行は「All-in-One WP Migration and Backup」を使うことで一瞬で終了。これ神ツールですね。
従量課金なので月々どれくらいかかるかは不明ですが、3000円以内に収まってほしいというのが本音でして、それを超えるようだったらオンプレに戻してもいいかなと思います。
そしてこのご時世、わかんないことがあればAIに聞く。これさえ出来れば知識0でもそれなりのモノが作れてしまいます。今回だってそうです。
「クラウドサービスなにそれ美味しいの」状態から半日で移行出来てしまったわけですから。
なので細かい解説はしてないんですよね。結局みんなAIに突っ込むでしょ。そういうこと。
今回はコスト重視でE2にLAMP環境を構築しましたが、業務システムとかの場合はよりつよつよなインスタンスを使ったりGoogle CloudでDBをほぼメンテナンスフリーにしたりできます。
まだクラウドの触り部分しか理解してはいませんが、基本的な考えのベースはオンプレと同じなんだなという事をしれたのは良かったです。コレばかりはやっぱり手を動かして見ないと分からない部分ですから。
余談が長くなりましたが、以上報告でした。