개요
- 모놀리식 아키텍처
단일 코드 베이스의 애플리케이션임
대부분 내가 만들었던 프로젝트들도 모놀리식 아키텍처였다. 예를 들어 전체 애플리케이션이 단일 코드로 작성되어 단일 데이터베이스로 연결된다든지
장점: 단순성, 간편한 배포, 보편성, 디버깅이 쉬움, 쉬운 테스트, 쉬운 모니터링
단점: 규모가 커지면 유지 보수가 어려움, 유연하지 않은 확장성, 대규모 팀 작업이 어려움, 기술 사용 제한
장단점이 확실해 상황에 맞게 쓰는게 좋음
그럼 어떤 상황에서 쓰면 좋나?
1) 규모가 작은 애플리케이션의 경우
2) 주된 작업이 CRUD일 경우
- 마이크로서비스 아키텍처
애플리케이션을 작은 서비스로 분할하고, 각 서비스가 독립적이라 기술에 구애받지 않으며 각각 고유한 데이터베이스를 소유할 수 있음
서비스 단위로 쪼개서 운영한다고 생각하면 됨
장점: 유연한 확장, 독립적인 배포, 단일 실패 지점 제거, 전체 서비스 중단 위험 감소, 다른 데이터베이스를 소유, 다양한 기술 수용 가능, 민첩성
단점: 개발 생산성 필요, 디버깅이 어려울 수 있음, 마이크로서비스 간 통신, 오류 처리, 표준화 부족, 오류 식별의 어려움
모놀리식과는 반대 상황에 쓰면 됨
어떤 상황에서 쓰면 좋나?
1) 비즈니스가 계속 성장하고 있는 경우
2) 복잡한 어플리케이션임이 예상되는 경우
- 정리
아키텍처를 선택할 때는 여러 비즈니스 상황을 고려해야함
예를 들어 트위터나 우버의 경우 모놀리식 기반의 MVP로 앱을 개발한 후 비즈니스 모델의 가치를 인정받고, 비즈니스가 확장됨에 따라 마이크로서비스로 전환함
어떤게 옳다고 할 수 없으니 비즈니스 상황에 맞게 아키텍처를 선택하는게 좋음