12가지 요소 앱: 최신 사례 및 Leapcell 가이드
The Twelve-Factor App은 견고하고 확장 가능하며 유지 관리 가능한 최신 웹 애플리케이션 구축을 위한 방법론으로, 원래 Heroku의 개발자들이 제시했습니다. 특히 클라우드 네이티브 시대에 애플리케이션 개발 및 운영에서 흔히 발생하는 문제를 해결하기 위한 제도적 프레임워크를 제공합니다.
이 12가지 요소를 따르면 개발자는 지속적인 배포, 높은 이식성 및 원활한 확장에 최적화된 애플리케이션을 만들 수 있습니다.
Leapcell은 12가지 요소 앱 플랫폼으로 설계되었습니다. Twelve-Factor 방법론을 따르면 Leapcell의 기능을 활용하여 애플리케이션을 보다 효율적으로 구축하고 배포할 수 있습니다.
이 문서는 기존의 12가지 요소를 기반으로 Leapcell 플랫폼의 최신 해석 및 우수 사례를 추가하여 보완된 것입니다.
12가지 요소 현대적 해석 및 Leapcell 사례
I. 하나의 서비스를 위한 코드베이스
리비전 컨트롤에서 추적되는 하나의 코드베이스, 많은 배포.
애플리케이션의 모든 코드는 Git과 같은 버전 제어 시스템을 사용하여 단일 저장소에 저장되어야 합니다. 여러 배포 환경(예: 개발, 프로덕션)이 존재할 수 있지만 모두 동일한 코드베이스에서 시작되어야 합니다.
Leapcell의 배포 모델은 근본적으로 이 원칙에 기반합니다. Git 커밋 기록의 명확성을 높이고 프로젝트 관리 및 이해를 크게 단순화하는 “리포지토리당 하나의 서비스”라는 모범 사례를 옹호합니다.
II. 매니페스트 파일에서 종속성 선언
매니페스트 파일에서 종속성을 명시적으로 선언합니다.
모든 종속성은 매니페스트 파일(예: package.json, requirements.txt)을 통해 명시적으로 선언하고 적절한 격리 도구를 사용하여 관리해야 합니다.
정확한 종속성 관리는 서비스 이식성을 보장하는 데 매우 중요합니다. 빌드 프로세스가 복잡한 경우(예:
apt-get을 통한 시스템 패키지와pip을 통한 언어별 라이브러리 모두 필요)build.sh스크립트를 생성하여 빌드 단계를 통합하고 일관된 환경을 보장하는 것이 좋습니다.
III. 환경 변수를 구성으로 사용
환경에 구성을 저장합니다.
구성(예: 데이터베이스 URL, API 키)을 코드와 엄격하게 분리하고 환경 변수를 통해 주입합니다.
최신 모범 사례는 로컬 개발에
.env파일을 사용하는 것입니다. Leapcell 플랫폼에서 구성된 환경 변수는 런타임 환경에 자동으로 주입되므로 애플리케이션이 원활하게 액세스하고 로컬에서 프로덕션으로 원활하게 전환할 수 있습니다.
IV. 백업 서비스
백업 서비스를 연결된 리소스로 취급합니다.
앱이 네트워크를 통해 사용하는 모든 서비스(예: 데이터베이스 또는 캐시)는 구성에 저장된 URL 또는 자격 증명을 통해 연결된 플러그 가능 리소스로 취급해야 합니다.
Leapcell의 서버리스 서비스는
/tmp디렉토리를 제외하고 읽기 전용 파일 시스템을 특징으로 하는 이 철학을 구현합니다. 이 설계는 상태의 외부화를 강제하여 인프라의 고속 동적 스케줄링을 가능하게 하고 최대 속도로 컴퓨팅 리소스가 프로비저닝되도록 보장합니다. 또한 Leapcell은 상태 지속성의 부담을 효과적으로 줄이기 위해 가용성이 높은 PostgreSQL, Redis 및 객체 스토리지 서비스를 제공합니다.
V. 빌드, 릴리스, 실행
빌드, 릴리스, 실행 단계를 엄격하게 분리합니다.
이러한 분리를 통해 릴리스가 변경 불가능하고 쉽게 롤백할 수 있습니다. 최신 CI/CD 파이프라인은 이 프로세스를 자동화하여 빠르고 안정적인 배포를 가능하게 합니다.
Leapcell은 프로덕션 브랜치(예:
main)와 개발 브랜치 간의 명확한 구분을 권장합니다. 프로덕션 브랜치에 대한 모든 새 커밋에 대해 Leapcell은 자동으로 새 빌드 및 릴리스를 트리거하여 최신 코드를 프로덕션에 배포하고 CI/CD 워크플로를 완전히 수용합니다.
VI. 상태 비저장 프로세스
앱을 하나 이상의 상태 비저장 프로세스로 실행합니다.
애플리케이션은 “공유하지 않 음” 상태 비저장 프로세스로 실행되어야 합니다. 유지해야 하는 모든 데이터는 상태 저장 백업 서비스에 저장해야 합니다.
이 원칙은 빠른 수평 확장을 달성하고 상태 손실 없이 언제든지 프로세스를 시작하거나 중지할 수 있도록 하는 데 매우 중요합니다. Leapcell의 서버리스 서비스는 이를 염두에 두고 설계되어 상태 비저장 프로세스의 원활한 확장 및 관리를 가능하게 합니다.
VII. 포트 바인딩
포트 바인딩을 통해 서비스를 내보냅니다.
애플리케이션은 자체 포함되어 있어야 하며 포트에 바인딩하여 요청을 수신해야 합니다.
플랫폼은 외부 트래픽의 라우팅을 관리하기 위해 애플리케이션 구성에서 제공하는 포트를 사용합니다.
VIII. 동시성
프로세스 모델을 통해 확장합니다.
단일 프로세스를 더 강력하게 만드는 수직적 확장 대신 수평적 확장(더 많은 프로세스 추가)을 통해 증가된 부하를 처리합니다.
Leapcell의 서버리스 모드는 들어오는 트래픽을 기반으로 인스턴스를 자동으로 확장하여 최적의 리소스 활용률과 응답성을 보장하고 상태 비저장 프로세스 모델의 이점을 활용합니다.
IX. 폐기성
빠른 시작 및 정상 종료로 견고성을 최대화합니다.
프로세스는 폐기 가능해야 합니다. 즉, 언제든지 시작하거나 중지할 수 있어야 합니다.
Leapcell은 응답하지 않는 프로세스를 종료하기 위해 SIGKILL 신호를 보냅니다. 애플리케이션이 이 신호를 처리하고 종료하기 전에 필요한 정리를 수행하도록 구성할 수 있습니다.
X. 개발/프로덕션 패리티
개발, 스테이징 및 프로덕션을 최대한 유사하게 유지합니다.
환경 간의 격차를 좁히면 프로덕션에서만 나타나는 버그가 줄어듭니다.
개발 및 프로덕션을 위한 별도의 브랜치와 환경별 구성을 관리하기 위한
env.local파일과 함께 동일한 코드베이스를 사용하는 것이 좋습니다.
XI. 로그
로그를 이벤트 스트림으로 처리합니다.
애플리케이션은 로그 파일의 라우팅 또는 저장에 관여해서는 안됩니다. 대신 이벤트 스트림을 버퍼링되지 않은 상태로 표준 출력(stdout)에 기록해야 합니다.
Leapcell은 최신 로깅 인프라를 사용합니다. 모든 로그는 분석 및 모니터링을 위해 중앙 집중식 서비스로 전송되므로 다양한 기준에 따라 용어를 검색하거나 로그를 필터링할 수 있습니다.
XII. 관리 프로세스
관리/관리 작업을 일회성 프로세스로 실행합니다.
데이터베이스 마이그레이션과 같은 모든 관리 작업은 일회성 프로세스로 실행해야 합니다.
Leapcell은 현재 애플리케이션이 시작되기 전에 실행되는 사전 시작 명령을 제공하지 않습니다. 빌드 단계에서 이러한 작업을 실행하거나 시스템에서 수동으로 실행할 수 있습니다.