この文書はなにか

Beyond the Twelve-Factor App ^[1] は良文書だと思うのですが、それぞれの項目の目的や理由が明確ではないように思えました。言うまでもないことなのかもしれませんが、はっきりしていないと不安かなとも思います。

Beyond the Twelve-Factor App には以下の15の項目があります。優先順位順です。

One codebase, one application
API first
Dependency management
Design, build, release, and run
Configuration, credentials, and code
Logs
Disposability
Backing services
Environment parity
Administrative processes
Port binding
Stateless processes
Concurrency
Telemetry
Authentication and authorization

本文書ではそれぞれの目的とやることをすくいあげてまとめてみました。一部私の勝手作文になっているところもあります。私の理解不足や勘違いで元文書の意図を誤解しているところがあるかもしれません。間違いの指摘を歓迎します。^[2]

元文書の背景

Beyond the Twelve-Factor App の前段として、The Twelve-Factor App ^[3] という文書があります。これは、Software as a Serviceを作り上げるための方法論について書かれたものです。herokuの人が書いています。

Beyond the Twelve-Factor App はもとのTwelve-Factor App について内容の追加と詳細化を行なったものです。pivotalの人が書いています。

1. One codebase, one application

何のために

ビルド、デプロイを自動化したい。アプリが複数リポジトリに分かれていたら自動化が難しくなる。
複数アプリや複数チームで1個のリポジトリを共有していたら、コンウェイの法則^[4]に従うほうが自然である。

何をする

アプリとリポジトリは1対1にする。1個のコードベースというのは、共通のルートを持つ複数リポジトリでも良い。

2. API First

何のために

ユーザストーリーや機能について利害関係者との議論を持てるようなリソースが欲しい。
ほかシステムとの結合作業する際の失敗を避けたい。

何をする

APIを開発プロセスの第一級の成果物とする。 ^[5]

3. Dependency Management

何のために

アプリケーションが稼働環境の設定に依存しないようにしたい。繰り返し可能なデプロイをしやすくしたい。

何をする

依存するライブラリやツールをアプリごとに定義する。
稼働環境に何があるか、どんなライブラリやツールがあるかについては何も前提を置かない。

4. Design, Build, Release, Run

何のために

開発者の安心を保ちながらリリーススピードを上げたい。

何をする

開発から運用のフローを、設計、ビルド、リリース、実行の4つに分ける。それぞれ独立に実行させる。詳細は以下の通り。

設計

次にリリースされる機能について設計する。
全体的な設計はあるが変化するものであるので、イテレーション毎に少しずつ行う。
また、この段階で依存するライブラリについても決定する。

ビルド

コードがバイナリアーティファクト（＝ビルド）に変換される。CIツールが使われるべきである。
1個のビルドが複数の環境にリリースされるかたちになる。（テスト、QA、本番など）
「私の環境でしか動かない」問題が起きていたら、本項の4ステップが正しく分離されていないことを意味する。

リリース

ビルドに環境ごとの設定やアプリ固有の設定を施して、リリースとなる。
リリースにはそれぞれユニークなIDが付けられて、かつ不変であるべきである。
トラブルシューティングやロールバックにも活用できる。

実行

環境にリリースされたものをクラウドプロバイダーが実行させる。
クラウド実行環境はアプリを実行させ、ヘルスチェックし、ログを取ることに責任を持つ。また、動的スケールや耐故障性のための管理タスクも同様である。

5. Configuration, Credentials, and Code

何のために

環境毎に異なる設定とコードを同じ管理下に置くと、環境毎設定を管理するのが大変になる。認証情報とコードを同じ管理下に置くと、多数の開発者が見ることができて好ましくない。

何をする

設定・認証情報・コードを分けて管理する。認証情報と設定は環境変数とし、リリースの際にビルド生成物に登録する。

6. Logs

何のために

アプリがログ情報の管理をしないようにして、アプリを簡素化させたい。アプリ実行環境が動的にたくさんに増えると、環境毎にログファイルが作られる。そういうログ情報を楽に管理／分析したい。

何をする

ログを時間毎に流れてくる情報として扱う。アプリとしてはどこに置くかは関知しないようにし、ログをstdout と stderrに出すだけにする。その出力を収集・分析するような、別のツールやシステムを利用する。

何をする

すべての環境が同じになるようにする。

周辺の議論

以下の場合、相違が起きやすい。総じてヒューマンエラーである。

コード修正からリリースまでが長い。どんな修正をしたかや環境の変更をしたかを忘れてしまう。
手動でリリースしている。そもそも手作業は間違えるものであるので相違になる。
本番と同じバッキングサービスを準備するのが面倒で大変である。すると似ているが違うもので代用するようになりこれが相違になる。

10 Administrative Processes

背景

管理プロセスとは

DB移行 ^[6]
REPLでの処理
定時バッチ
1回だけ実行する特別な処理。

というものである。もともとの12factor ではアプリの1部機能としてこれらの処理をせよと言っているが、これはやめて別のやり方がないか検討するべきである。アプリが水平スケールしたときに1つのインスタンスだけでこれらの機能が動作することになってしまう。

パフォーマンスには、以下のものが考えられる。

Application performance monitoring (APM)
- 例：秒ごとのHTTP処理数
Domain-specific telemetry
- 例：直近20分である商品がiPad経由でいくつ売れたか
Health and system logs
- 例：システムのヘルスチェック情報。起動・停止・スケールなどのイベント情報。

補足

具体的にこうしろというものはないが、意識して取り方や内容について検討必要といっている様に見える。

15 Authentication and Authorization

何をする

セキュリティの設計／実装を開発の初日から実施する。

補足

クラウド環境であろうがなかろうがセキュリティはとても重要。後回しにしてはだめ。

参考リンク

Beyond the Twelve-Factor App

The Twelve-Factor App
https://12factor.net/ja/

脚注

https://tanzu.vmware.com/content/ebooks/beyond-the-12-factor-app ↩︎
間違い探し遊びにどうでしょうか。 ↩︎
https://12factor.net/ ↩︎
「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」 https://ja.wikipedia.org/wiki/メルヴィン・コンウェイ ↩︎
この項目は、契約を最優先にする開発スタイルの拡張とのことである。おおまかに言えば、サービスが外向けに提供する仕様を決めるということです。 ↩︎
データの移行とか古いデータの消込など？ ↩︎
Servletで言うところの、セッションスコープやアプリケーションスコープの変数を持たないということ。 ↩︎

Discussion