この記事は、The Twelve-Factor Appを補足し、実際に現代的なWebアプリケーションで適用する場合の注意点などを紹介するシリーズです。下記の原文を読んだ上でのワンポイント解説になります。
概要
これは何を表しているか
普通のプロセスに関しては「6. プロセス」や「8. 並行性」にかかれている内容と同様です。並行性が高ければ廃棄容易性も自動的に高いものになります。
いやゆるキューから起動する遅延実行処理のような仕組みがある場合、それらの処理が途中で死んでも再実行できるか、同じ処理が複数回走っても正常な結果になるかといったことに気をつけて設計する’必要があります。
実際に運用する場合
いわゆるautoscalingみたいなことをする場合、現在動作しているアプリケーション環境は突然死んだりします。そのためローカルストレージは突然破棄されたりします。
どうしてもローカルストレージを使わないといけないということもなくはないですが、ファイルは基本的にS3などのオブジェクトストレージに保存するようにし、ログは前述の通り標準出力からDockerのロギングドライバ等を経由し外部ストレージに保存するというようにし、ローカルストレージに依存しない環境にしましょう。NFSなどで永続ストレージをマウントする方法もありますが、取り扱いが難しいので最終手段にしておくべきです。
Webアプリケーションのユーザーからのリクエストで時間のかかる処理を書いてしまうとユーザーを待たせてしまうことになってしまうため、時間のかかる処理はキューに逃がして遅延実行させるということがよくあります。例えば決済処理を遅延処理した際に途中で突然死して再実行した場合に二重決済になるといったことは障害のよくある例です。メールが２回送信されてしまうといったこともよくあります。遅延実行時に限ったことではないですが、重要な処理は再実行が可能になっているかといったことは必ず確認しておきましょう。
