The Twelve Factors

 

 

Cloud-Native App은 Cloud 환경에 App을 배포하여 서비스하는 

SaaS(Software As A Service) 방식입니다

 

 

그리고 Cloud-Native와 SaaS에서는 Agile Manifesto 만큼 유명한 문서가 있죠

 

 

The Twelve-Factor App

The Twelve-Factor App (한국어)

 

 

App이 Cloud 환경에서 올바르게 동작할 수 있도록 개발하는

12가지 요소가 정리되어 있습니다

Cloud-Native 개발자라면 한 번쯤은 들어봤을 문서죠

에자일 선언문처럼 한글로도 잘 정리되어 있습니다

 

 

The Twelve Factor App의 '12'는 SaaS 개발 방법론 12가지입니다

이 문서는 Heroku라는 PaaS(Platform As A Service) 클라우드 플랫폼을 통해서

다양한 App의 개발, 운영, 확장을 관찰한 사람들에 의해 만들어졌다고 하네요!

 

 

[PaaS, Heroku]

/*

PaaS?

클라우드 컴퓨팅 서비스 분류 중 하나

앱을 개발하거나 구현할 때, 관련 인프라를 만들고 유지 보수하는 복잡함 없이

애플리케이션을 개발, 실행, 관리할 수 있게 하는 플랫폼을 제공

 

 

Heroku?

 

Heroku는 소프트웨어 개발 플랫폼이며 그림과 같이 AWS위에 올라가는 PaaS입니다

(IaaS, PaaS, SaaS를 제공하는 AWS와 달리 PaaS만 제공합니다)

App을 더 빠르게 만들고 배포할 수 있는 개발 환경을 제공해준다고 합니다

자세한 내용은 아래 참고

 

https://www.guru99.com/heroku-vs-aws.html

Heroku vs AWS: What is the Difference?

*/

 

 

해당 문서를 알게된건 2년 전쯤이었는데

생산성을 위해 Cloud에 올라갈 App이 아니어도

항상 이 12가지를 고려합니다

 

 

물론 사내 환경이나 상황 때문에 타협하지만

토이프로젝트에서는 마음껏 적용할 수 있죠!

 

 

 

---

 

 

12 Factors의 목표

12 Factors를 지키면 아래의 SaaS의 특징을 얻을 수 있습니다

 

• 설정 자동화를 위한 절차(declarative)를 체계화하여
  새로운 개발자가 프로젝트에 참여하는데 드는 시간과 비용을 최소화합니다
  
  
• OS에 따라 달라지는 부분을 명확히하고, 실행 환경 사이의 이식성을 극대화합니다
  
  
• 최근 등장한 클라우드 플랫폼 배포에 적합하고, 서버와 시스템의 관리가 필요 없게 됩니다
  
  
• 개발 환경과 운영 환경의 차이를 최소화하고 민첩성을 극대화하기 위해 지속적인 배포가 가능합니다
  
  
• 툴, 아키텍처, 개발 방식을 크게 바꾸지 않고 확장(scale up) 할 수 있습니다

 

 

---

 

 

12 Factors

 

I. Codebase(코드베이스)

버전 관리되는 하나의 코드베이스와 다양한 배포

• App은 항상 1개의 코드베이스(Git, SVN)로 관리 O
• 항상 코드베이스를 기반으로 개발하고 배포 O
• 여러 개의 앱이 동일한 코드를 공유 X
• 같은 앱의 다른 배포 O
  • tag, branch 등

 

II. Dependencies(종속성)

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

• App의 모든 종속성을 명시적으로 선언 O
• 시스템에 특정 패키지가 암묵적으로 있다고 가정 X
• pom.xml 같은 종속성 선언과 mvn build 처럼 종속성 분리를 나누어 사용 O
• 종속성 선언과 분리를 같이 사용 O
• 다양한 환경(window, mac, linux)에서 정상 동작 보장 O
• App에 필요한 시스템 도구가 있으면 App과 도구를 통합 O

 

III. Config(설정)

환경(environment)에 저장된 설정

• 모든 설정 정보(상수)는 코드로부터 분리하여 저장 O
• 설정 정보는 런타임에서 코드가 읽음 O
• 동일한 코드를 여러 환경(운영/개발)에 사용하므로
  환경마다 다른 설정 파일 사용 O
• 설정은 환경변수에 저장 O
  • OS나 언어에 의존하지 않음
• 설정으로 가야 할 정보 O
  • 데이터베이스 정보
  • 호스트 이름 등
  • 외부 리소스 인증 정보
  • 배포마다 달라지는 값(dev, prod)
• 설정을 저장하면 안 되는 위치 X
  • 코드
  • properties file
  • build
  • app serve

 

IV. Backing services(백엔드 서비스)

백엔드 서비스를 연결된 리소스로 취급

• 네트워크를 통해 이용하는 모든 서비스는 백엔드 O
  • DB, Cache, SMTP, Messaging/Queueing system
• 로컬 서비스와 3rd-party 서비스를 구분하지 않음 O
  • 모두 같은 리소스임
• 코드를 수정하지 않고 설정만 변경하여 로컬 DB(예 : MySQL)에서
  3rd-party에서 관리되는 DB(예 : Amazon RDS)로 전환되야함 O
  • Loose-coupled

 

V. Build, release, run(빌드, 릴리즈, 실행)

철저하게 분리된 빌드와 실행 단계

• 단계의 분리 O
  • 빌드 : 코드베이스에서 지정된 배포 버전을 종속성을 가져와 컴파일 수행
  • 릴리즈 : 만들어진 빌드와 해당 버전의 설정을 결합(실행 준비)
  • 실행 : 선택된 릴리즈의 프로세스 집합을 시작
• 모든 릴리즈는 유니크한 릴리즈 아이디를 가짐 O
  • 예) v1.1.0
• 만들어진 릴리즈는 변경될 수 없음 O
• 빌드 단계는 개발자에 의해 실행 O
• 배포 단계는 배포 툴에 의해 실행 O
• 실행 단계는 프로세스 매니저에 의해 실행 O
• 실행 단계는 최대한 간단하게, 빌드는 복잡해도 괜찮음 O

 

VI. Processes(프로세스)

애플리케이션을 하나 혹은 여러 개의 무상태(stateless) 프로세스로 실행

• App은 하나 이상의 프로세스로 실행 O
• 프로세스는 stateless이며 아무것도 공유 X
• 유지될 필요가 있는 모든 데이터는 DB 같은 안정된 백엔드 서비스에 저장 O
• 메모리/파일을 사용할 경우 단일 트랜잭션 내에서 읽고, 쓰고 등의 모든 작업을 처리 O
• Sticky Session X
• 세션 데이터의 경우 Memcached나 Redis 같은 저장소에 저장 O

 

VII. Port binding(포트 바인딩)

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

• App은 포트 바인딩하여 HTTP 서비스로 공개되며
  해당 포트로 들어오는 요청을 기다림 O
• 배포에서는 외부에 공개된 호스트명으로 들어온 요청을
  포트에 바인딩된 프로세스에 전달 O
• HTTP 뿐만 아니라 ejabberd의 XMPP,
  Redis의 Redis protocol 등의 백엔드도 포트 바인딩 O

 

VIII. Concurrency(동시성)

프로세스 모델을 사용한 확장

• 수평적으로 확장할 수 있도록 O
  • 아무것도 공유하지 않는 프로세스 수를 늘려 동시성을 높이는 안정적인 작업
• 수직적인 확장은 줄이는 게 좋음 O
  • 내부 쓰레드 등이 많아지면 무거움
• App은 여러 개의 물리머신에서 돌아가는
  여러개의 프로세스로 넓게 퍼지는 게 좋음 O
  • Microservice
• 프로세스는 절대 데몬화 X

 

IX. Disposability(폐기 가능)

빠른 시작과 그레이스풀 셧다운(graceful shutdown)을 통한 안정성 극대화

• 프로세스 시작 시간을 최소화 O
  • 짧은 시작은 릴리즈와 확장에서 유리하며 안정성도 높음
• 프로세스 매니저로부터 SIGTERM을 받을 때 graceful shutdown O
  • 서비스 포트 수신 중지(이후 거절을 위해)
  • 현재 처리 중인 요청 마무리
  • 현재 처리중인 요청 큐에 되돌려 놓기
  • DB lock 풀어놓기
  • 등등
• 우아하지 않은 갑작스러운 죽음에도 안정적으로 처리 O
  • Beanstalkd 같은 견고한 큐잉 백엔드 사용

 

X. Dev/prod parity(개발/프로덕션환경 일치)

개발, 스테이징, 프로덕션 환경을 최대한 비슷하게 유지

• 환경의 차이를 최소화하여 지속적인 배포 O
  • 시간의 차이 : 개발자가 작성한 코드는 몇 시간, 몇 분마다 배포
  • 담당자의 차이 : 작성한 개발자들이 배포와 production에서의 모니터링에 깊게 관여하기
  • 툴의 차이 : 개발과 production 환경을 비슷하게 유지하기

 

XI. Logs(로그)

로그를 이벤트 스트림으로 취급

• 로그는 고정된 게 아니라 App이 실행되는 동안 발생하는 스트림 O
• App은 로그 파일 작성/관리 X
  • 버퍼링 없이 stdout에 출력
    • 배포 환경에서는 각 프로세스의 로그 스트림은 
      별도의 로그 관리자를 통해 수집되어 열람하거나 보관

 

XII. Admin processes(Admin 프로세스)

admin/maintenance 작업을 일회성 프로세스로 실행

• 일회성 admin 프로세스는 다른 프로세스들과 동일한 환경에서 실행 O
  • DB 마이그레이션
  • 일회성 script 실행
• 일회성 admin 프로세스는 다른 프로세스들처럼 코드베이스와 설정을 기반 O

 

깔끔하게 정리해봤습니다

더 자세한 사항은 직접 문서를 참고해보세요!