Practice DevOps!
• 코드베이스(codebase): 모든 애플리케이션 코드와 서버 프로비저닝(provisioning) 정보는 버전 관 리(version control)되어야 한다. 각 마이크로서비스는 소스 제어 시스템 안에 독립적인 코드 저장소 를 가져야 한다.
• 의존성(dependencies): 애플리케이션이 사용하는 의존성을 메이븐(자바) 같은 빌드 도구를 이용해 명시적으로 선언해야 한다. 제3자(3 rd party)의 JAR 의존성은 특정 버전 번호를 붙여 명시해 선언해 야 한다. 따라서 동일 버전의 라이브러리를 사용해 항상 마이크로서비스를 빌드할 수 있다.
• 구성(config): 애플리케이션 구성(특히 환경별 구성)을 코드와 독립적으로 저장하자. 애플리케이션 구성은 절대로 소스 코드와 동일한 저장소에 있으면 안 된다.
• 백엔드 서비스(backing services): 마이크로서비스는 대개 네트워크를 거쳐 데이터베이스나 메시징 서비스와 통신한다. 그렇다면 언제든 데이터베이스 구현을 자체 관리형 서비스에서 외부업체 서비스 로 교체할 수 있어야 한다. 10장에서 로컬에서 관리되는 Postgres 데이터베이스를 AWS 데이터베 이스로 옮기면서 이를 보여 준다.
• 빌드, 릴리스, 실행(build, release, run): 배포할 애플리케이션의 빌드, 릴리스, 실행 부분을 철저히 분리하라. 코드가 빌드되면 개발자는 실행 중에 코드를 변경할 수 없다. 모든 변경 사항을 빌드 프로 세스로 되돌려 재배포해야 한다. 빌드된 서비스는 불변적이므로(immutable) 변경할 수 없다.
• 프로세스(processes): 마이크로서비스는 항상 무상태(stateless) 방식을 사용해야 한다. 서비스 인 스턴스 손실에 의해 데이터가 손실될 것이라는 우려 없이 언제든 서비스를 강제 종료하거나 교체할 수 있다.
• 포트 바인딩(port binding): 마이크로서비스는 서비스용 런타임 엔진을 포함한(실행 파일에 패키징 된 서비스를 포함한) 완전히 자체 완비형이다. 별도의 웹 또는 애플리케이션 서버 없이도 서비스는 실 행되어야 한다. 서비스는 명령행에서 단독으로 시작하고 노출한 HTTP 포트를 통해 즉시 액세스할 수 있어야 한다.
• 동시성(concurrency): 확장해야 한다면 단일 서비스 안에서 스레드 모델에 의존하지 마라. 그 대신 더 많은 마이크로서비스를 시작하고 수평 확장하라. 마이크로서비스 안에서 스레드 사용을 배제하지 는 않지만 확장을 위한 유일한 메커니즘으로 믿지 말라. 수직 대신 수평 확장하라.
• 폐기 가능(disposability): 마이크로서비스는 폐기 가능하므로 요구에 따라 시작 및 중지할 수 있다. 시작 시간은 최소화하고 운영 체제에서 강제 종료 신호(kill signal)를 받으면 프로세스는 적절히 종료 (gracefully shut down)해야 한다.
• 개발 및 운영 환경 일치(dev/prod parity): 서비스가 실행되는 모든 환경(개발자의 데스크톱 환경도 포함) 사이의 차이를 최소화하라. 개발자는 서비스 개발을 위해 실제 서비스가 실행되는 동일한 인프 라스트럭처를 로컬에 사용해야 한다. 이는 환경 간 서비스 배포가 수 주가 아닌 수 시간 안에 이루어 져야 한다는 것을 의미한다. 코드가 커밋되자마자 테스트되고 가능한 신속하게 개발 환경에서 운영 환경으로 전파되어야 한다.
• 로그(logs): 로그는 이벤트 스트림이다. 로그가 기록될 때 스플렁크(Splunk, http://splunk.com)나 Fluentd (http://fluentd.org) 같은 도구로 로그가 스트리밍되어야 한다. 이들 도구는 로그를 수집 해 중앙에 기록한다. 마이크로서비스는 이러한 로깅 동작 방식에 신경 쓰지 않아야 하며, 개발자는 표 준 출력(stdout)으로 출력된 로그를 시각적으로 확인할 수 있어야 한다.
• 관리 프로세스(Admin processes): 개발자는 종종 담당 서비스에 대해 데이터 마이그레이션이나 변 환처럼 관리 작업을 수행해야 한다. 이러한 작업은 임의로 수행되면 안 되고 소스 코드 저장소에 유지 및 관리되는 스크립트에 의해 수행되어야 한다. 이 스크립트는 실행될 각 환경에 반복적으로 수행 가 능하고 환경을 위해 변경되지 않아야 한다. 즉, 각 환경에 맞추어 스크립트를 수정하지 않는다
Referenced by
스프링_마이크로서비스_코딩_공작소
허로쿠의 Twelve-Factor 애플리케이션 선언(Heroku’s Twelve-Factor Application manif esto, https://12factor.net/)
• 코드베이스(codebase): 모든 애플리케이션 코드와 서버 프로비저닝(provisioning) 정보는 버전 관 리(version control)되어야 한다. 각 마이크로서비스는 소스 제어 시스템 안에 독립적인 코드 저장소 를 가져야 한다.
• 의존성(dependencies): 애플리케이션이 사용하는 의존성을 메이븐(자바) 같은 빌드 도구를 이용해 명시적으로 선언해야 한다. 제3자(3 rd party)의 JAR 의존성은 특정 버전 번호를 붙여 명시해 선언해 야 한다. 따라서 동일 버전의 라이브러리를 사용해 항상 마이크로서비스를 빌드할 수 있다.
• 구성(config): 애플리케이션 구성(특히 환경별 구성)을 코드와 독립적으로 저장하자. 애플리케이션 구성은 절대로 소스 코드와 동일한 저장소에 있으면 안 된다.
• 백엔드 서비스(backing services): 마이크로서비스는 대개 네트워크를 거쳐 데이터베이스나 메시징 서비스와 통신한다. 그렇다면 언제든 데이터베이스 구현을 자체 관리형 서비스에서 외부업체 서비스 로 교체할 수 있어야 한다. 10장에서 로컬에서 관리되는 Postgres 데이터베이스를 AWS 데이터베 이스로 옮기면서 이를 보여 준다.
• 빌드, 릴리스, 실행(build, release, run): 배포할 애플리케이션의 빌드, 릴리스, 실행 부분을 철저히 분리하라. 코드가 빌드되면 개발자는 실행 중에 코드를 변경할 수 없다. 모든 변경 사항을 빌드 프로 세스로 되돌려 재배포해야 한다. 빌드된 서비스는 불변적이므로(immutable) 변경할 수 없다.
• 프로세스(processes): 마이크로서비스는 항상 무상태(stateless) 방식을 사용해야 한다. 서비스 인 스턴스 손실에 의해 데이터가 손실될 것이라는 우려 없이 언제든 서비스를 강제 종료하거나 교체할 수 있다.
• 포트 바인딩(port binding): 마이크로서비스는 서비스용 런타임 엔진을 포함한(실행 파일에 패키징 된 서비스를 포함한) 완전히 자체 완비형이다. 별도의 웹 또는 애플리케이션 서버 없이도 서비스는 실 행되어야 한다. 서비스는 명령행에서 단독으로 시작하고 노출한 HTTP 포트를 통해 즉시 액세스할 수 있어야 한다.
• 동시성(concurrency): 확장해야 한다면 단일 서비스 안에서 스레드 모델에 의존하지 마라. 그 대신 더 많은 마이크로서비스를 시작하고 수평 확장하라. 마이크로서비스 안에서 스레드 사용을 배제하지 는 않지만 확장을 위한 유일한 메커니즘으로 믿지 말라. 수직 대신 수평 확장하라.
• 폐기 가능(disposability): 마이크로서비스는 폐기 가능하므로 요구에 따라 시작 및 중지할 수 있다. 시작 시간은 최소화하고 운영 체제에서 강제 종료 신호(kill signal)를 받으면 프로세스는 적절히 종료 (gracefully shut down)해야 한다.
• 개발 및 운영 환경 일치(dev/prod parity): 서비스가 실행되는 모든 환경(개발자의 데스크톱 환경도 포함) 사이의 차이를 최소화하라. 개발자는 서비스 개발을 위해 실제 서비스가 실행되는 동일한 인프 라스트럭처를 로컬에 사용해야 한다. 이는 환경 간 서비스 배포가 수 주가 아닌 수 시간 안에 이루어 져야 한다는 것을 의미한다. 코드가 커밋되자마자 테스트되고 가능한 신속하게 개발 환경에서 운영 환경으로 전파되어야 한다.
• 로그(logs): 로그는 이벤트 스트림이다. 로그가 기록될 때 스플렁크(Splunk, http://splunk.com)나 Fluentd (http://fluentd.org) 같은 도구로 로그가 스트리밍되어야 한다. 이들 도구는 로그를 수집 해 중앙에 기록한다. 마이크로서비스는 이러한 로깅 동작 방식에 신경 쓰지 않아야 하며, 개발자는 표 준 출력(stdout)으로 출력된 로그를 시각적으로 확인할 수 있어야 한다.
• 관리 프로세스(Admin processes): 개발자는 종종 담당 서비스에 대해 데이터 마이그레이션이나 변 환처럼 관리 작업을 수행해야 한다. 이러한 작업은 임의로 수행되면 안 되고 소스 코드 저장소에 유지 및 관리되는 스크립트에 의해 수행되어야 한다. 이 스크립트는 실행될 각 환경에 반복적으로 수행 가 능하고 환경을 위해 변경되지 않아야 한다. 즉, 각 환경에 맞추어 스크립트를 수정하지 않는다
Referenced by
스프링_마이크로서비스_코딩_공작소
허로쿠의 Twelve-Factor 애플리케이션 선언(Heroku’s Twelve-Factor Application manif esto, https://12factor.net/)
댓글
댓글 쓰기