MSA(MicroService Architecture)에 대해서

MSA란?

---

• MicroService Architecture의 줄임말
• 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다.

 

서비스 지향 아키텍처(SOA)란

---

• Service Oriented Architecture의 줄임말
• 애플리케이션 구성요소가 통신 프로토콜을 통해 다른 구성요소에 서비스를 제공하는 아키텍처 접근 방식이다.
• 대규모 컴퓨터 시스템을 구축할 때의 개념으로 업무상에 일 처리에 해당하는 소프트웨어 기능을 서비스로 판단하여 그 서비스를 네트워크상에 연동하여 시스템 전체를 구축해 나가는 방법론이다.
• 각 서비스는 독립적인 단위이다.

 

MSA 등장배경

---

• Monolithic Architecture는 소프트웨어의 모든 구성요소가 한 프로젝트에 통합되어 있는 서비스이다.
• 현재 많은 회사들의 소프트웨어가 레거시 또는 필요로 인하여 Monolithic 형태로 구성되어 있다.
• 소규모 프로젝트 Monolithic 형태가 MSA보다 간단하며, 유지보수가 편하고 비용이 적게든다는 장점이 있기에 대부분의 규모가 작은 회사에서는 Monolithic이 선호된다.

 

기존 Monolithic Architecture의 한계

---

• 부분 장애가 전체 서비스의 장애로 확대될 수 있다.
  예를들면 배민의 경우 배달서비스와 리뷰서비스가 있는데 리뷰서비스가 장애가 나면 배달서비스까지 장애가 확대된다.
• 전체 시스템 구조 파악이 어렵다.
  MSA의 경우 회사마다 다르지만 도메인 별로 서비스를 나누는편이라 구조파악이 편리하다.
• 서비스 변경이 어렵고, 수정 시 영향도(사이드 이펙트)파악이 힘들다
  MSA의 경우 각 서비스는 독립적이므로 수정이 쉽다.
• 빌드 시간 및 테스트, 배포 시간의 급증
• 서비스의 특정 부분만 스케일아웃(sacle-out)하기 어렵다.

이러한 기존 모놀리식 구조 서비스의 한계점에서 MSA가 등장하게 되었다.

 

MSA 특징

---

• MSA는 API를 통해서만 상호작용할 수 있다.
• MSA는 서비스의 end-point(접근점)을 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화한다. (이쯤되면 인터페이스가 생각난다.)
• 내부의 구현 로직, 아키텍처와 프로그래밍 언어, DB, 품질 유지 체계와 같은 기술적인 사항들은 서비스 API에 의해 철저하게 가려진다.
• 제데로 설계된 마이크로서비스는 하나의 비즈니스 범위에 맞춰 만들어지므로 하나의 기능만 수행한다.
• 어플리케이션 출시처럼 하나의 목표를 향해 일하지만 자기가 개발하는 서비스만 책임진다.
• 그리고 여러 어플리케이션에서 재사용할 수 있어야 한다.
• 어플리케이션은 항상 기술 중립적 프로토을 사용해 통신하므로 서비스 구현 기술과는 무관하다. 따라서 마이크로서비스 기반의 어플리케이션을 다양한 언어와 기술로 구축할 수 있다는 것을 의미한다.
• 마이크로 서비스는 SOA에서 사용되는 집중화된 관리 체계를 사용하지 않는다. 마이크로서비스 구현체의 공통적인 특징 중 하나는 ESB(Enterprise Service Bus)와 같은 무거운 제품에 의존하지 않는다는 점이다. REST 등 가벼운 통신 아키텍처, 또는 Kafka등을 이용한 message stream을 주로 사용한다.

 

MSA 장점

---

1. 배포

• 서비스별 개별 배포가 가능하다.(배포시 전체 서비스의 중단이 없다.)
• 특정 서비스의 요구사항만을 반영하여, 빠르게 배포 가능하다.

2. 확장

• 특정 서비스에 대한 확장성(scale-out)이 유리하다.
• 클라우드 기반 서비스 사용에 적합하다.

3. 장애

• 일부 장애가 전체 서비스로 확장될 가능성이 적다.
• 부분적으로 발생하는 장애에 대한 격리가 수월하다.

4. 그외

• 새로운 기술을 적용하기 유연하다.(전체 서비스가 아닌 특정 서비스만 별도 기술 또는 언어로 구현가능)
• 각각의 서비스에 대한 구조 파악 및 분석이 모놀리식 구조에 비해 쉽다.

 

MSA 단점

---

1. 설계의 어려움

• MSA는 모놀리식에 비해 상대적으로 많이 복잡하다. 서비스가 모두 분산되어 있기 떄문에 개발자는 내부 시스템의 통신을 어떻게 가져가야 할지 정해야한다. 또한, 통신의 장애와 서버의 부하 등이 있을 경우 어떻게 transaction을 유지할지 결정하고 구현해야 한다.

2. 성능

• 서비스 간 호출 시 API를 사용하므로, 통신 비용이나 Latency에 대해 이슈가 존재한다.

3. 테스트 / 데이터 트랜잭션

• 모놀리식에서는 단일 트랜잭션을 유지하면 됐지만, MSA에서는 비즈니스에 대한 DB를 가지고 있는 서비스도 각기 다르고, 서비스의 연결을 위해서는 통신이 포함되기 떄문에 트랜잭션을 유지하는게 어렵다.
• 통합 테스트가 어렵다. 개발 환경과 실제 운영환경을 동일하게 가져가는 것이 쉽지 않다.

4. 데이터 관리

• 데이터가 여러 서비스에 분산되어 있어 조회하기 까다롭다.
• 데이터를 관리하기 어렵다.

 

MSA 사례

---

• 22년 MSA 적용 회사 조사 에 따르면 응답 기업의 85%가 MSA를 채택하여 앱의 현대화를 수행 중이라고 한다.
• 애플리케이션의 절반 이상을 MSA에 둔 조직의 56%가 매일 혹은 더 자주 배포가 가능하기 때문에 MSA 덕분에 개발 주기가 빨라졌다고 응답하기도 했다.
• 2020년에 약 1조 원 남짓에 불과했던 클라우드 마이크로서비스 시장 규모는 21.7씩 성장하여 6년 만에 3배가 넘어 3조 5천억원을 넘길 예정이라고 한다.
• MSA가 이처럼 필수적 요건으로 자리매김하면서 MSA관련 솔루션을 지원하는 기업들의 몸값도 치솟는 중이다. 최근 마이크로서비스 플랫폼 제공 업체인 Greymatter.io는 약 92억 원 규모의 시리즈 A투자를 받았고 마이크로서비스 연결 서비스를 제공하는 기업인 Solo.io는 1755억 원을 유치했다.

이처럼 MSA를 적용하여 생산성 향상, 고객 만족도 증대, 시장 출시 기간 단축, 애플리케이션 품질 향상, 확장성 증가 등 비즈니스 성장을 주도할 수 있는 실질적인 이점을 얻을 수 있다.

 

MSA 무조건 적용해야 할까?

---

MSA의 효과를 오롯이 누리려면, 중요한 몇 가지 과제가 있다.

마이크로서비스에 대한 내부 경험 부족

• IBM이 조사해 발표한 결과 자료에 따르면, 54%의 응답자가 'MSA 전문 지식을 갖춘 인재를 확보하기 어렵다’고 대답했고 52%는 ‘마이크로서비스를 배우는 것이 복잡하다.’ 고 응답했다.
• 특히 현재 MSA를 이용하지 않는 사람들은 MSA를 도입하지 않은 가장 큰 이유로 '내부 경험 부족’을 꼽았다.

복잡성이 늘어날 가능성

• MSA 개발은 일반 개발보다 복잡하다. 각각 독립적인 서비스로 이루어져 있기 때문에 모듈의 인터페이스를 신중하게 처리해야 하고 제약들도 많다. 분산된 서비스마다 분리된 DB의 트랜잭션 관리도 신경 써야 한다.
• DB를 얼마나 할당해야 할지, 배포에 있어서도 각 서비스 간의 충돌이나 문제가 없는지 미리미리 챙겨야 한다.

구축 소요기간 및 비용의 불확실성

• MSA를 효과적으로 실행하는데 필요한 인프라가 부족하다는 응답도 51%나 됐다.
• MSA는 수백 또는 수천 개의 개별 서비스로 구성되어 있다.
• 시스템 전체를 중단하지 않고 필요한 부분만 업데이트&배포가 가능한 것이 특징이지만 바로 그 독립된 구조 탓에 배포나 테스트를 일관적으로 수행하기가 쉽지 않다.
• 적절한 툴이 없으면 대규모 테스트나 배포 전에 연결된 모든 서비스가 잘 작동하는지 일일이 확인해야 할 수도 있다.

 

검증된 MSA 개발 모델 앞으로의 시각

---

MSA를 현재 도입하지 않는 비사용자더라도 MSA가 이미 넥플릭스, 테슬라 등 MSA가 이미 검증된 애플리케이션 개발 모델이며 MSA 도입 시 인재 유치에 도움이 되고 개발팀에 많은 이점을 제공한다는 데에는 대다수가 동의하고 있다.

앞선 조사에 현재 MSA를 사용하고 있지 않는 응답자의 56%가 향후 채택 가능성이 높다고 답했고, 앞으로 애플리케이션에는 MSA가 대세가 될 것이라는 점에도 59%가 그렇다고 답했다.

MSA 도입은 필요와 규모에 따라 적절히 선택해야하겠지만, 이를 무릅쓸 만한 가치는 있다.

 

정리하며

---

최근 MSA, 헥사고날 아키텍처를 적용한 프로젝트를 끝낸 후, MSA에 대한 정리가 필요하다 생각했다.
MSA를 설명하려니 말이 나오지 않아 한번 더 정리하게 되었고, 취준이 길어지다보니 복습겸 정리하게 되었다.

사실 기존 모놀리식으로 돌아가는 서비스를 굳이? MSA로 바꿔야하나 생각이 들기도 한다.
잘 돌아가는 서비스를 비용을 들어서 MSA로 리펙터링 하는것이 과연 큰기업 말고는 적용하는 의미가 있을까?
물론 웹은 빠르게 변화하고 있다. 미래에는 MSA가 기본적으로 사용될 지 아무도 모른다.

개발자로서 MSA를 어떻게 바라봐야 할까 고민을 해보았고 MSA를 실무에서 사용하지 않더라도 알고 할줄은 알아야 어느정도 경쟁력있는 개발자가 되지 않을까 생각을 하며 글을 마무리 한다.

 

 

참고자료

https://happycloud-lee.tistory.com/261?category=832246
https://hahahoho5915.tistory.com/71
https://www.opsnow.com/요즘-대세-msa/