Twelve-Factor App

Twelve-Factor App#

The Twelve-Factor App は Webアプリ開発のベスト・プラクティスとされる方法論

Adam Wiggins がHerokuの開発で得た知見を2012年ごろにまとめたもの。

The Twelve Factors

  1. コードベース(codebase)

    • バージョン管理されている1つのコードベースと複数のデプロイ

    • codebaseはroot commitを共有する単一か複数のリポジトリのこと → コードベースは1つ、デプロイ(prd, stg, dev, …)は複数

  2. 依存関係(dependencies)

    • 依存関係を明示的に宣言し分離する

    • 依存関係の宣言マニフェスト:RubyのGemfileやPythonのPipなど

    • 依存関係の分離:Rubyの bundle exec や Pythonのvenv

  3. 設定(config)

    • ここでの「設定」はデプロイ(開発、本番など)間で異なりうるもののことを指す。例えばDB・S3などの認証情報、ホスト名など。

    • Twelve-Factor Appでは設定は環境変数に格納する。

  4. バックエンドサービス(backing service)

    • バックエンドサービス(データストア、メッセージキューイングなど)をローカルで自らが管理するサービスと区別せず、アタッチされたリソースとして扱う

  5. ビルド、リリース、実行(build, release, run)

    • ビルド、リリース、実行の3つのステージを厳密に分離する

  6. プロセス(processes)

    • アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する

    • 永続化が必要なデータは、ステートフルなバックエンドサービス(典型的にはDB)に格納する

  7. ポートバインディング(port binding)

    • ポートバインディングを通してサービスを公開する

  8. 並行性(concurrency)

    • プロセスモデルによってスケールアウトする

  9. 廃棄容易性(disposability)

    • 高速な起動とグレースフルシャットダウンで堅牢性を最大化する

    • グレースフルシャットダウン:サービスポートのリッスンを中止し(従って新しいリクエストを拒み)、処理中のリクエストが終了するまで待ち、シャットダウンする。ダウンタイムが最小限になる

  10. 開発/本番一致(dev/prod parity)

    • 開発、ステージング、本番環境をできるだけ一致させた状態を保つ

  11. ログ(logs)

    • ログをイベントストリームとして扱う

  12. 管理プロセス(admin processes)

    • 管理タスクを1回限りのプロセスとして実行する

    • 管理タスク:Railsのrails db:migrateなどのメンテナンス用のコマンドなど

    • これはアプリを提供するときのプロセスと同じコードベース上で1回限り実行されるべきである

Beyond the Twelve-Factor App#

Beyond the Twelve-Factor App は 2016年ごろにPivotal社のアーキテクト Kevin Hoffman によって「クラウドネイティブアプリ」向けにアップデートされたもの。

“API first”と”Telemetry”とセキュリティの話(Authentication and Authorization)が追加されているのが主な変更点(因子の順番も優先順位に応じて書かれている)

beyond_the_12-factor_app_pivotal.pdf

Beyond the Twelve-Factor App

  1. One codebase, one application

  2. API first

    • APIで他のアプリと連携することが多い時代になってきたのでAPIファーストの実装にする

    • 開発時は常にAPIとして利用されることを想定する(Webにしろモバイルにしろ)

    • API開発時は業界標準的なAPIの書き方やドキュメント作成ツールやserver mockを活用する

  3. Dependency management

  4. Design, build, release, and run

  5. Configuration, credentials, and code

  6. Logs

  7. Disposability

  8. Backing services

  9. Environment parity

  10. Administrative processes

  11. Port binding

  12. Stateless processes

  13. Concurrency

  14. Telemetry

    • 目的:効率的に監視したい。クラウドネイティブのアプリでは数百台のサーバーインスタンスを使ったりして大量のログが出てきたりするのでもうログを読んだりデバッガーを実行したりでは対応できない

    • 方法:

      1. Application performance monitoring (APM)

        • 外部ツール・ダッシュボードがアプリのパフォーマンスを監視するために使われるイベントストリーム。

        • 例:1秒あたりのHTTPリクエストの平均回数

      2. Domain-specific telemetry

        • データウェアハウスに入れて分析するイベントストリーム

        • 例:直近20分の製品の販売個数

      3. Health and system logs

        • クラウドプロバイダーが提供する、定期的なヘルスチェックの結果やアプリケーションの起動、終了などのイベントストリーム

    • ※Telemetry(テレメトリ, 遠隔測定法)は何かを測定した結果を通信して伝えること。例えばロケットが測定したデータを地球上の基地に伝えること。クラウドのサーバーは直接触れられないのでこの用語を使っている

  15. Authentication and authorization

    • クラウドネイティブアプリではrole-based access control (RBAC) が使われる事が多い

参考#