この記事は、The Twelve-Factor Appを補足し、実際に現代的なWebアプリケーションで適用する場合の注意点などを紹介するシリーズです。下記の原文を読んだ上でのワンポイント解説になります。
概要
- アプリケーションは単一または複数のプロセスによって構成される
- アプリケーションプロセスは状態を持ってはいけない・または状態をいつ破棄されても問題がないシステムになっている
これは何を表しているか
「Twelve-Factorのプロセスはステートレスかつシェアードナッシング」とありますが、ステートレスは文字通り状態を持たないことです。シェアードナッシングというのは、プロセスがお互いにリソースを共有しておらず、例えばどれか1つが死んでも他に影響を与えないような構造のことを指します。
プロセスはいつ勝手に再起動されても問題がないような構造にしておくことで、手軽に扱えるようになります。状態を持っていたり再起動に不安がある構造だと、障害発生時にオペレーションが煩雑になり、そもそもデプロイ方法も煩雑になることが予想されます。
ユーザーを特定するためのセッションのような仕組みは、MemcachedやRedisといった外部ストレージを利用することで永続化することができます。プロセス内メモリで保存していると、再起動した時点でセッションが全て初期化されてしまい、ユーザーに再ログインさせる必要などが発生します。
実際に運用する場合
Webアプリケーションにおいてプロセス内のメモリを永続的に信頼するようなコードはそもそも書くことが難しいので、標準的な構成であれば問題がないと思います。メモリを永続化する仕組み、例えばPHPのAPCのようなものを使う場合は、それを完全に信頼せず、いつ初期化されていても問題がない設計にしておくべきです。
フレームワークの組み込みのキャッシュ機構で、キャッシュの保存先をローカルのメモリや外部ストレージから指定できるようなものがありますが、破棄されて問題がないキャッシュであればメモリに保存する選択肢も悪くはありません。ローカルのメモリにキャッシュする場合、高速ではあるもののプロセス毎にキャッシュが作られることになりますので、キャッシュの利用頻度や計算速度などを考慮して選択しましょう。
セッションに関しては前述の通りMemcachedやRedisといった外部ストレージに保存すべきです。こちらもフレームワークに設定方法があると思いますので、事前に確認しておきましょう。