MSA 구조에대해

출처: https://velog.io/@dmchoi224/Microservice-Architecture-MSA-%EA%B7%B8%EB%A6%AC%EA%B3%A0-Monolithic

ㅇ MSA란

마이크로서비스 아키텍처(MSA)는 소프트웨어 개발 방식 중 하나로, 하나의 큰 애플리케이션을 독립적으로 배포 및 운영이 가능한 작은 서비스들로 분할하여 개발하는 방법이다. 각 서비스는 독립적으로 개발, 배포, 확장될 수 있고, 전통적인 모놀리식 아키텍처와 대조된다.

MSA의 주요 특징

1. 독립성: 각 서비스는 독립적으로 배포 및 확장 가능하고, 다른 서비스와 독립적으로 개발될 수 있음.
2. 작은 단위: 각 서비스는 특정 기능이나 도메인에 집중하여 설계된다.
3. 경량 통신: 서비스 간 통신은 주로 HTTP/REST 또는 메시징 큐를 통해 이뤄짐.
4. 데브옵스와 CI/CD: 자동화된 배포 파이프라인과 지속적인 통합 및 배포(CI/CD)를 통해 빠른 배포가 가능하다.
5. 폴리글롯 프로그래밍: 각 서비스는 각기 다른 프로그래밍 언어와 기술 스택을 사용할 수 있음.

MSA의 장점

1. 확장성: 각 서비스가 독립적으로 확장 가능하여 트래픽 증가에 유연하게 대응할 수 있다.
2. 유연성: 서비스별로 독립적인 배포 및 업데이트가 가능해서 새로운 기능 추가와 버그 수정이 신속하게 이뤄짐.
3. 탄력성: 하나의 서비스에 문제가 발생하더라도 전체 시스템에 영향을 최소화할 수 있음.
4. 개발 생산성 향상: 작은 단위로 나누어 개발하기 때문에 팀 간 협업이 수월하고, 개발 속도가 향상됨.

MSA의 단점

1. 복잡성 증가: 서비스가 많아질수록 서비스 간 통신, 데이터 관리, 트랜잭션 관리가 복잡해질 수 있음.
2. 운영 부담 증가: 각 서비스의 배포, 모니터링, 로깅 등 운영 작업이 복잡해질 수 있다.
3. 데이터 일관성: 분산 시스템에서 데이터 일관성을 유지하는 것이 어려울 수 있다.

MSA의 구현 방법

1. 서비스 분할: 시스템을 기능별로 나누어 각 기능을 독립적인 서비스로 설계한다.
2. API 게이트웨이: 모든 서비스 요청을 중앙에서 관리하는 API 게이트웨이를 구축하여 서비스 간 통신을 관리함.
3. 데이터베이스 분할: 각 서비스는 독립적인 데이터베이스를 가질 수 있고, 필요에 따라 데이터 일관성을 유지하는 메커니즘을 구현함.
4. 모니터링과 로깅: 각 서비스의 상태를 실시간으로 모니터링하고, 로그를 수집하여 문제 발생 시 신속히 대응할 수 있는 환경을 구축한다.

 

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

모놀리식 아키텍처는 전통적인 소프트웨어 개발 방법으로, 애플리케이션의 모든 기능이 하나의 코드베이스와 배포 단위로 통합되어 있는 구조. 모든 모듈이 단일 애플리케이션으로 결합되어 있고, 이는 개발, 배포, 확장, 유지보수에서의 여러 특성을 가지고 있다. 여태껏 내가 만들어온 프로젝트도 전부 모놀리식 아키텍처라고 볼 수 있다.

주요 특징

1. 단일 코드베이스: 모든 기능과 모듈이 하나의 코드베이스에 포함됨.
2. 단일 배포 단위: 애플리케이션이 하나의 배포 단위로 패키징되어 배포됨.
3. 통합된 데이터베이스: 일반적으로 하나의 통합된 데이터베이스를 사용한다.
4. 높은 결합도: 모듈 간의 의존성이 높아 변경이 어려울 수 있다.

장점

1. 단순성: 초기 개발과 배포가 비교적 간단하다. 모든 기능이 한 곳에 모여 있기 때문에 설정과 관리가 단순하다.
2. 일관된 성능: 단일 코드베이스와 데이터베이스를 사용하기 때문에 데이터 접근 속도가 빠르고 일관성이 유지된다.
3. 개발 환경: 개발자들이 하나의 코드베이스에서 작업하기 때문에 협업이 용이하며, 통합 테스트와 디버깅이 상대적으로 쉬움.
4. 보안: 모든 코드가 한 곳에 있기 때문에 보안 관리가 비교적 용이함.

단점

1. 유연성 부족: 애플리케이션의 일부분을 변경하거나 업데이트하려면 전체 애플리케이션을 다시 빌드하고 배포해야 한다.
2. 확장성 문제: 특정 기능에 대한 트래픽이 증가하면 전체 애플리케이션을 확장해야 하므로 자원 낭비가 발생할 수 있음.
3. 유지보수 어려움: 코드베이스가 커짐에 따라 이해하고 유지보수하는 것이 어려워질 수 있다. 변경 사항이 다른 부분에 영향을 미칠 가능성이 높다.
4. 배포 위험성: 하나의 서비스에 문제가 발생하면 전체 애플리케이션이 영향을 받을 수 있다.

 

프로젝트 구조의 비교

ㅇ 평소 만들던 애플리케이션의 구조 - 모놀리식 아키텍처

src
└── main
    ├── generated
    └── java
        └── com
            └── helfit
                └── wodiary
                    └── domain
                        ├── authority
                        ├── exercise
                        │   ├── controller
                        │   ├── dto
                        │   ├── entity
                        │   ├── repository
                        │   └── service
                        ├── user
                        │   ├── controller
                        │   ├── dto
                        │   ├── dummy
                        │   ├── entity
                        │   ├── repository
                        │   └── service
                        └── wsession
                            ├── controller
                            ├── dto
                            ├── entity
                            ├── repository
                            └── service
                    ├── exception
                    ├── security
                    └── WodiaryApplication
└── resources
└── test

 

ㅇ MSA 구조

msa-project
│
├── user-service
│   ├── src
│   │   ├── main
│   │   │   ├── java
│   │   │   │   └── com.example.user
│   │   │   │       ├── controller
│   │   │   │       ├── dto
│   │   │   │       ├── entity
│   │   │   │       ├── repository
│   │   │   │       └── service
│   │   │   └── resources
│   │   │       └── application.yml
│   └── test
│
├── exercise-service
│   ├── src
│   │   ├── main
│   │   │   ├── java
│   │   │   │   └── com.example.exercise
│   │   │   │       ├── controller
│   │   │   │       ├── dto
│   │   │   │       ├── entity
│   │   │   │       ├── repository
│   │   │   │       └── service
│   │   │   └── resources
│   │   │       └── application.yml
│   └── test
│
├── auth-service
│   ├── src
│   │   ├── main
│   │   │   ├── java
│   │   │   │   └── com.example.auth
│   │   │   │       ├── controller
│   │   │   │       ├── dto
│   │   │   │       ├── entity
│   │   │   │       ├── repository
│   │   │   │       └── service
│   │   │   └── resources
│   │   │       └── application.yml
│   └── test
│
└── api-gateway
    ├── src
    │   ├── main
    │   │   ├── java
    │   │   │   └── com.example.gateway
    │   │   │       └── GatewayApplication.java
    │   │   └── resources
    │   │       └── application.yml
    └── test

 

 

MSA구조로 만들면 각 설정(yml, build.gradle 등)이 따로 있어야하고, 포트번호도 다 달라진다.
어떻게 동작하는지는 추후에 더 알아봐야겠다.

아직 MSA구조는 경험해보지 못했지만 블로깅을 해보니 궁금해졌다. 저번에 지원님네 회사에서도 도메인별로 따로 만든다하셨던게 이구조로 만든다는거였다는걸 알게됐다. 나도 한번 이렇게 만들어봐야겠다.