[IT Infra 기초] 웹 데이터 흐름

# 웹 데이터 흐름

1. 클라이언트 PC → 웹 서버

2. 웹 서버 → AP 서버

3. AP 서버 → DB 서버

4. AP 서버 → 웹 서버

5. 웹 서버 → 클라이언트 PC

---

1. 클라이언트 PC → 웹 서버

# 흐름 (클라이언트 PC → 웹 서버 → AP 서버 질의)

   1) 웹 브라우저가 요청을 발행

       - 특정 인터넷 사이트에 요청을 보냄

   2) 이름 해석

       - 해당 사이트가 어디에 있는지 이름을 해석한 후 결과를 가지고 웹 서버에 요청을 보냄

   3) 웹 서버가 요청 접수

      - 웹 서버의 httpd 프로세스가 요청을 접수 

   4) 웹 서버가 정적 콘텐츠인지 동적 콘텐츠인지 판단

      - httpd가 받은 요청 내용을 분석

   5) 필요한 경로로 데이터에 액세스

       - 정적인 정보 → 디스크로부터 읽는다.

       - 동적인 정보 → 네트워크를 경유해서 다른 서버(AP 서버)에 요청을 보낸다.

# 클라이언트 PC에서의 처리 흐름 (웹 브라우저 실행)

- 디스크에서 프로그램을 읽어서 프로세스를 시작하고, 메모리 공간을 확보

- 시스템 콜이 이용되고 있음

   1) PC 내부도 서버와 거의 같은 구조

   2) 웹 브라우저도 OS의 '프로세스'로 실행됨

   3) 프로그램은 원래 디스크에 저정되어 있음. 이것을 읽어서 메모리에 상주시키고 실행하는 것은 OS

   4) 웹 브라우저 화면에서 링크를 클릭 → 웹 서버로 요청을 보냄

       (ex. 'http://juyoungs.tistory.com' → 이름 해석 → 웹 브라우저로 접속)

       ('http://juyoungs.tistory.com' = "HTTP를 이용해서 juyoungs.tistory.com 서버에 접속한다.")

   5) OS의 '시스템 콜'로 실행됨. 커널을 통해 NIC에 네트워크 통신이 요청됨

   6) 네트워크 경유로 웹 서버에 질의

 

# 이름 해석

- Name resolution

- 웹 브라우저는 서버가 어디에 있는지 모름 → 서버가 어디에 있는지 조사하는 구조

   - 인터넷 상의 주소 :  IP = 숫자 / URL = 문자열

      → 연결시켜야 통신이 됨

- 이름 해석 구조

   1) 웹 브라우저는 'juyoungs.tistory.com'의 IP 주소를 모른다.

   2) OS의 호스트명, IP 주소 변환 테이블을 참조

     (존재하지 않는 경우, 외부 DNS 서버에 요청을 던짐. DNS 서버에 호스팅명이 아닌 IP 주소로 지정되어 있는 이유)

   3) 전 세계에 있는 DNS 서버 - Root DNS 기준 트리구조

       개별 DNS 서버 - 정기적으로 부모 DNS 서버에서 데이터를 받아 최신 IP 주소 목록 유지

   4) IP 주소 검색 결과 반환

 

# 웹 서버의 역할

- HTTP 요청에 대해 적절한 파일이나 콘텐츠 반환

 

# HTTP 

- HyperText Transfer Protocol

- HTTP가 텍스트를 송수신하기 위한 약속

- 현재 HTTP는 이미지, 동영상 데이터 전송에도 이용. but, 기본은 텍스트 데이터

 

# httpd 프로세스

- HTTP를 처리하는 프로세스

- ex) 아파치 - 부모 프로세스 / 자식 프로세스로 나누어 처리 분담

       자식 프로세스 → 내부에서 여러 스레드를 가동하는 형태도 가능

       기본적으로 자식 프로세스가 HTTP 요청 접수

 

# 요청에 대한 대답 내용

- 바이너리 데이터로 구성

- 바이너리 데이터 : HTML 파일이라는 텍스트 데이터, 이미지, 동영상 등

   → 정적 콘텐츠 / 동적 콘텐츠

 

# 정적 콘텐츠

- 실시간으로 변경할 필요가 없는 데이터 (데이터 갱신 빈도가 낮은 콘텐츠)

- ex) 회사 로고 이미지

- 웹 서버에서 디스크에 저장해서 요청이 있으면 저장해둔 내용을 HTTP를 통해 사용자 웹 브라우저로 반환

 

# 동적 콘텐츠

- 높은 빈도로 변경되는 데이터

- ex) 사용자의 은행 잔고 정보, 최신 날씨 정보 데이터, 쇼핑 사이트의 장바구니 등

- AP 서버가 HTML 파일을 동적으로 생성

- 웹 서버는 동적 콘텐츠에 대한 요청을 AP 서버에 던지고 결과를 기다림

- 동적 콘텐츠를 서버 내부 디스크에 저장을 잘 안하는 이유 : 

   - 서버 내부의 디스크에 저장하면 갱신 빈도가 높기 때문에 디스크 성능이 병목 현상의 원인이 될 수 있음

   - 파일 형태로 저장하는 것 자체가 비효율적

 

2. 웹 서버 → AP 서버

# AP 서버

- 동적 콘텐츠에 대한 요청 처리 (아직 존재하지 않는 콘텐츠를 가능한 빨리 만들어내야하는 역할)

# 흐름 (웹 서버 → AP 서버)

1) 웹 서버로부터 요청이 도착

    - 웹 서버에서 온 요청 → NIC 경유 → 커널에 의해 끼어들기 처리

2) 스레드가 요청을 받으면 자신이 계산할 수 있는지, 아니면 DB 접속이 필요한지 판단

    - 스레드가 요청 접수

3) DB 접속이 필요하다면 연결 풀에 액세스

    - 동적 데이터를 가져와야 하는 경우

4) DB 서버에 요청을 던짐

    - 시스템 콜 이용

5) 네트워크 경유로 DB 서버에 질의

 

# JVM

- Java Virtual Machine

- 자바를 이용한 AP 서버에서 동작하는 가상 머신

- 하나의 거대한 프로세스

 

# 가상머신

- 하나의 OS로서 다양한 기능 有

   - ex) 스레드 요청 접수 기능

          if, 단순 요청 O → 애플리케이션 상에서 계산 = AP 서버의 담당 스레드가 계산한 후 결과 반환

          (ex. 1+1의 계산 결과)

          if, 단순 요청 X → DB 서버에 질의 → 결과를 HTML 등으로 정리해서 반환

          (ex. 사용자 잔금 정보)

 

# AP 서버 → DB 서버 접속 시 '드라이버' 필요

- 드라이버 ≒ 커널의 장치 드라이버

- 드라이버 뒷단에 있는 것 = DB로 가는 인터페이스

- 해당 DB 자체를 은폐하는 역할

 

# DB 서버 이외의 옵션

1) JVM 내부에 캐시로 저장 및 반환

   - 규모가 작고 갱신 빈도가 낮은 정보 (ex. 대한민국 행정 경계 정보)

   - 처음부터 JVM에 데이터가 캐시되어 있으면 바로 데이터를 반환할 수 있어서 고속 처리 가능

2) DB 서버보다도 빠른 '캐시 전용 서버' 이용

3) 네트워크 경유로 다른 서버에 질의

    - 규모가 큰 정적 데이터 → CDN (Content Delivery Network) 이라 불리는 데이터 전송 전용 서버를 이용

 

# CDN

- Content Delivery Network

- 데이터 전송 전용 서버

- 대량의 데이터 전송에 특화

- 전 세계에 있는 데이터 복사본(캐시)을 배치하는 기술 + 병렬 기술 → 처리 효율화

- 대부분의 웹 시스템에서 이용 (기업형 시스템에서는 잘 사용되지 X)

 

# 웹 시스템 vs 기업형 시스템

웹 시스템	기업형 시스템
- 하나의 시스템을 수많은 사용자가 이용 - 대량의 데이터를 참조하는 업무가 多	- 하나의 시스템에 대한 사용자 수가 제한 - 참조뿐만 아니라 데이터를 갱신하는 업무가 多

 

3. AP 서버 → DB 서버

- DB 서버에 요청 시 언어 : SQL

- DB의 역할 : SQL 해석 → 데이터 액세스 방식 결정 → 디스크나 메모리에서 필요한 데이터만 수집

# 흐름 (AP 서버 → DB 서버)

1) AP 서버로부터 요청이 도착

    - DB 서버에서는 DB 프로세스가 요청 접수

2) 프로세스가 요청 접수, 캐시가 존재하는지 확인

    - 이전에 사용한 정보는 캐시에 있기 때문에 캐시가 존재하는지 찾기 위해 일단 공유 메모리 검색

3) 캐시에 없으면 디스크에 액세스

    - 공유 메모리에 데이터가 존재하지 않기 때문에 디스크에서 읽음. 시스템 콜을 경유하여 디스크에 요청을 던짐

4) 디스크가 데이터를 반환

    - 디스크의 데이터는 요청을 보낸 프로세스로 반환

5) 데이터를 캐시 형태로 저장

    - 한 번 액세스한 데이터는 메모리에 캐시 형태로 저장되고 이후 액세스 시 재사용됨

6) 결과를 AP 서버에 반환

 

# DB 서버 SW

1) 웹 계열 시스템

    - MySQL

    - Postgre SQL 등

2) 기업용

    - 오라클 DB

    - MS SQL Server 등

3) RDBMS

    - KVS (Key-Value Store) 등

 

# DB 서버

- 데이터 저장 창고

- 데이터 방대 → 얼마나 효율적으로 액세스하는가가 중요

   ⇒ 1) 서버 메모리에 캐시가 있는지 먼저 확인

       2) 없으면 디스크에 액세스해서 필요한 데이터를 가져옴

 

# 인메모리(In-memory) DB

- 디스크 자체를 사용하지 않고 모든 처리를 메모리 내에서 완료하는 구조

   → 고속화 실현 가능

 

# DB 프로세스의 종류 및 역할

   1) 서버 프로세스

      - SQL로 요청을 받아서 해석, 데이터에 액세스, 검색 · 가공하는 프로세스

      - 디스크에서 데이터를 읽거나 메모리에 캐시로 저장

   2) 백그라운드 프로세스

      - ex) LGWR 프로세스 , DBWR 프로세스 등

      - 메모리상의 차이정보(REDO)를 관리, 데이터를 디스크에 반영

      - 개별 서버 프로세스가 아닌 공유화를 통해 효율성 및 비동기성 실현

      - 메모리에 캐시로 존재하는 데이터와 디스크에 있는 데이터를 '정기적으로 동기회'

 

# DB 프로세스 간 작업 분담을 하는 이유

: 분업 → 처리 병렬화 → 처리량 향상

 

# 외부 저장 장치에 액세스

- 기업 시스템 → DB 서버 내부의 디스크 직접 사용 거의 X (∵이중화 관점에서 뒤떨어짐) ⇒ 외부의 별도 저장 장치 이용

- 저장 장치 내부에도 CPU나 메모리가 있으며, 전용 OS가 실행되고 있음

- 메모리에 캐시 형태로 저장하는 구조도 有

- 대량의 데이터에 고속 액세스하기 위한 전용 서버

 

# RDBMS

- '표(테이블)'로 데이터 표현 → 데이터가 정리됨

- 릴레이션(Relation)에 의해 표 사이의 관계 표현

- 데이터의 일관성을 엄격히 관리 → 갱신 속도가 상대적으로 느림 = 속도보다 안정성 중시

 

4. AP 서버 → 웹 서버

# 흐름 (AP서버 → 웹 서버)

1) DB 서버로부터 데이터 도착

    - DB 서버에서 돌아온 데이터 → NIC 경유로 원래 스레드에 반환됨

2) 스레드가 데이터를 가지고 계산 등을 한 후 파일 데이터 생성

    - DB 데이터, JVM의 캐시 데이터 등을 이용 → 계산 및 집계 처리 → 특정 형태의 파일 생성

3) 결과를 웹 서버로 반환

 

# 가공 결과

- 텍스트 데이터 → HTML, XML 파일 사용

- 바이너리 데이터 (동적 이미지 등)

- HTTP로 전송 가능한 데이터라면 형태 상관 X

 

5. 웹 서버 → 클라이언트 PC

# 데이터 흐름

- AP 서버 → 웹 서버의 httpd 프로세스 → PC의 웹 브라우저

# 흐름 (웹 서버 → 클라이언트 PC)

1) AP 서버로부터 데이터 도착

    - AP 서버에서 돌아온 데이터 → NIC 경유 → 원래 스레드에 반환

2) 프로세스는 받은 데이터를 그대로 반환

    - 필요한 데이터 가공은 모두 AP 서버에서 이루어졌기 때문에 그대로 웹 브라우저에 데이터 반환

3) 결과가 웹 브라우저로 반환, 화면에 표시

 

* 하나의 요청 → 하나의 데이터 반환

   복수의 요청 → 분할 → 각 요청별로 데이터 반환

 

# 각 서버의 공통점 (웹 서버, AP 서버, DB 서버)

- 프로세스나 스레드가 요청을 받는다.

- 도착한 요청을 파악 → 필요에 따라 별도 서버로 요청을 보낸다.

- 도착한 요청에 대해 응답한다.

 

# 조감도

- 시스템 구성도. 전체를 보는 것

 

---

참고 : 야마자키 야스시 외 3, 「그림으로 공부하는 IT 인프라 구조」, 제이펍