기본 콘텐츠로 건너뛰기

4월, 2020의 게시물 표시

AWS Architecture of Micro service

마이크로 서비스 프로젝트에서 사용한 AWS서비스를 아키텍쳐로 구성하여 나타냄. 사용한 서비스(Used services) VPC : 네트워크 설정 (NAT, Subnet etc) ECS : 컨테이너 EC2 : 컴퓨팅(서버) ECR : 컨테이너 (Registry) 아키텍쳐(Architecture) ---End

Twelve-Factor 마이크로서비스 서비스 애플리케이션 구축

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): 마이크로서비스는 서비스용 런타임 엔진을 포함한(실행 파일에 패키징 된 서비스를 포