가상화ㆍ컨테이너 / 개발자 / 클라우드

마이크로서비스 아키텍처를 사용해야 하는 이유

Lee Atchison | InfoWorld 2021.11.16


각 개발팀이 독립적이라고 하지만, 온전히 독립적이지는 않다. 한 팀에서 수행한 변경이 다른 팀에서 진행 중인 작업에 큰 영향을 미치기 때문이다. 모든 프로젝트가 서로 얽혀 있어 독립적인 프로젝트를 추진할 수 없다. 혁신이 저해되고 비즈니스도 함께 저해된다. 

마이크로서비스의 가치 

이제 그림 3을 보자. 
 
그림 3. 마이크로서비스 애플리케이션 ⓒ IDG

각 서비스는 독립적이며 다른 모든 서비스와 격리돼 있다. 더 작은 대신 더 많은 서비스가 있다. 각 서비스 간에는 잘 정의된 인터페이스가 있으며, 각각은 잘 정의된 비즈니스 로직을 대변한다. 더 중요한 점은 각 서비스에 대해 소유권을 가진 개발팀은 하나라는 것이다. 하나의 개발팀이 각 개별 서비스의 모든 측면을 책임진다. 애플리케이션은 깔끔하고 소유권과 책임이 더 명확하다. 

간단히 말해 애플리케이션이 확장됐다. 지원할 수 있는 고객의 수 측면에서의 확장이 아니라, 성장하는 비즈니스를 지원하기 위해 유지하는 독립적인 개발자와 프로젝트, 이니셔티브의 수 측면에서 확장된 것이다. 

개발팀이 다른 개발팀의 발을 밟을 일이 없다. 대처해야 할 함정의 수가 적으므로 생산성은 더 높다. 만족도가 높아 회사에 오래 남을 가능성도 높아진다. 또한 소유권 책임의 균형을 조정하는 간단한 방법으로 개발팀과 개발자의 수를 늘릴 수 있다. 더 많은 개발자의 생산성이 더 높아지고 성장에 가장 중요한 비즈니스 프로젝트를 더 원활하게 추진할 수 있다. 

문제가 발생하면 서비스 간의 상호작용을 분석함으로써 문제의 근원지가 어디이며 어느 팀이 수정해야 하는지를 훨씬 더 쉽게 판단할 수 있다. 또한 각 팀마다 담당하는 부분이 훨씬 더 작으므로 각자가 책임지는 서비스가 기능하는 방식에 대한 지식도 더 깊어지고, 따라서 훨씬 더 빠르고 효과적으로 문제를 수정할 수 있다. 또한 각자가 책임지는 영역에 대한 이해도가 높아지므로 실수로 시스템에 오류가 유입될 가능성이 낮아진다. 
 

확장에 도움이 되는 마이크로서비스 

마이크로서비스 아키텍처는 다음과 같은 여러 측면에서 확장에 도움이 된다. 
 
  • 트래픽과 고객. 마이크로서비스를 사용하면 더 많은 트래픽, 더 많은 데이터와 함께 더 많은 고객을 지원할 수 있다. 
  • 개발자와 개발팀의 수. 마이크로서비스를 사용하면 개발팀을 추가해서 애플리케이션에 더 많은 개발자를 투입할 수 있다. 모놀리식 개발 프로세스와 같이 개발자들이 서로에게 방해가 되는 일이 많지 않으므로 생산성이 높아진다. 
  • 복잡성과 기능. 각 팀이 생각해야 할 애플리케이션 “표면 영역”이 더 적으므로 각자의 영역 내에서 더 복잡한 문제에 대처할 수 있다. 더 많은 팀이 더 많은 문제 영역에 대해 작업하므로 더 복잡한 프로젝트가 가능하다. 
 

단일팀 지향 서비스 아키텍처 

애플리케이션을 마이크로서비스 기반 아키텍처로 옮기는 것만으로는 충분하지 않다. 마이크로서비스 기반 아키텍처를 사용하더라도 개발팀이 여러 서비스에 걸친 프로젝트에서 작업하면서 팀 간에 복잡한 상호작용을 유발하는 상황은 여전히 발생할 수 있다. 마이크로서비스 기반 아키텍처로 전환하더라도 여전히 개발 함정에 빠질 수 있다는 것이다. 

이런 문제를 피하려면 명확한 서비스 소유권 및 책임 모델이 필요하다. 각각의 모든 서비스에는 그 서비스를 완전히 책임지는 명확하고 잘 정의된 하나의 개발팀이 필요하며, 작업은 서비스 수준에서 관리 및 위임되어야 한다. 단일팀 지향 서비스 아키텍처(Single Team Oriented Service Architecture, STOSA)와 같은 모델을 추천한다. 이 모델은 애플리케이션과 개발팀이 비즈니스 요구에 맞추어 확장할 수 있게 해주는 명료성을 제공한다. 
 

마이크로서비스의 비용 

마이크로서비스 아키텍처에도 비용이 따른다. 개별 서비스를 이해하고 관리하기는 더 쉽지만, 애플리케이션 전체적으로는 움직이는 부분이 더 많고 그 자체로 매우 복잡한 형태가 된다. 이는 애플리케이션 복잡성으로 이어질 수 있고, 복잡성으로 인한 문제가 애플리케이션의 다른 측면에도 영향을 미칠 수 있다. 간과해서는 안될 부분이다.

함정에 빠진 많은 기업(그림 2)이 마이크로서비스 아키텍처로 마이그레이션하기 위한 프로젝트를 시작할 것이다(그림 3). 그러나 많은 기업이 희망 또는 예상한 것보다 더 어렵고 값비싼 전환에 직면하게 되고, 결국 마이그레이션 중간에 포기할 가능성이 높다. 일부만 마이그레이션하면 마이그레이션을 시작할 당시보다 오히려 상황이 더 나빠지는 경우가 많다. 

마이크로서비스 아키텍처로 마이그레이션을 시작하기 전에 예상되는 모든 비용과 혜택, 과제를 미리 파악해야 한다. 전환 프로젝트 그리고 미래의 애플리케이션이 성공하기 위해서는 적절한 기대치를 설정해야 한다. editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.