[7. Apr] 아키텍처 / TIL

프록시 서버

• 원 서버를 대리하여 통신하며 캐시, 로드밸런서, 보안 등 중계 역할을 하는 서버
• 클라이언트는 프록시 서버를 '서버'라고 인식하고, 서버는 프록시 서버를 '클라이언트'로 인식한다.
• 웹 서버에서 클라이언트의 IP를 숨겨 프라이버시를 강화하는 데 사용할 수 있다.
• 웹 사이트의 SSL과 같은 암호화를 구현한다.
• 서버로부터의 응답을 압축하여 네트워크 대역폭을 줄이고 성능을 향상시킨다.
• 사용자가 정책에 따라 웹 사이트 또는 기타 서비스에 연결하지 못하도록 할 수 있다.
• 네트워크 트래픽을 기록할 수 있다.

---

포워드 프록시 (forwaed proxy)

• 일반적인 프록시로 클라이언트-서버 구조에서 클라이언트 쪽을 대리한다.
• 클라이언트에서 서버로 리소스를 요청할 때 직접 요청하지 않고 프록시 서버를 거쳐서 요청한다.

리버스 프록시 (reverse proxy)

• 애플리케이션 서버의 앞에 위치하여, 클라이언트가 서버에 요청할 때 리버스 프록시를 호출하고,
• 리버스 프록시가 원 서버로부터 응답을 전달받아 다시 클라이언트에게 전송하는 역할을 한다.

---

로드밸런서 (Load Balancer)

서비스를 제공할 수 있는 용량이 단일 서버로 충분하더라도, 서버를 한 대로 구성하면 장애가 발생했을 때 정상적인 서비스를 제공할 수 없다.

서비스 가용성을 높이기 위해 하나의 서비스는 보통 두 대 이상의 서버로 구성하는 데 각 서버 IP주소가 다르므로 사용자가 서비스를 호출할 때 어떤 IP로 서비스를 요청할 지 결정해야 한다.

여러 대의 서버를 사용하면 특정 서버에 장애가 발생했을 때 전체 사용자에게 영향을 미치진 않지만 부분적으로 서비스 장애가 발생하는데, 로드 밸런서는 이러한 문제를 해결하기 위한 방안이다.

---

• 로드 밸런서는 사용자로부터 요청이 들어오면 받아서 사용자 별로 다수의 서버에 요청을 분산시킨다.
• 때문에 서버에 장애가 발생하더라도 다른 서버에서 서비스를 제공받을 수 있게 한다.
• L4 로드 밸런서
  - TCP, UDP 기반 / 일반적인 로드 밸런서 동작 방식
  - 기존 로드 밸런서의 부하 분산 기능 뿐 아니라, TCP 계층의 최적화 보안 기능을 함께 제공한다.
  - 최근에는 4계층과 7계층의 기능을 모두 지원한다.
• L7 로드 밸런서 (ADC, Application Delivery Controller)
  - 프로토콜(HTTP, FTP, SMTP) 정보 기반 / 리버스 프록시 역할을 수행한다.
  - HTTP 헤더 정보나 URI 같은 정보를 기반으로 프로토콜을 이해한 후 부하를 분산한다.
  - 4계층에서 7계층까지 로드 밸런싱 기능을 제공하며, 장애 극복, 리다이렉션 기능도 함께 수행한다.

---

캐시 (Cache)

캐시가 없을 경우 사용자는 데이터가 변경되지 않아도 계속 네트워크를 통해 데이터를 다운로드 받아야한다.
때문에 용량이 클 수록 비용이 커지고 로딩 속도가 느려진다. 

• 캐시 : 데이터나 값을 미리 복사해놓은 임시 장소
• 계산이나 접근 시간 없이 더 빠른 속도로 데이터에 접근할 수 있다.
• 브라우저에 캐시를 저장할 땐 헤더에 cache-control 속성을 통해 캐시가 유효한 시간을 지정할 수 있다.
• 유효한 시간을 지정하면 응답 결과를 캐시에 저장하며 지정한 시간 동안 유효하게 된다.
• 요청이 또 다시 오면 캐시를 우선 조회하여 캐시가 존재하거나 지정한 시간이 지나지 않아 유효하다면 해당 캐시에서 데이터를 가져온다.
• 유효 시간이 지나게 되면 서버에 재요청하여 다시 네트워크 다운로드가 발생하고 기존 캐시를 지우고 새 캐시로 업데이트 하며 유효 시간이 초기화된다.

 

---

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

검증 헤더 (Validator)

• ETag: "v1.0", ETag:"1234asdfg12354"
• Last-Modified: Mon, 01 Jan 2020 00:00:00 GMT
  
  

조건부 요청 헤더

• If-Match, If-None-Match: ETag 값 사용
• If-Modified-Since, If-Unmodified-Since: Last-Modified 값 사용

---

Last-Modified / If-Modifed-Since

검증 헤더 Last Modified를 이용해 캐시의 수정 시간을 알 수 있다. (응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 저장)
따라서 캐시 유효시간이 초과되더라도 서버의 데이터가 갱신되지 않으면 If-Modified-Since / 304 Not Modified + 헤더 메타데이터로만 응답한다. (바디 X) 
다음은 검증, 응답 순서이다.

## 응답 헤더 ##

HTTP/1.1 304 Not Modified
Content-Type: image/jpeg
Cache-Control: max-age=60
Last-Modified: 2021년 3월 3일 08:00:00
Content-Length: 34012

• 유효 시간이 끝난 캐시의 최종 수정일과 비교해서 데이터가 수정되었는지 검증한다.
• 수정되지 않았다면 바디를 제외한 HTTP 헤더만 응답 메시지로 전송한다. / Body(1.0M)가 빠진 0.1M 만 전송
• 브라우저 캐시에서 응답 결과를 재사용하며, 헤더 메타데이터도 갱신된다.
• 브라우저는 캐시에서 조회한 데이터를 렌더링한다.
• 위 헤더의 상태코드 304 Not Modified는 변경된 것이 없다는 뜻이다.
• 클라이언트는 응답 헤더 정보로 캐시의 메타데이터를 갱신해 주고 다시 일정 시간(60초) 동안 유효하게 된다.

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

---

ETag / If-None-Match

• 캐시용 데이터에 임의의 도유한 버전 이름을 달아두어 데이터가 변경되면 이 이름을 바꾸어 변경한다. (Hash 재생성)
• 단순하게 ETag만 보내서 태그가 같으면 유지하고, 다르면 다시 받는 방식이다.
• 캐시 제어 로직을 서버에서 완전히 관리하고, 애플리케이션 배포 주기에 맞춰 ETag를 갱신한다.
• 캐시 시간이 초과돼서 다시 요청 해야 하는 경우 ETag 값을 검증하는 If-None-Match를 요청 헤더에 작성해서 보낸다.
• 서버에서 데이터가 변경되지 않았을 경우 ETag는 동일하기 때문에 If-None-Match는 거짓이 된다.

## 응답 헤더 ##

HTTP/1.1 200 OK
Content-Type: image/jpeg
Cache-Control: max-age=60
ETag: "1234asdfg12354"
Content-Length: 34012

---

프록시 캐시

평소 우리는 해외 사이트에서 불편함 없이 빠르게 정보를 받아볼 수 있다. 이러한 것들이 클라이언트와 원 서버 사이에 프록시 캐시가 도입되어 있기 때문이다.

우리가 어떠한 자료를 찾을 때 여러 사람이 찾은 자료일수록 이미 캐시에 등록되어 있기 때문에 빠른 속도로 자료를 가져올 수 있다. 이는 캐시가 같은 국내에 있기 때문에 원서버에 접근하는 것보다 훨씬 빠르게 자료를 가져올 수 있는 것이다.

---

캐시 지시어 (directives) : 캐시에 관련된 헤더 & 조건부 요청 헤더

Cache-Control : 캐시 무효화
웹 브라우저가 민감한 정보까지 임의로 캐싱할 때 무효화하는 헤더

• Cache-Control: s-maxage
  - 프록시 캐시에만 적용되는 max-age
  
  
• Cache-Control: no-cache
  - 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용 (이름에 주의)
  
  
• Cache-Control: no-store
  - 데이터에 민감한 정보가 있으므로 저장하면 안됨
  
  
• Cache-Control: private
  - 응답이 해당 사용자만을 위한 것, private 캐시에 저장해야 함(기본 값)
  - 클라이언트에서 사용하고 저장하는 캐시
  
  
• Cache-Control: public
  - 응답이 public 캐시에 저장되어도 됨
  - 프록시 서버의 캐시
  
  
• Cache-Control: must-revalidte
  - 캐시 만료 후 최초 조회 시 원 서버에 검증해야 함
  - 원 서버 접근 실패 시 반드시 504(Gateway Timeout) 오류가 발생해야 함
  - must-revalidate : 캐시 유효 시간이라면 캐시를 사용함
  
  
• Age: 60 (HTTP 헤더)
  - Origin 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)
  
  
• Pragma: no-cache
  - HTTP 1.0 하위 호환
  
  
• Expires: Mon, 01 Jan 2020 00:00:00 GMT
  - 캐시 만료일을 정확한 날짜로 지정하며, HTTP 1.0부터 사용한다.
  - max-age와 함께 사용하면 Expires는 무시된다.

 

Cache-Control : no-cache, no-store, must-revalidate
Pragma: no-cache

확실한 캐시 무효화 응답을 하고 싶을 때 위 캐시 지시어를 모두 넣어야 한다.

---

	no-cache	must-revalidate
기본 동작	캐시 서버 요청 시 프록시 캐시 서버에 도착하면 원 서버에 요청을 하고 원 서버에서 검증 후 304 응답을 한다.	캐시 서버 요청 시 프록시 캐시 서버에 도착하면 원 서버에 요청을 하고 원 서버에서 검증 후 304 응답을 한다.
접근 불가 상태	오류가 아닌, 오래된 데이터라도 보여주자는 개념으로 200 OK 응답을 한다.	504 Gateway Timeout 오류

---

Content Delivery Network (CDN)

• 콘텐츠를 좀 더 빠르고 효율적으로 제공하기 위해 등장한 서비스
• 원본을 복사하여 저장할 여러 개의 캐시 서버로 구성되어 있다.
• 콘텐츠 요청을 받으면 데이터를 전달하기 가장 유리한 캐시 서버에서 관련 콘텐츠를 제공한다.
  - (위치상 가장 가까운 캐시서버가 우선 순위를 가진다.)
• CDN은 여러 캐시 서버로 구성되어 있기 때문에 *DDoS 공격에 대응할 수 있다.
• CDN을 이용해 로딩 속도가 증가하면 사용자의 사이트 이탈 확률이 감소하고 잠재 고객이 증가할 수 있다.
• 요청을 여러 서버에서 분산 처리하기 때문에 한 서버에서 큰 트래픽을 감당할 수 있는 인터넷 회선과 높은 성능의 서버가 필요하지 않아서 비용이 절감된다.

---

CDN이 다룰 수 있는 콘텐츠의 종류

• 정적 콘텐츠 : 내용이 거의 변하지 않고 대중적인 콘텐츠로 CDN의 캐시 서버에 저장하기 적합하다.
  ex. HTML 파일, 동영상
• 동적 콘텐츠 : 접속할 때마다 내용이 바뀌거나 사용자 마다 다른 내용을 보여주며, 공통적인 부분을 캐시 서버에 저장한다.
  ex. 위치, IP 주소, 사용시간 관련 콘텐츠 / 개인화된 정보 관련 콘텐츠

---

CDN이 서버를 분산하는 방식

Scattered

• 빠른 응답속도를 목표로 하기 때문에 세계 곳곳에 비교적 낮은 성능의 데이터 센터를 구성하고 연결해 두어야 한다.
• 클라우드 제공자는 관리 비용을 사용자에게 전가하고, 데이터 센터 유지 비용이 높개 때문에 사용 요금이 높다.
• 연결 수요가 적은 지역 대상으로 적절한 방식이다.
  
  

Consolidated

• 다수의 고성능 데이터 센터들을 통합하여 운용하기 때문에 응답 시간이 증가하지만 데이터 센터 관리 및 유지 비용이 절감된다.
• 유지 관리 비용이 적어지는 것은 사용자들에게 전가되는 요금이 줄어든다는 뜻이다.
• 연결 수요가 많은 지역 대상으로 적절하다.

---

 초기에는 응답 속도에 중점을 두었기 때문에 Scattered 방식과 CDN 정적 콘텐츠가 주류였기 때문에 사용자에게 전가되는 비용이 높았다.

 하지만 점차 동적 콘텐츠를 지원하고 데이터 센터를 통합하기 시작하여 Consolidated 방식이 주류가 되어 사용자에게 전가되는 비용이 줄어들고 있다.

 또한 DDoS 공격 등 사이버 공격에 대응하고 어느 상황에서도 콘텐츠를 제공할 수 있도록 보안과 안정성에 집중하고 있습니다.

 

 

* 메타데이터 : 데이터를 설명해주는 데이터
* DDoS 공격 (Distributed Denial of Service attack) : 서버의 수용량보다 훨씬 많은 요청을 보내 서버를 사용 불가능하게 만드는 것