마이크로서비스 5개 배포 원칙

마이크로서비스 5개 배포 원칙

실행 격리 Isolated execution

부하가 발생하거나 배포를 할 때 마이크로서비스 간에 영향을 주면 안된다.
예를 들어 하나의 호스트에서 여러 마이크로서비스를 실행하게 되면 어떠한 서비스의 부하가 증가하게 되는 순간 다른 마이크로서비스들이 다 같이 성능이 저하되거나 혹은 마이크로서비스 배포를 위해서 리눅스 os 설정 등을 변경하게 되면 다른 마이크로서비스 배포에 영향을 준다거나 이런 상태를 해결하기 위해 마이크로서비스는 서로 격리된 환경에서 실행되어야 한다.

가상화 기술, 컨테이너, FaaS 등을 사용하면 격리가 쉬워진다.

물리적 장비를 사용하면 강하게 격리를 할 수 있고, 컨테이너를 사용하면 상대적으로 빠르게 격리를 할 수 있다.

자동화에 초점 Focus on automation

마이크로서비스가 많아질수록 복잡해진다. 더 많은 절차, 더 많은 설정, 더 많은 모니터링 대상이 생긴다. 그렇게 되면 운영하는데 부하도 증가하게 되고, 개발하는 시간만큼 운영하는데 들어가는 시간도 늘어난다. 그래서 운영 부하를 감소하기 위해서 자동화하는데 초점을 맞춰야한다. 자동화하지를 않으면 성장에 빠르게 대응할 수가 없다.

그리고 중요한 것은 개발자가 직접 인프라 서비스를 제공할 수 있어야 하는 조직의 문화나 규칙이 필요하다. 개발자가 원하는 시간이나 상황에 컨테이너를 만들고 배포할 수 있는 상황이 되지 않으면 생산성이 떨어지게 될 것이다.

코드형 인프라 Infrastructure as code

인프라스트럭처를 코드로 정의하는 것이다. 코드형 인프라는 자동화를 구현하는 한 가지 방법이다. 보통 텍스트형식으로 인프라스트럭처를 설정파일 형태로 정리하니 버전관리도 가능해지고, 잘못 설정했을 때 복구하는 것도 상대적으로 쉬워진다.

클라우드 환경이 점점 보편화 되어가고 있어서 Terraform, Pulumi 등의 특화된 도구를 사용하게 되고, 클라우드나 컨테이너가 확대되다 보니 Puppet 이나 Ansible 같은 도구의 사용은 감소세이다.

Pulumi 는 코드로 인프라스트럭처를 정의할 수 있는 도구이다.

무중단 배포 Zero-downtime deployment

마이크로서비스에서 개발 및 배포할 때 무중단 배포는 필수이다. 배포나 출시를 위해서 마이크로서비스를 사용하는 팀 혹은 사용자에게 통지하지 않고 출시하는 것이 중요하다. 출시를 위해 사용자와 통지하고 일정을 협의하고 이런 과정은 최대한 제거하는 것이다. 또한 독립적 배포를 위해서라도 무중단 배포는 필요하다.

기대 상태 관리 Desired state management

마이크로서비스에 대해 기대하는 상태를 관리할 수 있는 수단이 필요하다. 개발자의 개입없이 인프라스트럭처를 원하는 상태로 유지할 수 있는 상태를 가져야 한다.

예를 들어 최소 세 개의 인스턴스가 실행 중이어야 한다. 그러면 마이크로서비스 인스턴스 세 개 중에 하나가 죽었을 때 자동으로 3개를 맞춰주는 것이다.

혹은 다른 예로 CPU 부하가 50% 이상 증가하면 인스턴스를 자동으로 한 개 더 늘린다. 부하가 증가할 때 자동으로 스케일아웃이 된다던가 이러한 것들이 필요하다.

이렇듯 개발자의 개입없이 기대하는 상태를 유지할 수 있는 방법을 강구해야한다. 이를 지원하는 도구는 많이 있고, 직접 코드로 구현하는 것도 방법이다.

참고자료

Building Microservices