12-Factors
클라우드 네이티브 어플리케이션을 구축함에 있어 고려해야할 열 두가지 항목인 12 Factors에 대해 알아보자.
그럼 이제 이 열 두가지에 대해 하나씩 살펴보자.
12 Factors
1. 코드 통합 (Base Code)
자체 레포지토리에 저장된 각 마이크로 서비스에 대한 단일 코드 베이스(Git, SVN)를 뜻한다.
버전을 제어하기 위한 목적이고, 형상관리를 위해 코드를 한 곳에서 배포하는게 주 목적이다.
동일한 코드로 운영/개발에 배포하여야 한다.
중요도: 🌟
2. 종속성의 배제 (Dependency Isolation)
각 마이크로 서비스는 자체 종속성을 가지고 패키지 되어있어서, 전체 시스템에 영향을 주지 않은 상태로 변경되고 내용을 수정할 수 있어야 한다는 뜻이다.
중요도: 🌟🌟🌟
3. 환경설정의 외부 관리 (Configurations)
모든 설정 정보는 코드로부터 분리된 공간에 저장되어야 하고, 런타임에서 코드에 의해 읽혀야 한다.
이 때 설정정보란, 코드 안에 하드코드 되어있는 구성 설정정보가 아니라, 시스템 코드 외부에서 구성 관리 도구를 통해서 마이크로 서비스에 필요한 작업들을 제어하는 것을 이야기한다.
중요도: 🌟🌟
4. 백업 서비스의 분리 (Linkable Backing Services)
보조 서비스(데이터베이스, 캐시, 메시징 서비스, 브로커 등..)를 이용해 마이크로 서비스가 가져야할 기능들을 추가로 지원할 수 있다.
이렇게 프로그램 자체에서 필요한 Backing System Resource를 분리하게 됨으로써 code dependency를 갖지 않는 상태에서 작업할 수 있개 된다.
(예로 mysql을 사용하다가 app의 코드변경없이 설정변경만으로 oracle을 사용할 수 있어야 한다.)
중요도: 🌟🌟🌟
5. 개발 환경과 테스트 운영 환경의 분리 (Stages of Creation (Build, Release and Run))
코드 베이스는 build > release > run의 단계를 거쳐 배포로 변환되며, 각 단계는 엄격하게 분리되어야 한다.
각각은 고유한 아이디로 태그를 가지고 있어야 하고,
이전 상태로 돌아가는 롤백 기능을 지원해야하며,
CI/CD 시스템을 완벽하게 이용해서 자동화된 시스템을 구축하는게 좋다.
중요도: 🌟
6. 상태 관리 (Stateless Processes)
실행 환경에서 앱은 하나 이상의 프로세스로 실행되며, 각 프로세스는 stateless로 아무것도 공유하지 않아야 한다.
즉, 각각의 마이크로 서비스는 실행중인 다른 서비스와 분리된 채 자체 프로세스에서 운영될 수 있어야 한다.
이것은 이전에 배운 독립성과도 일치하는 항목이다.
하나의 마이크로 서비스는 다른 쪽에 있는 마이크로 서비스와 분리되어서 독립적으로 실행할 수 있는 상태여야 한다.
필요한 자원이 있다면, 캐시 혹은 데이터 저장소와 같은 형태를 이용해 외부와의 데이터 동기화를 통해 얻을 수 있다.
중요도: 🌟🌟🌟
7. 포트 바인딩 (Port Binding)
배포된 어플리케이션을 타 애플리케이션에서 접근할 수 있도록 포트 바인딩을 통해 서비스를 공개한다.
각각의 마이크로 서비스는 자체 포트에서 노출되는 인터페이스 및 기능과 함께 제체에 포함되어 있는 기능이 있어야 한다.
그러면 다른 마이크로 서비스와의 격리가 가능하기 때문이다.
중요도: 🌟🌟
8. 동시성 (Concurrency)
마이크로 서비스는 수평으로 확장할 수 있어야 한다.
즉, 사용 가능한 가장 큰 인스턴스로 확장하는 것과는 반대로, 아주 많은 수의 동일한 프로세스를 복사해 확장해나가게 된다.
동일한 서비스가 여러 인스턴스에 나뉘어서 서비스 되기 위해서 동시성을 가지고 있어햐 한다.
중요도: 🌟
9. 서비스의 올바른 폐기 가능 (Disposability)
프로세스는 shut down 신호를 받았을 때 graceful shut down 해야 한다.
또한 확장성 기회를 높여야하고, 정상적으로 종료할 수 있는 상태가 되어야 한다.
예를 들어 Scale down 시점에 graceful shut down 이 아니라면 db lock 등으로 인해 타 프로세스에 영향을 주게 된다.
만약, 컨테이너 가상화 기술로써 도커라던가 Containderd 라던가 CRI-O 등을 사용한다고 하면,
서비스에 인스턴스를 등록하고 실행하고 삭제하는 작업을 쉽게 할 수 있다.
중요도: 🌟🌟
10. 개발과 운영환경의 통일 (Development & Production Parity)
development, staging, production 환경을 최대한 비슷하게 유지한다.
개발 환경과 production 환경의 차이를 작게 유지하여 지속적인 배포가 가능하도록 디자인되어야 한다.
중요도: 🌟🌟
11. 로그의 분리 (Logs)
마이크로 서비스에 의해 생성된 로그를 이벤트 스트림으로 취급하여 로그를 로컬에 저장하지 않는다.
즉, 하나의 시스템 안에서 구성되고 있는 로그를 출력하는 로직은 기존에 사용한 어플리케이션 로직과 분리되어
어플리케이션이 실행되지 않는 상태라고 하더라도 로그만은 정상적으로 작동할 수 있는 상태여야 한다.
이러한 이벤트 집계를 사용하기 위해서는 별도의 추가적인 모니터링 도구를 사용할 수도 있다.
예를 들어, Azure(MicroSoft 제공), Data Mining(Splunk 제공), ELK(ElasticSearch 제공) 등을 이용해
장기적으로 보관되고 있는 로그를 분석할 수도 있다.
12. 관리 프로세스 (Admin Processes for Eventual Processes)
admin/maintenance 작업을 일회성 프로세스로 실행해야 한다.
현재 운영되고 있는 모든 마이크로 서비스들을 어떤 상태로 사용되고 있으며, 리소스는 어떻게 쓰고있는지에 대해 파악하기 위한 적절한 관리 도구가 있어야 한다.
이러한 작업에는 reporting 할 수 있는 기술이 포함되어 있어야 하고, 데이터 정리/분석 기능이 포함될 수 있다.
중요도: 🌟🌟🌟
12 Factors + 3
최근에는 12 factors에 3개의 항목을 더해 피보탈이라는 클라우드 회사가 발표하기도 했다.
1. API 우선 (API first)
가지고 있는 모든 마이크로 서비스는 API 형태로 제공된다.
클라우드용으로 개발된 어플리케이션은 일반적으로 분산 서비스 에코시스템의 참여자이며,
API가 명확하게 정의되지 않으면 통합 실패의 악몽으로 이어질 수 있다.
따라서 클라우드에서 번창하는 애플리케이션을 설계할 때 이 요소가 중요하다.
또한 API를 구축함에 있어서 사용자 측에서 어떠한 형태로 쓸 것이가를 고민해 개발해야 한다.
2. 원격 측정 (Telemetry)
모든 지표는 수치화/시각화 돼서 관리할 수 있어야하는 항목이어야 한다.
🤔 Loggin 과 Telemetry의 차이?
원래 12개 요소 앱 방법론에 이미 포함된 로깅 요소 외에 원격 분석이 자체 요소로 필요한 이유에 대해 질문할 수 있다.
로깅은 클라우드 네이티브 애플리케이션을 구축하는 데 중요한 요소이지만 일반적으로 개발 중에 오류 및 코드 흐름을 진단하는 데 사용되는 도구이다.
로깅은 일반적으로 실제 고객 사용을 반영하기보다는 앱의 내부 구조를 중심으로 한다.
반면, 원격 측정은 앱이 출시되면 데이터 수집에 중점을 둔다.
원격 측정 및 실시간 앱 모니터링을 통해 개발자는 복잡하고 고도로 분산된 환경에서 애플리케이션의 성능, 상태 및 주요 메트릭을 모니터링할 수 있다.
3. 인증 및 권한 부여 (Authentication and authorization)
인증 및 권한 부여 요소 의 추가는 클라우드 네이티브 애플리케이션의 보안에 대한 중요한 강조를 추가한다.
클라우드 환경에서 애플리케이션을 배포한다는 것은,
애플리케이션을 전 세계의 많은 데이터 센터에서 전송하고, 여러 컨테이너 내에서 실행하고, 거의 무제한의 클라이언트에서 액세스할 수 있음을 의미한다.
따라서 보안은 클라우드 네이티브 어플리케이션에 대한 사후 고려 사항이 아니며 고려해야 할 매우 중요한 요소라는 것이다.
💛 개인 공부 기록용 블로그입니다. 👻