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
1workers/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
1worker/processeのみ再起動します。
全体の再起動を行わないため、速度があがりますがコードの更新しか反映されません。
また、preforkには使えません。
--touch-workers-reloadオプションを利用するとWorkers reloadingでリロードされます。
$ uwsgi --touch-workers-reload path/to/reload.trigger -s path/to/app.socket
$ touche path/to/reload.trigger
Chain reloading
1worker/processeを1つずつ再起動します。「Workers reloading」の改良版です。
順次更新して行く形なのでクライアント側の待ち時間が少ないです。
また、処理が分散されるのでリロード時の負荷が少ないです。
--touch-chain-reloadオプションを利用するとChain reloadingでリロードされます。
$ uwsgi --touch-chain-reload path/to/reload.trigger -s path/to/app.socket
$ touche path/to/reload.trigger
まとめ
uwsgiのgraceful reloadには複数の技術があることが解りました。
各手法には長所短所があるため、自分たちのサービスにあった方法を使う事が大切かと思います。
-
この記事の中でworker/processeという表記をしておりますが、uwsgiの中でworkerもprocesseもどちらも同義なため、このような表記をしています。http://uwsgi-docs.readthedocs.io/en/latest/Options.html 内の各workersとprocessesのhelp文言が同じです。 ↩ ↩2 ↩3