프로젝트를 진행 중이다.
프로젝트의 규모가 커질 수록 계층 간 DTO 객체를 이용하는 일이 많아졌다. 불변 객체를 적절히 설계해야 할 필요를 느끼며 최대한 클래스 설계를 잘했다.
리뷰를 받던 중 MAS 아키텍쳐에 대해 알게 되었다. 데이터 정합성 관련 문제가 생길 수 있지만 한번 개념에 대해 정리해보고 수정을 해볼 생각이다.
보편적인 아키텍처
모놀리식 아키텍쳐 (Monolithic Architecture)
우리가 많이 보아온 형태이다!
소프트웨어의 모든 구성 요소가 하나로 통합되어 있는 형태
주로 소규모 프로젝트에서 사용한다. 규모가 커질 경우 한계가 드러남
장점
- 단순한 아키텍처로 개발이 쉽다
- 복잡하지 않고, 배포가 간단하다
- 확장성이 쉽다
- 고가용성 서버를 쉽게 구현할 수 있다
단점
- Scale out이 어렵다
- 서비스의 변경이 어렵고 수정에 대한 영향 파악이 어렵다
- 배포 시간이 오래 걸린다
- 프레임워크와 언어에 종속적이다
마이크로 서비스 아키텍처 (Micro Service Architecture)
하나의 큰 애플리케이션을 여러 개의 애플리케이션으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처이다
특징
- 서비스 하나마다 모놀리식 아키텍처와 유사한 구조를 지님
- 서비스는 독립적으로 배포 가능해야 함
- 다른 서비스에 대한 의존성이 작다
- 각 서비스는 개별 프로세스로 구동되며, Rest API와 같은 가벼운 방식으로 통신되어야 한다
장점
- 서비스 별 개별 배포가 가능해 개발자의 자율성 증가 및 빠르게 배포 가능함
- 특정 서비스에 대한 확장성이 용이해 클라우드 사용에 적합하다
- 장애가 전체 서비스로 확장될 가능성이 적고, 격리가 쉬움
- 코드의 이해도도 증가하고 유지보수가 쉽다
- 신기술의 적용이 유연하다
단점
- 서비스 간 호출 시 API를 사용하므로 통신 비용 증가 및 지연 시간 증가
- 데이터를 한 번에 조회하기 어렵고, 정합성 관리가 어렵다
- 통합 테스트에 시간과 비용이 많이 든다
- 트랜잭션을 구현하기 까다롭다
- 아키텍처의 복잡성으로 개발 및 관리가 어렵고 유지 비용이 많이 든다
MSA 환경에서 내 API의 동작
엊그제 이메일 인증번호 전송 및 검증 API를 만들었다.
트래픽이 몰릴 경우를 대비해 비동기 방식을 채택해 메서드를 정의했다.
나의 아키텍처는 레이어 아키텍처이다 모놀리식 아키텍처이다.
근데 MSA 환경에서는 어떤 식으로 동작할까?
우선 데이터 정합성 문제가 가장 큰 이슈일 것 같다.
메일을 보내고 나서 redis에 인증 번호와 이메일을 저장하는데 msa 환경에서는 DB도 스키마 별로 나뉘므로 정합성을 지키기가 쉽지 않을 것 같다.
1. 일반 DBMS에 저장을 해야 하는지
2. 뷰를 생성해 API 별로 공유를 하던지
=> 뷰는 하나의 유저 테이블이 뷰를 정기적으로 업데이트하면 될 것 같다.
이런 식으로 정합성 관련 문제를 해결할 수 있을 것 같다.
반응형
'🏛️ Architecture' 카테고리의 다른 글
[만들면서 배우는 클린 아키텍처] Chapter10. 아키텍처 경계 강제하기 (0) | 2022.11.15 |
---|---|
[만들면서 배우는 클린 아키텍처] Chapter9. 애플리케이션 조립하기 (0) | 2022.11.11 |
[만들면서 배우는 클린 아키텍처] Chapter6. 영속성 어댑터 구현하기 (0) | 2022.10.31 |
[만들면서 배우는 클린 아키텍처] Chapter5. 웹 어댑터 구현하기 (0) | 2022.10.30 |
Layered & Domain Architecture 란 무엇일까? (0) | 2022.05.03 |