The Twelve-Factor Appを自分の中で整理してみました
はじめに
ついにRuby on Railsのプラクティスに進むことができ、手を動かしながら学習を進めて行っているのですが、参考資料にThe Twelve-Factor Appという資料がありました。
一度読んだだけでは、中々理解することができなかったので、自分の理解を促すために整理してみました。
The Twelve-Factor Appとは
Herokuのエンジニアが2011に提唱したアプリ開発の方法論です。
この方法論を守ることで以下のメリットがあります。
- プロジェクトに新しく入った人がすぐについていけるようにできる。
- 実行環境間での移植性が最大化される。
- クラウドプラットフォーム上でのデプロイに適しており、サーバ管理やシステム管理をなくすことができる。
- 開発環境と本番環境の差を小さくすることで、デプロイにかかるコストを下げることができ、継続的なデプロイがしやすくなる、
- スケールアップ(サーバを増やしてシステムの処理能力を上げること)がしやすくなる。
1. コードベースはアプリケーションと1対1の関係にする
Gitなどのリポジトリはアプリケーション1つにつき、1つという1対1の関係にすること。
2. 依存関係を明示的に宣言し分離する
bundlerなどのパッケージ管理システムを使うことで依存関係を宣言しなければなりません。
そして、依存関係設定ファイルに記述されるもの以外のアプリ外のライブラリやシステムツールに依存してはいけません。
3. 設定は環境変数に格納すること
環境変数はデプロイごとに簡単に変更できるものです。これに設定を格納することにより、デプロイごとに設定を管理することができます。
4. バックエンドサービスをリソースとして扱う
ここで、バックエンドサービスとはアプリケーションが動作中にネットを通じて利用する全てのサービスを指します(DB、メールサービスなど)。
これらを、一つのリソースだと捉えて、簡単にアタッチしたりデタッチしたりできることが理想です。そのためには、アタッチされたリソースとアタッチされる対象となるデプロイが疎結合である必要があります。
5. ビルド、リリース、実行の3つのステージを厳密に分けること
ここでは
ビルドステージとは、依存関係を取得して、アプリケーションが実行可能な状態になるステージ。
リリースステージとは、ビルドステージからのビルドを受け取り、それを現在のデプロイの設定と合わせるステージ。
実行ステージは、実際の実行環境で実行するステージ。
とされます。
6. アプリケーションをステートレスなプロセスとして実行すること
ステートフルなデータはDBに格納すること。
7. ポートバインディングを通してサービスを公開すること
これがあまり理解できていないのですが、サーバー無しでも実行できるようにアプリケーション内に組み込みサーバーを持つという方法のようです。
8. プロセスモデルによってスケールアウトすること
負荷に対しては、メモリやCPUの増強(垂直スケール)ではなく、インスタンスの増加(水平スケール)で対応すること。
9. 高速な起動とグレースフルシャットダウンで堅牢性を最大化する
起動と停止にかかる時間は最小限にすること。
10. できるだけ本番環境に近い環境で開発、ステージングを行うこと
時間、人材、ツールのギャップを少なくして、継続的なデプロイをしやすくすること。
11. ログはログファイルで管理しないこと
ログファイルで管理すると、消える可能性があるため、標準出力に返すようにすること。
12. SSHログインなどの管理作業は、1回で済むようにすること
ミスの元となるため、管理プロセスはアプリケーションの初期化処理として実行すること。
補足
そもそもデプロイとは
実行する環境に合わせて、アプリケーションが実行可能になることを指します。
そもそもHerokuとは？
アプリの構築、提供、監視、スケールに役立つクラウドプラットフォームです。
最後に
まだ、実際にアプリケーションの開発に携わっているわけではないので、全然ピンときていません💦
今後、実際の開発に参加することで、この方法論に戻ってきて、色々と実感できれば良いなーと思います。
参考
とにかく分かりづらいTwelve-Factor Appの解説を試みる
The Twelve-Factor Appで考えるAWSのサービス開発
