STON Edge Server - Sketch¶

저자:	STON 개발팀

Spec¶

원본 멀티세션 다운로드¶

이 기능은 원본서버 - Range요청 의 확장으로 동작한다. 이유는 다음과 같다.

원본에서 한 세션이 다운로드 받는 크기를 제한(설정)한다.

다운로드 시점에 서로 다른 Range로 여러 세션을 생성한다.

멀티세션 다운로드¶

다운로드 크기와 동시 다운로드 세션 수를 설정한다.

# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>

<PartSize Session="0" Continue="On">0</PartSize>

<PartSize> (단위: MB) 만큼 다운로드 받는 세션을 Session (단위: 개) 수 만큼 만들어서 다운로드를 진행한다. Continue (기본: ON) 설정이 ON 이면 다운로드가 멈추지 않고 진행된다. OFF 인 경우 1회만 다운로드를 진행하고 멈춘다.

예를 들어 1MB씩 15개의 세션으로 완전한 다운로드를 진행하려면 다음과 같이 설정한다.

<PartSize Session="15">1</PartSize>

반면 아래의 경우 결과적으로 15MB만 다운로드가 진행된다.

<PartSize Session="15" Continue="Off">1</PartSize>

Note

디스크 공간 절약등의 목적이 아닌 경우 Continue 설정은 항상 ON (기본값) 으로 유지해야 속도 향상을 기대할 수 있다.

ㅁ.. _sync:

Sync¶

API를 이용한 Purge는 직관적으로 간편하다는 장점이 있는 반면 서비스 규모가 커지면서 다소 한계점이 있다.

대상 서버가 많아지면 일일이 API를 호출하기 번거롭다.
점검등의 이유로 일시적으로 서버가 배제된 경우 해당 시간동안의 Purge가 누락된다.
(클라우드 Auto-Scale 처럼) 서버 인스턴스가 지속적으로 변동되는 환경일 경우 대상 서버 리스트를 만들기 까다롭다.

Sync는 Publish-Subscribe 모델을 통해 복수의 STON을 동일하게 관리할 수 있는 기법이다.

이 모델은 관리자가 URL로 게시(Publish)하고, 각 서버들이 이를 수신(Subscribe)하여 반영하는 구조이다. 각각의 서버가 능동적으로 목록을 수신하기 때문에 서비스 규모가 커지면서 발생하는 대상 지정의 어려움이 근본적으로 사라진다.

Note

Sync는 목적에 의해 설정 동기화, 캐싱 동기화(Pre-Caching), Purge 동기화로 분류할 수 있다. 본 Prototype에서는 Purge 동기화만을 대상으로 한정한다.

설정¶

Purge목록을 수신(Subscribe)할 수 있는 URL을 설정한다.

$ server.xml - <Server>

<Sync>
   <Purge Status="Inactive" Timeout="5" Cycle="3">http://example.com/purge.html</Purge>
</Sync>

<Purge>

Purge목록의 게시 URL을 설정한다. Status="Active" 일 때 활성화된다.
- Timeout (기본: 5초) 소켓연결부터 HTTP Transaction이 완료될 때까지 유효시간
- Cycle (기본: 3초) 게시 URL 접근주기

설정된 서버는 게시 URL을 Cycle 초 마다 Polling한다.

게시 파일형식¶

Purge 목록 게시 서버가 제공해야 하는 파일은 아래와 같이 XML 형식이다.

<STON>
   <Meta>
      <Method>Purge</Method>
   </Meta>
   <Body>
      <Item><![CDATA[example.com/logo.jpg]]></Item>
      <Item><![CDATA[example.com/script/myscript.js]]></Item>
      <Item><![CDATA[foo.com/*.js]]></Item>
      <Item><![CDATA[foo.com/dummy/]]></Item>
      <Item><![CDATA[http://bar.com/private.html?id=*]]></Item>
   </Body>
<STON>

<Method> (기본: Purge) 수행할 무효화 명령을 선택한다. Purge , HardPurge , Expire 중 선택한다.
<Item> 무효화할 대상을 지정하며 특수문자를 고려하여 CDATA로 표현한다. 명시적인 주소(URL), 패턴, 디렉토리 표현이 가능하다. 가상호스트 이름이 포함되어야 하며 프로토콜(http://)은 생략 가능하다.

Content-Type이나 확장자는 별도로 체크하지 않는다.

변경감지¶

변경목록을 매번 반영할 경우 지나친 중복 처리가 부담되기 때문에 Last-Modified 헤더를 통해 이 문제를 해결한다.

게시 URL이 example.com/purge.html 라면 STON이 보내는 최초 요청은 다음과 같다.

GET /purge.html HTTP/1.1
Host: example.com

서버는 Lats-Modified 헤더를 반드시 명시해야 한다.

HTTP/1.1 200 OK
Server: Apache/1.3.27
Content-Length: 288
Last-Modified: Mon, 24 Jul 2017 01:09:43 GMT

... Body ...

STON은 마지막 Last-Modified 헤더 값을 기억하며 다음과 같이 If-Modified-Since 헤더를 이용해 내용이 변경되었을 때만 서버가 200 OK로 응답하길 기대한다.

GET /purge.html HTTP/1.1
Host: example.com
If-Modified-Since: Mon, 24 Jul 2017 01:09:43 GMT

변경이 있을 경우 200 OK로 응답하며 Last-Modified 시간이 갱신된다. 변경이 없는 경우 다음처럼 304 Not Modified 로 응답해야 하여 변경없음을 알린다.

HTTP/1.1 304 Not Modified
Server: Apache/1.3.27

주의사항¶

게시(Publish)서버는 Last-Modified 값을 통해 최적화된 변경목록을 게시할 수 있다.

아래와 같이 변경되는 파일에 대한 이력을 별도로 저장소(i.e. Database)에 기록하고 이를 동적 페이지로 게시하는 경우의 예를 들어보자.

변경항목들이 있다면 동적 페이지에서는 다음과 같이 Last-Modified 헤더를 명시적으로 설정해 주어야 한다.

<?php
  header("Last-Modified: Mon, 24 Jul 2017 01:09:43 GMT");
?>

<STON>
...
</STON>

이 때 Last-Modified 설정과 관련하여 현재 시간 1초동안 미묘한 시점이 발생한다. 다음과 같이 3개의 URL에 대해 변경이 1초 안에 발생했다고 예를 들어보자.

example.com/a.jpg       // 01:09:43 기록
example.com/b.jpg       // 01:09:43 기록
example.com/c.jpg       // 01:09:43 기록

이때 이 목록에 접근하면 게시서버는 다음과 응답한다.

HTTP/1.1 200 OK
Server: Apache/1.3.27
Content-Length: 153
Last-Modified: Mon, 24 Jul 2017 01:09:43 GMT

<STON>
   <Body>
      <Item><![CDATA[example.com/a.jpg]]></Item>
      <Item><![CDATA[example.com/b.jpg]]></Item>
      <Item><![CDATA[example.com/c.jpg]]></Item>
   </Body>
<STON>

STON이 기억하는 Last-Modified 은 Mon, 24 Jul 2017 01:09:43 GMT 이다.

이 때 서버에서 아래와 같이 3개의 URL(d.jpg ~ f.jpg)이 변경되었다.

example.com/a.jpg       // 01:09:43 기록
example.com/b.jpg       // 01:09:43 기록
example.com/c.jpg       // 01:09:43 기록
example.com/d.jpg       // 01:09:43 기록
example.com/e.jpg       // 01:09:43 기록
example.com/f.jpg       // 01:09:44 기록

STON이 다시 목록에 접근할 다음과 같이 If-Modified-Since 헤더를 붙여서 요청한다.

GET /purge.html HTTP/1.1
If-Modified-Since: Mon, 24 Jul 2017 01:09:43 GMT

이 경우 동적 페이지에서 아마도 다음 2가지 조건으로 저장소로부터 변경목록을 수집할 가능성이 높다.

Mon, 24 Jul 2017 01:09:43 GMT  <  변경항목
   -> example.com/f.jpg 만 대상이 된다. (d.jpg, e.jpg 누락)

Mon, 24 Jul 2017 01:09:43 GMT  <=  변경항목
   -> 모두가 대상이 된다. (a~c.jpg 중복)

이상의 문제로 인해 초 단위의 현재시간은 목록에서 배제해야 올바른 구현이 가능하다.

If-Modified-Since  <  변경항목  <  현재시간

기타¶

게시서버에서 변경목록을 무한히 가지고 있을 수 없다. 가령 서버가 1주일 동안의 변경목록만을 제공할 수 있다면 STON에 캐싱된 1주일 이전 데이터는 유효하다고 볼 수 없다. 이 경우 다음 설정을 통해 STON이 구동될 때 일정시간 이전의 데이터는 로딩하지 않도록 설정할 수 있다.

# server.xml - <Server>

<Cache>
   <Freshness>0</Freshness>
</Cache>

<Freshness> (단위: 일) 0보다 큰 경우, STON이 구동될 때 현재 시간으로부터 설정된 날(days) 이전에 캐싱된 콘텐츠는 삭제하고 로딩한다.

API¶

API 목록 레퍼런스. 모든 API는 다음과 같이 호출한다.

http://{ston-ip}:10040/{API}

Meta¶

/help
/ver
/version

설정¶

관리¶

/conf/reload
/conf/reloadserver
/conf/reloadvhosts
/conf/export
/conf/import
/conf/download
/conf/latest
/conf/history
/conf/restore

열람¶

/conf/server.xml
/conf/vhosts.xml
/conf/bypass.txt
/conf/ttl.txt
/conf/expires.txt
/conf/acl.txt
/conf/headers.txt
/conf/querystring.txt
/conf/throttling.txt
/conf/postbody.txt
/conf/compression.txt

명령어¶

서버운영¶

/command/restart
/command/terminate
/command/cacheclear
/command/unmount
/command/umount
/command/mount

캐싱객체 관리¶

/command/hardpurge
/command/purge
/command/expire
/command/expireafter

기타¶

/command/resetorigin
/command/cleanup
/command/update
/command/convertregexp
/command/encryptpassword

모니터링¶

통계¶

/monitoring/average.xml
/monitoring/average.json
/monitoring/realtime.xml
/monitoring/realtime.json
/monitoring/fileinfo.json
/monitoring/hwinfo.json
/monitoring/cpuinfo.json
/monitoring/vhostslist.json
/monitoring/geoiplist.json
/monitoring/ssl.json
/monitoring/cacheresource.json
/monitoring/origin.json
/monitoring/clusterlist

로그¶

/monitoring/logtrace/info
/monitoring/logtrace/deny
/monitoring/logtrace/sys
/monitoring/logtrace/access
/monitoring/logtrace/origin
/monitoring/logtrace/monitoring
/monitoring/logtrace/originerror

전역 그래프¶

/graph/cpu_day.png
/graph/cpu_week.png
/graph/cpu_month.png
/graph/cpu_year.png
/graph/cpu_dash.png
/graph/stoncpu_day.png
/graph/stoncpu_week.png
/graph/stoncpu_month.png
/graph/stoncpu_year.png
/graph/stoncpu_dash.png
/graph/mem_day.png
/graph/mem_week.png
/graph/mem_month.png
/graph/mem_year.png
/graph/mem_dash.png
/graph/ssockevent_day.png
/graph/ssockevent_week.png
/graph/ssockevent_month.png
/graph/ssockevent_year.png
/graph/ssockevent_dash.png
/graph/ssockusage_day.png
/graph/ssockusage_week.png
/graph/ssockusage_month.png
/graph/ssockusage_year.png
/graph/ssockusage_dash.png
/graph/csockevent_day.png
/graph/csockevent_week.png
/graph/csockevent_month.png
/graph/csockevent_year.png
/graph/csockevent_dash.png
/graph/csockusage_day.png
/graph/csockusage_week.png
/graph/csockusage_month.png
/graph/csockusage_year.png
/graph/csockusage_dash.png
/graph/eq_day.png
/graph/eq_week.png
/graph/eq_month.png
/graph/eq_year.png
/graph/eq_dash.png
/graph/wf2w_day.png
/graph/wf2w_week.png
/graph/wf2w_month.png
/graph/wf2w_year.png
/graph/wf2w_dash.png
/graph/loadavg_day.png
/graph/loadavg_week.png
/graph/loadavg_month.png
/graph/loadavg_year.png
/graph/loadavg_dash.png
/graph/acldenied_day.png
/graph/acldenied_week.png
/graph/acldenied_month.png
/graph/acldenied_year.png
/graph/acldenied_dash.png
/graph/iowait_day.png
/graph/iowait_week.png
/graph/iowait_month.png
/graph/iowait_year.png
/graph/iowait_dash.png
/graph/tcpsocket_day.png
/graph/tcpsocket_week.png
/graph/tcpsocket_month.png
/graph/tcpsocket_year.png
/graph/tcpsocket_dash.png
/graph/urlrewrite_day.png
/graph/urlrewrite_week.png
/graph/urlrewrite_month.png
/graph/urlrewrite_year.png
/graph/urlrewrite_dash.png

가상호스트 그래프¶

/graph/vhost/mem_day.png
/graph/vhost/mem_week.png
/graph/vhost/mem_month.png
/graph/vhost/mem_year.png
/graph/vhost/mem_dash.png
/graph/vhost/wf2d_day.png
/graph/vhost/wf2d_week.png
/graph/vhost/wf2d_month.png
/graph/vhost/wf2d_year.png
/graph/vhost/wf2d_dash.png
/graph/vhost/client_httpreq_bypass_day.png
/graph/vhost/client_httpreq_bypass_week.png
/graph/vhost/client_httpreq_bypass_month.png
/graph/vhost/client_httpreq_bypass_year.png
/graph/vhost/client_httpreq_bypass_dash.png
/graph/vhost/client_httpreq_denied_day.png
/graph/vhost/client_httpreq_denied_week.png
/graph/vhost/client_httpreq_denied_month.png
/graph/vhost/client_httpreq_denied_year.png
/graph/vhost/client_httpreq_denied_dash.png
/graph/vhost/origin_http_session_day.png
/graph/vhost/origin_http_session_week.png
/graph/vhost/origin_http_session_month.png
/graph/vhost/origin_http_session_year.png
/graph/vhost/origin_http_session_dash.png
/graph/vhost/origin_traffic_day.png
/graph/vhost/origin_traffic_week.png
/graph/vhost/origin_traffic_month.png
/graph/vhost/origin_traffic_year.png
/graph/vhost/origin_traffic_dash.png
/graph/vhost/origin_http_res_day.png
/graph/vhost/origin_http_res_week.png
/graph/vhost/origin_http_res_month.png
/graph/vhost/origin_http_res_year.png
/graph/vhost/origin_http_res_dash.png
/graph/vhost/origin_http_res_complete_day.png
/graph/vhost/origin_http_res_complete_week.png
/graph/vhost/origin_http_res_complete_month.png
/graph/vhost/origin_http_res_complete_year.png
/graph/vhost/origin_http_res_complete_dash.png
/graph/vhost/origin_http_res_detail_day.png
/graph/vhost/origin_http_res_detail_week.png
/graph/vhost/origin_http_res_detail_month.png
/graph/vhost/origin_http_res_detail_year.png
/graph/vhost/origin_http_res_detail_dash.png
/graph/vhost/origin_http_res_time1_day.png
/graph/vhost/origin_http_res_time1_week.png
/graph/vhost/origin_http_res_time1_month.png
/graph/vhost/origin_http_res_time1_year.png
/graph/vhost/origin_http_res_time1_dash.png
/graph/vhost/origin_http_res_time2_day.png
/graph/vhost/origin_http_res_time2_week.png
/graph/vhost/origin_http_res_time2_month.png
/graph/vhost/origin_http_res_time2_year.png
/graph/vhost/origin_http_res_time2_dash.png
/graph/vhost/client_http_session_day.png
/graph/vhost/client_http_session_week.png
/graph/vhost/client_http_session_month.png
/graph/vhost/client_http_session_year.png
/graph/vhost/client_http_session_dash.png
/graph/vhost/client_traffic_day.png
/graph/vhost/client_traffic_week.png
/graph/vhost/client_traffic_month.png
/graph/vhost/client_traffic_year.png
/graph/vhost/client_traffic_dash.png
/graph/vhost/client_http_res_day.png
/graph/vhost/client_http_res_week.png
/graph/vhost/client_http_res_month.png
/graph/vhost/client_http_res_year.png
/graph/vhost/client_http_res_dash.png
/graph/vhost/client_http_res_complete_day.png
/graph/vhost/client_http_res_complete_week.png
/graph/vhost/client_http_res_complete_month.png
/graph/vhost/client_http_res_complete_year.png
/graph/vhost/client_http_res_complete_dash.png
/graph/vhost/client_http_res_detail_day.png
/graph/vhost/client_http_res_detail_week.png
/graph/vhost/client_http_res_detail_month.png
/graph/vhost/client_http_res_detail_year.png
/graph/vhost/client_http_res_detail_dash.png
/graph/vhost/client_http_res_time1_day.png
/graph/vhost/client_http_res_time1_week.png
/graph/vhost/client_http_res_time1_month.png
/graph/vhost/client_http_res_time1_year.png
/graph/vhost/client_http_res_time1_dash.png
/graph/vhost/client_http_res_time2_day.png
/graph/vhost/client_http_res_time2_week.png
/graph/vhost/client_http_res_time2_month.png
/graph/vhost/client_http_res_time2_year.png
/graph/vhost/client_http_res_time2_dash.png
/graph/vhost/client_http_res_hit_day.png
/graph/vhost/client_http_res_hit_week.png
/graph/vhost/client_http_res_hit_month.png
/graph/vhost/client_http_res_hit_year.png
/graph/vhost/client_http_res_hit_dash.png
/graph/vhost/client_traffic_ssl_day.png
/graph/vhost/client_traffic_ssl_week.png
/graph/vhost/client_traffic_ssl_month.png
/graph/vhost/client_traffic_ssl_year.png
/graph/vhost/client_traffic_ssl_dash.png
/graph/vhost/hitratio_day.png
/graph/vhost/hitratio_week.png
/graph/vhost/hitratio_month.png
/graph/vhost/hitratio_year.png
/graph/vhost/hitratio_dash.png
/graph/vhost/filecount_day.png
/graph/vhost/filecount_week.png
/graph/vhost/filecount_month.png
/graph/vhost/filecount_year.png
/graph/vhost/filecount_dash.png

STON.js¶

JavaScript로 STON을 운영한다.

HTTPS¶

Secondary 인증서¶

ECDSA로 서명된 인증서는 RSA로 서명된 인증서에 비해 성능상의 이점을 가진다. SSL.com 의 Comparing ECDSA vs RSA 에 따르면 112 bit레벨의 암호화에서 RSA는 2048 bit의 키가 필요한 반면 ECDSA는 224 bit 키만으로도 충분한다. 128bit 레벨의 암호화에선 RSA의 상황이 더 나빠지는데, RSA는 3072 bit, ECDSA는 256 bit가 필요하다.

아래 Cloudflare - ECDSA: The digital signature algorithm of a better internet 의 결과가 말해주듯 지속적으로 보안레벨이 높아지는 상황에서 RSA는 효율적이지 못한 옵션이 된다.

                            sign/s
256 bit ecdsa (nistp256)    9516.8
rsa 2048 bits               1001.8

(openssl 1.0.2 beta on x86_64 with enable-ec_nistp_64_gcc_128)

Note

AWS CloudFront도 2018년부터 ECDSA를 통한 원본서버 연결 을 지원한다.

ECDSA 인증서 도입의 가장 큰 걸림돌은 클라이언트의 Cipher Suite 지원 여부이다. ECDSA는 TLS 1.2부터 표준이 되었기 때문에 이를 미지원하는 클라이언트라면 HTTPS 세션 연결이 불가능하다.

이를 해결하기 위해 한 주체(Subject)에 대해 다음과 같이 Secondary 인증서를 구성할 수 있다.

<Https>
   <Cert>/usr/ssl/cert_ecdsa.pem | /usr/ssl/cert_rsa.pem</Cert>
   <Key>/usr/ssl/certkey_ecdsa.pem | /usr/ssl/certkey_rsa.pem</Key>
   <CA>/usr/ssl/ca_ecdsa.pem | /usr/ssl/ca_rsa.pem</CA>
</Https>

각 인증서 세트는 파이프(“|”)로 구분하며 동작 시나리오는 다음과 같다.

서멍된 알고리즘(ECDSA)를 지원하는 클라이언트라면 Primary 인증서(cert_ecdsa.pem)를 제공한다.

지원하지 않는다면 Secondary 인증서(cert_rsa.pem)를 제공한다.

인증서는 최대 2세트만 지원이 가능하다.

Note

RSA가 더 높은 호환성을 가지기 때문에 RSA인증서를 Primary에 배치한다면 ECDSA 인증서는 서비스되지 않을 것이다.

동영상¶

시청자수 집계¶

라이브 방송처럼 시청자수가 서비스의 핵심지표라면, 동시접속자를 시청자수와 같은 의미로 사용하는 것은 다소 문제의 소지가 있다.

Note

만일 RTSP같은 스트리밍 프로토콜을 사용한다면 같은 의미로 볼 수 있다. 하지만 HLS등 HTTP기반 프로토콜이 폭넓은 호환성을 바탕으로 라이브 서비스에서도 널리 적용되고 있다. 문제는 HTTP가 파일기반으로 설계되었고, 심지어 무상태(Stateless)로 동작하는 것에 기인한다.

1명의 시청자가 10초로 분할된 HLS 영상을 1분간 시청했다고 가정해 보자. 관점에 따라 시청자수는 전혀 다르게 계산될 수 있다.

0.016 - 모든 TS파일을 다운로드 받는데 1초가 소요되어 “1초(트래픽 발생 시간) / 60초(시청시간)” 으로 계산한다.
5 - 브라우저가 서버로 동시에 맺는 HTTP 세션 수는 5이다.
6 - 다운로드된 TS파일의 개수는 6개이다.

모든 수치가 엉뚱하다. 이런 문제가 발생하는 근본적인 원인은 시청자수를 네트워크 관점만으로 계산했기 때문이다.

결론적으로 시청자수는 연결된 세션수나 다운로드 속도와 상관없이 전송된 시간의 총합으로 계산되어야 한다.

         전송된 재생시간의 합
--------------------------------------
             단위 시간

예를 들어 축구경기 라이브 방송을 2시간 진행했다. 전송된 동영상 전체의 재생시간이 20만 시간이라면 평균 시청자수는 10만명이라고 볼 수 있다. 이는 매우 휴리스틱(Heuristic)한 접근이지만 꽤 효율적이다.

시청자수 집계 기능은 전송된 재생시간을 실시간으로 반영하여 시청자수를 제공한다.

# server.xml - <Server><VHostDefault><Media>
# vhosts.xml - <Vhosts><Vhost><Media>

<Viewer Status="Inactive">
   <Group Name="sports" Time="2">
      <Pattern>/baseball/*.ts</Pattern>
      <Pattern Time="1">/soccer/*.ts</Pattern>
      <Pattern>/baseketball/*.ts</Pattern>
   </Group>
   <Group Name="shopping" Time="5">
      <Pattern>/shop/beauty</Pattern>
   </Group>
</Viewer>

<Viewer> 시청자수 집계의 최상위 설정. 여러 <Group> 을 하위 설정으로 가진다.
- Status (기본: Inactive) 시청자수 집계 활성화 ( Active 또는 Inactive )

<Group> 시청자수 제공 단위. 여러 <Pattern> 을 하나의 단위로 집계 할 수 있다.

Name 통계(시청자수)를 구분하는 고유한 이름

Time (기본: 2초, 범위: 1~60) 기본 재생시간. 값이 60을 넘을 경우 60으로 수렴한다.

<Pattern> 입력 패턴과 일치하는 URL요청이 200 OK 응답으로 완전히 전송(=HTTP 트랜잭션 완료)되었을 때 재생시간을 집계한다. Time 속성을 설정하면 상위 설정인 <Group> 의 Time 속성을 사용하지 않는다.

Note

<Pattern> 의 값은 성능상의 이유로 정규표현식을 지원하지 않는다. 와일드카드(*)만 지원된다.

Warning

스펙이 확정되는 시점에 API, SNMP 통계형태를 결정한다.

4장. Caching 정책¶

TTL (Time To Live)¶

Custom TTL¶

TTL 만료시간 지정¶

Custom TTL 을 확장하여 TTL 만료시간을 지정할 수 있다.

# /svc/www.example.com/ttl.txt
# {Match}, {TTL}, {minute hour} 순서로 표기한다.

# 자정(00시 00분)에 TTL을 만료한다.
/events/*, 86400, 0 0

# 22시 38분에 TTL을 만료한다.
/foo/bar, 86400, 38 22

# 매 시간마다 TTL을 만료한다.
/index.html, 86400, 0 *

# 5분마다 TTL을 만료한다.
/script/*.js, 86400, */5 *

# 매 6시간마다 TTL을 만료한다.
/image/ad.jpg, 86400, 0 */6

예제의 {TTL} 값이 86400인 이유는 TTL을 설정할 때 {TTL} 과 {minute hour} 중 작은 값을 선택하기 때문이다.

/api/v1/*, 30
/api/v2/*, 30, * *

예를 들어 위 설정의 경우 요청(=캐싱)시간을 기준으로 만료시간이 작은 값을 기준으로 설정된다.

패턴	요청시간	만료시간
/api/v1/*	1:15:10	1:15:40
/api/v1/*	1:15:40	1:16:10
/api/v2/*	1:15:10	1:15:40
/api/v2/*	1:15:40	1:16:00

Note

설정을 변경해도 이미 캐싱된 객체의 TTL이 변경되지는 않는다. TTL은 객체가 초기화(=캐싱) 되는 시점에 고정되기 때문이다.