The Twelve Factor App

원본 : https://12factor.net/ko/ 과 자체적인 해석을 곁들여(?) 작성하였습니다.

1편: https://kimjongmo.github.io/common-sense/twelve-factor-app

1. 포트 바인딩

• 서비스는 포트 바인딩을 통해서 외부에 공개한다.
• 웹서버는 웹앱과 독립적으로 존재해야 한다. 즉 웹 서비스를 위해 처리하는 실행환경 및 런타임 인젝션에 웹 서버는 의존되면 안됩니다.
• 포트 바인딩된 앱은 또 다른 포트 바인딩된 앱과 상호작용 할 수 있습니다.

2. 동시성

• Twelve-Factor App의 프로세스는 다양한 타입으로 나누어져 있으며, 각각은 작업 부하를 처리할 수 있도록 설계되어야 합니다. 예를 들면 HTTP 요청은 웹 프로세스가 처리하고, 시간이 오래 걸리는 작업은 worker 프로세스가 처리하도록 설계되어야 합니다.

• 하나의 머신에서 너무 많은 프로세스가 있는 것 보다는 여러 물리적인 머신에서 여러개의 프로세스로 Scale 을 넓혀 가야합니다.

3. 폐기 가능

• Twelve-Factor App은 시작과 종료를 간단하게 할 수 있어야 합니다.

• 짧은 시작 시작은 릴리즈 작업과 확장이 더 민첩하게 이루어질 수 있도록 만듭니다.

• 프로세스는 프로세스 매니저로부터 sigterm 신호를 받았을 때 그레이스풀 셧다운을 해야합니다.

  • 그레이스풀 셧다운 : 포트의 수신을 중지, 현재 처리 중인 요청이 끝나길 기다린 뒤 프로세스를 종료.

• 백그라운드에서 실행중인 worker 프로세스의 경우 메시지큐에 작업을 다시 큐로 돌리는 방식이 있습니다.

4. 개발과 프로덕션 환경의 일치

• 로컬 개발 환경과 프로덕션 환경의 차이는 주로 아래와 같습니다.

  • 시간 : 개발자가 작업한 코드는 프로덕션에 반영되기까지 오랜시간이 필요합니다.
  • 담당 : 개발자가 코드를 작성하면, 시스템 엔지니어가 배포를 도와 배포합니다.
  • 툴 : 실제 툴과 개발용 툴의 차이가 있을 수 있습니다(ex. Linux vs OS X)

• Twelve-Factor App 은 이러한 로컬과 프로덕션 환경의 차이를 작게 유지하여 지속적인 배포가 가능하도록 되어야 합니다.

  • 시간 : 개발자가 작성한 코드는 몇 시간 이내에 배포되어야 합니다.
  • 담당 : 개발자들은 배포와 프로덕션 모니터링에 깊게 관여합니다.
  • 툴 : 실제 툴과 최대한 비슷한 환경을 만들어야 합니다.

5. 로그

• Twelve-Factor App은 아웃풋 스트림의 전달이나 저장에 절대 관여하지 않습니다.
• 각 프로세스의 스트림은 실행 환경에 의해서 수집된 후 다른 스트림과 병합되어 하나 이상의 목적지(ex. Splunk, Hadoop/Hive (로그 분석 시스템, 데이터 저장소))로 전달해야 합니다. (암튼 로컬말고 별도로 저장소를 사용하라는 말인듯)

6. 어드민 프로세스

• 개발자들은 아래와 같은 일회성 관리나 유지 보수 작업이 필요합니다.
  • 데이터베이스 마이그레이션
  • 임의의 일회성 스크립트
• 이런 일회성 어드민 프로세스는 기존 프로세스들과 동일한 환경, 코드베이스, 설정을 사용합니다.
• Twelve-Factor App은 별도의 설치나 구성없이 shell을 제공하는 언어 (ruby, python 같은) 스크르립트 언어를 선호합니다. 그렇게 되면 어드민 프로세스를 바로바로 실행가능하게 됩니다.