サーバーを立てることになりました。
あとでしっかり設計固めて作りなおすことが前提な、デモ版のサーバーです。
pythonのバージョン、仮想環境、ミドルウェアの選定もとりあえず僕がして、動くものをできるだけ早く作る！という感じです。
で、EC2 + Nginx + Gunicornを使うことにしました。
なぜなら僕が自分のサービスで使っている構成だから(EC2はLightsailのものだけど)。
以下を参考にしました。
AWSにDjangoアプリケーションをデプロイ(Nginx, gunicorn, postgresql)

流れ

・EC2インスタンスの立ち上げ
・ポート開ける
・Amazon-Linux(EC2)にユーザー作る
・Pythonをtarファイルからインストール
・シンボリックリンクを貼る
・Django入れる
・Nginx入れる
・Gunicorn入れる
・https化する

といった流れです。
https化はオレオレ証明書を使っていてnginxをさらにいじるのが面倒だったため、
ELB(+ACM発行証明書)→EC2
のパターンでやろうかなと思っています。
EC2のhttps化は8種類あって、そのうち最もスタンダードなものらしいです。
(参考 : AWSでWebサイトをHTTPS化 全パターンを整理してみました)
本番ではそれも精査しないと。

これで、
Client ⇒ サーバー80番ポート(Nginx) ⇒ サーバー8000番ポート(gunicorn) ⇒ Djangoアプリケーション
の流れを作れます。
例えばwebsocketを組み込みたいときは、ws(wss)://から始まるリクエストは、Nginxでサーバー8001番に振り分けて、gunicornの代わりにdaphneで受け取って、DjangoのAsgiに流したりします。
ここらへんは今度またwebsocket組み込むアプリ作るのでそのときにでも書きます。

ハマったところとか得た知識とか

・sudo su でログインしなかったから、Python3が使えなかった

・Nginxの文法エラーは

nginx -t

ですぐわかる

・too many open files
ってエラーがNginxで出ましたが、

location / {
    proxy_pass http://127.0.0.0:8000;
}

にしてなかっただけっぽいです。
このproxy_passをIPアドレスにしていたため、同じサーバーの8000番ポートに流してgunicornに流すはずが、再びNginxで受け取る流れになってしまったのだろうか？
だとしたら無限ループに陥ってtoo many open filesが出るのも納得。
ちなみにマジのtoo many open filesエラーにはnginxのworker_rlimit_nofileの設定を変える必要があるっぽいです。
worker_rlimit_nofile の設定値は worker_connections の値の３〜４倍程度がいいらしいです(デフォルトのworker_connectionsは1024なのでworker_rlimit_nofileは4096に設定しているサイトが多かった)。
(参考 : Nginx - ファイルディスクリプタ設定(Too many open files 対策)！)

とまぁこんな感じですね。
インフラはいじる機会があまり多くないので忘れがちですね。
こんな感じでどんどん備忘録を作っていきます。
ハマらなければ20分くらいで構築できると思うので、それを目指します。
AWSとDjangoなら一瞬でサーバー構築できる人になりたいな！

本日もお読みいただきありがとうございました！