1. 개요

12 Factor Applicatin(Twelve-Factor Application) 이란..

 1) 설정 자동화를 위한 절차를 체계화하여 새로운 개발자가 프로젝트에 참여하는데 드는 시간과 비용을 최소화 하고,
 2) OS에 따라 달라지는 부분을 명확히하고 실행환경 사이의 이식성을 극대화하고, 
 3) 클라우드 플랫폼 배포에 적합하고, 서버와 시스템 관리가 필요없게 하며,
 4) 개발환경과 운영환경의 차이를 최소화하고 민첩성을 극대화하기 위해 지속적인 배포가 가능하고,
 5) Tool, Architecture, 개발 방식을 크게 바꾸지 않고 확장 가능한 

SaaS Application을 만들기 위한 방법론이다. 이 방법론은 어떤 프로그래밍 언어로 작성된 App.에도 적용 가능하고 Back-end 서비스(DB, Queue, Mem cache 등)와 다양하게 조합할 수 있다. 

2. 12 Factor

 1) Codebase : 버전 관리되는 하나의 Codebase와 다양한 배포

Codebase는 SVN 같은 중앙집중식 버전 관리 시스템 형태의 단일 저장소일 수도 있고 Git 과 같이 루트 커밋을 공유하는 분산 버전 관리 시스템 형태의 저장소 일 수 있다.
Codebase와 App. 은 항상 1:1 관계가 성립되고, Codebase가 여러개이면 App. 도 여러개 즉 분산시스템으로 볼 수 있다. 이 개별 App. 은 12Factor를 따른다.
여러개의 App. 이 동일한 코드를 공유하지 않도록 해야 하며(12Factor 위반), 공유하려는 코드를 라이브러리화 시키고, 해당 라이브러리를 종속성 매니저로 관리해야 한다. 

 2) 종속성 : 명시적으로 선언되고 분리된 종속성

12Factor App.은 전체 시스템에 특정 패키지가 암묵적으로 존재하는 것에 대해 절대 의존하지 않는다. manifest를 이용하여 모든 종속성을 완전하고 엄격하게 선언한다. 
종속성 분리 툴을 사용하여 실행하는 동안 둘러싼 시스템으로 암묵적 종속적 유출이 발생하지 않는 것을 보장한다.
종속성 선언을 위해 Ruby는 Gemfile manifest 포맷 지원, Python은 Pip가 있고, 종속성 분리를 위해 Ruby는 bundle exec, Python은 Virtualenv, C언어에서는 Autoconf가 있다.
종속성 선언과 분리는 항상 같이 사용되어야 12Factor에 만족할 수 있다.  

 3) 설정 : Environment에 저장된 설정

설정에는 다음이 포함된다. 12Factor App.은 설정을 환경변수(envvars나 env)에 저장한다. 
 - 데이터베이스, memcached 등 백엔드 서비스들의 리소스 핸들
 - Amazon S3 이나 트위터 등의 외부 서비스 인증 정보
 - 배포된 호스트의 정규화된 호스트 이름(canonical hostname)처럼 각 배포마다 달라지는 값 4) Back-end 서비스
설정을 상수로 코드에 저장하는 것은 12Factor를 위반하는 것이다. 12Factor는 설정을 코드에서 엄격하게 분리하는 것을 요구한다. 

 4) Back-end 서비스 : Back-end 서비스를 연결된 리소스로 취급

Back-end 서비스란 애플리케이션 정상 동작 중 네트워크를 통해 이용하는 모든 서비스이다.
 ※ Back-end 서비스의 예
 : 데이터 저장소(예: MySQL, CouchDB), 메시지 큐잉 시스템(예: RabbitMQ, Beanstalkd), 메일을 보내기 위한 SMTP 서비스 (예: Postfix), 캐시 시스템(예: Memcached) 등

각각의 다른 Back-end 서비스는 리소스이다. 예를 들어 하나의 MySQL DB는 하나의 리소스이다. 12Factor App.은 이러한 데이터베이스들을 Attached 리소스로 다룬다. 
이들은 서로 느슨하게 결합되고, 이 리소스는 자유롭게 배포에 연결되거나 분리될 수 있다. 

 5) 빌드, 릴리즈, 실행 : 철저하게 분리된 빌드와 실행 단계

Codebase는 3단계를 거쳐 배포로 변환된다. "빌드단계, 릴리즈단계, 실행단계(런타임)"
12Factor App.은 이 3단계를 엄격하게 서로 분리한다. 
배포 도구는 일반적으로 릴리즈 관리 도구를 제공하는데, 이전 릴리즈로 되돌릴 수 있는 롤백 기능이 있어 필요 시 이전 버전으로 쉽고 빠르게 이전 릴리즈로 롤백할 수 있도록 해준다.

 6) 프로세스 : 애플리케이션을 하나 혹은 어려개의 stateless 프로세스로 실행

12Factor 프로세스는 stateless이며 아무것도 공유하지 않는다. 유지될 필요가 있는 모든 데이터는 DB와 같은안정된 Back-end 서비스에 저장되어야 한다.
※ Sticky Session은 12Factor에 위반되며, 절대로 사용하거나 의존해서는 안된다.
   Session 상태 데이터는 Memcached나 Redis처럼 유효기간을 제공하는 데이터 저장소에 저장하는 것이 적합하다.

 7) 포트 바인딩 : 포트 바인딩을 사용해서 서비스를 공개함.

12Factor App.은 완전히 독립적이고 웹서버가 웹 서비스를 만들기 위해 처리하는 실행환경에 대한 런타임 인젝션에 의존하지 않는다.
12Factor 웹 App.은 포트를 바인딩하여 HTTP 서비스로 공개되며 그 포트로 들어오는 요청을 기다린다.
포트 바인딩을 사용한다는 것은 하나의 앱이 다른 앱을 위한 Back-end 서비스가 될 수 있다는 것을 의미한다.

 8) 동시성(Concurrency) : 프로세스 모델을 사용한 확장

프로세스 모델은 수평적으로 확장하는 경우가 가장 좋다.
12Factor App.에서의 프로세스는 서비스 데몬들을 실행하기 위한 Unix 프로세스 모델에서 큰 힌트를 얻었다.
애플리케이션의 작업을 적절한 프로세스 타입에 할당함으로써 다양한 작업 부하를 처리할 수 있도록 설계할 수 있다. -> 프로세스 포메이션
12Factor App. 프로세스는 절대 데몬화하면 안된다.
아무것도 공유하지 않고 수평으로 분할할 수 있는 12Factor App. 프로세스의 성질은 동시성을 높이는 것은 간단하고 안정적인 작업이라는 것을 의미한다.

 9) 폐기 기능(Disposability) : 빠른 시작과 Graceful Shutdown을 통한 안정성 극대화

12Factor App.의 프로세스는 간단하게 폐기 가능하다. 즉, 프로세스는 바로 시작하거나 종료될 수 있다. 
프로세스는 시작 시간을 최소화하도록 노력해야 하고, 하드웨어 에러에 대한 갑작스러운 죽음에도 견고해야 한다.(Beanstalkd와 같은 견고한 큐잉 백엔드를 사용하는 것을 권장)

 10) 개발/프로덕션환경 일치 : 개발, 스테이징, 프로덕션 환경을 최대한 비슷하게 유지

12Factor App.은 개발 환경과 프로덕션 환경의 차이를 작게 유지하여 지속적인 배포가 가능하도록 디자인 되었다. 

※ 차이에 대한 대응책

 11) 로그 : 로그를 이벤트 스트림으로 취급

12Factor App은 아웃풋 스트림의 전달이나 저장에 절대 관여하지 않는다.
App.은 로그 파일을 작성하거나, 관리하려고 해서는 안된다.
대신, 각 프로세스는 이벤트 스트림을 버퍼링 없이 stdout에 출력한다. 이는 오픈소스로그라우터를 통해 관리한다. (예: (Logplex, Fluentd))
App.의 이벤트 스트림은 Splunk 같은 로그 분석 시스템과 Hadoop/Hive 같은 범용 데이터 보관소에 보내면 장기간에 걸쳐 App.의 동작을 조사할 수 있는 강력함과 유연성을 가지게 된다. 

 12) Admin 프로세스 : admin/maintenance 작업을 일회성 프로세스로 실행

12Factor는 별도의 설치나 구성없이 REPL shell을 제공하는 언어를 강하게 선호한다.
이러한 점은 일회성 스크립트를 실행하기 쉽게 만들어주기 때문인데, 개발자는 로컬 배포에서는  App.을 체크아웃한 디렉토리에서 일회성 admin 프로세스를 shell 명령어로 바로 실행시키고 production 배포에서는 ssh나 배포의 실행 환경에서 제공하는 다른 원격 명령어 실행 메커니즘을 사용하여 admin 프로세스를 실행할 수 있다.