핵심: 역할을 나누면 문제 지점을 찾고 필요한 부분만 늘리기 쉬워진다. 서버를 늘린 뒤에는 상태 공유와 장애 대응도 필요하다.
한눈에 보는 흐름
왜 배웠는가?
클라우드 인프라를 설계하려면 Web·App·DB가 왜 분리되는지 알아야 했다. 조원들은 작은 쇼핑몰을 가정하고, 사용자가 늘거나 서버가 고장날 때 구조가 어떻게 바뀌어야 하는지 조사했다.
핵심 개념
- 3-Tier: 화면·요청을 받는 Web, 업무를 처리하는 App, 정보를 보관하는 DB로 역할을 나누는 방식.
- Scale Up / Out: 서버 한 대를 더 강하게 만들기 / 같은 역할의 서버를 여러 대 두기.
- Load Balancer: 들어온 요청을 여러 서버에 나눠 보내는 입구.
- Stateless: 특정 App의 메모리에만 의존하지 않도록 상태를 관리하는 방식. 로그인 세션은 공용 저장소에 둘 수 있다.
- Health Check: 서버가 정상 응답하는지 주기적으로 확인하는 기능.
- 장애 범위: 하나가 고장났을 때 함께 영향을 받는 범위.
이해를 만든 질문
가정한 문제 | 배운 해결 방향 |
App만 느린데 모든 서버를 늘려야 하나? | 병목이 생긴 계층부터 확장한다. |
App을 두 대 만들었는데 한 대만 요청을 받는다. | 요청을 분배할 장치가 필요하다. |
다른 App으로 가면 로그인이 풀린다. | 서버 밖에서 로그인 상태를 함께 참조한다. |
죽은 서버로 요청이 계속 간다. | 정상 여부를 확인하고 살아 있는 대상으로 보낸다. |
App을 재시작했더니 DB도 멈춘다. | 상태를 보관하는 DB의 수명과 장애 범위를 분리한다. |
확장하면서 함께 고민한 점
기본 조사들은 세션 외부화와 장애 대응까지 연결했다. 조준환의 글은 세션뿐 아니라 캐시·이벤트 전달도 서버를 늘릴 때 달라진다는 점을 추가로 다뤘다. 서버를 여러 대 만든다고 내부 상태가 자동으로 공유되지는 않는다.
프로젝트에 남긴 의미
상용 쇼핑몰의 모든 기능을 구현하는 것이 목적은 아니었다. 이 지식을 바탕으로 공격 대상 서버와 탐지 서버가 함께 멈추지 않도록 설계할 이유를 설명할 수 있게 됐다.
확장과 장애 대응은 가정한 상황을 바탕으로 설계 원리를 학습한 내용이다.
배운 점
“서버가 세 대다”보다 역할·상태·장애 범위가 어떻게 나뉘는가가 중요하다.
