The Twelve-Factor App

VI. プロセス

アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する

アプリケーションは、実行環境の中で1つもしくは複数の プロセス として実行される。

最も単純な場合では、コードは単体のスクリプトであり、実行環境は言語ランタイムがインストールされた開発者のローカルノートPCであり、プロセスはコマンドラインから実行される（例：python my_script.py）。対極にあるのは、複数の実行プロセスとしてインスタンス化される多くのプロセスタイプを使う洗練されたアプリケーションの本番デプロイである。

Twelve-Factorのプロセスはステートレスかつシェアードナッシング である。永続化する必要のあるすべてのデータは、ステートフルなバックエンドサービス（典型的にはデータベース）に格納しなければならない。

プロセスのメモリ空間やファイルシステムは、短い単一のトランザクション内でのキャッシュとして利用してもよい。例えば、大きなファイルをダウンロードし、そのファイルを処理し、結果をデータベースに格納するという一連の処理において、ファイルシステムをキャッシュとして利用できる。Twelve-Factor Appは、メモリやディスクにキャッシュされたものが将来のリクエストやジョブにおいて利用できることを決して仮定しない – それぞれのプロセスタイプのプロセスが多く実行されている場合、将来のリクエストやジョブが別のプロセスで処理される可能性が高い。1つのプロセスしか実行されていない場合であっても、プロセスが再起動すると、すべての局所的な状態（メモリやファイルシステムなど）が消えてしまうことがある。プロセスの再起動の要因としては、コードのデプロイ、設定の変更、プロセスを別の物理位置に再配置する実行環境などがある。

アセットパッケージャー（例：Jammit や django-compressor）は、コンパイルされたアセットをキャッシュするためにファイルシステムを利用する。Twelve-Factor Appは、このコンパイル処理を実行時に行うよりも、Rails asset pipelineのようにビルドステージで行うほうが、望ましいと考えている。

Webシステムの中には、“スティッキーセッション”に頼るものがある – これはユーザーのセッションデータをアプリケーションプロセスのメモリにキャッシュし、同じ訪問者からの将来のリクエストが同じプロセスに送られることを期待するものである。スティッキーセッションはTwelve-Factorに違反しており、決して使ったり頼ったりしてはならない。セッション状態のデータは、有効期限を持つデータストア（例：Memcached や Redis）に格納すべきである。