FTGO 애플리케이션 아키텍처
모놀리스(monolith): 일체형
비즈니스 로직
- 각자가 도메인 객체 컬렉션인 모듈(예: 주문 관리, 배달 관리, 과금, 지불)로 구성됨
- 외부 시스템과 연계하는 어댑터
- REST API, 웹 UI 어댑터 등 비즈니스 요청을 호출하여 처리하는 인바운드 어댑터
- 비즈니스 로직에서 MySQL DB에 접근하거나 트윌리오, 스트라이프 등 클라우드 서비스를 호출하게 해주는 아웃바운드 어댑터
모놀리식 아키텍처의 장점
규모가 작은 초기에는 모놀리식 아키텍처의 장점이 많았음
- 개발이 간단
- 애플리케이션을 쉽게 변경할 수 있음
- 테스트하기 쉬움
- 배포하기 쉬움
- 확장하기 쉬움
하지만 시간이 흐를수록 개발, 테스트, 배포, 확장하기가 쉽지 않음
모놀리식 지옥의 실상
- 너무 복잡해서 개발자가 주눅 듬
- 개발이 더딤: IDE 실행 속도 저하, 빌드 시간 늘어남. -> 코드 수정 후 빌드/테스트까지 시간이 낭비
- 커밋부터 배포가 너무 험난함
- 확장하기 어려움
- 모놀리스는 확실하게 전달하기가 어려움: 테스트성이 부족해서 신뢰성이 부족함. 결함 격리(fault isolation)가 어려움.
- 갈수록 한물간 기술 스택에 발목 잡힘
확장 큐브와 마이크로서비스
- X축 확장: 다중 인스턴스에 고루 요청 확산
- Z축 확장: 요청 속성별 라우팅
- Y축 확장: 기능에 따라 애플리케이션을 서비스로 분해
마이크로 서비스는 모듈성을 갖고 있다
모듈성(modularity)는 크고 복잡한 애플리케이션을 개발할 때 꼭 필요한 특성
마이크로서비스 아키텍처는 서비스를 모듈성의 단위로 사용함. 각 서비스는 API라는 경계선을 갖고 있어서 다른 서비스 내부 클래스에 마음대로 들어올 수 없음. 시간이 지나도 모듈성을 유지하기가 훨씬 수월함.
마이크로서비스와 SOA
SOA: Service Oriented Architecture; 서비스 지향 아키텍쳐
두 아키텍처 모두 시스템을 여러 서비스로 구성하는 아키텍처 스타일임. 그러나 근본적인 차이점이 있음
마이크로서비스의 장점
- 크고 복잡한 애플리케이션을 지속적으로 전달/배포 가능
- 서비스 규모가 작아 관리하기 쉬움
- 서비스를 독립적으로 배포/확장 가능
- 마이크로서비스 아키텍처 덕분에 팀이 자율적으로 움직임
- 결함 격리가 잘 됨
- 새로운 기술을 실험하고 도입하기 쉬움
크고 복잡한 애플리케이션을 지속적으로 전달/배포 가능
MSA는 테스트성, 배포성, 자율성(느슨한 결합)으로 지속적 전달/배포를 실현함
- 테스트성: 서비스 크기가 작아서 자동화 테스트를 작성하기 쉽고 더 빨리 실행됨
- 배포성: 독립적으로 배포할 수 있어서 자신이 담당한 서비스 변경분을 배포할 때 다른 개발자와 협의할 필요가 없음
- 자율성(느슨한 결합)
지속적 전달/배포의 이점?
- 프로덕트를 시장에 내놓는 시기를 앞당길 수 있음 -> 현장의 고객 피드백을 신속히 대응 가능
- 현재 고객들이 기대하는 수준으로 신뢰성있는 서비스를 제공할 수 있음
마이크로서비스의 단점
- 딱 맞는 서비스를 찾기가 쉽지 않음
- 분산 시스템은 너무 복잡해서 개발, 테스트, 배포가 어려움
- 여러 서비스에 걸친 기능을 배포할 때에는 잘 조정해야 함
- 마이크로서비스 아키텍처 도입 시점을 결정하기가 어려움
'컴퓨터 공학 > 소프트웨어 공학' 카테고리의 다른 글
[마이크로서비스 패턴] 분해 전략 (0) | 2022.08.24 |
---|