MSA
in Web-Programming on MSA
MSA
MicroServices Architecture: 마이크로 서비스 구조
하나의 애플리케이션을 여러 개의 독립적인 서비스로 분리하여 개발, 배포, 유지 보수를 용이한 소프트웨어 아키텍처 스타일이다. 서비스들은 각자의 특징 비즈니스 로직 서비스 기능을 수행하고 따로 독립하여 배포랑 확장을 할 수 있다. 서비스들간의 통신은 HTTP/HTTPS/메세지 큐 등을 이용하여 통신을 하게된다.
- 독립적인 배포, 다른 서비스에 영향 없음
- 소규모 팀 구성의 개발 관리 가능
- 기술 스택 다양성
기존 개발 방식과 차이
기존 개발 방식을 모놀리식(Monolithic)이라 한다. 이 모놀리식은 한 어플리케이션 내 여러가지 서비스 들이 뭉쳐져 있는 개발 방식이다. 당장 최근에 한 팀 프로젝트가 기존 대로 개발해왔던 방식이다. 이 프로젝트를 통해 기존 개발 방식을 나열하자면…
- 어플리케이션을 개발/테스트/빌드 하기 위해 환경을 일괄로 맞춘다.
- 단순히 한 어플내에서 개발하는 구조를 갖춘다.
- 단일 DB로 관리한다.
정도 되시겠다. 그럼 MSA와 차이는 무엇일까?
구조는 위의 그림과 같이 차이가 난다. MSA는 기존 모놀리식과는 달리 기능별 서비스를 나누어서 관리하고 배포할 수 있으며, 각 서비스별 환경을 따로 통일시키지 않고 코드를 확장할 수 있는 유연성을 가지고 있다. 그러나 전체적인 구조로 본다면 기존 모놀리식에 비해 각 서비스별로 관리해야할 주체가 많아 지고 그에 따른 DB 관리도 별도로 많아지게 된다. 즉 관리 및 운영의 난이도가 높아진다고 할 수 있다. 이 내용을 요약하자면 아래 표와 같다.
| 구분 | MSA | 모놀리식 |
|---|---|---|
| 서비스 기능 위치 | 각 서비스별로 개발 | 한 어플리케이션 내에서 개발 |
| 개발 환경 | 각 서비스별 독립적인 환경 구축 | 개발 환경 일치 후 개발 |
| 확장성 | 기능 추가 및 수정에 다른 서비스에 영향이 없으므로 유연하게 확장 가능 | 하나 수정하면 전체적인 영향 발생 가능, 따로 확장이 힘듦 |
| 배포 | 각 서비스 별 배포 가능 | 하나 바뀌면 전체를 배포, 그러나 단순히 배포할 수는 있다. |
| DB | 각 서비스 별 별도 DB 필요 | 단일 DB로 관리 |
| 관리 | 각 서비스 별 관리 대상, 운영 비용 증가 | 단일 어플리케이션 관리, 그러나 비대해지면 더 곤란해짐 |
그래서 MSA인가?
MSA란 트렌드를 따라잡기 위해선 MSA로 개발해야한다 라는 것은 주의해야 한다. 어떤 구조로 개발해야 하는 가에 대해선 먼저 생각해야 할 것이 있다.
- 개발하려는 목표의 유형
- 주어진 예산과 시간 그리고 자원
- MSA에 대한 경험
- 개발발 후 사후 관리에 대한 확장성
무엇을 개발하고 확장시켜 갈 수 있는가? 주어진 자원 내에서 어떤 구조로 개발하면 좋을 것인가? MSA에 대해서 정확한 개념과 능력을 녹여내어 관리 할 수 있는가에 따라 개발 구조 방향성을 정하면 되겠다. 모놀리식으로 쭉 가던가, 모놀리식에서 MSA로 전환하여 뜯어 고친다던가, 아니면 처음부터 MSA로 가면서 이어가던가, 선택은 개발자들의 두뇌에서 나오게 될 것이다. 이 두뇌들이 고뇌가 되어 막막하게 느낀다면, 아래의 질문을 통해 분석을 해본다.
- 개발 어플리케이션이 크고 복잡해질 가능성이 있는가?
- 해당 개발 도메인에 대해서 잘 알고 있는가?
- 가용성 및 확장성을 갖춰야하는 개발인가?
- MSA에 대한 경험이 있는가?
위 질문에 대한 답이 모두 맞다면 MSA에 더 적합할 것이다.
