The Twelve-Factor App

IV. バックエンドサービス

バックエンドサービスをアタッチされたリソースとして扱う

バックエンドサービス はアプリケーションが通常の動作の中でネットワーク越しに利用するすべてのサービスを言う。例としては、データストア（例：MySQL や CouchDB）、メッセージキューイングシステム（例：RabbitMQ や Beanstalkd）、電子メールを送信するためのSMTPサービス（例：Postfix）、キャッシュシステム（例：Memcached）などがある。

従来、データストアなどのバックエンドサービスは、デプロイされたアプリケーションと同じシステム管理者によって管理されていた。このようなローカルで管理されるサービスに加えて、サードパーティによって提供、管理されるサービスを利用することもある。例としては、SMTP サービス（例：Postmark）、メトリクス収集システム（例：New Relic や Loggly）、ストレージサービス（例：Amazon S3）、APIアクセス可能な消費者向けサービス（例：TwitterやGoogle Maps、Last.fm）などがある。

Twelve-Factor Appのコードは、ローカルサービスとサードパーティサービスを区別しない。 アプリケーションにとっては、どちらもアタッチされたリソースであり、設定に格納されたURLやその他のロケーター、認証情報でアクセスする。Twelve-Factor Appのデプロイは、アプリケーションのコードに変更を加えることなく、ローカルで管理されるMySQLデータベースをサードパーティに管理されるサービス（Amazon RDSなど）に切り替えることができるべきである。同様に、ローカルのSMTPサーバーも、コードを変更することなくサードパーティのSMTPサービス（Postmarkなど）に切り替えることができるべきである。どちらの場合も、変更が必要なのは設定の中のリソースハンドルのみである。

それぞれのバックエンドサービスは リソース である。例えば、1つのMySQLデータベースはリソースである。2つのMySQLデータベース（アプリケーション層でのシャーディングに使う）は2つの異なるリソースと見なせる。Twelve-Factor Appはこれらのデータベースを アタッチされたリソース として扱う。これは、アタッチされたリソースとアタッチする対象のデプロイが疎結合であることを意味する。

リソースは自由にデプロイにアタッチしたり、デプロイからデタッチしたりできる。例えば、ハードウェアの問題によってアプリケーションのデータベースの動作がおかしい場合、アプリケーションの管理者は最新のバックアップから新しいデータベースサーバーを立ち上げる。そして現在の本番データベースをデタッチし、新しいデータベースをアタッチする – コードを一切変更せずに。