Beyond The Twelve-Factor Appを自分なりに理解してみる

3年前にこの文書の前身となる、「The Twelve-Factor App」を教えてもらいました。
アジャイル開発という言葉も、名前だけ聞いたことがある程度で、DXな人材とは離れたエンジニアをしていました。
今では、同じようなステータスの方のスキルチェンジをお手伝いする立場で、内容をお伝えしないといけない立場になりました。

しかし、概念は理解しているが、簡単に説明できるまでは体に染み込んでいないので、整理したいと思います。
複雑ではなくシンプルに。

Beyond the Twelve-Factor Appとは

もともとの文書は、Herokuの中の人が提唱した「The Twelve-Factor App」です。2012年ころに提唱されたものです。
そのため、2016年ころにPivotalの中の人が更新したものが、Beyond The Twelve-Factor Appです。
これは、この期間でクラウドにおける、クラウドネイティブな開発のノウハウが貯まり、ベストプラクティスとして、更新されたものと考えられます。
項目として増えた箇所もあれば、より具象化された文言になっている印象です。

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

1. One codebase, one application

内容

コードベースとはリポジトリである。
アプリケーションとリポジトリは1対1にする。
共通的なコードは、別のコードベースとし、アプリケーションからライブラリとして呼ばれるようにする。
CI/CDなどの自動化を実施しやすくなる。複数リポジトリに分かれていると自動化が難しくなる。
Conwayの法則に則ることによるコードベースの分割も検討できる。

参考

現状なし

2. API first

内容

APIを最初に設計する。
APIを最初に設計することで、他チームとの調整がしやすくなる。
APIのモックが作れる。
CI/CDパイプラインとの相性がよい。

参考

SwaggerなどのAPI First開発をサポートするツールの活用

3. Dependency management

内容

アプリケーション毎に依存するライブラリを明示的にマニフェストファイルなどに定義する。
稼働環境などの前提など、記載されていないライブラリや環境を利用しない（分離している）。

参考

依存関係の記述としては、MavenやGradle、NuGetなどのツールで確認する。

4. Design, build, release, and run

内容

開発のアジリティを高めるため、設計・ビルド・リリース・実行までのプロセスを明確にし、それらを一つのサイクルにする。
テストとデプロイの自動化も行う。

参考

現状なし

5. Configuration, credentials, and code

内容

環境ごとに異なる設定は環境変数に格納する。
デプロイ時に異なる値とコード、コードベースから分離する。
ID、パスワード、鍵情報のほか、資格情報も外部管理を行うようにする。

参考

Spring Cloud Configuration Serverなど、設計されたサーバを使用する。

6. Logs

内容

ログの管理と、アプリケーションから分離する。関心事を分離させる。
ログはイベントストリームとして扱う。ログの収集、分析は別で管理する。
環境ごとにログを作られてしまうと、管理が複雑になってしまう。
コンテナなど、スケールアウトなど揮発性が高いため、ストレージに保存する運用にしない。

参考

ログの集約、保存、解析はアプリで行わず、他のツール、サービスを利用する
ELK（ElasticSearch、Logstash、Kibana）やSplunk、Sumologic、Fluentdなど

7. Disposability

内容

迅速に起動する。
迅速に停止する。

参考

スケールアウト時に有効である。
クラウドインスタンス上のアプリケーションのライフサイクルは短い。

8. Backing services

内容

コードに手を入れることなく、内部リソースや、外部サービス、RDBなどのミドルウェアを切り替えることができる。
バッキングサービスとの接続情報は、外部設定によって行う。
サーキットブレーカー
バックエンドサービスが落ちているときに、該当のサービスを遮断し、フォールバックまたはフォールセーフパスを提供する。
バックエンドサービスと疎結合とする。

参考

現状なし

9. Environment parity

内容

環境について、一致させた状態とさせること
時間のギャップを一致させる
開発者がコードを修正してから、デプロイされるまでの時間が空くことがよくある。そのため、コード修正内容を忘れてしまうことがある。
CI/CDなどの自動化により、デプロイを迅速に行う。
人のギャップを一致させる
役割として、アプリはアプリ開発者、デプロイはインフラ担当者が実施するなどの分担があるプロジェクトもある。
そもそも、デプロイ時に人を関与させない。
CI/CDなどの自動化により、人を関与させない対応方法もある。

参考

現状なし

10. Administrative processes

内容

管理プロセスは、「DB移行」、「定時バッチ」、「1回限りの管理やメンテナンスのプロセス」である。
管理プロセスがアプリに組み込まれていると、水平スケールした際に無数の機能が動作してしまうので、分離すべき。
定時バッチはcronなどの実行環境のリソースを使うのではなく、AWS Lambdaなどのクラウドベンダが用意しているマネジメントサービスを使う。

参考

現状なし

11. Port binding

内容

ポートバインディングにより、ポートとサービスとを紐づける
水平スケーリングした際に、ネットワークの設定をすべて人で行うのは難しい
アプリケーション開発者側が意識しないようにする
一つのコンテナ内で複数アプリケーションをデプロイするような構成としない

参考

現状なし

12. Stateless processes

内容

アプリケーションは単一のステートレスなプロセスとして実行するべきである。
破棄容易性を維持する
オートスケールを実現する

参考

Statefullは状態を保持し、データを持っていること

13. Concurrency

内容

水平スケーリングを行う
Disposabilityを満たすこと
Stateless processesを満たすこと

参考

現状なし

14. Telemetry

内容

クラウドネイティブなアプリケーションの監視を検討する
水平スケールにより、インスタンスが増えるとその分ログ量も増加することも念頭に置くこと
パフォーマンス、ヘルスチェック、分散処理のトレースなど
監視データの遠隔的な監視の仕組み作り

参考

15. Authentication and authorization

内容

セキュリティの設計は後付けでなく、開発当初から考慮すべきことである。

参考

OAuth2、OpenID Connect、SSOなどが挙げられている。
AWSだと、Cognitoを使ったりする。
Firebaseだと、Authentication機能もある。
すぐ使うならSaasであるAuth0などもある。
APIゲートウェイに認証認可を持たせると、不必要な処理をサーバサイドにさせなくてもよさそう

おわりに

調べた結果のメモになっているため、これらの項目の背景など整理できれば理解は深まると思われます。
リライト時に詰めてみます。

12factor DX