プロセスタイプ

プロセスタイプとは

プロセスタイプは、Twelve-Factor App の第 8 原則「並行性はプロセスモデルで実現する」に基づく概念で、アプリケーションの実行形態を Web プロセス、Worker プロセス、スケジュールプロセスなどに分類する。原典は仕事の種類ごとにプロセスタイプを割り当てることを勧めており、HTTP リクエストは web プロセス、時間のかかる背景処理は worker プロセスが担うという分け方を例に挙げている。ただし各プロセスがステートレスであるべきというのは第 6 原則の要求で、プロセスタイプの分割はこの前提の上でしかスケールアウトに効かない。

プロセスタイプの例

分ける基準は「起動のきっかけ」である。同期のリクエスト、キューへの投入、時刻、人の手作業は、それぞれ流量の増え方も遅れの許容度も違うので、別のタイプに割り当てる。

タイプ	役割	AWS での実装
Web	HTTP リクエストの処理	Lambda + API Gateway
Worker	非同期タスクの処理	Lambda + SQS
Clock	スケジュール実行	Lambda + EventBridge
One-off	一回限りの管理タスク (第 12 原則)	Lambda (手動実行)

Procfile (Heroku 形式)

Procfile は <プロセスタイプ名>: <起動コマンド> を 1 行ずつ並べた拡張子なしのテキストファイルで、アプリのルートに置く。ファイル名は Procfile でなければならず、Procfile.txt では認識されない。タイプ名は自由に付けられるが web だけは特別で、Heroku のルーターから外部の HTTP トラフィックを受け取れる唯一のタイプである。

web: node dist/server.js
worker: node dist/worker.js
clock: node dist/scheduler.js

AWS サーバーレスでのプロセスタイプ

サーバーレスに移すと、常駐プロセスが消えてプロセスタイプは「関数とトリガーの組」になる。並行性はプロセス数ではなく同時実行数で決まるため、タイプごとに予約同時実行を切り分けておかないと、片方の急増がアカウント全体の枠を食って他方を枯渇させる。Worker を Lambda に載せる場合は関数のタイムアウト上限 900 秒 (15 分) が設計の制約になり、これを超える仕事は Step Functions で分割するか ECS タスクへ寄せる。

ステートレスの原則

全てのプロセスタイプはステートレスに保つ。永続させる必要があるデータは DynamoDB や S3 のような永続層へ置き、ElastiCache に置けるのは失っても作り直せる状態 (セッションやキャッシュ) までである。原典が禁じているのは「次のリクエストも同じプロセスに来る」という前提で、プロセス内のメモリやファイルシステムは 1 回の処理の中で使う一時置き場にとどめる。デプロイや設定変更、実行環境の移動による再起動でローカルの状態は消える。

実務では、まず web だけで作り、遅い処理が現れた時点で worker へ切り出す順が扱いやすい。分割するとキューの滞留監視と失敗時の再試行設計が増えるので、応答時間・スケールの単位・障害の隔離のどれを買うために分けるのかを毎回はっきりさせる。