-
마이크로서비스는 소프트웨어가 잘 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성되어 있는 경우의 소프트웨어 개발을 위한 아키텍처 및 조직적 접근 방식이다.
왜 마이크로서비스가 부상하였는가?
마이크로서비스 아키텍처는 애플리케이션의 확장을 용이하게 하고 개발 속도를 앞당겨 혁신을 실현하며 새로운 기능의 출시 시간을 단축할 수 있게해 준다.
모놀리식 아키텍처 vs 마이크로서비스 아키텍처
모놀리식 vs 마이크로서비스 아키텍처 - 모놀리식 아키텍처 : 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행된다. 따라서 애플리케이션의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야 한다. 종속 관계를 이루며 긴밀하게 결합된 많은 프로세스로 인해 단일 프로세스의 실패로 인한 영향이 증가함에 따라 모놀리식 아키텍처는 애플리케이션 가용성에 대한 위험을 가중시킨다.
- 마이크로서비스 아키텍처 : 애플리케이션이 독립적인 구성 요소로 구축되어 각 애플리케이션 프로세스가 서비스로 실행된다. 이러한 서비스는 경량 API를 사용하여 잘 정의된 인터페이스를 통해 통신한다. 서비스는 비즈니스 기능을 위해 구축되며 서비스마다 한 가지 기능을 수행한다. 서비스가 독립적으로 실행되기 때문에 애플리케이션의 특정 기능에 대한 수요를 충족하도록 각각의 서비스를 업데이트, 배포 및 확장할 수 있다.
마이크로서비스의 이점
민첩성
팀은 충분한 이해를 바탕으로 하는 소규모 컨텍스트 내에서 활동하며 더 독립적이면서 신속하게 업무를 수행할 수 있다. 그 덕에 개발 주기 시간이 단축된다.
유연한 확장성
각 서비스가 지원하는 애플리케이션 기능의 수요를 충족하도록 해당 서비스를 독립적으로 확장할 수 있다. 따라서 팀은 필요한 인프라의 규모를 적절히 조절하고, 기능의 비용을 정확하게 측정하고, 서비스의 수요가 급증하는 경우에도 가용성을 유지할 수 있다.
손쉬운 배포
마이크로서비스는 지속적 통합 및 지속적 전달을 통해 새로운 아이디어를 손쉽게 시험하고 문제가 발생할 경우 간단히 롤백할 수 있게 해준다. 이처럼 저렴한 실패 비용 덕분에 더 쉽게 코드를 업데이터하고 새로운 기능의 출시 시간을 앞당길 수 있다.
기술적 자유
마이크로서비스 아키텍처는 "모든 규모에 부합하는" 접근 방식을 추구하지 않는다. 팀은 특정한 문제를 해결하는 데 가장 적합한 도구를 자유롭게 선택할 수 있다.
재사용 가능한 코드
소프트웨어를 잘 정의된 소규모 모듈로 분할하면 팀이 기능을 여러 용도로 사용할 수 있게 된다. 특정 기능을 위해 구축된 서비스를 다른 기능의 빌딩 블록으로 사용할 수 있는 것이다.
복원성
마이크로서비스에서는 기능을 저하시키고 전체 애플리케이션을 충돌시키지 않는 방식으로 전체 서비스 실패를 처리한다. (모놀리식 아키텍처의 경우 단일 구성 요소가 실패하는 경우 전체 애플리케이션이 실패하게 될 수 있다.)