スケーラビリティの高いアプリケーションを迅速かつ効率的に構築するための12の基本をご紹介します。
、アプリケーションを短期間で構築し、スケーラブルにするためのガイダンスを提供します。これは、software-as-a-serviceアプリケーション、Webアプリケーション、そして潜在的にはコミュニケーションplatform-as-a-serviceで使用するためにHerokuの開発者によって作成されました。12ファクターアプリケーション手法は、プロジェクトを効率的に編成し、スケーラブルなアプリケーションを管理するという点で、オープンソース開発にとって大きな利点があります。
-方法論の原則の適用
12ファクター・アプリケーション手法のルールは非常に厳格であり、SaaSアプリケーションの開発とデプロイの基礎となるもので、プログラミング言語やデータベースに制限されることはありません。
つのベースライン・コードで複数のデプロイメント
すべてのアプリケーションは、複数の異なる環境/デプロイメントを持つコードベースを持つべきです。
開発者は、異なる環境でセットアップするためだけに別のコードベースを開発すべきではありません。異なる環境は異なる状態を表しますが、これらの異なる環境は同じコードベースを共有すべきです。
GitLab のようなバージョン管理システムに保存されている多くのオープンソースプロジェクトでは、環境をブランチとみなすことができます。たとえば、VoIP-app というクラウド VoIP アプリケーション用のリポジトリを中央のバージョン管理システムに作成し、開発ブランチとステージングブランチのふたつのブランチを作成します。
依存関係の明確な宣言と分離
すべての依存関係を宣言してください。アプリケーションは外部のシステム・ツールやライブラリに依存してもかまいませんが、システム・ツールやライブラリに依存してはいけません。アプリケーションは常に、すべての依存関係とその正しいバージョンを明示的に宣言しなければなりません。
特にオープンソースプロジェクトでは、外部ライブラリの変更によってコードベースにバグが混入する可能性があります。たとえば、あるコードベースが、依存関係やバージョンを明示的に宣言せずに外部ライブラリを使うことがあります。外部ライブラリがテストされていない新しいバージョンに更新されると、コードに互換性の問題が発生する可能性があります。依存関係とその正しいバージョンが明示的に宣言されていれば、 コードベースにはこのような問題は発生しません。
テクノロジースタックによっては、依存ライブラリの名前とバージョンを表す依存ライブラリ宣言のリストを読み込んで、それぞれのシステム上の依存関係をダウンロードするために、パッケージマネージャを使用するのが最善です。
環境設定の保存
複数の環境もしくはクライアントをサポートする必要があるとき、コンフィギュレーションはアプリケーションの重要な部分になります。デプロイメント間のコンフィギュレーションは環境変数に保存されるべきです。これによってコードを変更することなくデプロイメント間のコンフィギュレーションを簡単に変更できます。
クローズドソースのアプリケーションの場合、データベース接続情報やその他の秘密データのような機密情報を公開したくないので、この原則は有益です。しかし、オープンソースの開発では、これらの詳細は公開されます。この場合、何度もコードを変更する必要がないという利点があります。このように変数を設定し、環境を変えるだけでコードを完璧に動作させることができます。
バックエンド・サービスを追加リソースとして扱う
すべてのフォールバック・サービスは、実行環境によってアタッチまたはデタッチされる追加リソースとみなされます。この原則に従って、これらのサービスの場所や接続の詳細が変更されても、コードを変更する必要はありません。これらの詳細はコンフィギュレーションで確認できます。
バックアップサービスは、デプロイメントからすばやくアタッチまたはデタッチできます。例えば、クラウドベースのスプレッドシートのデータベースが正常に動作しない場合、開発者はコードベースに変更を加えることなく、最近のバックアップからリストアされた新しいデータベースサーバーを作成できるはずです。
ビルドとランの厳格な分離
12ファクターのアプリケーション手法では、ビルド、リリース、実行の各フェーズを厳密に区別する必要があります。
- 最初の段階はフェーズです。このフェーズでは、ソースコードがアセンブルまたはコンパイルされて実行可能ファイルになり、依存関係がロードされてアセットが作成されます。ビルドフェーズは、新しいコードをデプロイする必要があるたびに開始されます。
- 2番目のフェーズはフェーズです。このフェーズでは、ビルド フェーズで生成されたコードがデプロイの現在の設定と組み合わされます。最終リリースにはビルドとコンフィギュレーションが含まれ、実行環境ですぐに実行できます。
- 3番目と最後のフェーズは、実行環境でアプリケーションを実行するフェーズです。このフェーズは、他のフェーズによって中断されてはなりません。
これらのフェーズを厳密に区別することで、コードの断線を避けることができ、システムのメンテナンスがより管理しやすくなります。
つ以上のステートレス・プロセスでアプリケーションを実行します。
アプリケーションは、実行環境において1つ以上のプロセスの集まりとして実行されます。これらのプロセスはステートレスで、永続的なデータはデータベースなどのバックエンドサービスに格納されます。
アプリケーションの特定のバージョンを使用している開発者は、スケーラビリティのためにクラウドプラットフォーム上にマルチノードのデプロイメントを作成できるため、これはオープンソースにとって便利です。ノードのいずれかがクラッシュするとデータが失われるため、データは永続化されません。
ポートバインディングによるサービス提供
アプリケーションは、他のアプリケーションから独立したサービスとして存在する必要があります。アプリケーションは、他のアプリケーションから独立したサービスとして存在しなければなりません。こうすることで、アプリケーションは必要なときに他のアプリケーションのリソースとして機能することができます。このコンセプトを使って、 12-Factor アプリケーション方法論構築することができます。
プロセスモデリングによる拡張
並行性の原則としても知られているこの原則は、アプリケーション内のすべてのプロセスが、スケーリング、再起動、または自身のクローンを作成できるようにすることを提案しています。
単一のプロセスを大きくする代わりに、開発者は複数のプロセスを作成し、アプリケーションの負荷をそれらのプロセスに分散させることができます。このようにして、各負荷をプロセス・タイプに割り当てることで、異なる負荷に対応できるアプリケーションを構築できます。
堅牢性を高める高速スタートアップとグレースフル・ターミネーション
アプリケーションは単純なプロセスに基づいて構築されるべきです。そのため、開発者はプロセスをスケールアップしながら、何か問題が発生した場合にプロセスを再起動することができます。これにより、アプリケーションのプロセスは簡単に破棄できるようになります。
この原則に基づいてアプリケーションを構築するということは、コードの迅速なデプロイ、迅速な弾力的スケーリング、より柔軟なリリースプロセス、そして堅牢な本番デプロイを意味します。これらはすべて、オープンソースの開発環境において非常に有用です。
開発環境、プレリリース環境、本番環境を可能な限り同一に保ちます。
同じプロジェクトに取り組むチームは、同じオペレーティングシステム、サポートサービス、依存関係を使用する必要があります。そうすることで、エラーの可能性を減らし、開発に必要な時間を短縮することができます。
オープンソース・プロジェクトの開発者は分散しており、使用するシステム、サービス、依存関係について コミュニケーションをとる ことができない可能性があるため、この原則を実践することはオープンソース・プロジェクトにとって課題となる可能性があります。このような相違を減らす1つの可能性は、どのオペレーティングシステム、サービス、依存関係を使用するかを推奨する開発ガイドラインを作成することです。
ログをイベントストリームとして扱う
ログは生産上の問題のトラブルシューティングやユーザーの行動を理解するために重要です。しかし、12ファクターアプリケーションの方法論はログの管理に適していません。
その代わりに、ログエントリはイベントのストリームとして扱われ、標準出力に書き出され、分析とアーカイブのために別のサービスに送られるべきです。ロボティック・プロセス・オートメーション技術は、ログの処理と分析のためのサードパーティ・サービスとして使用することができます。実行環境は、そのデータストリームで何をするかを決定します。これは、より大きな柔軟性とアプリケーションの動作を反映する能力を提供します。
バックグラウンド管理タスクはワンタイムプロセスとして実行されます。
この原則は、実際には開発とは関係なく、アプリケーションの管理に関するものです。管理プロセスは、アプリケーションの通常の長時間実行プロセスと同じ環境で実行されるべきです。ローカルのデプロイメントでは、開発者はアプリケーションのチェックアウトディレクトリ内のシェルコマンドを使用して、1回限りの管理プロセスを直接実行することができます。
はんけつをくだす
12ファクターアプリケーション方法論を使用してアプリケーションを開発することは、効率性の向上と迅速なリリースにつながります。オープンソース開発では、特定のガイドラインから逸脱することが理にかなっているかもしれませんが、可能な限り忠実に従うことが最善です。
オープンソースの12ファクターアプリケーションは可能です。その良い例が Jitsiです。 Jitsiは12ファクターアプリケーションの方法論を使って構築され、大成功を収めました。
via:
