마이크로 서비스 아키텍처는 작은 자율 서비스 컬렉션으로 구성되어있다.
각 서비스는 독립적이며 제한된 컨텍스트 내에서 단일 비즈니스 기능을 구현해야 한다.
마이크로 서비스란?
마이크로 서비스는 작고, 독립적이며, 느슨하게 결합되어 있습니다. 하나의 소규모 개발자 팀이 작성하고 유지 관리할 수 있습니다.
각 서비스는 작은 개발 팀이 관리할 수 있는 개별 코드베이스입니다.
서비스를 독립적으로 배포할 수 있습니다. 팀이 전체 애플리케이션을 다시 빌드한 후 재배치하지 않고도 기존 서비스를 업데이트할 수 있습니다.
서비스가 해당 데이터 또는 외부 상태를 유지해야 합니다. 이는 별도의 데이터 레이어가 데이터 지속성을 처리하는 기존 모델과의 차이점입니다.
서비스가 잘 정의된 API를 사용하여 서로 통신합니다. 각 서비스의 내부 구현 세부 정보는 다른 서비스에서 숨겨집니다.
다중저장소 프로그래밍을 지원합니다. 예를 들어 서비스가 동일한 기술 스택, 라이브러리 또는 프레임워크를 공유할 필요가 없습니다.
이점
민첩성. 마이크로 서비스는 독립적으로 배포되기 때문에 버그 수정 및 기능 릴리스를 관리하기가 더 쉽습니다. 전체 애플리케이션을 다시 배포하지 않고 서비스를 업데이트할 수 있고, 문제가 발생하면 업데이트를 롤백할 수 있습니다. 기존의 많은 애플리케이션의 경우, 버그가 애플리케이션의 한 부분에서 발견되면 전체 릴리스 프로세스를 차단할 수 있습니다. 버그 수정이 통합, 테스트 및 게시될 때까지 새로운 기능은 보류될 수 있습니다.
집중화된 소규모 팀. 마이크로 서비스는 규모가 작아서 한 기능 팀에서 충분히 구축, 테스트 및 배포할 수 있습니다. 소규모 팀은 민첩성이 높습니다. 대규모 팀은 커뮤니케이션의 속도가 느리고, 관리 오버헤드가 증가하며, 민첩성이 감소되기 때문에 생산성이 떨어지는 경향이 있습니다.
소규모 코드 기준. 모놀리식 애플리케이션의 경우 시간이 경과하면서 코드 종속성이 얽히는 경향이 있습니다. 새 기능을 추가하려면 여러 지점의 코드를 손봐야 합니다. 마이크로 서비스 아키텍처는 코드나 데이터 저장소를 공유하지 않으므로 종속성이 최소화되며 그 결과 새로운 기능을 추가하기 쉽습니다.
기술의 혼합. 팀은 혼합된 기술 스택을 적절히 사용하여 서비스에 가장 적합한 기술을 선택할 수 있습니다.
결함 격리. 개별 마이크로 서비스를 사용할 수 없게 되더라도, 장애를 제대로 처리하도록 업스트림 마이크로 서비스를 설계하면 전체 애플리케이션에 방해가 되지 않습니다. 예를 들어 회로 차단기 패턴을 구현하거나 마이크로 서비스가 비동기 메시징 패턴을 사용하여 서로 통신하도록 솔루션을 디자인할 수 있습니다.
확장성. 서비스는 별도로 확장될 수 있어 전체 애플리케이션 규모를 확장하지 않고도 리소스가 더 많이 필요한 하위 시스템의 규모를 확장할 수 있습니다. Kubernetes 또는 Service Fabric 등의 오케스트레이터를 사용하면 단일 호스트에 서비스를 보다 높은 밀도로 패킹할 수 있기 때문에 리소스를 보다 효율적으로 활용할 수 있습니다.
데이터 격리. 단일 마이크로 서비스만 영향을 받기 때문에 스키마 업데이트를 수행하는 것이 훨씬 쉽습니다. 모놀리식 애플리케이션에서는 스키마 업데이트가 매우 어려울 수 있습니다. 애플리케이션의 다양한 부분이 모두 동일한 데이터에 영향을 미칠 수 있어서 스키마를 변경하는 것이 위험하기 때문입니다.
과제
마이크로 서비스의 이점은 무료로 제공되지 않습니다. 마이크로 서비스 아키텍처를 시작하기 전에 고려해야 할 몇 가지 과제가 있습니다.
복잡성. 마이크로 서비스 애플리케이션에는 동등한 모놀리식 애플리케이션보다 작동 부분이 더 많습니다. 각 서비스는 더 단순하지만 전체 시스템이 더 복잡합니다.
개발 및 테스트. 다른 종속 서비스에 의존하는 소규모 서비스를 작성하려면 기존의 모놀리식 또는 계층화된 애플리케이션을 작성하는 것과 다른 접근 방식이 필요합니다. 기존 도구는 항상 서비스 종속성 작업에 맞게 설계되지 않습니다. 서비스 경계를 벗어난 리팩터링은 어려울 수 있습니다. 특히 애플리케이션이 빠르게 발전하는 경우 서비스 종속성을 테스트하기도 어렵습니다.
통제 부족. 마이크로 서비스 빌드에 대한 분산 접근 방법에는 장점이 있지만 문제가 발생할 수도 있습니다. 언어와 프레임워크가 너무 많아서 애플리케이션 유지 관리가 어려워질 수 있습니다. 팀의 유연성을 지나치게 제한하지 않고 몇 가지 프로젝트 전체 표준을 적용하는 것이 유용할 수도 있습니다. 특히 로깅과 같은 교차 기능에 해당합니다.
네트워크 정체 및 대기 시간. 다수의 작고 세분화된 서비스를 사용하면 서비스 간 통신이 증가할 수 있습니다. 또한 서비스 종속성 체인이 너무 길어질 경우(서비스 A가 B를 호출하고, B가 C를 호출하고...) 추가 대기 시간이 문제가 될 수 있습니다. API를 신중하게 디자인해야 합니다. 통신량이 과도한 API를 피하고, 직렬화 형식을 고려하고, 큐 기반 부하 평준화와 같은 비동기 통신 패턴을 사용할 영역을 찾아보세요.
데이터 무결성. 각 마이크로 서비스가 자체 데이터 지속성을 담당합니다. 그 결과, 데이터 일관성이 과제가 될 수 있습니다. 가능한 경우 결과적 일관성을 수용합니다.
관리. 마이크로 서비스에 성공하려면 성숙한 DevOps 문화가 필요합니다. 전체 서비스의 상관관계 로깅이 까다로울 수 있습니다. 일반적으로 로깅은 단일 사용자 작업에 대한 여러 서비스 호출을 상호 연결해야 합니다.
버전 관리. 서비스 업데이트로 인해 종속된 서비스가 손상되지 않아야 합니다. 언제든지 여러 서비스가 업데이트될 수 있으므로 신중하게 디자인하지 않으면 이전 버전 또는 이후 버전과의 호환성 문제가 발생할 수 있습니다.
기술 수준. 마이크로 서비스는 고도로 분산된 시스템입니다. 팀이 성공을 위한 기술과 경험을 가지고 있는지 신중하게 평가합니다.
