Twelve-Factor: 마이크로서비스를 위한 앱 조정
Twelve-Factor 앱은 유용한 웹 애플리케이션을 만들기 위한 일반적인 원칙을 확립하기 위해 PaaS 제공업체인 Heroku의 노력으로 알려져 있습니다.
그러나 이 원칙은 Heroku의 PaaS 플랫폼에 특화되어 있습니다. 마이크로서비스 아키텍처에 완벽하게 적합하지 않습니다.
NGINX MRA를 구현하면서 NGINX는 Twelve-Factor 애플리케이션을 수정하여 마이크로서비스에 적합하게 확장했습니다.
수정된 버전은 매우 유용하다는 것을 알게 되었습니다.
예를 들어 Twelve‑Factor 앱은 구성 코드가 구성 파일이 아닌 환경 변수에 저장되도록 지정합니다. 이는 구성 코드와 사용하는 NGINX Plus 서버의 수만 다른 세 가지 모델이 있는 MRA에 매우 유용한 원칙입니다.
이러한 내용을 바탕으로 NGINX 마이크로서비스 실수팀은 다음과 같은 원칙 세트를 개발했습니다.
NGINX의 원칙 세트는 Twelve-Factor 애플리케이션의 핵심 아이디어를 지속적인 전달에 최적화된 범용 마이크로서비스 아키텍처에 적용합니다.
목차
1. 마이크로서비스에 적용되는 Twelve-Factor
1-1. Twelve-Factor – 코드베이스
1-2. Dependencies
1-3. Twelve-Factor -구성
1-4. Twelve-Factor – 지원 서비스
1-5. Twelve-Factor – Build, Release, Run
1-6. 프로세스
1-7. 데이터 격리
1-8. 동시성
1-9. 일회용
1-10. 개발/생산 parity
1-11. Twelve-Factor Log
1-12. Twelve-Factor 관리 프로세스
2. 결론
1. 마이크로서비스에 적용되는 Twelve-Factor
1-1. Twelve-Factor – 코드베이스
계정 관리에서 추적되는 서비스당 하나의 코드베이스 배포
Twelve-Factor App은 앱 당 하나의 코드베이스를 권장합니다. 그러나 마이크로서비스 아키텍처에서는 올바른 접근 방식은 실제로 각 서비스 당 하나의 코드베이스입니다. 또한, 우리는 Git을 저장소로 사용하는 것을 강력히 권장합니다. Git은 다양한 기능 세트와 거대한 생태계로 인해 많은 사람들에게 선택되고 있습니다. GitHub는 오픈 소스 커뮤니티에서 기본 Git 호스팅 플랫폼이 되었지만, 조직의 요구에 따라 다른 많은 우수한 Git 호스팅 옵션이 있습니다.
1-2. Dependencies
종속성을 명시적으로 선언하고 격리
The Twelve-Factor App에서 제안한 대로, 애플리케이션이 실행되는 플랫폼에 관계없이 해당 언어나 프레임워크에 포함된 Dependency manager를 사용하세요. 운영 체제나 플랫폼 의존성을 설치하는 방법은 플랫폼에 따라 다릅니다.
- 컨테이너화되지 않은 환경에서는 구성 관리 도구(Chef, Puppet, Ansible)를 사용하여 시스템 의존성을 설치하세요.
- 컨테이너화된 환경에서는 Dockerfile에서 이 작업을 수행하세요.
참고: 의존성 관리 메커니즘을 단독적인 결정으로 선택하는 것이 아니라 포괄적인 Infrastructure‑as‑Code 전략의 일환으로 선택하는 것을 권장합니다.
1-3. Twelve-Factor -구성
환경에 구성 저장
배포 간에 다른 사항은 모두 구성으로 간주할 수 있습니다. Twelve-Factor App 가이드라인은 모든 구성을 저장소에 커밋하는 대신 환경에 저장하는 것을 권장합니다. 다음과 같은 구체적인 관행을 권장합니다:
- 로컬 개발을 위해 버전 관리되지 않는 .env 파일을 사용하세요. Docker는 이러한 파일을 런타임에 로드하는 기능을 지원합니다.
- 모든 .env 파일을 보안이 유지되는 저장 시스템(예: Vault)에 보관하여 개발 팀에서 파일에 액세스할 수 있지만 Git에 커밋되지 않도록 유지하세요.
- 런타임에 변경될 수 있는 모든 사항과 공유 저장소에 커밋되지 않아야 하는 비밀에 대해서는 환경 변수를 사용하세요.
- 애플리케이션을 배포한 후에는 배포 플랫폼의 환경 변수 관리 메커니즘을 사용하세요.
1-4. Twelve-Factor – 지원 서비스
지원 서비스를 연결된 리소스로 처리
Twelve-Factor App 가이드라인에서는 백엔드 서비스를 “앱이 정상적인 작동의 일부로 네트워크를 통해 사용하는 모든 서비스”로 정의합니다. 마이크로서비스에 대한 함의는 서비스 외부의 모든 것을 연결된 리소스로 취급한다는 것입니다. 이는 모든 서비스가 완전히 이식 가능하며 시스템의 다른 리소스와 느슨하게 결합되도록 보장합니다. 또한, 엄격한 분리는 개발 중에 유연성을 높입니다. 개발자는 수정하는 서비스만 실행하면 되며 다른 서비스는 실행할 필요가 없습니다.
1-5. Twelve-Factor – Build, Release, Run
엄격하게 분리된 빌드 및 실행 단계
The Twelve-Factor App에서 권장하는 대로 빌드, 릴리스 및 실행 단계의 엄격한 분리를 지원하기 위해 CI/CD(지속적 통합/지속적 전달) 도구를 사용하여 빌드를 자동화하는 것을 권장합니다. Docker 이미지를 사용하면 빌드와 실행 단계를 쉽게 분리할 수 있습니다. 이상적으로는 모든 커밋에서 이미지를 생성하고 배포 Artifacts로 취급합니다.
1-6. 프로세스
하나 이상의 상태 비저장 프로세스에서 앱 실행
마이크로서비스에서 “프로세스” 요소에서 중요한 점은 애플리케이션이 상태를 가지지 않아야 한다는 것입니다. 이렇게 하면 해당 서비스의 인스턴스를 추가함으로써 서비스를 수평으로 확장하기가 쉬워집니다. 상태를 가지는 데이터나 인스턴스 간에 공유되어야 하는 데이터는 백엔드 서비스에 저장하세요.
1-7. 데이터 격리
각 서비스가 자체 데이터를 관리
마이크로서비스에 대해 Port binding 요소를 보다 유용하게 만들기 위한 수정으로, 우리는 각 서비스의 API를 통해서만 해당 서비스가 소유한 영속적인 데이터에 액세스할 수 있도록 권장합니다. 이렇게 함으로써 마이크로서비스 간에 암묵적인 서비스 계약을 방지하고 마이크로서비스가 서로 강하게 결합되지 않도록 보장합니다. 데이터 격리는 개발자가 각 서비스에 가장 적합한 데이터 저장소 유형을 선택할 수 있도록 합니다.
1-8. 동시성
프로세스 모델을 통해 Scale-Out
유닉스 프로세스 모델은 주로 Monolith 애플리케이션 내에서 다른 작업에 대한 특화 및 리소스 공유를 허용하여 진정한 마이크로서비스 아키텍처의 선구자입니다. 마이크로서비스 아키텍처에서는 각 서비스를 기반 인프라가 지원하는 한도 내에서 독립적으로 수평으로 확장할 수 있습니다. 컨테이너화된 서비스를 사용하면 Twelve-Factor App에서 권장하는 동시성을 무료로 얻을 수 있습니다.
1-9. 일회용
빠른 시작과 원활한 종료를 통해 견고성 극대화
서비스의 인스턴스는 빠르게 시작, 중지 및 재배포할 수 있어야 하며 데이터 손실 없이 이루어져야 합니다. Docker 컨테이너에 배포된 서비스는 이 요구 사항을 자동으로 충족시킵니다. 컨테이너는 즉시 중지 및 시작할 수 있는 내재적인 기능을 가지고 있기 때문입니다. 상태나 세션 데이터를 큐나 다른 백엔드 서비스에 저장함으로써 컨테이너 충돌 시 요청이 원활하게 처리되도록 할 수 있습니다. 또한, 충돌 전용 디자인을 지원하기 위해 백엔드 스토어를 사용하는 것을 권장합니다.
1-10. Dev/Prod parity
개발, 스테이징 및 프로덕션을 최대한 유사하게 유지
개발, 스테이징, 프로덕션 등 모든 환경을 가능한 한 동일하게 유지하여 버그가 특정 환경에서만 발생하는 위험을 줄이세요. 이 원칙을 지원하기 위해 NGINX는 다시 한 번 컨테이너의 사용을 권장합니다. 컨테이너는 로컬 개발부터 프로덕션까지 완전히 동일한 실행 환경을 제공하는 강력한 도구입니다. 그러나 기반 데이터의 차이로 인해 실행 환경에서 여전히 차이가 발생할 수 있다는 점을 염두에 두세요.
1-11. Twelve-Factor Log
Log를 Event Stream으로 처리
마이크로서비스에서 라우팅이나 로그 저장을 위해 코드를 포함하는 대신, Twelve-Factor App에 명시된 여러 우수한 로그 관리 솔루션 중 하나를 사용하세요. 또한, 로그 처리 방식을 결정하는 것은 더 큰 APM 및/또는 PaaS 전략의 일부여야 합니다.
1-12. Twelve-Factor 관리 프로세스
관리 및 관리 작업을 일회성 프로세스로 실행
운영 환경에서는 관리 및 유지보수 작업을 앱과 별도로 실행하세요. 컨테이너를 사용하면 이를 매우 쉽게 수행할 수 있습니다. 작업을 실행하기 위해 컨테이너를 시작하고 작업이 완료되면 종료할 수 있습니다.
2. 결론
Twelve-Factor App과 이러한 추가 원칙을 사용하여 지속적인 전달에 최적화된 견고한 마이크로서비스 기반 앱을 만드는 데 도움을 받으세요. 또한, MRA는 처음부터 시작해야 하는 것보다 더 빠르고 더 멀리 나아갈 수 있도록 도와주는 치트 코드와 같습니다.
NGINX Plus를 시도해 보려면 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하기 위해 NGINX STORE에게 문의하세요.
아래 뉴스레터를 구독하고 NGINX와 NGINX STORE의 최신 정보들을 빠르게 전달 받아보세요.
