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

학습 목표

• OSI 7계층 모델과 TCP/IP 4계층 모델을 기반으로 한 네트워크 흐름에 대해 이해할 수 있다.
  • TCP/IP 패킷이 왜 필요한 지 설명할 수 있다.
  • TCP와 UDP의 차이에 대해 설명할 수 있다.
  • 데이터 링크 계층과 물리적 계층에 대해서 설명할 수 있다.
• HTTP 기본 동작과 특징에 대해 이해할 수 있다.
  • 상태유지(Stateful)과 무상태(Stateless)의 개념에 대해 설명할 수 있다.
  • HTTP 메시지 구성에 대해 설명할 수 있다.
• 아키텍처의 구성요소에 대해서 알 수 있다.
  • 프록시, 로드밸런서에 대해 설명할 수 있다.
  • 캐시의 기본 원리와 CDN에 대해 설명할 수 있다.
  • 프록시 서버를 만들고, 프록시 캐시를 컨트롤 할 수 있다.

---

프록시(proxy)

---

• 사전적 의미: 대리, 대리권
• 원 서버를 대리하여 통신하며 캐시, 로드밸런서, 보안 등 중계 역할을 하는 서버
• 프록시 서버가 중간에 위치하기 때문에 클라이언트는 프록시 서버를 ‘서버’라고 인식하고, 서버 입장에서는 프록시 서버를 ‘클라이언트’로 인식하게 됨

• 위치에 따라 포워드 프록시(forward proxy)와 리버스 프록시(reverse proxy)로 나뉨
• 포워드 프록시(forward proxy)
  • 일반적인 프록시 서버는 포워드 프록시를 말하며, 이는 클라이언트-서버 구조에서 클라이언트 쪽을 대리하며, 클라이언트에서 서버로 리소스를 요청할 때 직접 요청하지 않고 프록시 서버를 거쳐서 요청함
  • 사용 목적
    • Privacy
    • Encrytion
    • Compression
    • Security
    • Load Balacing
    • Caching
    • Content Delivery Network
    • Filtering
    • Logging
    • Performance
• 리버스 프록시(reverse proxy
  • 포워드 프록시와 반대의 개념으로, 어플리케이션 서버의 앞에 위치하여 클라이언트가 서버에 요청할 때 리버스 프록시를 호출하고, 리버스 프록시가 원 서버로부터 응답을 전달받아 다시 클라이언트에게 전송하는 역할을 함
  • 사용 목적
    • Load Balancing
    • Orchestration
    • Encrytion
    • Information Security
    • Caching
    • Content Delivery Network

---

로드밸런서(Load Balancer)

---

• 서비스 가용성(availability)을 높이기 위해 하나의 서비스는 보통 두 대 이상의 서버로 구성하는데, 각 서버 IP 주소가 다르므로 사용자가 서비스를 호출할 때는 어떤 IP로 서비스를 요청할지 결정해야 함
• 사용자에 따라 호출하는 서버의 IP가 다르면, 특정 서버에 장애가 발생했을 때, 전체 사용자에게 영향을 미치지 않아 장애 범위는 줄어들겠지만, 여전히 부분적으로 서비스 장애가 발생함
• 이러한 문제점을 해결하기 위해 로드 밸런서(Load Balancer)를 사용함
• 동일한 서비스를 하는 다수의 서버가 등록되고, 사용자로부터 서비스 요청이 오면 로드 밸런서가 받아 사용자별로 다수의 서버에 요청을 분산시켜 부하를 분산함
• 서비스를 위한 가상 IP를 하나 제공하고, 사용자는 각 서버의 개별 IP 주소가 아닌 동일한 가상 IP를 통해 각 서버로 접근함
• 각 서버의 서비스 상태를 체크해 서비스가 가능한 서버로만 사용자의 요청을 분산하므로 ㅅ버에서 장애가 발생하더라고 기존 요청을 분산하여 다른 서버에서 서비스를 제공할 수 있음
• L4 로드 밸런서
  • 일반적인 로드 밸런서가 동작하는 방식
  • TCP, UDP 정보(특히 포트넘버)를 기반으로 로드 밸런싱을 수행함
  • 부하를 분산하는 기능 뿐 아니라, TCP 계층에서의 최적화와 보안 기능을 함께 제공함
  • 최근 사용되는 로드 밸런서는 4계층과 7계층의 기능을 모두 지원하기 때문에 4계층 로드밸런싱만 제공하는 경우는 찾기 어려움
• L7
  • HTTP, FTP, SMTP와 같은 애플리케이션 프로토콜 정보를 기반으로 로드 밸런싱을 수행함
  • HTTP 헤더 정보나 URI와 같은 정보를 기반으로 프로토콜을 이해한 후 부하를 분산함
  • 일반적으로 이런 장비를 ADC(Application Delivery Controller)라고 부르며 리버스 프록시 역할을 수행함
  • 대부분의 L7 로드밸런서는 4계층에서 7계층까지 로드밸런싱 기능을 제공하며, 장애극복(Failover), 리다이렉션의 기능도 함께 수행함

---

캐시

---

• 컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소
• 캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용함
• 캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간 없이 더 빠른 속도로 데이터에 접근할 수 있음
• 브라우저에 캐시를 저장할 땐 헤더에 cache-control 속성을 통해 캐시가 유효한 시간을 지정할 수 있음
• 캐시 유효시간이 지났지만 변경이 없기 때문에 해당 데이터를 써도 되는 상황이라면, 이를 검증하고 사용하는 방법은 없을까?
  • 검증 헤더 Last Modified를 이용해 캐시의 수정시간을 알 수 있음
  • 데이터가 마지막으로 수정된 시간 정보를 헤더에 포함하고, 응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 저장됨
  • 서버의 해당 자료의 최종 수정일과 비교해서 데이터가 수정이 안되었을 경우 응답 메시지에 이를 담아서 알려줌
  • 이때 HTTP Body는 응답 데이터에 없으며, 상태 코드는 304 Not Modified로 변경된 것이 없다는 뜻
• Last-Modified와 If-Modified-Since 정리
  • 캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면?
    • 304 Not Modified + 헤더 메타데이터만 응답 (바디x)
  • 클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타데이터를 갱신
  • 클라이언트는 캐시에 저장되어 있는 데이터 재활용
  • 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드
  • 매우 실용적인 해결책
• Last-Modified와 If-Modified-Since 단점
  • 1초 미만 단위로 캐시 조정 불가능
  • 날짜 기반의 로직 사용
  • 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
  • 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
    • 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우
• 검증 헤더(Validator)
  • ETag
  • Last-Modified
• 조건부 요청 헤더
  • If-Match, If-None-Match
  • If-Modified-Since, If-Unmodified-Since
• 서버에서 완전히 캐시를 컨트롤하고 싶은 경우, ETag
  • Entity Tag
  • 캐시용 데이터에 임의의 고유한 버전 이름을 달아둠
  • 데이터가 변경되면 이 이름을 바꾸어서 변경함(Hash를 다시 생성)
  • 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받는 방식
  • Last-Modified와 마찬가지로, 변경이 없으면 HTTP Body는 응답 데이터에 없으며, 상태 코드는 304 Not Modified
• ETag와 If-None-Match 정리
  • 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받는 방식
  • 캐시 제어 로직을 서버에서 완전히 관리
  • 클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 매커니즘을 모름)
  • 예시
    • 서버는 베타 오픈 기간인 3일 동안 파일이 변경되어도 ETag 유지
    • 애플리케이션 배포 주기에 맞추어 ETag 갱신
• Cache-Control, 캐시 지시어(directives)
  • max-age: 캐시 유효 시간, 초 단위
  • np-cache: 데이터는 캐시해도 되지만, 항상 원(Origin) 서버에 검증하고 사용
  • no-store: 데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용하고 최대한 빨리 삭제)
• Expires, 캐시 만료일 지정(하위 호환)
  • 캐시 만료일을 정확한 날짜로 지정
  • HTTP 1.0부터 사용
  • 지금은 더 유연한 Cache-Control: max-age를 권장하고, 이와 함께 사용하면 Expires는 무시됨

---

프록시 캐시(Proxy Cache)

---

• private 캐시: 클라이언트에서 사용하고 저장하는 캐시
• public: 프록시 캐시 서버의 캐시
• Cache-Control, 캐시 지시어(directives)
  • public: 응답이 public 캐시에 저장되어도 됨
  • private: 응답이 해당 사용자만을 위한 것으로 private 캐시에 저장해야 함(기본값)
  • s-maxage: 프록시 캐시에만 적용되는 max-age
  • Age: xx (HTTP 헤더): 오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(xx초)
  • no-cache: 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의)
  • no-store: 데이터에 민감한 정보가 있으므로 저장하면 안됨(메모리에서 사용하고 최대한 빨리 삭제)
  • must-revalidate: 캐시 만료 후 최초 조회 시 원 서버에 검증해야함, 원 서버 접근 실패 시 반드시 오류가 발생해야함(504 Gateway Timeout), must-revalidate는 캐시 유효 시간이라면 캐시를 사용함
  • no-cache: HTTP 1.0 하위 호환
• 확실한 캐시 무효화 응답을 하고 싶다면, 아래의 캐시 지시어를 모두 넣어야 함
  • Cache-Control: no-cache, no-store, must-revalidate
  • Pragma: no-cache
• no-cache vs must-revalidate
  • no-cache의 경우
    • 캐시 서버 요청시, 프록시 캐시 서버에 도착하면 no-cache인 경우 원 서버에 요청을 하게 됨
    • 그리고 원 서버에서 검증 후 304 응답을 하게 됨
    • 만약 프록시 캐시 서버와 원 서버 간 네트워크 연결이 단절되어 접근이 불가능하다면, 오류가 아닌 오래된 데이터라도 보여주자라는 개념을 200 OK 응답을 함
  • must-revalidate
    • 원 서버에 접근이 불가능하다면 504 Gateway Timeout 오류를 보냄

---

CDN(Content Delivery Network)

---

• 콘텐츠를 좀 더 빠르고 효율적으로 제공하기 위해 등장한 서비스
• 특징
  • 원본을 복사하여 저장할 여러개의 캐시 서버로 구성
  • 콘텐츠를 요청받은 경우 데이터를 전달하기 가장 유리한 캐시 서버에서 관련 콘텐츠를 제공
    • 제공할 콘텐츠를 가지고 있으며 위치상으로 가장 가까운 캐시 서버가 우선순위를 가짐
• 정적 콘텐츠: 내용이 거의 변하지 않는 콘텐츠로 CDN의 캐시 서버에 저장하기 적합함
  • HTML 파일, 동영상과 같은 콘텐츠
  • 변화가 없는 콘텐츠
  • 개인화되지 않은 대중적인 콘텐츠
• 동적 콘텐츠: 접속할때 마다 내용이 바뀌거나 사용자 마다 다른 내용을 보여주는 콘텐츠로, CDN 네트워크가 지원하기 어렵기 때문에 동적 콘텐츠 자체를 저장하기 보다는 공통적인 HTML 파일 부분을 캐시 서버에 저장함
  • 위치, IP 주소, 사용시간 관련 콘텐츠
  • 사용자가 접근할때 마다 내용이 달라지는 콘텐츠
  • 카드 번호, 전화번호 등 개인화된 정보 관련 콘텐츠
• 이점
  • DDos 공격에 대해 어느정도의 대응이 가능
  • 로딩속도 감소로 인한 사용자 경험 향상
  • 트래픽 분산으로 인한 트래픽 관련 비용 절감
• 네트워크 구성 방법
  • Scatterd 방식: 최대한 낮은 응답 시간에 집중
    • 세계 곳곳에 최대한 많은 캐시 서버를 제공
    • 낮은 수용량의 데이터 센터 및 캐시 서버
    • 매우 높은 관리비용 및 사용자 요금
    • 연결 수요가 적은 지역 대상으로 적절한 방식
  • Consolidated 방식: 여러 서버를 통합하여 운용하는 방식
    • 다수의 고성능 서버로 통합하여 운용하는 방식
    • 응답시간 증가, 하지만 관리 및 유지 비용이 낮아짐
    • 연결 수요가 많은 지역 대상으로 적절한 방식

과거	현재
정적 콘텐츠	동적 및 정적 콘텐츠
매우 낮은 응답 속도에 집중	낮은 응답 속도, 안정성, 보안에 집중
데이터센터를 최대한 분산	데이터 센터를 대다수 통합
매우 높은 비용	저렴한 비용