작은 규모의 소프트웨어에서는 모놀리식이 장점이 많음
- 개발 편함
- 쉽게 변경
- 테스트 용이
- 배포 용이
- 업-다운 스케일 용이
서비스가 커지면서, 즉 프로그램 규모가 커질수록 위의 장점은 사라지고 단점들이 많아짐
- 너무 복잡해서 개발자가 주눅든다 (매우 공감…) 코드 베이스를 이해하기 힘듬 (만악의 근원)
- 자연스럽게 개발이 더뎌짐
- 자연스럽게 테스트가 오래걸림
- 자연스럽게 수정,배포가 어려움
갈수록 한물간 기술 스택에 발목 붙잡히다
아키텍쳐 때문에 어쩔 수 없이 점점 한물간 기술 스택을 쓸 수 밖에 없고, 그 특성상 최신 기술을 사용하고자 전체 모놀리식 어플리케이션을 재작성하는 것은 비용도 비용이고 리스크가 높아 그냥 따라갈 수 밖에없음
💡 == 신한카드의 IT 서비스의 현상황이라고 생각
💡 도입부에서 이미 박수 치고있었음 👏
MSA(마이크로 서비스 아키텍쳐)에서 마이크로 서비스의 단위는 사람마다 다름
확장큐브: 3차원 모델
- X축: 동일한 다중 인스턴스
- Y축: 기능에 따라 나누어 확장
- Z축: 요청 속성에 따라 요청 라우팅 (데이터 분할)
X축 확장 = 주로 모놀리식의 확장 수단
X/Z축 확장의 경우 어플리케이션의 능력과 가용성 개선
But, 복잡성에 대한 문제 해결X
⇒ 기능 분해가 필요하다
어플리케이션이 방대해지고 복잡해져 개인이 이해하고 개발하기 어려워지는 것을 막기 위해 모듈성을 지켜야함.
이를 위해 서비스가 다른 서비스를 침범하지 않게 하기 위해 경계선을 가져야함
- 서비스마다 DB도 따로 두어야함
SOA(서비스 지향 아키텍쳐) vs MSA
SOA MSA
| 서비스간 통신 | 엔터프라이즈 서비스 버스 중심의 스마트 파이프 | 메세지 브로커 또는 서비스 간 통신 중심의 덤 파이프 |
| 데이터 | 전역 데이터 모델 및 공유 DB | 서비스 개별 데이터 모델 및 DB |
💡 계정계, 채널계, 정보계, 등등 여러 시스템으로 나누어지고 이러한 시스템 간의 통신을 담당하고 있는 EAI, MCI 같은 구조를 보고 어떻게 보면 MSA 아닌가? 라는 생각을 했었는데, SOA가 맞는 것 같다.
MSA의 포인트
잘못 분해, 설계하면 모놀리식과 MSA의 단점만 가진 시스템 되어버림
분산 시스템이라는 또 다른 복잡성 생김
테스트가 어려워짐
서비스간의 Dependency 고려해야 함
서비스마다 DB를 따로 두었을 때 발생할 수 있는 문제에 대한 내용을 가볍게 언급했는데, 개인적으로 이에 대해 관심이 많아서 뒷 내용이 기대가 된다.
반응형
댓글