Microservices Architecture Style
마이크로서비스 아키텍처에 대해 알아보아요
References: microsoft docs, aws docs
What are Microservices?
마이크로서비스는 작고, 독립적이며, 느슨하게 결합되어 있다
하나의 소규모 개발자 팀이 작성하고 유지/관리 할 수 있다
각 서비스는 작은 개발 팀이 관리할 수 있는 개발 코드 베이스이다
서비스를 독립적으로 배포할 수 있다
팀이 전체 application을 다시 빌드한 후 재배치 하지 않고도 기존 서비스를 업데이트 할 수 있다
서비스가 해당 데이터 or 외부 상태를 유지해야 한다
별도의 데이터 레이어가 데이터 지속성을 처리하는 기존 모델과의 차이점!
서비스가 잘 정의된 API를 사용하여 서로 통신한다
각 서비스 내부 구현 세부 정보는 다른 서비스에 의해 숨겨진다
서비스가 동일한 기술 스택, library, 또는 framework를 공유할 필요가 없다
Benefits of Microservices
민첩성
독립적으로 배포되기 때문에 버그 수정 및 릴리스를 관리하기가 더 쉽다
집중화된 소규모 팀
마이크로 서비스는 규모가 작아서 한 기능 팀에서 충분히 구축, 테스트 및 배포할 수 있다
소규모 팀은 민첩성이 높다!
소규모 코드 기준
모놀리식 애플리케이션의 경우 시간이 경과하면서 코드 종속성이 얽히는 경향이 있기 때문에 새로운 기능을 추가하려면 많은 부분에서 코드를 수정해야 한다
but, 마이크로 서비스 아키텍처는 코드나 데이터 저장소를 공유하지 않으므로 종속성이 최소화되며 그 결과 새로운 기능을 추가하기 쉽다
기술의 혼합
팀은 혼합된 기술 스택을 적절히 사용하여 서비스에 가장 적합한 기술을 선택할 수 있다
결함 격리
개별 마이크로 서비스를 사용할 수 없게 되더라도, 장애를 제대로 처리하도록 업스트림 마이크로 서비스를 설계하면(예: 회로 단락 구현) 전체 애플리케이션에 방해가 되지 않는다
확장성
서비스는 별도로 확장될 수 있어 전체 애플리케이션 규모를 확장하지 않고도 리소스가 더 많이 필요한 하위 시스템의 규모를 확장할 수 있다
데이터 격리
단일 마이크로 서비스만 영향을 받기 때문에 스키마 업데이트를 수행하는 것이 훨씬 쉽다
but, 모놀리식 애플리케이션에서는 스키마 업데이트가 매우 어려울 수 있다!
애플리케이션의 다양한 부분이 모두 동일한 데이터에 영향을 미칠 수 있어서 스키마를 변경하는 것이 위험하기 때문!
Challenges of Microservices
복잡성
Microservice application에는 동등한 monolithic application 보다 작동하는 part가 더 많다
각각의 서비스는 더 단순하지만 전체 시스템은 더 복잡하다
통제의 어려움
Microservice build에 대한 분산 접근 방식에는 장점이 있지만, 문제가 발생할 여지가 있다
사용되는 언어와 framework가 많아서 application의 유지 관리가 어려워질 수 있다
그래서 프로젝트에 몇 가지 표준을 적용하는 것이 좋다!
ex) logging 과 같은 cross-cutting 기능
네트워크 정체 & 대기 시간
다수의 작고 세분화된 서비스를 사용하면 서비스 간 통신이 증가할 수 있다
또한 서비스의 종속성 체인 (서비스 A가 B를 호출하고, B가 C를 호출하고......) 이 너무 길어질 경우 추가 대기 시간에 대한 문제가 발생 할 수 있다
그러므로 API를 신중하게 설계해야 한다!
데이터 무결성
각 Microservice는 자체적으로 데이터의 지속성을 관리한다
그래서 데이터의 일관성이 문제될 수 있다
버전 관리
서비스의 업데이트로 인해 종속된 서비스가 손상되지 않도록 해야한다
언제든 여러 서비스가 업데이트 될 수 있으므로 신중하게 디자인 하지 않으면 호환성 문제가 발생할 수 있다
Last updated