Open15
Twelve-Factor Appを図で書いて理解する
参考
本家
AWS/ECS(Fargate)でTwelve-Factor Appを解説
GoogleCloud
Twelve-Factor Appとは?
Webアプリケーションの設計や構築に関するベストプラクティスを示す方法論を定義したもの
12個ある
1. コードベース
- コードベースとアプリケーション関係は1対1とする
- 別のアプリケーションと共有するソースコードは外部ライブラリとして切り出す
2. 依存関係
- 明示的にパッケージの依存関係を宣言し管理する
- システム全体にインストールされるパッケージが暗黙的に存在することに決して依存しない
- すべてのライブラリ/パッケージの正体・バージョンを把握しておくこと、と理解しました!
例 :サーバにデフォルトでインストールされているパッケージをアプリケーションで使用しない。使用するものはパッケージマネージャ、手順書で管理する
例2 :パッケージの把握のために、Dockerfileで環境を構成する
3. 設定
- 良い①💡:設定を環境変数へ入れる
- 良い②💡:パラメータストアなどの情報格納用ストレージへ入れる
- 悪い💀:コード内にベタがき
①
②
4. バックエンドサービス
- ファイル システム、データベース、キャッシュ システム、メッセージ キューなどは外部サービスとして扱う
- 構成変更の際にアプリケーションコードの変更を変更する必要がないようにする
- ネットワーク越しに利用するサービスをアプリから切り離すイメージ
- 構成変更の際は環境変数などから行う
5. ビルド、リリース、実行
- ソフトウェアのデプロイプロセスは、ビルド、リリース、実行の 3 つの段階に分けることが重要
-
ビルド:テストをパスしたコードをビルドして実行可能(なアーティファクト)にする
- アプリケーションの実行環境で直接ソースコードを変更しない
-
リリース:ビルドステージで生成されたアーティファクトを受け取り、現在のデプロイ設定と合わせてリリースを作成する
- リリースは一意の識別出来るIDを持つ
- リリースをコミットIDなどで追跡できることが大切
- 実行:リリースからアプリケーションをデプロイする
6. プロセス
- プロセスはステートレスかつシェアードナッシングであること
- プロセスの生成・削除によって環境が移り変わるため、プロセス内の状態に依存させない
- このようにすることでプロセスの拡大、移植が容易となる
- 永続化する必要のあるすべてのデータは、ステートフルなバックエンドサービスへ保存する
- データベース、インメモリキャッシュ等
コンテナごとに 1 つのアプリケーションプロセスを実行するのがよいですね
7. ポートバインディング
- アプリケーションへは公開したポート番号からアクセスする
- 実行環境にwebサーバ等を入れ、公開する必要がないようにする
- アプリケーションが他のアプリケーションにとってのバックエンドサービスになれる
- 避けるべきことはアプリケーションのスケーラビリティを制限するもの
- ポート番号のハードコーディング、特定のインフラへの依存等
8. 並行性
- アプリケーションが平行に(同時に)実行可能であること
- スケールアウトを容易に、単純に実行できるようにする
- プロセス間で状態を共有しない(ステートレス)
- ワークロードの種類をプロセスタイプに割り当てる
- フロントエンド、バックエンド、時間がかかる処理等
9. 廃棄容易性
- プロセスを即座に起動・終了させることができる
- 素早いスケール、デプロイのため
- グレースフルシャットダウンによって未完了のタスクを完了してから終了することが推奨される
- 処理が死んでも問題ないか?
- 新しい処理が失敗しないか?
これはまあ図がなくてもいいよね...(思いつかない)
10. 開発/本番一致
- 継続的デプロイしやすいよう開発環境と本番環境のギャップを小さく保つ
- ギャップは以下の3つに分類される
- 時間
- 人材
- ツール
11. ログ
- Twelve-Factor Appはアプリケーションの出力ストリームの送り先やストレージについて一切関知しない
- stdoutに書き出したログをツール(Fluentd等)で飛ばす
- 分析やアラートのために集約する
12. 管理プロセス
- データベースのマイグレーションなどの一度限りのプロセスは、アプリと同じプロセスで実行するべき
- 環境間の差異による問題を避けるため
感想
Twelve-Factor App、設計の際の指針にしていきたいですね。
Twelve-Factor Appはコンテナに適用しやすいと感じた