12factorapp

12 factor app

1. コードベース
   • コードベースとアプリケーションは常に1対1、デプロイは環境(開発、ステージング、本番等)毎に複数存在
   • 共通のコードはライブラリ化する
2. 依存関係
   • 依存関係の明示と分離 ex. package.json, gem
   • システム固有の暗黙的なツール(curlなど)を前提にせず、必要な場合はvendor appとして内包する
3. 設定
   • デプロイ毎に異なる設定をコード内に格納するのでなく、環境変数に格納する
   • ソースをgithub等、ossとして公開状態で管理するのであればcredentialは絶対コード内に格納してはいけない
   • credential, db接続情報、変動があるものは環境変数で読み込む形でコード化する
4. バックエンドサービス
   • DB, Storage, SMTP等デタッチアタッチ可能なリソースとして扱う
   • すべてURLで扱う
5. ビルド、リリース、ラン
   • それぞれのステージを厳密に分離 ビルド->リリース->ラン
   • ビルド: コードを実行可能な形にする、依存関係の整理、コンパイルなど
   • リリース: ビルドとデプロイに関する設定の整理、サーバーで実行できる状態かつロールバック機能を担保する ex.fabric, capistrano
   • ラン: サーバー上でアプリを起動する、実行中のコードを変更することはしてはいけない
6. プロセス
   • ステートレス、シェアードナッシングなプロセスとしてアプリを実行する
   • 状態はDBなどのサービスに持たせる
   • memchacheやredisでのキャッシュ管理
7. ポートバインディング
   • Webアプリをポートにバインドすることでhttpサービスとして公開する
   • 1 container 1 service
8. 並行性
   • プロセスモデル採用によるスケールアウトの実現
   • スレッドではなく、プロセスを用いてスケールアウトする
   • 各プロセスが内部でスレッドやasync/eventedを用いて多重化するのはok
9. 廃棄容易性
   • 高速な起動とグレースフルシャットダウンの両立により堅牢性を高める
   • 起動時間を最小化することによりリリースやスケールアウト時のアジリティを高める
   • プロセス終了時の後処理をきちんとする、新しいリクエストを受けるのをやめ、現在進行している処理は正常に完了させる
   • 冪等性を担保した設計
   • リクエストの接続が失われても裏で再接続できるような設計
10. 開発本番一致
    • 開発/本番環境のギャップを小さく保つ
    • 時間のギャップ: リリース対象のコードは数時間・数分後にはデプロイ可能な状態とする
    • 人材のギャップ: リリース対象コードを書いた開発者がデプロイ、リリース後の挙動を見守る
    • ツールのギャップ: 開発/本番環境をできるだけ一致させる(利用スタックの統一)
11. ログ
    • ログをイベントストリームとして扱う
    • アプリはstdoutにログを吐くだけ
    • 実行中のアプリの挙動を可視化、アーカイブ化できるようなログルーターの利用(ex. fluent)
12. 管理プロセス
    • 管理タスクを1回限りのプロセスとして実行する
    • c.f. “heroku run”, “rails c”, “rails r”, “rake db:migrate”