キャッシュストレージ

Traffic Server のキャッシュは URL と関連するヘッダーにより キャッシュオブジェクト をインデックスする オブジェクトストア と呼ばれる高速なオブジェクトデータベースで構成されています。

The Traffic Server Cache

Traffic Server のキャッシュは URL と関連するヘッダーにより キャッシュオブジェクト をインデックスする オブジェクトストア と呼ばれる高速なオブジェクトデータベースで構成されています。これは Traffic Server が Web ページだけでなく最適な帯域の節約をする部分的な Web ページも格納、取得、提供を可能とします。洗練されたオブジェクト管理により、オブジェクトストアは同じオブジェクトの 代替 バージョン ( バージョンは異なる言語やエンコーディングにより異なります ) をキャッシュできます。またとても小さいオブジェクトもとても大きいドキュメントも効率よく格納できるので、無駄な領域を最小限にできます。キャッシュがいっぱいのとき、 Traffic Server は一番リクエストされたオブジェクトが容易に利用可能で新鮮な状態であることを維持するために 新鮮でない データを削除します。

Traffic Server はキャッシュディスクのあらゆるディスク障害に耐性を持つよう設計されています。ディスクが完全に故障した場合、Traffic Server はディスク全体を壊れていると印付けし、残りのディスクを使用し続けます。そしてディスク故障を示すアラームが作成されます。すべてのディスクが故障すると、Traffic Server はプロキシー限定モードに入ります。

次のキャッシュ設定作業を行うことができます。

  • キャッシュに割り当てられたディスク領域の総量を変更する。 キャッシュキャパシティの変更 を参照。

  • 特定のプロトコルと オリジンサーバー/ドメイン 用にキャッシュディスクの領域を予約してキャッシュを区分けする。 キャッシュの区分け を参照。

  • キャッシュ内のすべてのデータを削除する。 キャッシュのクリア を参照。

  • 時間、ポート、リクエストのメソッド ( など ) に対する追加のフィルターによるリクエストされたドメイン名、URL の正規表現、ホスト名または IP に対するキャッシュディレクティブの上書き。 ATS は、キャッシュしないようにも、常にキャッシュするようにも、 no-cache ディレクティブを無視するようにも、他にもいろいろと設定できます。これらは cache.config で設定されます。

The RAM Cache

Traffic Server はとてもよく使用されるオブジェクトの小さな RAM キャッシュを維持します。RAM キャッシュは、特に一時的なトラフィックのピークの際に、一番人気のあるオブジェクトをできるだけ素早く提供しディスク負荷を低減します。以下の RAM キャッシュのサイズの変更 で説明されているように、必要に応じて RAM キャッシュのサイズを設定できます。

The RAM cache supports two cache eviction algorithms, a regular LRU (Least Recently Used) and the more advanced CLFUS (Clocked Least Frequently Used by Size; which balances recentness, frequency, and size to maximize hit rate, similar to a most frequently used algorithm). The default is to use LRU, and this is controlled via proxy.config.cache.ram_cache.algorithm.

LRU と CLFUS RAM キャッシュはスキャン耐性を増加する設定に対応しています。典型的な LRU では、存在しうるすべてのオブジェクトに順にリクエストを行うと、リクエストのたびにキャッシュを撹拌することになるでしょう。この問題に対してある程度の耐性を追加するために proxy.config.cache.ram_cache.use_seen_filter オプションを設定することができます。

さらに、CLFUS は RAM キャッシュ自体の圧縮にも対応しています。これはコンテンツ自体が圧縮されていない場合 ( 例えば画像 ) に便利です。これを Content-Encoding: gzip と混同しないでください。この機能は RAM キャッシュ自体の領域を内部的に節約するだけの機能です。それ自体、 User-Agent に対して完全に透明です。 RAM キャッシュの圧縮は proxy.config.cache.ram_cache.compress オプションで有効化されます。

取りうる値は :

値

意味

0

圧縮しない (デフォルト)

1

fastlz 圧縮

2

libz 圧縮

3

liblzma 圧縮

RAM キャッシュのサイズの変更

Traffic Server provides a dedicated RAM cache for fast retrieval of popular small objects. The default RAM cache size is automatically calculated based on the number and size of the cache partitions you have configured. If you've partitioned your cache according to protocol and/or hosts, then the size of the RAM cache for each partition is proportional to the size of that partition.

キャッシュヒットパフォーマンスを良くするために RAM キャッシュサイズを増やすことができます。しかしながら、RAM キャッシュのサイズを増やしてパフォーマンスの低下 ( レイテンシーの増加など ) に気づいた場合、オペレーティングシステムがネットワークリソース用により多くのメモリーを必要としている可能性があります。この場合は、RAM キャッシュのサイズを元の値に戻すべきです。

RAM キャッシュサイズを変更するには:

  1. Traffic Server を停止

  2. Set the variable proxy.config.cache.ram_cache.size to specify the size of the RAM cache. The default value of -1 means that the RAM cache is automatically sized at approximately 10MB per gigabyte of disk.

  3. Traffic Server を再起動。RAM キャッシュのサイズを 1GB 以上に増やした場合、trafficserver コマンドで再起動してください (Traffic Server を起動する を参照 ) 。

Disabling the RAM Cache

It is possible to disable the RAM cache. If you have configured your storage using the volume.config you can add an optional directive of ramcache=false to whichever volumes you wish to have it disabled on. This may be desirable for volumes composed of storage like RAM disks where you may want to avoid double RAM caching.

キャッシュキャパシティの変更

コンテンツをクリアすることなくキャッシュに割り当てられたディスク領域の総量を増加もしくは削減することができます。キャッシュのサイズ ( バイト ) を確認するには、traffic_ctl metric get proxy.process.cache.bytes_total コマンドを実行してください。

キャッシュキャパシティの増加

既存のディスク上のキャッシュに割り当てられたディスク領域の総量を増加させる、もしくは Traffic Server のノードに新しくディスクを追加するには :

  1. Traffic Server を停止

  2. 必要であればハードウェアを追加。

  3. 既存のディスクに割り当てられたディスクスペースの総量を増加させるため、もしくは追加した新しいハードウェアを記載するために storage.config を編集。

  4. Traffic Server を再起動。

キャッシュキャパシティの削減

既存のディスク上のキャッシュに割り当てられたディスク領域の総量を削減する、もしくは Traffic Server のノードからディスクを取り外すには :

  1. Traffic Server を停止

  2. 必要であればハードウェアを取り外す。

  3. 既存のディスクに割り当てられたディスクスペースの総量を削減するため、もしくは取り除いたハードウェアへの参照を削除するために storage.config を編集。

  4. Traffic Server を再起動。

重要

storage.config で、フォーマットされた、もしくは raw ディスクは少なくとも 128 MB なければなりません。

キャッシュの区分け

You can manage your cache space and restrict disk usage from specific origin servers and/or domains by creating cache volumes.

オリジンサーバーもしくはドメインによってキャッシュを区分けする

You can assign the volumes you create to specific origin servers and/or domains. You can assign a volume to a single origin server or to multiple origin servers. However, if a volume is assigned to multiple origin servers, then there is no guarantee on the space available in the volumes for each origin server. Content is stored in the volumes according to popularity. In addition to assigning volumes to specific origin servers and domains, you must assign a generic volume to store content from all origin servers and domains that are not listed. This generic volume is also used if the partitions for a particular origin server or domain become corrupt. If you do not assign a generic volume, then Traffic Server will run in proxy-only mode. The volumes do not need to be the same size.

注釈

特定のホストやドメインにボリュームを割り当てる前に Traffic Server を停止する必要はありません。しかし、このタイプの設定は時間がかかり、メモリ使用量のスパイクを引き起こすかもしれません。したがって、トラッフィクが少ない時間帯にパーティション割り当ての設定を行うのが最適です。

ホスト名とドメインによってキャッシュを区分けするには:

  1. 各オリジンサーバーやドメインで使用されるボリュームを割り当てるための行を hosting.config ファイルに入力。

  2. ファイルに記載されているどのオリジンサーバーやドメインにも属さないコンテンツで使用する汎用ボリュームを割り当てる。特定のオリジンサーバー用のすべてのボリュームが壊れた場合、Traffic Server は hosting.config によるオリジンサーバーのコンテンツを格納するために汎用ボリュームも使用します。

  3. 設定の変更を反映するためにコマンド traffic_ctl config reload を実行。

キャッシュオブジェクトのサイズ制限を設定

デフォルトでは、Traffic Server はどんなサイズのオブジェクトがキャッシュされることを許しています。次の手順により、このデフォルトの振る舞いを変更してキャッシュ内のオブジェクトのサイズを制限する指定が行えます。

  1. キャッシュ内で許されるオブジェクトの最大サイズをバイト単位で指定するために proxy.config.cache.max_doc_size を設定。 0 ( ゼロ ) を設定するとキャッシュオブジェクトのサイズは無制限になります。

  2. 設定の変更を反映するためにコマンド traffic_ctl config reload を実行。

キャッシュのクリア

キャッシュをクリアすると、キャッシュ全体からすべてのデータを削除します。これにはホストデータベースのデータも含まれます。区分けのような確実なキャッシュの設定作業を行う前にはキャッシュをクリアすべきです。 Traffic Server が動作している間はキャッシュのクリアは行えません。

キャッシュをクリアするには:

  1. Traffic Server を停止 (Traffic Server の停止を参照 )。

  2. キャッシュをクリアするために次のコマンドを入力

    traffic_server -Cclear

    clear コマンドはオブジェクトストアとホストデータベース内のすべてのデータを削除します。Traffic Server は削除の確認を促しません。

  3. Traffic Server を再起動 (Traffic Server の起動を参照 ) 。

キャッシュからオブジェクトを削除する

Traffic Server はキャッシュから特定のオブジェクトを取り除くときのためにカスタム HTTP リクエストメソッド PURGE を受け付けます。オブジェクトがキャッシュ内で見つかり取り除くことに成功すると、Traffic Server は 200 OK の HTTP メッセージで応答します。そうでない場合は、404 File Not Found メッセージが返されます。

注釈

デフォルトでは PURGE リクエストメソッドは localhost インターフェースで受信した時のみ処理されます。

次のサンプルでは、Traffic Server がドメイン example.com 上で動作しており、キャッシュから remove_me.jpg という画像を取り除きたいとします。デフォルトでは PURGE リクエストは他のどの IP からも許されていないので、localhost からデーモンに接続します。

$ curl -vX PURGE --resolve example.com:80:127.0.0.1 http://example.com/remove_me.jpg
* About to connect() to example.com port 80 (#0)
* Trying 127.0.0.1... connected
* Connected to example.com (127.0.0.1) port 80 (#0)

> PURGE /remove_me.jpg HTTP/1.1
> User-Agent: curl/7.19.7
> Host: example.com
> Accept: */*
>
< HTTP/1.1 200 Ok
< Date: Thu, 08 Jan 2010 20:32:07 GMT
< Connection: keep-alive

次に Traffic Server が取り除かれたオブジェクトへのリクエストを受け取ったときは、新しいコピーを取得するためにオリジンサーバーに接続します。新しいコピーは Traffic Server で以前にキャッシュされていたバージョンを置き換えます。

This procedure only removes the index to the object from a specific Traffic Server cache. While the object remains on disk, Traffic Server will no longer able to find the object. The next request for that object will result in a fresh copy of the object fetched. Users may still see the old (removed) content if it was cached by intermediary caches or by the end-users' web browser.

Pushing an Object into the Cache

Traffic Server accepts the custom HTTP request method PUSH to put an object into the cache. If the object is successfully written to the cache, then Traffic Server responds with a 200 OK HTTP message; otherwise a 400 Malformed Pushed Response Header message is returned.

To push an object, first save the object headers and body into a file. For instance:

$ curl -s -i -o /path/to/file "http://example.com/push_me.html"
$ cat /path/to/file
HTTP/1.1 200 OK
Date: Wed, 31 May 2017 16:01:59 GMT
Access-Control-Allow-Origin: *
Cache-Control: max-age=10800, public
Last-Modified: Wed, 31 May 2017 16:01:59 GMT
Content-Type: text/html
Age: 0
Content-Length: 176970

<!DOCTYPE html><html id= ...

Then, to push the object, post the object using the PUSH method:

$ curl -s -o /dev/null -X PUSH --data-binary @/path/to/file "http://example.com/push_me.html"

If-Modified-Since/If-None-Match

Traffic Server will respond to matching If-Modified-Since/If-None-Match requests with a 304 Not Modified HTTP message.

This table describes how Traffic Server handles these types of requests:

OS = Origin Server's response HTTP message
IMS = A GET request w/ an If-Modified-Since header
LMs = Last-Modified header date returned by server
INM = A GET request w/ an If-None-Match header
E   = Etag header present
D, D' are Last modified dates returned by the origin server and are later used for IMS
The D date is earlier than the D' date

Client's Request

Cached State

Proxy's Request

Response to client

OS 200

OS 304

GET

Fresh

N/A

N/A

N/A

GET

Stale, D'

IMS D'

200, new

200, cached

GET

Stale, E

INM E

200, new

200, cached

INM E

Stale, E

INM E

304

304

INM E + IMS D'

Stale, E + D'

INM E IMS D'

200, new *

304

IMS D

None

GET

200, new *

N/A

INM E

None

GET

200, new *

N/A

IMS D

Stale, D'

IMS D'

200, new

Compare LMs & D'. If match, 304 If no match, 200, cached

IMS D'

Stale, D'

IMS D'

200, new

IMS D'

Stale D

IMS D

200, new *