모놀리스가 무너지는 순간은 갑자기 오지 않는다 개발자가 운영하던 커머스 플랫폼은 초창기엔 단 하나의 Spring Boot 애플리케이션이었습니다. 주문, 결제, 회원, 상품, 배송이 하나의 코드베이스에 공존했고, 초기에는 그것이 오히려 장점이었습니다.
카테고리
Architecture
총 7편의 글
분산 시스템, 도메인 경계, 이벤트 기반 설계처럼 변경과 장애에 강한 시스템 구조를 만드는 방법을 정리합니다.
- 적용 대상
- 서비스 경계와 장기 유지보수 비용을 고민하는 백엔드·플랫폼 개발자
- 주요 초점
- 시스템 경계장애 격리트레이드오프
읽기와 쓰기가 같은 모델을 공유할 때 생기는 일 결제 시스템을 운영하다 보면 특이한 현상을 목격하게 됩니다. 쓰기 트래픽이 몰리는 시간대에 주문 목록 조회가 같이 느려집니다. 원인을 추적하면 항상 같은 곳에 도달합니다. 쓰기와 읽기가 동일한 테이블, 동일한 인덱스, 동일한 ORM 모델을 공유하고 있다는 사실입니다.
배포와 출시를 분리한다는 것 Feature flag의 가장 큰 가치는 배포(deploy)와 출시(release)를 분리하는 것입니다. 코드는 production에 배포하되, 기능은 특정 사용자에게만 켜거나 아예 꺼둘 수 있습니다. 이 단순한 분리가 배포 리스크를 크게 낮춥니다.
결제는 성공했는데 메시지는 사라졌다 분산 시스템에서 가장 불편한 진실은 "데이터베이스 커밋"과 "메시지 발행"을 하나의 원자적 동작으로 묶기 어렵다는 점입니다. 주문 서비스가 결제를 승인하고 orders 테이블에 상태를 저장한 뒤, Kafka나 RabbitMQ로 OrderPaid 이벤트를 발행한다고 가정해봅시다. 평소에는 아무 문제 없이 동작합니다.
마이크로 프론트엔드: 거대한 프론트엔드 모놀리스를 해체하는 기술 현대 웹 애플리케이션은 하나의 거대한 프론트엔드(Frontend Monolith)로 시작하여, 시간이 지남에 따라 수십만 줄의 코드와 수백 개의 컴포넌트를 품은 괴물로 성장하는 경우가 허다합니다.
마이크로 프론트엔드(Micro-frontends) 아키텍처는 현대의 거대한 웹 애플리케이션 개발에서 파생된 복잡성을 해결하기 위한 가장 유력한 대안 중 하나로 자리 잡았습니다.
프론트엔드 모노레포: 파편화된 코드 베이스를 넘어 거대한 협업 생태계로 기업이 성장하고 서비스가 확장됨에 따라 프론트엔드 코드의 복잡도는 기하급수적으로 증가합니다. 여러 개의 웹 앱, 공통 UI 컴포넌트 라이브러리, 유틸리티 함수, 그리고 백엔드와 공유하는 타입 정의까지.