네트워크(5) : 서버측의 LAN에는 무엇이 있는가

📍목차

1. 웹 서버의 설치 장소
2. 방화벽의 원리와 동작
3. 복수 서버에 리퀘스트를 분배한 서버의 부하 분산
4. 캐시 서버를 이용한 서버의 부하 분산
5. 콘텐츠 배포 서비스

---

1️⃣ 웹 서버의 설치 장소

본 포스팅에서는 패킷이 서버 바로 앞의 방화벽, 캐시 서버, 부하 분산 장치 등을 통과하는 장면을 알아보자.

패킷의 여정은 서버의 설치 장소에 따라 다른데,
서버가 설치되는 장소를 크게 세 가지로 분류하면 아래와 같다.

(a)의 라우터에서 직접 연결하는 형태는

1. IP 주소의 부족
2. 위험한 패킷 차단 불가능

두가지를 이유로 잘 사용하지 않고,
(b)와 (c) 형태의 구조에서 방화벽을 앞에 두어 위험한 패킷을 차단하는 형태가 일반적이다.

---

2️⃣ 방화벽의 원리와 동작

방화벽이란, 네트워크를 외부에서의 공격으로부터 지키기 위해 고안된 관문이다.

이때 방화벽은 다양한 공격 수법에 대비하여 바이러스 검사, 부정 침입 검사, 검역 네트워크 등을 추가로 수행한다.

또한 패킷 필터링형, 애플리케이션 게이트웨이형, 서킷 게이트웨이형 등 다양한 유형이 있지만, 가장 많이 보급된 패킷 필터링형을 중심으로 방화벽의 원리에 대해 알아보자.

방화벽은 설정된 패킷 필터링 조건을 통해 패킷의 통과 여부를 결정하기 때문에, 패킷의 흐름에 착안하여 조건을 잘 설정하는 것이 핵심이고,

패킷 필터링형 방화벽은 송수신처 IP 주소, 송수신처 포트 번호, 컨트롤 비트 등 패킷의 헤더에 있는 제어 정보를 통해 조건을 설정한다.

추가로, 침입자의 수법 파악이나 향후 대책 마련을 위해 차단한 패킷에 대한 기록을 남기기도 한다.
이 경우, 라우터는 메모리 용량이 작으므로 전용 하드웨어나 소프트웨어를 사용하는 편이다.

또한, 유의할 점은 패킷이 통과되었다고 해도 패킷이 항상 안전하지는 않다는 것이다.
방화벽은 시점과 종점을 조사하여 판단하기 때문에, 패킷의 내용을 직접 조사하지 않고서는 서버가 공격에 노출될 가능성이 존재한다.

이 경우
1. 웹 서버 내 소프트웨어의 버그 수정
2. 방화벽과 별도로 패킷의 내용 조사 장치 마련
등의 방법을 통해 해결한다.

---

3️⃣ 복수 서버에 리퀘스트를 분배한 서버의 부하 분산

지금까지 라우터에 대해 알아봤다.
이어서, 고속화된 회선을 통해 서버에 대량의 패킷이 들어와 처리 능력이 따라잡지 못하는 경우의 대처법에 대해 알아보자.

서버 머신을 고성능 기종으로 교체하더라도 다수의 사용자가 집중적으로 접근하면 한 대의 서버 머신으로는 해결하지 못할 수 있다.

이때 복수의 서버를 사용해 처리를 분담하는 방법을 분산 처리라고 한다.

라운드 로빈

가장 단순한 방법으로, 여러 대의 웹 서버를 설치하고 한 대가 담당하는 사용자 수를 줄이는 방법이다.

이때 클라이언트의 요청을 웹 서버에 분배하는 구조 중 가장 간단한 방법은 DNS 서버에서 요청을 분배하는 방법이다.

DNS 서버에 같은 이름으로 여러 대의 웹 서버를 등록해두면,
DNS가 조회마다 차례대로 IP 주소를 되돌려주는 형태를 라운드 로빈이라고 한다.

예를 들어 www.doohyeon.com이라는 서버명에 대해
192.0.2.10, 192.0.2.20, 192.0.2.30을 등록했다고 가정하면,

첫번째 요청 : 192.0.2.10 응답
두번째 요청 : 192.0.2.20 응답
세번째 요청 : 192.0.2.30 응답
네번째 요청 : 192.0.2.10 응답

의 형태로 액세스를 분산하는 방식이다.

라운드 로빈 문제점

그러나 이러한 방식의 경우, DNS 서버는 웹 서버의 정상 동작 여부를 확인하지 못하여 고장한 웹 서버의 IP 주소를 회답한다는 결점이 존재한다.

부하 분산 장치 (로드 밸런서)

라운드 로빈의 문제점을 해결하기 위해 부하 분산 장치가 고안되었다.

이 방식은 웹 서버 대신 부하 분산 장치를 DNS 서버에 등록하고,
클라이언트가 부하 분산 장치를 웹 서버라고 생각하게해 여기에 리퀘스트 메시지를 보내도록 구현하는 방식이다.

이때 어느 웹 서버에 요청을 전송할지 판단하는 기준으로는 요청할 페이지의 수가 핵심적이고, 각 상황은 아래와 같다.

1. 요청할 페이지가 하나인 경우

   웹 서버의 부하 상태가 판단 근거가 된다.
   정기적으로 CPU나 메모리 사용률 등을 수집하여 부하를 판단한다.

2. 요청할 페이지가 여러 개인 경우

   웹 서버의 부하에 관계없이 이전 요청과 같은 웹 서버에 전송한다.

   이는 웹 서버가 변하면 대화가 끊기는 상황이 발생하기 때문인데,
   첫 번째 페이지에서 주소 입력하고 두 번째 페이지에서 카드 번호 입력 후 상품 주문하는 경우가 예시이다.

그러나 HTTP는 웹 서버의 부담을 줄이기 위해 전후 관계를 판단하지 않도록 설계되었는데, 이를 위해 고안된 방법으로는 HTTP 헤더 필드 부가가 대표적이다.
부하 분산 장치는 이러한 정보를 통해 전후 관계를 파악하여 같은 웹 서버에 리퀘스트를 전송할지, 부하가 적은 웹 서버에 전송할지 판단한다.

---

4️⃣ 캐시 서버를 이용한 서버의 부하 분산

앞서 살펴본 부하 분산 장치가 같은 기능의 서버를 여러 대 설치하는 방식이었다면,
또 다른 방식으로 캐시 서버를 사용할 수도 있다.

캐시 서버는 프록시라는 구조를 이용해 데이터를 캐시에 저장하여 부하를 분산한다.

이때 프록시의 개념에 대해 이해해야 하는데,

프록시는 웹 서버와 클라이언트 사이에서 웹 서버에 대한 액세스 동작을 중개한다.

이어서 중개 방식의 핵심을 정리해보면,

웹 서버에서 받은 데이터를 캐시 서버의 디스크에 저장해두고,
웹 서버를 대신해 데이터를 클라이언트에 반송하는 기능을 갖는다.

웹 서버는 URL 점검, 권한 점검, 데이터 내장 등 여러 작업을 수행하는 반면,
캐시 서버는 저장해둔 데이터를 클라이언트에 송신만 하기 때문에 더욱 신속한 응답이 가능해진다.

✔️ 한 대의 캐시로 여러 서버의 데이터를 저장하는 경우 전송 대상을 어떻게 판단하는가?

• 몇 가지 방식이 있지만, 대표적으로 리퀘스트 메시지의 URI에 쓰여진 디렉토리를 보고 판단한다.

✔️ 서버측에서 데이터가 변경된 경우, 캐시 서버는 어떻게 중개하는가?

• If-Modified-Since라는 헤더 필드를 담은 메시지를 웹 서버에 전송하고,
  웹 서버측에서 데이터의 최종 갱신 일시와 비교한다. (위 사진 참고)

포워드 프록시

앞서 설명한 캐시 서버 내의 프록시는 웹 서버측에 프록시가 위치하는 형태이다.
그러나 프록시의 시초는 클라이언트 측에 위치하는 형태였고, 이를 포워드 프록시라 칭한다.

포워드 프록시의 경우, 방화벽을 실현한다는 중요한 목적을 지녔다.

프록시는 리퀘스트의 내용을 조사한 후 전송하기 때문에, 리퀘스트의 내용에 따라 액세스 여부를 판단할 수 있다.

따라서 위험한 사이트나 작업과 관계없는 사이트에 대한 액세스는 금지할 수 있게되며, 패킷 필터링형 방화벽은 IP나 포트 번호만으로 액세스 여부를 판단하기 때문에 프록시와 같이 자세한 조건을 설정할 수 없다는 점에서 차이가 발생한다.

포워드 프록시의 메시지 전송 동작

포워드 프록시는, 웹 서버의 경로명 일부를 추출하여 리퀘스트 메시지에 기록하는 것이 아닌 http://~~~ 형태의 URL을 그대로 메시지에 기록한다는 특징이 있다.

이로 인해 서버측의 캐시 서버와 같이 전송 대상을 사전에 설정할 필요없이, 모든 웹 서버에서 전송할 수 있게된다.

리버스 프록시

포워드 프록시의 경우, 브라우저에서 잘못 설정한 경우 장애의 원인이 되기도 하며 누가 액세스하는지 알 수 없다는 제약이 있다.

따라서 리퀘스트 메시지의 URI에 쓰여진 디렉토리명과 전송 대상의 웹 서버를 대응하여 리퀘스트 메시지를 전송할 수 있도록 했으며,
이것이 캐시 서버에서 사용하는 방식인 리버스 프록시이다.

트랜스페어런트 프록시

리퀘스트 메시지에서 패킷의 IP 헤더를 통해 액세스 대상 웹 서버를 파악하는 방식을 트랜스페어런트 프록시라고 부른다.

이를 통해 포워드 프록시처럼 브라우저 설정이 필요없고, 전송 대상을 캐시 서버에 설정할 필요없이 어느 웹 서버에서나 전송할 수 있게된다.

그러나 트랜스페어런트 프록시를 DNS 서버에 등록하게 되면,
프록시 자체가 액세스 대상이 되어 수신처 IP 주소로 전송 대상의 웹 서버를 판단할 수 없게 된다.

이를 해결하기 위해 리퀘스트 메시지가 웹 서버로 흘러가는 길에 프록시를 설치하고, 프록시가 메시지를 가로챈 뒤 웹 서버에 다시 전송하는 구조를 고안했다.

리퀘스트 메시지가 흐르는 길이 많다면, 길이 수렴되는 곳에 프록시를 설치하게 된다.

트랜스페어런트 프록시를 사용하면 사용자가 프록시를 의식할 필요가 없고, 캐시를 이용한다는 측면에서 비중이 높아지고 있다.

---

5️⃣ 콘텐츠 배포 서비스

캐시 서버가 어느 쪽에 위치하느냐에 따라 이용 효과 차이가 발생한다.

• (a) 웹 서버측 캐시 서버

  • 인터넷의 트래픽은 줄지 않는다.

• (b) 클라이언트측 캐시 서버

  • 서버 운영자가 캐시 서버를 제어할 수 없다.

또한 서버측과 클라이언트측의 장점을 취합한 방식으로, (c)와 같이 프로바이더와 계약하여 서버 운영자가 제어 가능한 캐시 서버를 클라이언트 측 프로바이더에 두는 방법이 있다.

그러나 서버 운영자가 프로바이더와 계약하고 서버를 설치한다는 것은 쉽지 않은 일이므로,

캐시 서버를 설치하여 서버 운영자에게 대출하는 서비스를 제공하는 콘텐츠 배포 서비스가 등장했다.

콘텐츠 배포 서비스 제공자는 프로바이더와 계약하여 웹 서버와 캐시 서버를 연대하며,
다수의 웹 서버 데이터를 캐시에 저장하는 형태로 회사당 비용을 절감한다.

이를 통해 서버 운영자는 캐시 서버에 대한 비용 부담이 줄게된다.

가장 가까운 캐시 서버를 제공하는 방법

콘텐츠 배포 서비스의 경우 다수의 캐시 서버를 이용하는데, 가장 가까운 캐시 서버를 제공하는 구조가 필요하다.

크게 두 가지 방식이 존재하며, 다음과 같다.

• 서버측 DNS에서 각 캐시 서버 장소의 라우터에서 경로표를 수집
  • 이를 통해 라우터로부터 클라이언트측 DNS 서버까지의 경로를 알 수 있고,
    어느 라우터가 클라이언트측 DNS 서버에 가장 가까운지 알게 된다.
  • DNS 서버와 클라이언트가 같은 장소에 있지는 않지만, 대략적인 거리를 측정할 수 있다.
• 리다이렉트용 서버로 액세스 대상 분배
  • HTTP 헤더 중 Location에 가장 가까운 캐시 서버를 기록해두고 여기로 리다이렉트하는 형태로, 액세스 대상을 가장 가까운 캐시 서버로 돌리는 구조이다.
  • 리다이렉트를 위한 HTTP 메시지가 증가하지만, HTTP 메시지의 송신처 IP 주소를 바탕으로 거리를 판단하여 정확도가 높다.

추가적으로, 경로 정보를 사용하지 않고 시험용 패킷의 왕복 시간이 짧은 캐시 서버로 리퀘스트를 다시 보내는 방식도 존재한다.

캐시 갱신 기능

캐시 서버의 데이터가 최신 데이터임을 확인하는 과정에서 응답 시간이 악화되는 경우를 방지하기 위해선, 웹 서버에서 데이터를 갱신하는 경우 캐시 서버도 갱신하는 구조가 필요하다.

콘텐츠 배포 서비스의 캐시 서버에는 이러한 구조가 마련되어 있기 때문에,
원래 데이터의 갱신을 확인할 필요가 없게된다.

콘텐츠 배포 서비스의 캐시 서버는 항상 최신의 상태를 유지한다.

유의할 점은, 리퀘스트를 받았을 때 동적으로 페이지를 생성하는 경우 캐시 서버에 데이터를 저장하면 안 되기때문에,
매번 달라지는 부분과 달라지지 않는 부분을 구분하여 달라지지 않는 부분만 캐시에 저장해야 한다.

---

👏 마무리

서버 앞 방화벽, 캐시 서버, 부하 분산 장치 등을 통과하는 과정에 대해 알아보았다.
다음 포스팅에서는 웹 서버에서 리퀘스트를 받아 요구 내용을 조사한 뒤 응답 메시지를 만들어 반송하는 부분에 대해 알아보자.

---

참고 자료

성공과 실패를 결정하는 1%의 네트워크 원리

---