IT STUDY LOG
[네트워크 기초] 02. 아키텍처를 구성하는 요소들 본문
# 학습 목표
- 아키텍처의 구성요소에 대해서 알 수 있다.
- 프록시, 로드밸런서에 대해 설명할 수 있다.
- 캐시의 기본 원리와 CDN에 대해 설명할 수 있다.
- 프록시 서버를 만들고, 프록시 캐시를 컨트롤 할 수 있다.
# 학습 내용
목차
1. 프록시 (Proxy)
2. 로드밸런서(Load Balancer)
3. 캐시의 기본 원리 및 적용
4. 캐시 검증 헤더와 조건부 요청
5. 프록시 캐시(Proxy Cache)
6. CDN
1. 프록시(proxy)
프록시(Proxy)란?
- 기존 서버를 대리하여 통신하며 캐시, 로드밸런서, 보안 등 중계 역할을 하는 하는 서버
- 구성 : 클라이언트 - 프록시 서버 - 서버
> 클라이언트는 프록시 서버를 ‘서버’라고 인식
> 서버 입장에서는 프록시 서버를 ‘클라이언트’로 인식
프록시 서버 위치에 따른 구분
포워드 프록시(forward proxy)
- 클라이언트-서버 구조에서 클라이언트 쪽을 대리하며, 클라이언트에서 서버로 리소스를 요청할 때 직접 요청하지 않고 프록시 서버를 거쳐서 요청
리버스 프록시(reverse proxy)
- 포워드 프록시와 반대의 개념으로, 애플리케이션 서버의 앞에 위치하여 클라이언트가 서버에 요청할 때 리버스 프록시를 호출하고, 리버스 프록시가 원 서버로부터 응답을 전달받아 다시 클라이언트에게 전송하는 역할
- 클라이언트는 리버스 프록시를 서버라고 생각하는 구조
프록시 서버의 사용 목적 및 용도
프록시 서버의 사용 목적
- 프라이버시 강화 (ex) 웹 서버에 클라이언트 IP 숨기는 요청
- 암호화
- 네트워크 대역폭 감소 및 성능 향상을 위해 서버 응답 압축
- 정보 보안 위협으로부터 웹 서버를 보호하는 보안 프론트엔드 역할
- 로드밸런싱 구현으로 부하 분산
- 캐싱 프록시를 통해 과부하 방지 및 응답 속도 향상
- 콘텐츠 전송 네트워크 캐시 서버를 통해 응답 향상
- 캐시 서버를 통해 필터링 가능
- 네트워크 트래픽을 로깅
- 네트워크 서비스 속도를 향상하도록 프록시 설계
리버스 프록시 서버의 예시
- 로드 밸런싱 역할을 수행, 수평 확장
- 요청 전달 위치를 판단하고 결정
- 암호화
- DDoS와 같은 위협 방어를 위한 보안
- 성능 향상과 서버 부하 감소를 위한 캐싱
- 콘텐츠 전송 네트워크
2. 로드밸런서(Load Balancer)
- 가용성을 위해 서비스를 보통 두 대 이상의 서버로 구성할 경우
① 각 서버 IP주소가 다르기 때문에 사용자가 서비스를 호출할 때는 어떤 IP로 서비스를 요청할지 결정할 필요성
② 사용자에 따라 호출하는 서버의 IP가 다르면 특정 서버에 장애가 발생했을 때 전체 사용자에게 영향을 미치지는 않겠지만 여전히 부분적으로 서비스 장애가 발생
∴ 이러한 문제점을 해결하기 위해서 로드 밸런서(Load Balancer)를 사용
로드밸런서
- 로드밸런서에 동일한 서비스를 하는 다수의 서버를 등록하고, 요청이 오면 로드 밸런서가 받아 사용자별로 다수의 서버에 요청을 분산시켜 부하를 분산
- 로드밸런서에 서비스를 위한 가상 IP를 하나 제공하고, 사용자는 각 서버의 개별 IP 주소가 아닌 동일한 가상 IP를 통해 각 서버로 접근
- 로드 밸런서는 각 서버의 서비스 상태를 체크해 서비스가 가능한 서버로만 사용자의 요청을 분산해 서버에서 장애가 발생하더라도 기존 요청을 분산하여 다른 서버에서 서비스를 제공 가능
계층별 로드 밸런서
L4 로드 밸런서
- 일반적인 로드 밸런서 동작하는 방식
- TCP, UDP 정보(포트 넘버)를 기반으로 로드 밸런싱을 수행
- 부하를 분산하는 기능뿐만 아니라, TCP 계층에서의 최적화와 보안 기능을 함께 제공
- But, 최근 사용되는 로드 밸런서는 4 계층과 7 계층의 기능을 모두 지원
L7 로드 밸런서
- HTTP, FTP, SMTP와 같은 애플리케이션 프로토콜 정보를 기반으로 로드 밸런싱을 수행
- HTTP 헤더 정보나 URI와 같은 정보를 기반으로 프로토콜을 이해한 후 부하를 분산
- 일반적으로 이런 장비를 ADC(Application Delivery Controller)라고 부르며 리버스 프록시 역할을 수행
- 대부분의 L7 로드밸런서는 4 계층에서 7 계층까지 로드밸런싱 기능을 제공하며, 장애극복(Failover), 리다이렉션의 기능도 함께 수행
3. 캐시의 기본 원리 및 적용
캐시란?
- 캐시 : 데이터나 값을 미리 복사해 놓는 임시 장소
- 캐시가 없을 경우 데이터 변경이 없어도 동일한 요청에 네트워크를 통해 또 응답/요청 과정 수행 필요
- 용량이 클수록 비용이 커지고 브라우저의 로딩 속도 지연
- 느린 사용자 경험
캐시의 적용
- 캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용
- 캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간 없이 더 빠른 속도로 데이터에 접근 가능
- 브라우저에 캐시를 저장할 땐 헤더에 cache-control 속성을 통해 캐시가 유효한 시간을 지정 가능
- 캐시 가능 시간 동안 네트워크 재요청, 응답 필요 없음
- 브라우저 로딩 속도가 빠름
- 빠른 사용자 경험 제공
캐시 시간이 초과한다면?
- 다시 서버에 요청하고 응답
- 응답 결과를 브라우저가 렌더링 하면 브라우저 캐시는 기존 캐시를 지우고 새 캐시로 데이터를 업데이트, 유효 간 초기화
4. 캐시 검증 헤더와 조건부 요청
캐시 유효 시간이 지났지만 변경이 없을 경우 검증하고 사용하려면?
If-Modified-Since 헤더와 Last-modified 헤더
응답 헤더 : Last-modified
- HTTP 응답 헤더의 Last-modified 검증 헤더를 통해 캐시 수정 시간을 확인 가능
- 응답 결과를 캐시에 저장할 때 해당 데이터의 최종 수정일 정보가 담기게 됨
요청 헤더 : If-Modified-Since
- 캐시 유효 시간이 초가 되더라도 HTTP 요청 헤더에 If-Modified-Since 헤더를 이용해 조건부 요청이 가능
If-Modified-Since, Last-modified의 작동 방식
- 요청 시 서버는 HTTP 요청의 If-Modified-Since 헤더를 확인하고 최종 수정일을 검증하고 변경되지 않았을 경우 304 Not Modified로 HTTP 응답함
- 변경된 데이터가 없으므로 응답 바디가 없음
- 클라이언트는 응답을 확인하고 서버가 보 응답 헤더 정보로 캐시의 메타 데이터를 갱신하여 다시 캐시 유효 시간만큼 유지
- 클라이언트는 캐시에 저장되어 있는 해당 데이터를 재사용하고 캐시에서 조회한 데이터를 렌더링
∴ 네트워크 다운로드 발생하나 용량이 적은 헤더 정보만 다운로드하여 실용적
If-Modified-Since, Last-modified의 단점
- 1초 미만(0.x초) 단위로 캐시 조정 불가능
- 날짜 기반의 로직 사용
- 데이터를 수정해 날짜가 다르더라도 같은 데이터를 수정해 데이터 결과가 똑같은 경우 적용 어려움
- 서버에서 별도의 캐시 로직을 관리하고 싶은 경우 적용 어려움 (ex) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시 유지하고 싶은 경우
ETag 헤더와 If-None-Match 헤더
응답 헤더 : ETag (Entity Tag)
- 캐시용 데이터에 임의의 고유한 버전 이름을 달아두는 방식 (ex) ETag : "v1.1", ETag : "630dfmope690afk" 등
- 데이터가 변경되면 이 이름을 바꾸어 변경함(Hash를 재생성) (ex) ETag : "630dfmope690afk" -> ETag : "9k19tmdl1djmf"
- 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받는 방식
요청 헤더 : If-None-Match
- 캐시 시간이 초과되어 다시 요청해야 하는 경우 ETag값을 검증해 달라는 요청인 If-None-Match 요청 헤더에 ETag 값을 넣어 조건부 요청
ETag, If-None-Match의 작동 방식
- 요청 시 서버는 HTTP 요청의 If-None-Match 헤더를 확인 후 ETag 값과 검증하고 변경되지 않았을 경우 304 Not Modified로 HTTP 응답함
- 변경된 데이터가 없으므로 응답 바디가 없음
- 클라이언트는 응답을 확인하고 서버가 보 응답 헤더 정보로 캐시의 메타 데이터를 갱신하여 다시 캐시 유효 시간만큼 유지
- 클라이언트는 캐시에 저장되어 있는해당 데이터를 재사용하고 캐시에서 조회한 데이터를 렌더링
- 클라이언트는 캐시 메커니즘을 모르고 단순히 서버에 값을 제공하기만 하면 됨
∴ If-Modified-Since, Last-Modifed 방식과 동일하게 효율적이며 캐시 제어 로직을 서버에서 완전 관리 가능
캐시와 관련된 헤더 - Cache-Control : 캐시 지시어(directives)
Cache-Control: max-age
- 캐시 유효 시간, 초 단위
Cache-Control: no-cache
- 데이터는 캐시해도 되지만, 항상 Origin 서버에 검증하고 사용
Cache-Control: no-store
- 데이터에 민감한 정보가 있으므로 저장해선 안됨(메모리에서 사용하고 최대한 빨리 삭제)
Expires : 캐시 만료일 지정(하위 호환)
- Expires: Mon, 01 Jan 1990 00:;00:00 GMT
- 캐시 만료일을 정확한 날짜로 지정
- HTTP/1.0부터 사용
- 지금은 더 유연한 Cache-Control: max-age를 권장하며 동시 사용 시 Expires는 무시됨
5. 프록시 캐시(Proxy Cache)
프록시 서버란?
- 클라이언트가 다른 네트워크 서비스에 간접적으로 접속할 수 있께 하는 컴퓨터 시스템이나 응용 프로그램
- 클라이언트-서버 사이에 대리로 통신을 수행하는 것을 프록시, 그 중계 기능을 하는 서버를 프록시 서버
- 클라이언트-서버가 간접적으로 네트워크에 접속할 수 있어 보안, 캐싱을 통한 성능, 트래픽 분산의 장점
프록시 캐시
- 지리적으로 멀리 떨어진 지역의 Origin 서버에 접근하기 보다 중간에 Proxy Cache 서버를 두어 자료를 조회하도록 서버 구성하면 속도 향상
> Priavte 캐시 : Client에서 사용, 저장하는 캐시
> Public 캐시 : Proxy Cache Server에서 사용, 저장하는 캐시
프록시 캐시와 관련된 헤더 - Cache-Control : 캐시 지시어(directives)
Cache-Control: public
- 응답이 public 캐시에 저장되어도됨
Cache-Control: private
- default값, 응답이 해당 사용자만을 위한 것으로 private 캐시에 저장되어야 함
Cache-Control: s-maxage
- 프록시 캐시에만 적용되는 max-age
Age: 60(HTTP 헤더)
- 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)
민감한 정보와 같은 정보를 웹 브라우저가 임의로 캐싱할 때 무효화하는 방법?
프록시 캐시와 관련된 헤더 - Cache-Control : 캐시 지시어(directives)
Cache-Control: no-cache
- 데이터는 캐시해도 되지만, 항상 Origin 서버에 검증하고 사용
Cache-Control: no-store
- 데이터에 민감한 정보가 있으므로 저장해선 안됨(메모리에서 사용하고 최대한 빨리 삭제)
Cache-Control: must-revalidate
- 캐시 만료 후 최초 조회 시 origin 서버에서 검증해야 함
- origin 서버에 접근 실패하면 반드시 오류 발생 (504 Gateway Timeout)
- must0revalidate는 캐시 유효 시간이라면 캐시를 사용
Pragma: no-cache
- HTTP/1.0 하위 호환
∴ 확실히 캐시 무효화 응답을 하고 싶을 경우 Cache-Control: no-cache, no-store, must0revalidate Pragma: no-cache 지시어를 모두 넣어야 함
no-cache vs must-revalidate 동작 방식의 차이
no-cache 기본 동작
① 원 서버에 접근이 가능할 경우
- 클라이언트 -> 프록시 캐시 서버 : 캐시 서버 요청
- 프록시 캐시 서버 -> 원 서버 : 검증 요청
- 원 서버 -> 프록시 캐시 서버 : 304 Not Modified
- 프록시 캐시 서버 -> 클라이언트 : 304 Not Modified
- 클라이언트 : 저장된 캐시 사용해 렌더링
② 원 서버에 접근이 불가능할 경우
- 클라이언트 -> 프록시 캐시 서버 : 캐시 서버 요청
- 프록시 캐시 서버 -> 원 서버 : 검증 요청
- 원 서버 -> 프록시 캐시 서버 : X
- 프록시 캐시 서버 -> 클라이언트 : 200 OK
- 클라이언트 : 오류가 아닌 오래된 캐시 렌더링
must-revalidate 기본 동작
① 원 서버에 접근이 불가능할 경우
- 클라이언트 -> 프록시 캐시 서버 : 캐시 서버 요청
- 프록시 캐시 서버 -> 원 서버 : 검증 요청
- 원 서버 -> 프록시 캐시 서버 : X
- 프록시 캐시 서버 -> 클라이언트 : 504 Gateway Timeout
- 클라이언트 : 캐시를 사용하지 않음 (ex) 오래된 통장 잔고를 보여주어선 안 되므로
6. CDN (Content Delivery Network)
- 콘텐츠를 좀 더 빠르고 효율적으로 제공하기 위해 등장한 서비스
- 원본 서버와 다수의 CDN 데이터 센터로 구성
CDN의 특징
- 원본을 복사해 저장할 여러개 캐시 서버로 구성
- 콘텐츠를 요청 받은 경우 데이터 전달이 가장 유리한 캐시 서버에서 관련 콘텐츠르 제공
- 제공할 콘텐츠를 가지고 있으며, 지리적으로 가장 가까운 캐시 서버가 우선 순위
CDN의 동작 방식
- 요청한 곳에서 가장 가까운 CDN 데이터 센터가 해당 콘텐츠를 저장하고 있는지 확인
- 만일 데이터가 존재하지 않는다면, 해당 CDN 데이터 센터를 제외하고 나머지 중 지리적으로 가까운 CDN 데이터 센터를 확인 * 반복
- 만일 모든 CDN 데이터 센터가 데이터를 가지고 있지 않으면 원본 서버에서 콘텐츠를 제공
- 제공된 데이터는 요청한 곳에서 가장 지리적으로 가까운 CDN 데이터 센터에 저장
정적 및 동적 콘텐츠
| 정적 콘텐츠 | 동적 콘텐츠 |
| - 내용이 거의 변하지 않는 콘텐츠 - HTML, CSS 파일, 동영상과 같이 변화가 없는 콘텐츠 - 개인화되지 않은 개인적인 콘텐츠 - CDN 캐시 서버 저장이 적합 |
- 접속 시마다 내용이 바뀌거나, 사용자에 따라 다른 내용을 보여주어야 하는 콘텐츠 - 위치, IP 주소, 사용시간 관련 콘텐츠로 사용자 접근 시마다 내용이 변경되는 콘텐츠 - 카드번호, 전화번호 등 개인화된 정보 관련 콘텐츠 - 컨텐츠가 바뀔 때마다 캐시 서버에 바뀐 컨텐츠가 전파되어야 하므로 '공통적인 부분'을 캐시 서버에 저장 - CDN 캐시 서버에 저장하기 적합하지 않음 |
CDN의 이점
DDoS 공격에 대해 어느 정도 대응이 가능
- CDN 데이터 센터와 같이 데이터 센터가 지리적으로 여러 곳에 분산될 경우 하나의 서버가 마비되어도 다른 데이터 센터가 동작함
- 데이터 센터들은 거대한 컴퓨팅 능력을 가지고 있어 DDoS 공격으로 서비스 장애가 발생하기 어려움
로딩 속도 감소로 인한 사용자 경험 향상
- 페이지 로딩이 짧아져 사이트 이탈이나 잠재 고객 감소와 같은 부정적 효과가 줄어듦
트래픽 분산으로 인한 트래픽 관련 비용 절감
- 방대한 요청을 하나의 서비스에서 담당하기 위해서는 고성능 서버와 고성능 인터넷 수용력이 필요 -> 고비용
- 서버를 분산하면 낮은 성능의 인터넷, 서버로도 요청 처리가 가능
- 사용자 경험 향상과 비용 절감 효과
CDN 네트워크 구성 방법
Scattered 방식
- 최대한 빠른 응답 속도에 집중하는 방식
- 지리적으로 많은 곳에 저성능의 데이터 센터를 구성하고 연결
- 관리해야하는 데이터 센터가 많아져 데이터 센터 유지 비용이 높아 클라우드 제공자가 관리 비용을 사용자에 전가 -> 고비용
- 수요가 적은 지역에 데이터 센터를 세울 경우 유리
Consolidated 방식
- 여러 서버를 통합해 운용하는 방식
- 고성능의 데이터 센터를 통합하여 운용하는 방식
- 응답 시간은 늘어나지만 데이터 센터 수가 줄어들어 관리 및 유지 비용 절감
- 유지 관리 비용이 줄어들어 사용자에게 전가하는 요금이 감소
- 연결 수요가 많은 지역 대상에 데이터 센터를 설립할 경우 적절한 방식
CDN의 시간에 따른 변화
과거
- 빠른 응답 속도에 집중
- 정적 콘텐츠
- Scattered 방식 (데이터 센터를 최대한 분산)
- 응답 속도는 빠르나 고비용
현재
- 동적 및 정적 콘텐츠
- 상대적으로 느린 응답 속도, 안정성, 보안에 집중
- Consolidated 방식 (데이터 센터를 대다수 통합)
- 저렴한 비용
# References
'devops bootcamp 4 > 클라우드 서비스 운영' 카테고리의 다른 글
| [Docker] 02. Docker CLI (0) | 2023.04.12 |
|---|---|
| [Docker] 01. 왜 Docker인가? (0) | 2023.04.11 |
| [Docker] 00. Before You Learn (0) | 2023.04.11 |
| [YAML] 01. YAML과 JSON (0) | 2023.04.11 |
| [네트워크 기초] 01. OSI 7계층과 TCP/IP 4계층 (0) | 2023.04.06 |
