uwsgiのgraceful reload(hot reload)について日本語で解りやすくまとまっている記事が無かったのでまとめてみようと思いました。

graceful reloadについて

既に稼働しているアプリケーションサーバを更新する際に、既に接続しているクライアントが切断されないようにreloadを行うための技術です。v1からv2の状態へと移行するためにreloadした場合v1のworkerを保持しつつv２のworkerを立ち上げてv1の接続がなくなったら順次そのworkerを切って行き、接続を切断せずに移行して行くような方法があります。

参考ドキュメントと動画

○ The Art of Graceful Reloading

○ [動画] pycon jp 2015 uWSGI/Dockerを利用したWebサービス運用事例

graceful reloadの種類

今回はuwsgiのtouche-reload系のoptionを追加して実行するだけで対応出来る3種類の方法を紹介したいと思います。
他にも上記の記事や動画では紹介していますが、uwsgiのoption以外にも構成を変えたりしないといけなかったりしたので、とりあえず簡単なものだけ説明させて頂きたいと思います。

Standard graceful reload
Workers reloading
Chain reloading

Standard graceful reload

¹workers/processesへの接続が全てがなくなったのを確認してuwsgiを再起動する手法です。
reloadに時間がかかるのとその待機中にタイムアウトしてしまうユーザが発生する可能性があります。

--touch-reloadオプションを利用するとStandard graceful reloadでリロードされます。

起動例.

$ uwsgi --touch-reload path/to/reload.trigger -s path/to/app.socket
$ touche path/to/reload.trigger

Workers reloading

¹worker/processeのみ再起動します。
全体の再起動を行わないため、速度があがりますがコードの更新しか反映されません。
また、preforkには使えません。

--touch-workers-reloadオプションを利用するとWorkers reloadingでリロードされます。

example.

$ uwsgi --touch-workers-reload path/to/reload.trigger -s path/to/app.socket
$ touche path/to/reload.trigger

Chain reloading

¹worker/processeを1つずつ再起動します。「Workers reloading」の改良版です。
順次更新して行く形なのでクライアント側の待ち時間が少ないです。
また、処理が分散されるのでリロード時の負荷が少ないです。

--touch-chain-reloadオプションを利用するとChain reloadingでリロードされます。