12-Factor Application Methodologyは、短期間でスケーラブルなアプリケーションを構築するためのガイダンスを提供します。Herokuの開発者によって開発されたこのメソッドは、Software as a Service（SaaS）アプリケーション、Webアプリケーション、そして将来的にはCommunication Platform as a Service（CPaaS）にも適用されます。12-Factor Application Methodologyは、オープンソース開発において、プロジェクトの効率的な組織化とスケーラブルなアプリケーションの管理において大きなメリットをもたらします。

12ファクター応用方法論の原則

12-Factor アプリケーション方法論は非常に厳格なルールを持ち、SaaS アプリケーションの開発と展開の基礎であり、プログラミング言語やデータベースによって制限されません。

1: 1つの基本コードベース、複数のデプロイメント

説明図：この図では、左側の緑色の線で表されたコードベースが、右側の緑色の四角で表された4つのデプロイメントにつながっています。オレンジ色の四角はステージング環境、赤色の四角は本番環境を表しています。

説明図：この図では、左側の緑色の線で表されたコードベースが、右側の緑色の四角で表された4つのデプロイメントにつながっています。オレンジ色の四角はステージング環境、赤色の四角は本番環境を表しています。

各アプリケーションには、複数の異なる環境/デプロイメントを備えたコードベースが必要です。

開発者は、単に異なる環境を設定するためだけに別々のコードベースを作成するべきではありません。異なる環境は異なる状態を表しますが、これらの異なる環境は同じコードベースを共有する必要があります。

多くのオープンソースプロジェクトがGitLabのようなバージョン管理システムに保存されている場合、環境をブランチとして捉えることができます。例えば、クラウドVoIPアプリケーション「VoIP-app」用のリポジトリを任意の中央バージョン管理システムに作成し、 developmentブランチとstagingブランチの2つのブランチを作成し、 masterブランチをリリースブランチとして使用することができます。

2: 依存関係を明確に宣言し分離する

すべての依存関係を宣言する必要があります。アプリケーションは外部のシステムツールやライブラリに依存する可能性がありますが、それらのツールやライブラリに暗黙的な依存関係があってはなりません。

コードベースに依存関係を含めると、特にオープンソースプロジェクトでは、外部ライブラリの変更によってバグが発生する可能性があるため、問題が発生する可能性があります。例えば、コードベースで外部ライブラリを使用しているにもかかわらず、その依存関係やそのバージョンを明示的に宣言していない場合があります。外部ライブラリが新しい、テストされていないバージョンに更新された場合、コードとの互換性の問題が発生する可能性があります。依存関係とその正しいバージョンを明示的に宣言することで、コードベースでこれらの問題を回避できます。

テクノロジー スタックに応じて、依存関係の名前とバージョンを表す依存関係宣言のリストを読み取って、パッケージ マネージャーを使用してシステムに依存関係をダウンロードするのが最適です。

3: 環境に構成を保存する

複数の環境やクライアントをサポートする場合、設定はアプリケーションの重要な要素となります。異なるデプロイメント間の設定は環境変数に保存する必要があります。これにより、コードを変更することなく、デプロイメント間で簡単に設定を変更できます。

この原則は、データベース接続の詳細やその他の機密データといった機密情報を公開したくないクローズドソースアプリケーションには有益です。しかし、オープンソース開発ではこれらの情報は公開されています。この場合の利点は、コードを繰り返し変更する必要がないことです。変数を設定し、環境を変更するだけで、コードを完璧に動作させることができます。

4: バックエンドサービスを補助リソースとして扱う

すべてのバックアップサービス（データベース、外部ストレージ、メッセージキューなど）は、実行環境に接続または切断される補助リソースとして扱われます。この原則に基づき、これらのサービスの場所や接続の詳細が変更されても、コードを変更する必要はありません。これらの詳細は設定ファイルで確認できます。

バックアップサービスは、デプロイメントに迅速に接続または切断できます。例えば、クラウドベースのスプレッドシートデータベースが正常に機能しなくなった場合、開発者はコードベースに変更を加えることなく、最新のバックアップから復元する新しいデータベースサーバーを作成できる必要があります。

5: ビルドと実行を厳密に分離する

12-Factor アプリケーション方法論では、ビルド、リリース、およびランタイムの各フェーズを厳密に区別する必要があります。

• 最初の段階は建設です。
• 第二段階はリリースです。
• 第三段階は操作です。

これらの段階を厳密に区別することで、コードの破損を回避し、システムのメンテナンスを管理しやすくなります。

6: アプリケーションを 1 つ以上のステートレス プロセスとして実行します。

アプリケーションは、実行環境内で1つ以上のプロセスの集合として実行されます。これらのプロセスはステートレスであり、永続データはデータベースなどのバックグラウンドサービスに保存されます。

これはオープンソースにとって非常に便利です。特定のバージョンのアプリケーションを使用する開発者は、スケーラビリティを確保するためにクラウドプラットフォーム上にマルチノードデプロイメントを構築できるからです。これらのノードのいずれかがクラッシュするとデータが失われるため、データはこれらのノード内に保持されません。

7: ポートバインディングを介してサービスを提供する

アプリケーションは、他のアプリケーションから独立したスタンドアロンサービスとして存在する必要があります。サービスとして存在し、URL経由で他のサービスからアクセスできるようにする必要があります。これにより、必要に応じてアプリケーションを他のアプリケーションのリソースとして利用できるようになります。この概念を用いて、REST APIを構築できます。

8: プロセスモデルを通じて拡張する

この原則は同時実行原則とも呼ばれ、アプリケーション内の各プロセスがそれ自体を拡張、再起動、または複製できる必要があることを規定しています。

開発者は、単一のプロセスをスケールアップする代わりに、複数のプロセスを作成し、アプリケーションのワークロードをそれらのプロセスに分散させることができます。このアプローチにより、各タイプのワークロードを異なるプロセスタイプに割り当てることができるため、多様なワークロードを処理できるアプリケーションを構築できます。

9: 素早いスタートとスムーズな停止で堅牢性向上

アプリケーションはシンプルなプロセスに基づいて構築する必要があります。そうすることで、開発者はプロセスをスケールさせつつ、問題発生時にもプロセスを再起動できるようになります。これにより、アプリケーションプロセスを容易に破棄できるようになります。

この原則に基づいてアプリケーションを構築することは、迅速なコードデプロイ、迅速かつ柔軟なスケーリング、より柔軟なリリースプロセス、そして堅牢な本番環境へのデプロイを意味します。これらはすべて、オープンソース開発環境において非常に有用です。

10: 開発環境、プレリリース環境、本番環境をできるだけ同じ状態に保ちます。

同じプロジェクトに取り組むチームは、同じオペレーティングシステム、サポートサービス、依存関係を使用する必要があります。これにより、エラーの発生確率が低減し、開発期間が短縮されます。

オープンソースプロジェクトの開発者は地理的に分散しているため、使用するシステム、サービス、依存関係についてコミュニケーションをとることができない場合があり、この原則はオープンソースプロジェクトにとって課題となります。こうした差異を軽減する方法の一つとして、使用するオペレーティングシステム、サービス、依存関係を推奨する開発ガイドラインを策定することが挙げられます。

11: ログをイベントストリームとして扱う

ログは、運用上の問題のトラブルシューティングやユーザー行動の理解に不可欠です。しかし、12-Factor アプリケーション手法はログ管理には適していません。

代わりに、ログエントリはイベントストリームとして標準出力に書き込まれ、分析とアーカイブのために別のサービスに送信する必要があります。ロボティック・プロセス・オートメーション（RPA）テクノロジーは、ログの処理と分析のためのサードパーティサービスとして機能します。実行環境がこのデータストリームの処理方法を決定します。これにより、アプリケーションの動作を反映する柔軟性と能力が向上します。

12: バックグラウンド管理タスクを 1 回限りのプロセスとして実行します。

この原則は実際には開発とは関係なく、むしろアプリケーション管理に関係しています。管理プロセスは、アプリケーションの通常の長期実行プロセスと同じ環境で実行される必要があります。ローカルデプロイメントでは、開発者はアプリケーションのチェックアウトディレクトリ内でシェルコマンドを直接使用して、一回限りの管理プロセスを実行できます。

結論は

アプリケーション開発に12-Factorアプリケーション手法を用いることで、効率性が向上し、リリースを迅速化できます。オープンソース開発においては、特定のガイドラインから逸脱することが有益な場合もありますが、可能な限り厳密に遵守することが最善です。

オープンソースの12-Factorアプリケーションは実現可能です。好例として、パンデミック中に100倍にスケールアップし、大きな成功を収めたJitsi（オープンソースのビデオ会議プラットフォーム）が挙げられます。Jitsiは12-Factorアプリケーション手法を用いて構築されました。