はじめに

https://qiita.com/ggg-mzkr/items/4576fe2815c36a4c30e9 の続きです。

VII. ポートバインディング

• 外部のWEBサーバーを使用せず、WEBサーバー自体もアプリケーションに含める
• サービスの公開はポート単位で行えるようにする

PHPのアプリケーションはWEBサーバーとしてApacheやnginxを用いることが多いと思います。しかしそのようなアプリケーション外部のWEBサーバーを利用せず、アプリケーション単体でサービスが完結するようにするべきです。具体的な方法としては、PythonではTornado、RubyではThin、JavaやではJettyなどのWEBサーバーライブラリを依存関係に含めるなどをします。
このようにすることで、ポート単位でサービスが公開できるようになり、アプリケーションが他のアプリケーションのバックエンドサービスになることもできるようになります。

VIII. 並行性

• アプリケーションはステートレスなプロセスをにするべきである

負荷に対応する際、スケールアップをしようとすると、大きなコストがかかります。プロセスをステートレスな物にしておくことで、スケールアウトが容易になり、並列性を高めることができます。アプリケーションのプロセスの管理は、OSのプロセスマネージャーを用いて管理するべきです。

IX. 廃棄容易性

• 起動・終了が即座に行えるべきである
• プロセスがクラッシュした場合にも対処できるように設計すべきである

アプリケーションの起動や終了が即座に行えると言うことは、アプリケーションのデプロイや、スケールアウト、スケールインのアジリティが高くなることに直結します。また、アプリケーションが終了の命令を受け取った時、何もせずすぐに終了するのでは無く、処理中のリクエストを返したり、ジョブをキューに戻すなど、終了しても問題ない状態になってから終了するべきです。

X. 開発/本番一致

• 開発環境と本番環境のギャップをできる限り小さくする

伝統的なアプリケーションでは、開発環境と本番環境の間には、異なるツールが用いられる、編集されたコードがデプロイされるまでには長い時間がかかる、コードを書いていない人がデプロイを行う、と言うようなギャップがありました。Twelve Factor APPでは、使用するツールはできるだけ本番環境と一致させ、コードを書いた人が数分から数時間のうちにデプロイを行い、本番環境での動作をモニタリングします。
開発で使用されるツールの違いは、フレームワークなどが吸収してくれたりもしますが、わずかな非互換性の違いで本番環境では動かない、と言うこともあります。このようなことを考えると、多少手間でも本番環境と同じツールを用いた方が結果的には楽だったりします。

XI. ログ

• ログはストリームとして標準出力に書き出す

ログは一般的にログファイルへ書き出されることを想像しますが、これは出力フォーマットの一つにすぎません。ログはアプリケーションのイベントを示しています。アプリケーション自体はこのイベントをストリームとして単に標準出力へ書き出すに留めます。このようにすることで、環境によってファイルへリダイレクトすることもできますし、ログ解析システムへ送ることもできるようになります。

XII. 管理プロセス

• 管理タスクのためのコードはコードベースへ含める
• 管理タスクの実行はアプリケーションの依存に含まれていないツールを用いない

管理タスクとは、データベースのマイグレーションや、一回限り実行するスクリプトなどのことです。当たり前のことですが、これらを行うためのコードはコードベースへ含めるべきです。また、管理タスクをする時は、アプリケーションの依存に含まれていないけどこのライブラリ使っちゃおう！みたいなことをしてはいけません。もし使うのならば、そのライブラリも依存関係宣言マニフェストへ追加するべきです。