마이크로서비스의 원칙#
마이크로서비스의 원칙 정의#
비지니스 개념에 따른 모델#
시스템이 동작하는 도메인을 모델링함으로써 더 안정적인 인터페이스를 형성하려 할 뿐만 아니라 비지니스 프로세스의 변경을 쉽게 할수 있다. 잠재적인 도메인 경계를 정의하기 위해서는 경계가 있는 콘텍스트를 이용하자.
자동화 문화의 적용#
마이크로서비스의 경우, 변경되는 부분과 복잡도가 올라가게 된다. 자동화 문화는 이점을 처리하는 핵심 이슈고, 마이크로서비스 지원을 하는 도구 지원을 하자. 서비스들의 동작을 보장하는 방법 또한 모놀리식 시스템에 비해 복잡도가 높으므로 자동화는 필수가 된다. 일괄된 명령행 호출로 * 어디에서나 같은 방식으로 배포*하고, *지속적 배포*에도 귀결된다. 따라서 환경변수 등의 배포 환경의 차이를 없애고, 완전 자동화된 서버를 구축하자.
내부 세부 구현의 은폐#
서비스 대 서비스 간 독립적으로 개발을 극대화하기 위해 세부 구현을 은폐하는건 필수적이다. 경계가 있는 콘텍스트*로 모델링하는 것은 공유되고 은폐되어야 하는 모델에 좋다. 전통적인 서비스 지향 아키텍처에서 발생하는 흔한 문제인 결합의 문제에 주의하여 *데이터베이스도 감추자. 리포팅 목적으로 여러 서비스들로부터 데이터를 통합하기 위해 데이터 펌프 또는 이벤트 데이터 펌프를 사용하자. 가능하다면 다른 기술 스택을 자유롭게 사용하도록 기술 중립적 API을 선택하자. 내부와 외부의 세부 구현 분리를 정형화하는 REST를 사용하자.
모든 것을 분권화#
마이크로서비스의 또하나의 핵심 나눠서 유리한 서비스들은 나누자. 각 서비스를 소유한 팀에 의사결정과 통제를 하게 하자. 콘웨이의 법칙이 효과가 있도록 팀을 조직에 맞춰서 조정하자. 만약 중요한 지침이 필요한 곳이라면 각 팀의 사람들이 시스템의 기술 비전을 진화 시킬 책임을 집단으로 공유하는 개념인 공유 거버넌스(shared governance) 모델을 시도하자.
오케스트레이션과 멍청한 미들웨어 대신 코레오그래피를 선호하라. 코레오그래피는 서비스 경계 내에서 로직과 데이터 연관성을 보장하는 영리한 엔드포인트로 응집력을 유지하게 한다.
독립적인 배포#
- 호환성을 깨뜨리는 변경이 필요할 때에는 여러 버전의 엔드 포인트가 공존해야 한다.
- 호스트당 단일 서비스 모델을 적용함으로써 서비스 배포시 다른 서비스에 영향이 없도록 하자.
- 잘못된 릴리스의 위험을 줄이며 릴리스와 배포를 분리하기 위해 청색/녹색 또는 카나리아 릴리스 기법 사용을 고려하자.
- 호환성을 깨뜨리는 변경을 미리 발견할 수 있도록 소비자 주도 계약을 사용하라
- 서비스의 소비자가 자신을 업데이트 할때를 결정해야 한다는점을 기억하자.
장애 격리#
- 네트워크 호출을 할 때 원격 호출을 지역 호출처럼 처리하지 말자.
- 타임아웃이 적절히 설정을 확인하자.
- 장애가 발생한 컴포넌트의 악영향을 제한하기 위해 격벽과 회로차단기를 언제 어떻게 사용하지 고려하자
- 네트워크 파티션이 함축하는 것과 주어진 상황에서 가용성과 일관성 중 어느 것을 중요도를 고려하자.
뚜렷한 식별성#
- 시스템이 정상 독작하는지 알기 위해 가상 트랙잭션을 주입함으로써 실사용자 행위를 모의하는 유의적 모니터링을 사용하자.
- 시스템간의 상호작용과 호출을 확인하고 싶다면 *상관관계ID*를 사용하자.
언제 마이크로서비스를 사용하지 않아야 하나#
해당 분야를 제대로 이해하지 못하는 경우, 서비스에 대한 적절한 경계가 있는 콘텍스트를 찾기 힘들다. 서비스 경계를 잘못 나누게 되는 경우, 고비용이 드는 서비스와 서비스 간의 협업에 많은 변경이 발생하게 된다. 미개발 분야의 경우 역시 여렵지만 새로운 분야의 문제만이 아니라 없는 것보다 있는 것을 구축하는것이 쉽다. 모놀리식을 시작하고 안정되면 분해하는 방법도 고려하자.
Reference : Build Microservice By Sam Newman, Publisher: O’Reilly