Apache kafka performance(throughput) - without data loss and guaranteeing dat...SANG WON PARK
Apache Kafak의 성능이 특정환경(데이터 유실일 발생하지 않고, 데이터 전송순서를 반드시 보장)에서 어느정도 제공하는지 확인하기 위한 테스트 결과 공유
데이터 전송순서를 보장하기 위해서는 Apache Kafka cluster로 partition을 분산할 수 없게되므로, 성능향상을 위한 장점을 사용하지 못하게 된다.
이번 테스트에서는 Apache Kafka의 단위 성능, 즉 partition 1개에 대한 성능만을 측정하게 된다.
향후, partition을 증가할 경우 본 테스트의 1개 partition 단위 성능을 기준으로 예측이 가능할 것 같다.
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
Apache Kafak의 빅데이터 아키텍처에서 역할이 점차 커지고, 중요한 비중을 차지하게 되면서, 성능에 대한 고민도 늘어나고 있다.
다양한 프로젝트를 진행하면서 Apache Kafka를 모니터링 하기 위해 필요한 Metrics들을 이해하고, 이를 최적화 하기 위한 Configruation 설정을 정리해 보았다.
[Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안]
Apache Kafka 성능 모니터링에 필요한 metrics에 대해 이해하고, 4가지 관점(처리량, 지연, Durability, 가용성)에서 성능을 최적화 하는 방안을 정리함. Kafka를 구성하는 3개 모듈(Producer, Broker, Consumer)별로 성능 최적화를 위한 …
[Apache Kafka 모니터링을 위한 Metrics 이해]
Apache Kafka의 상태를 모니터링 하기 위해서는 4개(System(OS), Producer, Broker, Consumer)에서 발생하는 metrics들을 살펴봐야 한다.
이번 글에서는 JVM에서 제공하는 JMX metrics를 중심으로 producer/broker/consumer의 지표를 정리하였다.
모든 지표를 정리하진 않았고, 내 관점에서 유의미한 지표들을 중심으로 이해한 내용임
[Apache Kafka 성능 Configuration 최적화]
성능목표를 4개로 구분(Throughtput, Latency, Durability, Avalibility)하고, 각 목표에 따라 어떤 Kafka configuration의 조정을 어떻게 해야하는지 정리하였다.
튜닝한 파라미터를 적용한 후, 성능테스트를 수행하면서 추출된 Metrics를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
Understanding of Apache kafka metrics for monitoring SANG WON PARK
2019 kafka conference seould에서 발표한 "Apache Kafka 모니터링을 위한 Metrics 이해" 슬라이드 자료
기존 2018년 자료에서 모니터링 관점에서 중요한 metrcis를 중심으로 정리하였고, 2019년 기준으로 추가/변경된 metrics를 반영하였다.
주용 내용은
- 업무에 최적화된 apache kafka 모니터링을 하려면?
- 어떤 정보를 모니터링 해야 할까?
- 적시성 관점의 모니터링 지표 (TotalTimeMs에 대한 세부 구조 이해)
- 안정성 관점의 모니터링 지표 (데이터 유실이 없이 중단없는 서비스)
- 언제 apache kafka 클러스터를 확장해야 할까? (어떤 지표를 봐야 할까?)
위 모든 지표는 producer/broker/consumer 3가지 측면에서 검토하였다.
컨퍼런스 영상 링크 : https://www.youtube.com/watch?v=p2RGsTOCHAg
다양한 하둡에코 소프트웨어 성능을 검증하려는 목적으로 성능 테스트 환경을 구성해보았습니다. ELK, JMeter를 활용해 구성했고 Kafka에 적용해 보았습니다.
프로젝트에서 요구되는 성능요건을 고려해 다양한 옵션을 조정해 시뮬레이션 해볼수 있습니다.
처음 적용한 뒤 2년 정도가 지났지만, kafka 만이 아니다 다른 Hadoop eco 및 Custom Solution에도 유용하게 활용 가능하겠습니다.
Apache kafka performance(throughput) - without data loss and guaranteeing dat...SANG WON PARK
Apache Kafak의 성능이 특정환경(데이터 유실일 발생하지 않고, 데이터 전송순서를 반드시 보장)에서 어느정도 제공하는지 확인하기 위한 테스트 결과 공유
데이터 전송순서를 보장하기 위해서는 Apache Kafka cluster로 partition을 분산할 수 없게되므로, 성능향상을 위한 장점을 사용하지 못하게 된다.
이번 테스트에서는 Apache Kafka의 단위 성능, 즉 partition 1개에 대한 성능만을 측정하게 된다.
향후, partition을 증가할 경우 본 테스트의 1개 partition 단위 성능을 기준으로 예측이 가능할 것 같다.
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
Apache Kafak의 빅데이터 아키텍처에서 역할이 점차 커지고, 중요한 비중을 차지하게 되면서, 성능에 대한 고민도 늘어나고 있다.
다양한 프로젝트를 진행하면서 Apache Kafka를 모니터링 하기 위해 필요한 Metrics들을 이해하고, 이를 최적화 하기 위한 Configruation 설정을 정리해 보았다.
[Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안]
Apache Kafka 성능 모니터링에 필요한 metrics에 대해 이해하고, 4가지 관점(처리량, 지연, Durability, 가용성)에서 성능을 최적화 하는 방안을 정리함. Kafka를 구성하는 3개 모듈(Producer, Broker, Consumer)별로 성능 최적화를 위한 …
[Apache Kafka 모니터링을 위한 Metrics 이해]
Apache Kafka의 상태를 모니터링 하기 위해서는 4개(System(OS), Producer, Broker, Consumer)에서 발생하는 metrics들을 살펴봐야 한다.
이번 글에서는 JVM에서 제공하는 JMX metrics를 중심으로 producer/broker/consumer의 지표를 정리하였다.
모든 지표를 정리하진 않았고, 내 관점에서 유의미한 지표들을 중심으로 이해한 내용임
[Apache Kafka 성능 Configuration 최적화]
성능목표를 4개로 구분(Throughtput, Latency, Durability, Avalibility)하고, 각 목표에 따라 어떤 Kafka configuration의 조정을 어떻게 해야하는지 정리하였다.
튜닝한 파라미터를 적용한 후, 성능테스트를 수행하면서 추출된 Metrics를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
Understanding of Apache kafka metrics for monitoring SANG WON PARK
2019 kafka conference seould에서 발표한 "Apache Kafka 모니터링을 위한 Metrics 이해" 슬라이드 자료
기존 2018년 자료에서 모니터링 관점에서 중요한 metrcis를 중심으로 정리하였고, 2019년 기준으로 추가/변경된 metrics를 반영하였다.
주용 내용은
- 업무에 최적화된 apache kafka 모니터링을 하려면?
- 어떤 정보를 모니터링 해야 할까?
- 적시성 관점의 모니터링 지표 (TotalTimeMs에 대한 세부 구조 이해)
- 안정성 관점의 모니터링 지표 (데이터 유실이 없이 중단없는 서비스)
- 언제 apache kafka 클러스터를 확장해야 할까? (어떤 지표를 봐야 할까?)
위 모든 지표는 producer/broker/consumer 3가지 측면에서 검토하였다.
컨퍼런스 영상 링크 : https://www.youtube.com/watch?v=p2RGsTOCHAg
다양한 하둡에코 소프트웨어 성능을 검증하려는 목적으로 성능 테스트 환경을 구성해보았습니다. ELK, JMeter를 활용해 구성했고 Kafka에 적용해 보았습니다.
프로젝트에서 요구되는 성능요건을 고려해 다양한 옵션을 조정해 시뮬레이션 해볼수 있습니다.
처음 적용한 뒤 2년 정도가 지났지만, kafka 만이 아니다 다른 Hadoop eco 및 Custom Solution에도 유용하게 활용 가능하겠습니다.
AWS의 CDN 서비스인 CloudFront의 가속 및 DDoS 방어 소개
# CloudFront 장점
- 수퍼 PoP: AWS 클라우드 구축/운영 Know-How 가 담긴 고성능/대용량 아키텍쳐
* 국내 최대 Capacity / 가장 빠르게 성장하는 글로벌 CDN 서비스
- Single-Service: (캐싱, 다이나믹 가속, HTTPS, AWS Shield Standard 등) 동일 가격 체계로 제공
- AWS Backbone 전용망: Edge <=> Origin 가속
- 인라인 DDoS 방어: Shield Standard & Advance
- AWS 서비스 연동성
드랍박스, nDrive 등과 같은 클라우드 스토리지 서비스들은 데이터를 어떻게 저장하는지에 대한 이론적 내용과 실제 구현 내용을 살펴봅니다. 이 발표에서는 OpenStack 의 swift라는 Object Storage 를 이용하여 이론이 어떻게 구현되어있는지 알아봅니다.
웹 사이트의 빠른 로딩을 위한 프론트 엔드 최적화 기법과 더불어 알아두어야 할 HTTP 프로토콜 최적화를 언급하며, 최근 발표된 HTTP/3를 소개합니다.
HTTP/3는 "Hyper Text Transfer Protocol over QUIC"의 내용을 근간으로 UDP의 장점을 HTTP에 활용한 버전입니다.
HTTP/3를 알기 위해서는 QUIC에 대한 이해와 함께, 기존 버전인 HTTP/2에서 어떤 부분이 개선되었는지에 대한 이해가 동시에 필요합니다.
Chrome을 활용한 웹 성능 비교 예제들은 HTTP/3의 기술들을 빠르게 이해하는 데 도움이 될 것입니다.
Java Memory 구조와 내용에 대해서 정리한 PPT 입니다.
회사에서, 서버가 메모리 누수가 발생하여 뻗는 사건이 생겨서 팀원들이 전부 공부를 해서 발표를 했습니다.
GC는 Heap 영역에서 일어납니다.
메서드 영역 : 클래스 놀이터 입니다.
힙 영역 : 생성된 객체 및 배열 놀이터 입니다.
스택 영역 : 메서드 놀이터 입니다.
자바스크립트 스터디 하면서, 발표했던 자료.
(각자 맡은 부분에 대한 개념 정리해서 발표)
JavaScript 중요 개념인 실행컨텍스트와 클로저에 대해서 정리가 되어있다. (업로드 하면서 다시 봤는데. 여전히 어렵고 헷갈린다)
실행컨텍스트는 자바스크립트에 실행환경 등의 정보를 확인하는 도구로 이해하면 된다.
- 참조 : 인사이드 자바스크립트
REST에 대한 내용을 정리한 PPT 입니다.
많은 내용이 있지만 축약 또는 이해되는 내용만 정리를 하려고 하다보니 빠진 부분이 있을 수 있습니다.
REST는
1. URI와 HTTP Method를 이용해 객체화된 서비스에 접근하는 것.
2. HTTP URI로 잘 표현된, 리소스에 대한 행위를 HTTP Method에 정의 리소스에 내용은 json, xml, yaml 등의 다양한 언어로 정의.
3. 하나의 URI는 하나의 고유한 리소스를 대표하도록 설계된다는 개념.* REST는 표준이 아님 + REST는 프로토콜이 아님.
결론적으로 REST API를 사용하는 궁극적인 목적은
서로 다른 플랫폼(OS, 개발언어)에서 데이터를 주고받기 위해서와 범용 인터페이스(HTTP/URI)를 만들어서 각 API를 독립적으로 배포하기 위함이다.
객체지향에 관련해서, 가볍게 내용을 정리하였습니다.
참고서적 : 스프링 입문을 위한, 자바 객체 지향의 원리와 이해 김종민 지음
객체지향.
말은 참 어려운데. 프로그래밍 하면서 사람이 인식하는 사물 또는 실체를 하나하나 조합해서 프로그래밍 하자는 패러다임입니다.
쉽게, 객체를 가지고 놀자 이겁니다.
객체지향언어에서는
클래스(Class) 객체(Object)가 존재합니다.
클래스는 추상화 및 분류
객체는 실제를 의미합니다.
예) 사람클래스 -> 원빈 객체 / 동물 클래스 -> 고양이 객체
4대 특징
- 캡슐화
- 상속
- 추상화
- 다형성
객체지향 개념을 완벽히 이해하려면. 많이 공부해야 할거같습니다..ㅠㅠ
TDD 테스트 주도 개발이며, 하나의 개발 방법론 입니다.
- TDD는 반복 테스트을 이용한 소프트웨어 개발법이다. 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 소프트웨어를 구현한다.
- TDD의 목표는 작동하는 깔끔한 코드 “Clean code that works”
- TDD는 아래 단계의 반복으로 진행된다.
빨강 : 실패하는 작은 테스트 케이스를 작성한다. 처음에는 컴파일조차 안될 수 있다.
초록 : 테스트를 통과하는 코드를 작성한다.
리펙터링 : 테스트를 통과하기 위해 만든 코드의 모든 중복을 제거하고, 불명확한 것을 명확히 한다.
이러한 단계로 인해 TDD는 “업무 코드 작성 전에 테스트 코드를 먼저 만드는 것”으로 정의되기도 한다
Spring Framework 에서 중요한 개념인 DI(의존성 주입)에 대해서, 정리하였습니다.
DI(Dependency Injection) 란?
- 스프링 IoC 컨테이너 핵심 개념 중 하나
- 다양한 프레임워크에 이미 적용되어 있는 기능
- 객체 간의 의존 관계를 외부의 조립기가 관리
- 불필요한 의존 관계를 없애거나 줄일 수 있음
- 단위테스트 수행 수월
- 설정파일과 애노테이션을 이용하여 객체 간의 의존 관계를 설정
- 각 객체를 빈(bean)으로 관리
3. Node ? 노드는 네트워크 내의 교차점 / 연결지점을 의미. 모든 장치가 네트워크를 통해 액세
스 할 수 있는 환경의 장치는 모두 노드로 간주.(서버, 클라이언트 -> 컴퓨터 / 라우터. CDN에
서는 컨텐츠를 가진 서버라고 생각하자)
Content ? 텍스트, 응용 플로그램, 이미지, 전자메일, 데이터, 서비스, 오디오 및 비디오 등과
같은 모든 창의적인 요소를 의미.
What is a CDN ?
CDN = Content Delivery Network
Content Distribution Network
- CDN은 원본 서버에서 가져온 데이터(Resource)복사본이 있는 대규모 서버
네트워크를 의미.
- CDN은 contents를 효율적으로 전달하기 위해, Node를 가진 네트워크에 데
이터를 저장하여 제공하는 시스템을 의미.
4. 대기시간(Network 지연시간, Latency)을 줄이기 위해서, CDN
이 만들어 졌습니다.
CDN은 contents를 수신하려는 사용자(client)와 패킷 또는 청
크를 보내는 서버간의 물리적 거리를 줄이기 위해 사용 합니
다.
패킷(packet)? 패킷은 주어진 네트워크 경로를 따라 이동하는 단일 패키지로 만들어진 데이터 단위.
청크(chunk)? SCTP(Stream Control Transmission Protocol)에서 사용되는 제어 데이터 및 패킷 세트.
홉(hop)? 각 패킷이 매 노드를 건너가는 양상을 비유적으로 표현 -> 이러한 체계를 hop-by-hop 체제라고
말함. 홉은 라우팅에서 사용되는 용어로서 하나의 데이터 링크를 가르킨다. 네트워크 내에서 출발지부
터 목적지에 이르는 경로는 일련의 홉들로 연결된다. 홉은 패킷이 통과해야만 하는 라우터의 숫자를 측
정하는데 자주 사용.(실제로 거리보다는, 라우터가 개입될때마다 느려짐. 이유는? Store and Forward이
기 때문이다. -> 패킷을 버퍼에 저장 후, 헤더를 보고 갈 길을 찾은 뒤 보내는거라, 빛의 속도로 전송되는
케이블과는 비교할 수 없을 정도로 느림.
Why use CDN ?
5. 클라이언트와 웹 서버 사이의 거리를 최소화 하기
위해 CDN은 캐시된 버전의 contents를 여러 지
리적 위치에 저장.(points of presence, or PoP)
본질적으로, CDN은 한번에 여러 위치에 contents
를 배치하여, 클라이언트에게 더 나은 적용 범위
를 제공.
CDN’s Process ?
6. CDN PoP(Points of Presence) ?
지리적으로 가까운 지역의 클라이언트와 의사소
통을 담당하는 전략적으로 위치한 데이터 센터.
주요 기능은, contents를 웹 사이트 방문자에게
더 가까이 가져와서 왕복시간(Round-trip
latency)를 줄이는 것 입니다. 각, CDN PoP에는
일반적으로 수많은 캐싱 서버가 포함되어있다.
각, PoP에 위치한 서버를 ‘edge server’라고 한다.
Edge server = proxy cache server이며, 웹 사이트
의 contents를 생성하지 않으며, 대신 contents
사본을 보관.
CDN’s Process ?
7. - CDN은 서버의 대역폭을 절약하고, 과도한 사용자 트래픽,
서버 중단 또는 기타 유사한 이벤트가 발생하더라도 최종 사
용자가 contents에 access 할 수 있도록 함으로써 웹 사이트의
가용성을 향상.
What are the benefits
of using a CDN ?
8. Here is an example of just some of the file types that can be hosted on a CDN:
- Images: PNG, JPG, SVG, GIF, TIF
- Stylesheets: CSS
- JavaScript: JS
- Video and Audio: FLV (Flash), HLS, MP4 (HTML5 videos), MOV (QuickTime), WMV
(Windows Media), MP3 and WAV
- Web Fonts: EOT, TTF, OTF, CFF, AFM, LWFN, FFIL, FON, PFM, PFB, WOFF, SVG, STD, PRO,
XSF, and more…
- Other File Formats: HTML, JSON, PDF, DOC, PPT, XLS, EPUB, ODT, ODP, ODS, TXT, RTF,
ZIP
What type of content Is
Stored on a CDN ?
9. How to refresh cache
server on a CDN
- 캐시 서버가 오리진 서버의 콘텐츠를 캐싱하고 이용자들에게 캐싱된 콘텐
츠를 전달하는 과정에서 만약 오리진 서버에 저장되어 있는 콘텐츠가 업데
이트되면 이용자들이 캐시 서버로 부터 다운로드 받는 콘텐츠는 더 이상 유
효한 콘텐츠가 아니게 됩니다. 이러면 어떤 문제가 발생을 하느냐? 만약 해
당 콘텐츠가 CSS나 이미지 파일이라면 웹 페이지 화면이 깨져 보이게 되겠
죠. 따라서 캐시 서버는 오리진 서버를 통해 캐싱된 콘텐츠에 대한 유효성
(freshness)를 주기적으로 확인(validation)하고, 만약 콘텐츠가 업데이트되
었으면 다시 다운로드 받아 캐싱을 해야 합니다.
10. How to refresh cache
server on a CDN
1. 이용자 웹 브라우저가 HTTP GET 메시지를 통해 캐시 서버로 다음과 같이 image.jpg 파일 요청을 합니다. (이용자의 요청이 오리진 서버가 아닌 캐시 서버로 가는 절차는 Request Routing 글을
참조)
Host: www.example.com
Request URI: /image.jpg
2. 웹 브라우저가 최초로 콘텐츠를 요청했으므로 캐시 서버에 해당 파일이 없습니다(Cache Miss).
3. 따라서 캐시 서버는 오리진 서버에게 HTTP GET 메시지를 통해 image.jpg 파일을 요청합니다.
4.오리진 서버는 HTTP 200 OK 메시지를 통해 image.jpg 파일과 해당 콘텐츠의 메타 태그 정보를 캐싱 서버로 전달합니다. 메타 태그에는 아래와 같이 캐싱과 관련된 정보가 포함되어 있습니다.
Last-Modified: Mon, 1 Oct 2012 09:00:00 - 오리진 서버에 저장되어 있는 image.jpg 파일은 2012년 10월 1일 오전 9시 정각에 업데이트 되었음 (이 정보는 뒤에 14번 cache validation에서 사용
됨)
Cache-Control: max-age=100 - image.jpg 파일의 캐싱 유효시간은 100초임. "100초 동안만 캐싱하고, 그 이후에는 다시 오리진 서버로 콘텐츠 요청 혹은 freshness 확인을 해라"라는 의미
5.캐시 서버는 t = 0 시각에 HTTP 200 OK 메시지를 통해 image.jpg 파일을 수신합니다. 그리고 수신한 image.jpg 파일을 캐싱(저장)하고(Cache Fill), 이 콘텐츠의 캐싱 유효시간 100초를 Cache
Control Table에 기록합니다. 이제 캐시 서버는 앞으로 100초 동안은 이용자들의 image.jpg 파일 요청에 대해서 자신이 캐싱한 파일을 전달해 줄 수 있습니다. 그리고 그림에는 표시되지 않았으
나 Last-Modified 필드에 명시된 콘텐츠 업데이트 시각(Mon, 1 Oct 2012 09:00:00)도 함께 저장합니다.
6.캐시 서버는 오리진 서버로 부터 수신한 컨텐츠를 웹 브라우저에게 전달합니다. 이 때 max-age는 오리진 서버가 명시한 값 100초를 그대로 전달합니다. 웹 브라우저는 image.jpg 파일을 100
초 동안 캐싱하며, 따라서 이 시간 동안은 캐싱된 콘텐츠에 대한 재요청을 하지 않습니다.
11. How to refresh cache
server on a CDN
7.이제 다른 이용자 James(웹 브라우저)가 40초 후(t = 40 시각)에 동일 콘텐츠 image.jpg를 동일 캐시 서버로 요청합니다.
8.캐시 서버에는 image.jpg 파일이 캐싱되어 있으며 아직 캐싱 만료 시간까지는 60초(100초 - 40초)가 남아 있습니다.
9.따라서 캐시 서버는 오리진 서버를 대신하여 James(웹 브라우저)에게 image.jpg 파일을 전달합니다. 이 때의 max-age는 캐시 서버에서 관리하는 캐싱 만료 시간 60초가 됩니다. 따라서
James(웹 브라우저)는 image.jpg 파일을 60초 동안 캐싱합니다.
12. How to refresh cache
server on a CDN
10.이용자 Alice(웹 브라우저)가 90초 후(t = 90 시각)에 동일 콘텐츠 image.jpg를 동일 캐시 서버로 요청합니다.
11.여전히 캐시 서버는 캐싱 만료 시간이 되지 않았으므로(10초 남음)
12.Alice(웹 브라우저)에게 max-age를 10초로 하여 image.jpg 파일을 전달합니다.
13.캐시 서버는 (구현에 따라 다르지만) 콘텐츠 캐싱 유효시간의 80%가 지난 후(100초의 80%인 80초가 지난 후) 이용자로 부터 해당 콘텐츠 요청이 오면 일단 이용자에게 캐싱된 콘텐츠
전달 후, 캐싱된 콘텐츠의 변경 여부(freshness)를 확인하기 위해 validation 작업을 수행합니다.
14.이를 위해 캐시 서버는 HTTP GET 메시지에 If-Modified-Since 필드를 삽입하여 오리진 서버로 전달합니다. 이 필드에 들어가는 시각은 앞서 4번에서 받은 image.jpg 파일의 업데이트 시
각입니다. 오리진 서버는 이 시각과 자신이 저장하고 있는 image.jpg 파일의 시각을 비교하여,
만약 시각이 다르면(오리진 서버에 image.jpg 파일이 업데이트 된 경우) HTTP 200 OK 메시지를 통해 업데이트된 image.jpg를 캐시 서버로 전달해 주고,
시각이 같다면(업테이트 되지 않았다면) HTTP 304 Not Modified 메시지로 응답을 합니다. 이 메시지에는 image.jpg 콘텐츠가 포함되어 있지 않습니다. 즉, "콘텐츠가 업데이트 되지
않았으니 네(캐시 서버)가 가지고 있는거 써라"는 의미입니다.
15.오리진 서버로부터 HTTP 304 Not Modified 메시지를 수신한 캐시 서버는 해당 메시지에 명시된 max-age=100으로 image.jpg의 캐싱 유효시간을 리셋합니다. 즉, 다시 Cache Control
Table의 값을 100초로 설정합니다.
13. How to refresh cache
server on a CDN
정리
- 캐시 서버는 오리진 서버에서 다운로드 받아 캐싱하는 각 콘텐츠에 대해 캐싱 유효시간(max-age)을 관
리.
- 이용자에게는 캐시 서버에서 관리하는 캐싱 유효시간(max-age)을 전달.
- 캐시 서버는 캐싱 유효시간(max-age)이 만료되기 전에 미리 오리진 서버를 통해 validation을 수행.
-Validation은 HTTP GET 메시지 헤더에 If-Modified-Since 필드를 이용하여 수행하며, 오리진 서버는 해당
콘테츠가 업데이트되었으면 HTTP 200 OK 메시지를 통해 업데이트된 콘텐츠를 전달하고 그렇지 않은 경
우 HTTP 304 Not Modified 메시지로 응답.
참고 링크 : http://www.netmanias.com/ko/post/blog/5654/cdn-http/http-cache-control-expiration-and-
validation