はじめに
今回は Amazon Lightsail のWordpressにおいてなぜか数日で落ちる問題への対応についてです。
この辺りの記事が詳しいです。
記事を参考にすると2日おきに落ちるとのことでした(うちの環境ではそれほどの頻度ではありませんでしたが)。
サービスのステータスがアクセスできなかった時にメールを送信させていましたが、うちの環境ではバックアップ作成時に落ちていたようです。
色々試行錯誤をしましたが、おそらく swap メモリが未定義だったことが原因と考えられます。というのも、swap を指定してから1週間、とりあえず安定しています。
サーバのダウンが発生しているであろう定期処理は BackWPup が実行されるタイミングです。毎日4:00にバックアップが実行されますが、7時など、サーバ復旧後は実施時間が微妙に異なります。4:00に空いていても処理されないのが不明ですが……。
プランの見直し
さて、はじめに現在の料金プランが問題かと調べました。
最小構成はない、という点がポイントです。
現在のプランは「1 GB RAM、2 vCPU、40 GB SSD」です。
最小プランは「0.5 GB RAM、2 vCPU、20 GB SSD」です。昔、最小プランで数日運用しましたが処理が追いつかなかったため、下から2番目のプランを指定していました。
参考までに、一つ上のプランは「2 GB RAM、2 vCPU、60 GB SSD」で、メモリが倍になる程度です。
実運用上は、以下の条件を満たせば動作するはずです。
最小でも1GB以上を割り当てる必要があります。
https://wp.xserver.ne.jp/support/manual/man_wp_resource_limit.php
メモリが0.5GBではほぼ使えない状態だったので、上記の記事は正しいと思います。最小構成でも1GBあれば動作するはずで、実際に1GBでは通常使う程度なら問題なく動作しています。
問題の切り分け
問題は、しばらく経過すると落ちることです。WordPress のサービスが落ちるならまだ理解できますが、インスタンス自体が無応答になります。そのため、WordPress の問題ではなく Lightsail 側の問題だと考えられます。
サービスが落ちる時には CPU がバーストしています。具体的にはメトリクスグラフを確認するとステータスチェックが失敗しています。今回はこのエラーが発生した際にメールを送らせて対応しました。
Swap メモリでの対応
今回、この問題を解消するために swap メモリを実装することで、とりあえずの対応としました。
Swap メモリの設定方法は以下の記事が参考になります。
しばらく様子を見ていますが、現在は問題なく動作しています。
現在の状態は以下の通りです。
$ free -m
total used free shared buff/cache available
Mem: 945 573 217 54 357 371
Swap: 4095 75 4020swap がしっかり使われていることが分かります。
終いに
今回は、AWS Lightsail 上で動作する WordPress のサービスがなぜか数日で落ちる問題の対策として、swap メモリを指定することで解消できるという記事を書きました。
まだこれが決定的な解決策とは言い切れませんが、現在のところ落ちる現象は発生していません。このまま安定して動作してくれると嬉しいです。
