MSA의 역사

주댕이·2024년 5월 16일

microservice monolithic msa

안녕하세요, 요즘 MSA에 대해 흥미가 생겨 어떻게 MSA가 탄생하게 되었는지,

특징에 대해 정리하고자 작성하려고 합니다.

MSA 란?

우선 MSA 는 Microservice Architecture 의 줄임말로, 어떠한 Service를 Micro 단위 , 즉 "하나의 기능을 서비스 별로 분할시킨 구조"를 뜻합니다.

기존에는 모든 서비스를 하나의 구조에 넣는 Monolithic Architecture 을 사용했었죠.

MSA가 나오게 된 건, Monolithic Architecture 의 단점을 보완하기 위해 생긴 것입니다.

우선 MSA 나오기 전 Monolithic Atchitecture 에 대해 알아보겠습니다.

Monolithic Architecture 이란 ?

"거대하고 빙하 같은 것" 의 뜻을 가지며 하나의 서비스 또는 애플리케이션이 하나의 거대한 아키텍쳐를 가지는 구조입니다.

Monolithic Architecture의 장점

단순성 : 모든 코드가 단일 코드 베이스며, 변경 사항이 발생할 경우 필요한 모든 코드가 한 곳에 존재합니다.
간편한 배포 : 단일 프로젝트만 배포하면 되기 때문에, 새로운 기능이 추가되거나 버그가 수정될 때마다 단일 애플리케이션을 배포하면 됩니다.
보편성 : 대부분 개발자가 Monolithic Architecture에서 작업한 경험이 있어, 프로젝트를 쉽게 시작할 수 있습니다.
쉬운 디버깅 : 모든 코드가 한 곳에 있기에 빠른 디버깅이 가능합니다.
쉬운 테스트 : 디버깅과 마찬가지로 빠른 검증이 가능합니다.
쉬운 모니터링 : 오류 문제시 발생한 위치를 빠르게 찾을 수 있습니다.

Monolithic 애플리케이션은 사전 계획이 많이 필요하지 않으므로 시작하기가 더 쉬워 개발 시작 후에 필요에 따라 코드 모듈을 계속 추가할 수 있는 이점이 있습니다. 그러나 시간이 지남에 따라 애플리케이션이 복잡해지고 업데이트나 변경이 어려워질 수 있습니다.

Monolithic Architecture의 단점

규모가 커지면 유지 보수가 어려움 : 시간에 지남에 따라 애플리케이션이 커지면 관리가 어려워질 수 있습니다.
유연하지 않은 확장성 : 어느 특정 부분에 대해 확장이 필요하면 해당 부분만 확장하는 것이 아닌 전체 애플리케이션을 확장해야 합니다.
대규모 팀 작업이 어려움 : 모든 팀이 동일한 코드, 프로젝트에서 작업하기 때문에 코드 병합에 대한 충돌 가능성이 높고, 기능 변경 시 다른 팀의 작업에 영향을 줄 수 있습니다.
기술 사용 제한 : 시작과 동시에 동일한 기술을 사용해야 합니다.

이와 같이 Monolithic Architecture는 규모가 너무 커지고 확장이 어려워지면 더 이상 효과적이지 않게 됩니다. 그렇지만 다음과 같은 경우에는 효과적으로 사용할 수 있습니다.

규모가 작은 애플리케이션
현 비즈니스를 통해 성장할 계획이 없거나, 복잡한 시스템 설계 및 관리가 필요하지 않은 경우
현재 아이디어를 구상 중인 단계
팀의 규모가 작거나 새로 생긴 팀인 경우, 혹은 새로운 도메인일 때
아직 MVP 상태일 때
주된 작업이 CRUD만 있을 경우

MicroService Architecture 의 탄생

MSA는 갑자기 생겨난 신기술은 아닙니다. MSA를 구축하기 위해 사용된 다양한 기술들이 기존에 이미 존재하고 있었으나 클라우드 시대가 열리게 돼, 필요성이 부각되어 기존에 있던 기술들이 조합되어 나오게 되었습니다. 과거의 IT 시스템의 발전 흐름을 이해하면 MSA의 필요성을 더 이해하기 쉽게 느껴지실 겁니다.

1960 - 1980s: Fragile

메인 프레임 시기라고 불리며, 하드웨어 중심적이었습니다. 소프트웨어보다 하드웨어 사양이나 성격에 맞춰 서비스를 구축해야 했던 시기였고, 하드웨어 자체가 고가여서 서비스의 변경이나 발전이 어려웠습니다. 깨지기 쉬운 시스템 성격이 강함(Fragile)``````
코드를 입력하세요
1990 ~ 2000: Robust

분산이라는 키워드가 주가된 시기, 분산 환경이 발전되던 시기, Robust Distributed 구조를 통해 좀 더 안정적인 시스템을 가져갈 수 있었습니다. 시스템의 불확실성을 가져간다 하더라도 안정적일 수 있게 되었습니다.
2010s ~ : Resilient/Anti-Fragile
Resilient(탄력성), Anti Fragile을 지향하며, 클라우드 서비스의 확장으로 인해 비용도 저렴하고 지속적인 확장이 가능한 구조(Cloud Native)를 지향할 수 있게 되었습니다.
- 로컬 환경에서 클라우드로 전환되었고 안정성과 확장성 ↑
- 지속적인 개선 및 변경사항이 생기더라도 시스템은 탄력적으로 운영할 수 있도
  록 구축 되었습니다.
- 다른 시스템에 비해 안정성이 높고, 비용 또한 적게 가져갈 수 있습니다.

현 시대에서 AWS, Azure, GCP 등 다양한 클라우드 서비스들이 등장하며 Anti Fragile을 지향한 Cloud Native Architecture을 구성할 수 있게 되었습니다.

(참고 : https://velog.io/@humblechoi/Microservice%EC%99%80-Spring-Cloud)

이처럼 Cloud service의 등장으로 로컬 환경에서 Hardware적으로 IT 시스템을 구축할 때 발생하던 불편함과 비용 문제를 해소하고 저비용으로 탄력적이고 안정적인 IT 시스템을 구축할 수 있게 되었습니다. 또한 하드웨어, 네트워크 속도 발전으로 전체 시스템을 하나의 서비스로 통합할 필요 없이 작은 단위의 서비스로 분리해도 된다는 점이 부각되어 Micro services 구조가 나오게 되었습니다.

MSA 탄생 배경에 대해 간략히 보면 다음과 같습니다.

2005 : Cloud Computing Conference에서 "micro Web Service"
- 참고 : https://bit.ly/3UBPhgo
2011 : SW Architecture 워크샵에서 "Microservgice"라는 용어 탄생
2014 : James Lewis와 Martin Fowler가 Microservgices의 정의, 특징들을 정리
- 참고 : https://martinfowler.com/articles/microservices.html

이렇듯, MSA라는 개념 자체가 나온지는 오래되지 않았습니다.

Microservice Architecture 이란?

MSA는 앞서 얘기한 것 처럼 "하나의 어플리케이션을 다수의 독립적인 서비스들의 집합으로 구성하는 것" 입니다. MSA는 API를 통해서만 상호작용할 수 있는데, 서비스의 end-point를 API 형태로 외부에 노출하고, 실질적인 세부 사항은 모두 추상화합니다. 또한 내부 구현된 로직이나 사용된 기술 스택들은 서비수 API에 의해 철저하게 가려지게 됩니다. 따라서 SOA(Service Oriented Architecture)의 특징을 각각 가지게 됩니다.