ポイント: 12ファクターアプリの方法論は、スケーラブルなクラウドアプリケーションを構築するためのガイドラインを提供し、展開と保守の容易さを強調します。主な原則には、依存関係の分離、設定管理、およびプロセスの廃棄可能性が含まれ、アプリケーションの堅牢性と適応性を向上させます。
- 依存関係が分離された自己完結型アプリケーションに焦点を当てる。
- プロセスの迅速な起動と優雅なシャットダウンを奨励する。
アプリケーションコードの作成は、ほとんどのクラウドソリューションよりも前に始まりました。これらのソリューションは、現在ほとんどのアプリケーションプログラマーが特に書いているものです。
この不調和を処理するために、12ファクターアプリの方法論が登場しました。12ファクターは、プログラマーが宣言的な方法で現代のアプリを書くのを助けるアプローチであり、クラウドを介して展開される明確な契約を使用します。
この記事では、12ファクターアプリの方法論を紹介し、その原則の概要を提供します。
12ファクターアプリの方法論とは？
2012年、Herokuのプログラマーが12ファクターアプリの方法論を発表しました。これらのプログラマーは、何百ものアプリを開発および展開し、この方法論を書きました。彼らの経験に基づいて、SaaSアプリを「野生で」見たことから、彼らはこの方法論を発展させました。
このグループは、この方法論を次の3つの三角測量と見なしています：
- アプリ開発をサポートするための理想的な実践
- アプリが有機的に成長する際に発生するダイナミクス
- コードベースの開発者間の関係とコラボレーション
[helix-video]
彼らの目標は2つあります：
- ソフトウェアの劣化コストを回避する手助けをすること
- 現代のアプリ開発で観察されたシステム上の問題についての認識を高めること
このグループは、エンタープライズアプリケーションアーキテクチャのパターンとリファクタリング、どちらもプロの開発者マーチン・ファウラーによるものを指摘しています。
さて、12のファクターを紹介します。
原則 I. コードベース
「リビジョン管理で追跡される1つのコードベース、多くのデプロイ」
コードベースには、理解しやすい論理的なバージョン管理システムが必要です。
すべてのデプロイメントには、それぞれのコードリポジトリが必要であり、複数の環境にデプロイできる必要があります。同じリポジトリ内に複数のアプリケーションを格納するのは避けてください。これにより、バージョン管理がほぼ理解不可能になり、バージョンが混乱して、付加価値のない作業が発生します。
原則 II. 依存関係
「依存関係を明示的に宣言し、分離する」
この原則は、システム全体のパッケージの暗黙の存在に依存してはいけないと主張します。代わりに、
- アプリ特有のライブラリが利用可能であることを確認する
- OSにシェルを確認する
- curlやImageMagickなど、必要なシステムライブラリが利用可能であることを確認する。 (これらが将来アプリが実行される可能性のあるすべてのシステムに存在する保証はありません。)
全体として、12ファクターアプリは自己完結型である必要があります。アプリケーションは、ホストマシンにインストールされた競合するライブラリとの相互作用を避けるために、十分に分離されている必要があります。
例を見てみましょう。Pythonでは、PipとVirtualenvを使用することで、宣言と分離を達成できます。この原則を満たすためには、依存関係の宣言と分離の両方を常に使用する必要があります。依存関係は、外部ソースからではなく、アプリケーション内で管理する必要があります。依存関係は、アプリ内のリポジトリにホストされるべきです。
原則 III. 設定
「環境に設定を保存する」
アプリケーションとその設定は完全に独立しているべきです。さらに、設定を常にコード内に保存することは完全に避けるべきです。
設定は別のファイルを持ち、コードリポジトリ内にホストされるべきではありません。別の設定ファイルを持つことで、特定の設定値を変更する際に実際のコードベースに触れることなく設定値を簡単に更新できます。
設定がアプリ内ではなく、環境に変数として存在する場合、ソースコードに触れることなく別の環境に移動できます。12ファクターアプリは、設定を変数として保存し、「リポジトリに誤ってチェックインされる可能性が低い」ようにします。もう1つのボーナス：これにより、設定が言語やOSに依存しなくなります。
原則 IV. バッキングサービス
「バッキングサービスを接続されたリソースとして扱う」
12ファクターアプリでは、コアアプリをサポートしないサービスは、サービスとしてアクセスする必要があります。これらのコアではない必須サービスには、次のようなものが含まれます：
- データベース
- 外部ストレージ
- メッセージキュー
- その他
これらはリソースとして扱われます。これらには、HTTPや類似のリクエストを介してサービスとしてアクセスし、設定で指定する必要があります。これにより、サービスのソースを変更してもアプリのコアコードに影響を与えることはありません。
たとえば、メッセージキューイングシステムを使用するアプリは、RabbitMQからZeroMQ、ActiveMQに簡単に変更できるのが最適です。設定情報を変更するだけで済みます。
原則 V. ビルド、リリース、実行
「ビルドと実行の段階を厳密に分ける」
12ファクターアプリは、ビルド、リリース、および実行の3つの段階を分けることに厳格です。
ビルドプロセスを開始するには、アプリをソース管理に保存し、その依存関係をビルドします。設定情報を分けることで、リリース段階のビルドと組み合わせることができ、それから実行段階の準備が整います。また、各リリースには一意のIDが必要です。
原則 VI. プロセス
「アプリを1つ以上のステートレスプロセスとして実行する」
永続化が必要なデータは、データベースなどのステートフルなバッキングサービスに保存します。この考え方は、プロセスがステートレスであり、何も共有しないということです。
多くの開発者は「スティッキーセッション」に慣れており、同じサービスからの次のリクエストが来ることを期待してセッションに情報を保存することは、この方法論に矛盾します。
原則 VII. ポートバインディング原則
「ポートバインディングを介してサービスをエクスポートする」
12ファクターアプリは、常に追加のアプリケーションから独立している必要があります。すべての機能は独自のプロセスであり、完全に分離されているべきです。
従来の環境では、異なるプロセスが異なる機能を扱うことを前提としています。したがって、これらの機能がHTTPなどのWebプロトコルを介して入手可能であると仮定するのは簡単であり、アプリがApacheやTomcatのようなWebサーバーの背後で実行される可能性が高くなります。しかし、これは12ファクターの方法論には反します。
代わりに、コアアプリにWebサーバーライブラリや同様のものを追加します。これにより、アプリは定義されたポートでリクエストを待機できるようになります。HTTPまたは別のプロトコルであってもです。
原則 VIII. 同時実行性
「プロセスモデルを介して拡張する」
真の12ファクターアプリは、スケーリングを考慮して設計されています。アプリケーションを構築して、クラウドでのスケーリングがシームレスになるようにします。アプリを同時実行可能に設計することで、新しいインスタンスをクラウドに effortlessly スピンアップできます。
より多くの容量を追加するため（追加のマシンで追加のプロセスを開始する）、アプリはローカルマシンのメモリやCPUを増やすのではなく、より多くのインスタンスを追加できる必要があります。
原則 IX. 廃棄可能性
「迅速な起動と優雅なシャットダウンで堅牢性を最大化する」
廃棄可能なプロセスの概念は、アプリケーションがいつでも終了できるが、ユーザーには影響しないことを意味します。アプリは他のアプリに置き換えられたり、すぐに再起動したりできます。アプリに廃棄可能性を組み込むことで、アプリは優雅にシャットダウンします。すべての利用されたリソースをクリーンアップし、スムーズにシャットダウンする必要があります。
このように設計された場合、アプリはすぐに再起動します。同様に、プロセスが終了するときは、現在のリクエストを完了し、すべての受信リクエストを拒否し、終了する必要があります。
原則 X. 開発/本番の均衡
「開発、ステージング、および本番をできるだけ似たものに保つ」
開発と本番にデプロイされるアプリは均衡を保つべきです。基本的には、両方のデプロイメントの間にわずかな違いしかないべきです。
大きな違いは、開発と本番のコード間に意図しない互換性の問題を引き起こす可能性があります。12ファクターアプリを構築する際には、開発と本番の間でのバッキングサービスは同じである必要があります。ここに違いがあると、将来的に重要な問題を引き起こす可能性があります。
原則 XI. ログ
「ログをイベントストリームとして扱う」
モノリシックおよび従来のアプリがログ情報をファイルに保存するのに対し、この原則はログを選択した場所にストリーミングする必要があると主張しています。単にログファイルにダンプするのではなく。
通常、ログは、すべてのバーニング後にクラウドベースの環境内の同じ場所に存在しません。新しいプロセスが開始されたり、アプリがクラッシュしたりすると、ログは複数のクラウドマシンに分散されます。単一のマシンやホストに保存されません。
この問題を解決するには、ログがストリーミングされる一般的な場所を指定します。場合によっては、単に標準出力をファイルにリダイレクトすることで済むこともあります。しかし、より一般的には、Fluentdのようなログルータを展開し、ログをHadoopや特定のサービス、たとえばSplunkに保存したいと思うでしょう。
原則 XII. 管理プロセス
「管理/管理タスクを一回限りのプロセスとして実行する」
最後の12ファクターアプリの原則は、管理タスクをアプリケーションの残りの部分から分離することを提案します。これらのタスクには、データベースの移行やレコードの検査が含まれる場合があります。
管理プロセスは別ですが、同じ環境内で、アプリ自体の基本コードと設定に対して実行し続ける必要があります。管理タスクのコードをアプリケーションと一緒に出荷することで、ドリフトを防ぎます。
関連する読み物
これらの投稿は私自身の意見であり、BMCの立場、戦略、または意見を必ずしも表すものではありません。