Django本番環境のデプロイ構成

　Djangoで開発したWebアプリを本番でどんな構成でデプロイすればいいかについて書きます。

全体のDjangoアプリデプロイ構成

　基本的には、Djangoアプリケーション、アプリケーションサーバー、Webサーバーの3層と考えると良いです。

　manage.py runserverは開発用であり簡易的な機能のため本番には向いていません。並列処理機能がなく、プロセスが落ちた場合に自動起動などができないなどの問題があります。

　とりあえず、manage.py runserverは本番では使うべきではないと覚えておくべきです。

　アプリケーションサーバーは高パフォーマンスで、並列処理やアクセスログ出力などの機能があります。

　アプリケーションサーバーはGunicornやuWSGIが一般的に利用されています。

　Gunicornはpipのみで入り、gunicornコマンド1発で動くなど、使い方が単純でおすすめです。

　また、アプリケーションサーバーとDjangoのつなぎ合わせはWSGIというインターフェースでやり取りをします。WSGIはライブラリ開発者側でなければあまり意識するところではありません。

　プロセス自動再起動やサーバー再起動時の自動立ち上げはLinuxならSystemdを使うと良いです。Systemdスクリプトを書いてService登録する必要があります。

　アプリケーションサーバーだけだと、CSSやJSなど静的ファイルの配信処理が重いです。Webサーバーをリバースプロキシとして動かすと良いです。

　1度Webサーバーがアクセスを受けて、静的ファイルならWebサーバーが配信、動的に画面を組み立てる必要があるならアプリケーションサーバーに流す感じです。

　Nginxでのリバースプロキシの設定方法は以下のURLを参照。
　https://blog.narito.ninja/detail/21

　静的ファイル配信がWebアプリケーションサーバーより高速であり、キャッシュなどができるためパフォーマンスが上がります。

　HTMLを動的に組み立てるなど、動的な処理だけgunicornに渡してあげることでパフォーマンス向上につながります。

　また、リクエストボディの大きさを制限したり、タイムアウト設定などができ、セキュリティ面を強化する役割もあります。