ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Twelve-Factor(트웰브 팩터) 방법론
    Programming/etc. 2022. 3. 28. 22:10

    트웰브 팩터(Twelve-Factor App,방법론)
    아래의 특징을 가진 SaaS 앱을 만들기 위한 방법론
    1.설정 자동화를 위한 절차(declarative)를 체계화하여 새로운 개발자가 프로젝트에 드는 시간과 비용을 최소화한다.
    2.OS에 따라 달라지는 부분을 명확히하고, 실행 환경 사이의 이식성을 극대화한다.
    3.최근 등장한 클라우드 플랫폼 배포에 적합하고, 서버와 시스템의 관리가 필요없게 된다.
    4.개발 환경과 운영 환경의 차이를 최소화하고 민첩성을 극대화하기 위해 지속적인 배포가 가능하다.
    5.툴, 아키텍처, 개발 방식을 크게 바꾸지 않고 확장(scale up)을 할 수 있다.

     

    트웰브 팩터 방법론은 어떤 프로그래밍 언어로 작성된 앱에도 적용 할 수 있고 백엔드 서비스(데이터베이스, 큐, 메모리 캐시 등)와 다양한 조합으로 사용할 수 있다.


    The Twelve-Factors
    1.코드베이스
    •버전 관리되는 하나의 코드베이스와 다양한 배포
    •코드베이스는 단일 저장소이거나 루트 커밋을 공유하는 여러 저장소(Git같은 분산 버전 관리 시스템)일수도있다.
    •앱의 코드베이스는 한개여야하고, 여러개라면 앱이 아닌 분산 시스템으로 봐야한다.

     

    2.종속성
    •환경(enviroment)에 저장된 설정
    •종속성 선언이란, 패키지 매니저 등으로 명시적으로 pacakge.json등에 선언하는 것
    •종속성 분리란, 전역 설치 하는 것보다 지역 설치를 통하여 앱 별로 따로 패키지를 관리하는 것이다.

     

    3.설정
    •환경(environment)에 저장된 설정
    •설정은 배포(스테이징, 프로덕션, 개발환경 등) 마다 달라질 수 있는 모든 것들
    •종류: DB와 같은 백엔드 서비스들의 리소스 핸들
              AWS S3와 같은 외부 서비스 인증정보(API 말하는 듯)

              배포된 호스트의 정규화된 호스트 이름 처럼 각 배포마다 달라지는 값
    •설정의 분리라는 것은 껍데기로 정의만 되어있고 정작 중요한 설정은 외부에서 임포트해서 사용하는 식인듯
    ex)spring cloud config server

     

    4.백엔드 서비스
    •백엔드 서비스를 연결된 리소스로 취급
    •설정에 있는 리소스 핸들만 수정해서 소스코드를 수정하거나 새로 배포하지 않고 api를 스위칭 할 수 있어야한    다.

     

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

     

    6.프로세스 
    •애플리케이션을 하나 혹은 여러개의 무상태(stateless) 프로세스로 실행
    •세션 상태 데이터는 유효기간을 제공하는 데이터 저장소에 저장

     

    7.포트 바인딩
    •포트 바인딩을 사용해서 서비스를 공개함
    •웹앱은 웹서버 컨테이너 내부에서 실행되기도 한다.
    •포트 바인딩을 통하여 하나의 앱을 다른 앱의 백엔드로 사용 할 수 있고, 이를 위해 2.종속성 분리를 위한 백엔드 앱의 URL을 사용할 앱의 3.설정을 통하여 해결 할 수 있다는 내용 인듯 하다.

     

    8.동시성(Concurrency)
    •프로세스 모델을 사용한 확장
    •앱은 여러개의 물리적 머신에서 돌아가는 여러개의 프로세스로 넓게 퍼질 수 있어야만 한다.
    •프로세스 모델은 수평적으로 확장

     

    9.폐기 가능(Disposability)
    •빠른 시작과 그레이스풀 셧다운(graceful shutdown)을 통한 안정성 극대화
    •트웰브 팩터 앱의 프로세스는 간단하게 폐기가 가능, 바로 시작 혹은 종료 가능 -> 프로덕션 배포 안정성 증가
    •그레이스풀 셧다운 과정: 서비스 포트 수신 중지 -> 현재 처리중 요청은 끝날때까지 대기 -> 프로세스 종료
    *그레이스풀 셧다운: 프로그램이 종료 될 때 side effect를 발생하지 않고 로직들이 잘 처리된 후(데이터, 비즈니스 로직 등) 종료하는 것을 의미.

     

    10.개발/프로덕션 환경 일치
    •개발,스테이징, 프로덕션 환경을 최대한 비슷하게 유지
    •세가지는 시간의 차이, 담당자의 차이, 툴의 차이가 있었는데 이 차이를 최소화 해야한다. 한마디로 개발용에선 이걸로 하고 실제 배포용으론 다른 라이브러리 혹은 방식을 쓰면 안된다는 것

     

    11.로그
    •로그를 이벤트 스트림으로 취급
    •보통 로그는 디스트에 파일로 저장되는데 이는 출력  포맷 중 하나에 불과하니 로그 분석 시스템을 사용하여 과거의 특정 이벤트를 찾거나 하는 앱의 동작을 조사할  수 있는 강력함과 유연성을 가지게한다.
     ex)특정 이벤트 발생하거나 어떤 수치 혹은 값에 도달하면 알림이나 그래프 등

     

    12.Admin 프로세스
    •admin / maintenance 작업을 일회성 프로세스로 실행
    •프로세스 포메이션은 애플리케이션의 일반적인 기능들(web req등)을 처리하기 위한 프로세스들의 집합
    •이와 별개로 종종 일회성 관리나 유지보수 작업이 필요, 예로 디비 마이그레이션,저장소의 커밋된 일회성 스크립트 실행 등
    •일회성 관리자 프로세스 또한 오래 실행되는 프로세스와 같은 환경에서 돌아야한다.
    •모든 프로레스 타입들에는 종속성 분리 기술이 사용되어야 한다.

     

    -References-

    https://12factor.net/ko/

    'Programming > etc.' 카테고리의 다른 글

    RESTful API에 대하여  (0) 2022.05.10
    Garbage Collector, Garbage Collection에 대하여  (0) 2022.03.29
    CDN에 관하여  (0) 2022.03.18
    CI/CD에 대한 이해  (0) 2022.02.10
    CORS(Cross-Origin Resource Sharing)에 대하여  (0) 2022.02.10

    댓글

Designed by Kort.