모놀리식 아키텍처 vs 마이크로 서비스 아키텍처

모놀리식 아키텍처

• 단일 코드 베이스의 애플리케이션
• 모든 개발자가 코딩을 처음 시작할 때 시작하는 방식 (보편적)
• 모든 서비스가 한 데이터 베이스 안에 존재

 

마이크로 서비스 아키텍처

• 애플리케이션을 작은 서비스로 분할하여 각 서비스가 서로 독립적(느슨한 결합)이라 기술에 구애받지 않음
• 각각의 서비스는 각각의 고유한 데이터베이스를 소유

 

모놀리식 아키텍처 장단점

장점	단점
단순성 → 모든 코드가 단일 베이스 → 변경 사항 발생 시 모든 코드가 한 곳에 존재	애플리케이션의 규모가 커질 경우 유지보수 어려움
간편한 배포 → 단일 프로젝트로 배포	유연하지 않은 확장성 → 애플리케이션의 특정 부분 요청 시 해당 부분만 확장할 수 없고 전체 애플리케이션 확장
보편성 → 대부분의 개발자가 경험	대규모 팀 작업이 어려움 → 모든 팀이 동일한 코드, 동일한 프로젝트에서 작업하여 코드 병합의 충돌 가능성이 높고, 기능 변경 시 다른 팀작업에 영향을 줄 가능성 존재
디버깅 쉬움	기술 사용 제한 → 다른 기술로 변경이 어려워 오랜 기간 동일한 기술을 사용
쉬운 테스트
쉬운 모니터링

 

마이크로 서비스 아키텍처 장단점

장점	단점
유연한 확장 → 다른 서비스와 독립적이기 때문에 특정 서비스만 확장 가능	개발 생산성 필요 → 여러 개의 마이크로 서비스 중 하나에 새로운 기능을 구현해야 할 때, 다른 서비스에 접근할 수 있도록 로컬에서 많은 애플리케이션을 실행할 수 있는 환경 구성
독립적인 배포 → 느슨하게 결합되어 있어 하나의 마이크로 서비스만 배포 가능 → 전체 애플리케이션의 동작을 멈출 필요가 없음	디버깅의 어려움 → 테스트를 위해 둘 이상의 마이크로 서비스를 실행해야 해서 디버깅이 어려울 수 있음
단일 실패 지점 제거 → 여러 소규모 서비스로 분할하여, 전체에 영향을 미치는 단일 실패 지점 제거	마이크로 서비스간 통신 → 동기/비동기 통신을 고려해야하므로 애플리케이션의 복잡성 증가
전체 서비스 중단 위험 감소 → 특정 마이크로 서비스가 중단되더라도 다른 서비스는 정상 작동 가능	오류 처리 → 두 개 이상의 마이크로 서비스를 사용해 요청 처리 할 때 첫 번째 마이크로 서비스에 대한 요청에서 문제 발생 시 작업을 이전 상태로 돌려두는 것을 고려 → A 서비스의 DB와 B 서비스의 DB의 CRUD를 하는 요청에서 문제 발생 시 양쪽 모두의 롤백 필요
다른 데이터베이스 소유 → 서비스마다 알맞는 데이터 베이스 사용 가능 Ex) A 서비스 : RDBMS / B 서비스 : NoSQL	표준화 부족 → 공통 플랫폼이 없음 → 모든 오류 또는 문제를 모니터링할 수 있는 중앙 모니터링 체계를 갖춰야 함
다양한 기술 수용 가능 Ex) A 서비스 : Java / B 서비스 : Python	오류 식별의 어려움 → 모놀리식 보다 훨씬 복잡하고 어렵고, 특히 비동기 통신일 때 더 어려움
민첩성 → 전체 애플리케이션에 영향을 주지 않고 새로운 것을 추가 가능 → 새 버전 배포가 매우 쉬움