⭐ 허로쿠의 Twelve-Factor 마이크로서비스 애플리케이션 구축
데브옵스 문화에서 성공적으로 마이크로서비스 애플리케이션 개발을 하기 위해 12가지 지침을 명심해야 한다.
✔️ 코드베이스(CodeBase)
모든 애플리케이션 코드와 서버 프로비저닝(Provisioning) 정보는 버전 관리(Version-Conrol)되어야 한다. 각 마이크로서비스는 소스 제어 시스템 안에 독립적인 코드 레포지터리를 가져야 한다.
✔️ 의존성(Dependencies)
애플리케이션이 사용하는 의존성을 메이븐, 그레이들 같은 빌드 도구를 이용해 명시적으로 선언해야 한다. 3rd party의 JAR 의존성은 특정 버전 번호를 붙여 명시적으로 선언해야 한다. 따라서 동일 버전의 라이브러리를 사용해 마이크로서비스를 빌드할 수 있다.
✔️ 구성(Config)
애플리케이션 구성을 코드와 독립적으로 저장해야 한다. 애플리케이션 구성은 절대 소스 코드와 동일한 레포지터리에 두지 않는다.
✔️ 백킹 서비스(Backing Services)
일반적으로 마이크로서비스는 네트워크를 거쳐 데이터베이스나 메시징 서비스와 통신한다. 따라서 언제든 DB 구현을 자체 관리형 서비스에서 외부업체 서비스로 교체할 수 있어야 한다. (JPA)
✔️ 빌드, 릴리스, 실행 (Build, Release, Run)
배포할 애플리케이션의 빌드, 릴리스, 실행 부분을 철저히 분리하여야 한다. 코드가 빌드되면 개발자는 실행 중에 코드를 변경할 수 없다. 모든 변경 사항을 빌드 프로세스로 되돌려 재배포해야 한다. 빌드된 서비스는 불변적이므로 변경할 수 없다.
✔️ 프로세스(Processes)
마이크로서비스는 항상 무상태 (Stateless) 방식을 사용해야 한다. 서비스 인스턴스 손실에 의해 데이터가 손실될 것이라는 우려 없이 언제든 서비스를 강제 종료하거나 교체할 수 있다.
✔️ 포트 바인딩(Port Binding)
마이크로서비스는 서비스용 런타임 엔진을 포함한 (실행 파일에 패키징된 서비스를 포함한) 완전히 자체 완비형이다. 따라서 별도의 웹 또는 애플리케이션 서버 없이도 서비스는 실행되어야 하며, 서비스는 명령행에서 단독으로 시작하고 노출한 HTTP 포트를 통해 즉시 액세스할 수 있어야 한다.
✔️ 동시성(Concurrency)
확장해야 한다면 수직 확장이 아닌 수평 확장해라. 단일 서비스 스레드 모델에 의존하는 대신 마이크로서비스의 수를 늘려라.
✔️ 폐기 가능(Disposability)
마이크로서비스는 폐기 가능하므로 요구에 따라 시작 및 중지할 수 있다. 시작 시간은 최소화하고 운영 체제에서 강제 종료(Kill Signal)를 받으면 프로세스는 적절히 종료해야 한다.
✔️ 개발 및 운영 환경 일치(Dev/Prod Parity)
서비스가 실행되는 모든 환경(로컬 환경까지도)을 통일시킬 것. 서비스 개발을 위해 실제 서비스가 실행되는 동일한 Infra Structure를 로컬에 사용해야 한다. 코드가 커밋되자마자 테스트되고 가능한 신속하게 개발 환경에서 운영 환경으로 전파되어야 하기 때문이다.
✔️ 로그(Logs)
로그인 이벤트 스트림을 뜻한다. 마이크로서비스는 어떤 툴이 되었건 로깅 동작 방식에 신경 쓰지 않아야 하며, 개발자는 표준 출력 (stdout)으로 출력된 로그를 시각적으로 확인할 수 있어야 한다.
✔️ 관리 프로세스(Admin Processes)
데이터 마이크레이션과 같은 작업 수행은 임의로 수행되면 안 되고 소스 코드 저장소에서 관리되는 스크립트에 의해 수행되어야 한다. 그리고 이 스크립트는 반복적으로 수행 가능하여야 하며 환경에 맞추어 그때그때 수정되어선 안된다.
