メインコンテンツへスキップ

12因子アプリケーション:現代の実践とLeapcellのガイド

The Twelve-Factor Appは、堅牢でスケーラブル、かつ保守可能な最新のWebアプリケーションを構築するための方法論であり、もともとはHerokuの開発者によって提唱されました。これは、特にクラウドネイティブ時代において、アプリケーション開発と運用における共通の問題を解決するための制度的なフレームワークを提供します。

これらの12の要素に従うことで、開発者は継続的なデプロイ、高い移植性、スムーズなスケーリングに最適化されたアプリケーションを作成できます。

ヒント

Leapcellは、12因子アプリケーションプラットフォームとして設計されています。12因子Methodologyに従うことで、Leapcellの機能を活用して、アプリケーションをより効率的に構築およびデプロイできます。

このドキュメントは、古典的な12の要素を基に構築されており、Leapcellプラットフォーム上の現代的な解釈とベストプラクティスを補足しています。


12の要素の現代的な解釈とLeapcellの実践

I. 1つのサービスのコードベース

リビジョン管理で追跡される1つのコードベース、多数のデプロイ。

アプリケーションのすべてのコードは、Gitのようなバージョン管理システムを使用して、単一のリポジトリに保存する必要があります。複数のデプロイメント環境(例:開発、本番)が存在する可能性がありますが、それらはすべて同じコードベースから派生する必要があります。

Leapcellのデプロイメントモデルは、基本的にこの原則に基づいています。Gitのコミット履歴の明確さを高め、プロジェクト管理と理解を大幅に簡素化する「リポジトリごとに1つのサービス」というベストプラクティスを提唱しています。

II. マニフェストファイルで依存関係を宣言する

マニフェストファイルで依存関係を明示的に宣言します。

すべての依存関係は、マニフェストファイル(例:package.jsonrequirements.txt)を介して明示的に宣言し、適切な分離ツールで管理する必要があります。

正確な依存関係の管理は、サービスの移植性を確保するために重要です。ビルドプロセスが複雑な場合(例:apt-getを介したシステムパッケージと、pipを介した言語固有のライブラリの両方が必要な場合)、ビルドステップを統合し、一貫した環境を保証するために、build.shスクリプトを作成することを強くお勧めします。

III. 環境を構成として

構成を環境に保存します。

構成(例:データベースのURL、APIキー)をコードから厳密に分離し、環境変数を介して注入します。

最新のベストプラクティスは、ローカル開発に.envファイルを使用することです。Leapcellプラットフォームでは、構成された環境変数がランタイム環境に自動的に注入されるため、アプリケーションはシームレスにアクセスでき、ローカルから本番へのスムーズな移行が保証されます。

IV. バッキングサービス

バッキングサービスをアタッチされたリソースとして扱います。

アプリがネットワーク経由で使用するすべてのサービス(データベースやキャッシュなど)は、構成に保存されているURLまたは資格情報を介してアタッチされたプラグ可能なリソースとして扱う必要があります。

Leapcellのサーバーレスサービスは、/tmpディレクトリを除く読み取り専用のファイルシステムを備えており、この哲学を具現化しています。この設計により、状態の外部化が強制され、インフラストラクチャの高速で動的なスケジューリングが可能になり、コンピューティングリソースが最大限の速度でプロビジョニングされるようになります。さらに、Leapcellは、状態の永続化の負担を効果的に軽減するために、可用性の高いPostgreSQL、Redis、およびオブジェクトストレージサービスを提供します。

V. ビルド、リリース、実行

ビルド、リリース、および実行ステージを厳密に分離します。

この分離により、リリースが不変になり、簡単にロールバックできるようになります。最新のCI/CDパイプラインは、このプロセスを自動化し、迅速で信頼性の高いデプロイを可能にします。

Leapcellは、本番ブランチ(例:main)と開発ブランチを明確に区別することを推奨しています。本番ブランチへの新しいコミットごとに、Leapcellは自動的に新しいビルドとリリースをトリガーし、最新のコードを本番環境にデプロイし、CI/CDワークフローを完全に採用します。

VI. ステートレスプロセス

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

アプリケーションは、「共有なし」のステートレスプロセスとして実行する必要があります。永続化する必要のあるデータは、ステートフルなバッキングサービスに保存する必要があります。

この原則は、迅速な水平スケーリングを実現し、状態を失うことなくいつでもプロセスを開始または停止できるようにするために重要です。Leapcellのサーバーレスサービスは、この点を考慮して設計されており、ステートレスプロセスのシームレスなスケーリングと管理が可能です。

VII. ポートバインディング

ポートバインディングを介してサービスをエクスポートします。

アプリケーションは自己完結型であり、ポートにバインドしてリクエストをリッスンする必要があります。

プラットフォームは、アプリケーション構成によって指定されたポートを使用して、外部トラフィックのルーティングを管理します。

VIII. 並行性

プロセスモデルを介してスケールアウトします。

水平方向にスケール(より多くのプロセスを追加)して負荷の増加に対応します。垂直方向(単一のプロセスをより強力にする)ではありません。

Leapcellのサーバーレスモードは、受信トラフィックに基づいてインスタンスを自動的にスケールし、最適なリソース使用率と応答性を確保し、ステートレスプロセスモデルの利点を活用します。

IX. 処分可能性

高速な起動と正常なシャットダウンにより、堅牢性を最大化します。

プロセスは使い捨て可能である必要があり、いつでも瞬時に開始または停止できることを意味します。

Leapcellは、応答のないプロセスを終了するためにSIGKILLシグナルを送信します。このシグナルを処理し、終了前に必要なクリーンアップを実行するようにアプリケーションを構成できます。

X. 開発/本番環境のパリティ

開発、ステージング、および本番環境を可能な限り類似させてください。

環境間のギャップを埋めることで、本番環境でのみ発生するバグを減らすことができます。

開発と本番に別々のブランチを持つ同じコードベースを使用し、環境固有の構成を管理するためにenv.localファイルを使用することをお勧めします。

XI. ログ

ログをイベントストリームとして扱います。

アプリケーションは、ログファイルのルーティングまたは保存に関与しないでください。代わりに、イベントストリームをバッファリングせずに標準出力(stdout)に書き込む必要があります。

Leapcellは最新のロギングインフラストラクチャを使用しています。すべてのログは、分析および監視のための一元化されたサービスに送信され、用語を検索したり、さまざまな基準に基づいてログをフィルタリングしたりできます。

XII. 管理プロセス

管理/管理タスクを1回限りのプロセスとして実行します。

データベースの移行など、管理タスクは1回限りのプロセスとして実行する必要があります。

Leapcellは現在、アプリケーションの開始前に実行される事前起動コマンドを提供していません。このようなタスクは、ビルドフェーズ中に実行するか、マシン上で手動で実行できます。