<aside> 🎯

한줄 결론: Web·Application·DB의 역할을 분리하고, 병목 계층만 수평 확장하며, 상태와 DB를 서버 밖에 두어야 장애와 확장에 대응할 수 있다.

</aside>

상황

사용자 로그인, 상품 조회·주문, 회원·주문 정보 저장 기능이 있는 이커머스를 단계적으로 개선한다. 실제 AWS 리소스를 새로 만들기보다 왜 구조가 바뀌는지 이해한다.

Step 1 · 한 서버에서 역할 분리

문제: Web·주문 로직·DB가 한 서버에 섞여 병목과 장애 원인을 구분하기 어렵다.

답: 요청을 받는 Presentation, 업무 로직의 Application, 데이터를 저장하는 Data 계층으로 나눈다.

• Presentation: Nginx 같은 Web Server
• Application: 로그인·상품·주문 로직
• Data: 회원·상품·주문 데이터

구조 변경: 단일 서버 → Web / App / DB

효과: 계층별 로그·자원 사용량을 확인하고 필요한 부분만 배포·확장할 수 있다.

Step 2 · Scale Up과 Scale Out

App CPU만 100%라면 App이 병목이다.

• Scale Up: CPU·메모리를 키운다. 간단하지만 사양 한계와 교체 중 중단 가능성이 있다.
• Scale Out: App 수를 늘린다. 확장과 장애 대응에 유리하지만 Load Balancing과 상태 관리가 필요하다.

선택: 계속 성장하는 서비스는 App을 두 대 이상으로 수평 확장한다.

현재 실습 구조

Step 3 · Load Balancing

App 2대를 만들기만 해서는 요청이 자동 분산되지 않는다. Load Balancer가 하나의 주소로 요청을 받고 여러 App에 나눈다.