네트워크 기초 - 아키텍처를 구성하는 요소들

프록시(Proxy)

 

원 서버를 대리하여 통신하며, 캐시, 로드밸런서, 보안 등 중계 역할을 하는 서버.

 

프록시 서버가 중간에 위치하기 때문에 클라이언트는 프록시 서버를 '서버'로 인식

서버 입장에서 프록시 서버를 '클라이언트'로 인식.

 

포워드 프록시(forward proxy)

일반적인 프록시 서버를 말함.

클라이언트-서버 구조에서 클라이언트 쪽을 대리, 클라이언트에서 서버로 리소스를 요청할 때 직접 요청하지 않고 프록시 서버를 거침.

 

리버스 프록시(reverse proxy)

포워드 프록시의 반대 개념. 애플리케이션 서버의 앞에 위치, 클라이언트가 서버에 요청할 때 리버스 프록시를 호출, 리버스 프록시가 원 서버로부터 응답을 받아 다시 클라이언트에 전송.

 

로드밸런서(load balancer)

네트워크 트래픽을 여러 대의 서버 또는 컴퓨터에 분산시켜 처리할 수 있도록 도와주는 하드웨어 또는 소프트웨어.

서버 부하 분산, 고가용성, 확장성 등의 이점을 제공. 예를 들어, 웹 사이트에 대한 요청이 많은 경우, 로드 밸런서는 이러한 요청을 여러 대의 웹 서버에 분산하여 각 서버가 일을 나누어 처리하도록 하여 전체적인 성능을 향상시키고, 서버의 다운타임을 최소화.

 

계층별 로드밸런서

L4 로드 밸런서

일반적인 로드 밸런서가 동작하는 방식. TCP, UDP 정보를 기반으로 로드 밸런싱을 수행.

이 때, 부하를 분산하는 기능 뿐만 아니라, TCP 계층에서의 최적화와 보안 기능을 함께 제공. 

 

L7 로드 밸런서

HTTP, FTP, SMTP와 같은 애플리케이션 프로토콜 정보를 기반으로 로드 밸런싱을 수행.

이 때, HTTP 헤더 정보나 URI와 같은 정보를 기반으로 프로토콜을 이해한 후 부하를 분산.

일반적으로 이런 장비를 ADC라고 부르고 리버스 프록시 역할을 수행.

 

ADC(Application Delivery Controller)

로드 밸런싱, SSL 오프로딩, 웹 어플리케이션 방화벽, 웹 애플리케이션 가속, 캐싱 등 다양한 기능을 제공하는 네트워크 장비.

ADC는 로드 밸런서와 유사한 기능을 가지고 있지만, 더 많은 기능을 하나의 장비에서 제공하므로, 서버의 부하를 줄이고, 인프라스트럭처의 간소화와 유지보수의 용이성을 제공.

 

캐시의 기본 원리 및 적용

캐시는 컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소.

브라우저에 캐시를 저장할 땐 헤더에 cache-control 속성을 통해 캐시가 유효한 시간을 지정.

예시) Cache-Control: Max-age=60 으로 설정하면 60초동안만 캐시가 유효.

 

만약 설정된 60초가 지난 후 요청을하면 다시 서버에 요청을 하고 60초간 유효한 logo.jpg 이미지를 응답받음.

이때 다시 네트워크에 다운로드가 발생.

 

응답결과를 브라우저가 렌더링하면 브라우저 캐시는 기존 캐시를 지우고 새 캐시로 데이터를 업데이트.

이 과정에서 캐시 유효 시간이 다시 초기화.

 

캐시 검증 헤더와 조건부 요청

검증 헤더 Last Modified

캐시의 수정시간을 알 수 있음.

예시) Last-Modified: 2023년 4월 7일 08:00:00

 

이 검증 헤더는 데이터가 마지막으로 수정된 시간 정보를 헤더에 포함.

 

If-Modified-Since

캐시 유효시간이 초과되더라도 조건부 요청을 할 수 있음.

 

예시) If-Modified-Since: 2023년 4월 7일 08:00:00

 

정리

• 캐시가 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않을때 (304 Not Modified + 헤더 메타데이터만 응답 (이때 바디는 없음)
• 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타데이터를 갱신
• 클라이언트는 캐시에 저장되어 있는 데이터 재활용
• 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
• 매우 실용적인 해결책

Last-Modified와 If-Modified-Since 단점

• 1초 미만 단위로 캐시 조정 불가능
• 날짜 기반의 로직 사용
• 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
• 서버에서 별도의 캐시 로직을 관리하고 싶은 경우

ETag와 If-None-Match 검증 헤더

ETag

서버에서 완전히 캐시를 컨트롤하고 싶은 경우 사용.

 

정리

• 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받는 방식
• 캐시 제어 로직을 서버에서 완전히 관리
• 클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 매커니즘을 모름)

캐시 지시어(directive)

Cache-Control: max-age

• 캐시 유효 시간. 초 단위

Cache-Control: no-cache

• 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용

Cache-Control: no-store

• 데이터에 민감한 정보가 있으므로 저장하면 안됨( 메모리에서 사용하고 최대한 빨리 삭제)

캐시 만료일 지정

Expires: Fri, 07 April 2023 00:00:00 GMT

• 캐시 만료일을 정확한 날짜로 지정
• HTTP 1.0부터 사용
• 지금은 유연한 Cache-Control: max-age 권장 하지만 같이 사용하면 Expires는 무시.