WEBサーバー

ポート監視して、自動リブート@AWS EC2

ECCUBE3は、ECCUBE2と比べて、対応速度は格段に早いし、
その恩恵ともなるのが、コアのSymfonyですが、

EFSが使えない(おそらく、ファイル数が多すぎるのが原因)

は、解決し、今回は、こちらの問題について。

 

エラーが出ると、502に陥り、暴走が始まる。

単純に、エラーコードを書くと、カンタンに発生出来ました。

その都度、PHP-FPMをリブート。

実運用では、暴走しているであろうCPUの高負荷状態を、
CloudWatchで監視し、リブートさせたわけですが、
最終的には、crontabでの10分ごとの禁断の自動リブート

その結果、サーバーが落ちることはなくなりましたが、
新たな問題が発生。

 

決済プロセスが途中で中断される

まあ、当然予測していたわけですが、、、
A.完全停止とB.決済落ちと、どっちがいい?という、狭間でしたので。

当然、機会損失の少ないBとなるわけですが、

 

原因は、PHP-FPMのメモリーリーク

PHP Fatal error: Allowed memory size of xxx bytes exhausted

 

  1. エラーが起きないようコードを書き換える。
  2. PHP-FPMの自動リブート

1. Synfony内部まで、触っていられないし、原因が取り切れるわけではないので、
2. PHP-FPMの設定も修正し、毎分ステータスチェックの自動リブートを作りました。

 

PHP-FPMの設定

pm.max_requestsを上げればいいだとか、
memory_limitを上げればいいだとか、

無尽蔵のメモリーを積めば、解決するかもしれませんが、
地球温暖化対策のため、最小メモリーの512Mなので、

www.conf

pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 128

php_admin_value[memory_limit] = 32M

1プロセス 32MB x 8プロセスを上限 とし、
128リクエスト毎にプロセスを、自己再生を設定。

参考 > PHPのメモリの上限やエラーについて学ぼう!メモリの考え方基本解説

この設定でも、発生するので、

参考 > Nginx + PHP-FPM で 502 Bad Gateway が時折発生する場合の対処方法

request_terminate_timeout

単一のリクエストを処理する際のタイムアウト。この時間を過ぎるとワーカープロセスが kill されます。 このオプションは、’max_execution_time’ ini オプションが何らかの理由でスクリプトの実行を止められなかった場合に使われます。 値 ‘0’ は ‘Off’ を意味します。 使用可能な単位: s(秒)(デフォルト), m(分), h(時間) あるいは d(日)、 デフォルト値: 0
PHP: 設定 – Manual より

 

今のところ、3日間無停止が続いていますので、
今回、「暴走時、指定時間後、killしてくれる」が、肝だったということでしょう。

WEBなら、30秒でいいんじゃないですかね?、長くても60秒?。
しかし、デフォ0っていうのが、理解不能。せめて、初期値300などしておいてほしい箇所でした。

 

それでも心配なので、

ステータスチェック

CloudWatchでは、ポート監視できるのは、EC2ではなく、ALBだけ。
どの機械かはわからず、再起動も負荷。

結局、CPUのクレジットの使用下限を設けて、
リブートしか出来ないため、自前で実装。

LOGFILE=/var/log/phpfpm-check-status.log
URL=http://127.0.0.1/_healthcheck4elb.php
HTTP_STATUS=`curl -LI ${URL} -o /dev/null -w '%{http_code}\n' -s`

log=`date '+%Y-%m-%d %H:%M:%S'`" PHPFPM STATUS:${HTTP_STATUS} RESTARTED"
if [ $HTTP_STATUS = "200" ]; then
    exit;
else
echo ${log} | sudo tee -a ${LOGFILE}
    sudo docker stop phpfpm
    sudo docker start phpfpm
fi

あとは、これをcrontabで毎分実行。
エラー時には、メールで通知されると、便利かも。

 

その他参考

 

 

-

DropboxをEC2に入れて冗長化 > Syncthing導入

前述、ECCUBE3 on EFSが遅すぎるため、Dropboxを入れて、冗長化してみましたが、

Windows版だと、一番性能が良いと思っておりましたが、
CPUがやたらと回るし、ファイル同期も欠損が生じるレベル。

CPUクレジットが減る一方で、手動停止する始末・・・

***

S3Syncなど、いろいろな冗長化の方法はあると思いますが、
今回は、「Syncthing」という同期ツールを使いました。

センターサーバー(親)はあるものの、P2Pなので、
クライアント同士がファイルを持ち合います。
=親はファイルを持たない

オープンソースなので、悪いコードが含まれているかも、
確認可能なのも、いいところ。

 

Syncthing

Pythonのバージョンの違いなどで、インストールが難航したのですが、
Alpha LinuxのDockerイメージを見つけたので、
それを用いました。

https://hub.docker.com/r/syncthing/syncthing

 

インストールが終わると、あとはブラウザーを使って、設定するだけ。
超簡単なんですが、

 

所有者問題で苦労しました。

Docker Fileには、

ENV PUID=1000 PGID=1000 HOME=/var/syncthing

と、定義されていますが、ec2-userは500:500

WinSCPは、500で接続しているので、
A機でファイルを作ると、所有者は500ですが、
同期先のB機では、1000になります。

B機で編集すると、所有者の問題から、A機には反映されません。

664にしておけばいいのですが、
都度都度設定するのは、わりと面倒でした。

 

Docker FIleのPUID / GUIDを500:500にすればいいのですが、
うまくいかなかったので、

結局、1000:1000のアカウントで、WINSCPに接続し、完結。

 

同期のタイムラグ

が、数秒あります。

直接編集時は、ブラウザーが、どっちの機に繋がっているかを特定し、
そののサーバーに接続して、作業することで、
タイムラグを解消しました。

 

PS.
AWSを使い始めて、5年目となりました。
もっと便利な機能はあるんだろうけど、未開拓が山積みですが、

特に、トラブった時。解決索を見いだせる様になったので、
「Linux楽しぃ!」と思えるようになってきました。

が、普通のレンタルサーバーが如何に楽(ラク)か、、、

-