MSA란? 😯

Micro Service Architecture

MSA는 최신에 나온 개념이 아니다.

그런데 왜, IT 업계 뿐만 아니라 다양한 업계에서 ‘Micro Service’에 꽂혀있을까? 왜 이렇게 핫할까?

아키텍쳐 관점에서 어떤 차이가 있는지, 어떤 공부와 준비가 필요한지에 대한 내용을 정리해보았다.

기존 시스템

어플리케이션 하나를 구성하는 것들로 크게 나누자면 화면, API, 회원 정도로 볼 수 있다.

더 세분화 해보자면, 화면은 PC와 Mobile로 나눌 수 있고

API는 서비스를 이루는 데 필요한 기능별로(결제, 정산, 조회 등) 나눌 수 있을 것이다.

이처럼 기존의 어플리케이션은 모든 구성요소들이 한 프로젝트에 통합되어 있는 형태로, 모놀릭스 아키텍쳐 형태였다.

• 모놀릭스 아키텍쳐(Monolithic Architecture) = 하나의 단일 시스템

왜 마이크로로 바뀌고 있는가?

모놀릭스는 하나의 큰 덩어리라고 하면, 마이크로 서비스는 작은 컨테이너 사이즈라고 볼 수 있다.

• MSA 철학은 서로 간의 통신을 한다는 것! (API 함수 호출 등)

• 단순하게 생각했을 때,

  복잡도 측면 🆙 (작은 단위로 쪼개어져 호출이 많아진다)

  비용 측면 ❓ (올라갈지, 떨어질지 모르지만 API 호출이 많아지면 결국 서버 전사용량이 늘어나기 때문에 올라갈 가능성이 높다)

아니 그럼 뭐가 좋아지는데..? 왜 전부 다 마이크로 서비스를 외치는거야?!

MSA가 좋은 점 🙂

1. 장애에 강하다

넷플릭스 같은 큰 서비스의 한 모듈에 장애가 나서 전체 서비스가 다운됐다고 가정해보자.

한 곳이 다운되어도 나머지 서비스는 이상없이 서비스가 되도록 해야한다.

마이크로 서비스로 기능 단위로 쪼개어 서비스가 되면, 전체 서비스 장애를 막을 수 있다. (분할 측면의 의미)

2. 인프라 확장에 용이하다

기존 서비스에서 회원 증가하고, 서비스도 늘어나고, 인프라도 늘리고 있는 상황이라고 가정해보자.

이 때, 결제, 정산 서비스 기능의 변경은 거의 없고 ‘조회’ 서비스의 이용이 급격하게 늘어나고 있을 때, ‘조회’ 인프라만 늘리면 더 효율적이다.

또한, 인프라 증설 시에 필요한 기능만 확대할 수 있다. (오토 스케일링 도입)

3. 배포 시 특정 기능만 배포 가능

빈번한 업데이트 및 배포가 이루어지는 모듈이 특별히 주어져 있을 때,

‘결제’, ‘정산’ 서비스 기능의 변경은 거의 없고 ‘조회’만 기능이 계속 업데이트 될 때,

‘조회’ 팀을 따로 만들어 조회 기능에 대해서만 발전시키고 업그레이드 하는 것을 전담할 수 있다. (다른 서비스와의 상호 커뮤니케이션은 반드시 필요하다.)

따라서, 전체 코드를 한번에 빌드할 필요가 없고 다른 기능은 정상적으로 쓰면서 빈번하게 업데이트 되는 기능 부분만 빌드가 가능하다.

도출되는 안좋은 점 ☹️

지금의 MSA가 좋은 것도 있지만 단점은 분명하다는 점!

“복잡도는 증가했는데, 비용은 그대로”

레거시를 충분히 유지해도 되는데 굳이 바꿔서 어떤 점이 좋아지는지 의구심이 든다..🤔

MSA 도입에 있어서는 분명한 ROI(Return Of Investment)

즉, 투자대비효과가 어떤 측면에서 반드시 있다는 것을 미리 계산한 다음에 도입해야 한다!

1. 어플리케이션부터 인프라단까지 다 수정 필요하고,
2. 관리해야 할 요소가 늘어나고,
3. 준비된 팀이 아닌 이상 괜히 도입했다가 장애가 일어날 수 있다.

MSA에 대한 결론 💁‍♀️

1. 검토할 가치는 항상 있다. 프로젝트 규모가 커질수록, 배포가 빈번한 기능이 뚜렷하게 있다면, MSA로 인해 고질적인 문제가 해결될 수도 있다. (배포가 빈번한 팀만 야근한다던지..🌚)
2. 요즘은 MSA에 적합한 인프라들(클라우드, 도커, 쿠버네티스 …)이 형성되는 중이기 때문에 확장성에 있어서 더 열려있다. 🚪
3. 엄청난 규모의 서비스인 입장에서는 MSA가 맞을 수 있지만, 기존 시스템에서 잘 굴러가는 서비스에서 무조건적으로 MSA를 도입할 필요는 없다. 충분히 계산한 후에 도입해도 늦지않다! 🐌