프록시(proxy)
프록시서버
컴퓨터 네트워크에서 다른 서버 상의 자원을 찾는 클라이언트로부터 요청을 받는 중계하는 서버 즉, 중계해주는 서버
프록시 서버는 프록시 서버에 요청된 내용들을 캐시를 이용하여 저장한다.
포워드 프록시
- 일반적인 프록시 서버
- 클라이언트-서버 구조에서 클라이언트 쪽을 대리
- 클라이언트에서 서버로 리소스를 요청할 때 직접 요청하지 않고 프록시 서버를 거쳐 요청
- 인터넷보다 프록시서버를 먼저 호출하면 포워드 프록시
- 서버가 응답받은 IP는 프록시 서버의 IP이기 때문에 클라이언트가 누군지 알 수 없음. -> 클라이언트를 감춤
- Ex) 회사 내부 인트라넷에서 인터넷상에 있는 서버에 요청을 할 때 프록시 서버를 먼저 호출함
리버스 프록시
- 애플리케이션 서버의 앞에 위치
- 클라이언트가 서버에 요청할 때 리버스 프록시를 호출
- 리버스 프록시가 원 서버로부터 응답을 전달받아 다시 클라이언트에게 전송
- 인 클라이언트가 프록시 서버를 호출하여 내부망에 있는 서버를 호출하면 리버스 프록시
- 클라이언트는 리버스 프록시 서버를 먼저 호출하여 실제 서버의 IP를 알 수 없음
- Ex) 회사 내부 인트라넷에 있는 서버를 호출할 때 인터넷 망에 있는 클라이언트가 리버스 프록시 서버에 요청하여 응답을 받음
프록시(포워드) EX
- 클라이언트의 IP를 숨겨 개인 정보 보호
- SSL과 같은 암호화 가능
- 네트워크 대역폭을 줄이고 서버의 응답을 압축하여 성능을 향상
- 방화벽으로 보호되는 서버와 인터페이스 하여 보안 강화
- 로드 밸런싱을 구현하여 서버가 다운돼도 서비스 계속 작동 가능
- (비디오, 이미지, 스크립트 및 HTML) 정적 콘텐츠를 캐시하여 최근에 엑세스한 콘텐츠를 빠르게 제공하여 과부하 방지
- 콘텐츠 전송 네트워크를 이용하여 가장 가까운 위치에서 서비스를 제공
- 프록시를 사용하여 구성 가능한 정책에 따라 사용자가 웹사이트 또는 기타 서비스 연결 불가하게 필터링 가능
- 감사 추천 또는 도청과 같은 동기를 위해 네트워크 트래픽을 기록하는 데 사용 가능
- 웹 브라우저가 웹사이트의 IP주소를 조회하는데 사용하는 DNS 쿼리와 같은 네트워크 서비스의 속도를 높이도록 설계 가능
리버스 프록시 EX
- 요청을 전달할 위치를 결정 가능
- TSL와 같은 암호화 구현
- 요청을 스캔하고 의심스러워 보이는 모든 것을 거부하여 정보 보안에 용이
- 요청을 캐시하여 성능 향상 가능
- 콘텐츠 전송 네트워크는 종종 리버스 프록시로 구현되기도 함
로드밸런서(Load Balancer)
서비스 규모가 커지면 서버 한 대로는 모든 서비스를 수용할 수 없게 되며, 서버 한 대로 서비스를 제공할 수 있는 용량이 충분하더라도 서비스를 단일 서버로 구성하면 해당 서버의 애플리케이션, 운영체제, 하드웨어에 장애가 발생했을 때, 정상적인 서비스를 제공할 수 없다.
서비스 가용성(availability)을 높이기 위해서 하나의 서비스는 보통 두 대 이상의 서버로 구성하는데 각 서버 IP주소가 다르므로 사용자가 서비스를 호출할 때는 어떤 IP로 서비스를 요청할지 결정해야 한다. 사용자에 따라 호출하는 서버의 IP가 다르면, 특정 서버에 장애가 발생했을 때, 전체 사용자에게 영향을 미치지 않아 장애 범위는 줄어들겠지만 여전히 부분적으로 서비스 장애가 발생하며 이러한 문제점을 해결하기 위해서 로드 밸런서(Load Balancer)를 사용한다.
로드 밸런서는 동일한 서버를 하는 다수의 서버가 등록되고 클라이언트로부터 서비스 요청이 오면 로드 밸런서가 받아 사용자별로 다수의 서버에 요청 분산하여 부하를 분산한다.
로드 밸런서는 서비스를 위한 가상 IP를 하나 제공하고, 사용자는 서버의 개별 IP가 아닌 동일한 가상IP를 통해 서버로 접근한다. 또한 각 서버의 서비스의 상태를 체크해 하나의 서버에 장애가 발생하여도 장애가 발생하지 않는 서버로 요청을 분산하여 장애 없이 서비스를 제공한다.
계층별 로드 밸런서
로드 밸런서는 동작하는 계층에 따라 OSI 7 계층 모델을 기준으로 보통 4 계층과 7 계층으로 나눈다.
L4 로드 밸런서
일반적인 로드 밸런서가 동작하는 방식이며 TCP, UDP 정보(특히 포트 넘버)를 기반으로 로드 밸런싱을 수행한다. 이때, 부하를 분산하는 기능뿐만 아니라, TCP 계층에서의 최적화와 보안 기능을 함께 제공한다. 그러나 최근 사용되는 로드 밸런서는 4 계층과 7계층의 기능을 모두 지원하기 때문에 4계층 로드밸런싱만 제공하는 경우는 찾기 어렵다.
L7 로드 밸런서
HTTP, FTP, SMTP와 같은 애플리케이션 프로토콜 정보를 기반으로 로드 밸런싱을 수행하며 HTTP 헤더 정보나 URI와 같은 정보를 기반으로 프로토콜을 이해한 후 부하를 분산한다. 일반적으로 이런 장비를 ADC(Application Delivery Controller)라고 부르며 리버스 프락시 역할을 수행한다. 대부분의 L7 로드밸런서는 4 계층에서 7 계층까지 로드밸런싱 기능을 제공하며, 장애극복(Failover), 리다이렉션의 기능도 함께 수행한다.
캐시의 기본 원리 및 적용
클라이언트가 logo.jpg 이미지에 대한 요청을 보내고 서버가 해당 이미지에 대한 응답을 줄 때, HTTP 헤더가 0.1M, 바디가 1.0M로 총 1.1M로 가정해보겠다. 같은 이미지를 다시 요청하더라도 첫 번째처럼 똑같이 1.1M의 응답을 보냅니다. 이 경우 logo.jpg 데이터가 변경되지 않아도 계속 데이터를 새로 다운로드하여야 한다.
인터넷 네트워크는 매우 느리고 비싸며 브라우저 로딩 속도 또한 느려지며 느린 사용자의 경험을 제공하여 해결책을 나온 것이 캐시이다.
캐시(cache)
컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 말한다.
캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리거나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용하며 캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간이 없어 더 빠른 속도로 데이터에 접근이 가능하다.
브라우저에 캐시를 저장할 땐 헤더에 cache-control 속성을 통해 캐시의 유효한 시간을 지정할 수 있다.
Ex) Cache-control : max-age = 60 이면 60초 동안 캐시가 유효하다는 의미
두번째 요청에서는 캐시를 우선 조회하며 캐시가 존재하고 아직 60초가 지나지 않아 유효한 캐시라면 해당 캐시에서 데이터를 가져온다.
이러한 경우 캐시 가능 시간 동안 네트워크를 사용하지 않아도 돼서 비싼 네트워크 사용량을 줄일 수 있으며 브라우저 로딩 속도가 매우 빠르며 사용자에게 빠른 경험을 제공한다.
만약, 캐시의 유효시간이 초과한다면 어떻게 될까?
이러한 경우 다시 서버에 요청을 하여 다시 조회하고, 캐시를 갱신하여 60초간 유효한 데이터를 응답받으며 이때, 다시 네트워크 다운로드가 발생하게 된다.
응답 결과를 브라우저가 랜더링 하면 브라우저 캐시는 기존 캐시를 지우고 새 캐시로 데이터를 업데이트하며 이 과정에서 캐시 유효 시간이 다시 초기화된다.
캐시 검증 헤더와 조건부 요청
앞에선 캐시의 유효시간이 초과하면 다시 요청을 보내 새로운 데이터로 캐시를 업데이트하였다. 굳이 데이터가 같은데 또 요청을 보내 업데이트하면 데이터 낭비이다. 만약 캐시 유효시간이 지나도 변경이 없어서 해당 데이터를 써도 되는 상황이라면 이를 검증하고 사용하는 방법은 없을까?
Last-Modified 와 If-Modified-Since
검증 헤더 Last Modified를 이용해 캐시의 수정시간을 알 수 있으며 Last Modified는 데이터가 마지막으로 수정된 시간 정보를 헤더에 포함된다. 이로 인해 응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 저장됩니다.
처음 Last-Modified를 확인하여 데이터의 수정을 검증하고 수정값이 없다면 바디를 제외한 HTTP 헤더(0.1M)만 전송하며 브라우저 캐시에 응답 결과를 재사용, 헤더 메타 데이터 또한 갱신(60초 유효)한다. 브라우저는 캐시에서 조회한 데이터를 랜더링 한다.
즉, 캐시 유효 시간이 초과하여도, 서버의 데이터가 갱신되지 않으면 304 Not Modified 응답 코드와 바디 없이 헤더 메타데이터만 응답하며 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타데이터를 갱신하여 클라이언트는 캐시에 저장되어있는 데이터를 재활용한다.
결과적으로, 네트워크 다운로드는 발생하지만 용량이 적은 헤더 정보만 다운로드한다.
Last - Modified와 If-Modified-Since 단점
- 1초 미만(0.x초) 단위로 캐시 조정이 불가능하며 날짜 기반의 로직을 사용한다.
- 데이터를 수정하여 날짜가 다르지만 수정 결과는 똑같을 때 수정 날짜는 바뀌었기 때문에 바디값을 포함하여 응답한다.
- 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
ex) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우
ETag 와 If-None-Match
ETag : 캐시용 데이터에 임의의 고유한 버젼이름을 달아둔 것이며 데이터가 변경되면 이름을 바꾸어서 변경함(Hash를 다시 생성)
단순하게 ETag를 보내서 같으면 유지, 다르면 다시 받는 방식이다.
처음 캐시를 받을 때 서버에서 헤드에 ETag를 작성해 응답하고 클라이언트의 캐시에서 해당 ETag 값을 저장한다.
만약 캐시 시간이 초과돼서 다시 요청을 해야 하는 경우라면 ETag 값을 검증하는 If-None-Match를 요청헤더에 작성해서 보낸다.
데이터가 수정되었는지 ETag 값을 통해 검증하여 데이터가 변경되지 않았을 경우 ETag는 동일하기에 If-None-Match는 거짓이 되며 서버에서는 304 Not Modified를 응답하며 HTTP 바디값은 없이 헤더만 전송한다. 브라우저 캐시에서 응답 결과를 재사용, 헤더 메타데이터 또한 갱신하여 브라우저는 캐시에서 조회한 데이터를 랜더링한다.
즉, ETag만 보내서 같으면 유지, 다르면 다시 받는 방식이며 캐시 제어 로직을 서버에서 완전히 관리한다. 클라이언트는 단순히 이 값을 서버에게 제공할 뿐 캐시 매커니즘은 모른다.
ex) 서버는 베타 오픈 기간인 3일동안 데이터의 변경이 있어도 ETag를 동일하게 유지하고 애플리케이션 배포 주기에 맞춰 ETag 갱신 할 수 있다.
Cache-Control
- Cache-control: max-age : 캐시 유효 시간, 초 단위
- Cache-Control : no-cache : 데이터는 캐시해도 되지만, 항상 원(Origin) 서버에 검증하고 사용
- Cache-Control : no-stroe : 데이터에 민감한 정보가 있으므로 저장하면 안되고 메모리에서 사용하고 최대한 빨리 삭제
- Expires : 캐시 유효 기간, 날짜 HTTP/1.0부터 사용하며 max-age를 더 사용 권장하며 동시에 사용됐을 때 Expires는 무시됨.
프록시 캐시(Proxy Cache)
만약 한국에 있는 클라이언트가 특정 데이터가 필요한 상황인데 해당 데이터의 원 서버가 미국에 있을 때 시간이 적게 걸리면 문제없지만 많이 걸리면 문제가 발생 할 수 있다. 이러한 문제를 해결하기위해 클라이언트와 원 서버 사이에 있는 프록시 캐시 서버를 도입하였다. 한국에 프록시 캐시 서버를 두고 한국의 클라이언트는 프록시 캐시 서버를 통해 자료를 가져올 때 여러 사람이 찾는 자료일수록 이미 캐시에 등록 되어있기때문에 원서버에 요창하는것보다 더 빠른 속도로 자료를 가져올 수 있다.
이때, 클라이언트에서 사용하고 저장하는 캐시를 Private 캐시라 하며, 프록시 캐시 서버의 캐시를 Public라 한다.
Cache-Control
- Cache-Control : pubilc - 응답이 pubilc 캐시에 저장되어도 됨
- Cache-Control : private - 응답이 해당 사용자만을 위한 것이며 private 캐시에 저장해야 함(기본값)
- Cache-Control : s-maxage - 프록시 캐시에만 적용되는 max-age
- Age : n(초) - HTTP 헤더이며 오리신 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)
캐시 무효화
클라이언트가 캐시를 적용하지 않아도 임의로 브라우저가 캐시를 적용하는 경우, 특정 페이지에서 캐시가 되면 안 되는 정보(통장 잔고)가 있다면 캐시 무효화를 어떻게 할 수 있을까?
Cache-Control
- Cache-Control : no-cache = 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용
- Cache-Control : no-store = 데이터에 민감한 정보가 있으므로 저장하면 안되며, 메모리에서 사용하고 최대한 빨리 삭제
- Cache-Control : must-revalidate = 캐시 만료 후 최초 조회 시 원 서버에 검증해야하며 원 서버에 접근 실패 시 반드시 오류가 발생해야함 - 504(Gateway Timeout) 캐시가 만료되지않은경우엔 캐시를 사용함
- Pragma : no-cache = HTTP/1.0 하위 호환
만약 캐시 무효화를 확실하게 하고싶은 경우엔 Pragma와 같은 하위 호환까지 포함하여 적용해야한다.
ex)Cache-Control : no-cache, no-store, must-revalidate, Pragma : no-cache
no-cache vs. must-revalidate
캐시 서버 요청을 하면 프록시 캐시 서버에 도착하면 no-cache인 경우 원 서버에 요청을 하게 되며 원 서버에서 검증이 되면 304 응답을 한다.
만약 프록시 캐시 서버와 원 서버 간 네트워크 연결이 단절되어 접근이 불가능하면, no-cache에서는 응답으로 오류가 아닌 오래된 데이터라도 보여주자라는 개념으로 200 OK를 응답을 한다.
CDN(Content Delivery Network)
https://www.cloudflare.com/ko-kr/learning/cdn/what-is-a-cdn/
콘텐츠를 좀 더 빠르고 효율적으러 제공하기위해 등장한 서비스이며 원본을 복사하여 저장할 여러개의 캐시 서버(데이터 센터)로 구성되있으며 콘텐츠를 요청받은 경우 데이터를 전달하기 가장 유리한 캐시 서버에서 관련 콘텐츠를 제공한다. 이때, 제공할 콘턴체를 가지고 있으며 위치상으로 가장 가까운 캐시 서버가 우선 순위를 가진다.
데이터 센터가 다음 지도와 같이 위치하고 있을 때 원본서버에서 원본을 저장하고 있으며, S3와 같이 CND에 속하지 않은 외부의 서버일때,
한국에서 콘텐츠 요청을 받는다고 가정하면
먼저, CDN 네트워크는 요청한 곳과 가장 가까운 데이터 센터가 해당 콘텐츠를 저장하고 있는지 확인한다. 위 그림에선 중국 데이터 센터가 가장 가까우며 만약 중국 데이터센터에 요청하는 콘텐츠가 없다면 다음으로 거리가 가까운 데이터 센터를 선택한다. 모든 데이터 센터가 요청하는 콘텐츠가 없다면 원본 서버에서 제공해야하며 이런 경우 콘텐츠를 요청한 곳과 가장 가까운 데이터 센터에 저장한다.
정적 및 동적 콘텐츠
CDN이 다룰 수 있는 콘텐츠는 정적,동적 콘텐츠로 구분 할 수 있다.
정적 콘텐츠
- 내용이 거의 변하지 않는 콘텐츠
- 변화가 없는 콘텐츠
- 개인화되지 않은 대중적인 콘텐츠 - 변화가 거의 없기 때문에 CDN의 캐시 서버에 저장하기 적합
- 동영상, HTML 파일, 뉴스 기사 등
동적 콘텐츠
- 사용자가 접근할때 마다 내용이 달라지는 콘텐츠
- 개인화된 정보 관련 콘텐츠 - 늘 변화하기때문에 CDN의 캐시 서버에 저장하기 부적합
- 콘텐츠가 바뀔때마다 캐시 서버에 바뀐 콘텐츠를 전파되어야 함 - 공통적인 부분을 캐시 서버에 저장
- 위치, IP주소, 사용시간, 카드번호, 전화번호 등
CDN의 이점
- DDOS 공격에 대한 어느정도의 대응이 가능
- 로딩속도 감소로 인한 사용자 경험 향상
- 트래픽 분산으로 인한 트래픽 관련 비용 절감
1. DDos(Distributed Denial of Service attack)는 분산 서비스 거부 공격이며, 서버의 수용량보다 훨씬 많은 요청을 보내 서버를 사용 불가능하게 만든다. DDos 공격으로 한곳의 서버가 다운되도 지리적으로 가까운 다른 서버에서 콘텐츠 제공이 가능하다.
2.만약 어느 사이트 접속 시 로딩이 완료되기까지 10초 이상 소요될 때 기다리는 사람도 있겠지만 대부분 해당 사이트를 떠날 것이다. 그럼 사이트 이용 유저가 줄어들면 즉, 잠재 고객의 수가 적다는 의미로 해석 될 수 있다.
3.만약 모든 요청을 하나의 서버에서 담당하게된다면 고성능의 서버와 인터넷 수용력이 필요하며 높은 성능에는 소모되는 전력 많으며 인터넷회선 또한 엄청난 요청을 감당해야 하기 때문에 매우 높은 비용이 든다. 하지만 서버를 세계 곳곳에 분산한다면 낮은 성능의 인터넷, 서버로도 감당 가능하며 외국에 있는 사용자들의 로딩 시간 또한 단축 시킬 수 있어 사용자 경험 향상 및 비용 절감의 효과를 볼 수 있다.
Scattered 방식
- 최대한 낮은 응답시간에 집중한 방식
- 세계 곳곳에 최대한 많은 캐시 서버를 제공
- 낮은 수용량의 데이터 센터 및 캐시 서버
- 매우 높은 관리비용 및 사용자 요금 -> 사용자들에게 전가되는 요금이 커진다는 의미
- 연결 수요가 적은 지역 대상으로 적절한 방식
Consolidated 방식
- 여러 서버를 통합하여 운용하는 방식
- 다수의 고성능 서버로 통합하여 운용하는 방식
- 응답 시간 증가, 하지만 관리 및 유지 비용이 낮아짐 -> 사용자들에게 전가되는 요금이 줄어든다는 의미
- 연결 수요가 많은 지역대상으로 적절한 방식
시간에 따른 변화
| 과거 | 현재 |
| 정적 콘텐츠 | 동적 + 정적 콘텐츠 |
| 매우 낮은 응답 속도에 집중 | 낮은 응답 속도, 안정성, 보안에 집중 |
| 데이터센터를 최대한 분산 | 데이터 센터를 대다수 통합 |
| 매우 높은 비용 | 저렴한 비용 |
'TIL' 카테고리의 다른 글
| 24일차 AWS (0) | 2022.05.19 |
|---|---|
| 23일차 네트워크 기초 (0) | 2022.05.19 |
| 22일차 발표 (0) | 2022.05.17 |
| 21일차 발표 (0) | 2022.05.16 |
| 21일차 네트워크 기초 (0) | 2022.05.16 |