모든 클릭 뒤에: 클라이언트-서버 아키텍처 이해

Source: Dev.to

소개

클라이언트‑서버 아키텍처는 현대 애플리케이션 개발에서 가장 기본적인 모델 중 하나입니다.

• Client – 요청을 하는 사용자 또는 애플리케이션
• Server – 요청을 처리하고 응답을 반환하는 머신

사용자가 서버에 접근하고 싶을 때 가장 간단한 방법은 서버의 IP 주소에 ping을 보내는 것입니다. 하지만 IP 주소는 기억하기 어려워 직접 접근하기가 실용적이지 않습니다. 이 문제를 해결하기 위해 Domain Name System (DNS) 를 사용합니다.

하드웨어가 제한된 서버(예: CPU 2개, RAM 4 GB)는 일정 수량의 요청만 처리할 수 있습니다. 트래픽이 크게 증가하면 사용자는 지연을 경험하거나 서버가 응답하지 않을 수 있습니다.

확장 전략

수직 확장 (Vertical Scaling, Scaling Up)

단일 서버의 물리적 자원을 늘리는 것으로, 예를 들어 CPU 16개, RAM 128 GB로 업그레이드하는 경우입니다.

장점

• 구조가 단순함 (단일 서버)

단점

• 트래픽이 적을 때 자원 낭비
• 서버를 재시작해야 하므로 확장 중 다운타임 발생
• 하드웨어 한계 – 업그레이드가 불가능한 최대 용량이 존재

수평 확장 (Horizontal Scaling, Scaling Out)

동일한 구성의 작은 서버를 여러 대 복제하는 방식(예: CPU 2개, RAM 4 GB 서버 여러 대).

장점

• 서버를 추가하거나 제거할 때 다운타임이 없음
• 비용 효율성 향상
• 높은 내 fault tolerance
• 피크 타임에 효율적인 트래픽 관리

고려 사항

• 각 복제된 서버는 자체 IP 주소를 갖게 되는데, DNS가 하나만 가리키는 경우 여러 서버 IP를 어떻게 처리할 것인가? 라는 질문이 발생합니다.

여러 서버 IP 처리 방법

서버가 여러 대 존재할 때는 일반적으로 로드 밸런서가 앞에 배치됩니다. 로드 밸런서는 단일 DNS 이름으로 들어오는 트래픽을 받아 선택된 알고리즘(예: 라운드‑로빈, 최소 연결, 가중치 분배)에 따라 서버 IP 풀에 요청을 분산시킵니다.

핵심 설계 고려 사항

• 로드 밸런싱 결정 로직 – 로드 밸런서는 각 요청을 어떤 서버에 보낼지 어떻게 결정합니까?
• 세션 지속성 – 여러 서버에 걸쳐 사용자 세션(예: 로그인 세션)을 어떻게 유지합니까?
• 자동 확장 – 트래픽이 급증할 때 자동 확장 그룹은 어떻게 동작합니까?
• 공유 스토리지 – 서버가 분산되어 있을 때 애플리케이션은 공유 파일을 어떻게 저장합니까?
• 헬스 체크 – 헬스 체크는 실패한 서버에 트래픽이 전송되지 않도록 어떻게 보장합니까?