12 Factors, +3

본 포스팅은 인프런
Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA)
강의를 기반으로 작성된 포스팅입니다.

Spring Cloud로 개발하는 마이크로서비스 애플리케이션(MSA) - 인프런 | 강의

 

---

12 Factors

Cloud Native Application을 구축하면서 고려해야할 12가지 항목이다.

12 Factors는 Cloud Service중 Platform as a Service(PaaS)라는 형태의

서비스를 제공하는 헤로크라는 개발회사에서 제공하는 열두가지 항목으로써

Cloud Native Application을 개발하거나

서비스를 운영할때 고려해야할 항목을 정리한것이다.

 

자사의 고객들을 상대로 Cloud Service시에  발생했었던 문제점과 개선점

시행착오등을 바탕으로 가이드 라인을 만들어 배포하였다.

많은 Cloud Native Application에서 이러한 가이드를 바탕으로

어플리케이션을 설계하고 개발, 운영하는데 사용하고 있다.

12 Factors

1. 코드 통합 Base Code

- 자체 레파지토리에 저장된 각 마이크로 서비스에 대한 단일 코드 베이스를 뜻한다.

   버전을 제어하기위한 목적이고 형상관리를 위해서 코드를 한곳에서 배포하는것이 주 목적이다.

   이후에 배포하기 위해서 개발환경, 스테이징, 프로덕션에 배포하기 위해서 코드의 통일적인 관리가

   필요하기 때문에 가장 중요한 항목으로 꼽힌다.

 

2. 종속성의 배제 DEPENDENCY ISOLATION

- 각 마이크로 서비스는 자체 종속성을 가지고 패키징 되어있어서

   전체 시스템에 영향을 주지 않는 상태에서 변경되고 내용을 수정할 수 있어야 한다. 

 

3. 환경설정의 외부 관리 CONFIGURATIONS

- 하드코딩 되어있는 설정정보가 아니라 시스템 코드 외부에서 구성관리 도구를 통해서

   마이크로 서비스에 필요한 작업들을 제어하는것. 동일한 배포가 올바른 구성이 적용된

   환경에서 전파될 수 있다.

 

4. 백업 서비스의 분리, 서비스 지원 LINKABLE BACKING SERVICES

- 보조서비스, 예를들어 DB, 캐시, 메세징 서비스, 브로커 등을 이용해서

   마이크로 서비스가 가져야할 기능들을 추가로 지원할 수 있는것을 말한다.

   응용 프로그램 자체에서 필요한 BACKING System Resource를

   분리하게 됨으로써 서로 상호가능한 서비스 자체를 Dependency를

   갖지 않는 상태에서 작업할 수 있게 된다.

 

5. 개발환경과 테스트 운영환경의 분리, Build Release and Run, STAGES OF CREATION

- 빌드, 릴리즈, 실행환경을 각각 분리하는것. 우리는 필요한 상태에 대해서

   개발 서버에서 만들어진 코드를 배포하기 위해서 실행단계까지 옮기는 과정을 

   엄격하게 분리하여야 한다. 각각은 고유한 아이디로 태그를 가지고 있어야 하고

   이전 상태로 돌아가는 롤백기능을 지원해야하며 CI / CD 시스템을 완벽하게 이용해서

   자동화된 시스템을 구축하는것이 좋다.

 

6. 상태관리 STATELESS PROCESS

- 각각의 마이크로 서비스는 실행중인 다른 서비스와 분리된채

   자체 프로세스에서 운영될 수 있어야 한다. 독립성과 일치하는 항목이다.

   하나의 마이크로 서비스는 다른쪽의 마이크로 서비스와 분리되어

   독립적으로 실행할 수 있는 상태여야 하고 필요한 자원이 있다면 

   캐시, 데이터 저장소등의 형태를 이용하여 외부와 데이터 동기화를 하면된다.

 

7. 포트 바인딩 PORT BINDING

- 각각의 마이크로 서비스는 자체 포트에서 노출되는 인터페이스 및 기능과 함께

   자체에 포함되어 있는 기능이 있어야 한다. 이렇게하면 다른 마이크로 서비스와 

   격리가 가능해진다. 

 

8. 동시성 CONCURRENCY

- 마이크로 서비스는 사용 가능한 가장 강력한 인스턴스 컴퓨터에서

   가장 큰 인스턴스로 확장하는것과는 반대로 아주 많은 수의 서비스

   동일한 프로세스를 복사해서 확장하게 된다.

   하나의 서비스가 여러가지 인스턴스에 동일한 형태로 복사되어

   운영됨으로써 부하분산을 이루어낸다.

   따라서 서비스가 여러 인스턴스에 나누어져 있기 때문에 동시성을 가져아한다.

 

9. 서비스의 올바른 상태유지 DISPOSABILITY

- 서비스 인스턴스 자체가 삭제 가능해야하며, 확장성 기회를 높여야하고

   정상적으로 종료할 수 있어야 한다. 컨테이너 가상화 도구로써 DOCKER등을

   사용한다면 서비스에 인스턴스를 등록하고 실행하고 삭제하는 과정을 쉽게할 수 있다.

 

10. 개발과 운영환경의 통일 DEVELOPMENT, PRODUCTION PARITY

- 개발 단계와 프로덕션 단계의 구분, 운영프로그램의 수명주기 전반에 걸쳐

   최대한으로 많은 서비스에 직접 Access하는 기능을 방지하여

   환경 자체를 최대한 다른쪽 서비스와 중복적이지 않고 종속적이지 않은 상태로써

   서비스를 유지할 수 있어야 한다.

 

11. 로그 분리 LOGS

- 로깅 시스템은 마이크로 서비스에 의해서 생성된 로그를

   이벤트 스트림으로 처리해야한다. 즉, 하나의 시스템 안에서 구성되고 있는

   로그를 출력하는 로직은 기존의 있었던 어플리케이션 로직과 분리되어

   어플리케이션이 실행되지 않는 상태여도 로그만은 정상적으로 작동되어야 한다.

   이러한 로그, 이벤트 집계를 사용하기 위해서는 별도의 추가적인 서비스 혹은

   모니터링 서비스를 사용할 수 있다.

 

12. 관리 프로세스 ADMIN PROCESSES FOR EVENTUAL PROCESSES

- 현재 운영되고 있는 모든 마이크로 서비스들을 어떤 상태로 사용되고 있으며

   리소스가 현재 어떻게 사용되고 있는지 파악하기 위한 적절한 관리도구가 필요하다.

   이러한 작업에는 리포팅 할 수 있는 기술이 포함되어 있어야 하고

   데이터 정리 및 분석하는 기능이 포함될 수 있다.

 

---

12 Factors + 3

이제는 12가지에서 3가지가 추가된 15가지의 요인에 대하여 고민하여야 될 수 있다.

 

1. API First

- 가지고 있는 모든 마이크로 서비스는 API 형태로 서비스가 제공된다.

   API를 구춤하에 있어서 사용자측에서 어떠한 형태로 쓸것인가를 먼저

   고민하여 개발해야 한다.

 

2. Telemetry

- 모든 지표는 수치화, 시각화되어 관리할 수 있는 항목이어야 한다.

 

3. Authentication and authorization

- API를 사용함에 있어서 인증 작업은 필수이다.

  비록 마이크로 서비스로 분리되어 있는 형태로 개발되어도

  적절한 인증을 가지고 있는 리소스, 서비스, 외부시스템 에서는

  데이터를 전달, 교환하는 것이 가능하여야 한다.