마이크로서비스 배포

-. 개발자가 운영 팀에게 코드를 일일이 넘겨주었던 수작업 과정은 고도로 자동화되고 물리적인 프로덕션 환경은 가볍고 일시적인 컴퓨팅 인프라로 대체되었습니다. 
-. AWS EC2 ⇢ 도커 릴리스 ⇢ AWS 람다 도입
-. 운영 환경에 사용되는 컴퓨팅 리소스 역시 물리 머신을 추상한 개념이 등장하면서 많은 변화를 겪게 되었고, AWS 등 고도로 자동화한 클라우드에 기반해 가상 머신은 수명이 긴 물리/가상 머신으로 빠르게 대체되었습니다. 
-. 현대에 이르러서 가상 머신은 불변 = Immutable 합니다. 재구성 = reconfiguration 하기보다 폐기 후 재생성 합니다. 
-. 배포 프로세스/아키텍처가 발전을 거듭한 것은 마이크로서비스 아키텍처가 점점 더 많이 채택되는 이유 입니다.
-.

프로덕션 환경의 4대 필수 기능

1. 서비스 관리 인터페이스 : 개발자가 서비스를 생성, 수정, 구성 할 수 있는 인터페이스를 제공합니다. CLI나 GUI 배포 툴에서 호출하는 REST API가 가장 좋습니다. 
2. 런타임 서비스 관리 : 서비스 인스턴스가 항상 적정한 개수만큼 실행되도록 합니다. 만약, 머신 자체가 깨질 경우, 서비스 인스턴스를 다른 머신에서 재시동해야 합니다. 
3. 모니터링 : 서비스가 무슨 일을 하고 있는지, 로그 파일 및 지표를 개발자가 관찰 할 수 있습니다. 
4. 요청 라우팅 : 사용자 요청을 서비스로 보냅니다. 

서비스 배포: 언어에 특정한 패키징 포맷 패턴 (레거시 방식)

언어에 특정한 패키지 형태로 프로덕션에 배포합니다. 
서비스를 프로덕션에 자동 배포하는 배포 파이프라인을 구축하는것이 좋습니다. 

자바 서비스 인스턴스는 JVM에서 실행되는 하나의 프로세스입니다. Node.js 서비스는 동시 처리를 위해 여러 개의 워커 프로세스를 파생시킬 수 있습니다. 과거에 무겁고 값비싼 애플리케이션 서버에서 자주 사용했던 애플리케이션 배포 방식입니다. 
-. 장점
-. 배포가 빠르다.
-. 리소스를 효율적으로 활용할 수 있습니다. (OS를 공유하므로)

-. 단점
-. 기술 스택을 캡슐화할 수 없습니다. (서비스 마다 사용한 언어/프레임워크가 다양하고 같은 언어/프레임워크라도 버전이 제각각입니다.)
-. 서비스 인스턴스가 소비하는 리소스를 제한할 방법이 없습니다. (한 프로세스가 전체 CPU/메모리를 다 소모하면 다른 서비스 인스턴스와 OS리소스는 기아에 허덕입니다.) 

서비스 배포 : 컨테이너 패턴

컨테이너는 격리된 샌드박스에서 하나 이상의 프로세스로 실행됩니다. 일반적으로 하나의 머신에 여러 컨테이너가 실행되고 컨테이너는 모두 동일한 OS를 공유합니다.

서비스를 컨테이너로 배포하는것입니다. 배포 파이프라인은 빌드 타임에 컨테이너 이미지 빌드 툴로 서비스 코드 및 이미지 디스크립션을 읽고 컨테이너 이미지를 생성합니다. 그 후 레지스트리에 보관합니다. 런타임에 레지스트리의 컨테이너 이미지를 당겨와서 컨테이너를 생성하게됩니다. 컨테이너 이미지로 패키징된 서비스는 레지스트리에 저장됩니다. 이렇게 저장된 이미즐 토대로 런타임에 여러 컨테이너가 인스턴스를 만들어서 서비스룰 구항하게 됩니다. 컨테이너는 가상머신에서 실행되고 하나의 VM이 여러 컨테이너를 실행하게 됩니다. 

서비스를 도커로 배포하고 이미지로 빌드 그리고 레지스트리에 푸시합니다. (*) 그리고 도커 컨테이너를 실행합니다.

컨테이너 패턴
장점
-. 기술 스택의 캡슐화가 가능합니다. 또, 서비스 관리 API가 곧 컨테이너 API가 됩니다.
-. 서비스 인스턴스가 격리됩니다.
-. 서비스 인스턴스의 리소스를 제한할 수 있습니다. 
단점
-. 컨테이너 이미지를 직접 관리해야 합니다.
-. OS와 런타임 패치도 정기적으로 해주어야 합니다.
-. 클라우드 서비스로 호스팅 하지 않으면 컨테이너 인프라 및 실행 기반의 VM인프라를 직접 관리해야 합니다.

애플리케이션 배포 : 쿠버네티스