Monolith에서 Modular로 (기본적인 간단한 예제)
Source: Dev.to
내 코드를 직접 분해하면서 시스템 설계를 배우는 방법.
Phase 1: The Simple Single Server (2‑Tier)
Repository: arsalanbardsiri/simple-single-server-app
모든 훌륭한 시스템은 모놀리식으로 시작합니다. 첫 번째 반복은 고전적인 “2‑Tier” 애플리케이션이었습니다. 이 설정에서는 아키텍처가 겉보기와 달리 매우 단순합니다:
- Client Tier: 사용자 인터페이스(브라우저).
- Server Tier: 비즈니스 로직(Web Server)과 데이터 영속성(Database)을 모두 처리하는 단일 머신.
The Architecture
Why start here?
가장 빠르게 배포할 수 있기 때문입니다. 애플리케이션과 데이터베이스가 같은 하드웨어에 존재하므로 네트워크 지연이 전혀 없습니다. 배포는 단 한 번의 명령으로 끝납니다. 학생 프로젝트나 개념 증명(Proof‑of‑Concept)에는 완벽합니다.
The Wall
하지만 이 단순함은 함정이 될 수 있습니다.
- Vertical Scaling Limits: 더 많은 사용자를 처리하려면 전체 서버를 업그레이드해야 합니다(더 많은 RAM, 더 좋은 CPU). 데이터베이스만 별도로 업그레이드할 수 없습니다.
- Single Point of Failure (SPOF): 웹 서버가 버그가 있는 스크립트 때문에 다운되면 데이터베이스도 함께 내려갑니다.
- Security Risk: 2‑Tier 설정에서는 데이터베이스가 종종 외부에 노출된 웹 서버와 같은 환경을 공유하게 되며, 공격 표면이 확대됩니다.
Phase 2: The Evolution to 3‑Tier Architecture
Repository: arsalanbardsiri/3tier-simple-app
단일 서버의 취약성을 해결하기 위해 애플리케이션을 3‑Tier Architecture 로 리팩터링했습니다. 이는 이유가 있는 업계 표준입니다. 시스템을 물리적·논리적으로 세 개의 구별된 레이어로 분리합니다.
The Architecture
- Presentation Tier: 사용자가 보는 프론트엔드(클라이언트).
- Application Tier: 요청을 처리하는 백엔드 API(비즈니스 로직).
- Data Tier: 정보를 저장하는 전용 데이터베이스 서버.
The “Aha!” Moment
이 아키텍처로 전환하면서 복잡성이 증가했습니다—이제 연결 문자열, 네트워크 지연, 다중 배포를 관리해야 합니다. 그렇다면 왜 전환했을까요?
-
Independent Scalability
애플리케이션이 무거운 계산(CPU‑집중) 작업을 수행한다면 Application Server 를 추가로 배치할 수 있고, 대량의 로그(스토리지‑집중)를 저장한다면 Database Server 를 독립적으로 업그레이드할 수 있습니다. -
Improved Security
단일 서버 앱에서는 데이터베이스가 공개 웹 서버에 존재했습니다. 3‑Tier 앱에서는 Database Tier가 Application Tier 뒤에 숨겨져 있어, 오직 Application Server만 접근 가능한 사설 네트워크에 위치합니다. -
Fault Tolerance
구성 요소를 분리함으로써 시스템은 재시작을 견딜 수 있습니다. 패치를 배포하기 위해 웹 서버를 재시작해도 데이터베이스에는 영향을 주지 않습니다.
What’s Next?
관심사를 성공적으로 분리했지만 여전히 단일 장애 지점이 존재합니다: Application Server 하나와 Database Server 하나만 있기 때문입니다. ByteByteGo 로드맵의 다음 단계는 로드 밸런서(아마 NGINX)를 도입해 여러 애플리케이션 서버에 트래픽을 분산시켜, 하나가 다운되더라도 사용자는 전혀 체감하지 못하도록 하는 것입니다.