취업을 위해 모집 공고를 확인하다가 MSA란 단어를 발견했다.
이 MSA란게 도대체 무엇일까?
MSA란?
구글은 MSA(Microservices Architecture)를 다음과 같이 정의한다.
직역해보면,
"마이크로서비스 아키텍처는 어플리케이션이 서비스의 모음으로 개발되는 애플리케이션 아키텍처 유형이다. 이것은 프레임워크에게 마이크로서비스 아키텍처 다이어그램과 서비스를 개별적으로 개발, 배포 그리고 유지하게 해준다,"
여전히 무슨 말인지 이해되진 않는다. 그래서 이것저것 찾아보고 한줄로 정리해보면,
MSA: 소프트웨어 시스템을 여러 작은 독립적인 서비스로 분할하여 개발하고 배포하는 방식
딱 봐도 구현이 복잡해보인다는 것을 알 수 있다.
하지만 복잡해도 사용하는데는 다 이유가 있을 것이다.
MSA의 등장 배경
기업들은 더 안정적이고 유연한 IT 운영을 위한 고민한다.
그 일환으로, 기존의 Monolithic Architecture(MA)는 유지보수가 어렵고 확장성이 떨어지기에 새로운 아키텍처로써 MSA가 출현하였다.
Monolithic Architecture(MA)의 한계
- 하나의 애플리케이션으로 모든 기능을 처리하다보니 애플리케이션이 커지면서 복잡도 증가.
- 모든 변경이 애플리케이션 전체에 영향.
- 특정 기능에 대한 수요가 증가해도 전체 시스템을 확장.
- 단일한 기술 스택에 의존하기 때문에 새로운 기술 도입이 어려움.
그렇기 때문에 MSA를 도입함으로써 이러한 한계를 극복 할 수 있었다.
또한 클라우드 컴퓨팅의 발전으로 MSA 구현이 용이해진 것도 MA에서 MSA로의 변화를 가속화시켰다.
MSA의 특장점
- 독립적인 서비스: 각 서비스가 특정한 비즈니스 기능을 수행. (독립적으로 배포, 확장, 및 관리 가능)
- 느슨한 결합: 각 서비스는 다른 서비스와 최소한의 의존성만을 갖도록 설계되어 있기에, 업데이트시 하나의 서비스에만 영향. (안정성 향상)
- 다양한 기술 스택 사용: 각 서비스는 자체적인 기술 스택을 선택 가능. (새로운 기술 도입 용이)
- 스케일링 용이성: 각 서비스는 필요에 따라 개별적으로 확장 가능. (성능 최적화 및 트래픽 대응에 용이)
- 서비스 간 통신: 서비스 간의 통신은 주로 HTTP나 메시징 시스템을 통해 이루어짐. (상호작용 단순화 및 표준화)
사실상 MA의 한계를 극복하는 것이다!
초기의 단순한 구조가 아닌, 복잡도가 높은 시스템을 설계한다면 MSA가 필수적이다.
하지만 그만큼 개발자간의 커뮤니케이션이 중요해지기 때문에 기업에선 '소통'을 굉장히 큰 능력으로 보게 되는 것이었다..!
이전에 프로젝트를 진행 할 때, AWS에 배포하고 운영하며 과금이 된 적이 있었다.
그것을 보고 개발자 선배님이 "잘게 나눴어야지. 우리도 무료버전만 쓰는데!ㅋㅋ"라고 얘기했다.
그 때는 '코드를 어떻게 잘게 나누는거지??' 라고만 생각했었는데, 오늘 MSA에 대해 알아보니 서비스별로 나누었다면 과금이 되지 않았을 것 같다.
진행했던 프로젝트에 적용시켜 본다면 '알림 기능'과 '채팅 기능' 그리고 '회원가입 기능', 이 세가지는 서로 다른 서버를 띄워서 운영 할 수 있지 않았을까? 물론 다른 기능들을 더 잘게 나눌수도 있을 것 같다.
빨리 해보고싶다! 해보고 싶은건 많은데 빠르게 지나가는 시간이 야속하다.
출처
