Google Compute Engineで動かしているWordPressサーバーに、サイズ適正化の推奨事項が出ていました。
過去7日間のCPU使用率とメモリ使用量が低いため、現在の e2-standard-2 から e2-medium に変更すると、月額 $30.83 を節約できるという内容です。
月額で約30ドル、年間にすると約370ドルです。個人ブログのインフラ費としては無視しづらい金額なので、今回はこの推奨事項を適用しました。
ただし、マシンタイプを下げるということは、単に料金が安くなるだけではありません。今回はメモリが 8GB から 4GB に半減します。
そのため、スケールダウン前の確認と、スケールダウン後のメモリ不足対策としてSwap領域の追加まで行いました。
この記事で分かること
- GCEのサイズ適正化を適用する前に確認したこと
- 静的IPアドレスとスナップショットを確認した理由
- メモリ半減後に2GBのSwapファイルを追加した手順
- Swap追加後に見ておきたい注意点
やったこと
今回やったことは次の3つです。
- GCEの外部IPアドレスが静的IPとして予約されているか確認する。
- 自動スナップショットが正常に取得されているか確認する。
e2-mediumへ変更したあと、2GBのSwapファイルを追加する。
スケールダウン前に確認したこと
GCEのマシンタイプ変更では、VMの停止と再起動が発生します。
作業自体はGoogle Cloudコンソールから数クリックでできますが、WordPressの公開サーバーなので、事前にIPアドレスとバックアップを確認しておきます。
なお、GCEではWordPressのデータや設定ファイルは永続ディスクに保存されています。そのため、マシンタイプを変更するだけでディスク上のデータが消えるわけではありません。
ただし、VMの停止・再起動によるダウンタイムや、構成変更後にサービスが期待通り起動しない可能性はあります。データが消えない作業であっても、公開サーバーでは事前確認をしてから進めるのが安全です。
静的IPアドレスを確認する
まず、外部IPアドレスが静的IPとして予約されているか確認しました。
外部IPがエフェメラル、つまり動的なIPアドレスの場合、VMの停止や再作成のタイミングでIPアドレスが変わる可能性があります。IPアドレスが変わると、DNSレコードの修正も必要になります。
今回はGoogle CloudコンソールのIPアドレス画面で、対象VMに割り当てられている外部IPの種類が 静的 になっていることを確認しました。
これで、VMを停止・再起動しても、WordPressの公開先IPが変わらないことを確認できました。
スナップショットを確認する
次に、永続ディスクのスナップショットを確認しました。
マシンタイプ変更で問題が起きる可能性は高くないと思いますが、VMが起動しなくなる、サービスが立ち上がらない、といった事態に備えて復元ポイントは必要です。
今回は毎日深夜に自動スナップショットを取得するスケジュールを設定しているため、直近のスナップショットが正常に作成されていることを確認しました。
サイズ適正化を適用する
事前確認ができたので、GCEコンソールの推奨事項画面からサイズ適正化を適用しました。
変更内容は以下です。
| 項目 | 変更前 | 変更後 |
|---|---|---|
| マシンタイプ | e2-standard-2 | e2-medium |
| vCPU | 2 | 2 |
| メモリ | 8GB | 4GB |
| 月額コスト削減額 | – | $30.83 |
適用時にはVMの停止と再起動が入ります。数分のダウンタイムのあと、WordPressにアクセスできることを確認しました。
変更後に free -h を実行すると、メモリの合計が 3.8Gi と表示されていました。OS上でも4GBメモリの e2-medium に切り替わっていることが確認できます。
$ free -h
total used free shared buff/cache available
Mem: 3.8Gi 768Mi 2.7Gi 6.0Mi 485Mi 2.8Gi
Swap: 0B 0B 0Bメモリ半減への対策としてSwapを追加する
今回の変更で一番気にしたのは、CPUではなくメモリです。
CPUは2 vCPUのままですが、メモリは8GBから4GBに半減します。普段の使用量が低くても、突発的なアクセス増加や管理画面での重い処理、バックアップ処理などが重なると、メモリ不足になる可能性があります。
Linuxではメモリが足りなくなると、OOM Killerによってプロセスが強制終了されることがあります。WordPressサーバーでは、MySQLやWebサーバーが落ちるとそのまま障害になります。
そこで、物理メモリを増やす代わりに、緊急時のバッファとして2GBのSwapファイルを追加しました。
Swapはメモリの代わりにディスクを使うため、性能改善のための設定ではありません。あくまで、メモリ不足でいきなりプロセスが落ちるリスクを下げるための保険として使います。
現在のメモリとSwapを確認する
まず、free -h で現在のメモリとSwapの状態を確認します。
$ free -h今回のVMでは、Swapが 0B になっていました。
2GBのSwapファイルを作成する
SSHでVMに接続し、以下のコマンドを実行しました。
# 2GBのSwapファイルを作成する
$ sudo fallocate -l 2G /swapfile
# rootのみ読み書きできるようにする
$ sudo chmod 600 /swapfile
# Swap領域として初期化する
$ sudo mkswap /swapfile
# Swapを有効化する
$ sudo swapon /swapfile有効化できたら、もう一度 free -h で確認します。
$ free -h今回の実行結果では、Swap の行に 2.0Gi と表示されました。
$ free -h
total used free shared buff/cache available
Mem: 3.8Gi 769Mi 2.7Gi 6.0Mi 485Mi 2.8Gi
Swap: 2.0Gi 0B 2.0Giこれで、Swapファイルが作成され、有効化されていることを確認できました。
再起動後もSwapを有効にする
swapon しただけでは、VMを再起動したときにSwap設定が消えます。
再起動後も有効にするため、/etc/fstab に追記します。
$ echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstabこのコマンドは /etc/fstab に行を追加します。何度も実行すると同じ設定が重複するため、実行は1回だけにします。
必要なら、追記後に以下で確認します。
$ tail -n 5 /etc/fstab今回の実行時は、tee の出力として追加した行が表示されました。
$ echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
/swapfile none swap sw 0 0注意点
Swapを追加しても、メモリ不足の根本原因が解決するわけではありません。
Swapを使い始めるほどメモリが逼迫している状態では、ディスクI/Oが増えてサーバー全体が遅くなります。Swapは「落ちにくくするための余白」であって、「4GBでも8GBと同じように動くようにする設定」ではありません。
スケールダウン後は、しばらく次のような項目を見ておくとよさそうです。
- メモリ使用量
- Swap使用量
- MySQLやApacheのエラーログ
- WordPressの表示速度
- バックアップ実行時間帯の負荷
もしSwapが常に使われているようなら、マシンタイプを戻すか、MySQLやWebサーバー側の設定を見直した方がよさそうです。
まとめ
GCEのサイズ適正化を使って、e2-standard-2 から e2-medium に変更しました。
Google Cloudコンソール上ではボタン数回の作業ですが、公開中のWordPressサーバーなので、事前に静的IPアドレスとスナップショットを確認してから進めました。
結果として、月額 $30.83、年間で約370ドルのインフラ費を削減できました。
一方で、メモリは8GBから4GBに半減します。コスト最適化は「安くする操作」だけではなく、構成変更で増えるリスクにどう備えるかもセットで考える必要があります。
今回は2GBのSwapファイルを追加することで、突発的なメモリ不足に対する最低限の余白を作りました。