Skip Navigation
Show nav
Heroku Dev Center
  • Get Started
  • ドキュメント
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
  • ドキュメント
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
View categories

Categories

  • Heroku のアーキテクチャ
    • Dyno (アプリコンテナ)
    • スタック (オペレーティングシステムイメージ)
    • ネットワーキングと DNS
    • プラットフォームポリシー
    • プラットフォームの原則
  • コマンドライン
  • デプロイ
    • Git を使用したデプロイ
    • Docker によるデプロイ
    • デプロイ統合
  • 継続的デリバリー
    • 継続的統合
  • 言語サポート
    • Node.js
    • Ruby
      • Bundler の使用
      • Rails のサポート
    • Python
      • Django の使用
      • Python でのバックグランドジョブ
    • Java
      • Maven の使用
      • Java でのデータベース操作
      • Spring Boot の使用
      • Java の高度なトピック
    • PHP
    • Go
      • Go の依存関係管理
    • Scala
    • Clojure
  • データベースとデータ管理
    • Heroku Postgres
      • Postgres の基礎
      • Postgres Getting Started
      • Postgres のパフォーマンス
      • Postgres のデータ転送と保持
      • Postgres の可用性
      • Postgres の特別なトピック
    • Heroku Redis
    • Apache Kafka on Heroku
    • その他のデータストア
  • モニタリングとメトリクス
    • ログ記録
  • アプリのパフォーマンス
  • アドオン
    • すべてのアドオン
  • 共同作業
  • セキュリティ
    • アプリのセキュリティ
    • ID と認証
    • コンプライアンス
  • Heroku Enterprise
    • Private Space
      • インフラストラクチャネットワーキング
    • Enterprise Accounts
    • Enterprise Team
    • Heroku Connect (Salesforce 同期)
      • Heroku Connect の管理
      • Heroku Connect のリファレンス
      • Heroku Connect のトラブルシューティング
    • シングルサインオン (SSO)
  • パターンとベストプラクティス
  • Heroku の拡張
    • Platform API
    • アプリの Webhook
    • Heroku Labs
    • アドオンのビルド
      • アドオン開発のタスク
      • アドオン API
      • アドオンのガイドラインと要件
    • CLI プラグインのビルド
    • 開発ビルドパック
    • Dev Center
  • アカウントと請求
  • トラブルシューティングとサポート
  • Integrating with Salesforce
  • 言語サポート
  • Python
  • Gunicorn を使用した Python アプリケーションのデプロイ

Gunicorn を使用した Python アプリケーションのデプロイ

日本語 — Switch to English

最終更新日 2023年02月22日(水)

Table of Contents

  • アプリケーションへの Gunicorn の追加する
  • 基本設定
  • 高度な設定
  • 参考情報

受信 HTTP リクエストを並列処理する Web アプリケーションの方が、一度に 1 つのリクエストしか処理しない Web アプリケーションより dyno リソースをより効率的に使用します。このため、本番環境のサービスを開発して実行するときは常に、並列リクエスト処理をサポートする Web サーバーを使用することをお勧めします。

Django と Flask の各 Web フレームワークは便利なビルトイン Web サーバーを備えていますが、これらのブロッキングサーバーは一度に 1 つのリクエストしか処理しません。Heroku でこれらのサーバーを使用してデプロイを行うと、dyno リソースの利用効率とアプリケーションの応答性が低下します。

Gunicorn​ は、WSGI アプリケーション用の純粋な Python HTTP サーバーです。単一 dyno 内で複数の Python プロセスを実行することによって、任意の Python アプリケーションを並列して実行できるようにします。Gunicorn は、パフォーマンス、柔軟性、設定のシンプルさの絶妙なバランスを提供します。

このガイドでは、Gunicorn Web サーバーを使用して新しい Python アプリケーションを Heroku にデプロイする方法について説明します。Heroku の基本的なセットアップと知識については、「Getting Started with Python​」(Python スターターガイド) を参照してください。

いつものように、本番環境アプリケーションにデプロイする前に、ステージング環境で設定変更をテストします。

アプリケーションへの Gunicorn の追加する

まず、pip​ を使用して Gunicorn をインストールします。

$ pip install gunicorn

必ず、requirements.txt​ ファイルにも gunicorn​ を追加してください。

次に、Gunicorn を使用するためにアプリケーションの Procfile​ を修正します。次に示すのは、「Heroku スターターガイド (Python)​」で作成した Django アプリケーション用の Procfile​ の例です。

Procfile

web: gunicorn gettingstarted.wsgi

基本設定

Gunicorn は各 dyno 内で複数のシステムプロセスをフォークして、Python アプリがスレッドセーフでなくても複数の並列リクエストをサポートできるようにします。Gunicorn の用語では、これらはワーカープロセスと呼ばれます (独自の dyno で実行される Heroku ワーカープロセスと混同しないようにしてください)。

システムプロセスをフォークするごとに消費メモリが増加します。これにより、1 つの dyno で実行できるプロセスの数が制限されます。一般的な Django アプリケーションのメモリフットプリントでは、eco​、basic​ または standard-1x​ dyno で 2 ~ 4 個の Gunicorn ワーカープロセスが実行されることが想定されます。アプリケーション固有のメモリ要件によっては、この想定から外れることが許容される場合があります。

この設定のための環境設定を行うことをお勧めします。WEB_CONCURRENCY​ 環境変数が設定されている場合、Gunicorn は自動的にこの環境変数を優先します。

$ heroku config:set WEB_CONCURRENCY=3

WEB_CONCURRENCY​ 環境変数は、プロセスの dyno サイズに基づいて、Heroku によって自動的に設定されます。この機能は、アプリケーションのための適切な開始点になることを目的にしています。プロセスのメモリ要件を把握し、それに応じてこの環境設定を調整することをお勧めします。

Procfile

web: gunicorn hello:app

Heroku Labs の log-runtime-metrics​ 機能は、実行中の dyno の負荷およびメモリ使用量を可視化するためのサポートを追加します。有効にすると、heroku logs​ コマンドを使用してアプリケーションのメモリ使用量を監視できます。

高度な設定

アプリの事前ロード

メモリの制約がある場合やアプリの起動時間が低速な場合は、preload​ オプションを有効にすることを検討してください。有効にすると、ワーカープロセスがフォークされる前にアプリケーションコードが読み込まれます。

web: gunicorn hello:app --preload

詳細については、事前ロードに関する Gunicorn のドキュメント​を参照してください。

ワーカーのタイムアウト

デフォルトでは、ワーカーが過去 30 秒以内に何の処理も完了していない場合、Gunicorn によって暗黙的にワーカーが再起動されます。リクエストの絶え間ない受信フローにアプリケーションが迅速に応答することを期待する場合は、タイムアウト設定値を下げてみてください。

$ gunicorn hello:app --timeout 10

詳細については、ワーカーのタイムアウトに関する Gunicorn のドキュメント​を参照してください。

最大リクエストリサイクル

アプリケーションでメモリリークが発生している場合、指定された数のリクエストがワーカーで処理された後、ワーカーを暗黙的に再起動するように Gunicorn を設定できます。これは、メモリリークの影響を限定するために役立つ便利な方法となる可能性があります。

$ gunicorn hello:app --max-requests 1200

詳細については、最大リクエスト数に関する Gunicorn のドキュメント​を参照してください。

参考情報

  • Gunicorn のドキュメント

関連カテゴリー

  • Python
Python ランタイムの指定 Heroku の Python サポート

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing
  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Github
  • LinkedIn
Heroku is acompany
  • heroku.com
  • Terms of Service
  • Privacy (日本語)
  • Cookies
  • Cookie Preferences
  • Your Privacy Choices
  • © 2023 Salesforce.com