몇년 전 웹 개발을 처음 시작했을 당시에는 단일 서버 형태로 단순한 시스템을 설계하였다.
처음 만든 웹 어플리케이션이었기 때문에 제대로 동작하는지 확인하는게 중요했고,
서버 설계에 대한 지식도 없었으므로 단순히 책과 수업에서 배운 내용 그대로를 따라한 구조였다.
아래는 그당시 설계된 서버 구조를 대략적으로 그려본 것이다. 사용자 요청 처리는 다음과 같이 이루어진다.
사용자는 PC웹 브라우저나 모바일 기기를 통하여 웹 사이트에 접속하고자 한다.
그러기 위해 사용자의 요청이 어떻게 처리되어 보여지는지 간략하게 정리해 보았다.
1. 사용자가 도메인 주소를 입력하면, 클라이언트(웹,앱 브라우저 등)는 입력한 도메인 주소를 해석하기 위해
DNS(Domain Name System) 서버에 조회 요청을 보낸다.
2. DNS 서버는 도메인 주소를 IP 주소로 변환하여 반환한다. 이것을 DNS 조회라고 한다.
DNS는 해당 웹 사이트의 개발자가 직접 만든 서비스가 아니라 보통 제3자가 제공하는 서비스이다.
인터넷 서비스 제공업체(ISP), 기업, 인터넷주소자원관리기구(ICANN)와 같은 조직 등이 제공한다.
3. DNS 서버가 도메인 주소에 대한 IP 주소를 찾으면 클라이언트에게 IP주소를 넘겨주고,
클라이언트는 해당 IP 주소에 HTTP요청을 전달한다. 이 요청에는 클라이언트가 원하는
페이지 또는 리소스에 대한 정보가 포함되어 있다.
4, 5. 웹 서버는 클라이언트의 HTTP 요청을 받아들이고, 요청된 페이지나 리소스를 찾아내서 응답을 생성한다.
그러기 위해서 서버는 비지니스 로직을 수행하며 이때 데이터 읽기, 쓰기, 수정, 삭제 등의 처리를 위해
DB서버와 응답을 주고 받는다.
6. 위의 동작을 수행한 결과로 웹서버는 요청된 페이지나 리소스를 HTML페이지나 JSON과 같은 형태로
클라이언트에 반환한다.
7. 웹 서버에서 생성한 HTTP 응답이 클라이언트로 전송된다. 클라이언트에서는 받은 응답을 이용하여
클라이언트가 요청한 웹 페이지와 같은 컨텐츠를 제공 및 표시한다.
클라이언트 웹 브라우저는 받은 응답을 기반으로 웹 페이지를 렌더링하고 사용자에게 표시한다.
위 구조는 서버를 한대 또는 두대정도만 운영하면 되므로 구조가 간단하고 비용 또한 적게든다.
하지만 이러한 형태의 서버구조로 모든 웹 서비스를 안정적으로 운영할 수 있을까?
해당 질문을 챗 GTP에게 해 보았다.
| Chat GPT 曰 : 단일 서버 구조(싱글 서버 구조)는 하나의 서버가 모든 웹 응용 프로그램 및 데이터베이스 요청을 처리하는 클래식한 방식의 웹 호스팅 모델입니다. 이러한 구조는 간단하고 비용 효율적이지만, 다음과 같은 문제점이 발생할 수 있습니다 1. 단일 장애점 (Single Point of Failure): 단일 서버에 모든 요청이 집중되므로 해당 서버의 장애가 발생하면 전체 서비스에 영향을 미칩니다. 이는 가용성과 신뢰성을 저해할 수 있습니다. 2. 스케일링 어려움: 트래픽 또는 데이터베이스 부하가 증가할 때, 단일 서버 구조에서는 확장하기 어렵습니다. 서버의 성능 업그레이드가 한계에 도달하면 서비스 품질이 저하될 수 있습니다. 3. 보안 위험: 모든 데이터와 애플리케이션을 단일 서버에 호스팅하면 보안 취약점이 공격자에게 노출될 수 있습니다. 하나의 취약점이 서버 전체에 영향을 미칠 수 있습니다. 4. 성능 문제: 트래픽이 급증하면 서버에서 처리해야 할 부하가 증가하고 응답 시간이 길어질 수 있습니다. 이로 인해 사용자 경험이 악화될 수 있습니다. 5. 확장성 부족: 새로운 애플리케이션 또는 서비스를 추가하려면 새로운 서버를 구축하고 설정해야 합니다. 이것은 관리 복잡성을 증가시킬 수 있습니다. 6. 백업 및 복구 어려움: 단일 서버에 모든 데이터가 저장되므로 백업 및 복구 프로세스가 복잡해질 수 있습니다. 장애나 데이터 손실 시 복구 시간이 길어질 수 있습니다. 7. 자원 낭비: 트래픽이 낮을 때도 서버는 일정한 자원을 사용하므로 자원이 낭비될 수 있습니다. 이러한 문제점을 극복하기 위해 분산 시스템, 로드 밸런싱, 데이터베이스 클러스터링, 가용성 및 복구 솔루션, 가상화 및 컨테이너 기술, 그리고 클라우드 컴퓨팅과 같은 다양한 기술 및 아키텍처 패턴을 사용하여 확장 가능하고 안전한 웹 호스팅 환경을 구축하는 것이 일반적입니다. |
마지막에 언급된것 처럼, 확장 가능하고 안전한 환경을 구축하기 위해서는 단순한 단일 서버의 구조가 아닌 목적과 상황에 맞는 서버 설계가 필요할 뿐만 아니라 어플리케이션 서버 기술, 데이터베이스 기술, 리버스 프록시 서버 기술, 클라우드 서비스 등과 같은 다양한 기술 및 아키텍쳐 패턴이 필요하다.
다음 글들은 내가 실무에서 경험해본 몇가지 서버 구조와, 이러한 서버 구조 위에서 경험해본 몇가지 기술스텍들에 대해 정리하는 내용이 될 예정이다. 그간 깊게 생각하지 않고 사용한 기술들도 있었고, 문제가 되어 고민과 논의 끝에 모듈 및 구조를 바꾼 경험도 있었다. 이러한 경험들을 잘 정리해 놓아 서버 개발자로서의 방향성을 더 확고하게 하고 싶다.
'서버 개발' 카테고리의 다른 글
| 레이스 컨디션 (Race Condition) -02. Pessimistic Lock, Optimistick Lock (0) | 2024.04.10 |
|---|---|
| CURL로 외부 서버와 통신 테스트(+ 겪을 수 있는 에러로그) (0) | 2024.03.25 |
| 내부망에서 외부 서버와의 통신시 발생할 수 있는 문제들 (0) | 2024.03.20 |
| 확장 가능한 시스템 설계 예시 (0) | 2023.10.22 |
| 서버 개발 고민 (1) | 2023.10.15 |
