
MSA: Micro Service Architect
소프트웨어 아키텍쳐 중 하나로, 독립적으로 구성 가능한 작은 단위의 서비스로 구성된 어플리케이션 구조를 말한다.
기존 서비스의 아키텍쳐는 시스템(인프라) 위에 어플리케이션(프로그램) 올라가서 하나의 어플리케이션이 되는 아키텍쳐를 Monolitic 시스템, 즉 단일 시스템이라고 불렀다.
여기서 마이크로 서비스 아키텍쳐로 왜 쪼개지는지에 대해서 생각해볼 수 있다.
마이크로 단위의 기준이 뭘까?
어디까지 단위를 마이크로 서비스라고 하나?
무조건 쪼갠다고 하는 게 정답인가?
쪼개면 뭐가 좋아지냐?

일단 시스템을 쪼개면 쪼갠 단위에서 각각 호출하고 사용할 수 있다.
대부분의 서비스는 서로 연동되어 있고, MSA의 철학도 각각 통신을 하는 것을 목표로 한다.
마이크로 서비스로 쪼개면 API 호출이 많아지는데,
API 호출이 많아지면 서버의 비용이 높아질 가능성이 높다.
그렇다면 왜 금융, 제조, IT 전부 MSA 외치는 이유가 뭘까?
뭐가 좋아질까??
우선 장애에 강해진다.
극단적으로 좋은 측면만 생각해보면 넷플릭스 같은 곳에서 큰 장애가 발생하면 전체 서비스가 다운될 수 있다. 이때 MSA에서는 전체 서비스가 모듈화를 통해 한 모듈이 다운되어도 나머지 서비스는 동작하게 해서 전체 사이트 장애를 막을 수 있다.
1. 효율적인 인프라
인프라 증설시 필요한 인프라만 확장할 수 있다.
어떤 서비스에서 회원이 엄청 늘어나고 서비스도 엄청 늘어나면 인프라도 늘려야 된다.
서비스 기능 중에 특정 기능이 엄청나게 호출되고 있을 때, 이 기능에 탑재된 인프라만 늘리면 효율적인 인프라를 관리할 수 있다.
2. 잦은 배포에 특화
빈번한 업데이트가 이뤄지는 모듈이 있다고 할 때, 모듈 단위 업데이트를 할 수 있다.
이를 담당하는 팀이 DevOps 팀이다.
다른 팀과의 연동에서 반드시 상호작용과 커뮤니케이션이 필요하다.
왜 도입됐을까
글로벌 기업, 선진 기업에서 DevOps, Agile 전략을 키워나가면서 MSA 키워드가 대두됐다.
CTO, CIO 는 선진 사례를 받아서 적용해야 하는 역할이 컸다.
한동안 빅데이터라는 키워드로 업계에 빅데이터가 도입이 됐다.
빅데이터 또한 잘 적용해서 이득을 본 기업도 있고, ROI(Return Of Investment)가 나오지 않는 투자로 손해를 본 기업도 있다.
현재 MSA 키워드는 빅데이터와 비슷한 사례로 선진 기업의 문화를 도입하면서 따라 흘러들어온 키워드로 볼 수 있다.
따라서 MSA를 도입하기 전에 ROI를 미리 계산하고 MSA로 만들 생각을 해야 한다.
MSA로의 변화로 얻는 장단점이 분명하기에 도입할 때 신중할 필요가 있다.
검토의 가치는 분명히 있지만 신중히 검토해야 한다.
최근 IT에서 MSA가 핫했던 이유는 클라우드, 도커, 쿠버네티스로 이동하면서 MSA를 하기 적합한 구조의 인프라가 형성되고 있기 때문이다. 그래서 해볼만 하긴 한데, 생각을 좀 하면서 도입할 필요가 있다는 내용.
관련 자료
기술노트님 너무 이해가 쏙쏙 잘되게 설명을 잘해주신다.
'개발 > 클라우드 | 인프라' 카테고리의 다른 글
[인프라] IT 인프라 정복하기 2편 - 네트워크 톺아보기 (0) | 2025.02.01 |
---|---|
[인프라] IT 인프라 정복하기 1편 - 서버 톺아보기 (0) | 2025.01.27 |
[클라우드] IaaS, PaaS, SaaS (0) | 2025.01.24 |
[클라우드] 하이브리드 클라우드 왜 쓸까 (0) | 2025.01.24 |
[클라우드] 클라우드와 데이터베이스의 차이 (0) | 2025.01.23 |