1 분 소요

몇 년 전부터 MSA에 대한 주제가 대두되고 있다고 해서 이에 대해 더 자세히 알아보고, 현재 진행 중인 프로젝트에 적용을 시도할 만한지 확인해보고자 했다.

📚 모놀리식 아키텍처(Monolithic Architecture)

모놀리식 아키텍처는 전통적인 방식으로 하나의 프로젝트에 모든 기능이 포함되어 있는 형태를 가진다.

출처 : [https://mozzi-devlog.tistory.com/34](https://mozzi-devlog.tistory.com/34)

출처 : https://mozzi-devlog.tistory.com/34

하나의 프로젝트로 전체 어플리케이션을 묶어서 개발하기 때문에 비즈니스 로직이 추가될 수록 코드 베이스가 커지게 되는 구조이다.

장점

  • 초기 개발에 유리하고 빠르게 프로토타입을 개발할 수 있다.
  • 모든 기능을 한 번에 호출해서 복잡한 통신 없이 사용할 수 있다.

→ 간단한 사이드 프로젝트나 단기 프로젝트에 적합하다.

단점

  • 일부 기능을 수정하거나 업데이트를 하려면 전체 어플리케이션을 재배포 해야한다.

📚 마이크로 서비스 아키텍처(Micro Service Architecture)

여러 개의 작은 단위의 서비스로 나누어 각 서비스가 독립적으로 개발되고 배포되는 구조이다.

출처 : [https://mozzi-devlog.tistory.com/34](https://mozzi-devlog.tistory.com/34)

출처 : https://mozzi-devlog.tistory.com/34

서비스를 쪼갰을 때의 변화

웬만한 어플리케이션에서 각 비즈니스 로직들은 서로 상호작용을 한다. 서로의 기능과 값을 사용하기 위해서는 서비스 간 통신이 필요하고, 그에 따라 연결 구축 및 관리의 복잡도는 증가할 수 밖에 없다.

비용적 측면에서 바라봐도 서로 간의 통신을 위해 API 등이 많이 호출이 되면 WAS의 전체 사용량을 늘리기 때문에 유지 보수의 장점을 고려하더라도 비용이 늘어날 가능성이 높다.

MSA의 장점은?

  1. 서비스 장애 발생에 대응이 쉽다.

    모놀리식의 경우 서비스의 어느 한 부분에 장애가 발생했을 때 전체 서비스가 사용 불능이 된다면 큰 문제가 발생할 수 있는데, msa의 경우 고장난 일부분의 서비스만 잠시 막아두고 처리하면 되므로 큰 피해가 발생하지는 않는다.

  2. 효율적인 인프라 구축이 가능하다.

    비즈니스 로직에서 조회, 결제, 정산이 기능이 있을 때 조회가 전체 사용량의 90%를 이룬다고 가정을 하자. 그러면 조회 서비스에 대한 인프라만 늘리는 방식으로 효율성을 높일 수 있다.

  3. 빈번한 배포에 유리하다.

    이 경우에도 조회 서비스만 빈번하게 업데이트가 발생한다고 했을 때, 해당 서비스만 재배포하면 되므로 조회 서비스에 대한 팀을 따로 꾸려 Devops를 기반으로 지속적인 개발과 통합을 진행하면 된다.

그렇다면 MSA를 무조건 도입해야 하는가?

옛날 빅데이터가 핫한 이슈로 떠올랐을 때 많은 회사에서 이를 도입했고, 어느 회사는 이를 유의미하게 활용하고 어느 회사는 빛 좋은 개살구가 되었다고 한다. ROI(Return Of Investment), 투자 대비 얻는 수익을 고려하여 해당 어플리케이션에 MSA가 적용되기 적합한 지를 잘 판단해야 한다.

참고


https://www.youtube.com/watch?v=dSGnJWHuxtQ

https://mozzi-devlog.tistory.com/34

댓글남기기