목차

1. Step 1. 서버 한 대에 전부 올렸더니
2. Step 2. App 서버만 CPU 100%
3. Step 3. 두 번째 서버가 놀고 있다
4. Step 4. 페이지를 넘길 때마다 로그아웃
5. Step 5. 죽은 서버로 계속 요청이 간다
6. Step 6. App을 재시작했더니 DB까지 죽었다
7. Step 7. AWS로 옮기기
8. 정리하며

Cloud & CERT 과제의 첫 번째 주제는 3-Tier Architecture다. 사용자 로그인, 상품 조회, 주문, 회원·주문 정보 저장 기능을 가진 작은 쇼핑몰을 서버 한 대에서 시작한다. 문제가 생길 때마다 구조를 고쳐 나가는 방식으로 진행했고, 각 단계에서 무엇을 배웠는지, 어디서 잘못 생각했는지 순서대로 정리했다.

Step 1. 서버 한 대에 전부 올렸더니

문제 사용자가 늘자 서버가 느려졌다. 웹 처리가 느린 건지, 주문 로직이 느린 건지, DB 조회가 느린 건지 구분이 안 된다.

처음에는 웹 서버, 애플리케이션, DB를 한 서버에 모두 설치했다. 사용자가 늘자 서버가 느려졌는데, 웹 처리 때문인지 주문 로직 때문인지 DB 조회 때문인지 구분할 수 없었다. 셋이 CPU, 메모리, 디스크를 같이 쓰고 있으니 당연한 결과다. 하나만 고치려고 재시작해도 나머지가 같이 멈췄다.

그래서 서버를 나누기로 했는데, 여기서 첫 번째로 잘못 생각했다. 처음에는 "로그인 서버, 주문 서버, 상품 서버"처럼 기능별로 나누려 했다. 그런데 이건 마이크로서비스 쪽 이야기이고, 문제에서 물은 것은 "웹이냐 로직이냐 DB냐"를 가르는 것이었다. 그래서 기준을 처리 계층으로 바꿨다.

• Presentation (Web) — HTTP 요청을 받고 정적 파일을 돌려주는 계층이다. 네트워크 I/O가 주된 부하다.
• Application — 로그인 검증, 주문 처리 같은 비즈니스 로직을 담당한다. CPU를 주로 쓴다.
• Data (DB) — 회원과 주문 정보를 영구 저장한다. 디스크 I/O가 크고, 유일하게 상태를 가진 계층이다.

세 계층은 부하 특성도, 상태 유무도 다르다. 그래서 떼어 놓아야 원인을 분리할 수 있고 각각 따로 확장할 수 있다.