소프트웨어 아키텍처 – 모놀리식
MVC 패턴
- 정의: MVC는 Model, View, Controller의 약자로, 소프트웨어 디자인 및 아키텍처를 위한 패턴 중 하나이다.
- 구성 요소:
- Model: 데이터와 비즈니스 로직을 담당한다.
- View: 사용자 인터페이스를 표현한다.
- Controller: 사용자 입력을 처리하여 Model과 View를 관리한다.
- 특징:
- 각각의 구성 요소가 명확한 역할을 수행하면서 관심사를 분리하여 유지보수와 확장성을 증가시킨다.
- 주로 GUI 애플리케이션에서 사용되며, 사용자 입력에 따라 Model의 상태를 업데이트하고 이를 View에 반영하는 방식으로 동작한다.
- 변화에 대한 대응이 뛰어나며, 사용자 인터페이스와 비즈니스 로직의 분리를 통해 코드의 가독성을 높인다.
레이어드 아키텍처 (Layered Architecture)
- 정의: 소프트웨어를 여러 레이어로 나누어 각 레이어 간에는 명확한 인터페이스가 존재하도록 하는 아키텍처이다.
- 구성 요소:
- 프레젠테이션 레이어 (Presentation Layer): 사용자 인터페이스와 상호 작용하며 사용자 입력을 처리한다.
- 비즈니스 레이어 (Business Layer): 비즈니스 로직과 데이터 처리를 담당한다.
- 데이터 액세스 레이어 (Data Access Layer): 데이터베이스와의 상호 작용을 처리한다.
- 주요 특징:
- 레이어 간의 명확한 경계로 인해 독립적으로 개발, 유지보수 및 테스트 가능하다.
- 규모가 커져도 유지 보수성, 민첩성, 시험성, 배포성 등에서 우수한 성능을 보인다.
- 레이어 간의 관심사 분리로 각 레이어가 독립적으로 변경 가능하다.
- 도메인 변경이 어려울 수 있지만, 레이어 간의 분리로 인해 각 레이어의 역할이 명확하다.
- 레이어 간의 인터페이스를 통해 각 레이어가 독립적으로 확장 가능하다.
MVC 패턴의 장단점 비교
레이어드 아키텍처와레이어드 아키텍처의 장점:
- 유지 보수성 및 확장성: 레이어 간의 명확한 경계로 각 레이어가 독립적으로 개발 및 유지 보수 가능하며, 규모가 커져도 성능과 확장성이 우수하다.
- 테스트 용이성: 각 레이어를 독립적으로 테스트할 수 있어 전체 시스템의 안정성을 높인다.
- 관심사 분리: 각 레이어가 특정 역할에만 집중하므로 코드의 가독성을 향상시키고 유지보수를 쉽게 만든다.
레이어드 아키텍처의 단점:
- 도메인 변경 어려움: 특정 도메인을 변경할 때 모든 레이어에 수정이 필요하므로 변경이 어려울 수 있다.
MVC 패턴의 장점:
- 각 구성 요소 역할 명확: Model, View, Controller가 각각 데이터 관리, 사용자 인터페이스 표현, 사용자 입력 처리를 담당하여 역할이 명확하다.
- 변화 대응 용이: 변화에 빠르게 대응하며, 사용자 인터페이스와 비즈니스 로직의 분리로 코드 유지 보수성을 높인다.
MVC 패턴의 단점:
- 복잡성: 각 구성 요소 간의 통신과 협력이 많아질수록 복잡성이 증가할 수 있다.
- 프레임워크 의존성: 일부 프레임워크에 의존하게 되어 이를 준수해야 하므로 자유도가 제한될 수 있다.
레이어드 아키텍처의 적합성 – 미니프로젝트 진행
레이어드 아키텍처는 쇼핑몰과
같은 규모가 큰 웹 애플리케이션의 복잡한 요구 사항에 잘 부합한다. 쇼핑몰은 다양한 기능과 데이터를 관리해야 하므로 각 레이어의 분리와 명확한 역할이 중요하다. 레이어드 아키텍처는 이를 가능하게 하며 유지 보수성, 확장성, 테스트 용이성 등에서 우수한 성능을 보여준다. 특히 쇼핑몰은 사용자 경험과 성능이 중요한데, 레이어드 아키텍처는 각 레이어의 독립성을 통해 사용자 인터페이스 개선과 빠른 대응이 가능하다.
MSA
소프트웨어 아키텍처 –마이크로서비스 아키텍처 (Microservices Architecture)
- 정의: 마이크로서비스 아키텍처는 소프트웨어 시스템을 여러 작은 독립적인 서비스로 나누어 개발하고, 각 서비스가 독립적으로 배포되고 확장되며 연동되는 아키텍처 스타일이다.
주요 특징
- 각 마이크로서비스는 독립된 코드베이스, 데이터베이스, 비즈니스 로직을 가지며, 서로 영향을 주지 않고 독립적으로 배포 가능하다
1. 독립성
- 각 서비스는 자체 기술 스택을 선택할 수 있어 특정 서비스에 최적화된 언어와 프레임워크를 사용할 수 있다.
2. 다양한 기술 스택
- 독립적인 배포 가능성과 높은 자동화 수준으로 인해 신속한 개발 및 배포가 가능하며, 변화에 대응하기 용이하다.
3. 빠른 배포와 민첩성
- 특정 서비스에 대한 부하가 더 많은 경우 해당 서비스만 확장하여 자원을 효율적으로 사용할 수 있다.
4. 부분적인 확장성
- 지속적인 통합과 전달을 적극적으로 활용하여 작은 단위로 자주 배포되고 업데이트될 수 있어 빠른 개발 주기에 부합된다.
5. 지속적인 전달 및 통합
- 각 마이크로서비스가 독립적으로 실행되기 때문에 특정 서비스의 장애가 전체 시스템에 영향을 미치지 않도록 고가용성 및 내결함성을 쉽게 구현할 수 있다.
6. 고가용성 및 내결함성마이크로서비스 vs. 모놀리식 아키텍처
마이크로서비스의 장점
- 유연성 및 확장성: 독립된 서비스로 구성되어 각 서비스가 필요에 따라 확장 가능하며, 새로운 서비스를 쉽게 추가할 수 있다.
- 빠른 개발 및 배포: 독립적인 배포 가능성과 지속적 통합/전달을 통해 빠른 개발 주기와 배포가 가능하다.
- 고가용성 및 내결함성: 서비스 간의 독립성으로 부터 고가용성 및 내결함성을 구현하는 것이 용이하다.
- 다양한 기술 스택 활용: 각 서비스가 독립적인 기술 스택을 가질 수 있어 특정 기술의 선택에 자유롭다.
마이크로서비스의 단점
- 운영적인 복잡성: 다수의 서비스를 운영, 모니터링, 배포하는 것은 일반적으로 복잡하며, 팀 간의 협업과 의사소통이 중요하다.
- 분산 시스템의 복잡성: 서비스 간 통신이 네트워크를 통해 이루어지기 때문에 네트워크 문제, 지연 등의 복잡성이 증가한다.
- 단순한 운영과 배포: 단일 코드베이스와 데이터베이스를 가지고 있어 운영 및 배포가 비교적 간단하다.
- 간단한 통합: 코드와 데이터가 한 곳에 존재하기 때문에 통합이 상대적으로 간단하다.
모놀리식의 장점
- 유연성 및 확장성 부족: 전체 시스템의 복잡성으로 인해 유연성 및 확장성이 떨어질 수 있다.
- 모놀리식 애플리케이션의 단일 실패 지점: 특정 서비스의 장애가 전체 시스템에 영향을 미칠 수 있다.
모놀리식의 단점마이크로서비스의 적용 가능한 경우
- 대규모 및 복잡한 프로젝트: 여러 팀이 협업하며 복잡한 기능을 개발해야 할 때.
- 다양한 기술 스택 활용이 필요한 경우: 각 서비스마다 다른 기술을 활용하고자 할 때.
- 빠른 개발 주기와 배포가 필요한 경우: 신속한 개발과 변화에 빠르게 대응해야 할 때.
- 부분적인 확장성이 필요한 경우: 특정 서비스에 대한 부하가 크고 해당 서비스만 확장해야 할 때.
- 다양한 데이터베이스 요구: 각 서비스가 자체적인 데이터베이스를 필요로 할 때.
- 고가용성 및 내결함성이 요구되는 경우: 특정 서비스의 장애에도 전체 시스템이 정상 동작해야 할 때.
MSA 방식과 결합 유기적으로 구현을 진행중이며, 회원에 대한 기능을 마무리했다.
본 팀은 모놀리식으로 구현하던 기존의 방식을 현재'Spring' 카테고리의 다른 글
[Spring] 미니프로젝트 종료 이후 (0) | 2024.01.23 |
---|---|
[Spring] 김영한 Spring Data Jpa 요점정리 (1) (1) | 2024.01.23 |
[Spring] N+1 문제 - QueryDSL과 관련하여 (0) | 2024.01.08 |
[Spring] N+1 문제 - JPQL과 관련하여 (0) | 2024.01.08 |
[Spring] Spring Security를 활용한 세션 기반 로그인 구현 (1) | 2024.01.03 |