モダンWebアプリケーション開発で重要な「The Twelve-Factor App」の概要
The Twelve-Factor Appとは、Webアプリケーションの開発において、モダンなWebアプリケーションとはどうあるべきか、の12個の要素についてのベストプラクティスをまとめたものです。
今回は、そのThe Twelve-Factor Appについてまとめてみました。
もし、永続的にステータスを管理する必要がある場合は、DB等に持つようにする。
つまり、サーバ無しでもアプリケーションだけで実行できるようにしておく。
停止前には、リクエストの受付停止、処理中リクエストの待機、DB接続やI/Oクローズなど、各リソースの廃棄（グレースフル）を行うようにする。
今回は、そのThe Twelve-Factor Appについてまとめてみました。
コードベース
- 1つのリポジトリから複数のアプリケーションが作られるということは、密結合である可能性が高く、拡張性が低下してしまう
- 複数のリポジトリから1つのアプリケーションが作られるということは、ビルドやデプロイの手順が複雑化してしまう
依存関係
- システムツール（例：curl）はアプリケーションのデプロイ先となる環境に常にインストールされているとは限らない
- 新たな開発者のセットアップにコストがかかってしまう
設定
- 設定をコードに含めると、環境ごとにビルドが必要になってしまう
- 設定を設定ファイルで行うと、環境ごとい設定ファイルが必要になってしまい、スケールしにくくなってしまう
- バージョン管理システムに設定ファイルがあると、情報漏洩につながってしまう
バックエンドサービス
- 設定をコードに含めると、設定の変更が必要になった時にビルドが必要になってしまう
- 設定をコードに含めると、サービスインスタンスが停止した際、別のインスタンスにすぐ接続できなくなってしまう
ビルド・リリース・実行
- 環境ごとにビルドを行ったり、実行中のソースコードを修正するとオペミスによって障害を引き起こす可能性がある
- テスト済みのソースコードをビルドし、そのままリリース・実行すれば、障害を引き起こす可能性が極めて少なくなる
プロセス
- インスタンスは仮想サーバのスケールイン・スケールアウトで増減するため、永続的に存在するものではない
もし、永続的にステータスを管理する必要がある場合は、DB等に持つようにする。
ポートバインディング
- 環境ごとによるサーバの設定を必要としないようにする
- 自アプリケーションを、別のサービスのバックエンドとして容易に提供できるようにする
つまり、サーバ無しでもアプリケーションだけで実行できるようにしておく。
並行性
- 垂直スケール（メモリやCPUの増強）の場合、マシンの再起動が必要となってしまう
- マシン再起動によってダウンタイムが発生してしまう
廃棄容易性
- プロセスの起動が遅いとスケールが容易でなくなってしまう
停止前には、リクエストの受付停止、処理中リクエストの待機、DB接続やI/Oクローズなど、各リソースの廃棄（グレースフル）を行うようにする。
開発/本番一致
- 時間のギャップは、開発からデプロイを数時間で行えることが望ましい
- 人材のギャップは、開発者が運用も行えることが望ましい
- ツールのギャップは、ローカル、開発環境、本番環境でそれぞれツールが異ならないようにしなくてはいけない
ログ
- スケールイン時に、仮想サーバそのものがなくなる可能性がある
管理プロセス
- 手動で管理を実行するとオペミスを引き起こす可能性がある
