Jshiike 3年弱前 edited | ▲upvoteする | link | parent | on: The Twelve-Factor App の解説

The Twelve-Factor AppはHerokuが提唱しているマニフェスト的なもので、モダンなウェブアプリをつくる際に留意すべきポイントがまとまっています。意図するところがすぐにはわかりづらい表現がいくつかありますが、それに対して、Will Koffelがブログで "12-Factor Apps in Plain English" と題して、平易な言葉で解説してくれています。

I. Codebase — One codebase tracked in revision control, many deploys

コードベースはソース管理システムに置き、多くの環境にデプロイできるようにしておくこと。。

II. Dependencies — Explicitly declare and isolate dependencies

依存するライブラリは明確に宣言し、コードをデプロイするときは正しいバージョンがダウンロードされ、正しい場所に置かれるように設定しておくこと。

III. Config — Store config in the environment

設定条件はソースコードの中で環境別に管理すること。

IV. Backing Services — Treat backing services as attached resources

コードは多くのサービス(DB、キャッシュ、メール、キューなど)とやり取りし、そのサービスは様々な環境(同じマシン、別のホスト、別のデータセンター、クラウドなど)で実行されているかもしれないが、コードはその違いを意識せずに各サービスをシンプルなエンドポイント(URL、ときにはID/パスワード)で参照できるようにしておくこと。

V. Build, release, run — Strictly separate build and run stages

ビルドする時点では開発者はあらゆる面倒な作業が必要となる。しかしリリース後、本番の実行されるステージでは、とにかくシンプルで安心できる環境を用意すること。例えば、マシンに障害があっても、アプリが自動的に再起動することで、人の手を借りないで済むようにしておくと、開発チームは安心して夜寝られるようになる。

VI. Processes — Execute the app as one or more stateless processes

多くのトラフィックをさばき、障害耐性を持たせるために、アプリは複数のサーバで実行されることになるが、各コードを実行するインスタンスはステートレスであるべき。つまり、そのシステムのステートは、各々の実行されているアプリのインスタンスではなく、データベース及び共有されたストレージで定義されるべき。例えば、プロファイルの入力画面が3ページあり、中間のステートが実行中のコードで保持されていると、作業が完了するまで同じユーザには同じサーバがアサインされ続ける。正しいアプローチとしては、中間データがDBもしくはkey/valueストアに保持される仕組みにしておくと、途中でサーバが落ちても、ユーザは別のサーバが難なく対応してくれるようになる。

VII. Port binding — Export services via port binding

これは IV. Backing Services の拡張的な話で、アプリは外界に対してもシンプルなURLのインターフェースをもつべきということ。ウェブサーバを使っているとデフォルトでその状態にはなっているが、例えば、社内と社外に対して共通のAPIをアプリが提供していた場合、別々のURLを用意することで、より信頼できる社内アクセスには、セキュリティレベルの違う、早いアクセスを提供できるかもしれない。

VIII. Concurrency — Scale out via the process model

コードを実行する際に、個別の細かいニーズに対して多くのプロセスを走らせるとよいというアイデアに行きつくはず。例えば、ウェブリクエストの対応、APIコールの対応、バックグランドで入会のwelcomeメールやtweetの送信など、それらの作業が独立して別々のプロセスで平行して実行できるようになると、アプリはうまくスケールする。

IX. Disposability — Maximize robustness with fast startup and graceful shutdown

最近は外部ライブラリへの依存が多くなってきているので、秒速で起動することは難しくはなっているが、コードの読込み以外に、その都度に発生する作業があると、高頻度でのリリースサイクルづくりが難しくなる。本番のトラフィックにすぐに対応できるように事前に準備をしておき、起動プロセスをすっきりさせること。また、クラッシュも避けたいが、クラッシュした場合もすぐに復旧できるようにしておき、都度クリーンアップ作業が発生するような状態は避けたい。

X. Dev/prod parity — Keep development, staging, and production as similar as possible

開発/ステージング/本番を極力同じ環境にしておくこと。

XI. Logs — Treat logs as event streams

最低限、エラーログはNew RelicAirBrakeに送ったり、ログをpapertrailSplunk Stormに送るようにしておくこと。リアルタイムのログデータ収集、長期のアーカイブ、データマイニングをHadoopなどを利用して構築しておくと尚良し。

XII. Admin processes — Run admin/management tasks as one-off processes

アプリが本番に提供されると、悪いデータのクリーンアップや、分析データの集計、A/Bテストの実施など、一時的なタスクを開発者が実行しなくてはいけなくなる。ローカルのターミナルウィンドウで実行したり、データベースを直接アップデートはしないこと。本番環境のマシンから実行すること。本番システムへのコンソールアクセスを用意するのは必須。

#heroku

yojik_ 約2年前 | ▲upvoteする | link

III. Config — Store config in the environment

設定条件はソースコードの中で環境別に管理すること。

ですが、元の文から抜粋すと

All configuration data should be stored in a separate place from the code, and read in by the code at runtime.

「すべての設定項目はコードとは分離し、実行時に読み込む」といっているので、なんとなく原文と逆のニュアンスになっていると思います。

”設定条件はソースコードの「外」で環境別に管理すること。”が良いのではないでしょうか?

Back