MSA 개요

문성하·2024년 1월 3일

MSA 아키텍처

MSA 란 무엇이며 과연 정답이 있는가?

MSAMSA는 마이크로 서비스 아키텍처로 하나의 서비를 여러 작은 서비스로 나누어진 형태의 아키텍처를 의미합니다. 각 서비스는 독립적으로 느슨한 결합의 형태를 유지합니다.

등장배경monolitic -> SOA -> MSA모놀리식 아키텍처: 소프트웨어의 모든 구성 요소가 하나로 결합된 형태SOA : 서비스 지향 개발방식, 서비스 단위로 개발, 재사용성 높힘MSA : 아주 작은 서비스로 나누어진 아키텍처 - SOA와 달리 서비스의 재사용이 없습니다.(독립적)

정답이 있는가?MSA는 서비스를 작게 나누어 작은 서비스 단위로 개발, 배포되다보니 기존 모놀리식 방식에 비해 설계 및 구축이 어렵습니다. 반면 모놀리식 방식은 방법이 고착화되어 설계 및 유지보수가 편리합니다. 이러한 단점에도 많은 IT 선두주자들이 MSA를 채택하는 것은 단점에 비해 장점이 많기 때문입니다. 지금 당장은 모놀리식 아키텍처를 선택하는 것이 기업 이윤에 득이 될 수 있지만, 결국 회사 혹은 서비스의 규모가 커지면 MSA로 바꾸는 것이 불가피해집니다. 결국 선택해야 할 MSA라면 서비스를 시작하지 않았거나 서비스의 규모가 작을 때 바꾸는 것이 현명합니다.

MSA 왜 하는가? 무엇이 좋아 지는가?

MSA의 장점은 독립된 서비스라는 것으로부터 나오게 됩니다.

서비스 개별 배포 가능

각 서비스가 독립적이기 때문에 배포 시 전체 서비스의 중단 없이 해당 부분만 개별 배포가 가능합니다.

확장성

각 서비스가 독립적이기 때문에, 하나의 서비스에 새로운 기술을 적용시킬 수 있습니다. 새로운 언어나 프레임워크를 적용할 수 있는 장점이 있습니다.

장애 확산

기존 모놀리식 아키텍처는 일부 장애가 전체 서비스의 장애로 확산될 가능성이 있습니다. 또한 이러한 장애는 서비스의 규모가 클 수록 디버그하기 쉽지 않습니다.MSA는 각 서비스가 독립적이기 때문에, 일부 장애가 전체 서비스의 장애로 확산될 가능성이 낮습니다. 또한, 각 서비스에서 발생한 장애를 빠르게 찾고, 대처할 수 있습니다.

유연한 개발

각 서비스가 독립적이기 때문에, 서비스 별로 개발을 진행할 수 있습니다.

부분적 scale-out 쉬움

각 서비스에 대해 트래픽 처리량이 많은 서비스만 따로 scale-out하는 것이 쉽습니다.

MSA를 어떻게 해야 하는가?

모놀리식 아키텍처에서 MSA로의 전환은 운영 및 개발 조직에 많은 변화를 불러옵니다. 운영 조직은 하나의 서비스를 관리하다 독립된 여러 서비스를 관리하게 되어 많은 오류와 직면하게 됩니다. 개발팀도 이런 오류속에서 잦은 트러블슈팅에 직면하게 됩니다.
이러한 상황에 맞추어 DevOps라는 방식이 생겨나게 됩니다.
DevOps는 Development(개발)과 Operations(운영)의 합성어로, 개발과 운영이 동시에 이루어지는 체인 구조를 말합니다. MSA에서 DevOps는 속도, 안전성, 확장성 등에서 여러 이점을 가져오게 됩니다.

MSA를 효율적으로 하기 위한 조직 구조 및 문화는 ?

DevOps팀을 따로 만들어 운영하는 것 보다는 Dev팀과 OPs팀을 하나의 조직으로 결합하는 것이 바람직합니다.

DB 왜 분리 해야 하는가?

데이터베이스를 공통으로 사용하게 된다면, 각 서비스가 데이터에 대한 동시 수정 시 오류가 생길 수 있으며, 트래픽이 많아 DB 접근이 많을 시 서비스 전체에 악영향을 줄 수 있습니다.
데이터베이스를 각 서비스별로 분리한다면, 각 서비스별로 필요한 데이터만을 저장해 CRUD에 대해 빠른 속도를 얻을 수 있으며, 각 서비스에 맞는 데이터베이스를 사용할 수 있습니다.