The Twelve-Factor App

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

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

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

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

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

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

4つのバックエンドサービスがアタッチされた本番デプロイ

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