12 Factors + 3 Factors

12 Factors

• Heroku 플랫폼을 통해 방대한 앱의 개발, 운영, 확장 등을 관찰한 많은 사람들이 고안해낸 SaaS 개발 방법론
• 시간이 지나면서 앱이 유기적으로 성장하는 부분, 앱 코드베이스에서 작업하는 개발자들 간의 협업, 시간이 지나면서 망가지는 소프트웨어 유지비용을 줄이는 법에 집중

12 Factors의 목적

아래와 같은 특징을 가진 SaaS 앱을 만들기 위함

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

구성요소

1. 코드베이스 (Code Base)

• 애플리케이션은 1개의 코드 베이스(Git, SVN)를 통해 관리되어야 하며, 동일한 코드로 운영/개발에 배포되어여 함
• 코드베이스가 여러개 있는 경우, 앱이 아니라 분산 시스템으로 간주하고 코드베이스 별로 Twelve-Factor를 적용
• 여러개 앱이 동일한 코드를 공유한다면 Twelve-Factor를 위반하는 것이므로 공유하는 코드를 라이브러리화 시켜 각 앱에 종속성을 주입하여 사용
• 다양한 버전의 앱 배포는 하나의 코드베이스를 통해 이루어져야 함 → Git Branch 이용

2. 종속성 격리(Dependency Isolation)

• 전체 시스템에 특정 패키지가 암묵적으로 존재하는 것에 절대 의존하지 않고 애플리케이션의 모든 종속성은 명시적으로 선언하여 사용해야 함
• 필요로 하는 라이브러리를 dependency manifest 파일에 (Gemfile, POM 등) 명시적으로 선언하여 실행환경과 분리시켜 사용하게 되면 다양한 환경에서도 SaaS가 정상작동하는 것을 보장할 수 있음
• Java 프로젝트들은 Maven이나 Gradle을 이용하여 종속성을 명시적으로 관리할 수 있음

3. 설정 (Configurations)

• 설정이란, 배포의 종류마다 달라질 수 있는 환경 관련 항목을 대상으로 함
  • 데이터베이스와의 연결 정보, Amazon S3 등의 외부 서비스 인증 정보, 호스트 이름 등
• 모든 설정 정보는 코드로부터 분리된 공간에 저장되어야 하고, 런타임에서 코드에 의해 읽혀야 함
  • 설정을 상수로 저장하는 것은 Tweleve-Factor를 위반하는 것
• 설정을 환경 변수에 저장하고, 각 배포마다 독립적으로 관리해야 함
  • 이렇게 관리하면 코드 변경없이 각 배포에 대해서 쉽게 변경이 가능해짐
• Java에서는 Spring Cloud Config를 활용

4. 백엔드 서비스 (Linkable Backing Services)

• 백엔드 서비스란 애플리케이션 정상 동작 중 네트워크를 통해 이용하는 모든 서비스를 의미하며, 서드파티 서비스도 포함
• 로컬 서비스와 서드파티 서비스를 모두 구분 없이 애플리케이션과 연결된 동등한 리소스로 취급해야함
• 백엔드 서비스를 자유롭게 연결 및 분리가 가능해야하고 코드 수정 없이 전환이 가능해야함
  • Config에 이러한 백엔드 서비스의 정보를 저장하여 관리

5. 빌드, 릴리즈, 실행 (Build, Release, Run)

• 코드 베이스는 build > release > run의 단계를 거쳐 배포로 변환되며, 각 단계는 엄격하게 분리
  • 빌드 단계
    • 저장소의 코드로부터 종속성을 결합하여 실행 가능한 번들로 변환
    • 오직 빌드 단계에서만 변경이 가능
    • 새로운 코드가 배포될 때마다 개발자에 의해 시작된다
  • 릴리즈 단계
    • 빌드 단계에서 만들어진 빌드와 배포의 환경 설정을 결합, 완성된 릴리즈는 빌드와 설정을 모두 포함하며 실행 환경에서 바로 실행될 수 있도록 준비되어야 함
    • 모든 릴리즈는 각각 유니크한 아이디를 가져야하며, 릴리즈는 추가만 가능하고 변경될 수 없음
    • 이전 릴리즈로 롤백이 가능
  • 실행 단계(런타임)
    • 선택된 릴리즈에 대한 애플리케이션 프로세스의 집합을 시작하고 애플리케이션을 실행 환경에서 돌아가도록 함

6. 무상태 프로세스 (Stateless Process)

• 애플리케이션을 하나 혹은 여러개의 무상태(stateless) 프로세스로 실행해야 하며 아무것도 공유하지 않아야 함
  • SaaS는 Scale out이 가능하기 때문에 여러 개의 인스턴스로 배포될 수 있는데 이 인스턴스 간에 상태를 공유해서는 안됨
  • 하나의 마이크로서비스는 다른 마이크로서비스와 독립되어서 실행되어야 함
• 유지될 필요가 있는 데이터들은 인스턴스의 메모리나 파일에 저장하는 것이 아닌 캐시나 DB 같은 안정된 백엔드 서비스에 저장되어야 함
  • 메모리/파일을 사용할 경우 단일 트랜잭션 내에서 읽고, 쓰고 등의 모든 작업을 처리

7. Port Binding

• 애플리케이션을 다른 애플리케이션에서 런타입 인젝션이 아닌 HTTP 서비스로 접근할 수 있도록 포트 바인딩을 통해 서비스를 공개
• 포트 바인딩을 사용한다는 것은 하나의 앱이 다른 앱을 위한 백엔드 서비스가 될 수 있다는 것을 의미

8. 동시성 (Concurrency)

• 애플리케이션은 Scale-out이 가능해야하며, 무상태 프로세스에 의해 동시성을 높일 수 있음
• 모든 일을 처리하는 하나의 프로세스 대신 기능별로 분리된 프로세스 실행(micro service)
• 프로세스가 데몬형태가 아니어야 함
• OS 프로세스 관리자/분산 프로세스 매니저/Foreman 같은 툴에 의존해서 output stream을 관리하고, 충돌이 발생한 프로세스에 대응, 재시작과 종료를 처리해야 함

9. 폐기 가능 (Disposability)

• 프로세스는 shut down 신호를 받았을 때 graceful shut down 해야함
  • 프로세스는 간단하게 폐기가 가능하며 바로 시작하거나 종료될 수 있어야 함
  • 종료 신호를 받은 애플리케이션은 새로운 요청을 받지않고 기존 요청을 빠르게 처리한 이후 종료되어야 함 (정상적 종료)
    • Message Queue의 Worker의 경우, 현재 처리중인 작업을 큐를 되돌린다던지, Lock-based 시스템의 경우, Lock을 풀고 종료된다던지, 트랜잭션을 통해 전체 작업이 전부 취소된다던지
• SaaS는 요청에 의해 Scale up/down이 빈번히 발생하는데 Disposability를 준수함으로써 사용에 안정성을 얻을 수 있음
• 예기치 못한 애플리케이션의 종료 시에도 견고해야하며, Java에서는 Spring Cloud Circuit Breaker를 통해 장애를 대비할 수 있음
• Docker의 Container를 이용해 쉽게 서비스를 등록하고 삭제할 수 있음

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

• development, staging, production 환경을 최대한 비슷하게 유지해야 함
  • 개발 환경과 production 환경의 차이를 작게 유지하여 지속적인 배포가 가능하도록 디자인
  • 개발 환경과 스테이징 환경에서는 동작하고 테스트에 통과된 코드가 production 환경에서 오류를 일으킬 수 있기 때문
• 준수방법
  • 시간의 차이를 최소화: 개발자가 작성한 코드는 몇 시간 또는 몇 분 후에 배포되어야 함
  • 담당자의 차이를 최소화: 코드를 작성한 개발자들이 배포와 production에서의 모니터링에 깊게 관여함
  • 툴의 차이를 최소화: 개발과 production 환경을 최대한 비슷하게 유지
    • 개발 시에는 H2, 배포 시에는 MySQL 을 사용하는 것이 아닌 동일하게 MySQL사용하는 것을 권장 → Docker를 이용해 손쉽게 해결 가능

11. 로그 (Logs)

• 로그를 이벤트 스트림으로 취급
• 애플리케이션은은 로그 파일을 작성하거나, 관리하려고 해서는 안된다.
  • SaaS는 언제든지 인스턴스가 생성/삭제될 수 있는 가능성이 있기에 로컬에 저장된 로그는 초기화되어 사라짐
  • 로그는 스트림으로 취급하여 별도의 저장소 및 도구를 이용하여 보관

12. 관리자 프로세스 (Admin Process)

• 어드민 또는 유지보수 작업을 일회성 프로세스로 실행해야함
  • DB 마이그레이션, 일회성 스크립트 실행 등
• 관리/유지보수 작업은 release와 함께 실행
• release와 동일한 환경에서 실행하고, 같은 코드 베이스와 config를 사용
• admin 코드는 동기화 문제를 피하기 위해 애플리케이션 코드와 함께 배포

 

3 Factors

• Pivotal에서 기존 12 Factors 에 세가지 요소를 추가

1. API first

• 사용자가 요청 및 응답이 무엇을 기대하는지 이해할 수 있도록 API를 먼저 정의하는 것을 의미
  • 이해 관계자와의 협업을 통해 이루어짐
• 협업하는 개발 프로세스에서 API를 첫 번째 우선 순위로 가져가는 것
• 이점
  • 플랫폼 간 호환 가능
  • 병렬 개발 가능
  • 재사용성 증가

2. Telemetry

• 인스턴스들은 원격으로 모니터링이 되어야 함
  • 모든 지표는 수치화, 시각화가 되어 관리
  • 애플리케이션 성능 모니터링(APM) — 애플리케이션 성능을 모니터링하는 이벤트 스트림
  • 도메인별 원격 측정 - 분석 및 보고를 위한 이벤트 및 데이터 스트림
  • 상태 및 시스템 로그 - 애플리케이션 시작, 종료, 확장, 웹 요청 추적 및 주기적인 상태 확인 결과와 같은 이벤트 스트림

3. Authentication & Authorization

• 인증 및 인가를 통해 보안을 강화해야 함
• JWT 등을 사용

 

 

 

참고자료

https://12factor.net/ko/

https://medium.com/dtevangelist/12-factors-란-b39c7ef1ed30

https://logical-code.tistory.com/174

https://developer.ibm.com/articles/15-factor-applications/

https://happy-coding-day.tistory.com/entry/1-API-First-Design-설계의-선순환