1. 3-Tier Architecture 설계

상황: 작은 이커머스 서비스 구축. 기능은 사용자 로그인, 상품 조회, 상품 주문, 회원 정보 저장, 주문 정보 저장.

1) 서버 한 대에 웹서버+애플리케이션+DB를 모두 설치

문제: 사용자가 늘자 서버가 느려졌음. 웹 처리가 느린 건지 주문 로직이 느린 건지 DB 조회가 느린 건지 구분이 안 됨. 하나를 고치려고 재시작하면 나머지도 같이 멈춤.

질문: 이 서버를 어떤 기준으로 나눠야 원인 분리와 개별 확장이 가능해지는가?

구체적인 설명

서버 한 대에서 모니터링 지표(CPU, 메모리, 디스크 I/O)를 봐도 원인을 못 찾는 이유는, 세 가지 완전히 다른 작업 패턴이 하나의 리소스 풀을 공유하고 있기 때문이다.

• 웹 서버(정적 파일 응답, 요청 라우팅) → 네트워크 I/O 위주
• 애플리케이션(주문 검증, 재고 계산 같은 비즈니스 로직) → CPU 연산 위주
• DB(조회, 쓰기, 인덱스 스캔) → 디스크 I/O + 메모리(캐시) 위주

한 서버에 다 있으면 "CPU 사용률 80%"라는 지표 하나가 애플리케이션 로직 때문인지, DB가 디스크를 읽으면서 커널 레벨에서 CPU를 같이 쓴 건지 구분이 안 된다. 그리고 세 프로세스가 메모리를 두고 경쟁하기 때문에, DB 캐시가 커지면 애플리케이션이 쓸 메모리가 줄어드는 식으로 서로한테 영향을 준다.

나누는 기준은 **역할(계층)**이다. 사용자를 직접 상대하는 계층(Presentation), 비즈니스 로직을 처리하는 계층(Application), 데이터를 영속적으로 저장하는 계층(Data) — 이렇게 셋으로 나누면:

• 각 서버의 지표(CPU/메모리/디스크)가 온전히 그 계층의 작업량만 반영하게 되어 원인 분리가 가능해짐
• 하나를 재시작해도 나머지 두 계층은 프로세스 자체가 물리적으로 분리돼 있어 영향을 안 받음
• 계층마다 필요한 리소스가 다르므로(웹은 네트워크, DB는 메모리·디스크 위주로), 각자에 맞는 사양으로 서버를 고를 수 있음

핵심 개념

• 3-Tier Architecture: Presentation(표현) / Application(응용) / Data(데이터) 3개 계층으로 물리적·논리적으로 분리하는 설계
• 핵심 목적: 장애 격리(Isolation) + 원인 관측 가능성(Observability) + 계층별 독립적 확장