はじめに
概要
Gunicorn（ガンコーン）は、Python製のWSGIアプリケーションサーバーです。FlaskやDjangoなどで作ったWebアプリケーションを本番環境で安定して動かすために使います。NginxなどのフロントWebサーバーとアプリケーションの間に入って、リクエストを受け渡す役割を果たします。
なぜ使うのか（例）
開発中はデバッグサーバーだけで動きますが、本番では高負荷や同時接続に強い仕組みが必要です。たとえば、ブラウザから多数の同時アクセスがあっても、Gunicornは複数のプロセスを使って効率よく処理します。これにより安定性が増します。
簡単なイメージ
WSGIは「通訳」のような役割で、Gunicornはその通訳を実際に動かす器です。Nginxが郵便局、Gunicornが配達員、アプリが受取人と考えると分かりやすいです。
この章ではまず用途と全体像を抑え、次章以降で詳しい仕組みや特徴を丁寧に説明します。
Gunicornとは
概要
Gunicorn（正式名：Green Unicorn）は、UNIX系OS向けの本番用WSGI HTTPサーバーです。FlaskやDjangoなどのWSGI対応アプリを、開発用サーバーより高速で安定して公開するために使います。
何をするか
GunicornはHTTPリクエストを受け取り、Pythonのアプリケーションに渡して処理結果を返します。たとえばブラウザでページを開くと、Gunicornがリクエストを受け取り、Flaskに処理を委ねてレスポンスを返します。処理の受け渡しを仲介する役割です。
特徴（簡単に）
- 軽量で設定がシンプルです。コマンド一行で起動できます。
- ワーカープロセスを立ち上げて並列にリクエストを処理します。1台のサーバーで多くの同時接続をさばけます。
- UNIX系に最適化されており、Linux環境でよく使われます。
対応するアプリ例
- FlaskやDjangoなどのWSGI対応フレームワーク
- 既存のWSGIアプリケーションの本番運用
導入のイメージ
本番ではGunicornをアプリ用プロセスとして動かし、その前段にnginxなどのリバースプロキシを置く構成が一般的です。nginxが静的ファイル配信やSSLを担当し、GunicornがPythonコードの実行を担当します。
役割と仕組み
役割
Gunicornは、NginxなどのフロントWebサーバーとFlaskやDjangoといったPythonアプリの橋渡しをします。具体的には、HTTPリクエストをアプリが処理できるWSGIという形に変換して渡します。たとえばNginxが受け取ったリクエストをUNIXソケットやTCPソケット経由でGunicornに送り、Gunicornがアプリに渡して応答を返します。
仕組みの概要
Gunicornはプリフォーク（マルチプロセス）モデルを採用します。マスタープロセスが起動し、複数のワーカープロセスを生成して管理します。ワーカープロセスが実際にアプリを読み込み、リクエストを処理します。
- マスター: ワーカーの監視、再起動、設定の反映を行います。ワーカーがクラッシュしてもマスターが新しいワーカーを立ち上げます。
- ワーカー: 実際のリクエスト処理を行います。同期（1リクエストずつ）と非同期（並行処理可能）のクラスがあり、用途に応じて選びます。
リクエストの流れ（簡単な例）
- クライアント→Nginxが受け取る
- Nginx→UNIX/TCPソケット経由でGunicornへ渡す
- GunicornのワーカーがWSGIでアプリに渡し処理する
- アプリの応答をワーカーが受け取り、Nginxへ返す
運用で注目する点
- ワーカー数: 一般的にCPUコア数に合わせて設定します（例: CPU数×2+1）。
- タイムアウトや再起動: 長時間処理やメモリリーク対策で設定します。
- ログとヘルスチェック: 問題発生時にどのプロセスが原因か特定しやすくなります。
特徴
シンプルで扱いやすい
Gunicornは基本がコマンド一発で動く設計です。例えば「gunicorn myapp:app -w 4 -b 0.0.0.0:8000」と打てばローカルで立ち上がります。設定はコマンドラインや設定ファイルで分かりやすく切り替えられます。
高性能で堅牢
ワーカープロセスを複数立ち上げる方式を採用します。1つのワーカーが問題で落ちても、他のワーカーが処理を続けるためサービス全体の安定性が高まります。同期型・非同期型など用途に合わせたワーカーを選べます。
スケーラビリティ
アクセスが増えたらワーカー数を増やすことで対応できます。目安として「ワーカー数＝CPUコア数×2＋1」のような計算がよく使われます。負荷の高い処理はワーカー構成や外部キューで分散できます。
運用のしやすさ
開発時は–reloadで素早く差し替えられ、本番はsystemdやコンテナと組み合わせて自動起動や監視を行います。ログやタイムアウトの設定が豊富で運用負荷を減らせます。
具体的な利用例
小〜中規模のWebアプリで手早く本番運用したいときに向きます。Nginxなどのリバースプロキシと組むことで公開環境に安定して導入できます。
他のPython Webサーバーとの違い
概要
Gunicornは主にWSGI仕様の同期型アプリ（例：Flask、Django）に向きます。一方、UvicornやHypercornはASGI対応で非同期処理やWebSocketに強みがあります。
同期（WSGI）と非同期（ASGI）の違い
- WSGI（Gunicorn）: リクエストごとにプロセスやスレッドで処理します。データベースや外部APIの呼び出しが同期的だと簡単に扱えます。例：伝統的なDjangoアプリの本番運用。
- ASGI（Uvicorn/Hypercorn）: イベントループで非同期I/Oを効率的に処理します。多数の同時接続やWebSocketが必要な場面で有利です。非同期関数（async/await）を使うことで待ち時間を有効活用できます。
実際の使い分け（判断基準）
- シンプルな同期アプリや既存のFlask/Django: Gunicornが安定で導入が容易です。
- 高い同時接続数、WebSocket、FastAPIなどの非同期フレームワーク: UvicornやHypercornを選びます。
- ハイブリッド運用: UvicornのワーカーをGunicornで動かすなど選択肢がありますが、設定や監視に注意が必要です。
性能と運用面の違い
非同期はI/O待ちが多い場合に効率的です。CPU負荷が高い処理では複数プロセスを使う同期モデルが有利なことがあります。ロギングやデプロイのエコシステムはGunicornが成熟していますが、ASGI側も急速に整っています。
まとめ代わりの簡潔な助言
用途に応じて選べばよいです。同期処理中心ならGunicorn、非同期やWebSocket中心ならUvicorn/Hypercornを検討してください。
いつ使うとよいか
本番環境での基本的な使いどころ
FlaskやDjangoで作ったアプリを開発用サーバーのまま運用すると、性能や安定性が足りない場面が出ます。Gunicornはその隙間を埋め、本番環境でアプリを安定して動かすために使います。具体例としては、社内向けダッシュボード、管理画面、標準的なREST APIなど、リクエストごとに処理が完結するWebアプリです。
向いているケース（具体例）
- 画面表示やデータベース問合せが中心の業務アプリ（注文管理や顧客管理など）
- リクエストが短時間で終わるAPI
- Nginx＋Gunicorn＋（Flask/Django）の構成で静的ファイルをNginxに任せる運用
これらは設定を少し調整するだけで安定した応答を得られます。
向かないケースと代替案
- 画像処理や機械学習などCPU負荷が高い長時間処理には向きません。その場合は専用ワーカーやバッチ処理（例：Celery）に切り出すとよいです。
- WebSocketや大量の長時間接続が必要なリアルタイム系は、uvicornやuvloopなど非同期サーバーのほうが適します。
運用上のポイント
Nginxをフロントに置き、Gunicornを複数ワーカーで動かします。ワーカー数やタイムアウトを実測に基づき調整し、ログと監視を用意してください。コンテナやsystemdでプロセス管理すると再起動やデプロイが楽になります。
