STON Edge Server完全ガイド¶
| 著者: | STON開発チーム |
|---|---|
| 最新バージョン: | [CDN] v2.5.16 / [Enterprise] v18.05.1 |
1部。 STON基本：設定を学ぶ¶
第1章。 STONエッジサーバー（Edge Server）¶
サービス設計の原則¶
サービスの成功は可用性速度拡張性にかかっています。「拡張性Webアーキテクチャと分散システムの設計」を書いたKate Matsudairaもこの3つの原則を強調しました。
可用性 (availability)
サービスは常に可能でなければならない。障害発生時の90％のお客様は競合他社に移動します。 完全なシステムはないが障害時の復旧は迅速なければならない。
速度 (speed)
ビジネスでの時間は金であります。 遅い応答時間は売上高の減少になります。 応答時間が0.1秒の遅延と売上高1％が減少します。 Amazon.comの顧客47％はWebページが2秒以内に開かれることを望みます。
拡張性 (scalability)
顧客は万人でも一人でもサービスはスムーズなければならない。 サイズを育て維持する努力ストレージ拡張性トランザクション処理余力も拡張性であります。 管理の拡張性欠かせない。 診断問題を理解しアップデートと変更が容易でなければならない。
すべての原則は最小のコストで守る収録効率的です。 費用はお金だけではなく時間努力訓練なども含んでいます。
成功サービスは 急成長します。 より多くの顧客とより多くのコンテンツに対処する必要があります。 成長すればするほどの原則はより守るのは難しい。 どのようにすればこの原則を簡単に最小のコストで守ることができるだろうか？
サービスの成長¶
テストやパイロットサービスは一・二台のサーバーで開始します。 サービスが少しずつ成長しています。 サーバーの数は徐々に増える。 コンテンツの更新は一台ずつ入念にする必要があります。 まだ力技で何とかできます。
サービスが成長し始めています。顧客が増え積むデータがますます大きくなります。 サーバーをいちいち管理することも難しくなります。 データを一箇所に集める高コストのストレージを導入します(NAS、SAN、DAS など)。 高コストであるが信頼することができるようだ。 コンテンツ更新が容易になった。ストレージにあげたコンテンツはサーバー側に自動的に更新されます。
サービスが成長します。 サーバー台数が増えてストレージの転送負荷が大きくなった。 より速いストレージはとても高価です。 導入をためらわれる。 投資する価値があるか。
同期（synchronization）ソリューションを検討します。 サーバーにデータ全体を準備することはできない。ストレージのコンテンツを選別する必要があります。 正確に制御するには高度な管理技術が必須だ。 少ない台数のサーバーの同期管理は簡単だ。 ただしサーバーとファイル数が増えるほど難しくなります。 ますます状況は悪化されます。 大きくなるほど遅くなり難しく不安定になります。
コンテンツが速い速度で更新されます。更新ファイルが多くなるほど同期時間が長くなります。 サービスの規模が大きくなるほど同期管理システムも同然に大きくなって複雑になります。 管理システムの障害はすぐに全体の障害を起こす。
コンテンツを迅速・円滑に配信する簡単な方法が必要になります。
サービス拡張性と配信¶
階層化（layering）にサービスをモデル化すると次の図のように2層に分かれます。
中心にデータを管理するストレージ（storage）の層があります。 その上にサービスロジックが実装されたアプリケーション（application）階層があります。 アプリケーション層は小規模顧客向けコンテンツ配信も処理することができます。 初期にはストレージとアプリケーション層のみでサービスを構成することができます。
サービスが成長し処理費用は変わります。初期にはロジックの開発が成長期には顧客の増加とともにデータ管理が最も多くの費用です。サービスが発展するほど最大の悩みは コンテンツ配信 になります。急増するトラフィックをどう解決するのか？ コンテンツ配信 はサービス増設（Scale-out）の大きな課題になります。
エッジ（edge）：トランスポート層¶
サービスが成長すると配信の負担は指数的に増加します。ショッピングモールのコンテンツ数は多ければ数十億個に達します。 動画サービスのコンテンツはTBに達して久しい。サービスの増設には コンテンツ配信の拡張性（scalability）を考慮する必要があります。
エッジ（edge）はサービスの最も外側最前方を指す。 エッジでは顧客はサービスの応答速度を体験します。 顧客が要求しているコンテンツは「必ず」応答する必要があります。 壊れたエラーイメージ・接続不能は非常に致命的になります。 エッジでコンテンツ配信を処理するとアプリケーションとストレージの転送負担が減ります。
エッジの拡張が効率的であれば他の高コストの層を増設する必要がない。 ストレージとアプリケーションの増設は高コストの非効率的選択であります。
STONエッジサーバーは以下の方法で迅速・簡単なコンテンツ配信を実現します。
エッジサーバーの動作：キャッシュ（cache）¶
送信の規模は顧客の数とコンテンツのサイズに比例して大きくなります。 どのように多くの顧客がどのようなコンテンツを要求していることはエッジで最も早く知ることができます。 エッジからBottom-upの処理の流れが効率的であります。 したがってエッジサーバーは顧客の要求に応じてOn-demandで動作する キャッシュ(cache) 伝送方式を採用した。 管理システムもいりません。具体的な動作は以下の通りです。
エッジサーバーは最初のコンテンツ転送要求を受けたとき元の階層からコンテンツを取得し顧客に送信します。 このコンテンツをエッジサーバーは自分にも保存します。 第二の要求とその後は保存されたコンテンツを顧客にすぐに送信します。 保存されたコンテンツは設定されたTTL（Time-To-Live）時間だけ有効であります。
エッジサーバーはこれらの方法でㅅ大量のコンテンツ配信を処理することができます。 アプリケーションとストレージの増設を最小限に抑えながら高速大容量伝送を処理します。 成長するサービスであれば必ずエッジを考慮する必要があります。
STONエッジサーバーは無制約・無依存環境を志向するソフトウェアです。 どんなハードウェアにインストールしても最大のパフォーマンスを発揮できるように設計されています。
CPU: Many-Coreに最適化された。Throughputはコア数に比例します。
Memory: Memoryが多ければ多いほど高速に処理します。 Disk I / Oを削減します。
Disk: I/O を均等に分散します。より多くのデータをcachingします。
NIC: 4Gbps NIC Bondingまたは10Gbps NICのBandwidthを保証します。
STONエッジサーバーは 強力な実時間モニタリング/ログ をサポートします。 秒単位のリアルタイム統計にすぐサービスの状態がどうかを確認することができます。 JSON、XML、SNMP などのいくつかの汎用フォーマットでリアルタイムの数値を提供します。
STONは管理者のための 簡単な設定 を提供します。 STONの設計理念は管理者のためのエッジサーバーであります。 Web Managementページを使用して直感的な設定方法を提供します。 ディテールの設定を希望する場合単2つのXML設定ファイルに簡単にすることができます。
エッジサーバーの影響¶
エッジサーバーの効果は次の通りであります。
- 簡単で便利なサービス加速
- サービスのソースを外部から保護 (Origin Shielding)
- サービスが重要な役割を実行することができるよう補助
エッジサーバーの影響は次の適用事例を中心にも確認することができます。
Game¶
伝統的にゲームサービスは信じられないほど多くの帯域幅を必要とします。 「大作」 のゲームから簡単なカジュアルゲームまで種類も非常に多様であります。 特にスマートフォンゲームの爆発的な成長はサービス形態をより多様にした。
高い帯域幅
単一のサーバーで高帯域幅を得る従来の方法は1Gbps NICをボンディング（Bonding）するものであります。 これにより4Gbpsの帯域幅まで得ることができます。 最近10Gbps NICも市場に多く普及している傾向にあります。
STON4Gbps NIC Bondingと10Gbps NICも最大帯域幅を保証します。ユーザーの帯域幅を保証
すべてのユーザーはゲームをすぐにダウンロード・プレイしたい。 光LANユーザーは100Mbpsの速度が得られない場合クレームの電話をかけるだろう。 サーバーは物理的に各ユーザーへ最大速度を提供する必要があります。
STONすべてのユーザーに最大速度で転送することを保証します。大容量ファイルの処理
インストールファイルがxGB程度のゲームはいまはのゲームでは普通のサイズだ。 数十GBは必要があり「大作」という単語を取り付けることができる世界であります。 ファイルが大きすぎる場合サーバーのメモリにファイルのすべてがCachingできない。 最悪の状況はファイルのサイズが大きすぎてユーザーごとにダウンロードされる位置がまちまちである状況であります。
STONCachingファイルサイズの制限がない。 MemoryとDiskへの適切なSwap処理でいつでも高性能を保証します。Range要求の処理
ファイルの転送が大型化されている傾向に基づいてGrid Delivery手法のP2Pソリューションも多く使用されています。 このようなソリューションはファイルを細かく分けた送受信が発生するためサーバーに非常に多いHTTP Rangeリクエストを届く。 10GBのファイルを万人の顧客が異なるRangeに要求する状況もありえます。 どの部分を要求してもサービスはすぐに応答する必要があります。 しかしOriginのサーバーでは必ず元のファイルのサイズ分だけのデータが送信されるべきであります。
STONRange要求に最適化されたファイルシステムが搭載された。 またマルチダウンロードに迅速な応答性を確保します。 オリジンサーバーから1Bytesも不要ダウンロードはしません。
ショッピングモール¶
ショッピングモールはサイトのアクセスが顧客の売上と直結します。 今伝統的なPC環境だけでなくモバイルショッピングが当たり前になった。 ショッピング環境が多様化だけではなく無限に増えるファイルを管理する必要があります。
- 無限大の小さなファイル
「億単位以上」「無数の」「いつも増加する」ファイルを保存するためには高価なStorageが必要であります。 しかし経済性が重要なEdgeサーバーではそのことができない。 サイズが1KBのファイルが10億個存在するサービスもあることができます。 結論としてすべてのファイルをCachingできない。 オリジンサーバーの負荷を最小限に抑えるながらもアクセス頻度が高いファイルを常に維持する方法が必要であります。
STONメモリとDiskリソースの最大容量だけCachingします。 すべてのファイルのアクセス頻度はリアルタイムで管理されLRU（Least Recently Used）によって古いファイルの順に削除されます。多くのユーザー
ショッピングモールは多くのユーザーを同時に処理することができなければならない。 急なイベントによってユーザー接続が爆発的に増加（= Burst）もあります。 Burst時サーバーは自分自身を保護する必要がありBurst後も安定性を維持する必要があります。
STONCPU拡張性（Scalability資源の増設によりソリューションの性能が高まること）を保証します。 弾力性のあるHTTP Keep-Alive処理とソケットの管理を使用してBurst時にも安定性を確保します。反応性
快適なショッピング環境とページがすぐにロードされていることを意味します。 ユーザーは待たない。 3秒以内にロードされない場合他のサイトに残します。 一般的にメインページには100個前後のファイルで構成され物理的な環境を考慮しても通常1秒台にページが完全にロードされるべきであります。
STONリアルタイムファイルのインデックスを使用したすぐに応答を保証します。 ソフトファイル交換を介して元の依存関係がなく反応性を最大化することができます。 すべてのHTTP応答（First byte応答トランザクションの完了）のログと統計数値を提供してパフォーマンスの低下かどうかをリアルタイムに検出することができます。ページTTL
大半のユーザーの移動経路はメインページ - >大カテゴリページ - >小型カテゴリー - >詳細ページ順であります。 ページごとに露出頻度が異なるだけでなく更新たりも異なるべきであります。 スマートなページCaching及び更新の方法が必要であります。
STONURLごとに個別のTTLを付与することができます。 またPurge、Expire、ExpireAfter、 HardPurge など状況に応じて様々な方式の更新方法を提供します。
メディア¶
メディア専用のプロトコルは徐々に居場所を失っています。 HTTP、MP4のシンプルだが強力な組み合わせは徐々に勢力を広げています。 モバイルの可変の接続状態を考慮すればHTTPベースのStreaming方式が送信標準になるだろう。
メディア認識
これ以上ファイルをChunkとして認識してはならない。 メディアファイルを正確に認識することができこそ帯域幅の節約と一緒に様々な付加機能を連動することができます。 サーバーがファイルの解釈のためにファイルのすべての部分を必要とする場合ユーザーは映像の再生を放棄するものであります。
STONMP4、MP3、M4A、FLV 形式をサポートします。 ダウンロードと同時にHTTP Pseudo Streamingのために必要な領域を優先的にCachingします。メディアヘッダーの再配置
ヘッダが背後にあるファイルの場合HTTP Pseudo Streamingが不可能であります。 そのためには専用のプレイヤーが必要ですがこれユーザーに迷惑を+10します。
STONMP4ファイルのエンコード後のヘッダーが後に付く場合ヘッダーを今後移す作業をさらに行う必要があります。 STONは自然にヘッダを前に移して整備します。帯域幅の調整
ほとんどの映像を最後まで見るユーザーは珍しい。 したがって再生に無理がないように必要な分だけの帯域幅を使用することが効率的な伝送方法であります。 同じ映像であっても360p480p720p1080pのようにBitrateを多様にサービスします。
STONBandwidth-Throttlingを通じてメディアファイルの転送帯域幅を最適化することができます。区間抽出
プレビュー/ハイライト/共有するなどファイル全体ではなく特定の区間だけをサービスする場合も多い。 サービスを提供するすべてのファイルに対して区間を抽出することは時間とストレージ容量を過度に無駄にします。 さらにユーザーごとに抽出区間が異なる場合もあります。 またSkip機能を区間再生に実装するプレイヤーも存在します。
STONTrimming機能により区間を抽出して完全な形のメディアファイルにサービスします。
ニュース/コミュニティ¶
非常に高い忠誠心のユーザー層を確保したサイトは興味深い点が多い。 同じ興味を持つユーザーが集まるので交流が盛んでページに留まる時間も非常に長い。 サービスパターンがバラバラだとサービスするかなり難しい。
304 Not Modified
サイトの忠誠心が非常に高いため既に多くのファイルをユーザーのローカルに保存しています。 ので実際に転送されるファイルよりも「変更の確認」の割合が圧倒的であります。
STON頻繁にアクセスされるファイルは常にメモリに常駐するように保証します。 「変更の確認」 の作業は待つことなくすぐに処理されます。Bypass
ユーザーに特化したページや新しい記事リップルなどのページは常にCachingできない領域を含んでいます。 しかしDomainを別々に分けずに単一のドメインをReverse-Proxyに委任する場合が多い。
STON多様な条件に基づいてバイパス対象を精巧に分類します。またOrigin AffinityPrivate機能を利用してログインセッションを維持することができます。不安定なオリジンサーバー
中小企業や個人が運営するサイトは高価な機器やインフラで運営するのは難しい。 オリジンサーバーの障害の頻度が比較的高くこれを克服するための経済性は非常に悪い。
STON元サーバーの過負荷や障害を判断して自動的に排除/復旧が行われる。 オリジンサーバーの障害時にTTLを自動的に延長させてオリジンサーバー依存を最小限に抑えています。イメージ加工
同じイメージをユーザーの環境に応じて多様に示す必要があります。 検索結果ではThumbnailイメージをニュースサイトでは 「XXニュース」 のような文字をウォーターマークとして表示する必要があります。 同じイメージを表示される形態に応じて毎回処理することはストレージ容量と時間労働力の浪費だ。
STONDIMS 機能を使用するとオリジンサーバーに単一のイメージだけで所望の形状をURL呼び出しだけで生成することができます。。
ファイルベースのサーバー¶
EdgeはReverse-Proxy構造に基づいています。Reverse-Proxyの重要な概念はリモートサーバー上のファイルをローカルに複製/更新/管理するものです。 すでに検証されたSTONをサービスサーバと連動することができればStorage一元化と同期の問題を除去することができます。 だけでなく開発時間の短縮とサービスの信頼性の向上の二匹のウサギをすべてキャッチすることができます。
File I/O サポート
専用プロトコルが必要な場合該当プロトコルモジュールに依存するサーバーになります。なんとか連動しても性能が低下すると無用の長物になります。プロトコルモジュールとサーバーとの間の中間段階は最小限にする必要があります。
STON標準File I / OでSTONが連動されます。 専用サーバーとSTONの間にはLinux Kernel（VFS）のみが存在し高性能を保証します。Web Server 連動
標準Webサーバ(Apache、Lighttpd、NginX)に特化した拡張モジュールがインストールされている場合標準のReverse-Proxyを導入が難しくなる可能性があります。DB / WASと連動されているファイルサービスや課金/決済サービスのような場合は簡単のサービスを拡張するのは難しい。
STONApacheのDocumentRootをSTONに指定するとApacheはSTONを物理ディスクとして認識します。 それ以外の設定はいらない。Wowza 連動
メディアサービスではWowzaが事実上の標準であります。 しかしWowzaのHTTP Caching機能の使用は面倒で弱いです。また徐々にHTTP以外の「専用」のプロトコルは減少傾向にあります。
STONローカルディスクにMountできるだけでなくMP4ヘッダの変換Trimmingなどすべての機能を利用することができます。リソースの制約
Back-endに存在するファイルをFront-Endのユーザーに配信するサーバーであれば常にファイルの同期が問題になります。 ゲームサーバSNSサーバなどの専用サーバーの開発問題は常に存在します。 このようなサーバーの場合中断することなく長期間運用されるべきなのでメモリディスクの使用が厳しく制限される必要があります。
STON最大使用メモリディスク使用量を制限することができます。 またディスクとしてMountしても他のすべての機能は同じように動作し複合的なサービスを最小限のソリューションで構成することができます。
STONはこれらの特性を積極的に活用する以下のようなのサービスと一緒に成長しています。
第2章 開始する¶
この章ではシステム構成からインストールおよびサンプルの仮想ホストまで構成してみます。 テキストエディタがあれば誰でもすることができます。
STONは標準のLinuxサーバで動作するように開発されました。 開発段階からHWだけでなくOSファイルシステムなどの依存関係を持たないように設計しました。顧客が合理的な機器を選択できるように助けることは非常に重要です。 サービスの特性や規模に応じて適切なサーバーを構成することがサービス開始の大事な一歩になるためです。
サーバーの構成¶
一般的にサーバーを構成するときはCPUメモリディスクを主に考慮します。 10Gbps級の高い性能を必要とするサービスであれば各構成要素がサービスの特性を満足しなければなら所望の性能を得ることができます。
CPU
Quadコア以上を推奨します。 STONはMany-Core Scalabilityシステムです。 コアが多ければ多いほど毎秒スループットは増加します。 ただし高スループットが必ずしも高いトラフィックを意味することではありません。
クライアントが多いほど多くのCPUは力になります。
4KBのファイルを約26万回を送信することと1GBのファイルを一度送信することは同じ帯域幅を使用します。 CPUの選択の最大の基準はどのように多くの同時接続を処理するかです。
メモリ
Memory-Indexing方式を使用するため4GB以上を推奨します。 ( メモリ構造 を参照) 頻繁にアクセスされるコンテンツはメモリに常駐しますがそうではないコンテンツはディスクからロードします。 したがってコンテンツが多く集中度が低い場合（Long-tail）ディスク負荷の増加しパフォーマンスが低下する場合があります。 サービスされているコンテンツの数に関係なくコンテンツサイズが大きくディスクI / Oの負荷が高い場合メモリを増設して負荷を下げることができます。
ディスク
OSを含む少なくとも3つ以上を推奨します。 ディスクも多ければ多いほど多くのコンテンツをキャッシュすることができるだけでなくI / Oの負荷も分散されます。
必ずOSとSTONはコンテンツとは別のディスクで構成します
一般的にOSがインストールされてディスクにSTONを設置します。 ログも同じディスクに設定するのが一般的です。 ログはサービスの状況をリアルタイムで記録するためWrite負荷が発生します。
STONはディスクをRAID 0のように使用します。 性能とRAIDの関係有無は顧客サービスの特性に応じて変わります。 しかしファイルの変更が頻繁せずコンテンツのサイズが物理メモリのサイズよりもはるかに大きい場合はRAIDを使用したRead速度の向上が効果的な場合があります。
OSの構成¶
最もデフォルト的な形で設置します。 標準64bit Linuxディストリビューション（Cent 6.2以上Ubuntu 10.04以上）であれば正常に動作します。パッケージの依存関係はありません。
インストール¶
最新バージョンのSTONをダウンロードします。
[root@localhost ~]# wget http://foobar.com/ston/ston.2.0.0.rhel.2.6.32.x64.tar.gz --2014-06-17 13:29:14-- http://foobar.com/ston/ston.2.0.0.rhel.2.6.32.x64.tar.gz Resolving foobar.com... 192.168.0.14 Connecting to foobar.com|192.168.0.14|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 71340645 (68M) [application/x-gzip] Saving to: “ston.2.0.0.rhel.2.6.32.x64.tar.gz” 100%[===============================================>] 71,340,645 42.9M/s in 1.6s 2014-06-17 13:29:15 (42.9 MB/s) - “ston.2.0.0.rhel.2.6.32.x64.tar.gz” saved [71340645/71340645]
圧縮を解凍します。
[root@localhost ~]# tar -zxf ston.2.0.0.rhel.2.6.32.x64.tar.gz
インストールスクリプトを実行します。
[root@localhost ~]# ./ston.2.0.0.rhel.2.6.32.x64.sh
インストールプロセスはinstall.logに記録されます。 ログを使用してインストール中に発生する問題を検知することができます。
#DownloadURL: http://foobar.com/ston/ston.2.0.0.rhel.2.6.32.x64.tar.gz #DownloadTime: 13 sec #Target: STON 2.0.0 #Date: 2014.03.03 16:48:35 Prepare for STON 2.0.0 install process Stopping STON... STON stopped [Copying files] `./fuse.conf' -> `/etc/fuse.conf' `./libfuse.so.2' -> `/usr/local/ston/libfuse.so.2' `./libtbbmalloc_proxy.so' -> `/usr/local/ston/libtbbmalloc_proxy.so' `./start-stop-daemon' -> `/usr/sbin/start-stop-daemon' `./libtbbmalloc_proxy.so.2' -> `/usr/local/ston/libtbbmalloc_proxy.so.2' `./libtbbmalloc.so' -> `/usr/local/ston/libtbbmalloc.so' `./libtbbmalloc.so.2' -> `/usr/local/ston/libtbbmalloc.so.2' `./libtbb.so' -> `/usr/local/ston/libtbb.so' `./libtbb.so.2' -> `/usr/local/ston/libtbb.so.2' `./stond' -> `/usr/local/ston/stond' `./stonx' -> `/usr/local/ston/stonx' `./stonr' -> `/usr/local/ston/stonr' `./stonu' -> `/usr/local/ston/stonu' `./stonapi' -> `/usr/local/ston/stonapi' `./server.xml.default' -> `/usr/local/ston/server.xml.default' `./vhosts.xml.default' -> `/usr/local/ston/vhosts.xml.default' `./ston_format.sh' -> `/usr/local/ston/ston_format.sh' `./ston_diskinfo.sh' -> `/usr/local/ston/ston_diskinfo.sh' `./wm.sh' -> `/usr/local/ston/wm.sh' [Exporting config files] #Export so directory /usr/local/ston/ to ld.so.conf #Export sysctl to /etc/sysctl.conf vm.swappiness=0 vm.min_free_kbytes=524288 #Export sudoers for WM Defaults !requiretty winesoft ALL=NOPASSWD: /etc/init.d/ston stop, /etc/init.d/ston start, /bin/ps -ef [Configuring STON daemon script] STON deamon activate in run-level 2345. [Installing sub-packages] curl installed. libjpeg installed. libgomp installed. rrdtool installed. [Installing WM] Stopping WM... WM stopped `./wm.server_default.xml' -> `/usr/local/ston/wm/tmp/conf/server_default.xml' `./wm.vhost_default.xml' -> `/usr/local/ston/wm/tmp/conf/vhost_default.xml' WM configuration found. Current WM port : 8500 PHP module for Legacy(CentOS 5.5) installed `./libphp5.so.5.5' -> `/usr/local/ston/wm/modules/libphp5.so' WM installation almost complete. Changing WM privileges. Installation successfully complete
ライセンス発行¶
新規顧客の場合次の手順でライセンスを発行します。
- 申込書 の作成
- license@winesoft.co.kr に転送
- 確認手続き後ライセンス発行
ライセンスファイル（license.xml）は必ずインストールパスに存在する必要がSTONが正常に駆動されます。
アップデート¶
最新バージョンが配布されるとstonuコマンドで更新できます。
./stonu 2.0.1
または 第13章 WM（Web Management） の 最新バージョンの更新 を通じて簡単にアップデートを行うことができます。
外部接続ができない場合¶
STONがインストールされるサーバーで外部接続がされていない場合は次のようにマニュアル方式のアップデートが可能です。
注釈
インストール/アップデートは必ずroot権限で行う必要があります。
外部接続が可能なPCでSTONをダウンロードします。 ダウンロードURLは公式releaseメールを介して配布されます。
ダウンロードしたファイルをPCからサーバにコピーします。 ファイル名の形式は次のとおりです。
- RHEL/CentOS/openSUSE - ston.
version.rhel.2.6.32.x64.tar.gz - Ubuntu - ston.
version.ubuntu.2.6.32.x64.tar.gz
CentOSのバージョン
2.4.9であればファイル名は ston.2.4.9.rhel.2.6.32.x64.tar.gz です。- RHEL/CentOS/openSUSE - ston.
STONが実行中であれば停止します。
service ston stop
サーバ内のコピーされたパスで圧縮を解除します。
tar zxvf ston.2.4.9.rhel.2.6.32.x64.tar.gz
インストールスクリプトを実行します。 STONが実行中であれば 「yes」を入力して停止します。
sh ston.2.4.9.rhel.2.6.32.x64.sh
インストールの完了後STONを開始します。
service ston start
正常に起動されたことを確認します。
ps -ef | grep ston
実行する¶
通常デフォルトのパスにSTONを設置します。
/usr/local/ston/
次のファイルのいずれかが存在しないかXML構文に合わない場合は実行できません。
- license.xml
- server.xml
- vhosts.xml
最初のインストール時にすべてのXMLファイルはありません。 配布されたライセンスファイルをインストールパスにコピーします。 そしてインストールパスのserver.xml.defaultとvhosts.xml.defaultをコピーまたは変更して設定します。 *.defaultファイルは常に最新のパッケージと一緒に配布されます。
Hello World¶
vhosts.xml ファイルを開き次のように編集します。
<Vhosts>
<Vhost Name="www.example.com">
<Origin>
<Address>hello.winesoft.co.kr</Address>
</Origin>
</Vhost>
</Vhosts>
STON実行¶
発行されたlicense.xmlをインストールパスにコピーします。
server.xmlを開き<Storage>を構成します。
<Server> <Cache> <Storage> <Disk>/cache1/</Disk> <Disk>/cache2/</Disk> </Storage> </Cache> </Server>
注釈
STONはデフォルト的にディスクをストレージとして使用するためディスクが設定されていない場合起動しません。 詳細については次の章で説明します。
STONを実行します。
[root@localhost ~]# service ston start
STONを停止したい場合はstopコマンドを使用します。
[root@localhost ~]# service ston stop
仮想ホストの動作確認¶
(Windows 7 ベース) C:WindowsSystem32driversetchosts ファイルに次のようにwww.example.comドメインを設定する。
192.168.0.100 www.example.com
ブラウザでwww.example.comにアクセスしたときに次のページが正常にサービスされると成功です。
WMが遅くなったりグラフが表示されない問題¶
インストールプロセス中にRRDグラフは動的にダウンロードしてインストールされます。 限られたネットワークでSTONをインストールする場合はRRDが正しくインストールされないことがあります。 これにより 第13章 WM（Web Management） が非常に遅くなるか Appendix A: Graph が動作しません。次のようにrrdtoolを設置して修正します。
1. rrdtoolのインストールの確認
次のようにインストール有無を確認します。
[root@localhost ston]# yum install rrdtool Loaded plugins: fastestmirror, security Loading mirror speeds from cached hostfile * base: centos.mirror.cdnetworks.com * elrepo: ftp.ne.jp * epel: mirror.premi.st * extras: centos.mirror.cdnetworks.com * updates: centos.mirror.cdnetworks.com Setting up Install Process Package rrdtool-1.3.8-6.el6.x86_64 already installed and latest version Nothing to do次はUbuntu系の場合です。
root@ubuntu:~# apt-get install rrdtool Reading package lists... Done Building dependency tree Reading state information... Done rrdtool is already the newest version. The following packages were automatically installed and are no longer required: libgraphicsmagick3 libgraphicsmagick++3 libgraphicsmagick1-dev libgraphics-magick-perl libgraphicsmagick++1-dev Use 'apt-get autoremove' to remove them. 0 upgraded, 0 newly installed, 0 to remove and 102 not upgraded.
2. RRD手動インストール
もしrrdtoolがyumを使用してインストールがされていない場合はOSのバージョンに合ったパッケージを ダウンロードし た後手動でインストールします。
| Name | Last Modified | Size | Description |
|---|---|---|---|
| tcl-rrdtool-1.4.7-1.el5.rf.i386.rpm | 06-Apr-2012 16:57 | 36K | RHEL5 and CentOS-5 x86 32bit |
| tcl-rrdtool-1.4.7-1.el5.rf.x86_64.rpm | 06-Apr-2012 16:57 | 37K | RHEL5 and CentOS-5 x86 64bit |
| tcl-rrdtool-1.4.7-1.el6.rfx.i686.rpm | 06-Apr-2012 16:57 | 35K | RHEL6 and CentOS-6 x86 32bit |
| tcl-rrdtool-1.4.7-1.el6.rfx.x86_64.rpm | 06-Apr-2012 16:57 | 35K | RHEL6 and CentOS-6 x86 64bit |
オリジンサーバー¶
仮想ホストはオリジンサーバーに代わってコンテンツをサービスすることが目的です。 サービス形態に合わせて多様なオリジンサーバーで多様なアプローチが可能です。
<Vhosts>
<Vhost Name="www.example.com">
<Origin>
<Address>1.1.1.1</Address>
<Address>1.1.1.2</Address>
</Origin>
</Vhost>
</Vhosts>
<Address>仮想ホストがコンテンツを複製するオリジンサーバーのアドレス。 数の制限はない。 アドレスが2つ以上の場合はActive / Active方式（Round-Robin）で選択されます。 オリジンサーバーのポートが80の場合は省略することができます。
例えば別のポート（8080）でサービスされている場合1.1.1.1:8080のようにポート番号を明示する必要があります。 アドレスは{IP | Domain} {Port} {Path}の形式で以下の8つの表現が可能です。
| Address | Hostヘッダ |
|---|---|
| 1.1.1.1 | 仮想ホスト名 |
| 1.1.1.1:8080 | 仮想ホスト名:8080 |
| 1.1.1.1/account/dir | 仮想ホスト名 |
| 1.1.1.1:8080/account/dir | 仮想ホスト名:8080 |
| example.com | example.com |
| example.com:8080 | example.com:8080 |
| example.com/account/dir | example.com |
| example.com:8080/account/dir | example.com:8080 |
オリジン要求のデフォルトHeader 中Hostヘッダを別途設定しない限り表Hostヘッダを送信します。
<Vhosts>
<Vhost Name="www.example.com">
<Origin>
<Address>origin.com:8888/account/dir</Address>
</Origin>
</Vhost>
</Vhosts>
例えば上記のように設定するとオリジンサーバーに次のように要請します。
GET / HTTP/1.1
Host: origin.com:8888
注釈
オリジンサーバーにexample.com/account/dirようパスがついている場合は要求されたURLはオリジンサーバーのアドレスのパスの後ろにつく。 クライアントが/img.jpgを要求すると最終的なアドレスはexample.com/account/dir/img.jpgになる。
サブオリジンサーバーアドレス¶
サブオリジンサーバーを設定します。
<Vhosts>
<Vhost Name="www.example.com">
<Origin>
<Address>1.1.1.1</Address>
<Address>1.1.1.2</Address>
<Address2>1.1.1.3</Address2>
<Address2>1.1.1.4</Address2>
</Origin>
</Vhost>
</Vhosts>
<Address2>すべての
<Address>が正常に動作する(Active)場合<Address2>はサービスに投入されない(Standby)。 Activeサーバーに障害が検出されるとそのサーバーを置き換えるために投入されてActiveサーバーが復旧すると再びStandby状態に戻る。 もしStandbyサーバに障害が検出されるとStandbyサーバが復旧するまでサービスに投入されない。
API呼び出し¶
HTTPベースのAPIを提供します。 API呼び出しの権限は 管理者の設定 の影響を受けます。 許可されていない場合すぐに接続を終了します。
STONバージョンを確認します。
http://127.0.0.1:10040/version
同じAPIをLinux Shellからのコマンドで実行します。
./stonapi version
注釈
HTTP APIは＆をQueryStringの区切り文字として認識しますがLinuxコンソールでは別の意味があります。 ＆が入るコマンドを呼び出す場合は＆にとして記入するか必ず括弧（"/...＆..."）で呼び出すURLを囲む必要があります。
ハードウェア情報照会¶
ハードウェア情報を照会します。
http://127.0.0.1:10040/monitoring/hwinfo
結果はJSON形式で提供されます。
{
"version": "1.1.9",
"method": "hwinfo",
"status": "OK",
"result":
{
"OS" : "Linux version 3.3.0 ...(省略)...",
"STON" : "1.1.9",
"CPU" :
{
"ProcCount": "4",
"Model": "Intel(R) Xeon(R) CPU E5606 @ 2.13GHz",
"MHz": "1200.000",
"Cache": "8192 KB"
},
"Memory" : "8 GB",
"NIC" :
[
{
"Dev" : "eth1",
"Model" : "Intel Corporation 82574L Gigabit Network Connection",
"IP" : "192.168.0.13",
"MAC" : "00:25:90:36:f4:cb"
}
],
"Disk" :
[
{
"Dev" : "sda",
"Model" : "HP DG0146FAMWL (scsi)",
"Total" : "238787584",
"Usage" : "40181760"
},
{
"Dev" : "sdb",
"Model" : "HITACHI HUC103014CSS600 (scsi)",
"Total" : "144706478080",
"Usage" : "2101075968"
},
{
"Dev" : "sdc",
"Model" : "HITACHI HUC103014CSS600 (scsi)",
"Total" : "144706478080",
"Usage" : "2012160000"
}
]
}
}
再起動/シャットダウン¶
コマンドを実行してSTONを再起動/終了することができます。 予期しない結果を避けるためにWebページを介して確認作業が必要ように開発された。
http://127.0.0.1:10040/command/restart
http://127.0.0.1:10040/command/restart?key=JUSTDOIT // すぐに実行
http://127.0.0.1:10040/command/terminate
http://127.0.0.1:10040/command/terminate?key=JUSTDOIT // すぐに実行
Caching初期化¶
サービスを中断しキャッシュされたすべてのコンテンツを削除します。 設定されたすべてのディスクをフォーマットする作業の完了後サービスを再開します。
http://127.0.0.1:10040/command/cacheclear
http://127.0.0.1:10040/command/cacheclear?key=JUSTDOIT // すぐに実行
コンソールでは次のコマンドを使用して全体または1つの仮想ホストを初期化します。
./stonapi reset
./stonapi reset/ston.winesoft.co.kr
第3章 設定構造¶
この章では設定の構造と変更された設定を適用する方法を説明します。 構造を正確に理解すれば迅速なサーバーデプロイ・障害状況にも円滑な対応ができます。
設定は大きく全域（server.xml）と仮想ホスト（vhosts.xml）に分けられる。
2つの.xmlファイルがすべてです。
2つのXMLファイルでほとんどのサービスを構成します。 複数のTXTファイルで仮想ホスト別の例外条件を設定し特定機能のリストを作成するのに使用されます。完全な形のXMLは以下の形式になります。
<Server>
<VHostDefault>
<Options>
<CaseSensitive>ON</CaseSensitive>
</Options>
</VHostDefault>
</Server>
説明では次のように省略して表記します。
# server.xml - <Server><VHostDefault><Options>
<CaseSensitive>ON</CaseSensitive>
注釈
ライセンス（license.xml）は設定がありません。
設定Reload¶
設定の変更後に管理者が明確にAPIを呼び出す必要があります。 システムパフォーマンス関連の設定以外のほとんどの設定はサービスを中断せずすぐに適用されます。
http://127.0.0.1:10040/conf/reload
設定が変更されるたびに Infoログ に変更が記録されます。
server.xmlグローバル設定¶
実行可能ファイルと同じパスに存在するserver.xmlこのグローバル設定ファイルです。 XML形式のテキストファイルです。
# server.xml
<Server>
<Host> ... </Host>
<Cache> ... </Cache>
<VHostDefault> ... </VHostDefault>
</Server>
まずグローバル設定の構造と簡単な機能を説明します。グローバル設定中ボリュームが大きい機能については 第15章 アクセス制御 や 第11章 SNMP などの各トピックをカバーする章で説明します。
管理者の設定¶
管理目的の機能を設定します。
# server.xml - <Server>
<Host>
<Name>stream_07</Name>
<Admin>admin@example.com</Admin>
<Manager Port="10040" HttpMethod="ON" Role="Admin" UploadMultipartName="confile">
<Allow>192.168.1.1</Allow>
<Allow Role="Admin">192.168.2.1-255</Allow>
<Allow Role="User">192.168.3.0/24</Allow>
<Allow Role="Looker">192.168.4.0/255.255.255.0</Allow>
</Manager>
</Host>
<Name>サーバー名を設定します。 名前が入力されていない場合はシステム名を使用します。
<Admin>管理者情報（メールや名前）を設定します。 この項目はSNMP照会目的のみ使用されます。
<Manager>管理の目的で使用マネージャーポートとACL（Access Control List）を設定します。 ACLはIPIP rangeBitMaskSubnetの四つの形式をサポートします。 接続したセッションがAllowに設定されたIPアドレスのみ許可します。 APIを呼び出すIPは
<Allow>リストに必ず設定する必要があります。アクセス条件に合わせてアクセス権限（Role）を設定することができます。 アクセス権がない要求については 401 Unauthorized で応答します。
<Allow>の条件にRole属性を明示的に宣言していない場合は<Manager>のRole属性が適用されます。AdminすべてのAPI呼び出しが可能です。Userapi_monitoring、 Appendix A: Graph APIのみを呼び出すことができます。LookerAppendix A: Graph APIのみを呼び出すことができます。
その他次のような細かい管理目的の属性を持つ。
HttpMethodON (デフォルト)caching-purge-http-method 呼び出し時ACLを点検します。OFFcaching-purge-http-method 呼び出し時ACLを検査しません。
UploadMultipartName設定アップロード の変数名を設定します。
Storage構成¶
Cachingされたコンテンツを保存するStorageを構成します。
# server.xml - <Server>
<Cache>
<Storage DiskFailSec="60" DiskFailCount="10" OnCrash="hang">
<Disk>/user/cache1</Disk>
<Disk>/user/cache2</Disk>
<Disk Quota="100">/user/cache3</Disk>
</Storage>
</Cache>
<Storage>コンテンツを保存するディスクを設定します。 サブ
<Disk>数の制限はありません。ディスクは障害が最も頻繁に発生する機器のため明確な障害条件を設定することをお勧めします。
DiskFailSec (デフォルト: 60秒)の間DiskFailCount (デフォルト: 10)だけディスクの操作が失敗した場合はそのディスクは自動的に排除されます。 排除されたディスクの状態は "Invalid"に指定されます。すべてのディスクが排除された場合の動作は
OnCrash属性に設定します。hang (デフォルト)障害ディスクの両方を再投入します。 通常のサービスを期待しているというよりは元のを保護する目的が強い。bypassすべての要求をオリジンサーバーにバイパスします。 ディスクが復旧されるとすぐにSTONこのサービスを処理します。selfkillSTONを終了させる。
各ディスクごとに最大キャッシュ容量を Quota (単位: GB) 属性に設定することができます。 あえて設定しなくても常にディスクがいっぱいになってないようにLRU（Least Recently Used）アルゴリズムによって古いコンテンツを自動的に削除します。 特に互換性に問題があるファイルシステムはありません。 したがって管理者は使い慣れたファイルシステムを使用してもパフォーマンスに大きな影響はありません。
注釈
v2.5.0からディスクなしで動作する Memory-Onlyモード がサポートされます。
メモリの制限¶
使用最大メモリとコンテンツの積載率を設定します。
# server.xml - <Server>
<Cache>
<SystemMemoryRatio>100</SystemMemoryRatio>
<ContentMemoryRatio>50</ContentMemoryRatio>
</Cache>
<SystemMemoryRatio> (デフォルト: 100%)システムメモリ中STONが使用可能な最大メモリを割合を設定します。 たとえば16GB装置では数値を50（％）に設定するとシステムメモリが8GBであるように動作します。 特に 第19章 File System などを介して他のプロセスと連動するときに便利です。
<ContentMemoryRatio> (デフォルト: 50%)STONはディスクからロードされたBodyデータをメモリに最大限Cachingしサービスの品質を向上させる。 サービス形態に応じてこの割合を調節して品質を最適化します。
ContentMemoryRatioを通じてメモリの割合を設定します。
例えばゲームのダウンロードのようなファイルの数は多くないがContentsサイズが大きいサービスの場合File I / O負荷が負担になる。 このような場合
<ContentMemoryRatio>を高めより多くのContentsデータがメモリに常駐するように設定するとサービスの品質を向上させることができます。
ContentMemoryRatioを上げるとI / Oが減少します。
その他のCaching設定¶
その他のCachingサービスの基盤動作を設定します。
# server.xml - <Server>
<Cache>
<Cleanup>
<Time>02:00</Time>
<Age>0</Age>
<EmptyFolder>delete</EmptyFolder>
</Cleanup>
<Listen>0.0.0.0</Listen>
<ConfigHistory>30</ConfigHistory>
</Cache>
<Cleanup>一日に一回システムの最適化を実行します。 最適化のほとんどはディスクのクリーンアップ操作でI / O負荷が発生します。 サービス品質の低下を最低限にするために最適化は少しずつ段階的に実行されます。
<Time> (デフォルト: AM 2)Cleanup実行時間を設定します。 午後11時10分を設定したい場合は23:10に設定します。<Age> (デフォルト: 0, 単位: 日)0よりも大きい場合には一定の期間一度もアクセスされていないコンテンツを削除します。 ディスクを事前に確保してサービス時間中のディスク不足が発生する確率を低減するためです。<EmptyFolder> (デフォルト: delete)Cleanup時点で空のフォルダ（キャッシュ保存用に使用）の削除有無を決定します。deleteの場合は削除しkeepの場合は削除しません。
<Listen>すべての仮想ホストがListenするIPのリストを指定します。 すべての仮想ホストのデフォルトListen設定の *：80は0.0.0.0:80を意味します。 指定されたIPだけ開きたい場合は次のように明確に設定します。
# server.xml - <Server> <Cache> <Listen>10.10.10.10</Listen> <Listen>10.10.10.11</Listen> <Listen>127.0.0.2</Listen> </Cache>
<ConfigHistory> (デフォルト: 30日)STONは設定が変更されるたびにすべての設定をバックアップします。 圧縮後./conf/に1つのファイルとして保存されます。 ファイル名は "日付_時刻_HASH.tgz" に生成されます。
20130910_174843_D62CA26F16FE7C66F81D215D8C52266AB70AA5C8.tgz
すべての設定が完全に同じであれば同じHASH値を持つ。 設定の復元 が呼び出される場合も新しい設定として保存されます。 バックアップされた設定はCleanup時間を基準に設定された日分だけ保存されます。 設定ファイルの保存の日の制限はありません。
強制Cleanup¶
API呼び出しにCleanupします。 <Age> をパラメータとして入力することができます。
http://127.0.0.1:10040/command/cleanup
http://127.0.0.1:10040/command/cleanup?age=10
<Age> が0であればディスクの空き容量が足りないと判断した場合にのみCleanupを実行します。
<Age> パラメータが0よりも大きい場合はその「日」に一度もアクセスされていないコンテンツを削除します。
仮想ホストの設定¶
管理者はそれぞれの仮想ホストを個別に設定することができます。 しかし仮想ホストを作成するたびに同じ設定を繰り返すことは非常に消耗です。 すべての仮想ホストは <VHostDefault> を継承します。
単一継承です。
www.example.comの場合は別途上書き（Overriding）した値がないためA = 1B = 2となる。 一方img.example.comはB = 3で上書きしたのでA = 1B = 3となる。 管理者は通常同じサービスの特性を持つサービスをしたサーバーにように構成します。 したがって継承は非常に効果的な方法です。
<VHostDefault> は機能別で囲まれた5つのサブタグを持つ。
# server.xml - <Server>
<VHostDefault>
<Options> ... </Options>
<OriginOptions> ... </OriginOptions>
<Media> ... </Media>
<Stats> ... </Stats>
<Log> ... </Log>
</VHostDefault>
例えば 第17章 メディア 機能は <Media> サブに設定する式です。
vhosts.xml仮想ホストの設定¶
実行可能ファイルと同じパスに存在するvhosts.xmlファイルを仮想ホストの設定ファイルとして認識します。 仮想ホストの数に制限はありません。
# vhosts.xml
<Vhosts>
<Vhost Status="Active" Name="www.example.com"> ... </Vhost>
<Vhost Status="Active" Name="img.example.com"> ... </Vhost>
<Vhost Status="Active" Name="vod.example.com"> ... </Vhost>
</Vhosts>
生成/破壊¶
<Vhosts> サブ <Vhost> で仮想ホストを設定します。
# vhosts.xml - <Vhosts>
<Vhost Status="Active" Name="www.example.com">
<Origin>
<Address>10.10.10.10</Address>
</Origin>
</Vhost>
<Vhost>バーチャルホストを設定します。Status (デフォルト: Active)Inactiveである場合はその仮想ホストはサービスしません。 キャッシュされたコンテンツは維持されます。Name仮想ホスト名。 重複することがない。
<Vhost> を削除するとその仮想ホストが削除されます。 削除された仮想ホストのすべてのコンテンツは削除対象となる。 再度追加してもコンテンツは甦るない。
検索¶
以下は最も単純な形式のHTTPリクエストです。
GET / HTTP/1.1
Host: www.example.com
一般的なWebサーバはHostヘッダに仮想ホストを探す。 一つの仮想ホストを複数の名前でサービスしたい場合は <Alias> を使用します。
# vhosts.xml - <Vhosts>
<Vhost Name="example.com">
<Alias>another.com</Alias>
<Alias>*.sub.example.com</Alias>
</Vhost>
<Alias>仮想ホストの別名を設定します。 数は制限がない。 明確な表現（another.com）とパターン表現(*.sub.example.com)をサポートします。 パターンは複雑な正規表現ではなくprefixに*表現を1つだけ付けることができる簡単な形式のみをサポートします。
仮想ホストの検索順序は次のとおりです。
<Vhost>のNameと一致するか？- 明示的な
<Alias>と一致するか？ - パターン
<Alias>を満足するか？
Default仮想ホスト¶
要求を処理する仮想ホストが見つからなかった場合は選択される仮想ホストを指定することができます。 リクエストを処理したくない場合は設定していてもよい。
# vhosts.xml
<Vhosts>
<Vhost Status="Active" Name="www.example.com"> ... </Vhost>
<Vhost Status="Active" Name="img.example.com"> ... </Vhost>
<Default>www.example.com</Default>
</Vhosts>
<Default>デフォルトの仮想ホスト名を設定します。 必ず
<Vhost>のName属性と同じ文字列に設定する必要があります。
サービスアドレス¶
サービスのアドレスを設定します。
# vhosts.xml - <Vhosts>
<Vhost Name="www.example.com">
<Listen>*:80</Listen>
</Vhost>
<Listen> (デフォルト: *:80){IP}：{Port}の形式でサービスのアドレスを設定します。 *:80 表現はすべてのNICからの80ポートに来る要求を処理するという意味だ。 たとえば特定のIP（1.1.1.1）の90ポートにサービスしたい場合は次のように設定します。
# vhosts.xml - <Vhosts> <Vhost Name="www.example.com"> <Listen>1.1.1.1:90</Listen> </Vhost>
仮想ホスト-例外条件 (.txt)¶
サービスの次のように例外的な状況が必要な時があります。
- すべてのPOSTリクエストは許可していませんが特定のURLへのPOSTリクエストは許可します。
- すべてのGETリクエストはSTONが応答するが特定のIP帯域についてはオリジンサーバーにバイパスします。
- 特定の国には伝送速度を制限します。
このような例外条件はXMLに設定しません。 すべての仮想ホストは独立した例外条件を有します。 例外条件は./svc/仮想ホスト/ディレクトリの下位にTXTに存在します。 関連の機能について説明すると例外条件も一緒に扱う。
仮想ホストのリストを確認¶
仮想ホストのリストを照会します。
http://127.0.0.1:10040/monitoring/vhostslist
結果はJSON形式で提供されます。
{
"version": "1.1.9",
"method": "vhostslist",
"status": "OK",
"result": [ "www.example.com","www.foobar.com", "site1.com" ]
}
設定を確認する¶
サービス中の設定ファイルを確認します。 txtファイルは仮想ホスト（vhost）を明確に指定する必要があります。
http://127.0.0.1:10040/conf/server.xml
http://127.0.0.1:10040/conf/vhosts.xml
http://127.0.0.1:10040/conf/querystring.txt?vhost=www.example.com
http://127.0.0.1:10040/conf/bypass.txt?vhost=www.example.com
http://127.0.0.1:10040/conf/ttl.txt?vhost=www.example.com
http://127.0.0.1:10040/conf/expires.txt?vhost=www.example.com
http://127.0.0.1:10040/conf/acl.txt?vhost=www.example.com
http://127.0.0.1:10040/conf/headers.txt?vhost=www.example.com
http://127.0.0.1:10040/conf/throttling.txt?vhost=www.example.com
http://127.0.0.1:10040/conf/postbody.txt?vhost=www.example.com
設定のリスト¶
バックアップされた設定のリストを閲覧します。
http://127.0.0.1:10040/conf/latest
http://127.0.0.1:10040/conf/history
結果はJSON形式で提供されます。 高速最後の設定状態のみを確認したい場合は/ conf / latestを使用することを推奨します。
{
"history" :
[
{
"id" : "5",
"conf-date" : "2013-11-06",
"conf-time" : "15:26:37",
"type" : "loaded",
"size" : "16368",
"hash" : "D62CA26F16FE7C66F81D215D8C52266AB70AA5C8",
"ver": "1.2.8"
},
{
"id" : "6",
"conf-date" : "2013-11-07",
"conf-time" : "07:02:21",
"type" : "modified",
"size" : "27544",
"hash" : "F81D215D8C52266AB70AA5C8D62CA26F16FE7C66",
"ver": "1.2.8"
}
]
}
id設定の一意のID（Reloadするたびに +1)conf-dateの設定変更日conf-timeの設定を変更時間typeの設定が反映された形 -loadedSTONが開始される -modified設定が（管理者またはWMによって）変更されたとき -uploaded設定ファイルAPIを介してアップロードされたとき -restored設定ファイルがAPIを介して復旧されたときsize設定ファイルサイズhash設定ファイルをSHA-1でhash値
設定の復元¶
hash値またはidに基づいて任意の時点の設定に戻す。 hashとidの両方が記載されている場合hash値が優先されます。 正常Rollbackされた場合200 OK失敗した場合500 Internal Errorで応答します。
http://127.0.0.1:10040/conf/restore?hash=...
http://127.0.0.1:10040/conf/restore?id=...
設定のダウンロード¶
hash値またはidに基づいて任意の時点の設定をダウンロードします。 Content-Typeは "application / x-compressed" に指定されます。 hashとidの両方が記載されている場合hash値が優先されその時点の設定が存在しない場合404 NOT FOUNDに応答します。
http://127.0.0.1:10040/conf/download?hash=...
http://127.0.0.1:10040/conf/download?id=...
設定アップロード¶
APIを利用して設定を変更します。 正常反映場合200 OKで応答するが失敗した場合500 Internal Server Errorで応答します。
{
"version": "2.5.10",
"method": "uploadconfig",
"status": "Fail",
"result": "E0001"
}
"result" エラーコードは次のとおりです。
| result | 説明 |
|---|---|
| E0000 | 設定を適用完了 |
| E0001 | アップロードしたファイルが存在しません。 |
| E0002 | tgzファイルを圧縮解除に失敗しました。 |
| E0003 | アップロードされたxmlファイルがロードされない。 |
| E0004 | アップロードされたxmlファイルの内容が間違っていた。 |
全体の設定アップロード¶
全体の設定圧縮ファイルをHTTP Post方式（Multipartサポート）にアップロードします。
http://127.0.0.1:10040/conf/upload
次のように住所 Content-Length, Content-Type(="multipart/form-data")が明確に宣言されてなければならない。
POST /conf/upload
Content-Length: 16455
Content-Type: multipart/form-data; boundary=......
アップロードが完了すると圧縮を解除した後全体の設定を更新します。
Multipart方式では "confile"をデフォルト名として使用します。 この値は、 <Manager> の UploadMultipartName 属性で設定することができます。
<form enctype="multipart/form-data" action="http://127.0.0.1:10040/conf/upload" method="POST">
<input name="confile" type="file" />
<input type="submit" value="Upload" />
</form>
XML設定アップロード¶
XML個々の設定圧縮ファイルをHTTP Post方式（MultipartとSOAP方式の両方をサポート）にアップロードします。
http://127.0.0.1:10040/conf/upload/server.xml
http://127.0.0.1:10040/conf/upload/vhosts.xml
注釈
server.xmlをアップロードする場合は全体の設定を更新しますがvhosts.xmlのみアップロードする場合は仮想ホストにのみ設定を更新します。
2部。 HTTPサービス¶
第4章 Cachingポリシー¶
この章ではサービスの中核となるTTL（Time To Live）Caching-Keyと有効期限ポリシーについて説明します。 保存されたコンテンツはTTLの期間内に有効です。 HTTPの仕様はTTLを設定できるようにCache-Controlを明示しています。 しかしこれは絶対的なものではないです。 様々な方式のTTLポリシーと 第5章 Caching削除 を介してサービスの質を向上させることができます。
HTTPはコンテンツを区別する様々な規格が存在します。 それほどCaching-Keyも多様に存在することができます。 コンテンツの変更がないほど元の負荷を軽減することができるだけでなく簡単に拡張することができます。 サービスに最適化された有効期限ポリシーを策定する多様な方法について説明します。
これから説明される設定をすべての仮想ホストのデフォルト設定に適用したい場合は <VHostDefault> タグの下位に設定します。 反対に特定の仮想ホストにのみ適用さしたい場合は<Vhost>タグの下位に設定します。
Caching-Key はコンテンツを分離するユニークな値です。 ファイルシステム上のファイルと区別される固有のパス（例/usr/conf.txt）を持つのと同じ概念です。 Caching-Key はURLと混同されやすいです。 HTTPの複数の機能に応じて同じURLであってもコンテンツが変わることがあります。
TTL (Time To Live)¶
TTLは保存されたコンテンツの有効時間です。 TTLを長く設定するとオリジンサーバーの負荷は減りますが変更が遅れて反映されます。 反対に短く設定するとあまりにも頻繁な変更の確認要求にオリジンサーバーの負荷が高くなります。 運営の醍醐味はTTLを適切に設定して元の負荷を減らすことにあります。 TTLは一度設定されると有効期限が切れるまで変わらない。 新しいTTLはファイルの期限が切れるときに適用されます。 管理者は Purge , Expire , ExpireAfter , HardPurge などのAPIを使用してTTLを変更することができます。
デフォルトTTL¶
デフォルト的にはTTLはオリジンサーバーの応答に基づいて決定されます。 TTLが期限切れになるまで保存されたコンテンツにサービスされます。 TTLが期限切れになるとオリジンサーバーにコンテンツの変更有無( If-Modified-Since または If-None-Match )を確認します。 オリジンサーバーから 304 Not Modified 応答をくる場合TTLは延長されます。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<TTL>
<Res2xx Ratio="20" Max="86400">1800</Res2xx>
<NoCache Ratio="0" Max="5" MaxAge="0">5</NoCache>
<Res3xx>300</Res3xx>
<Res4xx>30</Res4xx>
<Res5xx>30</Res5xx>
<ConnectTimeout>3</ConnectTimeout>
<ReceiveTimeout>3</ReceiveTimeout>
<OriginBusy>3</OriginBusy>
</TTL>
Ratio （0〜100）を除くすべての設定単位は秒（sec）です。
<Res2xx> (デフォルト: 1800秒, Ratio: 20, Max=86400)オリジンサーバーが200 OKで応答したときTTLを設定します。 コンテンツを最初に保存するときに<Res2xx>秒後のコンテンツの期限が切れ（TTL）されるように設定します。 （TTL満了後）オリジンサーバーから変更されていない場合（304 Not Modified）Ratio比率（0〜100）だけTTLを延長します。 TTLは最大Maxまで増加します。<NoCache> (デフォルト: 5秒, Ratio: 0, Max=5, MaxAge=0)<Res2xx>と同じかオリジンサーバーがno-cacheに応答する場合にのみ適用されます。cache-control: no-cache または private または must-revalidate
MaxAgeが0より大きければmax-ageを与えることができます。
Max-AgeだけクライアントにCachingされる。
<Res3xx> (デフォルト: 300秒)オリジンサーバーが3xxで応答したときのTTLを設定します。 Redirect用途に使用されている場合が多い。<Res4xx> (デフォルト: 30秒)オリジンサーバーが4xxに応答したときのTTLを設定します。 404 Not Found の場合が多い。<Res5xx> (デフォルト: 30秒)オリジンサーバーが5xxに応答したときのTTLを設定します。 オリジンサーバーの内部障害状況である場合が多い。<ConnectTimeout> (デフォルト: 3秒)オリジンサーバーに接続できない場合のTTLを設定します。 コンテンツが既に保存されている場合は<ConnectTimeout>秒だけTTLを延長します。 コンテンツが保存されていない場合は<ConnectTimeout>秒ほどの障害状況に応答します。 これは障害の状況をサービスするという意味ではなくTTL時間（おそらく障害状況日）オリジンサーバーに負担をかけないため。<ReceiveTimeout> (デフォルト: 3秒)接続はされたがデータを受信していない場合のTTLを設定します。<ConnectTimeout>と意味的同じ。<OriginBusy> (デフォルト: 3秒)過負荷判断 条件を満たした場合オリジンサーバーへの要求なしで有効期限が切れたコンテンツのTTLを設定した分延長します。 これはオリジンサーバーの負荷を加重させないため。
注釈
TTL値を0に設定するとサービスの直後すぐに切れます。 もしすべてのリクエストに対してオリジンサーバーの応答を与える必要がある場合バイパスすることを推奨します。
Custom TTL¶
URLごとに個別にTTLを設定します。 明確なURLまたはパターンのURLマッチングされるコンテンツごとに固定されたTTLを設定することができます。 / svc / {仮想ホスト名} /ttl.txtに設定します。
# /svc/www.example.com/ttl.txt
# 区切り文字はカンマ（、）であり時間の単位は秒です。
*.jsp, 10
/,5
/index.html, 5
/script/*.js, 300
/image/ad.jpg, 1800
すべてのページ（htmlphpjspなど）に別途のTTLを設定するために* .htmlを追加しても初のページ（/）は設定されない。 オリジンサーバーが最初のページをどのページ（例えばindex.phpにdefault.jspなど）に設定したのかHTTPプロトコルでは知ることができない。 したがってすべてのページに個別のTTLを設定するためには/を追加する必要があります。
TTLの優先順位¶
適用するTTL設定の優先順位を設定します。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<TTL Priority="cc_nocache, custom, cc_maxage, rescode">
... (省略) ...
</TTL>
<TTL> の Priority (デフォルト: cc_nocache, custom, cc_maxage, rescode) 属性に設定します。
cc_nocacheオリジンサーバーがCache-Control：no-cacheに応答した場合customcaching-policy-customttlcc_maxageオリジンサーバーがCache-Controlにmaxageを明示した場合rescode元応答コード別デフォルトのTTL
異常TTL延長¶
オリジンサーバーのシャットダウンのための応答が来ない場合には障害の判断が明確であるがたまに正常に応答し障害の状況である場合が発生します。 たとえばコンテンツを保存するStorageとのアクセスを失うか通常の処理が不可能であると判断する場合があります。 前者の場合4xx応答（主に 404 Not Found ), 後者は5xx応答（主に 500 Internal Error )を受けることになる。
しかしすでに関連するコンテンツが保存されている場合はテキストの応答を信じることよりもTTLを延長させてサービス全体に障害が発生しないようにしたほうが効果的です。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<TTLExtensionBy4xx>OFF</TTLExtensionBy4xx>
<TTLExtensionBy5xx>ON</TTLExtensionBy5xx>
<TTLExtensionBy4xx>OFF (デフォルト)4xx応答としてコンテンツを更新します。ON304 not modifiedを受けたかのように動作します。
意図された4xx応答がないか注意する必要があります。
<TTLExtensionBy5xx>ON (デフォルト)304 Not Modified を受けたかのように動作します。OFF5xx応答でコンテンツを更新します。
通常のサーバーであれば5xxで応答しません。 主にサーバーの一時的な障害からのコンテンツを削除して元の負荷を加重させないための用途に使用されます。
更新不可時のポリシー¶
コンテンツのTTLは有効期限が切れましたがオリジンサーバーがすべて排除されて正常にコンテンツを更新（Revalidate）することができないときのポリシーを設定します。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<UnvalidatableObjectResCode>0</UnvalidatableObjectResCode>
<UnvalidatableObjectResCode>0 (デフォルト)有効期限が切れたコンテンツのTTLを<ConnectTimeout>だけ延長します。HTTP 応答コード更新することができない場合は設定された応答コードで応答します。
例えば次のように設定されている場合はコンテンツを更新することができないとき有効期限が切れたコンテンツを404 Not Foundで応答します。
<UnvalidatableObjectResCode>404</UnvalidatableObjectResCode>
更新ポリシー¶
TTL期限切れのコンテンツの場合オリジンサーバーの更新有無を確認した後サービスが行われます。
変更の確認後応答
- TTLが有効であります。 即座に応答します。
- TTLが期限切れになってオリジンサーバーに変更を確認（If-Modified-Since）を要請します。 変更の確認がされるまでクライアントに応答しません。
- オリジンサーバーからの応答があるばあいTTLを延長まやはコンテンツを変更（Swap）します。 オリジンサーバーで確認がされたのでクライアントに応答します。
- 変更の確認がされたコンテンツであるため次のTTL満了時まで即座に応答します。
高画質動画やゲームのような比較的反応性よりも転送速度が重要なサービスではこの方法が大きな問題にならない。 大容量データの場合はオリジンサーバーが10秒で更新の応答をしても送信に数分かかるので比較的オリジンサーバーの反応性が大きく重要ではありません。 むしろアクセス頻度が高くないコンテンツであるため必ず更新確認を行なう必要があります。
しかしショッピングモールのようなサービスの場合、状況は異なります。 Webページはすぐにロードされていることが何よりも重要であります。 1〜2秒以内にクライアントの画面表示が完了される必要があります。 転送速度よりも反応速度がより重要になります。
この時TTLが期限切れになってオリジンサーバーに更新を確認すると非常に大きな遅延が発生します。 通常のショッピングモールが数百万個のコンテンツを同時にサービスすることを考えるといつもオリジンサーバーからの更新確認作業が発生していると考えなければならない。 もしオリジンサーバーに障害が発生したりネットワーク障害が発生した場合大きな問題になります。
サービス提供側の要望はオリジンサーバーの障害や遅延からキャッシュされたコンテンツが安全に配信されることです。
障害怖くない！
そのためバックグラウンドコンテンツ更新機能が開発されました。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<RefreshExpired>ON</RefreshExpired>
<RefreshExpired>ON (デフォルト)変更の確認後に応答します。OFF変更の確認応答を待たずに応答します。 新しいコンテンツのダウンロード`後変更（Swap）します。
OFF 設定のより大きな理由はコンテンツがほとんど変更頻度ないからだ。
変更に敏感でない場合は待機しません。
上の図ではオリジンサーバーとの更新作業がすべてバックグラウンドで行われるためキャッシュされたコンテンツは待機せずにすぐにクライアントにサービスされます。 オリジンサーバーが 304 Not Modified に応答する場合TTLだけ延長されます。 ファイルが更新されオリジンサーバーから200 OKを応答した場合はそのファイルが完全にダウンロードされた後にファイルがスムーズに切り替えられる。 コンテンツが変わっても以前のコンテンツ（緑）をダウンロード受けたユーザーは通常のダウンロードが行われる。 ファイル交換後のアクセスされたユーザー（からし色）は変更したファイルにサービスされます。 コンテンツの更新ネットワーク障害オリジンサーバー障害など何らかの変数もコンテンツ更新はバックグラウンドで行われるため実際のサービスには全く遅れがない。
クライアントno-cacheリクエストTTLの有効期限¶
クライアントのHTTP要求にno-cacheの設定が複数記載されている場合そのコンテンツをすぐに期限切れにさせることができます。
GET /logo.jpg HTTP/1.1
...
cache-control: no-cache または cache-control:max-age=0
pragma: no-cache
...
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<NoCacheRequestExpire>OFF</NoCacheRequestExpire>
<NoCacheRequestExpire>OFF (デフォルト)は無視します。ONTTLをすぐに満了します。
有効期限が切れたコンテンツは 更新ポリシー に従う。
Accept-Encodingヘッダ¶
同じURLへのHTTP要求であってもAccept-Encodingヘッダの存在の有無に応じて他のコンテンツがキャッシュされることができます。 オリジンサーバーに要求を送信する時に圧縮有無を知ることができない。 応答を受けたとしても圧縮有無を毎回比較することもない。
オリジンサーバーがどんな答えを与える知ることができない。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<AcceptEncoding>ON</AcceptEncoding>
<AcceptEncoding>ON (デフォルト)HTTPクライアントが送信するAccept-Encodingヘッダを認識します。OFFHTTPクライアントが送信しAccept-Encodingヘッダを無視します。
オリジンサーバーで圧縮をサポートしていないかまたは圧縮が必要な大容量ファイルの場合 OFF に設定することが望ましい。
大文字と小文字の区別¶
オリジンサーバー上のコンテンツの大文字と小文字の識別ができない。
おそらくそのようなコンテンツであるか404が発生します。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<CaseSensitive>ON</CaseSensitive>
<CaseSensitive>ON (デフォルト)URL大文字と小文字を構文であります。OFFURL大文字と小文字を区別しません。 すべて小文字で処理されます。
QueryString区分¶
QueryStringによって動的に生成されたコンテンツではない場合はQueryStringを認識する必要はありません。 何の意味のないRandom値や常に変化するtimestampの値が毎回付く場合オリジンサーバーに多大な負荷が発生する恐れがあります。
動的なコンテンツがない場合は同じコンテンツである可能性が高い。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<ApplyQueryString Collective="OFF">ON</ApplyQueryString>
<ApplyQueryString>ON (デフォルト)QueryStringを認識します。 例外条件に満足するQueryStringが無視されます。OFFQueryStringを無視します。 例外条件に満足するQueryStringを認識します。
QueryString-例外条件は/ svc / {仮想ホスト名} /querystring.txtに設定します。
# ./svc/www.example.com/querystring.txt
/private/personal.jsp?login=ok*
/image/ad.jpg
例外条件が <ApplyQueryString> の設定に応じ意味が異なることに注意する必要があります。 明確なURLまたはパターン（ *のみを可能にする）に設定が可能であります。
Collective 属性は Purge APIが呼び出されたときにターゲットを指定します。
CollectiveOFF (デフォルト)パラメータURLのみを対象とします。ONパラメータURLだけでなくURLのQueryStringが存在するすべてのコンテンツを対象に指定します。
Collective 属性がONでありファイルが多ければ多いほど Purge API実行CPU負荷が高くなる。 関連ファイルを検索する時間が長くなることがあり予期しない問題が発生することができます。 なるべくQueryStringまでついた明確なURLに Purge APIを呼び出すことをお勧めします。
Varyヘッダ¶
Varyヘッダを認識してコンテンツを区分します。 一般的にVaryヘッダはCacheサーバーのパフォーマンスを大幅に落とす原因になります。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<VaryHeader />
<VaryHeader>オリジンサーバーが応答したVaryヘッダのサポートヘッダーのリストを設定します。 区切り文字はカンマ（、）を使用します。
たとえばオリジンサーバーが次のようにVaryヘッダを送ったとしても <VaryHeader> が設定されていない場合は無視します。
Vary: Accept-Encoding, Accept, User-Agent
User-Agentを除くAccept-EncodingとAcceptヘッダのみを認識するようにするには次のように設定します。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<VaryHeader>Accept-Encoding, Accept</VaryHeader>
オリジンサーバーが送信したすべてのVaryヘッダを認識するようにするには次のように設定します。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<VaryHeader>*</VaryHeader>
POSTリクエストのキャッシュ¶
POSTリクエストをCachingするように設定します。 POSTリクエストの特性上URLは同じですがBodyデータが異なる場合があります。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<PostRequest MaxContentLength="102400" BodySensitive="ON">OFF</PostRequest>
<PostRequest>OFF (デフォルト)POSTリクエストが来ればセッションを終了します。ONPOSTリクエストをCachingします。
実際にPOSTリクエストを処理するほとんどの場合はBodyデータをCaching-Keyとして使用します。
BodySensitive 属性と例外条件を使用して洗練された設定が可能であります。
BodySensitiveON (デフォルト)BodyデータまでCaching-Keyとして認識します。 最大の長さはMaxContentLength (デフォルト: 102400 Bytes)属性に制限します。 例外条件に満足するBodyデータを無視します。OFFBodyデータは無視します。 例外条件に満足するBodyデータを認識します。
POSTリクエストの例外条件は/ svc / {仮想ホスト名} /postbody.txtに設定します。
# /svc/www.example.com/postbody.txt
/bigsale/*.php?nocache=*
/goods/search.php
例外条件が BodySensitive 設定に応じて意味が異なることに注意する必要があります。 明確なURLまたはパターン（ *のみを許可します。）に設定が可能であります。
この設定は GET / POSTバイパス とポリシー的に混乱になる可能性があります。
<BypassPostRequest> (デフォルト: ON) によりPOSTリクエストがキャッシュされないことがあります。 したがってPOSTリクエストをキャッシュするためには <BypassPostRequest> を OFF または例外条件を設定する必要があります。 整理すると優先順位は次の通りであります。
- バイパス条件( GET / POSTバイパス )に満足した場合オリジンサーバーにバイパスします。
- Content-Lengthヘッダがない場合は接続を終了します。
PostRequestがONに設定されてContent-LengthがMaxContentLength属性値を超えなければキャッシュモジュールによって処理されます。- 以上のシナリオでは未処理の要求は終了します。
注釈
MaxContentLength 属性をも大きく設定した場合Caching-Key管理に多くのメモリが必要になります。可能な限り小さく設定するのが良い。
第5章 Caching削除¶
この章ではCachingされたコンテンツを削除する方法について説明します。 業界用語でPurgeで通称が様々な状況や環境により細分化されたAPIが必要です。
オリジンサーバーからキャッシュされたコンテンツは TTL (Time To Live) に基づい更新周期を持つ。 しかし明らかに内容が変更され管理者がこれをすぐに反映したい場合 TTL (Time To Live) が期限切れになるまで待つ必要はありません。 Purge / Expire / HardPurge などを使用するとすぐにコンテンツを削除させることができます。
削除APIは単にブラウザによって呼び出される場合もあるが自動化されている場合が多い。 例えばFTP経由でファイルのアップロードが完了したらすぐに Purge を呼び出す方法もあります。 管理者は次のようにいくつかの動作を設定することができます。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<Purge2Expire>NONE</Purge2Expire>
<RootPurgeExpire>ON</RootPurgeExpire>
<ResCodeNoCtrlTarget>200</ResCodeNoCtrlTarget>
<Purge2Expire> (デフォルト: NONE)Purge 要求を設定に応じて Expire で処理します。 たとえば特定のパターン(*.jpg)を Purge する場合意図せず多くのコンテンツが削除されソースに過度な負荷を発生する場合があります。 このような場合 Expire に処理するように設定すると過剰なオリジンサーバーの負荷を防止することができます。
<RootPurgeExpire> (デフォルト: ON)全体のコンテンツへの意図しない Purge / Expire は過度のオリジンサーバーの負荷を発生させることができます。 この設定を介してすべてのコンテンツの Purge / Expire を遮断することができます。 この設定は
<Purge2Expire>よりも優先します。<ResCodeNoCtrlTarget> (デフォルト: 200)Purge , Expire , HardPurge , ExpireAfter の対象オブジェクトが存在しないときのHTTP応答コードを設定します。
ターゲット設定はURLとパターンの2つの方法で表現します。
example.com/logo.jpg // URL
example.com/img/ // URL
example.com/img/*.jpg // パターン
example.com/img/* // パターン
明確なURLのほかのパターン(*.jpg)でも削除が可能です。 しかし作業を実行するまでターゲットコンテンツの数を明確に把握できない。 これは管理者の意図とは違い多くの対象が指定される可能性があり実際にCPUリソースをあまり消費することになりシステム全体に負担を与えることがなる可能性があります。
したがって実サービスの中には明確なURLだけを設定することを強く推奨します。 パターン表現はサービスから排除された状態で管理目的で使用するためです。
注釈
セキュリティ上の理由からexample.com/files/などの特定のディレクトリへのアクセスは403 FORBIDDENなどで遮断されます。 しかしルートディレクトリは例外を持つ。 たとえばユーザーがexample.comにアクセスするとブラウザはルートディレクトリ（/）を要請します。
GET / HTTP/1.1
Host: example.com
これに対してWebサーバーは管理者が設定したデフォルトのページ（おそらくindex.htmlまたはindex.htm）で応答します。 明らかにWebサービスの構成ではルートディレクトリ（/）はディレクトリではなくページで動作します。
しかしCacheサーバーはルートディレクトリ（/）にアクセスしたところ200 OKのページが来た理解します。 さらにオリジンサーバーがどのページを応答した知らない。 簡単に整理するとCacheサーバーの観点ではディレクトリ表現もURLの一種に過ぎない。
example.com/img/ // example.com 仮想ホストの / img / に アクセスした 結果 のページ
example.com/ // example.com の仮想ホストの デフォルト ページ （/）
example.com/img/* // example.com 仮想ホストの / img ディレクトリと その サブ ページ
example.com/* // example.com 仮想ホストの すべての コンテンツ
Purge¶
ターゲットコンテンツを無効にさせてオリジンサーバーからコンテンツを再ダウンロード受けるようにします。 Purge後最初のアクセス時にオリジンサーバーからコンテンツを再キャッシュします。 もしオリジンサーバーに障害が発生してコンテンツを取得することができない場合は削除されコンテンツを復元させてサービスに障害がないように処理します。 このように復元されたコンテンツはその時点からConnectTimeout設定だけ後ろに更新します。
http://127.0.0.1:10040/command/purge?url=...
ターゲットコンテンツはURLはパターンとして指定することができるだけでなく "|"（Vertical Bar）を区切り文字を使用して複数のドメインに複数のターゲットを指定することができます。 もしドメイン名が省略された場合最近使用されたドメインを使用します。
http://127.0.0.1:10040/command/purge?url=http://www.site1.com/image.jpg
http://127.0.0.1:10040/command/purge?url=www.site1.com/image.jpg
http://127.0.0.1:10040/command/purge?url=www.site1.com/image/bmp/
http://127.0.0.1:10040/command/purge?url=www.site1.com/image/*.bmp
http://127.0.0.1:10040/command/purge?url=www.site1.com/image1.jpg|/css/style.css|/script.js
http://127.0.0.1:10040/command/purge?url=www.site1.com/image1.jpg|www.site2.com/page/*.html
結果はJSON形式で提供されます。 ターゲットコンテンツ数/容量と処理時間（単位：ms）が指定されます。 すでにPurgeされたコンテンツは再びPurgeされない。
{
"version": "2.0.0",
"method": "purge",
"status": "OK",
"result": { "Count": 24, "Size": 3747491, "Time": 12 }
}
<Purge2Expire> を介して特定の条件のPurgeをExpireで動作するように設定することができます。 結果のない応答には <ResCodeNoCtrlTarget> でHTTP応答コードを設定することができます。
注釈
オリジンサーバーが障害のためにすべて排除された場合コンテンツを更新することができないためPurgeが動作しません。
Expire¶
ターゲットコンテンツのTTLをすぐに期限切れにせる。 Expire後最初のアクセス時にオリジンサーバーから変更有無を確認します。 変更されていない場合TTL延長があるだけコンテンツのダウンロードは発生しない。
http://127.0.0.1:10040/command/expire?url=...
その他のすべての動作は Purge とと同じです。
ExpireAfter¶
ターゲットコンテンツのTTL有効期限を現在の（API呼び出し時点）から入力された時間（秒）だけ後ろに設定します。 ExpireAfterに有効期限を繰り上げてコンテンツをより迅速に更新したり反対に有効期限を増やしオリジンサーバーの負荷を軽減することができます。
http://127.0.0.1:10040/command/expireafter?sec=86400&url=...
関数呼び出しの仕様は Purge / Expire と似ているがsecパラメータ（単位：秒）を使用してTTLの有効期限を指定することができます。 secが省略場合デフォルト値は1日（86400秒）に設定され0を入力した場合に失敗します。 結果は Purge / Expire と同じですがオリジンサーバーの障害の有無にかかわらず動作します。 結果のない応答には <ResCodeNoCtrlTarget> でHTTP応答コードを設定することができます。
注釈
ExpireAfterはキャッシュされているコンテンツの現在の有効期限だけを設定するだけでカスタムTTLや設定されたデフォルトのTTLを変更させるAPIではない。 ExpireAfter呼び出しの後キャッシュされたコンテンツは影響を受けない。
urlパラメータを先に入力した場合secパラメータがurlパラメータのQueryStringとして認識されることができます。 したがってsecパラメータが最初に入力されていることが安全です。
HardPurge¶
Purge / Expire / ExpireAfter 以上のAPIはオリジンサーバーの障害状況でもコンテンツが消えずに正常に動作します。 しかしHardPurgeはコンテンツの完全な削除を意味します。 HardPurgeは最も強力な削除方法が削除されたコンテンツはオリジンサーバーに障害が発生しても復帰できない。 結果のない応答には <ResCodeNoCtrlTarget> でHTTP応答コードを設定することができます。
http://127.0.0.1:10040/command/hardpurge?url=...
Purgeのデフォルトの動作¶
Purge APIが呼び出されるとコンテンツの復旧有無を選択します。
# server.xml - <Server><Cache>
<Purge>Normal</Purge>
HTTP Method¶
削除APIを拡張HTTP Methodで呼び出すことができます。
PURGE /sample.dat HTTP/1.1
host: ston.winesoft.co.kr
HTTP Methodはデフォルト的にManagerのポートとサービス（80）ポートで動作します。 サービスポートに要求されるHTTP Methodの 管理者の設定 で設定します。
POST規格¶
削除APIを次のようにPOSTで呼び出すことができます。
POST /command/purge HTTP/1.1
Content-Length: 37
url=http://ston.winesoft.co.kr/sample.dat
第6章 HTTPリクエスト/レスポンス¶
この章では、HTTPクライアントセッションと要求を処理する方法について説明する。 サービスの主な機能として見るには難しい内容が多いので、頭が痛い必要はない。 一部のHTTPの理解がなければ、難しいことができる部分があるが、このような場合は、デフォルトの設定を使用してほしい。 全体的にデフォルトの設定をそのまま使用してもサービスには全く支障がない内容だ。
セッション管理¶
HTTPクライアントがサーバー（STON）に接続すると、HTTPセッションが生成される。 クライアントは、HTTPセッションを介してサーバーに格納された複数のコンテンツをサービス受ける。 リクエストからレスポンスまでを一つの HTTPトランザクション と呼ぶ。 HTTPセッションは、複数のHTTPトランザクションを順次処理する。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<ConnectionHeader>keep-alive</ConnectionHeader>
<ClientKeepAliveSec>10</ClientKeepAliveSec>
<KeepAliveHeader Max="0">ON</KeepAliveHeader>
<ConnectionHeader> (デフォルト: keep-alive)クライアントに送信するHTTPレスポンスのConnectionヘッダ(keep-aliveまたはclose)を設定する。<ClientKeepAliveSec> (デフォルト: 10秒)クライアントセッションとは何の通信がない状態で設定された時間が経過すると、セッションを終了する。 時間を長すぎる設定すると、通信をしていないセッションが過度に多くなる。 あまりにも多くのセッションを維持するだけでも、システムは負荷となる。<KeepAliveHeader>ON (デフォルト)HTTP応答にKeep-Aliveヘッダを明示する。Max (デフォルト: 0)を0より大きく設定すると、Keep-Aliveヘッダの値にMax値が設定される。 以後HTTPトランザクションが発生するたびに1ずつ減算される。OFFHTTP応答にKeep-Aliveヘッダを省略する。
HTTPセッションを維持ポリシー¶
STONはなるべくApacheのポリシーに従う。 特にセッション維持ポリシーは、HTTPヘッダーの値に応じた変数が多い。 HTTPセッションを維持政策に影響を与える要素は次のとおりです。
- クライアントのHTTP要求に指定されたConnectionヘッダ（"Keep-Alive" または "Close"）
- 仮想ホスト
<Connection>設定 - 仮想ホストセッションKeep-Alive時間設定
- 仮想ホスト
<Keep-Alive>設定
クライアントのHTTP要求に "Connection: Close" に設定されている場合
GET / HTTP/1.1 ...(省略)... Connection: Close
このようなHTTPリクエストには、仮想ホストの設定の有無にかかわらず、 "Connection: Close" で応答する。 Keep-Aliveヘッダは設定されない。
HTTP/1.1 200 OK ...(省略)... Connection: Close
このHTTPトランザクションが完了すると、HTTP接続を終了する。
<ConnectionHeader>がCloseに設定された場合# server.xml - <Server><VHostDefault><Options> # vhosts.xml - <Vhosts><Vhost><Options> <ConnectionHeader>Close</ConnectionHeader>
クライアントのHTTP要求とは関係なく、 "Connection: Close" で応答する。 Keep-Aliveヘッダは設定されない。
HTTP/1.1 200 OK ...(省略)... Connection: Close
<KeepAliveHeader>がOFFに設定された場合# server.xml - <Server><VHostDefault><Options> # vhosts.xml - <Vhosts><Vhost><Options> <ConnectionHeader>Keep-Alive</ConnectionHeader> <KeepAliveHeader>OFF</KeepAliveHeader>
Keep-Aliveヘッダが設定されない。 HTTPセッションは、継続的に再利用可能です。
HTTP/1.1 200 OK ...(省略)... Connection: Keep-Alive
<KeepAliveHeader>がONに設定された場合# server.xml - <Server><VHostDefault><Options> # vhosts.xml - <Vhosts><Vhost><Options> <ConnectionHeader>Keep-Alive</ConnectionHeader> <ClientKeepAliveSec>10</ClientKeepAliveSec> <KeepAliveHeader>ON</KeepAliveHeader>
Keep-Aliveヘッダが設定される。 timeout値は、セッションKeep-Alive時間設定を使用する。
HTTP/1.1 200 OK ...(省略)... Connection: Keep-Alive Keep-Alive: timeout=10
注釈
<
<Keep-Alive>と<ClientKeepAliveSec>の関係 ><Keep-Alive>設定時<ClientKeepAliveSec>を参照してますが、<ClientKeepAliveSec>は、より根本的な問題と関連がある。 性能や資源的に最も重要な問題は、Idleセッション（= HTTPトランザクションが発生していないセッション）のまとめ視点をとるものです。 HTTPヘッダの設定は動的に変更されたり、時には省略されることがありますがIdleセッションクリーンアップは、はるかに敏感な問題です。 このような理由のために<ClientKeepAliveSec>は<KeepAliveHeader>に統合されず、別途存在する。<KeepAliveHeader>のMax属性が設定されている場合# server.xml - <Server><VHostDefault><Options> # vhosts.xml - <Vhosts><Vhost><Options> <ConnectionHeader>Keep-Alive</ConnectionHeader> <ClientKeepAliveSec>10</ClientKeepAliveSec> <KeepAliveHeader Max="50">ON</KeepAliveHeader>
Keep-Aliveヘッダにmax値を指定する。 このセッションではmax回使用可能であり、HTTPトランザクションが進むたびに1ずつ減少される。
HTTP/1.1 200 OK ...(省略)... Connection: Keep-Alive Keep-Alive: timeout=10, max=50
Keep-Aliveのmaxが満了した場合、
上記の設定どおりmaxが設定された場合maxは徐々に減少次のように1まで到達することになる。
HTTP/1.1 200 OK ...(省略)... Connection: Keep-Alive Keep-Alive: timeout=10, max=1
この応答は、現在のセッションで、今後1回のHTTPトランザクションの進行が可能である意味です。 このセッションでHTTP要求がもう一度行われる場合は、次のように "Connection: Close"で応答する。
HTTP/1.1 200 OK ...(省略)... Connection: Close
クライアントCache-Control¶
クライアントCache-Controlに関連する設定を説明します。
Ageヘッダ¶
Ageヘッダは、キャッシュされた瞬間からの経過時間（秒）を意味し、 RFC2616 - 13.2.3 Age Calculations によって計算される。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<AgeHeader>OFF</AgeHeader>
<AgeHeader>OFF (デフォルト)Ageヘッダを省略する。ONAgeヘッダを設定する。
Expiresヘッダ¶
Expiresヘッダを再設定する。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<RefreshExpiresHeader Base="Access">OFF</RefreshExpiresHeader>
<RefreshExpiresHeader>OFF (デフォルト)オリジンサーバーからの応答したExpiresヘッダをクライアントに指定する。 オリジンサーバーでExpiresヘッダが省略された場合、クライアントの応答もExpiresヘッダが省略される。ONExpires条件を反映してExpiresヘッダを明示する。 条件に該当しないコンテンツは、OFFの設定と同じように動作する。
Expires条件は、Apacheの mod_expires と同じように動作する。 特定の条件（URLやMIME Type）に対応するコンテンツのExpiresヘッダとCache-Controlの値を設定することができる。 Cache-Controlのmax-ageの値は設定されたExpires時間で要求された時間を引いた値になる。
Expires条件は/svc/ {仮想ホスト名} /expires.txtに設定する。
# /svc/www.exmaple.com/expires.txt
# 区切り文字はカンマ（、）であり、{条件}、{時間}、{基準}順に表記する。
$URL[/test.jpg], 86400
/test.jpg, 86400
*, 86400, access
/test/1.gif, 60 sec
/test/*.dat, 30 min, modification
$MIME[application/shockwave], 1 years
$MIME[application/octet-stream], 7 weeks, modification
$MIME[image/gif], 3600, modification
条件
URLとMIME Typeの2つに設定が可能です。 URLの場合、$ URL […]で、MIME Typeの場合$ MIME[…]と表記する。 パターン表現が可能であり、$表現が省略された場合は、URLとして認識する。
時間
Expires有効期限を設定する。 時間単位の表現をサポートし単位を設定しない場合秒として計算される。
基準
Expiresの有効期限の基準時点を設定する。 別途基準時点を指定しなければAccessが基準時点として設定される。 Accessは、現在の時刻を基準とする。 次は、MIME Typeがimage / gifのファイルへのアクセス時間から1日12時間後にExpiresヘッダの値を設定する例です。
$MIME[image/gif], 1 day 12 hours, access
Modificationは、オリジンサーバーから送信されたLast-Modifiedを基準とする。 以下はすべてのjpgファイルに対してLast-Modifiedから30分後にExpires値に設定する例です。
*.jpg, 30min, modification
Modificationの場合は、計算されたExpires値が現在の時間よりも過去の時間である場合、現在の時刻を指定する。 もしオリジンサーバーで、Last-Modifiedヘッダを提供しない場合Expiresヘッダを送信しません。
ETagヘッダ¶
クライアントに送信するHTTPレスポンスにETagヘッダの設定有無を指定する。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<ETagHeader>ON</ETagHeader>
<ETagHeader>ON (デフォルト)ETagヘッダを指定する。OFFETagヘッダを省略する。
デフォルトの応答ヘッダ¶
非標準ヘッダ処理¶
パフォーマンスとセキュリティ上の理由でオリジンサーバーからの送信ヘッダー中標準ヘッダのみを選択的に認識する。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<OriginalHeader>OFF</OriginalHeader>
<OriginalHeader>OFF (デフォルト)標準ヘッダではない場合は無視する。ONcookie, set-cookie, set-cookie2を除くすべてのヘッダーを保存して、クライアントに送信する。 ただし、メモリとストレージのコストをより消費する。
Viaヘッダ¶
クライアントに送信するHTTPレスポンスへのViaヘッダの設定有無を指定する。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<ViaHeader>ON</ViaHeader>
<ViaHeader>ON (デフォルト)Viaヘッダを次のように指定する。Via: STON/2.0.0
OFFViaヘッダを省略する。
Serverヘッダ¶
クライアントへのHTTPレスポンスにServerヘッダの設定有無を指定する。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<ServerHeader>ON</ServerHeader>
<ServerHeader>ON (デフォルト)ソースサーバーのServerヘッダを設定する。OFFServerヘッダを省略する。
クライアントの要求/応答ヘッダの変更¶
クライアントHTTPリクエストとレスポンスを特定の条件に応じて変更する。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<ModifyHeader FirstOnly="OFF">OFF</ModifyHeader>
<ModifyHeader>OFF (デフォルト)変更しません。ONヘッダ変更条件に応じて、ヘッダーを変更する。
ヘッダ変更時点を正確に理解しましょう。
HTTPリクエストヘッダの変更時点
クライアントのHTTP要求を最初に認識した時点でヘッダを変更する。 ヘッダが変更された場合変更された状態でCacheモジュールで処理される。 ただし、HostヘッダとURIは変更できない。
HTTP応答ヘッダーの変更時点
クライアントの応答の直前にヘッダを変更する。 ただし、Content-Lengthは変更できない。
ヘッダ変更条件は/ svc / {仮想ホスト名} /headers.txtに設定する。 ヘッダはマルチで設定可能なので条件に一致する場合すべての変更の設定が順次適用される。
最初の条件のみを変更したい場合 FirstOnly 属性を ON に設定する。 別の条件が同じヘッダを変更する場合 set によってLast-Winになったり、明示的に put append することができる。
# /svc/www.example.com/headers.txt
# 区切り文字はカンマ（、）です。
# リクエスト変更
# {Match}, {$REQ}, {Action(set|put|append|unset)} 順に表記する。
$IP[192.168.1.1], $REQ[SOAPAction], unset
$IP[192.168.2.1-255], $REQ[accept-encoding: gzip], set
$IP[192.168.3.0/24], $REQ[cache-control: no-cache], append
$IP[192.168.4.0/255.255.255.0], $REQ[x-custom-header], unset
$IP[AP], $REQ[X-Forwarded-For], unset
$HEADER[user-agent: *IE6*], $REQ[accept-encoding], unset
$HEADER[via], $REQ[via], unset
$URL[/source/*.zip], $REQ[accept-encoding: deflate], set
$METHOD[POST], $REQ[host: sub.example.com], set
# 応答変更
# {Match}, {$RES}, {Action(set|put|append|unset)}, {condition} 順に表記する。
# {condition}は、特定の応答コードに限ってヘッダーを変更することができますが、必須ではない。
$IP[192.168.1.1], $RES[via: STON for CDN], set
$IP[192.168.2.1-255], $RES[X-Cache], unset, 200
$IP[192.168.3.0/24], $RES[cache-control: no-cache, private], append, 3xx
$IP[192.168.4.0/255.255.255.0], $RES[x-custom-header], unset
$HEADER[user-agent: *IE6*], $RES[vary], unset
$HEADER[x-custom-header], $RES[cache-control: no-cache, private], append, 5xx
$URL[/source/*], $RES[cache-control: no-cache], set, 404
/secure/*.dat, $RES[x-custom], unset, 200
/*.mp4, $RES[Access-Control-Allow-Origin: example1.com], set
/*.mp4, $RES[Access-Control-Allow-Origin: example2.com], put
{Match}はIPアドレス、GeoIP、Header、URL、4つに設定が可能です。
IP
$IP[...]で表記しIP、IP Range、Bitmask、Subnet 4種類をサポートします。
GeoIP
$IP[...]で表記し必ず GeoIP が設定する必要があります。 国コードは、 ISO 3166-1 alpha-2 と ISO 3166-1 alpha-3 をサポートする。
Header
$HEADER[Key : Value]と表記する。 Valueは明確な表現とパターンをサポートする。 Valueが省略された場合にはKeyに対応するヘッダの存在の有無を条件に判断する。
URL
$URL[...]で表記し省略が可能です。 明確な表現とパターンを認識する。
METHOD
$METHOD[...]で表記し、GET、POST、HEAD、OPTIONSのどちらかを明示的に指定する。
{$REQ}と {$RES}は、ヘッダを変更方法を設定する。
set put append の場合、{Key：Value}で設定し、Valueが入力されていない場合は、空の値（""）が入力される。
unset の場合、{Key}のみ入力する。
{Action}は set , put , append , unset 4つに設定が可能です。
set要求/応答ヘッダに設定されているKeyとValueをヘッダに追加します。 すでに同じKeyが存在する場合、以前の値を上書きします。put(setと似ているが）同じKeyが存在すれば、上書きせずに新しい行に貼り付けます。append(setと似ているが）同じKeyが存在する場合は、既存のValueと設定されたValueの間にComma（、）で区切って値を結合する。unset要求/応答ヘッダに設定されているKeyに対応するヘッダを削除する。
{Condition}は200や304のような具体的な応答コードのほか2xx、3xx、4xx、5xxのように応答コードの系列の条件に設定する。 {Match}と一致しても{Condition}と一致しない場合変更が反映されない。 {Condition}が省略された場合は応答コードを確認しません。
注釈
#PROTOCOL キーワードを介してクライアントが要求したプロトコル（httpまたはhttps）をクライアントヘッダに追加することができる。
$URL[*], $REQ[X-Forwarded-Proto: #PROTOCOL], set
#CACHEHIT キーワードを使用して Request hit ratio の詳細コードをレスポンスヘッダに追加することができる。
$URL[*], $RES[X-Cache-Result: #CACHEHIT], set
圧縮¶
オリジンサーバーの結果コンテンツを圧縮して伝送する。 Accept-Encodingヘッダ に基づいてコンテンツを区別するように設定する必要があります。
Accept-Encoding: gzip, deflate
非圧縮ファイルをリアルタイムに圧縮して伝送する。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<Compression Method="gzip" Level="6" SourceSize="2-2048">OFF</Compression>
<Compression>OFF (デフォルト)圧縮機能を使用しません。ON圧縮機能を使用する。 次のプロパティをサポートします。Method (デフォルト: gzip)圧縮方式を指定する。 gzipのみサポートされる。Level (デフォルト: 6)圧縮レベルを指定します。 この値は、Methodによって異なる。 gzipは、1〜9までの指定が可能です。 数字が小さいほど高速ですが、圧縮率が悪く、大きいほど遅いが、圧縮率が良い。SourceSize (デフォルト: 2-2048, 単位: KB)元のコンテンツサイズを範囲で指定する。 あまりにも小さなファイルは圧縮率が低下する。 反対に大きすぎるファイルは過度にCPUを占有する場合があります。
圧縮されたコンテンツは、オリジナルと異なるコンテンツとして認識/キャッシュされ、同じ要求の再圧縮されない。 圧縮対象は/svc/{vhost}/compression.txtに指定する。 定義された順序で適用される。
# /svc/www.example.com/compression.txt
# 区切り文字はカンマ（、）です。
# {URL条件}、 {Method}、 {Level}順に表記する。
/sample.css、 no // 圧縮しない。
*.css // *.css 条件について 基本 Methodと Levelで 圧縮する。
*.htm、 gzip // *.htm htm 条件について gzipで 圧縮する。 (デフォルト Level)
*.xml、 9 // *.xml 条件について Level 9 に 圧縮する。 (デフォルト Method)
*.js、 gzip、 5 // *.js 条件について gzip（Level = 5）に圧縮する。
圧縮は、CPUリソースを大量に消費する機能です。 以下はファイルサイズ別GZIP（Level：9）の性能テストの結果です。
OSCentOS 6.3 (Linux version 2.6.32-279.el6.x86_64 (mockbuild@c6b9.bsys.dev.centos.org) (gcc version 4.4.6 20120305(Red Hat 4.4.6-4) (GCC) ) #1 SMP Fri Jun 22 12:19:21 UTC 2012)CPUIntel(R) Xeon(R) CPU E5-2603 0 @ 1.80GHz (8 processors)RAM8GBHDDSAS 275GB X 5EA
<Compression> が有効になっている場合は、オリジンサーバーに非圧縮コンテンツだけを要求する。 非圧縮コンテンツはオリジンサーバーにAccept-Encodingヘッダを設定せずに送った時の応答を意味する。 もしオリジンサーバが非圧縮コンテンツ要求に対してContent-Encodingヘッダを設定した場合は既に圧縮されたものとみなして圧縮しません。
DRM¶
On-the-flyでコンテンツを暗号化して配信する。
$ server.xml - <Server><VHostDefault><Options>
$ vhosts.xml - <Vhosts><Vhost><Options>
<Drm Status="Inactive" Keyword="drm" MaxSourceSize="500">
<Algorithm>RC4</Algorithm>
<IV> ... </IV>
<Token> ... </Token>
<Key Hash="none">$Token</Token>
</Drm>
<Drm>DRM方式を設定する。Status="Active"に設定されると、活性化される。 サービスアドレスの後ろKeywordをsuffixに付けてDRMを駆動する。// URL www.example.com/music.mp3 // DRM 処理された URL www.example.com/music.mp3/drm
MaxSourceSize (デフォルト: 500 MB)を超えるコンテンツについては、500 Internal Errorで処理する。<Algorithm> (デフォルト: RC4)暗号化アルゴリズムを選択する。 使用可能なアルゴリズムは次の通りです。<Algorithm> Bits RC4 40 ~ 2048 <IV>Initial Vector。<Token>キーの生成に使用されるトークン<Key> (デフォルト: $Token)変数を組み合わせて、がん化/復号化に使用されるキーを生成することができる。変数 説明 $Token <Token>の値 $url クライアントが要求されたURL $filename1 拡張子を含むファイル名 $filename2 拡張子を除いたファイル名 コンマ（、）を区切り文字として使用してキーを生成する。
URLが/music/iu.mp3で
<Token>をABCに仮定すると<Key>表現によるがん化/復号化キーは、次のとおりです。<Key Hash="none"> がん化/復号化キー $Token ABC $url,$Token /music/iu.mp3ABC $Token,$filename1 ABCiu.mp3 $filename2,$Token,$url iuABC/music/iu.mp3 Hash (デフォルト: none)属性がnoneの場合に組み合わせた文字列を、がん化/復号化キーを使用する。Hash属性を指定すると、以下のように組み合わせた文字列をハッシュした値をキーとして使用する。Hash( iuABC/music/iu.mp3 )
Hash属性はnone、MD5、SHA-1、SHA-256をサポートする。
注釈
DRM関連の変数( <Algorithm> 、 <IV> 、 <Token> 、 <Key> ) は、動的に変更できませんので、慎重に設定する必要がある。 以前キーで暗号化されたファイルは新しいキーで復号化できないためです。 したがって、キーを変更する必要がある状況ではその仮想ホストのキャッシュを初期化した後サービスすることが安全です。
<IV> と <Token> を平文（Plain Text）で提供するセキュリティ的に脆弱です。 これ以下のAPIを利用して暗号化した後、設定することを推奨する。
/command/encryptpassword?plain=abcdefghijklmnop
暗号化された <IV> 、 <Token> 設定のために Type="enc" 属性を追加する。
$ server.xml - <Server><VHostDefault><Options>
$ vhosts.xml - <Vhosts><Vhost><Options>
<Drm Status="Active" Keyword="drm">
<Algorithm>RC4</Algorithm>
<IV Type="enc">RokyekMd0IjDnRGKjVE7sQ==</IV>
<Token Type="enc">x4KHA1b+AirBOIoaeEBHmg==</Token>
<Key>$Token</Key>
</Drm>
注釈
暗号化APIは、証明書に基づいて動作する。 したがって、証明書が異なる暗号化/復号化の結果が異なっている。
第7章 オリジンサーバー¶
この章ではSTONとオリジンサーバーの関係について説明します。 オリジンサーバーは一般的にHTTPの仕様に準拠しているWebサーバーを意味します。 管理者はサービスを保護するために今回の章のすべての内容を熟知する必要があります。 これを基にオリジンサーバーの障害にも耐久性を備えた柔軟なサービスを構築することができます。
注釈
オリジンサーバーは保護されるべきです。 障害の種類が多様なほど対処案も多様です。 オリジン保護ポリシーを適切に設定するとゆったりとした点検時間を持つことができます。
障害の検知と復旧¶
Caching過程の中でオリジンサーバーに障害が発生した場合は自動的に排除します。 復元されたと判断するとサービスに投入します。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<ConnectTimeout>3</ConnectTimeout>
<ReceiveTimeout>10</ReceiveTimeout>
<Exclusion>3</Exclusion>
<Recovery Cycle="10" Uri="/" ResCode="0" Log="ON">5</Recovery>
<ConnectTimeout> (デフォルト: 3秒)n秒以内にオリジンサーバーとの接続が行われていない場合接続に失敗とみなす。
<ReceiveTimeout> (デフォルト: 10秒)通常のHTTPリクエストにもかかわらずオリジンサーバーがHTTP応答をn秒間送信しない場合は送信が失敗であると考えている。
<Exclusion> (デフォルト: 3回)オリジンサーバーで連続的にn回障害状況(
<ConnectTimeout>または<ReceiveTimeout>)が発生した場合そのサーバーを有効オリジンサーバーのリストから排除します。 排除前通常の通信が行われた場合はこの値は0に初期化されます。<Recovery> (デフォルト: 5回)CycleごとUriに要求してオリジンサーバーがResCodeに連続的にn回応答するとそのサーバーを復旧します。 この値を0に設定すると復旧しません。Cycle (デフォルト: 10秒)一定時間（秒）ごとにしようとします。Uri (デフォルト: /)要求を送信UriResCode (デフォルト: 0)正常応答として処理する応答コード。 0の場合は応答コードに関係なく応答が来れば成功とみなす。 200に設定すると応答コードが必ず200でなければなら正常応答で処理します。 コンマ（）を使用して有効な応答コードをマルチに設定します。 200、206、404に設定すると応答コードがこれらのいずれかである場合通常の応答で処理します。Log (デフォルト: ON)復旧のために使用されたHTTP Transactionを Originログ に記録します。
Health-Checker¶
`障害の検出と回復`_ はCaching過程中に発生する障害に対応します。
<Recovery> は応答コードを受け取り次第HTTP Transactionを終了します。 しかしHealth-CheckerはHTTP Transactionが成功することを確認します。
# vhosts.xml - <Vhosts><Vhost>
<Origin>
<Address> ... </Address>
<HealthChecker ResCode="0" Timeout="10" Cycle="10"
Exclusion="3" Recovery="5" Log="ON">/</HealthChecker>
<HealthChecker ResCode="200, 404" Timeout="3" Cycle="5"
Exclusion="5" Recovery="20" Log="ON">/alive.html</HealthChecker>
</Origin>
<HealthChecker> (デフォルト: /)Health-Checkerを構成します。 マルチで構成が可能です。 値としてUriを指定しXML例外文字の場合CDATAを使用します。
ResCode (デフォルト: 0)正しい応答コード（コンマでマルチ構成可能）Timeout (デフォルト: 10秒)ソケット接続からHTTP Transactionが完了するまで有効時間Cycle (デフォルト: 10秒)実行サイクルExclusion (デフォルト: 3回)連続n回失敗した場合そのサーバー排除Recovery (デフォルト: 5回)連続n回成功した場合そのサーバーの再投入Log (デフォルト: ON)HTTP Transactionを Originログ に記録します。
Health-Checkerはマルチで構成することができクライアントの要求に関係なく独立して実行されます。 `障害の検出と回復`_ や他のHealth-Checkerとも情報を共有せずに自分だけの基準で排除および責任を決定します。
送信元アドレスを使用ポリシー¶
送信元アドレス（IP）は次の要素によってどのように使用されるか決定されます。
- オリジンサーバー アドレスの形式（IPアドレスまたはDomain）とセカンダリアドレス
- `障害の検出と回復`_
- Health-Checker
サービスを運営しているとオリジンのアドレスが排除/復旧されることは頻繁です。 STONはIPテーブルに基づいてオリジンアドレスを使用して origin-status APIを介して情報を提供します。
送信元アドレスをIPに設定した場合非常に簡単です。
- 設定の変更に加えてIPリストを変化させる要因はない。
- TTLによりIPアドレスが期限切れにならない。
- 障害/復旧の両方の設定（IPアドレス）に基づいて動作します。
送信元アドレスをDomainに設定するとResolvingてIPアドレスを得なければならない。 ( DNSログ に記録されます。) IPリストは動的に変更されることができすべてのIPはTTL（Time To Live）の間だけ有効です。
- Domainは定期的に（1〜10秒）Resolvingします。
- Resolvingを介して使用するIPテーブルを構成します。
- すべてのIPはTTL分だけ有効でありTTLが期限切れになると使用しません。
- 同じIPアドレスが再びResolvingされるとTTLを更新します。
- IPテーブルは空白ではない。 （TTLが期限切れにされても）最後のIPは削除されない。
IPのTTLが長すぎる場合過度に多くのIPアドレスを使用するようになって意図しない結果を作成することができます。 これを防止するためにIPの最大TTLを制限することができます。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<DnsMaxTTL>60</DnsMaxTTL>
<DnsMaxTTL> (デフォルト: 60秒)ResolvingされたIPアドレスの最大使用時間（秒）を設定します。 この値が0の場合はDNSから提供されたTTLをそのまま使用します。
注釈
送信元アドレスをDomainに設定しても障害/復旧はIPベースで動作します。 Domainアドレス障害/復旧ポリシーは次のとおりです。
- （Domainについて）知っているすべてのIPアドレスが排除（Inactive）とそのDomainアドレスが排除されます。
- 新規IPがResolvingもDomainが排除されている場合はIPアドレスは最初から排除されます。
- すべてのIPアドレスはTTL有効期限が切れても排除されたDomain状態は解けない。
- 排除されたDomainに属するIPアドレスのいずれかが復旧されるべきはDomainは再び有効にされます。
やや複雑な内容であるため origin-status APIを使用してサービスの動作状態について理解を高めるのが良い。
オリジンの状態のモニタリング¶
APIを介して仮想ホストのオリジンの状態をモニタリングします。
http://127.0.0.1:10040/monitoring/origin // すべての仮想ホスト
http://127.0.0.1:10040/monitoring/origin?vhost=www.example.com
結果はJSON形式で提供されます。
{
"origin" :
[
{
"VirtualHost" : "example.com",
"Address" :
[
{ "1.1.1.1" : "Active" },
{ "1.1.1.2" : "Active" }
],
"Address2" : [ ],
"ActiveIP" :
[
{ "1.1.1.1" : 0 },
{ "1.1.1.2" : 0 }
] ,
"InactiveIP" : [ ]
},
{
"VirtualHost" : "foobar.com",
"Address" :
[
{ "origin.foobar.com" : "Active" }
],
"Address2" : [ ],
"ActiveIP" :
[
{ "5.5.5.5" : 21 },
{ "5.5.5.6" : 60 },
{ "5.5.5.7" : 37 }
],
"InactiveIP" :
[
{ "5.5.5.8" : 10 },
{ "5.5.5.9" : 184 }
]
}
]
}
VirtualHost仮想ホスト名Addressオリジンサーバー 。 設定アドレスが使用中であればActive、 （障害が発生して）使用していない場合Inactiveとして表示されます。Address2サブオリジンサーバーアドレス 。 設定アドレスを使用中であればActive、使用していない場合Inactiveとして表示されます。ActiveIP使用中のIPリストとTTL。 オリジンサーバーをIPに設定するとAddressと同じIPにTTLは0と表示されます。 Domainに設定するとResolving結果に従う。 様々なIPとTTLを使用します。InactiveIP使用しないIPリストとTTL。 使用していなくても復旧しているかHealthCheckerによって管理することができます。 そのアドレスはTTLの間復旧されなければ削除されます。
オリジンの状態の初期化¶
APIを介して仮想ホストのオリジンサーバー排除/復旧を初期化します。 また現在使用中のセッションを再利用せずに新たに接続を作成します。
http://127.0.0.1:10040/command/resetorigin // すべての仮想ホスト
http://127.0.0.1:10040/command/resetorigin?vhost=www.example.com
過負荷判断¶
最初に要求されているコンテンツは常にオリジンサーバーに要求する必要があります。 しかしすでにCachingされたコンテンツであればより柔軟に対応することができます。 オリジンサーバーが過負荷状態と判断されると更新をずらしてオリジンサーバーの負荷を高くない。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<BusySessionCount>100</BusySessionCount>
<BusySessionCount> (デフォルト: 100個)オリジンサーバーとHTTPトランザクションを進行中のセッションの数が一定数を超えると過負荷状態と判断します。 過負荷状態で有効期限が切れたコンテンツを更新するためにオリジンサーバーに接続しないようにTTLを TTL (Time To Live) の<OriginBusy>だけ延長します。 無条件元サーバーに要求が行くようにするにはこの値を非常に大きく設定すればよい。
オリジンサーバーの選択¶
元サーバーのアドレスがマルチ（2個以上）で構成されているときにオリジンサーバーの選択ポリシーを設定します。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<BalanceMode>RoundRobin</BalanceMode>
<BalanceMode> (デフォルト: RoundRobin)RoundRobin (デフォルト)すべてのオリジンサーバーが均等に要求を受信するようにRoundRobinで動作します。 接続されたIdleセッションはそのサーバーに要求が必要な場合にのみ使用します。Session再使用可能なセッションがある場合まず使用します。 新規セッションが必要な場合Round-Robinに割り当てる。Hashコンテンツを Consistent Hashing アルゴリズムに基づいてオリジンサーバーに分散して要請します。 サーバーが選択されると既に接続されたセッションを再利用しない場合は新規に接続します。
セッションの再利用¶
オリジンサーバーがKeep-Aliveをサポートする場合接続されたセッションは常に再使用されます。 しかしセッションを再利用して送信要求に対してオリジンサーバーが一方的に接続を終了することができます。 ので接続を復旧するのにユーザーの反応が遅くなる可能性があります。 特に長い間再使用していないセッションの場合これらの可能性はさらに高い。 これを防止するためにn秒の間再利用されていないセッションに対して自動的に接続を終了するように設定します。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<ReuseTimeout>60</ReuseTimeout>
<ReuseTimeout> (デフォルト: 60秒)一定時間使用されていないオリジンサーバーのセッションは終了します。 0に設定するとオリジンサーバーのセッションを再利用しません。
Rangeリクエスト¶
一度ダウンロードされたコンテンツのサイズを設定します。 動画のように前の部分だけが主に消費されるコンテンツの場合ダウンロードサイズを制限すると不要なオリジントラフィックを減らすことができます。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<PartSize>0</PartSize>
<PartSize> (デフォルト: 0 MB)0よりも大きい場合クライアントが要求した時点から設定サイズ（MB）だけRangeリクエストにダウンロードします。
<PartSize> を使用しているもう一つの理由はディスクスペースを節約するためです。 デフォルトの設定でSTONは元のサイズのファイルをディスク上に作成します。 しかし <PartSize> が0でない場合はダウンロードされている分だけファイルを分割して保存します。
たとえば1時間の映像（600MB）を1分（10MB）のみ視聴した場合にディスク領域を10MBだけを使用します。 スペースを節約する利点はあるがファイルが分割されて保存されるためディスク負荷が少し高くなる。
注釈
最初のコンテンツをダウンロードする際にContent-Lengthを知ることができないのでRange要求をすることができない。 ため <PartSize> が設定されている場合は設定サイズ分だけダウンロードして接続を終了します。
全体Range初期化¶
一般的にオリジンサーバーから最初のファイルをダウンロードするときや更新確認するときは次のように単純な形のGETリクエストを送信します。
GET /file.dat HTTP/1.1
しかしオリジンサーバーが一般的なGETリクエストに対して常にファイルを改ざんするように設定されている場合は元のファイルをそのままCachingできなく問題になることがあります。
最も代表的な例はApache Webサーバがmod_h.264_streamingなどの外部モジュールのように駆動される場合です。 Apache WebサーバーはGETリクエストに対して常にmod_h.264_streamingモジュールを介して応答します。 クライアント（この場合にはSTON）は元のファイルのままではなくモジュールによって変調されたファイルをサービス受ける。
mod_h.264_streamingモジュールは常にオリジンサーバーを変調します。
Range要求を使用するとモジュールをバイパスして元のをダウンロードすることができます。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<FullRangeInit>OFF</FullRangeInit>
<FullRangeInit>OFF (デフォルト)の一般的なHTTPリクエストを送る。ON0から始まるRangeリクエストを送る。 Apacheの場合Rangeヘッダが指定されるとモジュールをバイパスします。GET /file.dat HTTP/1.1 Range: bytes=0-
最初にファイルCachingするときはコンテンツのRangeを知らないのでFull-Range（= 0から始まる）を要請します。 オリジンサーバーがRange要求に対して正常に応答（206 OK）かどうかを必ず確認する必要があります。
コンテンツを更新するときは次のように If-Modified-Since ヘッダが一緒に指定されます。 オリジンサーバーが正しく 304 Not Modified に応答する必要があります。
GET /file.dat HTTP/1.1
Range: bytes=0-
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
注釈
<FullRangeInit> が正常に動作することを確認しWebサーバーのリスト。
- Microsoft-IIS/7.5
- nginx/1.4.2
- lighttpd/1.4.32
- Apache/2.2.22
クライアントの要求を維持¶
元に要求するときクライアントが送信した要求を維持するように設定します。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<WholeClientRequest>OFF</WholeClientRequest>
<WholeClientRequest>OFF (デフォルト)Caching-Keyを元に要求するURLに使用します。ONクライアントが要求されたURLに元に要請します。
Hit Ratioを高めるために次の設定を使用してCaching-Keyを決定します。
これによりオリジンサーバーに要求したURLとCaching-Keyは次のように決定されます。
| 設定 | クライアント要求URL | オリジン要求URL / Caching-Key |
|---|---|---|
大文字と小文字の区別 OFF |
/Image/LOGO.png | /image/logo.png |
大文字と小文字の区別 ON |
/Image/LOGO.png | /Image/LOGO.png |
QueryString区分 OFF |
/view/list.php?type=A | /view/list.php |
QueryString区分 ON |
/view/list.php?type=A | /view/list.php?type=A |
<WholeClientRequest> を ON に設定すると次のようにCaching-Keyとは関係なくクライアントが送信したURLをそのまま元に送る。
| 設定 | クライアント/オリジン要求URL | Caching-Key |
|---|---|---|
大文字と小文字の区別 OFF |
/Image/LOGO.png | /image/logo.png |
大文字と小文字の区別 ON |
/Image/LOGO.png | /Image/LOGO.png |
QueryString区分 OFF |
/view/list.php?type=A | /view/list.php |
QueryString区分 ON |
/view/list.php?type=A | /view/list.php?type=A |
POSTリクエストをキャッシュする場合オリジンサーバーに要求したときクライアントが送信したPOSTリクエストのBodyデータが変更なしで送信されます。
注釈
クライアントが送信したURLをそのまま送信するため Trimming ようアドオンのためにつけられたQueryStringもそのままオリジンサーバーに転送されます。
オリジン要求のデフォルトHeader¶
Hostヘッダ¶
オリジンサーバーに送信するHTTPリクエストのHostヘッダを設定します。 別に設定していない場合は仮想ホスト名が指定されます。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<Host />
<Host>オリジンサーバーに送信するHostヘッダを設定します。 オリジンサーバーで80ポート以外のポートでサービスしている場合必ずポート番号を設定する必要があります。# server.xml - <Server><VHostDefault><OriginOptions> # vhosts.xml - <Vhosts><Vhost><OriginOptions> <Host>www.example2.com:8080</Host>
クライアントが送信したHostヘッダを元に送りたい場合*に設定します。
User-Agentヘッダ¶
オリジンサーバーに送信HTTPリクエストのUser-Agentヘッダを設定します。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<UserAgent>STON</UserAgent>
<UserAgent> (デフォルト: STON)オリジンサーバーに送信UserAgentヘッダーを設定します。
クライアントが送信したUser-Agentヘッダを元に送りたい場合*に設定します。
XFF(X-Forwarded-For) ヘッダ¶
クライアントとオリジンサーバーとの間にSTONが位置するとオリジンサーバーはクライアントのIPアドレスを取得することができない。そのためSTONはオリジンサーバーに送信されるすべてのHTTP要求にX-Forwarded-Forヘッダを設定します。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<XFFClientIPOnly>OFF</XFFClientIPOnly>
<XFFClientIPOnly>OFF (デフォルト)クライアント（IP：128.134.9.1）が送信XFFヘッダにクライアントのIPアドレスを追加します。 クライアントがXFFヘッダを送信していない場合クライアントのIPのみ指定されます。X-Forwarded-For: 220.61.7.150, 61.1.9.100, 128.134.9.1
ONXFFヘッダの最初のアドレスだけをオリジンサーバーに転送します。X-Forwarded-For: 220.61.7.150
ETagヘッダ認識¶
オリジンサーバーからの応答するETag認識有無を設定します。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<OriginalETag>OFF</OriginalETag>
<OriginalETag>OFF (デフォルト)ETagヘッダを無視します。ONETagを認識しコンテンツ更新時If-None-Matchヘッダを追加します。
オリジン要求URLの変更¶
キャッシュを目的として元に送信するHTTPリクエストのURLを変更します
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<URLRewrite>
<Pattern>/download/(.*)</Pattern>
<Replace>/#1</Replace>
</URLRewrite>
// Pattern : /download/1.3.4
// Replace : /1.3.4
<URLRewrite>
<Pattern>/img/(.*\.(jpg|png).*)</Pattern>
<Replace>/#1/STON/composite/watermark1</Replace>
</URLRewrite>
// Pattern : /img/image.jpg?date=20140326
// Replace : /image.jpg?date=20140326/STON/composite/watermark1
handling_http_requests_url_rewrite のような表現を使用しますが仮想ホストごとに独立して設定するため仮想ホスト名を入力しません。
注釈
バイパスされるHTTP要求のURLは変更できない。
<WholeClientRequest> よりも優先します。
オリジン要求ヘッダの変更¶
オリジンサーバーにHTTPリクエストを送信するときの条件に応じてHTTPヘッダーを変更します。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<ModifyHeader FirstOnly="OFF">OFF</ModifyHeader>
<ModifyHeader>OFF (デフォルト)変更しません。ONヘッダ変更条件に応じてヘッダーを変更します。
ヘッダ変更時点はHTTP要求パケットが完成されてオリジンサーバーに転送する直前に実行されます。 ただしRangeヘッダは変調することができない。
この機能は クライアントの要求/応答ヘッダの変更 のサブ機能です。 ヘッダ変更には$ ORGREQキーワードを使用します。
# /svc/www.example.com/headers.txt
$URL[/*.mp4], $ORGREQ[x-media-type: video/mp4], set
$IP[1.1.1.1], $ORGREQ[user-agent: media_probe], put
*, $ORGREQ[If-Modified-Since], unset
*, $ORGREQ[If-None-Match], unset
# #PROTOCOLキーワードを介してクライアントが要求したプロトコルをヘッダに追加します。
$URL[*], $ORGREQ[X-Forwarded-Proto: #PROTOCOL], set
注釈
If-Modified-SinceヘッダとIf-None-Matchヘッダを unset するTTLが期限切れコンテンツはいつも再度ダウンロードします。
第8章 バイパス¶
この章ではクライアント要求の処理をオリジンサーバーに委任するバイパスについて説明します。 バイパスは条件と動作的に区分されます。
バイパスはCachingポリシーよりも優先します。 設計段階でEdge導入が検討されていないサービスであれば静的リソースと動的リソースを精巧に区分こなせない場合が多い。 このような場合すべてのクライアントの要求をバイパスするように構成した後ログに基づいて要求の多いコンテンツのみCachingように設定します。 ほとんどの場合数時間のログだけでオリジンサーバーの負荷を劇的に下げることができます。 第10章 モニタリング＆統計 でリアルタイムの情報を提供している理由もサービスをリアルタイムチューニングできるようにするためです。
バイパスは非常に速いだけでなくHTTPトランザクション単位で動作します。 いくらパーソナライズされたサイトといってもほとんどはメインページ（.html）のみ動的に変更されるだけで残りの99％は静的なリソースとして構成されている。 オリジンサーバーの動作に合わせることができるようオリジン オリジン要求のデフォルトHeader のバイパスバージョンが別々に存在します。
No-Cacheリクエストバイパス¶
クライアントがno-cacheリクエストを送信ばバイパスする。
GET / HTTP/1.1
cache-control: no-cache または cache-control:max-age=0
pragma: no-cache
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<BypassNoCacheRequest>OFF</BypassNoCacheRequest>
<BypassNoCacheRequest>OFF (デフォルト)Cacheモジュールが処理します。ONオリジンサーバーにバイパスします。
注釈
この設定はクライアントの動作（おそらく ctrl + F5 )によって判断されます。 したがって大量のバイパスがオリジンサーバーに負担を与える可能性があります。
GET / POSTバイパス¶
バイパスがGET / POSTリクエストのデフォルトの動作になるように設定することができます。 GETとPOSTの用途が異なるだけデフォルトの動作が異なることに注意する必要があります。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<BypassPostRequest>ON</BypassPostRequest>
<BypassGetRequest>OFF</BypassGetRequest>
<BypassPostRequest>ON (デフォルト)POSTリクエストをオリジンサーバーサーバーにバイパスします。OFFPOSTリクエストをSTONが処理します。
<BypassGetRequest>OFF (デフォルト)GETリクエストをSTONが処理します。ONGETリクエストをオリジンサーバーにバイパスします。
仮想ホストへのアクセス制御 と同じ条件の両方をサポートします。 バイパス例外条件は/ svc / {仮想ホスト名} /bypass.txtに設定します。。
# /svc/www.example.com/bypass.txt
$IP[192.168.2.1-255]
/index.html
cacheやbypass条件を明確にしていない場合はデフォルトの設定と反対に動作します。 例えば <BypassGetRequest> が ON であれば例外条件はCachingリストになる。 混乱余地が多い場合2番目のパラメータを使用してより明確に条件を設定することができます。
# /svc/www.winesoft.co.kr/bypass.txt
$HEADER[cookie: *ILLEGAL*], cache // 常にCaching処理
!HEADER[referer:] // デフォルトの設定に応じて
!HEADER[referer] & !HEADER[user-agent], bypass // 常にバイパス
$URL[/source/public.zip] // デフォルトの設定に応じて
整理すると優先順位は次の通りです。
- No-Cacheバイパス
- bypass.txtにbypassと明記されて
- bypass.txtのデフォルト設定
オリジンサーバーの固定¶
ログイン状態のようにオリジンサーバーとクライアントが必ず1：1で通信する必要があります。 `GET/POST バイパス`_ の属性にオリジンサーバーを固定させることができます。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<BypassPostRequest OriginAffinity="ON">...</BypassPostRequest>
<BypassGetRequest OriginAffinity="ON">...</BypassGetRequest>
OriginAffinityON (デフォルト)クライアント要求が常に同じサーバーにバイパスされることを保証します。 ただし同じソケットであることを保証するものではない。バイパスしなければならオリジンサーバーと接続しているすべてのソケットが切れる状況が発生することもあります。 しかしこのような場合でもサーバーに新しいソケット接続を要求します。
常に同じサーバーにバイパスされます。
バイパスたオリジンサーバーが障害を排除したりDNSに陥った場合新しいサーバーにバイパスされます。
OFFクライアントからの要求がどのサーバーにバイパスされることを保証することはできない。
オリジンサーバーの選択 によって従う。
オリジンセッション固定¶
クライアントソケットごとにオリジンサーバーと1：1でバイパスセッションを使用します。
クライアントがオリジンセッションを所有します。
`GET/POST バイパス`_ の属性にオリジンセッションを固定することができます。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<BypassPostRequest Private="OFF">...</BypassPostRequest>
<BypassGetRequest Private="OFF">...</BypassGetRequest>
PrivateONクライアントセッションがオリジンサーバー専用のセッションを使用するように動作します。 常に同じサーバーに要求がバイパスされます。 クライアントとオリジンサーバーのいずれか一方のセッションが終了された瞬間相手のセッションも終了されます。OFF (デフォルト)専用のセッションを使用しません。
オリジンサーバーがユーザーのログイン情報をセッションに基づいて維持する場合のようにクライアントの要求が必ずしも同じソケットに処理されるべき場合に便利です。
注釈
ややもするとあまりにも多くの要求を Private にバイパスする場合はクライアントの数だけオリジンサーバーに接続されて多大な負荷を与えることができます。 またこのように接続されたオリジンサーバーのセッションはクライアントが所有することになるので悪意のある攻撃の状況でのリスクをもたらすことができます。
Timeout¶
バイパスはオリジンサーバーから動的に処理した結果を応答する場合が多い。 これにより処理速度が静的なコンテンツよりも遅い場合が多い。 バイパス専用Timeoutを設定して不器用な障害の判断がされないようにします。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<BypassConnectTimeout>5</BypassConnectTimeout>
<BypassReceiveTimeout>300</BypassReceiveTimeout>
<BypassConnectTimeout> (デフォルト: 5秒)バイパスのためにn秒以内にオリジンサーバーとの接続が行われていない場合接続に失敗として処理します。<BypassReceiveTimeout> (デフォルト: 5秒)バイパス中オリジンサーバーからの応答がn秒間ない場合は送信失敗と処理します。
バイパスヘッダ¶
オリジン要求のデフォルトHeader 設定のバイパスを許可するを設定します。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<UserAgent Bypass="OFF">...</UserAgent>
<Host Bypass="ON"/>
<XFFClientIPOnly Bypass="ON">...</XFFClientIPOnly>
Bypass属性ONに設定されヘッダーを指定します。OFFクライアントが送信した関連ヘッダを設定します。
Portバイパス¶
特定のTCPポートのすべてのパケットを送信元サーバーとしてバイパスします。 仮想ホストのみ設定だ。
# vhosts.xml - <Vhosts>
<Vhost Name="www.example">
<PortBypass>443</PortBypass>
<PortBypass Dest=”1935”>1935</PortBypass>
</Vhost>
<PortBypass>指定されたポートで入力されたすべてのパケットをオリジンサーバーの同じポートにバイパスします。Dest属性にオリジンサーバーのポートを設定します。
たとえばポート443をバイパスする場合クライアントはオリジンサーバーと直接SSL通信をする効果を持つ。 バイパスされるポートは絶対に重複することができない。
注釈
構造的にPortバイパスはHTTPより下位LayerであるTCPで行われる。 特定の仮想ホストの下位にPortバイパスを設定する理由は統計情報を収集する主体が必要だからだ。
第9章 HTTPS¶
この章ではHTTPSの構成について説明します。 TLS 1.2をサポートしSSL 2.0はセキュリティ上の理由からアップグレードのみを許可します。 HTTPSはクライアントとSTON区間でのみ使用されます。 STONはオリジンサーバーとHTTPSで通信しません。 なぜならセキュリティ的にも性能的にSTONがHTTPSを中継することは適切でないからです。 もしオリジンサーバーと必ずHTTPSで通信が必要な場合 Portバイパス を推奨します。
サービスの構成¶
別のIPアドレスまたはポートを指定しない場合デフォルトでバインドされているサービスアドレスは "*:443" です。 グローバル設定（server.xml）に設定します。
# server.xml - <Server>
<Https>
<Cert>/usr/ssl/cert.pem</Cert>
<Key>/usr/ssl/certkey.pem</Key>
<CA>/usr/ssl/CA.pem</CA>
</Https>
<Https Listen="1.1.1.1:443">
<Cert>/usr/ssl_ip_port/cert.pem</Cert>
<Key>/usr/ssl_ip_port/certkey.pem</Key>
<CA>/usr/ssl_ip_port/CA.pem</CA>
</Https>
<Https Listen="*:886">
<Cert>/usr/ssl_port886/cert.pem</Cert>
<Key>/usr/ssl_port886/certkey.pem</Key>
<CA>/usr/ssl_port886/CA.pem</CA>
</Https>
<Https>HTTPSを構成します。<Cert>サーバー証明書<Key>サーバ証明書の秘密鍵。 暗号化された形式はサポートしません。<CA>CA(Certificate Authority) チェーンの証明書
同じPortをサービスしてもより明確な表現が優先します。
たとえば上記のNICが3個でそれぞれのIPアドレスが1.1.1.11.1.1.21.1.1.3である場合を想定してみよう。 1.1.1.1:443に接続したクライアントは最も明示的な表現である2番目（<Https Listen = "1.1.1.1:443">）証明書にサービスされます。 一方1.1.1.3:443に接続したクライアントはIPが一致する1番目（<Https>Listen = "* ：443"属性が省略されている）証明書にサービスされます。 証明書ファイルを同じ名前で上書きしてもReloadするときに反映されます。
注釈
証明書のフォーマットはPEM（Privacy Enhanced Mail）非対称キーアルゴリズムはRSAのみをサポートします。
SSL / TLS加速¶
CPU（AES-NI）を介してSSL / TLSを加速します。 AES-NIをサポートしているCPUである場合SSL / TLSでAESアルゴリズムを優先的に使用するように動作します。 AES-NIが認識された場合は次のようにInfo.logに記録されます。
AES-NI : ON (SSL/TLS accelerated)
管理者はAES-NIを使用有無を選択することができます。
# server.xml - <Server><Cache>
<AES-NI>ON</AES-NI>
<AES-NI> (デフォルト: ON)AES-NIを使用有無を選択します。
CipherSuiteを選択¶
サポートしているCipherSuitesは以下の通りである。
| Cipher Suite | TLS1.2 | TLS1.1/1.0 | SSL3.0 |
|---|---|---|---|
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) | O | ||
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) | O | ||
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02F) | O | ||
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xC027) | O | ||
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xC014) | O | O | |
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xC013) | O | O | |
| TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009D) | O | ||
| TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009C) | O | ||
| TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003D) | O | ||
| TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003C) | O | ||
| TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) | O | O | |
| TLS_RSA_WITH_AES_128_CBC_SHA (0x002F) | O | O | |
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000A) | O | O | |
| TLS_RSA_WITH_RC4_128_SHA (0x0005) | O | ||
| TLS_RSA_WITH_RC4_128_MD5 (0x0004) | O |
<Https> の CipherSuite 属性を使用すると使用CipherSuiteを設定することができます。
# server.xml - <Server>
<Https CipherSuite="ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP">
<Cert>/usr/ssl/cert.pem</Cert>
<Key>/usr/ssl/certkey.pem</Key>
<CA>/usr/ssl/CA.pem</CA>
</Https>
CipherSuiteApache mod_sslの SSL CipherSuite表現 に続く。
Forward Secrecy を保証するより高い安全性を得ることができます。 （下のリンク参照）
デフォルト的には FS（Forward Secrecy）を保証するCipherSuiteを優先的に選択します。
# server.xml - <Server>
<Https FS="ON"> ... </Https>
FSON (デフォルト)Forward Secrecyを保証するCipherSuiteを優先的に選択します。OFFClientHelloに記載順に選択します。
FS 属性は CipherSuite 属性よりも優先します。
注釈
パフォーマンス上の理由からECDHEのみをサポートします。 DHEは対応しません。
CipherSuite照会¶
CipherSuite設定結果を照会します。 CipherSuite式は OpenSSL 1.0.0E を遵守します。
http://127.0.0.1:10040/monitoring/ssl?ciphersuite=...
結果はJSON形式で提供されます。
{
"version": "2.0.0",
"method": "ssl",
"status": "OK",
"result":
[
{
"Name" : "AES128-SHA",
"Ver" : "SSLv3",
"Kx" : "RSA",
"Au" : "RSA",
"Enc" : "AES(128)",
"Mac" : "SHA1"
},
{
"Name" : "AES256-SHA",
"Ver" : "SSLv3",
"Kx" : "RSA",
"Au" : "RSA",
"Enc" : "AES(256)",
"Mac" : "SHA1"
}
]
}
マルチDomain構成¶
一台のサーバーで複数のサービスを同時に運用する場合はSSLの設定が問題になります。 ほとんどのWeb / CacheサーバはHTTPリクエストのHostヘッダを見てどの仮想ホストでサービスするか決定します。
一般的なHTTPS通信
一般的にSSLはクライアント（Browser）が自分が接続しようとするサーバーのドメイン名（winesoft.co.kr）を証明書を使用して確認すること身元確認をします。 もし証明書で身元確認ができない場合（無効な証明書または有効期間満了など）は次のようにユーザーに信頼有無を確認します（最初から遮断する場合もある）。 信頼有無はクライアントが選択するので通常の身元確認にならなくても続行したい場合はSSL通信が行われる。
ユーザーに判断を任せる。
サーバーでSSLを使用する仮想ホストが一つであれば問題にならない。 しかし複数の仮想ホストを同時に運営するサーバーでは問題になります。 サーバーがクライアントに証明書を転送するときに（"一般HTTPS通信"の "2.証明書伝達") クライアントがどのようなHostに接続しようとして知ることができないからです。
この問題を解決する代表的な方法は次のとおりになります。
| 方式 | 利点 | 欠点 |
|---|---|---|
| SNI | サーバーの設定だけで動作（標準） | Windows XPとIE6非対応 |
| Multi Certificate | 証明書のみ交換して動作 | メインドメインまたはサービス主体が同じこと |
| Multi Port | ポート変更して動作 | WebページからのHTTPSポートを設定する必要がある |
| Multi NIC | サーバーの設定だけで動作（最も広く使わ） | NICとIPの追加構成が必要 |
SNI (Server Name Indication)¶
SSL / TLSの SNI(Server Name Indication) 拡張フィールドを使用する方式です。 この方式はクライアントがサーバーにSSL接続を要求するときServer Name拡張フィールドを明示することで可能です。
# server.xml - <Server><Cache>
<HttpsSNI>OFF</HttpsSNI>
<HttpsSNI>OFF (デフォルト)Multi Port または Multi NIC 方法で複数の証明書をサポートします。。ONのようなIP + Portの組み合わせで複数の証明書をサポートします。 以下の場合のようにポート443で複数の証明書をサポートすることができます。# server.xml - <Server> <Https> <Cert>/usr/ssl/cert.pem</Cert> <Key>/usr/ssl/certkey.pem</Key> <CA>/usr/ssl/CA.pem</CA> </Https> <Https> <Cert>/usr/ssl_another/cert.pem</Cert> <Key>/usr/ssl_another/certkey.pem</Key> <CA>/usr/ssl_another/CA.pem</CA> </Https>
<HttpsSNI> は動的に変更が不可能です。 設定の変更後は必ずサービスを再起動する必要があります。
注釈
SNIは2003年6月 RFC 3546 を介してTLS 1.0以降でのみ定義された。 したがってSSL v3ではSNIをサポートしていません。 参考までにOpenSSLのs_clientにSSL-3.0オプションを適用するとSNI拡張フィールドを送信しません。
現在までで最もエレガントな方法ですがいくつかの古いクライアントでサポートされません。 以下はSNIをサポートしていないクライアントのリストです。 （出典: Wikipedia - Server Name Indication )
- Internet Explorer (any version) on Windows XP or Internet Explorer 6 or earlier
- Safari on Windows XP
- BlackBerry Browser
- Windows Mobile up to 6.5
- Android default browser on Android 2.x[34] (Fixed in Honeycomb for tablets and Ice Cream Sandwich for phones)
- wget before 1.14
- Java before 1.7
Multi Certificate¶
証明書に複数のドメインを入れたりWildcard(i.e. *.winesoft.co.kr)を明示して1つの証明書で複数のドメインの身元を確認することができる方法です。
一つの証明書で複数Domainを認証します。
サービス主体が同じなら効果的な方法ですが無関係であれば同じ証明書を共有することは現実的に困難です。 この方法は証明書のみを交換すればれるものなのでSTONで個別に設定することはない。 [ DigiCert 参考]
Multi Port¶
SSL / TLSはポート443を使用します。 重複していないポートを利用して証明書を複数インストールすることができます。 クライアントでは次のようにポートを明示することによりSSL通信が可能です。
https://winesoft.co.kr:543/
STONでは次のようにListen属性にポートを明示して証明書を複数に設定します。
# server.xml - <Server>
<Https> ..A社 の証明書.. </Https>
<Https Listen="*:543"> ..B社 の証明書.. </Https>
<Https Listen="*:544"> ..C社 の証明書.. </Https>
この方法は最も経済的ではあるがすべてのWebページへのリンクにHTTPSポートを指定しなければなら問題があります。
Multi NIC¶
サーバーのNICが複数で構成されている場合NICごとにIPアドレスを個別に割り当てることができます。 したがってサーバーのIPごとに個別の証明書をインストールしてクライアントが接続したサーバーのIPに基づいて証明書を決定するように設定します。 STONでは次のようにListen属性にIPアドレスを明示して証明書を複数に設定します。
# server.xml - <Server>
<Https Listen="10.10.10.10"> ..A社 の証明書.. </Https>
<Https Listen="10.10.10.11"> ..B社 の証明書.. </Https>
<Https Listen="10.10.10.12"> ..C社 の証明書.. </Https>
この方法は最も一般的に使用される方式です。
注釈
設定を共有するとIPアドレスのために問題になることができます。 このような場合はIPの代わりにNICの名前に設定します。
# server.xml - <Server>
<Https Listen="eth0"> ... </Https>
<Https Listen="eth1"> ... </Https>
<Https Listen="eth2"> ... </Https>
プロトコルの設定¶
<Https> にプロトコルを構成します。
# server.xml - <Server>
<Https TLS1.2="ON" TLS1.1="ON" TLS1.0="ON" SSL3.0="ON"> ... </Https>
TLS1.2 (デフォルト: ON)TLS1.2を使用します。TLS1.1 (デフォルト: ON)TLS1.1を使用します。TLS1.0 (デフォルト: ON)TLS1.0を使用します。SSL3.0 (デフォルト: ON)SSL3.0を使用します。
HSTS¶
HSTS(HTTP Strict Transport Security) は クライアントの要求/応答ヘッダの変更 を利用して簡単に実装が可能です。
# /svc/www.example.com/headers.txt
*, $RES[Strict-Transport-Security: max-age=31536000; includeSubDomains], set
Qualys SSL Server Test ではHSTSが適用されたサイトにのみA +の評価を与えている。
STON v2.2からA +を受けることができる。
3部。 管理/運営¶
第10章 モニタリング＆統計¶
この章ではモニタリングと統計について説明します。 モニタリングと統計は目的により別々で理解されている場合が多い。 しかしサービスを数字で話するという観点では両方は同じです。
ここで最も重要な要素はリアルタイム性です。 5分も長い。 リアルタイムでサービスの状態の変化を把握する必要があります。 多くのポリシーが適用さと同時に効果を出すのかすぐに知ることができなければならない。 すべての統計情報は1秒単位で収集され最小単位となる。
すべての統計情報は仮想ホストごとに別々に収集されるだけでなくリアルタイム（1秒）5分平均で提供されます。 顧客が統計をより簡単に分析加工することができるようにJSONとXMLフォーマットで提供します。
http://127.0.0.1:10040/monitoring/realtime?type=[JSON または XML]
http://127.0.0.1:10040/monitoring/average?type=[JSON または XML]
realtime1秒前のサービスの状態を提供します。average5分単位の統計情報を提供します。
収集範囲¶
統計情報の収集範囲を設定します。
# server.xml - <Server><VHostDefault>
# vhosts.xml - <Vhosts><Vhost>
<Stats>
<DirDepth>0</DirDepth>
<DirDepthAccum>OFF</DirDepthAccum>
<HttpsTraffic>OFF</HttpsTraffic>
<ClientLocal>OFF</ClientLocal>
<OriginLocal>OFF</OriginLocal>
</Stats>
<DirDepth> (デフォルト: 0)
ディレクトリごとの統計情報を収集します。 0に設定された場合すべての統計情報をルート（/）ディレクトリに収集します。 1に設定すると統計情報は最初のDepthディレクトリごとに収集されます。
注釈
値の制限はありませんが数万個以上のディレクトリの統計情報を収集する場合ややもするメモリの問題を引き起こすことができます。
<DirDepthAccum>ディレクトリごとの統計情報を収集する際に親ディレクトリの統計情報合算有無を設定します。
<DirDepth>が0であればこの設定は無視されます。OFF (デフォルト)上位ディレクトリに統計を合算しません。ON上位ディレクトリに統計を合算します。
たとえば
<DirDepth>が2でありすべてのディレクトリに同じように10ほどのトラフィックが発生していると仮定します。<DirDepthAccum>がOFFであれば左図のようにトラフィックが発生しているディレクトリ別に統計が収集されます。ONであれば右図のようにサブディレクトリのすべての統計情報が親ディレクトリに累積されます。
親ディレクトリの累積統計
たとえば/ imgディレクトリはサブディレクトリのトラフィックと自分のトラフィックを加えた30の統計値に持ちこのトラフィックは親ディレクトリに含まれる。
<HttpsTraffic>OFF (デフォルト)HTTPSトラフィックをSSL統計のみを収集します。ONHTTPSトラフィックをSSLとHTTPの両方の統計にように収集します。
デフォルト的にはSSL層を通過すると別のSSL統計に収集します。 HTTPSの場合上位プロトコルでHTTPで処理されるためより細かい統計情報の収集が可能です。 しかしSSL統計およびHTTP統計の両方に重複して統計情報の収集となりますのでHTTP統計だけ信頼することを推奨します。
<ClientLocal>LoopbackクライアントとSTON区間のトラフィックを統計に集計します。
OFF (デフォルト)集計しません。ON集計します。
<OriginLocal>STON区間とLoopbackオリジンサーバー区間のトラフィックを統計に集計します。
OFF (デフォルト)集計しません。ON集計します。
ホスト総合統計¶
ホスト統計情報は最も上位概念の統計にサービスするすべての仮想ホストの統計を総合します。 などの統計をJSONとXML形式で提供します。
{ <Host
"Host": Version="2.0.0"
{ Name="localhost"
"Version":"2.0.0", State="Healthy"
"Name":"localhost", Uptime="155986"
"State":"Healthy", OriginSession="32"
"Uptime":155996, OriginActiveSession="20"
"OriginSession":33, OriginInbound="1140741"
"OriginActiveSession":20, OriginOutbound="10059"
"OriginInbound":688177, OriginReqCount="42"
"OriginOutbound":14184, OriginResTotalCount="42"
"OriginReqCount":62, OriginResTotalTimeRes="5071"
"OriginResTotalCount":62, OriginResTotalTimeComplete="10288"
"OriginResTotalTimeRes":2375, OriginRes2xxCount="19"
"OriginResTotalTimeComplete":2509, OriginRes2xxTimeRes="9989"
"OriginRes2xxCount":54, OriginRes2xxTimeComplete="21521"
"OriginRes2xxTimeRes":2327, OriginRes3xxCount="23"
"OriginRes2xxTimeComplete":2481, OriginRes3xxTimeRes="1008"
"OriginRes3xxCount":8, OriginRes3xxTimeComplete="1008"
"OriginRes3xxTimeRes":2700, OriginRes4xxCount="0"
"OriginRes3xxTimeComplete":2700, OriginRes4xxTimeRes="0"
"OriginRes4xxCount":0, OriginRes4xxTimeComplete="0"
"OriginRes4xxTimeRes":0, OriginRes5xxCount="0"
"OriginRes4xxTimeComplete":0, OriginRes5xxTimeRes="0"
"OriginRes5xxCount":0, OriginRes5xxTimeComplete="0"
"OriginRes5xxTimeRes":0, ClientSession="165"
"OriginRes5xxTimeComplete":0, ClientActiveSession="80"
"ClientSession":155, ClientInbound="14792"
"ClientActiveSession":80 ClientOutbound="1981700"
"ClientInbound":35748, ClientReqCount="64"
"ClientOutbound":972906, ClientResTotalCount="64"
"ClientReqCount":152, ClientResTotalTimeRes="5535"
"ClientResTotalCount":152, ClientResTotalTimeComplete="6840"
"ClientResTotalTimeRes":1411, ClientRes2xxCount="44"
"ClientResTotalTimeComplete":1479, ClientRes2xxTimeRes="8050"
"ClientRes2xxCount":93, ClientRes2xxTimeComplete="9943"
"ClientRes2xxTimeRes":2305, ClientRes3xxCount="20"
"ClientRes2xxTimeComplete":2409, ClientRes3xxTimeRes="5"
"ClientRes3xxCount":59, ClientRes3xxTimeComplete="15"
"ClientRes3xxTimeRes":3, ClientRes4xxCount="0"
"ClientRes3xxTimeComplete":13, ClientRes4xxTimeRes="0"
"ClientRes4xxCount":0, ClientRes4xxTimeComplete="0"
"ClientRes4xxTimeRes":0, ClientRes5xxCount="0"
"ClientRes4xxTimeComplete":0, ClientRes5xxTimeRes="0"
"ClientRes5xxCount":0, ClientRes5xxTimeComplete="0"
"ClientRes5xxTimeRes":0, RequestHitRatio="6923"
"ClientRes5xxTimeComplete":0, ByteHitRatio="4243">
"RequestHitRatio":6387, <HttpCountSum
"ByteHitRatio":2926, OriginReqCount="0"
"HttpCountSum" : OriginResTotalCount="0"
{ OriginRes2xxCount="0"
"OriginReqCount" : 0, OriginRes3xxCount="0"
"OriginResTotalCount" : 0, OriginRes4xxCount="0"
"OriginRes2xxCount" : 0, OriginRes5xxCount="0"
"OriginRes3xxCount" : 0, ClientReqCount="0"
"OriginRes4xxCount" : 0, ClientResTotalCount="0"
"OriginRes5xxCount" : 0, ClientRes2xxCount="0"
"ClientReqCount" : 0, ClientRes3xxCount="0"
"ClientResTotalCount" : 0, ClientRes4xxCount="0"
"ClientRes2xxCount" : 0, ClientRes5xxCount="0"/>
"ClientRes3xxCount" : 0, <HttpRequestHitSum
"ClientRes4xxCount" : 0, TCP_NONE="0"
"ClientRes5xxCount" : 0 TCP_HIT="0"
}, TCP_IMS_HIT="0"
"HttpRequestHitSum" : TCP_REFRESH_HIT="0"
{ TCP_REF_FAIL_HIT="0"
"TCP_NONE" : 0, TCP_NEGATIVE_HIT="0"
"TCP_HIT" : 0, TCP_REDIRECT_HIT="0"
"TCP_IMS_HIT" : 0, TCP_MISS="0"
"TCP_REFRESH_HIT" : 0, TCP_REFRESH_MISS="0"
"TCP_REF_FAIL_HIT" : 0, TCP_CLIENT_REFRESH_MISS="0"
"TCP_NEGATIVE_HIT" : 0, TCP_DENIED="0"
"TCP_REDIRECT_HIT" : 0, TCP_ERROR="0"/>
"TCP_MISS" : 0, <FileSystem>
"TCP_REFRESH_MISS" : 0, <RequestHitRatio>0</RequestHitRatio>
"TCP_CLIENT_REFRESH_MISS" : 0, <ByteHitRatio>0</ByteHitRatio>
"TCP_DENIED" : 0, <Outbound>0</Outbound>
"TCP_ERROR" : 0 <Session>0</Session>
}, </FileSystem>
"FileSystem": <System> ... </System>
{ <VirtualHost> ... </VirtualHost>
"RequestHitRatio":0, <VirtualHost> ... </VirtualHost>
"ByteHitRatio":0, <VirtualHost> ... </VirtualHost>
"Outbound":0, <View> ... </View>
"Session":0 <View> ... </View>
}, </Host>
"System":{ ... },
"VirtualHost": [ ... ]
"View": [ ... ]
}
}
VersionSTONバージョンNameホスト名。 設定しなかった場合システムの名前を示します。Stateサービスの状態。 （Healthy =通常のサービス、Inactive =ライセンス無効化、Emergency）Uptime (単位: 秒)サービスの実行時間OriginSession元セッション数OriginActiveSession転送中のオリジンサーバーのセッション数OriginInbound (単位: Bytes, 平均)オリジンサーバーから受信した量OriginReqCount (平均)オリジンサーバーに送信される要求の数OriginOutbound (単位: Bytes, 平均)オリジンサーバーに送信さ量OriginResTotalCount (平均)オリジンサーバーの応答回数OriginResTotalTimeRes (単位: 0.01ms, 平均)オリジンサーバーの応答時間（HTTPリクエスト送信〜HTTP応答の最初の受信）OriginResTotalTimeComplete (単位: 0.01ms, 平均)オリジンサーバーHTTPトランザクションの完了時間（HTTPリクエスト送信〜HTTP応答完了）OriginRes2xxCount (平均)オリジンサーバー2xx応答回数OriginRes2xxTimeRes (単位: 0.01ms, 平均)オリジンサーバー2xx応答時間OriginRes2xxTimeComplete (単位: 0.01ms, 平均)オリジンサーバー2xxトランザクションの完了時間OriginRes3xxCount (平均)オリジンサーバー3xx応答回数OriginRes3xxTimeRes (単位: 0.01ms, 平均)オリジンサーバー3xx応答時間OriginRes3xxTimeComplete (単位: 0.01ms, 平均)オリジンサーバー3xxトランザクションの完了時間OriginRes4xxCount (平均)オリジンサーバー4xx応答回数OriginRes4xxTimeRes (単位: 0.01ms, 平均)オリジンサーバー4xx応答時間OriginRes4xxTimeComplete (単位: 0.01ms, 平均)オリジンサーバー4xxトランザクションの完了時間OriginRes5xxCount (平均)オリジンサーバー5xx応答回数OriginRes5xxTimeRes (単位: 0.01ms, 平均)オリジンサーバー5xx応答時間OriginRes5xxTimeComplete (単位: 0.01ms, 平均)オリジンサーバー5xxトランザクションの完了時間ClientSessionクライアントセッション数ClientActiveSession送信しているクライアントセッションの数ClientInbound (単位: Bytes, 平均)クライアントから受信した量ClientOutbound (単位: Bytes, 平均)クライアントに送信量ClientReqCount (平均)クライアントが送信した要求数ClientResTotalCount (平均)クライアントの応答回数ClientResTotalTimeRes (単位: 0.01ms, 平均)クライアントの応答時間（HTTPリクエストを受信〜HTTP応答送信）ClientResTotalTimeComplete (単位: 0.01ms, 平均)クライアントHTTPトランザクションの完了時間（HTTPリクエストを受信〜HTTP応答完了）ClientRes2xxCount (平均)クライアント2xx応答回数ClientRes2xxTimeRes (単位: 0.01ms, 平均)クライアント2xx応答時間ClientRes2xxTimeComplete (単位: 0.01ms, 平均)クライアント2xxトランザクションの完了時間ClientRes3xxCount (平均)クライアント3xx応答回数ClientRes3xxTimeRes (単位: 0.01ms, 平均)クライアント3xx応答時間ClientRes3xxTimeComplete (単位: 0.01ms, 平均)クライアント3xxトランザクションの完了時間ClientRes4xxCount (平均)クライアント4xx応答回数ClientRes4xxTimeRes (単位: 0.01ms, 平均)クライアント4xx応答時間ClientRes4xxTimeComplete (単位: 0.01ms, 平均)クライアント4xxトランザクションの完了時間ClientRes5xxCount (平均)クライアント5xx応答回数ClientRes5xxTimeRes (単位: 0.01ms, 平均)クライアント5xx応答時間ClientRes5xxTimeComplete (単位: 0.01ms, 平均)クライアント5xxトランザクションの完了時間RequestHitRatio (単位: 0.01%, 平均)Hit率。 キャッシュオブジェクトが生成されてそのオブジェクトが初期化されている場合Hitします。 反対にキャッシュオブジェクトが存在しないかそのオブジェクトがオリジンサーバーから初期化されていない場合Hitで打たない。 応答コードとHit率は関連がない。
HTTPとFile I / Oは仮想ホストを共有します。
Apacheを使用してアクセスされるFile I / OのRequestHitRatioは0％になる。 しかしHTTP Serverの場合File I / Oによってキャッシュされたファイルがサービスされるので100％のRequestHitRatioを持つ。 ByteHitRatioの場合元のInbound比Http outboundFile I / O outboundにそれぞれ計算されます。
ByteHitRatio (単位: 0.01%, 平均)オリジンサーバーに比べクライアント転送速度。(クライアント Outbound - オリジンサーバー Inbound) / クライアント Outbound
オリジンサーバーがはるかに速い速度を持っているかクライアントセッションがすぐに切断された場合負になる。
FileSystem独立FileSystem統計に他の統計数値に収集されない。RequestHitRatio (単位: 0.01%, 平均)File I / Oを使用したHit率ByteHitRatio (単位: 0.01%, 平均)オリジンサーバーに比べFile I / OレートOutbound (単位: Bytes, 平均)File I / OサービスデータサイズSession (平均)File I / O処理中のThreadができ
注釈
5分の統計のみ提供されているアイテムです。
HttpCountSumHTTPトランザクションの合計数HttpRequestHitSumキャッシュHIT結果
System統計¶
システムとグローバル・リソースの統計情報をJSONとXML形式で提供します。
"System": <System>
{ <CPU
"CPU": Kernel="689"
{ User="1316"
"Kernel":689, Idle="7993"
"User":1316, ProcKernel="570"
"Idle":7993, ProcUser="1216"
"ProcKernel":570, Nice="0"
"ProcUser":1216, IOWait="52"
"Nice":0, IRQ="10"
"IOWait":52, SoftIRQ="12"
"IRQ":10, Steal="0" />
"SoftIRQ":12, <Mem Free="5914644" STON="9785800"/>
"Steal":0 <Storage>
}, <Disk
"Mem": Path="/cache1"
{ Status="Normal"
"Free":5914644, Read="23"
"STON":9785800 ReadMerged="0"
}, ReadSectors="344"
"Storage": ReadTime="117"
{ Write="24"
"Disk": WriteMerged="93"
[ WriteSectors="936"
{ WriteTime="256"
"Path":"/cache1", IOProgress="0"
"Status":"Normal", IOTime="173"
"Read":23, IOWeightedTime="373"/>
"ReadMerged":0, <Disk
"ReadSectors":344, Path="/cache2"
"ReadTime":117, Status="Normal"
"Write":24, Read="27"
"WriteMerged":93, ReadMerged="1"
"WriteSectors":936, ReadSectors="488"
"WriteTime":256, ReadTime="144"
"IOProgress":0, Write="24"
"IOTime":173, WriteMerged="86"
"IOWeightedTime":373 WriteSectors="880"
}, WriteTime="254"
{ IOProgress="0"
"Path":"/cache2", IOTime="189"
"Status":"Normal", IOWeightedTime="380"/>
"Read":27, </Storage>
"ReadMerged":1, <ServerSocket
"ReadSectors":488, Total="42"
"ReadTime":144, Established="2"
"Write":24, Accepted="1"
"WriteMerged":86, Closed="0"/>
"WriteSectors":880, <ClientSocket
"WriteTime":254, Total="1"
"IOProgress":0, Established="0"
"IOTime":189, Connected="0"
"IOWeightedTime":380 Closed="0"/>
} <TCPSocket
] Established="30"
}, Timewait="2"
"ServerSocket": Orphan="0"
{ Alloc="0"
"Total":42, Mem="20"/>
"Established":1, <EQ>0</EQ>
"Accepted":0, <RQ>1000000</RQ>
"Closed":0 <WaitingFiles2Write>0</WaitingFiles2Write>
}, <ServiceAccess Allow="60" Deny="2"/>
"ClientSocket": <SystemLoadAverage Min1="0" Min5="0" Min15="0"/>
{ <URLRewrite>57</URLRewrite>
"Total":1, </System>
"Established":0,
"Connected":0,
"Closed":0
},
"TCPSocket":
{
"Established":30,
"Timewait":2,
"Orphan":0,
"Alloc":0,
"Mem":20
},
"EQ":0,
"RQ":1000000,
"WaitingFiles2Write":0,
"ServiceAccess":{"Allow":60, "Deny":2}
"SystemLoadAverage":
{
"Min1":0,
"Min5":0,
"Min15":0
},
"URLRewrite":57
}
CPU (単位: 0.01%)CPU使用率。 全体的なCPUの使用率はKernel + Userで計算する必要があります。KernelCPU(Kernel) の使用量UserCPU(User) の使用量Idle使用されていないCPU量ProcKernelSTONが使用するCPU（Kernel）の使用量ProcUserSTONが使用するCPU（User）の使用量Niceniced processes executing in user modeIOWaitwaiting for I/O to completeIRQservicing interruptsSoftIRQservicing softirqsStealinvoluntary wait
Mem (単位: Bytes)メモリ使用量FreeシステムFreeメモリサイズSTONSTONが使用するメモリサイズ
Diskディスク性能指標PathディスクパスStatusディスクの状態（Normal：正常動作、Invalid：障害に古い関数、Unmounted：管理者によってUnmountさ）Read読む成功回数ReadMerged読み込みがマージされた回数ReadSectors読んだセクタ数ReadTime (単位: ms)を読む所要時間Write執筆成功回数WriteMerged書き込みがマージされた回数WriteSectors書かれているセクタ数WriteTime (単位: ms)を送る所要時間IOProgress進行中IO数IOTime (単位: ms)IO所要時間IOWeightedTime (単位: ms)IO所要時間（重み付け）
ServerSocketサーバソケット（クライアントとSTON区間）についてTotal全サーバソケット数Established接続された状態のサーバソケット数Accepted新た接続されたサーバソケットができClosed接続が終了されたサーバーソケット数
ClientSocketクライアントソケット（STONと元サーバー区間）についてTotal全クライアントソケット数Established接続された状態のクライアントソケット数Connected新た接続されたクライアントソケット数Closed接続が終了されたクライアントソケット数
TCPSocketシステム（OS）が提供するTCPの状態情報EstablishedEstablished状態のTCP接続数TimewaitTIME_WAIT状態のTCP接続数Orphanまだfile handleにattachされていないTCP接続Alloc割り当てられたTCP接続Mem(undocumented)
EQSTON Frameworkでまだ処理されていないEvent数RQ最近サービスされたコンテンツを参照キューに保存されたEvent数WaitingFiles2Writeディスクへの書き込み待機しているファイルの数ServiceAccessServiceAccessによって許可（Allow）、拒否（Deny）されたソケット数SystemLoadAverageSystem Load Averageの1分/ 5分/ 15分の平均URLRewriteURL前処理によって変換が成功した回数
仮想ホストの統計¶
仮想ホストごとに統計が提供されます。 仮想ホストの統計はHTTP転送（ディレクトリ別）URLバイパスポートバイパスSSLに区分されます。
"VirtualHost": <VirtualHost
[ Name="image.11st.co.kr"
{ Uptime="155956"
"Name":"image.11st.co.kr", OriginSession="12"
"Uptime":155966, OriginActiveSession="6"
"OriginSession":12, OriginInbound="106914"
"OriginActiveSession":6, OriginOutbound="3238"
"OriginInbound":169, OriginReqCount="42"
"OriginOutbound":269, OriginResTotalCount="13"
"OriginReqCount":62, OriginResTotalTimeRes="1553"
"OriginResTotalCount":1, OriginResTotalTimeComplete="6630"
"OriginResTotalTimeRes":3300, OriginRes2xxCount="1"
"OriginResTotalTimeComplete":3300, OriginRes2xxTimeRes="3300"
"OriginRes2xxCount":0, OriginRes2xxTimeComplete="69300"
"OriginRes2xxTimeRes":0, OriginRes3xxCount="12"
"OriginRes2xxTimeComplete":0, OriginRes3xxTimeRes="1408"
"OriginRes3xxCount":1, OriginRes3xxTimeComplete="1408"
"OriginRes3xxTimeRes":3300, OriginRes4xxCount="0"
"OriginRes3xxTimeComplete":3300, OriginRes4xxTimeRes="0"
"OriginRes4xxCount":0, OriginRes4xxTimeComplete="0"
"OriginRes4xxTimeRes":0, OriginRes5xxCount="0"
"OriginRes4xxTimeComplete":0, OriginRes5xxTimeRes="0"
"OriginRes5xxCount":0, OriginRes5xxTimeComplete="0"
"OriginRes5xxTimeRes":0, ClientSession="30"
"OriginRes5xxTimeComplete":0, ClientActiveSession="12"
"ClientSession":26, ClientInbound="4113"
"ClientActiveSession":16, ClientOutbound="895937"
"ClientInbound":13968, ClientReqCount="64"
"ClientOutbound":110398, ClientResTotalCount="18"
"ClientReqCount":152, ClientResTotalTimeRes="666"
"ClientResTotalCount":52, ClientResTotalTimeComplete="4377"
"ClientResTotalTimeRes":94, ClientRes2xxCount="10"
"ClientResTotalTimeComplete":107, ClientRes2xxTimeRes="1200"
"ClientRes2xxCount":1, ClientRes2xxTimeComplete="7870"
"ClientRes2xxTimeRes":4700, ClientRes3xxCount="8"
"ClientRes2xxTimeComplete":4800, ClientRes3xxTimeRes="0"
"ClientRes3xxCount":51, ClientRes3xxTimeComplete="12"
"ClientRes3xxTimeRes":3, ClientRes4xxCount="0"
"ClientRes3xxTimeComplete":15, ClientRes4xxTimeRes="0"
"ClientRes4xxCount":0, ClientRes4xxTimeComplete="0"
"ClientRes4xxTimeRes":0, ClientRes5xxCount="0"
"ClientRes4xxTimeComplete":0, ClientRes5xxTimeRes="0"
"ClientRes5xxCount":0, ClientRes5xxTimeComplete="0"
"ClientRes5xxTimeRes":0, RequestHitRatio="10000"
"ClientRes5xxTimeComplete":0, ByteHitRatio="8806">
"RequestHitRatio":10000, <FileSystem>
"ByteHitRatio":9984, <RequestHitRatio>0</RequestHitRatio>
"FileSystem": <ByteHitRatio>0</ByteHitRatio>
{ <Outbound>0</Outbound>
"RequestHitRatio":0, <Session>0</Session>
"ByteHitRatio":0, </FileSystem>
"Outbound":0, <Memory>784786700</Memory>.
"Session":0 <SecuredMemory>0</SecuredMemory>.
}, <Disk> ... </Disk>
"Memory":785740769, <Session> ... </Session>
"SecuredMemory":0, <Dims> ... </Dims>
"Disk": { ... }, <Compression> ... </Compression>
"Session": { ... }, <File Total="458278" Opened="15" Instance="458292"/>
"Dims": { ... }, <Cached> ... </Cached>
"Compression": { ... }, <CacheFileEvent> ... </CacheFileEvent>
"FileTotal":458308, <WaitingFiles2Delete>1087593</WaitingFiles2Delete>
"FileOpened":15, <CacheFileEvent Create=\"%u\" Swap=\"%u\" Erase=\"%u\" Purge=\"%u\" Expire=\"%u\" />
"FileInstance":458320, <ClientHttpReqBypass Sum="8100">27</ClientHttpReqBypass>
"Cached": { ... }, <ClientHttpReqDenied Sum="400">1</ClientHttpReqDenied>
"CacheFileEvent": { ... }, <OriginTraffic> ... </OriginTraffic>
"WaitingFiles2Delete":1087595, <PortBypass> ... </PortBypass>
"ClientHttpReqBypassSum":8100, <ClientTraffic> ... </ClientTraffic>
"ClientHttpReqBypass":27, <UrlBypass> ... </UrlBypass>
"ClientHttpReqDeniedSum":400, </VirtualHost>
"ClientHttpReqDenied":1, <VirtualHost> ... </VirtualHost>
"OriginTraffic": { ... }, <VirtualHost> ... </VirtualHost>
"PortBypass": { ... }, <VirtualHost> ... </VirtualHost>
"ClientTraffic": { ... },
"UrlBypass": { ... }
},
...
]
Memory (単位: Bytes)メモリにロードされたコンテンツの量SecuredMemory (単位: Bytes)メモリから削除されたコンテンツの量Diskディスク情報Sessionセッション情報DimsDIMS変換統計Compression圧縮統計FileTotalファイル全体数FileOpened開いているローカルファイルの数FileInstanceキャッシュファイルの数Cachedキャッシュ情報CacheFileEventキャッシュファイルイベントWaitingFiles2Delete削除待機しているファイルの数ClientHttpReqBypassバイパスしたクライアントのHTTP要求の数ClientHttpReqDeniedHTTP要求がブロックされた回数OriginTrafficオリジンサーバーのトラフィックの統計情報PortBypassポートバイパストラフィックの統計情報ClientTrafficクライアントのトラフィックの統計情報UrlBypassURLマッチングまたは<BypassNoCacheRequest>を介してオリジンサーバーに変換統計されたHTTPトラフィックの統計情報
注釈
5分の統計のみ提供されているアイテムです。
ClientHttpReqBypassSumバイパスされるHTTPリクエストの合計数ClientHttpReqDeniedSumDenyされるHTTPリクエストの合計数
ディスク統計¶
仮想ホストが使用するディスクの統計情報を提供します。
"Disk": <Disk>
{ <TotalSize>22003701435</TotalSize>
"TotalSize":22004057982, <Create>1</Create>
"Create":0, <Open>10</Open>
"Open":1, <Delete>0</Delete>
"Delete":0, <ReadCount>9</ReadCount>
"ReadCount":1, <ReadSize>735726</ReadSize>
"ReadSize":104744, <WriteCount>1</WriteCount>
"WriteCount":0, <WriteSize>157145</WriteSize>
"WriteSize":0, <Distribution
"Distribution": U1K="45725"
{ U2K="192523"
"U1K="45725, U4K="137055"
"U2K="192523, U8K="39740"
"U4K="137055, U16K="13408"
"U8K="39740, U32K="12303"
"U16K="13408, U64K="11462"
"U32K="12303, U128K="2560"
"U64K="11462, U256K="22"
"U128K="2560, U512K="0"
"U256K="22, U1M="45725"
"U512K="0, U2M="192523"
"U1M="45725, U4M="137055"
"U2M="192523, U8M="39740"
"U4M="137055, U16M="13408"
"U8M="39740, U32M="12303"
"U16M="13408, U64M="11462"
"U32M="12303, U128M="2560"
"U64M="11462, U256M="22"
"U128M="2560, U512M="0"
"U256M="22, U1G="0"
"U512M="0, U2G="0"
"U1G="0, U4G="0"
"U2G="0, U8G="0"
"U4G="0, U16G="0"
"U8G="0, O16G="0" />
"U16G":0, </Disk>
"O16G":0
}
}
TotalSize (単位: Bytes)ローカルファイルサイズがありCreateローカルファイルの作成回数OpenローカルファイルOpen回数Deleteローカルファイルの削除回数ReadCountローカルファイルからReadした回数ReadSize (単位: Bytes)ローカルファイルからReadしたサイズWriteCountローカルファイルからWriteした回数WriteSize (単位: Bytes)ローカルファイルからWriteサイズDistributionローカルファイル人数分布U1K1KB 未満のファイル数U2K2KB 未満のファイル数U4K4KB 未満のファイル数U8K8KB 未満のファイル数U16K16KB 未満のファイル数U32K32KB 未満のファイル数U64K64KB 未満のファイル数U128K128KB 未満のファイル数U256K256KB 未満のファイル数U512K512KB 未満のファイル数U1M1MB 未満のファイル数U2M2MB 未満のファイル数U4M4MB 未満のファイル数U8M8MB 未満のファイル数U16M16MB 未満のファイル数U32M32MB 未満のファイル数U64M64MB 未満のファイル数U128M128MB 未満のファイル数U256M256MB 未満のファイル数U512M512MB 未満のファイル数U1G1GB 未満のファイル数U2G2GB 未満のファイル数U4G4GB 未満のファイル数U8G8GB 未満のファイル数U16G16GB 未満のファイル数O16G16GB 以上のファイル数
セッション統計¶
仮想ホストが使用するディスクの統計情報を提供します。
"Session": <Session
{ Client="30"
"Client":30, ActiveClient="20"
"ActiveClient":20, Origin="12"
"Origin":12, ActiveOrigin="7" />
"ActiveOrigin":7
},
Client完全なHTTPクライアントセッション数ActiveClient完全なHTTPクライアントの転送中のセッション数Origin全体オリジンサーバーのセッション数ActiveOrigin転送中のオリジンサーバーセッション数
DIMS統計¶
DIMSの性能指標を提供します。
"Dims": <Dims
{ Requests="30"
"Requests": 30, Converted="29"
"Converted": 29, Failed="1"
"Failed": 1, AvgSrcSize="1457969"
"AvgSrcSize": 1457969, AvgDestSize="598831"
"AvgDestSize": 598831, AvgTime="34" />
"AvgTime": 34
},
Requests変換要求数Converted変換成功回数Failed変換に失敗した回数AvgSrcSize (単位: Bytes)オリジンサーバーのイメージの平均サイズAvgDestSize (単位: Bytes)変換されたイメージの平均サイズAvgTime (単位: ms)変換所要時間
圧縮統計¶
圧縮の性能指標を提供します。
"Compression": <Compression
{ Requests="30"
"Requests": 30, Converted="29"
"Converted": 29, Failed="1"
"Failed": 1, AvgSrcSize="1457969"
"AvgSrcSize": 1457969, AvgDestSize="598831"
"AvgDestSize": 598831, AvgTime="34" />
"AvgTime": 34
},
Requests圧縮要求数Converted圧縮成功回数Failed圧縮に失敗した回数AvgSrcSize (単位: Bytes)ソースファイルの平均サイズAvgDestSize (単位: Bytes)圧縮されたファイルの平均サイズAvgTime (単位: ms)圧縮所要時間
オリジンサーバーの統計¶
STONとオリジンサーバーの間で発生するトラフィックの統計情報を提供します。
"OriginTraffic": <OriginTraffic>
{ <HttpReqCount Sum="600">2</HttpReqCount>
"HttpReqCountSum":0, <HttpReqHeaderSize>3238</HttpReqHeaderSize>
"HttpReqCount":0, <HttpReqBodySize>0</HttpReqBodySize>
"HttpReqHeaderSize":269, <HttpResHeaderSize>2020</HttpResHeaderSize>
"HttpReqBodySize":0, <HttpResBodySize>104894</HttpResBodySize>
"HttpResHeaderSize":169, <Response>
"HttpResBodySize":0, <ResTotal>
"Response": <Count Sum="8100">13</Count>
{ <Completed Sum="8100">12</Completed>
"ResTotal": <TimeRes>1553</TimeRes>
{ <TimeComplete>6630</TimeComplete>
"CountSum":0, </ResTotal>
"Count":1, <Res2xx>
"CompletedSum":0, <Count Sum="8100">1</Count>
"Completed":1, <Completed Sum="8100">1</Completed>
"TimeRes":3300, <TimeRes>3300</TimeRes>
"TimeComplete":3300 <TimeComplete>69300</TimeComplete>
}, </Res2xx>
"Res2xx": <Res3xx>
{ <Count Sum="8100">12</Count>
"CountSum":0, <Completed Sum="8100">11</Completed>
"Count":0, <TimeRes>1408</TimeRes>
"CompletedSum":0, <TimeComplete>1408</TimeComplete>
"Completed":0, </Res3xx>
"TimeRes":0, <Res4xx>
"TimeComplete":0 <Count Sum="8100">0</Count>
}, <Completed Sum="8100">0</Completed>
"Res3xx": <TimeRes>0</TimeRes>
{ <TimeComplete>0</TimeComplete>
"CountSum":0, </Res4xx>
"Count":1, <Res5xx>
"CompletedSum":0, <Count Sum="8100">0</Count>
"Completed":1, <Completed Sum="8100">0</Completed>
"TimeRes":3300, <TimeRes>0</TimeRes>
"TimeComplete":3300 <TimeComplete>0</TimeComplete>
}, </Res5xx>
"Res4xx": <ConnectTimeout Sum="8100">0</ConnectTimeout>
{ <ReceiveTimeout Sum="8100">0</ReceiveTimeout>
"CountSum":0, <Close Sum="8100">0</Close>
"Count":0, </Response>
"CompletedSum":0, <Connect>
"Completed":0, <Count>0</Count>
"TimeRes":0, <AvgDNSQueryTime>0</AvgDNSQueryTime>
"TimeComplete":0 <AvgConnTime>0</AvgConnTime>
}, </Connect>
"Res5xx": </OriginTraffic>
{
"CountSum":0,
"Count":0,
"CompletedSum":0,
"Completed":0,
"TimeRes":0,
"TimeComplete":0
},
"ConnectTimeoutSum":0,
"ConnectTimeout":0,
"ReceiveTimeoutSum":0,
"ReceiveTimeout":0,
"CloseSum":0,
"Close":0
},
"Connect":
{
"Count":0,
"AvgDNSQueryTime":0,
"AvgConnTime":0
}
},
HttpReqCount元サーバーに送信されるHTTPリクエストの数HttpReqHeaderSize (単位: Bytes)オリジンサーバーに送信されるHTTPヘッダーのサイズHttpReqBodySize (単位: Bytes)オリジンサーバーに送信されるHTTP BodyサイズHttpResHeaderSize (単位: Bytes)オリジンサーバーから受信したHTTPヘッダーのサイズHttpResBodySize (単位: Bytes)オリジンサーバーから受信したHTTP BodyサイズResponse元サーバーから送信される応答 (ResXXX)Count応答回数Completed正常に送信完了したHTTPトランザクションの数TimeResHTTP応答時間TimeCompleteHTTPトランザクションの完了時間
Responseその他のフィールドConnectTimeout接続に失敗しReceiveTimeout伝送遅延Close転送中オリジンサーバーから最初のソケットを終了
Connectオリジンサーバー接続の統計情報Count接続回数AvgDNSQueryTime (単位: 0.01ms)平均DNSクエリ時間AvgConnTime (単位: 0.01ms)の平均接続時間（TCP SYN送信〜TCP SYN ACK受信）
注釈
5分の統計のみ提供されているアイテムです。
HttpReqCountSumHTTPリクエストの合計回数CountSumHTTP応答の合計回数CompletedSum完了したHTTPトランザクションの合計回数ConnectTimeoutSumオリジンサーバー接続に失敗し合計回収ReceiveTimeoutSumオリジンサーバーの伝送遅延の合計回数CloseSum元サーバーで最初に接続を終了した総回数
ポートバイパス統計¶
<PortBypass> を介して発生したトラフィックの統計情報を提供します。
"PortBypass": <PortBypass SrcPort="1935" DestPost="1935">
[ <Session>0</Session>
{ <Hit Established="0"
"SrcPort":1935, "DestPort":1935, "Session":0, ClientClosed="0"
"Hit": OriginClosed="0"
{ OriginCT="0" />
"Established":0, "ClientClosed":0, <ClientTraffic In="0" Out="0"/>
"OriginClosed":0, "OriginCT":0 <OriginTraffic In="0" Out="0"/>
}, </PortBypass>
"ClientTraffic": { "In":0, "Out":0 }, <PortBypass SrcPort="1936" DestPost="1936">
"OriginTraffic": { "In":0, "Out":0 } <Session>17</Session>
}, ...
{ </PortBypass>
"SrcPort":1936, "DestPort":1936, "Session":17,
...
}
],
SrcPort/DestPortバイパスするSTONポート/オリジンサーバーのポートSession現在接続しているセッション数Hitバイパス接続統計Established成立した接続数ClientClosedクライアントが接続を終了した回数OriginClosedオリジンサーバーで接続を終了した回数OriginCTオリジンサーバー接続に失敗した回数
ClientTraffic (単位: Bytes)クライアントのトラフィック (In=Inbound、 Out=Outbound)OriginTraffic (単位: Bytes)オリジンサーバーのトラフィック (In=Inbound、 Out=Outbound)
クライアント統計¶
クライアントのトラフィックはディレクトリ毎の統計の設定かどうかによって"Traffic"がマルチで表現されます。ディレクトリ毎の統計情報を設定しなかった場合すべてのトラフィックはルート（/）に集計されます。ディレクトリの統計情報が設定されている場合はルート（/）とトラフィックが発生したディレクトリのみ提供されます。
"ClientTraffic": <ClientTraffics Depth="0" Accum="OFF" HttpsTraffic="OFF">
{ <TrafficCount>1</TrafficCount>
"Depth":0, <Traffic RequestHitRatio="0">
"Accum":"OFF", <Path>/</Path>
"HttpsTraffic":"OFF", <HttpReqCount Sum="0">0</HttpReqCount>
"TrafficCount":1, <HttpReqHeaderSize>4113</HttpReqHeaderSize>
"Traffic": <HttpReqBodySize>0</HttpReqBodySize>
[ <HttpResHeaderSize>3066</HttpResHeaderSize>
{ <HttpResBodySize>892871</HttpResBodySize>
"RequestHitRatio" : 9984, <Response>
"Path":"/", <ResTotal>
"HttpReqCountSum":0, <Count Sum="0">18</Count>
"HttpReqCount":100, <Completed Sum="0">18</Completed>
"HttpReqHeaderSize":13968, <TimeRes>666</TimeRes>
"HttpReqBodySize":0, <TimeComplete>4377</TimeComplete>
"HttpResHeaderSize":5654, </ResTotal>
"HttpResBodySize":104744, <Res2xx>
"Response": <Count Sum="0">10</Count>
{ <Completed Sum="0">10</Completed>
"ResTotal": <TimeRes>1200</TimeRes>
{ <TimeComplete>7870</TimeComplete>
"CountSum":0, </Res2xx>
"Count":52, <Res3xx>
"CompletedSum":0, <Count Sum="0">8</Count>
"Completed":52, <Completed Sum="0">8</Completed>
"TimeRes":94, <TimeRes>0</TimeRes>
"TimeComplete":107 <TimeComplete>12</TimeComplete>
}, </Res3xx>
"Res2xx": <Res4xx>
{ <Count Sum="0">0</Count>
"CountSum":0, <Completed Sum="0">0</Completed>
"Count":1, <TimeRes>0</TimeRes>
"CompletedSum":0, <TimeComplete>0</TimeComplete>
"Completed":1, </Res4xx>
"TimeRes":4700, <Res5xx>
"TimeComplete":4800 <Count Sum="0">0</Count>
}, <Completed Sum="0">0</Completed>
"Res3xx": <TimeRes>0</TimeRes>
{ <TimeComplete>0</TimeComplete>
"CountSum":0, </Res5xx>
"Count":51, </Response>
"CompletedSum":0, <SSL RecvSize="0" SendSize="0"/>
"Completed":51, <RequestHit
"TimeRes":3, TCP_NONE="0"
"TimeComplete":15 TCP_HIT="0"
}, TCP_IMS_HIT="0"
"Res4xx": TCP_REFRESH_HIT="0"
{ TCP_REF_FAIL_HIT="0"
"CountSum":0, TCP_NEGATIVE_HIT="0"
"Count":0, TCP_REDIRECT_HIT="0"
"CompletedSum":0, TCP_MISS="0"
"Completed":0, TCP_REFRESH_MISS="0"
"TimeRes":0, TCP_CLIENT_REFRESH_MISS="0"
"TimeComplete":0 TCP_DENIED="0"
}, TCP_ERROR="0"/>
"Res5xx": <RequestHitSum
{ TCP_NONE="0"
"CountSum":0, TCP_HIT="0"
"Count":0, TCP_IMS_HIT="0"
"CompletedSum":0, TCP_REFRESH_HIT="0"
"Completed":0, TCP_REF_FAIL_HIT="0"
"TimeRes":0, TCP_NEGATIVE_HIT="0"
"TimeComplete":0 TCP_REDIRECT_HIT="0"
} TCP_MISS="0"
}, TCP_REFRESH_MISS="0"
"SSL": TCP_CLIENT_REFRESH_MISS="0"
{ TCP_DENIED="0"
"RecvSize":0, TCP_ERROR="0"/>
"SendSize":0 </Traffic>
}, <FileSystem>
"RequestHit": <GetAttr
{ TimeRes="0"
"TCP_NONE":0, FileCount="0"
"TCP_HIT":0, DirCount="0"
"TCP_IMS_HIT":0, FailCount="0">0</GetAttr>
"TCP_REFRESH_HIT":0, <Open TimeRes="0">0</Open>
"TCP_REF_FAIL_HIT":0, <Read
"TCP_NEGATIVE_HIT":0, TimeRes="0"
"TCP_REDIRECT_HIT":0, BufferSize="0"
"TCP_MISS":0, BufferFilled="0">0</Read>
"TCP_REFRESH_MISS":0, <RequestHit
"TCP_CLIENT_REFRESH_MISS":0, TCP_NONE="0"
"TCP_DENIED":0, TCP_HIT="0"
"TCP_ERROR":0 TCP_IMS_HIT="0"
}, TCP_REFRESH_HIT="0"
"RequestHitSum": TCP_REF_FAIL_HIT="0"
{ TCP_NEGATIVE_HIT="0"
"TCP_NONE":0, TCP_REDIRECT_HIT="0"
"TCP_HIT":0, TCP_MISS="0"
"TCP_IMS_HIT":0, TCP_REFRESH_MISS="0"
"TCP_REFRESH_HIT":0, TCP_CLIENT_REFRESH_MISS="0"
"TCP_REF_FAIL_HIT":0, TCP_DENIED="0"
"TCP_NEGATIVE_HIT":0, TCP_ERROR="0"/>
"TCP_REDIRECT_HIT":0, <RequestHitSum
"TCP_MISS":0, TCP_NONE="0"
"TCP_REFRESH_MISS":0, TCP_HIT="0"
"TCP_CLIENT_REFRESH_MISS":0, TCP_IMS_HIT="0"
"TCP_DENIED":0, TCP_REFRESH_HIT="0"
"TCP_ERROR":0 TCP_REF_FAIL_HIT="0"
}, TCP_NEGATIVE_HIT="0"
"FileSystem": TCP_REDIRECT_HIT="0"
{ TCP_MISS="0"
"GetAttr" : TCP_REFRESH_MISS="0"
{ TCP_CLIENT_REFRESH_MISS="0"
"TimeRes" : 0, TCP_DENIED="0"
"FileCount" : 0, TCP_ERROR="0"/>
"DirCount" : 0, </FileSystem>
"FailCount" : 0, </ClientTraffics>
"TotalCount" : 0
},
"Open" :
{
"TimeRes" : 0,
"Count" : 0
},
"Read" :
{
"TimeRes" : 0,
"BufferSize" : 0,
"BufferFilled" : 0,
"Count" : 0
},
"RequestHit":
{
"TCP_NONE":0,
"TCP_HIT":0,
"TCP_IMS_HIT":0,
"TCP_REFRESH_HIT":0,
"TCP_REF_FAIL_HIT":0,
"TCP_NEGATIVE_HIT":0,
"TCP_REDIRECT_HIT":0,
"TCP_MISS":0,
"TCP_REFRESH_MISS":0,
"TCP_CLIENT_REFRESH_MISS":0,
"TCP_DENIED":0,
"TCP_ERROR":0
},
"RequestHitSum":
{
"TCP_NONE":0,
"TCP_HIT":0,
"TCP_IMS_HIT":0,
"TCP_REFRESH_HIT":0,
"TCP_REF_FAIL_HIT":0,
"TCP_NEGATIVE_HIT":0,
"TCP_REDIRECT_HIT":0,
"TCP_MISS":0,
"TCP_REFRESH_MISS":0,
"TCP_CLIENT_REFRESH_MISS":0,
"TCP_DENIED":0,
"TCP_ERROR":0
}
}
}
]
}
Depth統計情報を収集するディレクトリDepthAccumディレクトリの統計情報が設定されている場合サブディレクトリの統計情報を親ディレクトリに累積させる設定HttpsTrafficHTTPSトラフィックをHTTPトラフィックに重複して集計する設定TrafficCount集計されたトラフィックのカウントTrafficディレクトリ毎の統計情報です。ルート（/）は常に存在します。PathサービスディレクトリHttpReqCount(単位: Bytes)クライアントが送信したHTTPリクエスト数HttpReqHeaderSize(単位: Bytes)クライアントが送信したHTTPリクエストヘッダサイズHttpReqBodySize(単位: Bytes)クライアントが送信したHTTPリクエストBodyサイズHttpResHeaderSize(単位: Bytes)STONが送信されるHTTP応答ヘッダーのサイズHttpResBodySize(単位: Bytes)STONが送信されるHTTPレスポンスBodyサイズResponseSTONが送信応答Count応答回数Completed通常送信完了したHTTPトランザクションの数TimeResHTTP応答時間TimeCompleteHTTPトランザクションの完了時間
SSL(単位: Bytes)HTTPSトラフィック（RecvSize =受信サイズ、SendSize =送信サイズ）RequestHitキャッシュHIT結FileSystemFileSystemアクセスGetAttrgetattr関数呼び出し回数と応答時間。（FileCount：File応答、DirCount：Dir応答、FailCount：失敗応答）Openopen関数の呼び出し回数と応答時間Readread関数の呼び出し回数と応答時間、要求のサイズ（BufferSize）と応答のサイズ（BufferFilled）RequestHit（File I / Oアクセス）キャッシュHIT結果
注釈
5分の統計のみ提供されているアイテムです。
HttpReqCountSumHTTPリクエストの合計回数CountSumHTTP応答の合計回数CompletedSum完了したHTTPトランザクションの合計回数RequestHitSumキャッシュHIT結果
View¶
Viewは仮想ホストを一つにまとめ統計を抽出する方式です。Databaseの複数Tableをあたかも一つであるかのように扱うViewから取った概念です。構成は次のように非常に簡単です。
# vhosts.xml
<Vhosts>
<Vhost> ... </Vhost>
<Vhost> ... </Vhost>
... (省略) ...
<View Name="SK">
<Vhost>...</Vhost>
<Vhost>...</Vhost>
</View>
<View Name="KT">
<Vhost>...</Vhost>
<Vhost>...</Vhost>
<Vhost>...</Vhost>
</View>
<View Name="LG">
<Vhost>...</Vhost>
<Vhost>...</Vhost>
</View>
</Vhosts>
存在しない仮想ホストでViewを構成しても構わない。Viewが提供する統計情報は以下の通りです。
- Realtime XML/JSON
- SNMP - cache(1.3.6.1.4.1.40001.1.4).10 ~ 12
理解を助けるためにViewが必要例を挙げてみよう。Yordanホン・ミンボイム チヨンヨンはそれぞれ自分の好きなスポーツコミュニティサイトを運営します。
# vhosts.xml
<Vhosts>
<Vhost Name="baseball.com"> ... </Vhost>
<Vhost Name="basketball.com"> ... </Vhost>
<Vhost Name="football.com"> ... </Vhost>
</Vhosts>
三人は意気投合しスポーツの総合コミュニティサービスをオープンすることを決定した。ドメインもすべてのサービスを合わせることができるsports.comに決めた。開発/運営チームが解決しなければならミッションは以下の通りです。
- 統合サービスはsports.comとします。
- 既存のユーザーのために既存のドメインとサービスはそのまま維持します。
- 開発チームは統合します。運営チームは統合します。
- メイン（最初のページ）のみ新規開発します。リンクを介して既存のサービスを利用します。
- 予算がない。人がいない。時間がない。精神がない。
- すでにすべての購入手続きが終わった。
このすべての要件を処理する現実的な方法で開発チームは次のように1番目のディレクトリに既存のドメインを指定するルールを使用することを決定した。
# 既存のサービス
http://baseball.com/standing/list.html
http://basketball.com/stats/2014/view.html
http://football.com/player/messi.php
# 統合サービス
http://sports.com/baseball/standing/list.html
http://sports.com/basketball/stats/2014/view.html
http://sports.com/football/player/messi.php
URLの前処理を使用すると簡単に設定することができます。
# vhosts.xml
<Vhosts>
<Vhost Name="baseball.com"> ... </Vhost>
<Vhost Name="basketball.com"> ... </Vhost>
<Vhost Name="football.com"> ... </Vhost>
<URLRewrite>
<Pattern>sports.com/(.*)/(.*)</Pattern>
<Replace>#1.com/#2</Replace>
</URLRewrite>
</Vhosts>
統合された運営チームでは現在それぞれのサービスだけでなく統合されたサービス（交通、セッション、応答コードなど）にもモニタリングする必要があります。ほとんどSNMPに慣れている管理者であり統合された指標を得るためには次のようにViewを構成します。
# vhosts.xml
<Vhosts>
<Vhost Name="baseball.com"> ... </Vhost>
<Vhost Name="basketball.com"> ... </Vhost>
<Vhost Name="football.com"> ... </Vhost>
<URLRewrite>
<Pattern>sports.com/(.*)/(.*)</Pattern>
<Replace>#1.com/#2</Replace>
</URLRewrite>
<View Name="sports.com">
<Vhost>baseball.com</Vhost>
<Vhost>basketball.com</Vhost>
<Vhost>football.com</Vhost>
</View>
</Vhosts>
以上の例からわかるようにURL RewriteとViewの組み合わせは既存のサイトを一つにまとめてサービスするときに効果的です。
View統計¶
仮想ホストと同じ統計を提供します。次のようにタグ名のみ異なる。
"View": <View ...>
[ ...
{ ... }, </View>
{ ... }, <View> ... </View>
] <View> ... </View>
仮想ホストのリスト参照¶
仮想ホストのリストを照会します。
http://127.0.0.1:10040/monitoring/vhostslist
結果はJSON形式で提供されます。
{
"version": "2.0.0",
"method": "vhostslist",
"status": "OK",
"result": [ "www.example.com","www.winesoft.com", "site1.com" ]
}
キャッシュ情報¶
キャッシュしているファイルの状態をモニタリングします。一般的にファイルはURLで区切られますが同じURLに他のオプション(i.e. Accept-Encodingなど)が存在する場合複数のファイルが存在することができます。
http://127.0.0.1:10040/monitoring/fileinfo?url=example.com/sample.dat
結果はJSON形式で提供されます。以下は/sample.datファイルの情報を閲覧した結果です。
{
"version": "2.0.0",
"method": "fileinfo",
"status": "OK",
"result":
[
{
"URI": "/sample.dat",
"Accept-Encoding": "N",
"RefCount": 0,
"Disk-Index": 0,
"Size": 2100267,
"FID": 24267,
"LocalPath": "/cache1/example.com/000i/q3.bin",
"File-Opened ": "N",
"File-Updating": "-",
"Downloader-Count": "0",
"LastAccess": "[ 2012.09.03 14:29:50, -2 ]",
"UpdateTime": "[ 2012.09.03 13:53:43, -2169 ]",
"TTL-Left": "[ 2012.10.03 13:53:43, 2589831 ]",
"ResponseCode": 200,
"ContentType": "text/plain",
"LastModifiedTime": "[ 2010.11.22 20:31:47, -56224685 ]",
"ExpireTime": "[ 0, 0 ]",
"CacheControl": "not-specified",
"ETag": "502dd614:200c2b",
"CustomTTL": 0,
"NoMoreExist": "N",
"LocalFileExist": "Y",
"SmallFile": "N",
"State": "Cached",
"Deleted": "N",
"AddedSize": "Y",
"TransferEncoding": "N",
"Compression": "-",
"Purge": "N",
"Ignore-IMS ": "N",
"Redirect-Location ": "-",
"Content-Disposition ": "-",
"NoCache": "N"
}
]
}
URIファイルURIAccept-Encoding("Y" or "N") Accept-Encodingをサポートする場合は "Y"RefCountファイルの参照カウントSize(Bytes) ファイルサイズDisk-Index(0から始まる) 保存されたディスクのインデックスFIDファイルIDLocalPathローカルパスFile-Opened("Y" or "N") ローカルファイルを開き場合 "Y"File-Updatingファイルを更新している場合更新するオブジェクトのポインタが明示Downloader-Countオリジンサーバーではこのファイルをダウンロードする現在のセッションの数LastAccess(最後のアクセス時間、最後のアクセス時間 - 現在時刻) [ 2012.09.03 14:29:50, -2 ]の意味は2012.09.03 14:29:50にアクセスされ現在から2秒前にアクセスされたという意味です。UpdateTime(更新時間、更新時間 - 現在時刻) ファイルが最後に更新された時間。304 Not Modifiedも時間は更新されます。TTL-Left(有効期限、有効期限 - 現在時刻) コンテンツの有効期限予定の時間。TTLが残ったら正であり有効期限が切れたとすれば負の表記されます。ResponseCodeオリジンサーバーの応答コードContentTypeMIME TypeLastModifiedTime(Last Modified Time, Last Modified Time`` 現在時刻) オリジンサーバーが送信Last Modified Time。オリジンサーバーがこの値を送信していない場合0に表示されます。ExpireTimeソースサーバーが送信したExpire Time。ソースサーバーが、この値を送信していない場合、0に表示される。CacheControl("no-cache" or "not-specified" or (整数））オリジンサーバーが送信したCache-Contorl値ETagSTONが生成したETagCustomTTLカスタムTTL。設定されていない場合0です。NoMoreExist("Y" or "N") ファイルを破棄予約されている場合は "Y"LocalFileExist("Y" or "N") ローカルにファイルが存在する場合 "Y" (200 OK以外のファイルは常に "Y")SmallFile("Y" or "N") ファイルを小さなファイルに判断すれば "Y" (開発的な理由)State("Not Init" or "Cached" or "Error") ファイルの状態Deleted("Y" or "N") を削除された場合は "Y" (開発的な理由)AddedSize("Y" or "N") のサイズは統計に反映されている場合は "Y" (開発的な理由)TransferEncoding("Y" or "N") Transfer-Encodingをサポートする場合は "Y"Compression圧縮方式Purge("Y" or "N") Purgeたなら "Y"Ignore-IMS("Y" or "N") 更新するとIf-Modified-Sinceヘッダを送信しないように設定された場合は "Y"Redirect-LocationLocationヘッダの値Content-DispositionContent-Dispositionヘッダの値NoCache("Y" or "N") オリジンサーバーでno-cache応答を与えた場合 "Y"
Log Trace¶
記録されたログをリアルタイムで受けてみます。Access、Origin、Monitoingログは仮想ホスト（vhost）を指定する必要があります。
http://127.0.0.1:10040/monitoring/logtrace/info
http://127.0.0.1:10040/monitoring/logtrace/deny
http://127.0.0.1:10040/monitoring/logtrace/sys
http://127.0.0.1:10040/monitoring/logtrace/originerror
http://127.0.0.1:10040/monitoring/logtrace/access?vhost=www.site1.com
http://127.0.0.1:10040/monitoring/logtrace/origin?vhost=www.site1.com
http://127.0.0.1:10040/monitoring/logtrace/monitoring?vhost=www.site1.com
第11章 SNMP¶
この章ではSNMP（Simple Network Management Protocol）について説明します。 第10章 モニタリング＆統計 のすべての数値はSNMPでさらに細分化された時間の単位とシステムの状態情報まで提供します。 仮想ホストごとにリアルタイムの統計情報と最大60分まで "分" 単位の平均統計を提供します。
- 別のパッケージが必要ない。
- snmpdを個別に実行しません。
- SNMP v1およびv2cをサポートします。
変数¶
設定やユーザーの意図によって変更されることができる値を[変数名]に指定します。 たとえばディスクは複数が存在することができます。 この場合各ディスクを指す一意の番号が必要であり入力された順に1から割り当てられる。 このような変数を [diskIndex] で指定します。
[diskIndex]Storageに設定されたディスクを意味します。
# server.xml - <Server><Cache> <Storage> <Disk>/cache1</Disk> <Disk>/cache2</Disk> <Disk>/cache3</Disk> </Storage>
上記のように3つのディスクが設定された環境では/ cache1の
[diskIndex]は1/ cache3の[diskIndex]は3を有します。 例えば/ cache1の全容量に対応するOIDはsystem.diskInfo.diskInfoTotalSize.1（1.3.6.1.4.1.40001.1.2.18.1.3）1となる。 最後.1は最初のディスクを意味します。[vhostIndex]仮想ホストがロードされるときに自動的に付与されます。
# vhosts.xml <Vhosts> <Vhost Status="Active" Name="kim.com"> ... </Vhost> <Vhost Status="Active" Name="lee.com"> ... </Vhost> <Vhost Status="Active" Name="park.com" StaticIndex="10300"> ... </Vhost> </Vhosts>
最初上記のよう3つの仮想ホストがロードされると1から順番に
[vhostIndex]が付与されます。 以降仮想ホストは[vhostIndex]を記憶し仮想ホストが削除されても[vhostIndex]は変わらない。 仮想ホストの削除と追加が同時に発生した場合削除は最初に動作し新規追加された仮想ホストは空の[vhostIndex]を与えられる。
[vhostIndex]の動作[diskMin]、[vhostMin]時間（分）を意味します。 5は5分の平均を意味し60は60分の平均を意味します。 この値は1（分）から60（分）までの範囲を持ち0はリアルタイム（1秒）のデータを意味します。
SNMPは動的に値が変わることができる項目についてTable構造を使用します。 たとえば「ディスク全体のサイズ」はディスクの数に応じて提供するデータ数が変わるためTable構造を使用して表現する必要があります。 STONはすべての仮想ホストに対して「分」単位の統計情報を提供します。 したがって [vhostMin] . [vhostIndex] という多少難解な表現を提供します。
この表現は仮想ホストごとに必要な "分" 単位の統計情報を見ることができる利点を持っているが変数が2つなのでTable構造で表現するのは難しいという短所があります。 このような問題を克服するために [vhostMin] のデフォルト値を設定してSNMPWalkが動作できるようにします。
有効¶
グローバル設定（server.xml）を介してSNMP動作とACLを設定します。
# server.xml - <Server><Host>
<SNMP Port="161" Status="Inactive">
<Allow>192.168.5.1</Allow>
<Allow>192.168.6.0/24</Allow>
</SNMP>
<SNMP>プロパティを介してSNMPの動作を設定します。Port (デフォルト: 161)SNMPサービスポートStatus (デフォルト: Inactive)SNMPを有効にするにはこの値をActiveに設定します。
<Allow>SNMPアクセスを許可するIPアドレスを設定します。- IPの指定、IPアドレスの範囲を指定、ビットマスク、サブネット上四つの形式をサポートします。 接続したソケットが許可されたIPアドレスがなければ応答を与えない。
仮想ホスト/ View変数¶
SNMPを介して提供される仮想ホスト/ View数とデフォルト時間（分）を設定します。
# server.xml - <Server><Host>
<SNMP VHostCount=0, VHostMin=5 ViewCount=0, ViewMin=5 />
VHostCount (デフォルト: 0)0の場合存在する仮想ホストまでの応答をします。 0よりも大きい値である場合は仮想ホストの存在の有無に関係なく設定された仮想ホストまでの応答です。ViewCount (デフォルト: 0)Viewに適用します。 (VHostCountと同じ)VHostMin (デフォルト: 5分, 最大: 60分)[vhostMin]の値を設定します。 0〜60までの値を有します。 0の場合リアルタイムのデータを提供して1〜60の間である場合はその分だけの平均値を提供します。ViewMin (デフォルト: 0)Viewに適用します。 (VHostMinと同じ)
たとえば3つの仮想ホストが設定されている環境でSNMPWalkの動作が変わります。
VHostCount=0の場合
SNMPv2-SMI::enterprises.40001.1.4.2.1.2.1 = STRING: "web.winesoft.co.kr" SNMPv2-SMI::enterprises.40001.1.4.2.1.2.2 = STRING: "img.winesoft.co.kr" SNMPv2-SMI::enterprises.40001.1.4.2.1.2.3 = STRING: "vod.winesoft.co.kr"
VHostCount=5の場合
SNMPv2-SMI::enterprises.40001.1.4.2.1.2.1 = STRING: "web.winesoft.co.kr" SNMPv2-SMI::enterprises.40001.1.4.2.1.2.2 = STRING: "img.winesoft.co.kr" SNMPv2-SMI::enterprises.40001.1.4.2.1.2.3 = STRING: "vod.winesoft.co.kr" SNMPv2-SMI::enterprises.40001.1.4.2.1.2.4 = "" SNMPv2-SMI::enterprises.40001.1.4.2.1.2.5 = ""
その他の変数¶
その他の変数を設定します。
# server.xml - <Server><Host>
<SNMP GlobalMin="5" DiskMin="5" ConfCount="10" />
GlobalMin (デフォルト: 5分, 最大: 60分)[globalMin]の値を設定します。DiskMin (デフォルト: 5分, 最大: 60分)[diskMin]の値を設定します。ConfCount (デフォルト: 10)設定のリストをn個まで閲覧します。 1〜100の間で指定可能です。 1は現在の反映の設定を意味し2は以前の設定を意味します。 100は現在を基準に99回前の設定を意味します。
Community¶
Communityを設定して許可されたOIDのみアクセス/ブロックするように設定します。
# server.xml - <Server><Host>
<SNMP UnregisteredCommunity="Allow">
<Community Name="example1" OID="Allow">
<OID>1.3.6.1.4.1.40001.1.4.1</OID>
<OID>1.3.6.1.4.1.40001.1.4.2</OID>
<OID>1.3.6.1.4.1.40001.1.4.4</OID>
</Community>
<Community Name="example2" OID="Deny">
<OID>1.3.6.1.4.1.40001.1.4.3.1.11.11.10.1-61</OID>
</Community>
</SNMP>
<SNMP> の UnregisteredCommunity を "Deny"に設定すると登録されていないCommunity要求は遮断します。
<Community>Communityを設定します。NameCommunity 名。OID (デフォルト: Allow)サブ<OID>タグの値を設定します。 属性値がAllowであればサブ<OID>リストのみがアクセス可能です。 反対に属性値がDenyであればサブ<OID>リストにはアクセスが不可能です。
明示的なOID（1.3.6.1.4.1.40001.1.4.4）と範囲（OID 1.3.6.1.4.1.40001.1.4.3.1.11.11.10.1-61）表現が可能です。 OIDを許可/遮断する場合はサブすべてのOIDに対して同じルールが適用されます。
meta¶
OID = 1.3.6.1.4.1.40001.1.1
メタ情報を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
| .1 | manufacture | String | "WineSOFT Inc." |
| .2 | software | String | "STON" |
| .3 | version | String | バージョン |
| .4 | hostname | String | ホスト名 |
| .5 | state | String | "Healthy" または "Inactive" または "Emergency" |
| .6 | uptime | Integer | 実行時間（秒) |
| .7 | admin | String | <Admin> ... </Admin> |
| .10 | Conf | OID | Conf 拡張 |
meta.conf¶
OID = 1.3.6.1.4.1.40001.1.1.10
[confIndex] は <SNMP> の ConfCount 属性で設定します。
[confIndex] が1の場合は常に現在適用され設定値を2の場合は以前の設定値を意味します。 10であれば現在の（1）から9の前の設定を意味します。
| OID | Name | Type | Description |
|---|---|---|---|
.1. [confIndex] |
ID | Integer | 設定ID |
.2. [confIndex] |
Time | Integer | 設定時間（Unix時間） |
.3. [confIndex] |
Type | Integer | 設定モード (0 = Unknown、 1 = STON 開始、 2 = /conf/reload、 3 = /conf/upload、 4 = /conf/restore) |
.4. [confIndex] |
Size | Integer | 設定ファイルサイズ |
.5. [confIndex] |
Hash | String | 設定ファイルHashの文字列 |
.6. [confIndex] |
Path | String | 設定ファイルの保存パス |
.7. [confIndex] |
Ver | String | 設定時のSTONバージョン |
system¶
OID = 1.3.6.1.4.1.40001.1.2
STONが動作するシステムの情報を提供します。
[sysMin] 変数は0〜60分までの値を持ちリアルタイムまたは必要な時間だけの平均値を提供します。 SNMPWalkで [sysMin] は0に設定され現在の情報を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
.1. [sysMin] |
cpuTotal | Integer | 全体のCPU使用率 (100%) |
.2. [sysMin] |
全体のCPU使用率 (10000%) | ||
.3. [sysMin] |
cpuKernel | Integer | CPU(Kernel) の使用率 (100%) |
.4. [sysMin] |
CPU(Kernel) の使用率 (10000%) | ||
.5. [sysMin] |
cpuUser | Integer | CPU(User) の使用率 (100%) |
.6. [sysMin] |
CPU(User) の使用率 (10000%) | ||
.7. [sysMin] |
cpuIdle | Integer | CPU(Idle) の使用率 (100%) |
.8. [sysMin] |
CPU(Idle) の使用率 (10000%) | ||
| .9 | memTotal | Integer | システム全体のメモリ (KB) |
.10. [sysMin] |
memUse | Integer | システムの使用メモリ (KB) |
.11. [sysMin] |
memFree | Integer | システムの空きメモリ (KB) |
.12. [sysMin] |
memSTON | Integer | STON使用メモリ (KB) |
.13. [sysMin] |
memUseRatio | Integer | システムメモリの使用率 (100%) |
.14. [sysMin] |
システムメモリの使用率 (10000%) | ||
.15. [sysMin] |
memSTONRatio | Integer | STON メモリ使用率 (100%) |
.16. [sysMin] |
STON メモリ使用率 (10000%) | ||
| .17 | diskCount | Integer | disk数 |
| .18.1 | diskInfo | OID | diskInfo拡張 |
| .19.1 | diskPerf | OID | diskPerf拡張 |
.20. [sysMin] |
cpuProcKernel | Integer | STONが使用するCPU（Kernel）の使用率 (100%) |
.21. [sysMin] |
STONが使用するCPU（Kernel）の使用率 (10000%) | ||
.22. [sysMin] |
cpuProcUser | Integer | STONが使用するCPU（User）の使用率 (100%) |
.23. [sysMin] |
STONが使用するCPU（User）の使用率 (10000%) | ||
.24. [sysMin] |
sysLoadAverage | Integer | Load Average 1分平均 (0.01) |
.25. [sysMin] |
Load Average 5分平均 (0.01) | ||
.26. [sysMin] |
Load Average 15分平均 (0.01) | ||
.27. [sysMin] |
cpuNice | Integer | CPU(Nice) (100%) |
.28. [sysMin] |
CPU(Nice) (10000%) | ||
.29. [sysMin] |
cpuIOWait | Integer | CPU(IOWait) (100%) |
.30. [sysMin] |
CPU(IOWait) (10000%) | ||
.31. [sysMin] |
cpuIRQ | Integer | CPU(IRQ) (100%) |
.32. [sysMin] |
CPU(IRQ) (10000%) | ||
.33. [sysMin] |
cpuSoftIRQ | Integer | CPU(SoftIRQ) (100%) |
.34. [sysMin] |
CPU(SoftIRQ) (10000%) | ||
.35. [sysMin] |
cpuSteal | Integer | CPU(Steal) (100%) |
.36. [sysMin] |
CPU(Steal) | Integer | (10000%) |
.40. [sysMin] |
TCPSocket.Established. [globalMin] |
Integer | Established状態のTCP接続数 |
.41. [sysMin] |
TCPSocket.Timewait. [globalMin] |
Integer | TIME_WAIT状態のTCP接続数 |
.42. [sysMin] |
TCPSocket.Orphan. [globalMin] |
Integer | まだfile handleにattachされていないTCP接続 |
.43. [sysMin] |
TCPSocket.Alloc. [globalMin] |
Integer | 割り当てられたTCP接続 |
.44. [sysMin] |
TCPSocket.Mem. [globalMin] |
Integer | undocumented |
system.diskInfo¶
OID = 1.3.6.1.4.1.40001.1.2.18.1
ディスクの情報を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
.2. [diskIndex] |
diskInfoPath | String | ディスクパス |
.3. [diskIndex] |
diskInfoTotalSize | Integer | ディスク全体の容量 (MB) |
.4. [diskIndex] |
diskInfoUseSize | Integer | ディスク使用量 (MB) |
.5. [diskIndex] |
diskInfoFreeSize | Integer | ディスクの使用可能量 (MB) |
.6. [diskIndex] |
diskInfoUseRatio | Integer | ディスク使用率 (100%) |
.7. [diskIndex] |
ディスク使用率 (10000%) | ||
.8. [diskIndex] |
diskInfoStatus | String | "Normal" または "Invalid" または "Unmounted" |
system.diskPerf¶
OID = 1.3.6.1.4.1.40001.1.2.19.1
ディスクパフォーマンスの状態を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
.2. [diskMin] . [diskIndex] |
diskPerfReadCount | Integer | 読み込み成功回数 |
.3. [diskMin] . [diskIndex] |
diskPerfReadMergedCount | Integer | 読み込みがマージされた回数 |
.4. [diskMin] . [diskIndex] |
diskPerfReadSectorsCount | Integer | 読んだセクタ数 |
.5. [diskMin] . [diskIndex] |
diskPerfReadTime | Integer | 読む時間(ms) |
.6. [diskMin] . [diskIndex] |
diskPerfWriteCount | Integer | 執筆成功回数 |
.7. [diskMin] . [diskIndex] |
diskPerfWriteMergedCount | Integer | 書き込みがマージされた回数 |
.8. [diskMin] . [diskIndex] |
diskPerfWriteSectorsCount | Integer | 書かれているセクタ数 |
.9. [diskMin] . [diskIndex] |
diskPerfWriteTime | Integer | 書き込み時間(ms) |
.10. [diskMin] . [diskIndex] |
diskPerfIOProgressCount | Integer | 進行中のIO数 |
.11. [diskMin] . [diskIndex] |
diskPerfIOTime | Integer | IO 所要時間(ms) |
.12. [diskMin] . [diskIndex] |
diskPerfIOTimeWeighted | Integer | IO 所要時間(ms、重み付け) |
global¶
OID = 1.3.6.1.4.1.40001.1.3
STONのすべてのモジュールが共通で使用するリソース情報（ソケット、イベントなど）を提供します。
ServerSocket
クライアント〜STON区間。 STONがクライアントの要求を処理する目的で使用されるソケット
ClientSocket
STON〜オリジンサーバー区間。 STONがオリジンサーバーに要求を送信する目的で使用されるソケット
| OID | Name | Type | Description |
|---|---|---|---|
| .5 | EQ. [globalMin] |
Integer | STON Frameworkでまだ処理されていないEvent数 |
| .6 | RQ. [globalMin] |
Integer | 最近サービスされたコンテンツを参照キューに保存されたEvent数 |
| .7 | waitingFiles2Write. [globalMin] |
Integer | 書き込み待機中のファイルの数 |
| .10 | ServerSocket.Total. [globalMin] |
Integer | サーバー全体のソケット数 |
| .11 | ServerSocket.Established. [globalMin] |
Integer | 接続された状態のサーバソケット数 |
| .12 | ServerSocket.Accepted. [globalMin] |
Integer | 新たに接続されたサーバソケットができ |
| .13 | ServerSocket.Closed. [globalMin] |
Integer | 接続が終了されたサーバーソケット数 |
| .20 | ClientSocket.Total. [globalMin] |
Integer | 全クライアントソケットの数 |
| .21 | ClientSocket.Established. [globalMin] |
Integer | 接続された状態のクライアントソケット数 |
| .22 | ClientSocket.Accepted. [globalMin] |
Integer | 新たに接続されたクライアントソケット数 |
| .23 | ClientSocket.Closed. [globalMin] |
Integer | 接続が終了したクライアントソケット数 |
| .30 | ServiceAccess.Allow. [globalMin] |
Integer | ServiceAccessによって許可（Allow）されたソケット数 |
| .31 | ServiceAccess.Deny. [globalMin] |
Integer | ServiceAccessによって拒否（Deny）されたソケット数 |
cache¶
OID = 1.3.6.1.4.1.40001.1.4
キャッシュサービスの統計情報は仮想ホストごとに詳細に収集/提供されます。
| OID | Name | Type | Description |
|---|---|---|---|
| .1 | host | OID | ホスト（拡張) |
| .2 | vhostCount | Integer | 仮想ホストの数 |
| .3.1 | vhost | OID | 仮想ホスト別の統計 |
| .4 | vhostIndexMax | Integer | [vhostIndex] 最大値。 SNMPWalkはこの数値を基準に動作します。 |
| .10 | viewCount | Integer | View数 |
| .11.1 | view | OID | View別統計 |
| .12 | viewIndexMax | Integer | [viewIndex] 最大値。 SNMPWalkはこの数値を基準に動作します。 |
cache.host¶
OID = 1.3.6.1.4.1.40001.1.4.1
ホスト（=すべての仮想ホスト）の情報を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
| .2 | name | String | ホスト名 |
| .3 | status | String | "Healthy" または "Inactive" |
| .4 | uptime | Integer | STON実行時間（秒） |
| .10 | contents | OID | コンテンツ情報（拡張） |
| .11 | traffic | OID | 統計（拡張） |
cache.host.contents¶
OID = 1.3.6.1.4.1.40001.1.4.1.10
ホスト（=すべての仮想ホスト）がサービスするコンテンツ情報を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
| .1 | memory | Integer | メモリキャッシュサイズ(KB) |
| .2 | filesTotalCount | Integer | サービス中のファイル数 |
| .3 | filesTotalSize | Integer | サービス中の全ファイル量(MB) |
| .10 | filesCountU1KB | Integer | 1KB未満のファイル数 |
| .11 | filesCountU2KB | Integer | 2KB未満のファイル数 |
| .12 | filesCountU4KB | Integer | 4KB未満のファイル数 |
| .13 | filesCountU8KB | Integer | 8KB未満のファイル数 |
| .14 | filesCountU16KB | Integer | 16KB未満のファイル数 |
| .15 | filesCountU32KB | Integer | 32KB未満のファイル数 |
| .16 | filesCountU64KB | Integer | 64KB未満のファイル数 |
| .17 | filesCountU128KB | Integer | 128KB未満のファイル数 |
| .18 | filesCountU256KB | Integer | 256KB未満のファイル数 |
| .19 | filesCountU512KB | Integer | 512KB未満のファイル数 |
| .20 | filesCountU1MB | Integer | 1MB未満のファイル数 |
| .21 | filesCountU2MB | Integer | 2MB未満のファイル数 |
| .22 | filesCountU4MB | Integer | 4MB未満のファイル数 |
| .23 | filesCountU8MB | Integer | 8MB未満のファイル数 |
| .24 | filesCountU16MB | Integer | 16MB未満のファイル数 |
| .25 | filesCountU32MB | Integer | 32MB未満のファイル数 |
| .26 | filesCountU64MB | Integer | 64MB未満のファイル数 |
| .27 | filesCountU128MB | Integer | 128MB未満のファイル数 |
| .28 | filesCountU256MB | Integer | 256MB未満のファイル数 |
| .29 | filesCountU512MB | Integer | 512MB未満のファイル数 |
| .30 | filesCountU1GB | Integer | 1GB未満のファイル数 |
| .31 | filesCountU2GB | Integer | 2GB未満のファイル数 |
| .32 | filesCountU4GB | Integer | 4GB未満のファイル数 |
| .33 | filesCountU8GB | Integer | 8GB未満のファイル数 |
| .34 | filesCountU16GB | Integer | 16GB未満のファイル数 |
| .35 | filesCountO16GB | Integer | 16GB以上のファイル数 |
cache.host.traffic¶
OID = 1.3.6.1.4.1.40001.1.4.1.11
ホスト（=すべての仮想ホスト）のキャッシュサービスとトラフィックの統計情報を提供します。 trafficのすべての統計情報は最大60分までの平均で提供します。 minは '分'を意味し最大60までの値を有します。 minが省略されたり0であればリアルタイムの情報を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
.1. [vhostMin] |
requestHitRatio | Integer | Request Hit Ratio(100%) |
.2. [vhostMin] |
Request Hit Ratio(10000%) | ||
.3. [vhostMin] |
bytesHitRatio | Integer | Bytes Hit Ratio(100%) |
.4. [vhostMin] |
Bytes Hit Ratio(10000%) | ||
| .10 | origin | OID | オリジントラフィック情報（拡張） |
| .11 | client | OID | クライアントのトラフィック情報（拡張） |
cache.host.traffic.origin¶
OID = 1.3.6.1.4.1.40001.1.4.1.11.10
オリジンサーバートラフィックの統計情報を提供します。 オリジンサーバーのトラフィックはHTTPトラフィックとPortバイパストラフィックに区分します。
| OID | Name | Type | Description |
|---|---|---|---|
.1. [vhostMin] |
inbound | Integer | オリジンサーバーから受信し平均トラフィック(Bytes) |
.2. [vhostMin] |
outbound | Integer | オリジンサーバーに送信平均トラフィック(Bytes) |
.3. [vhostMin] |
sessionAverage | Integer | 全体オリジンサーバーの平均セッション数 |
.4. [vhostMin] |
activesessionAverage | Integer | 全体オリジンサーバーセッションの中で送信されているセッションの平均数 |
| .10 | http | OID | オリジンサーバーのHTTPトラフィック情報 |
.10.1. [vhostMin] |
http.inbound | Integer | オリジンサーバーから受信し平均のHTTPトラフィック(Bytes) |
.10.2. [vhostMin] |
http.outbound | Integer | オリジンサーバーに送信平均HTTPトラフィック(Bytes) |
.10.3. [vhostMin] |
http.sessionAverage | Integer | オリジンサーバーの平均HTTPセッション数 |
.10.4. [vhostMin] |
http.reqHeaderSize | Integer | オリジンサーバーに送信平均HTTP Headerトラフィック(Bytes) |
.10.5. [vhostMin] |
http.reqBodySize | Integer | オリジンサーバーに送信平均HTTP Bodyトラフィック(Bytes) |
.10.6. [vhostMin] |
http.resHeaderSize | Integer | オリジンサーバーから受信し平均HTTP Headerトラフィック(Bytes) |
.10.7. [vhostMin] |
http.resBodySize | Integer | オリジンサーバーから受信し平均HTTP Bodyトラフィック(Bytes) |
.10.8. [vhostMin] |
http.reqAverage | Integer | オリジンサーバーに送信される平均HTTPリクエスト数 |
.10.9. [vhostMin] |
http.reqCount | Integer | オリジンサーバーに送信されるHTTPリクエスト数 |
.10.10. [vhostMin] |
http.resTotalAverage | Integer | オリジンサーバーが送信した全体の平均HTTP応答数 |
.10.11. [vhostMin] |
http.resTotalCompleteAverage | Integer | オリジンサーバーから成功した平均HTTPトランザクション数 |
.10.12. [vhostMin] |
http.resTotalTimeRes | Integer | オリジンサーバーからの応答ヘッダを受信するまでの平均所要時間(0.01ms) |
.10.13. [vhostMin] |
http.resTotalTimeComplete | Integer | オリジンサーバーからの応答HTTP Transaction平均完了時間(0.01ms) |
.10.14. [vhostMin] |
http.resTotalCount | Integer | オリジンサーバーが送信した完全なHTTP応答数 |
.10.15. [vhostMin] |
http.resTotalCompleteCount | Integer | オリジンサーバーから成功したHTTPトランザクション数 |
.10.20. [vhostMin] |
http.res2xxAverage | Integer | オリジンサーバーが送信した平均2xx応答数 |
.10.21. [vhostMin] |
http.res2xxCompleteAverage | Integer | オリジンサーバーから成功した平均2xxトランザクション数 |
.10.22. [vhostMin] |
http.res2xxTimeRes | Integer | オリジンサーバーから2xxレスポンスヘッダを受信するまでの平均所要時間(0.01ms) |
.10.23. [vhostMin] |
http.res2xxTimeComplete | Integer | オリジンサーバーから2xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.24. [vhostMin] |
http.res2xxCount | Integer | オリジンサーバーが送信した2xx応答数 |
.10.25. [vhostMin] |
http.res2xxCompleteCount | Integer | オリジンサーバーから成功した2xxトランザクション数 |
.10.30. [vhostMin] |
http.res3xxAverage | Integer | オリジンサーバーが送信した平均3xx応答数 |
.10.31. [vhostMin] |
http.res3xxCompleteAverage | Integer | オリジンサーバーから成功した平均3xxトランザクション数 |
.10.32. [vhostMin] |
http.res3xxTimeRes | Integer | オリジンサーバーから3xx応答ヘッダを受信するまでの平均所要時間(0.01ms) |
.10.33. [vhostMin] |
http.res3xxTimeComplete | Integer | オリジンサーバーから3xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.34. [vhostMin] |
http.res3xxCount | Integer | オリジンサーバーが送信した3xx応答数 |
.10.35. [vhostMin] |
http.res3xxCompleteCount | Integer | オリジンサーバーから成功した3xxトランザクション数 |
.10.40. [vhostMin] |
http.res4xxAverage | Integer | オリジンサーバーが送信した平均4xx応答数 |
.10.41. [vhostMin] |
http.res4xxCompleteAverage | Integer | オリジンサーバーから成功した平均4xxトランザクション数 |
.10.42. [vhostMin] |
http.res4xxTimeRes | Integer | オリジンサーバーから4xx応答ヘッダを受信するまでの平均所要時間（0.01ms） |
.10.43. [vhostMin] |
http.res4xxTimeComplete | Integer | オリジンサーバーから4xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.44. [vhostMin] |
http.res4xxCount | Integer | オリジンサーバーが送信した4xx応答数 |
.10.45. [vhostMin] |
http.res4xxCompleteCount | Integer | オリジンサーバーから成功した4xxトランザクション数 |
.10.50. [vhostMin] |
http.res5xxAverage | Integer | オリジンサーバーが送信した平均5xx応答数 |
.10.51. [vhostMin] |
http.res5xxCompleteAverage | Integer | オリジンサーバーから成功した平均5xxトランザクション数 |
.10.52. [vhostMin] |
http.res5xxTimeRes | Integer | オリジンサーバーから5xx応答ヘッダを受信するまでの平均所要時間(0.01ms) |
.10.53. [vhostMin] |
http.res5xxTimeComplete | Integer | オリジンサーバーから5xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.54. [vhostMin] |
http.res5xxCount | Integer | オリジンサーバーが送信した5xx応答数 |
.10.55. [vhostMin] |
http.res5xxCompleteCount | Integer | オリジンサーバーから成功した5xxトランザクション数 |
.10.60. [vhostMin] |
http.connectTimeoutAverage | Integer | 平均オリジンサーバー接続に失敗した回数 |
.10.61. [vhostMin] |
http.receiveTimeoutAverage | Integer | 平均元サーバー送信に失敗した回数 |
.10.62. [vhostMin] |
http.connectAverage | Integer | 平均オリジンサーバー接続成功回数 |
.10.63. [vhostMin] |
http.dnsQueryTime | Integer | オリジンサーバー接続時の平均DNSクエリの所要時間 |
.10.64. [vhostMin] |
http.connectTime | Integer | オリジンサーバーの平均接続時間(0.01ms) |
.10.65. [vhostMin] |
http.connectTimeoutCount | Integer | オリジンサーバー接続に失敗した回数 |
.10.66. [vhostMin] |
http.receiveTimeoutCount | Integer | オリジンサーバーの転送に失敗した回数 |
.10.67. [vhostMin] |
http.connectCount | Integer | オリジンサーバー接続成功回数 |
.10.68. [vhostMin] |
http.closeAverage | Integer | 転送中のオリジンサーバーから先にソケットを終了した平均回数 |
.10.69. [vhostMin] |
http.closeCount | Integer | 転送中のオリジンサーバーから先にソケットを終了した回数 |
| .11 | portbypass | OID | Portバイパス元サーバーのトラフィック情報 |
.11.1. [vhostMin] |
portbypass.inbound | Integer | Portバイパスを介してオリジンサーバーから受け取る平均トラフィック(Bytes) |
.11.2. [vhostMin] |
portbypass.outbound | Integer | Portバイパスを介してオリジンサーバーに送信する平均トラフィック(Bytes) |
.11.3. [vhostMin] |
portbypass.sessionAverage | Integer | Portバイパス中の平均オリジンサーバーのセッション数 |
.11.4. [vhostMin] |
portbypass.closedAverage | Integer | Portバイパス中のオリジンサーバーが接続を終了した平均回数 |
.11.5. [vhostMin] |
portbypass.connectTimeoutAverage | Integer | Portバイパスオリジンサーバーの平均接続失敗回数 |
.11.6. [vhostMin] |
portbypass.closedCount | Integer | Portバイパス中のオリジンサーバーが接続を終了した回数 |
.11.7. [vhostMin] |
portbypass.connectTimeoutCount | Integer | Portバイパスオリジンサーバー接続に失敗した回数 |
cache.host.traffic.client¶
OID = 1.3.6.1.4.1.40001.1.4.1.11.11
クライアントトラフィックの統計情報を提供します。 クライアントのトラフィックはHTTPトラフィックはSSLトラフィックPortバイパストラフィックに区分されます。 SNMPではディレクトリごとの統計を提供しません。 たとえディレクトリの統計情報が設定されているとしても合算されています。
| OID | Name | Type | Description |
|---|---|---|---|
.1. [vhostMin] |
inbound | Integer | クライアントから受信平均トラフィック(Bytes) |
.2. [vhostMin] |
outbound | Integer | クライアントに送信平均トラフィック(Bytes) |
.3. [vhostMin] |
sessionAverage | Integer | 完全なクライアントの平均セッション数 |
.4. [vhostMin] |
activesessionAverage | Integer | 全クライアントの転送中の平均セッション数 |
| .10 | http | OID | クライアントのHTTPトラフィック情報 |
.10.1. [vhostMin] |
http.inbound | Integer | クライアントから受信平均HTTPトラフィック(Bytes) |
.10.2. [vhostMin] |
http.outbound | Integer | クライアントに送信平均HTTPトラフィック(Bytes) |
.10.3. [vhostMin] |
http.sessionAverage | Integer | クライアントの平均HTTPセッション数 |
.10.4. [vhostMin] |
http.reqHeaderSize | Integer | クライアントから受信平均HTTP Headerトラフィック(Bytes) |
.10.5. [vhostMin] |
http.reqBodySize | Integer | クライアントから受信平均HTTP Bodyトラフィック(Bytes) |
.10.6. [vhostMin] |
http.resHeaderSize | Integer | クライアントに送信平均HTTP Headerトラフィック(Bytes) |
.10.7. [vhostMin] |
http.resBodySize | Integer | クライアントに送信平均HTTP Bodyトラフィック(Bytes) |
.10.8. [vhostMin] |
http.reqAverage | Integer | クライアントから受信した平均HTTPリクエスト数 |
.10.9. [vhostMin] |
http.reqCount | Integer | クライアントから受信したHTTPリクエスト数 |
.10.10. [vhostMin] |
http.resTotalAverage | Integer | クライアントに送信平均全体の応答数 |
.10.11. [vhostMin] |
http.resTotalCompleteAverage | Integer | クライアントが完了した平均HTTPトランザクション数 |
.10.12. [vhostMin] |
http.resTotalTimeRes | Integer | クライアントの応答の平均所要時間(0.01ms) |
.10.13. [vhostMin] |
http.resTotalTimeComplete | Integer | クライアントHTTP Transaction平均完了時間(0.01ms) |
.10.14. [vhostMin] |
http.resTotalCount | Integer | クライアントに送信全体の応答数 |
.10.15. [vhostMin] |
http.resTotalCompleteCount | Integer | クライアントが完了したHTTPトランザクション数 |
.10.20. [vhostMin] |
http.res2xxAverage | Integer | クライアントに送信平均2xx応答数 |
.10.21. [vhostMin] |
http.res2xxCompleteAverage | Integer | クライアントが完了した平均2xxトランザクション数 |
.10.22. [vhostMin] |
http.res2xxTimeRes | Integer | クライアント2xx応答の平均所要時間(0.01ms) |
.10.23. [vhostMin] |
http.res2xxTimeComplete | Integer | クライアント2xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.24. [vhostMin] |
http.res2xxCount | Integer | クライアントに送信2xx応答数 |
.10.25. [vhostMin] |
http.res2xxCompleteCount | Integer | クライアントが完了した2xxトランザクション数 |
.10.30. [vhostMin] |
http.res3xxAverage | Integer | クライアントに送信平均3xx応答数 |
.10.31. [vhostMin] |
http.res3xxCompleteAverage | Integer | クライアントが完了した平均3xxトランザクション数 |
.10.32. [vhostMin] |
http.res3xxTimeRes | Integer | クライアント3xx応答の平均所要時間(0.01ms) |
.10.33. [vhostMin] |
http.res3xxTimeComplete | Integer | クライアント3xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.34. [vhostMin] |
http.res3xxCount | Integer | クライアントに送信3xx応答数 |
.10.35. [vhostMin] |
http.res3xxCompleteCount | Integer | クライアントが完了した3xxトランザクション数 |
.10.40. [vhostMin] |
http.res4xxAverage | Integer | クライアントに送信平均4xx応答数 |
.10.41. [vhostMin] |
http.res4xxCompleteAverage | Integer | クライアントが完了した平均4xxトランザクション数 |
.10.42. [vhostMin] |
http.res4xxTimeRes | Integer | クライアント4xx応答の平均所要時間(0.01ms) |
.10.43. [vhostMin] |
http.res4xxTimeComplete | Integer | クライアント4xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.44. [vhostMin] |
http.res4xxCount | Integer | クライアントに送信4xx応答数 |
.10.45. [vhostMin] |
http.res4xxCompleteCount | Integer | クライアントが完了した4xxトランザクション数 |
.10.50. [vhostMin] |
http.res5xxAverage | Integer | クライアントに送信平均5xx応答数 |
.10.51. [vhostMin] |
http.res5xxCompleteAverage | Integer | クライアントが完了した平均5xxトランザクション数 |
.10.52. [vhostMin] |
http.res5xxTimeRes | Integer | クライアント5xx応答の平均所要時間(0.01ms) |
.10.53. [vhostMin] |
http.res5xxTimeComplete | Integer | クライアント5xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.54. [vhostMin] |
http.res5xxCount | Integer | クライアントに送信5xx応答数 |
.10.55. [vhostMin] |
http.res5xxCompleteCount | Integer | クライアントが完了した5xxトランザクション数 |
.10.60. [vhostMin] |
http.reqDeniedAverage | Integer | ブロックされたリクエストの平均 |
.10.61. [vhostMin] |
http.reqDeniedCount | Integer | ブロックされたリクエスト数 |
| .11 | portbypass | OID | Portバイパスクライアントのトラフィック情報 |
.11.1. [vhostMin] |
portbypass.inbound | Integer | Portバイパスを介してクライアントから受信平均トラフィック(Bytes) |
.11.2. [vhostMin] |
portbypass.outbound | Integer | Portバイパスを介してクライアントに送信平均トラフィック(Bytes) |
.11.3. [vhostMin] |
portbypass.sessionAverage | Integer | Portバイパスしているクライアントの平均セッション数 |
.11.4. [vhostMin] |
portbypass.closedAverage | Integer | Portバイパス中のクライアントが接続を終了した平均回数 |
.11.5. [vhostMin] |
portbypass.closedCount | Integer | Portバイパス中のクライアントが接続を終了した回数 |
| .12 | ssl | OID | SSLクライアントのトラフィック情報 |
.12.2. [vhostMin] |
ssl.inbound | Integer | SSLを介してクライアントから受信平均トラフィック(Bytes) |
.12.3. [vhostMin] |
ssl.outbound | Integer | SSLを介してクライアントに送信平均トラフィック(Bytes) |
| .13 | requestHitAverage | OID | 平均キャッシュHIT結果 |
.13.1. [vhostMin] |
requestHitAverage.TCP_HIT | Integer | TCP_HIT |
.13.2. [vhostMin] |
requestHitAverage.TCP_IMS_HIT | Integer | TCP_IMS_HIT |
.13.3. [vhostMin] |
requestHitAverage.TCP_REFRESH_HIT | Integer | TCP_REFRESH_HIT |
.13.4. [vhostMin] |
requestHitAverage.TCP_REF_FAIL_HIT | Integer | TCP_REF_FAIL_HIT |
.13.5. [vhostMin] |
requestHitAverage.TCP_NEGATIVE_HIT | Integer | TCP_NEGATIVE_HIT |
.13.6. [vhostMin] |
requestHitAverage.TCP_MISS | Integer | TCP_MISS |
.13.7. [vhostMin] |
requestHitAverage.TCP_REFRESH_MISS | Integer | TCP_REFRESH_MISS |
.13.8. [vhostMin] |
requestHitAverage.TCP_CLIENT_REFRESH_MISS | Integer | TCP_CLIENT_REFRESH_MISS |
.13.9. [vhostMin] |
requestHitAverage.TCP_DENIED | Integer | TCP_DENIED |
.13.10. [vhostMin] |
requestHitAverage.TCP_ERROR | Integer | TCP_ERROR |
.13.11. [vhostMin] |
requestHitAverage.TCP_REDIRECT_HIT | Integer | TCP_REDIRECT_HIT |
| .14 | requestHitCount | OID | キャッシュHIT結果数 |
.14.1. [vhostMin] |
requestHitCount.TCP_HIT | Integer | TCP_HIT |
.14.2. [vhostMin] |
requestHitCount.TCP_IMS_HIT | Integer | TCP_IMS_HIT |
.14.3. [vhostMin] |
requestHitCount.TCP_REFRESH_HIT | Integer | TCP_REFRESH_HIT |
.14.4. [vhostMin] |
requestHitCount.TCP_REF_FAIL_HIT | Integer | TCP_REF_FAIL_HIT |
.14.5. [vhostMin] |
requestHitCount.TCP_NEGATIVE_HIT | Integer | TCP_NEGATIVE_HIT |
.14.6. [vhostMin] |
requestHitCount.TCP_MISS | Integer | TCP_MISS |
.14.7. [vhostMin] |
requestHitCount.TCP_REFRESH_MISS | Integer | TCP_REFRESH_MISS |
.14.8. [vhostMin] |
requestHitCount.TCP_CLIENT_REFRESH_MISS | Integer | TCP_CLIENT_REFRESH_MISS |
.14.9. [vhostMin] |
requestHitCount.TCP_DENIED | Integer | TCP_DENIED |
.14.10. [vhostMin] |
requestHitCount.TCP_ERROR | Integer | TCP_ERROR |
.14.11. [vhostMin] |
requestHitCount.TCP_REDIRECT_HIT | Integer | TCP_REDIRECT_HIT |
cache.host.traffic.filesystem¶
OID = 1.3.6.1.4.1.40001.1.4.1.11.20
HostのFile I / O統計を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
.1. [vhostMin] |
requestHitRatio | Integer | Request Hit Ratio(100%) |
.2. [vhostMin] |
Request Hit Ratio(10000%) | ||
.3. [vhostMin] |
byteHitRatio | Integer | Byte Hit Ratio(100%) |
.4. [vhostMin] |
Byte Hit Ratio(10000%) | ||
.5. [vhostMin] |
outbound | Integer | File I / Oデバイスに送信平均トラフィック (Bytes) |
.6. [vhostMin] |
session | Integer | File I / Oを実行中の平均Thread数 |
| .7 | requestHitAverage | OID | 平均キャッシュHIT結果 |
.7.1. [vhostMin] |
requestHitAverage.TCP_HIT | Integer | TCP_HIT |
.7.2. [vhostMin] |
requestHitAverage.TCP_IMS_HIT | Integer | TCP_IMS_HIT |
.7.3. [vhostMin] |
requestHitAverage.TCP_REFRESH_HIT | Integer | TCP_REFRESH_HIT |
.7.4. [vhostMin] |
requestHitAverage.TCP_REF_FAIL_HIT | Integer | TCP_REF_FAIL_HIT |
.7.5. [vhostMin] |
requestHitAverage.TCP_NEGATIVE_HIT | Integer | TCP_NEGATIVE_HIT |
.7.6. [vhostMin] |
requestHitAverage.TCP_MISS | Integer | TCP_MISS |
.7.7. [vhostMin] |
requestHitAverage.TCP_REFRESH_MISS | Integer | TCP_REFRESH_MISS |
.7.8. [vhostMin] |
requestHitAverage.TCP_CLIENT_REFRESH_MISS | Integer | TCP_CLIENT_REFRESH_MISS |
.7.9. [vhostMin] |
requestHitAverage.TCP_DENIED | Integer | TCP_DENIED |
.7.10. [vhostMin] |
requestHitAverage.TCP_ERROR | Integer | TCP_ERROR |
.7.11. [vhostMin] |
requestHitAverage.TCP_REDIRECT_HIT | Integer | TCP_REDIRECT_HIT |
| .8 | requestHitCount | OID | キャッシュHIT結果数 |
.8.1. [vhostMin] |
requestHitCount.TCP_HIT | Integer | TCP_HIT |
.8.2. [vhostMin] |
requestHitCount.TCP_IMS_HIT | Integer | TCP_IMS_HIT |
.8.3. [vhostMin] |
requestHitCount.TCP_REFRESH_HIT | Integer | TCP_REFRESH_HIT |
.8.4. [vhostMin] |
requestHitCount.TCP_REF_FAIL_HIT | Integer | TCP_REF_FAIL_HIT |
.8.5. [vhostMin] |
requestHitCount.TCP_NEGATIVE_HIT | Integer | TCP_NEGATIVE_HIT |
.8.6. [vhostMin] |
requestHitCount.TCP_MISS | Integer | TCP_MISS |
.8.7. [vhostMin] |
requestHitCount.TCP_REFRESH_MISS | Integer | TCP_REFRESH_MISS |
.8.8. [vhostMin] |
requestHitCount.TCP_CLIENT_REFRESH_MISS | Integer | TCP_CLIENT_REFRESH_MISS |
.8.9. [vhostMin] |
requestHitCount.TCP_DENIED | Integer | TCP_DENIED |
.8.10. [vhostMin] |
requestHitCount.TCP_ERROR | Integer | TCP_ERROR |
.8.11. [vhostMin] |
requestHitCount.TCP_REDIRECT_HIT | Integer | TCP_REDIRECT_HIT |
.10. [vhostMin] |
getattr.filecount | Integer | （getattr関数呼び出し）FILEに応答した回数 |
.11. [vhostMin] |
getattr.dircount | Integer | （getattr関数呼び出し）DIRで応答した回数 |
.12. [vhostMin] |
getattr.failcount | Integer | （getattr関数呼び出し）が失敗に応答した回数 |
.13. [vhostMin] |
getattr.timeres | Integer | （getattr関数の呼び出し）の反応時間 (0.01ms) |
.14. [vhostMin] |
open.count | Integer | open関数の呼び出し回数 |
.15. [vhostMin] |
open.timeres | Integer | open関数の反応時間 (0.01ms) |
.16. [vhostMin] |
read.count | Integer | read関数の呼び出し回数 |
.17. [vhostMin] |
read.timeres | Integer | read関数の反応時間 (0.01ms) |
.18. [vhostMin] |
read.buffersize | Integer | read関数で要求されたバッファサイズ (Bytes) |
.19. [vhostMin] |
read.bufferfilled | Integer | read関数で要求されたバッファに詰めたサイズ (Bytes) |
cache.host.traffic.dims¶
OID = 1.3.6.1.4.1.40001.1.4.1.11.21
HostのDIMS変換統計を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
.1. [vhostMin] |
requests | Integer | DIMS変換要求数 |
.2. [vhostMin] |
converted | Integer | 変換に成功回数 |
.3. [vhostMin] |
failed | Integer | 変換に失敗した回数 |
.4. [vhostMin] |
avgsrcsize | Integer | 元のイメージの平均サイズ (Bytes) |
.5. [vhostMin] |
avgdestsize | Integer | 変換されたイメージの平均サイズ (Bytes) |
.6. [vhostMin] |
avgtime | Integer | 変換所要時間 (ms) |
cache.host.traffic.compression¶
OID = 1.3.6.1.4.1.40001.1.4.1.11.22
Hostの圧縮統計を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
.1. [vhostMin] |
requests | Integer | 圧縮要求数 |
.2. [vhostMin] |
converted | Integer | 圧縮成功回数 |
.3. [vhostMin] |
failed | Integer | 圧縮失敗回数 |
.4. [vhostMin] |
avgsrcsize | Integer | 元のファイルの平均サイズ (Bytes) |
.5. [vhostMin] |
avgdestsize | Integer | 圧縮されたファイルの平均サイズ (Bytes) |
.6. [vhostMin] |
avgtime | Integer | 圧縮時間 (ms) |
cache.vhost¶
OID = 1.3.6.1.4.1.40001.1.4.3.1
仮想ホストの情報を提供します。 [vhostIndex] は1から仮想ホストの数ほどの範囲を持つ。
| OID | Name | Type | Description |
|---|---|---|---|
.2. [vhostIndex] |
name | String | 仮想ホスト名 |
.3. [vhostIndex] |
status | String | "Healthy" または "Inactive" または "Emergency" |
.4. [vhostIndex] |
uptime | Integer | 仮想ホストの実行時間（秒） |
| .10 | contents | OID | コンテンツ情報（拡張） |
| .11 | traffic | OID | 統計（拡張） |
cache.vhost.contents¶
OID = 1.3.6.1.4.1.40001.1.4.3.1.10
仮想ホストがサービスするコンテンツ情報を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
.1. [vhostIndex] |
memory | Integer | メモリキャッシュサイズ(KB) |
.2. [vhostIndex] |
filesTotalCount | Integer | サービス中のファイル数 |
.3. [vhostIndex] |
filesTotalSize | Integer | サービス中の全ファイル量(MB) |
.10. [vhostIndex] |
filesCountU1KB | Integer | 1KB未満のファイル数 |
.11. [vhostIndex] |
filesCountU2KB | Integer | 2KB未満のファイル数 |
.12. [vhostIndex] |
filesCountU4KB | Integer | 4KB未満のファイル数 |
.13. [vhostIndex] |
filesCountU8KB | Integer | 8KB未満のファイル数 |
.14. [vhostIndex] |
filesCountU16KB | Integer | 16KB未満のファイル数 |
.15. [vhostIndex] |
filesCountU32KB | Integer | 32KB未満のファイル数 |
.16. [vhostIndex] |
filesCountU64KB | Integer | 64KB未満のファイル数 |
.17. [vhostIndex] |
filesCountU128KB | Integer | 128KB未満のファイル数 |
.18. [vhostIndex] |
filesCountU256KB | Integer | 256KB未満のファイル数 |
.19. [vhostIndex] |
filesCountU512KB | Integer | 512KB未満のファイル数 |
.20. [vhostIndex] |
filesCountU1MB | Integer | 1MB未満のファイル数 |
.21. [vhostIndex] |
filesCountU2MB | Integer | 2MB未満のファイル数 |
.22. [vhostIndex] |
filesCountU4MB | Integer | 4MB未満のファイル数 |
.23. [vhostIndex] |
filesCountU8MB | Integer | 8MB未満のファイル数 |
.24. [vhostIndex] |
filesCountU16MB | Integer | 16MB未満のファイル数 |
.25. [vhostIndex] |
filesCountU32MB | Integer | 32MB未満のファイル数 |
.26. [vhostIndex] |
filesCountU64MB | Integer | 64MB未満のファイル数 |
.27. [vhostIndex] |
filesCountU128MB | Integer | 128MB未満のファイル数 |
.28. [vhostIndex] |
filesCountU256MB | Integer | 256MB未満のファイル数 |
.29. [vhostIndex] |
filesCountU512MB | Integer | 512MB未満のファイル数 |
.30. [vhostIndex] |
filesCountU1GB | Integer | 1GB未満のファイル数 |
.31. [vhostIndex] |
filesCountU2GB | Integer | 2GB未満のファイル数 |
.32. [vhostIndex] |
filesCountU4GB | Integer | 4GB未満のファイル数 |
.33. [vhostIndex] |
filesCountU8GB | Integer | 8GB未満のファイル数 |
.34. [vhostIndex] |
filesCountU16GB | Integer | 16GB未満のファイル数 |
.35. [vhostIndex] |
filesCountO16GB | Integer | 16GB以上のファイル数 |
cache.vhost.traffic¶
OID = 1.3.6.1.4.1.40001.1.4.3.1.11
仮想ホストのキャッシュサービスとトラフィックの統計情報を提供します。trafficのすべての統計情報は最大60分までの平均を提供します。minは'分'を意味し最大60までの値を有します。minが省略されたり0であればリアルタイムの情報を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
.1. [vhostMin] . [vhostIndex] |
requestHitRatio | Integer | Request Hit Ratio(100%) |
.2. [vhostMin] . [vhostIndex] |
Request Hit Ratio(10000%) | ||
.3. [vhostMin] . [vhostIndex] |
bytesHitRatio | Integer | Bytes Hit Ratio(100%) |
.4. [vhostMin] . [vhostIndex] |
Bytes Hit Ratio(10000%) | ||
| .10 | origin | OID | 元のトラフィック情報（拡張） |
| .11 | client | OID | クライアントのトラフィック情報（拡張） |
cache.vhost.traffic.origin¶
OID = 1.3.6.1.4.1.40001.1.4.3.1.11.10
オリジンサーバートラフィックの統計情報を提供します。オリジンサーバーのトラフィックはHTTPトラフィックとPortバイパストラフィックに区分されます。
| OID | Name | Type | Description |
|---|---|---|---|
.1. [vhostMin] . [vhostIndex] |
inbound | Integer | オリジンサーバーから受信し平均トラフィック(Bytes) |
.2. [vhostMin] . [vhostIndex] |
outbound | Integer | オリジンサーバーに送信平均トラフィック(Bytes) |
.3. [vhostMin] . [vhostIndex] |
sessionAverage | Integer | 全体オリジンサーバーの平均セッション数 |
.4. [vhostMin] . [vhostIndex] |
activesessionAverage | Integer | 全体オリジンサーバーセッションの中で送信されているセッションの平均数 |
| .10 | http | OID | オリジンサーバーのHTTPトラフィック情報 |
.10.1. [vhostMin] . [vhostIndex] |
http.inbound | Integer | オリジンサーバーから受信し平均のHTTPトラフィック(Bytes) |
.10.2. [vhostMin] . [vhostIndex] |
http.outbound | Integer | オリジンサーバーに送信平均HTTPトラフィック(Bytes) |
.10.3. [vhostMin] . [vhostIndex] |
http.sessionAverage | Integer | オリジンサーバーの平均HTTPセッション数 |
.10.4. [vhostMin] . [vhostIndex] |
http.reqHeaderSize | Integer | オリジンサーバーに送信平均HTTP Headerトラフィック(Bytes) |
.10.5. [vhostMin] . [vhostIndex] |
http.reqBodySize | Integer | オリジンサーバーに送信平均HTTP Bodyトラフィック(Bytes) |
.10.6. [vhostMin] . [vhostIndex] |
http.resHeaderSize | Integer | オリジンサーバーから受信し平均HTTP Headerトラフィック(Bytes) |
.10.7. [vhostMin] . [vhostIndex] |
http.resBodySize | Integer | オリジンサーバーから受信し平均HTTP Bodyトラフィック(Bytes) |
.10.8. [vhostMin] . [vhostIndex] |
http.reqAverage | Integer | オリジンサーバーに送信される平均HTTPリクエスト数 |
.10.9. [vhostMin] . [vhostIndex] |
http.reqCount | Integer | オリジンサーバーに送信されるHTTPリクエスト数 |
.10.10. [vhostMin] . [vhostIndex] |
http.resTotalAverage | Integer | オリジンサーバーが送信した全体の平均HTTP応答数 |
.10.11. [vhostMin] . [vhostIndex] |
http.resTotalCompleteAverage | Integer | オリジンサーバーから成功した平均HTTPトランザクション数 |
.10.12. [vhostMin] . [vhostIndex] |
http.resTotalTimeRes | Integer | オリジンサーバーからの応答ヘッダを受信するまでの平均所要時間(0.01ms) |
.10.13. [vhostMin] . [vhostIndex] |
http.resTotalTimeComplete | Integer | オリジンサーバーからの応答HTTP Transaction平均完了時間(0.01ms) |
.10.14. [vhostMin] . [vhostIndex] |
http.resTotalCount | Integer | オリジンサーバーが送信した完全なHTTP応答数 |
.10.15. [vhostMin] . [vhostIndex] |
http.resTotalCompleteCount | Integer | オリジンサーバーから成功したHTTPトランザクション数 |
.10.20. [vhostMin] . [vhostIndex] |
http.res2xxAverage | Integer | オリジンサーバーが送信した平均2xx応答数 |
.10.21. [vhostMin] . [vhostIndex] |
http.res2xxCompleteAverage | Integer | オリジンサーバーから成功した平均2xxトランザクション数 |
.10.22. [vhostMin] . [vhostIndex] |
http.res2xxTimeRes | Integer | オリジンサーバーから2xxレスポンスヘッダを受信するまでの平均所要時間(0.01ms) |
.10.23. [vhostMin] . [vhostIndex] |
http.res2xxTimeComplete | Integer | オリジンサーバーから2xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.24. [vhostMin] . [vhostIndex] |
http.res2xxCount | Integer | オリジンサーバーが送信した2xx応答数 |
.10.25. [vhostMin] . [vhostIndex] |
http.res2xxCompleteCount | Integer | オリジンサーバーから成功した2xxトランザクション数ョン数 |
.10.30. [vhostMin] . [vhostIndex] |
http.res3xxAverage | Integer | オリジンサーバーが送信した平均3xx応答数 |
.10.31. [vhostMin] . [vhostIndex] |
http.res3xxCompleteAverage | Integer | オリジンサーバーから成功した平均3xxトランザクション数 |
.10.32. [vhostMin] . [vhostIndex] |
http.res3xxTimeRes | Integer | オリジンサーバーから3xx応答ヘッダを受信するまでの平均所要時間(0.01ms) |
.10.33. [vhostMin] . [vhostIndex] |
http.res3xxTimeComplete | Integer | オリジンサーバーから3xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.34. [vhostMin] . [vhostIndex] |
http.res3xxCount | Integer | オリジンサーバーが送信した3xx応答数 |
.10.35. [vhostMin] . [vhostIndex] |
http.res3xxCompleteCount | Integer | オリジンサーバーから成功した3xxトランザクション数 |
.10.40. [vhostMin] . [vhostIndex] |
http.res4xxAverage | Integer | オリジンサーバーが送信した平均4xx応答数 |
.10.41. [vhostMin] . [vhostIndex] |
http.res4xxCompleteAverage | Integer | オリジンサーバーから成功した平均4xxトランザクション数 |
.10.42. [vhostMin] . [vhostIndex] |
http.res4xxTimeRes | Integer | オリジンサーバーから4xx応答ヘッダを受信するまでの平均所要時間(0.01ms) |
.10.43. [vhostMin] . [vhostIndex] |
http.res4xxTimeComplete | Integer | オリジンサーバーから4xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.44. [vhostMin] . [vhostIndex] |
http.res4xxCount | Integer | オリジンサーバーが送信した4xx応答数 |
.10.45. [vhostMin] . [vhostIndex] |
http.res4xxCompleteCount | Integer | オリジンサーバーから成功した4xxトランザクション数 |
.10.50. [vhostMin] . [vhostIndex] |
http.res5xxAverage | Integer | オリジンサーバーが送信した平均5xx応答数 |
.10.51. [vhostMin] . [vhostIndex] |
http.res5xxCompleteAverage | Integer | オリジンサーバーから成功した平均5xxトランザクション数 |
.10.52. [vhostMin] . [vhostIndex] |
http.res5xxTimeRes | Integer | オリジンサーバーから5xx応答ヘッダを受信するまでの平均所要時間(0.01ms) |
.10.53. [vhostMin] . [vhostIndex] |
http.res5xxTimeComplete | Integer | オリジンサーバーから5xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.54. [vhostMin] . [vhostIndex] |
http.res5xxCount | Integer | オリジンサーバーが送信した5xx応答数 |
.10.55. [vhostMin] . [vhostIndex] |
http.res5xxCompleteCount | Integer | オリジンサーバーから成功した5xxトランザクション数 |
.10.60. [vhostMin] . [vhostIndex] |
http.connectTimeoutAverage | Integer | 平均オリジンサーバー接続に失敗した回数 |
.10.61. [vhostMin] . [vhostIndex] |
http.receiveTimeoutAverage | Integer | 平均元サーバー送信に失敗した回数 |
.10.62. [vhostMin] . [vhostIndex] |
http.connectAverage | Integer | 平均オリジンサーバー接続成功回数 |
.10.63. [vhostMin] . [vhostIndex] |
http.dnsQueryTime | Integer | オリジンサーバー接続時の平均DNSクエリの所要時間 |
.10.64. [vhostMin] . [vhostIndex] |
http.connectTime | Integer | オリジンサーバーの平均接続時間(0.01ms) |
.10.65. [vhostMin] . [vhostIndex] |
http.connectTimeoutCount | Integer | オリジンサーバー接続に失敗した回数 |
.10.66. [vhostMin] . [vhostIndex] |
http.receiveTimeoutCount | Integer | オリジンサーバーの転送に失敗した回数 |
.10.67. [vhostMin] . [vhostIndex] |
http.connectCount | Integer | オリジンサーバー接続成功回数 |
.10.68. [vhostMin] . [vhostIndex] |
http.closeAverage | Integer | 転送中のオリジンサーバーから先にソケットを終了した平均回数 |
.10.69. [vhostMin] . [vhostIndex] |
http.closeCount | Integer | 転送中のオリジンサーバーから先にソケットを終了した回数 |
| .11 | portbypass | OID | Portバイパス元サーバーのトラフィック情報 |
.11.1. [vhostMin] . [vhostIndex] |
portbypass.inbound | Integer | Portバイパスを介してオリジンサーバーから受け取る平均トラフィック(Bytes) |
.11.2. [vhostMin] . [vhostIndex] |
portbypass.outbound | Integer | Portバイパスを介してオリジンサーバーに送信する平均トラフィック(Bytes) |
.11.3. [vhostMin] . [vhostIndex] |
portbypass.sessionAverage | Integer | Portバイパス中の平均オリジンサーバーのセッション数 |
.11.4. [vhostMin] . [vhostIndex] |
portbypass.closedAverage | Integer | Portバイパス中のオリジンサーバーが接続を終了した平均回数 |
.11.5. [vhostMin] . [vhostIndex] |
portbypass.connectTimeoutAverage | Integer | Portバイパスオリジンサーバーの平均接続失敗回数 |
.11.6. [vhostMin] . [vhostIndex] |
portbypass.closedCount | Integer | Portバイパス中のオリジンサーバーが接続を終了した回数 |
.11.7. [vhostMin] . [vhostIndex] |
portbypass.connectTimeoutCount | Integer | Portバイパスオリジンサーバー接続に失敗した回数 |
cache.vhost.traffic.client¶
OID = 1.3.6.1.4.1.40001.1.4.3.1.11.11
クライアントトラフィックの統計情報を提供します。クライアントのトラフィックはHTTPトラフィックは、SSLトラフィック、Portバイパストラフィックに区分されます。SNMPではディレクトリごとの統計を提供しません。たとえディレクトリの統計情報が設定されているとしても合算された統計を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
.1. [vhostMin] . [vhostIndex] |
inbound | Integer | クライアントから受信平均トラフィック(Bytes) |
.2. [vhostMin] . [vhostIndex] |
outbound | Integer | クライアントに送信平均トラフィック(Bytes) |
.3. [vhostMin] . [vhostIndex] |
sessionAverage | Integer | 完全なクライアントの平均セッション数 |
.4. [vhostMin] . [vhostIndex] |
activesessionAverage | Integer | 全クライアントの転送中の平均セッション数 |
| .10 | http | OID | クライアントのHTTPトラフィック情報 |
.10.1. [vhostMin] . [vhostIndex] |
http.inbound | Integer | クライアントから受信平均HTTPトラフィック(Bytes) |
.10.2. [vhostMin] . [vhostIndex] |
http.outbound | Integer | クライアントに送信平均HTTPトラフィック(Bytes) |
.10.3. [vhostMin] . [vhostIndex] |
http.sessionAverage | Integer | クライアントの平均HTTPセッション数 |
.10.4. [vhostMin] . [vhostIndex] |
http.reqHeaderSize | Integer | クライアントから受信平均HTTP Headerトラフィック(Bytes) |
.10.5. [vhostMin] . [vhostIndex] |
http.reqBodySize | Integer | クライアントから受信平均HTTP Bodyトラフィック(Bytes) |
.10.6. [vhostMin] . [vhostIndex] |
http.resHeaderSize | Integer | クライアントに送信平均HTTP Headerトラフィック(Bytes) |
.10.7. [vhostMin] . [vhostIndex] |
http.resBodySize | Integer | クライアントに送信平均HTTP Bodyトラフィック(Bytes) |
.10.8. [vhostMin] . [vhostIndex] |
http.reqAverage | Integer | クライアントから受信した平均HTTPリクエスト数 |
.10.9. [vhostMin] . [vhostIndex] |
http.reqCount | Integer | クライアントから受信したHTTPリクエスト数 |
.10.10. [vhostMin] . [vhostIndex] |
http.resTotalAverage | Integer | クライアントに送信平均全体の応答数 |
.10.11. [vhostMin] . [vhostIndex] |
http.resTotalCompleteAverage | Integer | クライアントが完了した平均HTTPトランザクション数 |
.10.12. [vhostMin] . [vhostIndex] |
http.resTotalTimeRes | Integer | クライアントの応答の平均所要時間(0.01ms) |
.10.13. [vhostMin] . [vhostIndex] |
http.resTotalTimeComplete | Integer | クライアントHTTP Transaction平均完了時間(0.01ms) |
.10.14. [vhostMin] . [vhostIndex] |
http.resTotalCount | Integer | クライアントに送信全体の応答数 |
.10.15. [vhostMin] . [vhostIndex] |
http.resTotalCompleteCount | Integer | クライアントが完了したHTTPトランザクション数 |
.10.20. [vhostMin] . [vhostIndex] |
http.res2xxAverage | Integer | クライアントに送信平均2xx応答数 |
.10.21. [vhostMin] . [vhostIndex] |
http.res2xxCompleteAverage | Integer | クライアントが完了した平均2xxトランザクション数 |
.10.22. [vhostMin] . [vhostIndex] |
http.res2xxTimeRes | Integer | クライアント2xx応答の平均所要時間(0.01ms) |
.10.23. [vhostMin] . [vhostIndex] |
http.res2xxTimeComplete | Integer | クライアント2xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.24. [vhostMin] . [vhostIndex] |
http.res2xxCount | Integer | クライアントに送信2xx応答数 |
.10.25. [vhostMin] . [vhostIndex] |
http.res2xxCompleteCount | Integer | クライアントが完了した2xxトランザクション数 |
.10.30. [vhostMin] . [vhostIndex] |
http.res3xxAverage | Integer | クライアントに送信平均3xx応答数 |
.10.31. [vhostMin] . [vhostIndex] |
http.res3xxCompleteAverage | Integer | クライアントが完了した平均3xxトランザクション数 |
.10.32. [vhostMin] . [vhostIndex] |
http.res3xxTimeRes | Integer | クライアント3xx応答の平均所要時間(0.01ms) |
.10.33. [vhostMin] . [vhostIndex] |
http.res3xxTimeComplete | Integer | クライアント3xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.34. [vhostMin] . [vhostIndex] |
http.res3xxCount | Integer | クライアントに送信3xx応答数 |
.10.35. [vhostMin] . [vhostIndex] |
http.res3xxCompleteCount | Integer | クライアントが完了した3xxトランザクション数 |
.10.40. [vhostMin] . [vhostIndex] |
http.res4xxAverage | Integer | クライアントに送信平均4xx応答数 |
.10.41. [vhostMin] . [vhostIndex] |
http.res4xxCompleteAverage | Integer | クライアントが完了した平均4xxトランザクション数 |
.10.42. [vhostMin] . [vhostIndex] |
http.res4xxTimeRes | Integer | クライアント4xx応答の平均所要時間(0.01ms) |
.10.43. [vhostMin] . [vhostIndex] |
http.res4xxTimeComplete | Integer | クライアント4xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.44. [vhostMin] . [vhostIndex] |
http.res4xxCount | Integer | クライアントに送信4xx応答数 |
.10.45. [vhostMin] . [vhostIndex] |
http.res4xxCompleteCount | Integer | クライアントが完了した4xxトランザクション数 |
.10.50. [vhostMin] . [vhostIndex] |
http.res5xxAverage | Integer | クライアントに送信平均5xx応答数 |
.10.51. [vhostMin] . [vhostIndex] |
http.res5xxCompleteAverage | Integer | クライアントが完了した平均5xxトランザクション数 |
.10.52. [vhostMin] . [vhostIndex] |
http.res5xxTimeRes | Integer | クライアント5xx応答の平均所要時間(0.01ms) |
.10.53. [vhostMin] . [vhostIndex] |
http.res5xxTimeComplete | Integer | クライアント5xx応答HTTP Transaction平均完了時間(0.01ms) |
.10.54. [vhostMin] . [vhostIndex] |
http.res5xxCount | Integer | クライアントに送信5xx応答数 |
.10.55. [vhostMin] . [vhostIndex] |
http.res5xxCompleteCount | Integer | クライアントが完了した5xxトランザクション数 |
.10.60. [vhostMin] . [vhostIndex] |
http.reqDeniedAverage | Integer | ブロックされたリクエストの平均 |
.10.61. [vhostMin] . [vhostIndex] |
http.reqDeniedCount | Integer | ブロックされたリクエスト数 |
| .11 | portbypass | OID | Portバイパスクライアントのトラフィック情報 |
.11.1. [vhostMin] . [vhostIndex] |
portbypass.inbound | Integer | Portバイパスを介してクライアントから受信平均トラフィック(Bytes) |
.11.2. [vhostMin] . [vhostIndex] |
portbypass.outbound | Integer | Portバイパスを介してクライアントに送信平均トラフィック(Bytes) |
.11.3. [vhostMin] . [vhostIndex] |
portbypass.sessionAverage | Integer | Portバイパスしているクライアントの平均セッション数 |
.11.4. [vhostMin] . [vhostIndex] |
portbypass.closedAverage | Integer | Portバイパス中のクライアントが接続を終了した平均回数 |
.11.5. [vhostMin] . [vhostIndex] |
portbypass.closedCount | Integer | Portバイパス中のクライアントが接続を終了した回数 |
| .12 | ssl | OID | SSLクライアントのトラフィック情報 |
.12.2. [vhostMin] . [vhostIndex] |
ssl.inbound | Integer | SSLを介してクライアントから受信平均トラフィック(Bytes) |
.12.3. [vhostMin] . [vhostIndex] |
ssl.outbound | Integer | SSLを介してクライアントに送信平均トラフィック(Bytes) |
| .13 | requestHitAverage | OID | 平均キャッシュHIT結果 |
.13.1. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_HIT | Integer | TCP_HIT |
.13.2. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_IMS_HIT | Integer | TCP_IMS_HIT |
.13.3. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_REFRESH_HIT | Integer | TCP_REFRESH_HIT |
.13.4. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_REF_FAIL_HIT | Integer | TCP_REF_FAIL_HIT |
.13.5. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_NEGATIVE_HIT | Integer | TCP_NEGATIVE_HIT |
.13.6. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_MISS | Integer | TCP_MISS |
.13.7. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_REFRESH_MISS | Integer | TCP_REFRESH_MISS |
.13.8. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_CLIENT_REFRESH_MISS | Integer | TCP_CLIENT_REFRESH_MISS |
.13.9. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_DENIED | Integer | TCP_DENIED |
.13.10. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_ERROR | Integer | TCP_ERROR |
.13.11. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_REDIRECT_HIT | Integer | TCP_REDIRECT_HIT |
| .14 | requestHitCount | OID | キャッシュHIT結果数 |
.14.1. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_HIT | Integer | TCP_HIT |
.14.2. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_IMS_HIT | Integer | TCP_IMS_HIT |
.14.3. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_REFRESH_HIT | Integer | TCP_REFRESH_HIT |
.14.4. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_REF_FAIL_HIT | Integer | TCP_REF_FAIL_HIT |
.14.5. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_NEGATIVE_HIT | Integer | TCP_NEGATIVE_HIT |
.14.6. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_MISS | Integer | TCP_MISS |
.14.7. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_REFRESH_MISS | Integer | TCP_REFRESH_MISS |
.14.8. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_CLIENT_REFRESH_MISS | Integer | TCP_CLIENT_REFRESH_MISS |
.14.9. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_DENIED | Integer | TCP_DENIED |
.14.10. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_ERROR | Integer | TCP_ERROR |
.14.11. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_REDIRECT_HIT | Integer | TCP_REDIRECT_HIT |
cache.vhost.traffic.filesystem¶
OID = 1.3.6.1.4.1.40001.1.4.3.1.11.20
仮想ホストのFile I / O統計を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
.1. [vhostMin] . [vhostIndex] |
requestHitRatio | Integer | Request Hit Ratio(100%) |
.2. [vhostMin] . [vhostIndex] |
Request Hit Ratio(10000%) | ||
.3. [vhostMin] . [vhostIndex] |
byteHitRatio | Integer | Byte Hit Ratio(100%) |
.4. [vhostMin] . [vhostIndex] |
Byte Hit Ratio(10000%) | ||
.5. [vhostMin] . [vhostIndex] |
outbound | Integer | File I / Oデバイスに送信平均トラフィック (Bytes) |
.6. [vhostMin] . [vhostIndex] |
session | Integer | File I / Oを実行中の平均Thread数 |
| .7 | requestHitAverage | OID | 平均キャッシュHIT結果 |
.7.1. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_HIT | Integer | TCP_HIT |
.7.2. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_IMS_HIT | Integer | TCP_IMS_HIT |
.7.3. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_REFRESH_HIT | Integer | TCP_REFRESH_HIT |
.7.4. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_REF_FAIL_HIT | Integer | TCP_REF_FAIL_HIT |
.7.5. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_NEGATIVE_HIT | Integer | TCP_NEGATIVE_HIT |
.7.6. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_MISS | Integer | TCP_MISS |
.7.7. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_REFRESH_MISS | Integer | TCP_REFRESH_MISS |
.7.8. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_CLIENT_REFRESH_MISS | Integer | TCP_CLIENT_REFRESH_MISS |
.7.9. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_DENIED | Integer | TCP_DENIED |
.7.10. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_ERROR | Integer | TCP_ERROR |
.7.11. [vhostMin] . [vhostIndex] |
requestHitAverage.TCP_REDIRECT_HIT | Integer | TCP_REDIRECT_HIT |
| .8 | requestHitCount | OID | キャッシュHIT結果数 |
.8.1. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_HIT | Integer | TCP_HIT |
.8.2. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_IMS_HIT | Integer | TCP_IMS_HIT |
.8.3. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_REFRESH_HIT | Integer | TCP_REFRESH_HIT |
.8.4. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_REF_FAIL_HIT | Integer | TCP_REF_FAIL_HIT |
.8.5. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_NEGATIVE_HIT | Integer | TCP_NEGATIVE_HIT |
.8.6. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_MISS | Integer | TCP_MISS |
.8.7. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_REFRESH_MISS | Integer | TCP_REFRESH_MISS |
.8.8. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_CLIENT_REFRESH_MISS | Integer | TCP_CLIENT_REFRESH_MISS |
.8.9. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_DENIED | Integer | TCP_DENIED |
.8.10. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_ERROR | Integer | TCP_ERROR |
.8.11. [vhostMin] . [vhostIndex] |
requestHitCount.TCP_REDIRECT_HIT | Integer | TCP_REDIRECT_HIT |
.10. [vhostMin] . [vhostIndex] |
getattr.filecount | Integer | （getattr関数呼び出し）FILEに応答した回数 |
.11. [vhostMin] . [vhostIndex] |
getattr.dircount | Integer | （getattr関数呼び出し）DIRで応答した回数 |
.12. [vhostMin] . [vhostIndex] |
getattr.failcount | Integer | （getattr関数呼び出し）が失敗に応答した回数 |
.13. [vhostMin] . [vhostIndex] |
getattr.timeres | Integer | （getattr関数の呼び出し）の反応時間 (0.01ms) |
.14. [vhostMin] . [vhostIndex] |
open.count | Integer | open関数の呼び出し回数 |
.15. [vhostMin] . [vhostIndex] |
open.timeres | Integer | open関数の反応時間 (0.01ms) |
.16. [vhostMin] . [vhostIndex] |
read.count | Integer | read関数の呼び出し回数 |
.17. [vhostMin] . [vhostIndex] |
read.timeres | Integer | read関数の反応時間 (0.01ms) |
.18. [vhostMin] . [vhostIndex] |
read.buffersize | Integer | read関数で要求されたバッファサイズ (Bytes) |
.19. [vhostMin] . [vhostIndex] |
read.bufferfilled | Integer | read関数で要求されたバッファに詰めたサイズ (Bytes) |
cache.vhost.traffic.dims¶
OID = 1.3.6.1.4.1.40001.1.4.3.1.11.21
仮想ホストのDIMS変換統計を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
.1. [vhostMin] . [vhostIndex] |
requests | Integer | DIMS変換要求数 |
.2. [vhostMin] . [vhostIndex] |
converted | Integer | 変換に成功回数 |
.3. [vhostMin] . [vhostIndex] |
failed | Integer | 変換に失敗した回数 |
.4. [vhostMin] . [vhostIndex] |
avgsrcsize | Integer | 元のイメージの平均サイズ (Bytes) |
.5. [vhostMin] . [vhostIndex] |
avgdestsize | Integer | 変換されたイメージの平均サイズ (Bytes) |
.6. [vhostMin] . [vhostIndex] |
avgtime | Integer | 変換所要時間 (ms) |
cache.vhost.traffic.compression¶
OID = 1.3.6.1.4.1.40001.1.4.3.1.11.22
仮想ホストの圧縮統計を提供します。
| OID | Name | Type | Description |
|---|---|---|---|
.1. [vhostMin] . [vhostIndex] |
requests | Integer | 圧縮要求数 |
.2. [vhostMin] . [vhostIndex] |
converted | Integer | 圧縮成功回数 |
.3. [vhostMin] . [vhostIndex] |
failed | Integer | 圧縮失敗回数 |
.4. [vhostMin] . [vhostIndex] |
avgsrcsize | Integer | 元のファイルの平均サイズ (Bytes) |
.5. [vhostMin] . [vhostIndex] |
avgdestsize | Integer | 圧縮されたファイルの平均サイズ (Bytes) |
.6. [vhostMin] . [vhostIndex] |
avgtime | Integer | 圧縮時間 (ms) |
cache.view¶
OID = 1.3.6.1.4.1.40001.1.4.11.1
仮想ホストの統計と同じ情報を提供します。
[viewIndex] は1からViewの数ほどの範囲を持つ。
- 1.3.6.1.4.1.40001.1.4.3 - 仮想ホストの統計
- 1.3.6.1.4.1.40001.1.4.11 - View 統計
第12章 ログ¶
この章ではログを説明します。サービスはログに始まりログに終わる。 ログは金であり法である正義の味方です。
ログはグローバルと仮想ホストに区分されます。 すべてのログは記録有無を設定することができ共通の属性を持つ。
<XXX Type="time" Unit="1440" Retention="10" Compression="OFF">ON</XXX>
Type (デフォルト: time),Unit (デフォルト: 1440分)ログローテート条件を設定します。time設定されたunit時間（単位：分）ごとにログファイルをローテートします。size設定されたunitサイズ（単位：MB）ごとにログファイルをローテートします。bothコンマ（、）で区切って時間とサイズを同時に設定します。 たとえばUnit = "1440、100"である場合時間が24時間（1440分）または100MBの場合ログファイルをローテートします。
Retention (デフォルト: 10個)単位のログファイルを最大n個の維持です。Compression (デフォルト: OFF)ログがローテートされる圧縮を行う。 たとえばaccess_20140715_0000.logファイルがローテートされるとaccess_20140715_0000.log.gzに圧縮されて保存されます。
Type が "time" 、 Unit が10の場合ログは10分毎にローテートされます。 たとえばサービスを2:18分に開始してもログは10分の2:20、2:30、2:40にローテートされます。 同様に一日に一回毎日0時0分にローテートする1440（60分X 24時間）で Unit 値に設定します。
time の設定でログは一日に一度無条件ローテートされるので Unit の最大値は1440を超えることができない。
最大値は24時間（Unit = 1440）時間ごとにログがローテートするように設定した場合は次の図のようにログが記録されます。
Installログ¶
インストール/アップデート時にすべての内容がinstall.logに記録されます。 このログは別の設定がない。
#DownloadURL: http://foobar.com/ston/ston.2.0.0.rhel.2.6.32.x64.tar.gz
#DownloadTime: 13 sec
#Target: STON 2.0.0
#Date: 2014.03.03 16:48:35
Prepare for STON 2.0.0 install process
Stopping STON...
STON stopped
[Copying files]
`./fuse.conf' -> `/etc/fuse.conf'
`./libfuse.so.2' -> `/usr/local/ston/libfuse.so.2'
`./libtbbmalloc_proxy.so' -> `/usr/local/ston/libtbbmalloc_proxy.so'
`./start-stop-daemon' -> `/usr/sbin/start-stop-daemon'
`./libtbbmalloc_proxy.so.2' -> `/usr/local/ston/libtbbmalloc_proxy.so.2'
`./libtbbmalloc.so' -> `/usr/local/ston/libtbbmalloc.so'
`./libtbbmalloc.so.2' -> `/usr/local/ston/libtbbmalloc.so.2'
`./libtbb.so' -> `/usr/local/ston/libtbb.so'
`./libtbb.so.2' -> `/usr/local/ston/libtbb.so.2'
`./stond' -> `/usr/local/ston/stond'
`./stonx' -> `/usr/local/ston/stonx'
`./stonr' -> `/usr/local/ston/stonr'
`./stonu' -> `/usr/local/ston/stonu'
`./stonapi' -> `/usr/local/ston/stonapi'
`./server.xml.default' -> `/usr/local/ston/server.xml.default'
`./vhosts.xml.default' -> `/usr/local/ston/vhosts.xml.default'
`./ston_format.sh' -> `/usr/local/ston/ston_format.sh'
`./ston_diskinfo.sh' -> `/usr/local/ston/ston_diskinfo.sh'
`./wm.sh' -> `/usr/local/ston/wm.sh'
[Exporting config files]
#Export so directory
/usr/local/ston/ to ld.so.conf
#Export sysctl to /etc/sysctl.conf
vm.swappiness=0
vm.min_free_kbytes=524288
#Export sudoers for WM
Defaults !requiretty
winesoft ALL=NOPASSWD: /etc/init.d/ston stop, /etc/init.d/ston start, /bin/ps -ef
[Configuring STON daemon script]
STON deamon activate in run-level 2345.
[Installing sub-packages]
curl installed.
libjpeg installed.
libgomp installed.
rrdtool installed.
[Installing WM]
Stopping WM...
WM stopped
`./wm.server_default.xml' -> `/usr/local/ston/wm/tmp/conf/server_default.xml'
`./wm.vhost_default.xml' -> `/usr/local/ston/wm/tmp/conf/vhost_default.xml'
WM configuration found. Current WM port : 8500
PHP module for Legacy(CentOS 5.5) installed
`./libphp5.so.5.5' -> `/usr/local/ston/wm/modules/libphp5.so'
WM installation almost complete. Changing WM privileges.
Installation successfully complete
Infoログ¶
Infoログはグローバル設定（server.xml）に設定します。
# server.xml - <Server><Cache>
<InfoLog Type="size" Unit="1" Retention="5">ON</InfoLog>
<InfoLog> (デフォルト: ON, Type: size, Unit: 1)STONの動作と設定の変更について記録します。
Denyログ¶
Denyログはグローバル設定（server.xml）に設定します。
# server.xml - <Server><Cache>
<DenyLog Type="size" Unit="1" Retention="5">ON</DenyLog>
<DenyLog> (デフォルト: ON, Type: size, Unit: 1)サーバーアクセス制御 によってアクセスブロックされたIPアドレスを記録します。
#Fields: date time c-ip deny 2012.11.15 07:06:10 1.1.1.1 AP 2012.11.15 07:06:26 2.2.2.2 GIN 2012.11.15 07:06:30 3.3.3.3 3.3.3.1-255
すべてのフィールドはスペースで区切られ各フィールドの意味は次のとおりです。
date日time時間c-ipクライアントのIPアドレスdenyブロック条件
OriginErrorログ¶
OriginErrorログはグローバル設定（server.xml）に設定します。
# server.xml - <Server><Cache>
<OriginErrorLog Type="size" Unit="5" Retention="5" Warning="OFF">ON</OriginErrorLog>
<OriginErrorLog> (デフォルト: OFF, Type: size, Unit: 5, Warning: OFF)すべての仮想ホストのオリジンサーバーで発生した障害だけ記録します。 障害は接続障害と伝送障害を意味しオリジンサーバー排除/復旧の結果が記録されます。
#Fields: date time vhostname level s-domain s-ip cs-method cs-uri time-taken sc-error sc-resinfo 2012.11.15 07:06:10 [example.com] [ERROR] 192.168.0.13 192.168.0.13 GET /Upload/ProductImage/stock/1716439_SM.jpg 20110 Connect-Timeout - 2012.11.15 07:06:26 [example.com] [ERROR] 192.168.0.13 192.168.0.13 GET /Upload/ProductImage/stock/1716439_SM.jpg 20110 Connect-Timeout - 2012.11.15 07:06:30 [example.com] [ERROR] 192.168.0.13 192.168.0.13 GET /Upload/ProductImage/stock/1716439_SM.jpg 20110 Connect-Timeout - #2012.11.15 07:06:30 [example.com] 192.168.0.13 excluded from service #2012.11.15 07:06:31 [example.com] Origin server list: 192.168.0.14 #2012.11.15 07:11:11 [example.com] 192.168.0.13 recovered back in service #2012.11.15 07:11:12 [example.com] Origin server list: 192.168.0.13
すべてのフィールドはスペースで区切られ各フィールドの意味は次のとおりです。
date障害が発生した日付time障害発生時間vhostname[仮想ホスト]level[障害レベル（ErrorまたはWarning)]s-domainオリジンサーバーのドメインs-ipオリジンサーバーのIPcs-methodSTONがオリジンサーバーに送信HTTP Methodcs-uriSTONがオリジンサーバーに送信URItime-taken障害が発生するまでにかかった時間sc-error障害の種類sc-resinfo障害発生時サーバーの応答情報（ "、"文字で区切ら）
Warning属性がONであれば次の例のように不正なHTTP通信が発生した場合に記録します。2012.11.15 07:09:03 [example.com] [WARNING] 10.10.10.10 121.189.63.219 GET /716439_SM.jpg 20110 PartialResponseOnNormalRequest Res=206,Len=2635 2012.11.15 07:09:03 [example.com] [WARNING] 10.10.10.10 121.189.63.219 GET /716439_SM.jpg 20110 ClosedWithoutResponse -
不正なHTTP通信の場合は以下の通りです。
ClosedWithoutResponse元サーバーによる接続終了。 HTTP応答を受けなかった。ClosedWhenDownloading元サーバーによる接続終了。 Content-Lengthだけダウンロードしていなかった。NotPartialResponseOnRangeRequestRange要求をしたが応答コードが206ではない。DifferentContentLengthOnRangeRequest要求されたRangeとContent-Lengthが異なる。PartialResponseOnNormalRequestRangeリクエストがないのに応答コードが206です。
SysLog送信¶
syslog プロトコルを使用してログをUDPでリアルタイム転送します。 すべてのログに対してsyslogに送信されるように設定することができます。
# server.xml - <Server><Cache>
<InfoLog SysLog="OFF">ON</InfoLog>
<DenyLog SysLog="OFF">ON</DenyLog>
<OriginErrorLog SysLog="OFF">ON</OriginErrorLog>
SysLogOFF (デフォルト)syslogを使用しません。ONこのタグの下位に設定された<SysLog>にログを送信します。
以下は <OriginErrorLog> が記録されるときにsyslogを設定する例です。
# server.xml - <Server><Cache>
<OriginErrorLog SysLog="ON">
<SysLog Priority="local3.info" Dest="192.168.0.1:514" />
<SysLog Priority="user.alert" Dest="192.168.0.2" />
<SysLog Priority="mail.debug" Dest="log.example.com" />
</OriginErrorLog>
<OriginErrorLog>のSysLog属性をONに設定します。<OriginErrorLog>の下位に<SysLog>タグを生成します。 n台のサーバーに同時に送信可能です。<SysLog>のPriority属性を設定します。 この表現は syslogの Facility Levels と Severity levels の組み合わせで構成します。<SysLog>のDest属性を設定します。 syslog受信サーバーを意味し受信ポートが514である場合省略可能です。
上記の設定で記録されたsysログの例は以下の通りです。 syslogのtagはSTON / {ログ名}に記録されます。
Mar 12 11:24:24 192.168.0.1 STON/ORIGINERROR: 2013-03-12 14:09:20 [ERROR] [example.com] - 192.168.0.14 GET /1.gifd 1996 Connect-Timeout -
Mar 12 11:24:24 192.168.0.1 STON/ORIGINERROR: 2013-03-12 14:09:22 [ERROR] [example.com] - 192.168.0.14 GET /favicon.ico 1995 Connect-Timeout -
Mar 12 11:24:24 192.168.0.1 STON/ORIGINERROR: 2013-03-12 14:09:24 [ERROR] [example.com] - 192.168.0.14 GET /1.gifd22 2020 Connect-Timeout -
Mar 12 11:24:24 192.168.0.1 STON/ORIGINERROR: #2013 .03.12 14:09:24 [example.com] 192.168.0.14:102 excluded from service
Mar 12 11:24:24 192.168.0.1 STON/ORIGINERROR: #2013 .03.12 14:09:24 [example.com] Origin server list:
仮想ホスト別のログ保存¶
仮想ホストごとにログは別々に記録されます。 ログが OFF に設定されていてもローカルファイルにのみ書かれていないだけなので
Log Trace は正常に動作します。
# server.xml - <Server><VHostDefault>
# vhosts.xml - <Vhosts><Vhost>
<Log Dir="/cache_log">
... (省略) ...
</Log>
<Log>Dir属性にログが記録されるディレクトリを設定します。 ログは設定したディレクトリの下位の仮想ホストのディレクトリに生成されます。
DNSログ¶
元サーバーのアドレスがDomainに設定された場合Resolving結果を記録します。
# server.xml - <Server><VHostDefault><Log>
# vhosts.xml - <Vhosts><Vhost><Log>
<Dns Type="size" Unit="10" Retention="10" SysLog="OFF" Compression="OFF">ON</Dns>
#Fields: date time domain ttl ip-list ip-count time-taken result
2014-07-30 12:10:33 example.com 157 173.194.127.15,173.194.127.23,173.194.127.24,173.194.127.31 4 5007 success
2014-07-30 12:10:38 example.com 152 173.194.127.23,173.194.127.24,173.194.127.31,173.194.127.15 4 9 success
2014-07-30 12:11:03 example.com 127 173.194.127.31,173.194.127.15,173.194.127.23,173.194.127.24 4 15007 success
2014-07-30 12:12:53 example.com 17 173.194.127.15,173.194.127.23,173.194.127.24,173.194.127.31 4 6 success
2014-07-30 12:23:16 test.com 0 - 0 10008 fail
2014-07-30 12:23:21 test.com 0 - 0 5007 fail
2014-07-30 12:23:26 test.com 0 - 0 5011 fail
2014-07-30 12:24:38 example.com 152 173.194.127.23,173.194.127.24,173.194.127.31,173.194.127.15 4 9 success
2014-07-30 12:25:03 example.com 127 173.194.127.31,173.194.127.15,173.194.127.23,173.194.127.24 4 15007 success
すべてのフィールドはスペースで区切られ各フィールドの意味は次のとおりです。
date日time時間domain対象Domainttlレコードの有効時間(Time To Live)ip-listIPリストip-countIP数time-taken実行時間resultsuccessまたはfail
Accessログ¶
すべてのクライアントからのHTTPトランザクションを記録します。 ログ記録の時点ではHTTPトランザクションが完了した時点で転送完了または送信停止時点を意味します。
# server.xml - <Server><VHostDefault><Log>
# vhosts.xml - <Vhosts><Vhost><Log>
<Access Type="time" Unit="1440" Retention="10" XFF="on" Form="ston" Local="Off">ON</Access>
XFFON (デフォルト)クライアントが送信したXFF（X-Forwarded-For）ヘッダの値とクライアントのIPアドレスをのように記録します。 ない場合はOFFと同じです。OFFクライアントのIPアドレスを記録します。TrimCIPXFFヘッダがない場合はクライアントのIPアドレスをある場合（クライアントのIPアドレスを除く）XFFヘッダだけを記録します。
Formston (デフォルト)W3C標準+拡張フィールドapacheApache形式iisIIS形式customadmin-log-access-custom
LocalOFF (デフォルト)ローカル通信（Loopback）は記録しません。ONローカル通信（Loopback）も記録します。
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-bytes time-taken cs-referer sc-resinfo cs-range sc-cachehit cs-acceptencoding session-id sc-content-length
2012.06.27 16:52:24 220.134.10.5 GET /web/h.gif - 80 - 61.50.7.9 Chrome/19.0.1084.56 200 98141 5 - Bypass+gzip+SSL3 - TCP_HIT gzip+deflate 7 1273735
2012.06.27 16:52:26 220.134.10.5 GET /favicon.ico - 80 - 61.50.7.9 Chrome/19.0.1084.56 200 949 2 - - - TCP_HIT gzip+deflate 35 14875
2012.06.27 17:00:06 220.168.0.13 GET /setup.Eexe - 80 - 61.168.0.102 Mozilla/5.0+(Windows+NT+6.1;+WOW64)+AppleWebKit/536.11+(KHTML,+like+Gecko)+Chrome/20.0.1132.57+Safari/536.11 206 20971800 7008 - - 398458880-419430399 TCP_HIT - 41 89764358
すべてのフィールドはスペースで区切られ各フィールドの意味は次のとおりです。
dateHTTPトランザクションが完了した日付timeHTTPトランザクションが完了した時刻s-ipサーバのIPcs-methodクライアントが送信したHTTP Methodcs-uri-stemクライアントが送信したURLの中でQueryStringを除いた部分cs-uri-queryクライアントが送信したURLの中でQueryStrings-portサーバーのポートcs-usernameクライアントusernamec-ipクライアントのIPアドレス。 XFFの設定が "ON"であればX-Forwarded-Forヘッダの値とクライアントのIPアドレスを記録します。cs(User-Agent)クライアントが送信したHTTP User-Agentsc-statusサーバーの応答コードsc-bytesサーバーが送信Bytes（ヘッダ+コンテンツ）time-takenHTTPトランザクションが完了するまでかかった合計時間（ミリ秒）cs-refererクライアントが送信したHTTP Referersc-resinfo付加情報。 "+"の文字に区分されます。 圧縮されたコンテンツをサービスした場合圧縮オプション（gzipまたはdeflate）が指定されます。 安全な通信であればSSLプロトコルのバージョン（SSL3、TLS1、TLS1.1、TLS1.2）が指定されます。 バイパスした通信であれば "Bypass"が指定されている。cs-rangeクライアントが送信したRangeヘッダを記録します。sc-cachehitキャッシュHIT結果cs-acceptencodingクライアントが送信されるAccept-Encodingヘッダsession-idHTTPクライアントセッションID (unsigned int64)sc-content-lengthサーバの応答Content-Lengthヘッダの値
Accessログは送信成功/失敗したかに関係なくすべてのHTTPトランザクションを記録します。 HTTPトランザクションはクライアントがHTTP要求を送信するときに開始されます。 STONがクライアントに応答を送信する前にHTTP接続が終了した場合HTTPトランザクションも終了されたものとみなす。 ログには sc-status と sc-bytes が0に記録されます。 主STONがオリジンサーバーからの応答を受信する前にクライアントが接続を終了する場合このようなログが記録されます。
ユーザー定義のAccessログのフォーマット¶
Accessログの形式をユーザー定義のログに設定します。
# server.xml - <Server><VHostDefault><Log>
# vhosts.xml - <Vhosts><Vhost><Log>
<Access Form="custom">ON</Access>
<AccessFormat>%a %A %b id=%{userid}C %f %h %H "%{user-agent}i" %m %P "%r" %s %t %T %X %I %O %R %e %S %K</AccessFormat>
<Access>のForm属性をcustomに設定します。<AccessFormat>カスタムログ形式。
上の例の場合は次のようにAccessログが記録されます。 （#Fieldsは記録しません。）
192.168.0.88 192.168.0.12 163276 id=winesoft; image.jpg example.com HTTP "STON" GET 80 "GET /ston/image.jpg?type=png HTTP/1.1" 200 2014-04-03 21:21:54 1 C 204 163276 1 2571978 TCP_MISS HTTP/1.1
192.168.0.88 192.168.0.12 63276 id=winesoft; vod.mp4 example.com HTTP "STON" POST 80 "GET /ston/vod.mp4?start=10 HTTP/1.1" 200 2014-04-03 21:21:54 12 C 304 363276 2 2571979 TCP_REFRESH_HIT HTTP/1.1
192.168.0.88 192.168.0.12 3634276 id=ston; news.html example.com HTTPS "STON" GET 443 "GET /news.html HTTP/1.1" 200 2014-04-03 21:21:54 30 X 156 2632576 1 2571980 TCP_MISS HTTP/1.1
192.168.0.88 192.168.0.12 6332476 id=winesoft; style.css example.com HTTP "STON" HEAD 80 "GET /style.css HTTP/1.1" 200 2014-04-03 21:21:54 10 X 234 653276 2 2571981 TCP_REFRESH_HIT HTTP/1.1
192.168.0.88 192.168.0.12 6276 id=ston; ui.js example.com HTTP "STON" GET 80 "GET /ui.js HTTP/1.1" 200 2014-04-03 21:21:54 1 X 233 63276 1 2571982 TCP_MISS HTTP/1.1
192.168.0.88 192.168.0.12 626 id=winesoft; hls.m4u8 example.com HTTP "STON" GET 80 "GET /hls.m4u8 HTTP/1.1" 200 2014-04-03 21:21:54 2 X 124 6312333276 2 2571983 TCP_REFRESH_HIT HTTP/1.1
Apacheのログ形式 をベースに開発されいくつかの拡張フィールドがあります。 各フィールドの区切り文字には制限がありませんSpaceを使用する場合はUser-AgentのようにSpaceが含まれているフィールドは二重引用符（"..."）で囲んで設定します。
%...aクライアントのIP192.168.0.66
%...AサーバーのIPアドレス192.168.0.14
%...bHTTPヘッダ以外の送らバイト数1024%...{foobar}Cサーバが受信した要求のクッキーFoobarの値%{id=}c に入力するとCookieのid=に相当する値を記録
%...Dリクエストを処理するのにかかった時間（MS）3000%...fファイル名/mp4/iu.mp4 なら iu.mp4を記録
%...hHostNameexample.com
%...Hリクエストプロトコルhttp または https
%...{foobar}iサーバが受信した要求からfoobar：ヘッダの内容%{User-Agent}i として入力する場合User-Agentの値を記録
%...mリクエストMethodGET または POST または HEAD
%...PServer PORT80%...qQueryStringId=10&value=20
%...rリクエストの最初の行(Request Line)GET /img.jpg HTTP/1.1
%...sの応答コード200%...tSTON デフォルトの時間形式2014-01-01 15:27:02
%...{format}tFormatで定義されている日付形式%{%Y-%m-%d %H:%M:%S}T と入力すると 2014-08-07 06:12:23 に記録した。%...TTimeTaken(秒単位)10%...UShortURI/img/img.jpg
%...uFullURI/img/img.jpg?session=1232&id=37
%...Xトランザクションが完了したときの状態X応答が完了する前に終了C応答が完了した
C%...Iリクエストヘッダを含む受信バイト2048%...Oレスポンスヘッダを含む送信バイト2048%...R応答時間(MS)2%...eSession-ID1%...SキャッシュHIT結果TCP_HIT%...KリクエストHTTPのバージョンHTTP/1.1
%...yリクエストのHTTPヘッダサイズ488%...z応答のHTTPヘッダサイズ362
設定したフィールドの値が存在しない場合 - で表記します。 形式が間違ってたらSTONデフォルトフォーマット（Form = "ston"）で動作します。
上の表では各フィールドの…には (e.g. “%h %U %r %b) 何も明示しなかったり記録条件を明示することができます。（条件を満たしていない場合 - で記録）。 条件はHTTPステータスコードのリストに設定するか！でNOT条件を設定することができます。
次の例では 400(Bad Request) エラーまたは 501(Not Implemented) エラーの場合にのみUser-agentを記録します。
"%400,501{User-agent}i"
次の例では正常な状態ではなくすべてのリクエストでRefererをログに残す。
"%!200,304,302{Referer}i"
Originログ¶
オリジンサーバーのすべてのHTTPトランザクションを記録します。 記録時点ではHTTPトランザクションが完了した時点で転送完了または送信停止時点を意味します。
# server.xml - <Server><VHostDefault><Log>
# vhosts.xml - <Vhosts><Vhost><Log>
<Origin Type="time" Unit="1440" Retention="10" Local="Off">ON</Origin>
#Fields: date time cs-sid cs-tcount c-ip cs-method s-domain cs-uri s-ip sc-status cs-range sc-sock-error sc-http-error sc-content-length cs-requestsize sc-responsesize sc-bytes time-taken time-dns time-connect time-firstbyte time-complete cs-reqinfo cs-acceptencoding sc-cachecontrol s-port sc-contentencoding session-id session-type
2012.06.27 17:40:00 357 899 192.168.0.13 GET i.example.com /t/2.gif 115.71.9.136 200 - - - 3874 197 271 3874 20 0 0 17 3 - gzip+deflate - 80 gzip 7 cache
2012.06.27 17:40:00 357 900 192.168.0.13 GET i.example.com /ex1.gif 115.71.9.136 200 - - - 5673 223 272 5673 24 0 0 21 3 - - - 80 - 8 cache
2012.06.27 17:40:00 357 901 192.168.0.13 GET i.example.com /exB.jpg 115.71.9.136 200 - - - 8150 189 273 8150 13 0 0 9 4 Bypass - - 80 - 7 cache
#[ERROR:01] 2012.06.27 17:40:01 220.73.216.5 220.73.216.5 GET /web/nmb/img/main/v1/h1.gif 1824 Connect-Timeout - 11 cache
2012.06.27 17:40:00 357 901 192.168.0.13 GET i.example.com /exB1.jpg 115.71.9.136 200 - - - 8150 189 273 8150 13 0 0 9 4 - max-age=3600 80 - 12 cache
2012.06.27 17:40:00 357 901 192.168.0.13 GET i.example.com /exB2.jpg 115.71.9.136 200 - - - 8150 189 273 8150 13 0 0 9 4 - no-cache 80 - 35 cache
2012.06.27 17:40:00 357 901 192.168.0.13 GET i.example.com /exB3.jpg 115.71.9.136 200 - - - 8150 189 273 8150 13 0 0 9 4 - - 80 - 35 cache
オリジンサーバーで障害が発生した場合＃[ERROR：xx]で始まるエラーログが記録されます。 すべてのフィールドはスペースで区切られ各フィールドの意味は次のとおりです。
元の時間測定区間
dateHTTPトランザクションが完了した日付timeHTTPトランザクションが完了した時刻cs-sidセッションの一意のID。 同じセッションで処理された（再された）HTTPトランザクションは同じ値を持つ。cs-tcountトランザクション数。 このHTTPトランザクションが現在のセッションで何番目に処理されたトランザクションであることを記録します。 同じcs-sid値を持つトランザクションであればこの値は重複することができない。c-ipSTONのIPcs-method元サーバーに送信HTTP Methods-domainオリジンサーバーのドメインcs-uri元サーバーに送信URIs-ipオリジンサーバーのIPsc-statusオリジンサーバーHTTP応答コードcs-rangeオリジンサーバーに送信されるRange要求値sc-sock-errorソケットエラーコード（1 =送信失敗、2 =伝送遅延、3 =接続の終了）sc-http-errorオリジンサーバーが4xxまたは5xx応答を与えてくれたときに応答コードを記録sc-content-lengthオリジンサーバーが送信したContent Lengthcs-requestsize (単位: Bytes)オリジンサーバーに送信されるHTTPリクエストヘッダサイズsc-responsesize (単位: Bytes)オリジンサーバーが応答したHTTPヘッダーのサイズsc-bytes (単位: Bytes)受信したコンテンツサイズ（ヘッダを除く）time-taken (単位: ms)HTTPトランザクションが完了するまでにかかった合計時間。 セッションの再利用がない場合はソケット接続時間まで含んでいる。time-dns (単位: ms)DNSクエリにかかった時間time-connect (単位: ms)オリジンサーバーとソケットEstablishedまでかかった時間time-firstbyte (単位: ms)要求を送信し応答が来るまでかかった時間time-complete (単位: ms)最初の応答から完了するまでにかかった時間cs-reqinfo付加情報。 "+"の文字で区切られている。 バイパスした通信であれば "Bypass", Privateバイパスなら "PrivateBypass"に記録されます。cs-acceptencodingオリジンサーバーに圧縮されたコンテンツを要求すると "gzip+deflate"に記録されます。sc-cachecontrol元サーバーが送信したcachecontrolヘッダs-portオリジンサーバーのポートsc-contentencoding元サーバーが送信されるContent-Encodingヘッダsession-idオリジンサーバー要求を発生させたHTTPクライアントセッションID（unsigned int64）session-typeオリジンサーバーに要求されたセッションのタイプcacheキャッシュ用途に使用されたセッションrecovery障害の検知と復旧 で復旧の目的で使用されたセッションhealthcheckHealth-Checker が使用セッション
Monitoringログ¶
5分平均の統計を記録します。
# server.xml - <Server><VHostDefault><Log>
# vhosts.xml - <Vhosts><Vhost><Log>
<Monitoring Type="size" Unit="10" Retention="10" Form="json">ON</Monitoring>
Formログ形式を指定します。 (jsonまたはxml)
FileSystemログ¶
第19章 File System を使用して発生するすべてのFile I / Oトランザクションを記録します。
# server.xml - <Server><VHostDefault><Log>
# vhosts.xml - <Vhosts><Vhost><Log>
<FileSystem Type="time" Unit="1440" Retention="10">ON</FileSystem>
File I/O トランザクションの終了時に記録されます。 トランザクションの終了時点ではcs-methodの形態に依存します。
#Fields: date time cs-method cs-path sc-status sc-bytes response-time time-taken sc-cachehit attr session-id
2012.06.27 16:52:24 ATTR /t 200 0 100 100 TCP_HIT FOLDER 1
2012.06.27 16:52:24 ATTR /t/2.gif 200 0 100 100 TCP_HIT FILE 1
2012.06.27 16:52:24 OPEN /file.txt 200 0 100 2000 TCP_HIT FILE 2
2012.06.27 16:52:24 READ /file.txt 200 1024768 100 2000 TCP_HIT FILE 2
dateFile I/Oトランザクションが完了した日付timeFile I/Oトランザクションが完了した時刻cs-methodFile I/Oアクセスを形成します。 次の3つのいずれかを持つ。ATTRgetattr関数を呼び出します。 関数が返されたときのログ記録OPENファイルは開かれたがREADしません。 ファイルが閉じられるときにログ記録READファイルを開きREADした。 ファイルが閉じられるときにログ記録
cs-pathアクセスパスsc-status応答コード。 通常のサービス（200）を除いた処理に失敗コードは次のとおりです。200通常のサービス301バイパスが必要302サービス拒否303Redirect必要400不正な要求401仮想ホストが見つからなかった402元からの初期化に失敗し500オブジェクトの初期化に失敗し501オブジェクトOpen失敗502保存パスの作成に失敗し503メモリの初期化に失敗し504Emergency状態600ファイルサービス待機中Timeout601ファイルのデータサービス待機中Timeout602ファイルサービス待機中のファイルの初期化に失敗し603ファイルのデータサービス待機中のデータの初期化に失敗し701誤ったOffset702ファイルの特定の領域をロードに失敗し703Not enough memory704元セッションの作成に失敗し
sc-bytesReadされたサイズresponse-time関数の呼び出し ~ サービスオブジェクトを接続するのに必要された時間time-taken関数の呼び出し ~ File I / O Transactionが完了されかかった時間sc-cachehitキャッシュHITの結果attrFILE または FOLDERsession-idFile I/O セッション ID (unsigned int64)注釈
session-idはClient（HTTPまたはFile I / O）Contextが作成されるときに割り当てられる。 一般的なファイル処理過程であるOpen - > Read - > CloseではOpen時点でClient Contextが作成されClose時点で破壊されます。 一方getattr関数はアトミック（Atomic）関数なので毎回Client Contextが作成/破壊され常に新しいsession-idを割り当てられる。
FTP転送¶
ログがローテートされる指定されたFTPクライアントを使用してログをアップロードします。
FTPクライアント¶
FTPクライアントを設定します。 ローテートされたログをリアルタイムでFTPサーバにアップロードします。
FTPクライアントの構造と動作
FTPクライアントは上図のようSTON外部に存在します。 STONはローカルに存在するログをFTPクライアントキューに入力するだけでFTPの動作には関与しません。 FTPクライアントは自分の設定に応じてアップロードを行う。
FTPクライアントはグローバル設定（server.xml）に設定します。
# server.xml - <Server>
<Ftp Name="backup1">
<Mode>Passive</Mode>
<Address>ftp.winesoft.co.kr:21</Address>
<Account>
<ID>test</ID>
<Password>12345abc</Password>
</Account>
<ConnectTimeout>10</ConnectTimeout>
<TransferTimeout>600</TransferTimeout>
<TrafficCap>0</TrafficCap>
<DeleteUploaded>OFF</DeleteUploaded>
<BackupOnFail>OFF</BackupOnFail>
<UploadPath>/log_backup/%v/%s-%e.%p.log</UploadPath>
<Transfer Time="Rotate" />
</Ftp>
<Ftp Name="backup2">
<Mode>Active</Mode>
<Address>192.168.0.14:21</Address>
<Account>
<ID>test</ID>
<Password>qwerty</Password>
</Account>
<ConnectTimeout>3</ConnectTimeout>
<TransferTimeout>100</TransferTimeout>
<TrafficCap>10240</TrafficCap>
<DeleteUploaded>ON</DeleteUploaded>
<BackupOnFail>ON</BackupOnFail>
<Transfer Time="Static">04:00</Transfer>
</Ftp>
<Ftp>FTPクライアントを設定します。Name属性に固有の名前を設定します。Mode (デフォルト: Passive)接続モード (PassiveまたはActive)AddressFTPアドレス。AccountFTPアカウント。 もしパスワード（例えばqwerty）を暗号化したい場合は次のAPIを使用します。/command/encryptpassword?plain=qwerty
暗号化されたパスワードは次のように設定します。
<Password Type="enc">dXR9k0xNUZVVYQsK5Bi1cg==</Password>
ConnectTimeout接続待機時間TransferTimeout送信待機時間TrafficCap (単位: KB)0より大きい値に設定した場合の転送の最大帯域幅を設定します。DeleteUploaded (デフォルト: OFF)送信完了後にログを削除します。BackupOnFail (デフォルト: OFF)送信失敗時のログが削除されないようにログを次のパスにバックアップします。/usr/local/ston/stonb/backup/
バックアップされたログは再送信せず管理者が削除するまで削除されない。
UploadPathアップロードパスを設定します。 別に設定しない場合は "/仮想ホスト/" にアップロードします。 example.comのログは/example.com/ディレクトリにアップロードされます。%{time format}sログの開始時間%{time format}eログ終了時刻%pprefix%v仮想ホスト名%h機器HOST名
例えば次のように設定した場合
# server.xml - <Server><Ftp> <UploadPath>/log_backup/%v/%s-%e.%p.log</UploadPath>
アップロードパスは次のとおりです。
/log_backup/example.com/200140722_0000-200140722_2300.access.log
Transferログ転送時間を指定します。Type属性に基づいて値の形式が違ってくる。Rotate (デフォルト)ローテートされるとすぐに送信します。 値を持たない。Static一日一回指定した時間に送信します。 たとえば04:00に設定とすれば午前4時に送信を開始します。Interval一定時間間隔で送信します。 たとえば4に設定した場合4時間間隔でログを送信します。
転送時間を設定した場合その時点でログがローテートされないように適切にログ管理ポリシーを設定する必要があります。
FTPクライアントはcurlを使用します。
FTPのログ¶
FTPのログは/usr/local/ston/sys/stonb/stonb.logに統合して保存されます。
#Fields: date time local-path cs-url file-size time-taken sc-status sc-error-msg
2014-04-23 17:10:20 /ston_log/winesoft.co.kr/origin_20140423_080000.log ftp://ftp.winesoft.co.kr:21/winesoft.co.kr/origin_20140423_080000.log 381 10006 fail "curl: (7) couldn't connect to host"
2014-04-23 17:10:20 /ston_log/winesoft.co.kr/access_20140423_1700.log ftp://192.168.0.14:21/winesoft.co.kr/access_20140423_1700.log 260 60 success "-"
2014-04-23 17:11:00 /ston_log/winesoft.co.kr/origin_20140423_080000.log ftp://ftp.winesoft.co.kr:21/winesoft.co.kr/origin_20140423_080000.log 381 10008 fail "curl: (7) couldn't connect to host"
2014-04-23 17:11:00 /ston_log/winesoft.co.kr/filesystem_20140423_080000.log ftp://192.168.0.14:21/winesoft.co.kr/filesystem_20140423_080000.log 179 60 success "-"
すべてのフィールドはスペースで区切られ各フィールドの意味は次のとおりです。
date日time時間local-path転送ログのローカルパスcs-url転送FTPアドレスfile-size転送ファイルサイズtime-taken (単位: ms)伝送所要時間sc-status伝送成功/失敗（successまたはfail）sc-error-msg送信失敗時curlエラーメッセージ
ログFTP転送¶
ログがローテートされる指定されたFTPクライアントを介してアップロードします。 コンマ（、）で区切って複数のFTPクライアントを同時に使用することができます。
# server.xml - <Server><VHostDefault>
# vhosts.xml - <Vhosts><Vhost>
<Log>
<Access Ftp="backup1, backup2">ON</Access>
<Origin Ftp="backup_org">ON</Origin>
<Monitoring Ftp="backup1">ON</Monitoring>
<FileSystem Ftp="backup2">ON</FileSystem>
</Log>
Ftp使用 FTP クライアント
ftp://{FTPサーバーアドレス}/{仮想ホスト名}/{ローテートされたログ名}でログをアップロードします。 たとえばftp.dummy.comサーバーに仮想ホストexample.comのローテートされたログ（access_20140424_0000.log）をアップロードするアドレスは ftp://ftp.dummy.com/example.com/access_20140424_0000.logになる。
第13章 WM（Web Management）¶
この章ではWeb Management（以下WM）を紹介する。 WMはAPIをベースに動作するWeb管理ツールである。 WMを介して直感的にサービスを構成することができるだけでなく、クラスタを構成して、多数のSTONを統合管理することができる。
STONをインストールすると/usr/local/ston/wmパスにWMが設置されます。 WMはApache 2.2.24 + PHP 5.3.24に実装された。 Apacheを使用するため/usr/local/ston/wm/conf/httpd.confファイルを編集して必要な構成（例えばHTTPS）に変更が可能です。 WMとSTONは密接な関連を持たない。 次の図のようにWMはSTONの設定ファイルとAPIのみでSTONの動作を構成します。
WMはSTONの設定ファイルとAPIを使用します。
私たちは、同様の方法でWMを凌駕する優れた管理手法が存在すると考えている。
接続¶
WMは8500番ポートを使用します。 インストールされたSTONのIPアドレスが192.168.0.100の場合WMアクセスアドレスは http://192.168.0.100:8500になる。 httpd.confファイルを変更するとカスタマイズが可能です。
WM接続の初期画面
アカウント¶
デフォルトのアカウントは [ユーザ名: admin 、 パスワード: ston ] です。 ログインに成功するとSTONの全体的な状態を確認できるダッシュボードページが表示されます。
WMのダッシュボード
最新バージョンの更新¶
最新バージョンがリリースされると次のように "新しいアップデートがあります" というメッセージが表示されます。
新しい更新があります。
メッセージをクリックすると最新のバージョンに更新することができるページが表示されます。 現在の動作中のサービスがある場合statusが表示されます。
WMの更新と危険です。
アップデートが完了するとすべてのサービスが自動的に再起動されます。
メニュー構成¶
メニューはDrop Downメニューで構成されています。
WMメニュー
グローバル設定
グローバル設定（server.xml）の仮想ホストの基本設定以外のすべての機能を設定します。
仮想ホストの管理
仮想ホストの追加/停止/削除ができサービス中のすべての仮想ホストの状態を一目で見ることができます。
クラスター
クラスターを構成/管理/削除することができ、同じクラスター内のすべてのサービスをサーバ別・サービス別に見ることができます。
コンテンツ制御
Purgeのようにサービスされているコンテンツに対して制御することができます。
サーバーの状態
システムstatusのようなグローバル・リソースをモニタリングします。 すべてのGraphはグローバルリソースのGraphを使用します。
サービスの状態
仮想ホストのサービスの状態をモニタリングします。 すべてのGraphは仮想ホストGraphを使用します。
仮想ホストの管理¶
サービスを提供するすべての仮想ホストについて詳細に設定し新規の仮想ホストを追加します。 すべての仮想ホストは別に明示的に設定を変更しない限りデフォルトの仮想ホスト（VHostDefault）の設定を使用します。 これはオブジェクト指向の継承（Inheritance）のような概念です。 サービスの仮想ホストはほとんどの項目を財政の（Overriding）することができます。
新規¶
新たにサービスする仮想ホストを作成します。 クラスターが設定されている場合すべてのサーバーに仮想ホストを同時に生成することができます。 すべての仮想ホストはデフォルトの仮想ホスト（VHostDefault）を継承されるため仮想ホスト名と元サーバーのアドレスを設定するだけすぐにサービス投入が可能です。 8つのサブ設定があり Expand ボタンを押して詳細設定で拡張することができます。
WM仮想ホストの管理-新規
リスト¶
サービス中のすべての仮想ホストの状態をモニタリングすることができます。 仮想ホストごとに開始/停止が可能です。 クラスターが設定されている場合はすべてのサーバーの仮想ホストを同時に制御することができます。 またデフォルトの仮想ホストを選択することができます。
WM仮想ホストの管理-リスト
詳細設定¶
デフォルトの仮想ホスト（VHostDefault）と個々の仮想ホストに設定します。 左上のコンボボックスを選択して仮想ホストを選択することができます。 "Default仮想ホスト" はすべての仮想ホストが継承するデフォルト設定です。 したがって特別な設定がない場合 "Default 仮想ホスト" を変更すると変更された設定が反映されます。
WMバーチャルホストの設定-トップメニュー
上の図のように多くのサブメニューが提供され現在選択されてサブメニューが赤い色で表示されます。 各メニューをクリック時下図のように詳細設定ページが提供されます。 すべての設定は "適用" または "Cluster全体に適用" ボタンを押したら反映されます。
WMバーチャルホストの設定-オリジンサーバー
ここで設定するほぼすべての項目は上書きする設定になる明確な理解が必要です。 たとえば既定の仮想ホストのTTL値が60に設定された場合すべての仮想ホストはこの値を継承します。 しかし明示的にこの値を上書きする場合は該当仮想ホストに限って上書きされた値を使用します。
次のように3つの場合が存在することができます。
他の値で財政の
Aの場合のようにデフォルト値は60ですが180で上書きする場合はAユーザーは180でサービスされます。 デフォルトの仮想ホストの設定を変更しても影響を受けない。
同じ値で財政の
Bの場合のようにデフォルト値と同じ値に設定しても上書きと判断してBのユーザーは60でサービスされます。 今後デフォルトの仮想ホストのTTL値が30に変更されても再定義がされているのでBユーザーの設定（60）は影響を受けない。
上書きしない
Cの場合のように省略された場合デフォルトの仮想ホストの設定を継承してCユーザーは60でサービスされます。 今後デフォルトの仮想ホストのTTL値が30に変更されるとCユーザーも30でサービスされます。
WMは色で上書きを区分します。 デフォルトの仮想ホストの設定をそのまま使用している場合は白い背景で表示されます。 オーバーライドされた値は杏色に表示されてデフォルトと区別されます。 すべての上書きの設定の右側にはXボタンが提供されます。 このボタンをクリックして上書きを終了します。
クラスター¶
複数のSTONを1つのクラスターに統合して一括して管理/運営することができます。 すべてのSTONは同等の関係に設定されるためクラスターに含まれているいくつかのSTONにログインしてもクラスター全体を管理することができます。
構成¶
クラスターを作成したり既に存在しているクラスターに別のサーバーを追加することができます。 クラスターに追加にはWMアカウントの認証手続きが必要です。 同じアカウント（ユーザ名とパスワード）でWMが構成されている場合認証手続きは省略されます。
新規クラスターの作成
クラスターリスト
クラスターが構成され仮想ホストの管理時に "Cluster全体に適用" ボタンで一括設定が可能です。 またクラスターに所属されたサーバー間には簡単にすべての設定を複製することができます。 特定のサーバーを別のクラスターに参加させたい場合は分離後の再参加が必要です。
専用ポート分離¶
初期インストール時にWMとクラスターポートが同じポートを使用します。 この方式はWMアカウントだけでクラスターリング構成が可能なメリットがありますがアクセスIPを制限する場合は問題になる場合があります。
- セキュリティ上の理由でWMにアクセスできるIPを制限したい。
- クラスターリングのためにはすべてのサーバーが別のサーバーのIPアドレスを許可する必要がある。
- （CDNのような）サーバーの数が非常に多いかサーバーのIPアドレスがダイナミックな場合はIPリストを作成ができない。
クラスターポートを分離してこの問題を解決することができます。 サーバー間の通信はWMアカウントではなくライセンスを使用して確認されます。 同じライセンスを持つサーバ間だけクラスター構成が可能となりセキュリティが高くなる。
1. [Apacheサーバー] httpd.confマルチPort設定
(デフォルトのインストールであれば) /usr/local/ston/wm/conf/httpd.conf ファイルを開き次のようにポートを追加します。
保存して反映するためのApacheサーバーを再起動します。
2. [WM]クラスター構成
通常のマルチポート設定がされた場合は次のように "クラスターポートの分離" ボタンが生成されます。
ボタンをクリックします。
3. [WM]クラスターポートの選択
分離可能なポートのリストが表示されます。 ポートを選択し構成します。
クラスターリングに参加するすべてのサーバーは同じポートを使用する必要があります。
サーバーの状態¶
クラスターに参加中のすべてのSTONサーバーの状態とサービスの現状を確認することができます。 サーバーのリストを構成する各項目をクリックするとより詳細な情報を確認することができます。
サーバー別のステータス
仮想ホストの状態¶
クラスターでサービスを提供するすべての仮想ホストのMRTGを総合して確認することができます。 タのすべての仮想ホストを同時に開始/停止することができます。 仮想ホストのリストを構成する各項目をクリックするとより詳細な情報を確認することができます。
仮想ホストのサービス別の状態
API¶
APIを介してクラスター構成サーバーのリストを照会することができます。
http://SERVER_IP:10040/monitoring/clusterlist
クラスターが構成されている場合結果は以下の通りです。
{
"version": "2.5.5",
"method": "clusterlist",
"status": "OK",
"result":
{
"Name" : "test",
"Node" :
[
{ "Address" : "192.168.0.148:8500"},
{ "Address" : "192.168.0.175:8500"}
]
}
}
失敗（クラスターが構成されていない、またはクラスター照会が失敗）の状況では以下のように答えている。
{
"version": "2.5.5",
"method": "clusterlist",
"status": "Fail",
"result": { }
}
コンテンツ制御¶
サービス中のコンテンツを閲覧/制御したりクリーンアップを実行することができます。 クラスター構成になっている場合はすべてのSTONのコンテンツを同時に閲覧したり制御することができます。
Caching状態の確認
PurgeなどのAPI呼び出し
4部。 高度な機能¶
第14章 仮想ホストの高度なテクニック¶
この章では仮想ホストを使用してサービスを柔軟に構成する複数の方法について説明します。
仮想ホストは一般的にオリジンサーバーのDomainまたはIPリストと1：1で構成されます。 しかし状況に応じて代表仮想ホストを複数のサブ仮想ホストに分岐したり反対に独立した複数の仮想ホストを一つのサービスとして提供する場合も発生します。 各機能に応じて クライアント統計 / Accessログ のポリシーが異なる場合があることに注意する必要があります。
URL前処理¶
正規表現 使用して要求されたURLを変更します。 URL前処理が設定されている場合はすべてのクライアントの要求（HTTPまたはFile I / O）は必ずURL Rewriterを経る。
URL Rewriterを経由して仮想ホストにアクセスします。
もしURL RewriterによってアクセスしようとするHostの名前が変更された場合クライアントのHTTP要求のHostヘッダが変更されたとみなされます。 URLの前処理は仮想ホストの設定（vhosts.xml）に設定します。 ほとんどの設定は仮想ホストに依存しますがURL前処理の場合クライアントが要求したHostの名前を変更することができますので仮想ホストと同じレベルに設定します。
# vhosts.xml
<Vhosts>
<Vhost ...> ... </Vhost>
<Vhost ...> ... </Vhost>
<URLRewrite ...> ... </URLRewrite>
<URLRewrite ...> ... </URLRewrite>
</Vhosts>
マルチに設定することができ順次正規表現に一致有無を比較します。
# vhosts.xml - <Vhosts>
<URLRewrite AccessLog="Replace">
<Pattern>www.exmaple.com/([^/]+)/(.*)</Pattern>
<Replace>#1.exmaple.com/#2</Replace>
</URLRewrite>
<URLRewrite>
- URL前処理を設定します。
AccessLog (デフォルト: Replace)属性はAccessログに記録されるURLを設定します。Replaceの場合変換後のURL（/logo.jpg）をPatternの場合変換前のURL（/baseball/logo.jpg）をAccessログに記録します。
<Pattern>マッチングさせるパターンを設定します。 一つのパターンは（）括弧を使用して表現されます。<Replace>変換形式を設定します。 一致したパターンには＃1＃2のように使用することができます。 ＃0は要求URL全体を意味します。 パターンは最大9個（＃9）まで指定することができます。
スループットは 第10章 モニタリング＆統計 で提供され URL前処理成功 でも確認することができます。 URL前処理は Trimming 、 MP4 HLS などの他の機能と組み合わせて表現を簡単にします。
# vhosts.xml - <Vhosts>
<URLRewrite>
<Pattern>example.com/([^/]+)/(.*)</Pattern>
<Replace>example.com/#1.php?id=#2</Replace>
</URLRewrite>
// Pattern : example.com/releasenotes/1.3.4
// Replace : example.com/releasenotes.php?id=1.3.4
<URLRewrite>
<Pattern>example.com/download/(.*)</Pattern>
<Replace>download.example.com/#1</Replace>
</URLRewrite>
// Pattern : example.com/download/1.3.4
// Replace : download.example.com/1.3.4
<URLRewrite>
<Pattern>example.com/img/(.*\.(jpg|png).*)</Pattern>
<Replace>example.com/#1/STON/composite/watermark1</Replace>
</URLRewrite>
// Pattern : example.com/img/image.jpg?date=20140326
// Replace : example.com/image.jpg?date=20140326/STON/composite/watermark1
<URLRewrite>
<Pattern>example.com/preview/(.*)\.(mp3|mp4|m4a)$</Pattern>
<Replace><![CDATA[example.com/#1.#2?&end=30&boost=10&bandwidth=2000&ratio=100]]></Replace>
</URLRewrite>
// Pattern : example.com/preview/audio.m4a
// Replace : example.com/audio.m4a?end=30&boost=10&bandwidth=2000&ratio=100
<URLRewrite>
<Pattern>example.com/(.*)\.mp4\.m3u8$</Pattern>
<Replace>example.com/#1.mp4/mp4hls/index.m3u8</Replace>
</URLRewrite>
// Pattern : example.com/video.mp4.m3u8
// Replace : example.com/video.mp4/mp4hls/index.m3u8
<URLRewrite>
<Pattern>example.com/(.*)_(.*)_(.*)</Pattern>
<Replace>example.com/#0/#1/#2/#3</Replace>
</URLRewrite>
// Pattern : example.com/video.mp4_10_20
// Replace : example.com/example.com/video.mp4_10_20/video.mp4/10/20
注釈
次のように類似したサブドメインがある場合は注意する必要があります。
image.example.com
myimage.example.com
正規表現では、image.exampe.comにパターンを作成した場合myimage.example.comもパターンと一致するものとみなされる。 これを防止するために、先頭に文字なしを ^ で表記ヘジュオヤimage.example.comのみマッチングさせることができる。
<URLRewrite>
<Pattern>^image.example.com/img/(.*\.(jpg|png).*)</Pattern>
<Replace>image.example.com/#1/STON/composite/watermark1</Replace>
</URLRewrite>
パターンの表現にXMLの5つの特殊文字（ " ＆ ' < > ）が入る場合は<！[CDATA [... ]]>で囲んで正しく設定されている。 第13章 WM（Web Management） を使用して設定するとすべてのパターンはCDATAとして処理されます。
Facade仮想ホスト¶
<Alias> は仮想ホストの別名だけを追加しているので統計とログが分離されない。 仮想ホストは共有がドメインに基づいて クライアント統計 と Accessログ を分離したい場合Facade仮想ホストを設定します。
facadeは統計とログを収集します。
# vhosts.xml - <Vhosts>
<Vhost Name="example.com">
...
</Vhost>
<Vhost Name="another.com" Status="facade:example.com">
...
</Vhost>
Status 属性の値を facade: + 仮想ホスト に設定します。 例の場合 クライアント統計 と Accessログ はexample.comではなくクライアントが要求したドメインであるanother.comに収集されます。
Sub-Path指定¶
仮想ホストでパス別に他の仮想ホストが処理するように設定することができます。
統計/ログは要求を最終処理した各仮想ホストに記録されます。
# vhosts.xml - <Vhosts>
<Vhost Name="sports.com">
<Sub Status="Active">
<Path Vhost="baseball.com">/baseball/<Path>
<Path Vhost="football.com">/football/<Path>
<Path Vhost="photo.com">/*.jpg<Path>
</Sub>
</Vhost>
<Vhost Name="baseball.com" />
<Vhost Name="football.com" />
<Vhost Name="photo.com" />
<Sub>パスまたはパターンが一致するとその要求を別の仮想ホストに送る。 一致しない場合のみ現在の仮想ホストが処理します。Status (デフォルト: Active)Inactiveの場合は無視します。<Path>クライアントが要求したURIとパスが一致した場合Vhostにその要求を送る。 値はパスまたはパターンのみ可能です。<Path Vhost="baseball.com">baseball<Path> <Path Vhost="photo.com">*.jpg<Path>
上記のように入力してもそれぞれ/ baseball /と/*.jpgとして認識されます。
たとえばクライアントが次のようにリクエストした場合その要求は仮想ホストのfootball.comが処理します。
GET /football/rank.html HTTP/1.1
Host: sports.com
Redirect追跡¶
オリジンサーバーでRedirect系（301、302、303、307）で応答する場合Locationヘッダを追跡してコンテンツを要請します。
クライアントはRedirectかどうかを知らない。
# server.xml - <Server><VHostDefault><OriginOptions>
# vhosts.xml - <Vhosts><Vhost><OriginOptions>
<RedirectionTrace>OFF</RedirectionTrace>
<RedirectionTrace>OFF (デフォルト)3xx 応答で保存されます。ONLocationヘッダに記載されアドレスからコンテンツをダウンロードします。 形式に合わない場合Locationヘッダがない場合は動作しません。 無限Redirectされることを防止するため1回だけ追跡します。
仮想ホストのリンク¶
コンテンツが複数のオリジンサーバーに分散している場合は仮想ホストのリンクを利用してコンテンツが統合されているようにサービスが可能です。 特にOn-Premiseからクラウドにストレージへのマイグレーションまたはストレージのコンテンツが分散している環境に有用です。
cloud.comにないコンテンツはnas.comが処理します。
# vhosts.xml - <Vhosts><Vhost>
<VhostLink Condition="...">...</VhostLink>
<VhostLink>要求を委任する仮想ホスト名。 コンテンツのオリジンサーバーの応答がConditionを満足すれば指定した仮想ホストに要求を委任します。 ただし一つだけ設定することができます。ConditionHTTP応答コード/パターン（1xx、2xx、3xx、4xx、5xx）、fail（オリジンサーバーからキャッシュしていなかった場合）
クライアントの要求が他の仮想ホストに委任されても クライアント統計 と Accessログ はクライアントがアクセスした仮想ホストに記録されます。
注釈
リンク関係にある仮想ホストの設定が異なる場合意図しない動作する場合がありますので注意する必要があります。 仮想ホストのリンクがA（単純キャッシュ） - > B（イメージ圧縮）で結ばれている場合はAで処理されたイメージは圧縮されませんがBで処理されたイメージは圧縮されます。
たとえばnas.comのコンテンツをcloud.comに移転している場合cloud.comにない（= 404 Not Found）コンテンツのみnas.comに要求を送信します。 以下の場合要求はnas.comによって処理されても クライアント統計 と Accessログ はcloud.comに記録されます。
# vhosts.xml - <Vhosts>
// cloud.comにない(=404 Not Found) のコンテンツは nas.comで サービスする。
<Vhost Name="cloud.com">
<VhostLink Condition="404">nas.com</VhostLink>
</Vhost>
<Vhost Name="nas.com">
</Vhost>
Accessログ のvhostlinkフィールドを介してクライアントの要求がどの仮想ホストで処理されたことが確認できます。 "-" は要求がリンクされていないことを意味し "nas.com" は要求がリンクされてnas.comで処理されたことを意味します。
#Fields: date time s-ip cs-method cs-uri-stem ...(中略)... vhostlink
2016.11.24 16:52:24 220.134.10.5 GET /web/h.gif ...(中略)... -
2016.11.24 16:52:26 220.134.10.5 GET /favicon.ico ...(中略)... nas.com
リンクが複数回発生した場合 "+" を区切り文字としてリンクされたすべての仮想ホストが表示されます。 この場合最後の仮想ホストが最終リクエストを処理した仮想ホストです。
次のように複数の仮想ホストを別の条件でリンクすることができます。
# vhosts.xml - <Vhosts>
// オリジンサーバーが 5 xxに 応答したり キャッシュしてい なかった 場合 （= fail） 要求を bar.comに 委任する 。
<Vhost Name="foo.com">
<VhostLink Condition="5xx,fail">bar.com</VhostLink>
</Vhost>
// オリジンサーバーが 4 xxに 応答した ときに その 要求を helloworld.comに 委任する 。
<Vhost Name="bar.com">
<VhostLink Condition="4xx">helloworld.com</VhostLink>
</Vhost>
// オリジンサーバーで 403404または 5 xxに 応答した ときに その 要求を example.comに 委任する 。
<Vhost Name="helloworld.com">
<VhostLink Condition="403,404,5xx">example.com</VhostLink>
</Vhost>
// これ以上は委任しない 。
<Vhost Name="example.com">
</Vhost>
抑止ながら可能です。
上記の例の場合foo.comの Accessログ は次のとおりです。
#Fields: date time s-ip cs-method cs-uri-stem ...(中略)... vhostlink
2016.11.24 16:52:24 220.134.10.5 GET /test.jpg ...(中略)... bar.com+helloworld.com+example.com
次の場合はリンクはすぐに中断されます。
- ターゲット仮想ホストが存在しない場合（foo.com - >？）
- 自分自身をターゲット仮想ホストに指定した場合（foo.com - > foo.com）
- 再帰リンク（Recursive Link）が発生した場合（foo.com - > bar.com - > foo.com）
第15章 アクセス制御¶
この章では不要なクライアントアクセスをブロックする方法について説明します。 アクセスブロックは通常ACL（Access Control List）にブロックリスト（Black-list）を作成しますが許可リスト（White-list）を作成することもあります。
アクセス制御はアクセスの段階で実行するサーバーへのアクセス制御と仮想ホストごとに設定する仮想ホストのアクセス制御に分けられる。 レベルごとに視点と判断基準が異なりますので効果的なブロック時点を決定する必要があります。 アクセス制御の動作はすべてログに記録されます。
サーバーアクセス制御¶
クライアントがサーバーに接続した瞬間IP情報を使用してブロック有無を決定します。 接続の段階で処理されるため最も確実で速い。 グローバル設定（server.xml）に設定し最も高い優先順位を持つ。
# server.xml - <Server><Host>
<ServiceAccess Default="Allow">
<Deny>192.168.7.9-255</Deny>
<Deny>192.168.8.10/255.255.255.0</Deny>
</ServiceAccess>
<ServiceAccess>IPベースのACLを設定します。 IP、IP Range、Bitmask、Subnetの四つの形式をサポートします。 順序を認識し上に設定された表現が優先します。Default (デフォルト: Allow)属性は一致する条件がない場合の処理方法です。 この属性をDenyに設定すると下位に<Allow>で許可する条件を明記する必要があります。
ブロックされたIPは Denyログ に記録されます。
GeoIP¶
GeoIPを使用して国別のアクセスを遮断することができます。 GeoIP Databases 中Binary Databasesを GEOIP_MEMORY_CACHE and GEOIP_CHECK_CACHE へのリンクしてリアルタイムで変更を反映します。
# server.xml - <Server><Host>
<ServiceAccess GeoIP="/var/ston/geoip/">
<Deny>AP</Deny>
<Deny>GIN</Deny>
</ServiceAccess>
<ServiceAccess> の GeoIP 属性にGeoIP Databasesパスを設定します。 国コードは ISO 3166-1 alpha-2 と
ISO 3166-1 alpha-3 をサポートします。
注釈
GeoIPはファイル名が予約されているので必ず保存されたローカルパスを設定します。 変更は自動的に反映されるます。
GeoIPが設定されている場合はそのディレクトリに保存されたファイルの一覧を表示します。 設定されていない場合404 NOT FOUNDに応答します。
http://127.0.0.1:10040/monitoring/geoiplist
結果はJSON形式で提供されます。
{
"version": "2.0.0",
"method": "geoiplist",
"status": "OK",
"result":
{
"path" : "/usr/ston/geoip/",
"files" :
[
{
"file" : "GeoIP.dat",
"size" : 766255
},
{
"file" : "GeoLiteCity.dat",
"size" : 12826936
}
]
}
}
仮想ホストへのアクセス制御¶
仮想ホストごとにサービスを許可/ブロック/ redirectを設定します。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<AccessControl Default="Allow" DenialCode="401">OFF</AccessControl>
<AccessControl>OFF (デフォルト)ACLが有効になっていない。 すべてのクライアントの要求を許可します。ONACLが有効になる。 ブロックされた要求にはDenialCode属性に設定された応答コードで応答します。Default (デフォルト: Allow)属性がAllowであればACLは拒否リストになる。 反対にDenyならACLは許可リストになる。
アクセス制御リストは/ svc / {仮想ホスト名} /acl.txtに設定します。
許可/拒否¶
すべてのクライアントのHTTP要求に対して許可/拒否有無を設定します。 Denyされたリクエストは Accessログ にTCP_DENYに記録されます。
各条件ごとに個別に応答コードを設定することもできます。
# /svc/www.example.com/acl.txt
# 区切り文字はカンマ（、）であり{条件}、{allowまたはdeny}順に表記します。
# denyの場合キーワードの後に応答コードを指定することができます。
# 指定しなければ ``<AccessControl>`` の ``DenialCode`` を使用します。
# n個の条件を組み合わせて（AND）するためには&を使用します。
$IP[192.168.1.1], allow
$IP[192.168.2.1-255]
$IP[192.168.3.0/24], deny
$IP[192.168.4.0/255.255.255.0]
$IP[AP] & !HEADER[referer], allow
$HEADER[cookie: *ILLEGAL*], deny, 404
$HEADER[via: Apache]
$HEADER[x-custom-header]
!HEADER[referer] & !HEADER[user-agent] & !HEADER[host], deny
$URL[/source/public.zip], allow
$URL[/source/*]
/profile.zip, deny, 500
/secure/*.dat
許可/遮断条件はIP、GeoIP、Header、URLの4つの設定が可能です。
IP
$IP[...]で表記し IP, IP Range, Bitmask, Subnet 4種類をサポートします。
GEOIP
$IP[...]で表記し必ずGeoIP設定が必須です。
HEADER
$HEADER[Key : Value]と表記します。 Valueは明確な表現とパターンを認識します。 $HEADER [Key：]のように区切り文字はありますがValueが空の文字列であればリクエストヘッダの値が空の場合を意味します。 $HEADER [Key]のように区切り文字なしにKeyのみ指定されている場合はKeyに対応するヘッダの存在の有無を条件で判断します。
URL
$URL[...]で表記し省略が可能です。 明確な表現とパターンを認識します。
$は "条件に合うなら〜する"を意味するが！は "条件に合わない場合は〜する"を意味します。 次のように否定条件で支援します。
# 国がJPNではない場合はdenyします。
!IP[JPN], deny
# refererヘッダが存在しない場合denyします。
!HEADER[referer], deny
# /secure/ 経路の以下ではない場合はallowします。
!URL[/secure/*], allow
Redirect¶
すべてのクライアントのHTTP要求に対してRedirect有無を設定します。 Redirectされた要求には 302 Moved temporarily で応答します。
# /svc/www.example.com/acl.txt
# 区切り文字はカンマ（、）であり{条件}、{redirect}順に表記します。
# redirectの場合キーワードの後に移動させるURLを指定します。 (Locationヘッダの値に明示)
$IP[GIN], redirect, /page/illegal_access.html
$HEADER[referer:], redirect, http://another-site.com
!HEADER[referer], redirect, http://example.com#URL
Redirectする場合にクライアントが要求されたURLが必要になることができます。 このような場合 #URL キーワードを使用します。
HTTPSのみをサポートするサービスの場合HTTPリクエストには次のように $PROTOCOL[HTTP] の条件でHTTPSを強制するようにredirectさせることができます。
$PROTOCOL[HTTP], redirect, https://example.com#URL
第16章 Bandwidth¶
この章では仮想ホストごとに多様な方式のBandwidth制限（調節）する方法について説明します。 過去にはBandwidthが一定レベルを超えないように制限することが目的でした。 今は効果的にBandwidthを調節することに変わりました。 さらにコンテンツをリアルタイムで分析しそれぞれに最適化されたBandwidthを使用するように設定することができます。
仮想ホストBandwidth制限¶
仮想ホストの最大Bandwidthを制限します。 これは最優先する物理的な方法です。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<TrafficCap Session="0">0</TrafficCap>
<TrafficCap> (デフォルト: 0 Mbps)の仮想ホストの最大BandwidthをMbps単位で設定します。 0に設定するとBandwidthを制限しません。Session (デフォルト: 0 Kbps)属性はクライアントセッションごとに送信することができる最大のBandwidthを設定します。
例えば <TrafficCap> を50（Mbps）に設定した場合は50Mbps NICをインストールしたのと同じ効果を出す。 仮想ホストにアクセスするすべてのクライアントBandwidthの合計は50Mbpsを超えることができない。
Session は次のように動作する
Sessionが設定されていてもすべてのクライアントBandwidthの合計は<TrafficCap>を超えることができない。- Bandwidth Throttling を設定してもクライアントセッションの最大速度は
Sessionを超えることができない。
Bandwidth Throttling¶
BT（Bandwidth Throttling）は（各セッションごとに）クライアントの転送帯域幅を動的に調整する機能です。 一般的なメディアファイルの内部には次のようにヘッダ、V（Video）、A（Audio）で構成されている。
ヘッダはBTの対象ではない。
ヘッダは再生時間が長いかKey Frame周期が短いほど大きくなる。 したがって認識することができるメディアファイルであれば円滑な再生のためにヘッダーは帯域幅制限なしで送信します。 次の図のようにヘッダが完全に転送された後BTが開始されます。
動作シナリオ
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<BandwidthThrottling>
<Settings>
<Bandwidth Unit="kbps">1000</Bandwidth>
<Ratio>100</Ratio>
<Boost>5</Boost>
</Settings>
<Throttling>OFF</Throttling>
</BandwidthThrottling>
<BandwidthThrottling> タグの下位にデフォルトの動作を設定します
<Settings>デフォルトの動作を設定します。
<Bandwidth> (デフォルト: 1000 Kbps)クライアントの転送帯域幅を設定します。Unitプロパティを介してデフォルト単位(kbps、mbps、bytes、kb、mb)を設定します。<Ratio> (デフォルト: 100 %)<Bandwidth>設定の率を反映して帯域幅を設定します。<Boost> (デフォルト: 5 秒)一定時間だけのデータを速度制限なしのクライアントに送信します。 データの量は<Boost>X<Bandwidth>X<Ratio>公式で計算します。
<Throttling>OFF (デフォルト)BTを適用しません。ON条件リストと一致するとBTを適用します。
Bandwidth Throttling条件リスト¶
BTの条件のリストを設定します。 条件のリストと一致するとBTが適用されます。 設定された順序で条件との一致をチェックします。 トランスポートポリシーは/ svc / {仮想ホスト名} /throttling.txtに設定します。
# /svc/www.example.com/throttling.txt
# 区切り文字はカンマ（、）であり、{条件}、{Bandwidth},{Ratio},{Boost} 順に表記します。
# {条件}を除くすべてのフィールドは省略可能です。
# 省略されたフィールドは ``<Settings>`` に設定されたデフォルト値が使用されます。
# すべての条件式はacl.txt設定と同じです。
# {Bandwidth} 単位は ``<Settings>`` ``<Bandwidth>`` の ``Unit`` 属性を使用します。
# 3秒のデータを速度制限なしで送信した後3Mbps（3000Kbps = 2000Kbps X 150％）でクライアントに送信します。
$IP[192.168.1.1], 2000, 150, 3
# bandwidthのみを定義します。 5（デフォルト）秒のデータを速度制限なしで送信した後800 Kbpsでクライアントに送信します。
!HEADER[referer], 800
# boostのみを定義します。 10秒のデータを速度制限なしで送信した後1000 Kbpsにクライアントに送信します。
HEADER[cookie], , , 10
# 拡張子がm4aの場合BTを適用しません。
$URL[*.m4a], no
メディアファイル（MP4M4AMP3）を分析するとEncoding RateからBandwidthを得ることができます。 アクセスされるコンテンツの拡張子は必ず.mp4.m4a.mp3のいずれかでなければならない。 動的にBandwidthを抽出するには次のようにBandwidth後ろ x を付ける。
# /vod/*.mp4 ファイルへのアクセスであればbandwidthデーターを取得します。取得できない場合は1000をbandwidthに使用します。
$URL[/vod/*.mp4], 1000x, 120, 5
# user-agentヘッダがない場合は bandwidthデーターを取得します。所得できない場合は 500をbandwidthに使用します。
!HEADER[user-agent], 500x
# /low_quality/* ファイルへのアクセスであればbandwidthデーターを取得します。取得できない場合はデフォルト値をbandwidthに使用します。
$URL[/low_quality/*], x, 200
QueryString優先条件¶
規定のQueryStringを使用して <Bandwidth> , <Ratio> , <Boost> を動的に設定します。 この設定はBTの条件よりも優先されます。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<BandwidthThrottling>
<Settings>
<Bandwidth Param="mybandwidth" Unit="mbps">2</Bandwidth>
<Ratio Param="myratio">100</Ratio>
<Boost Param="myboost">3</Boost>
</Settings>
<Throttling QueryString="ON">ON</Throttling>
</BandwidthThrottling>
<Bandwidth>,<Ratio>,<Boost>のParamそれぞれの意味に合わせてQueryStringキーを設定します。
<Throttling>のQueryStringOFF (デフォルト)QueryStringに条件を再定義しない。ONQueryStringに条件を再定義する。
上記のように設定されている場合は次のようにクライアントが要求されたURLに基づいてBTが動的に設定されます。
# 10秒のデータを速度制限なしで送信した後1.3Mbps（1mbps X 130％）でクライアントに送信します。
http://www.winesoft.co.kr/video/sample.wmv?myboost=10&mybandwidth=1&myratio=130
必ずすべてのパラメータを指定する必要はありません。
http://www.winesoft.co.kr/video/sample.wmv?myratio=150
上記のように一部の条件が省略された場合は残りの条件（ここではbandwidthboost）を決定するために条件のリストをチェックします。 ここでも適切な条件が見つからない場合 <Settings> に設定されたデフォルト値が使用されます。 QueryStringが一部存在しても条件リストで無視オプション（no）が設定されている場合はBTの適用されない。
QueryStringを使用するのでややもすると QueryString区分 と混沌する可能性があります。
QueryString区分 が ON の場合クライアントが要求されたURLのQueryStringがすべて認識されますが BoostParam , BandwidthParam , RatioParam は除外されます。
GET /video.mp4?mybandwidth=2000&myratio=130&myboost=10
GET /video.mp4?tag=3277&myboost=10&date=20130726
例えば上記のような入力はBTを決定するためだけに使用されます。Caching-Keyを生成したりオリジンサーバーに要求を送信する場合は削除されます。 つまりそれぞれ次のように認識されます。
GET /video.mp4
GET /video.mp4?tag=3277&date=20130726
第17章 画像/ DIMS¶
この章ではイメージを転送時点でon-the-flyに変換/転送するDIMS（ディムス）について取り上げる。 DIMS（Dynamic Image Management System）は元のイメージを様々な形に加工する機能です。
多様な動的イメージ処理
イメージは動的に生成され元のイメージのURLの後ろに規定のキーワードと加工オプションを付けて呼び出します。 加工されたイメージはキャッシュされてオリジンサーバーのイメージが変わらない限り再処理されません。
元のファイルが/img.jpgの場合、次のような形式でイメージを加工することができます。 ("12AB"は規定のKeywordです。)
http://image.example.com/img.jpg // origin content
http://image.example.com/img.jpg/12AB/optimize
http://image.example.com/img.jpg/12AB/resize/500x500/
http://image.example.com/img.jpg/12AB/crop/400x400/
http://image.example.com/img.jpg/12AB/composite/watermark1/
<Dims> は別に設定しなければすべて無効にされている。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<Dims Status="Active" Keyword="dims" MaxSourceSize="10" OnFailure="message" />
<Dims>StatusDIMS有効 (ActiveまたはInactive)KeywordオリジンサーバーとDIMSを区別するキーワードMaxSourceSize (デフォルト: 10MB)変換可能な最大イメージサイズ（単位：MB）OnFailureイメージ変換失敗時の動作方式message (デフォルト)500 Internal Errorで応答します。 本文には具体的な失敗の理由を明示します。The original file was not successfully downloaded.元のイメージを完全にダウンロードできなかった。The original file size is too large.元イメージのサイズがMaxSourceSizeを超えて変換していなかった。The original file loading failed.元のイメージデータを読み込まなかった。Image converting failed or invalid DIMS command.正しくない命令またはサポートされていないイメージなどが原因で変換していなかった。
redirect元のイメージのアドレスに302 Redirectします。
最適化¶
品質を低下せずにイメージを圧縮します。 JPEG、JPEG-2000、Loseless-JPEGイメージのみをサポートが可能です。 既に他のツールを使用して最適化されたイメージは最適化されない。
http://image.example.com/img.jpg/dims/optimize
最適化はキーワード以外の別のオプションはありません。 他の変換条件と組み合わせたときに一番後ろ明示する方法が望ましいです。
http://image.example.com/img.jpg/dims/resize/100x100/optimize
すべてのDIMSの機能はシステムリソースを大量に使用しますが、その中でも最適化が最も重い作業です。 以下はHitRatioが0％の状態でイメージサイズ別パフォーマンステストの結果です。
OSCentOS 6.2 (Linux version 2.6.32-220.el6.x86_64 (mockbuild@c6b18n3.bsys.dev.centos.org) (gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) ) #1 SMP Tue Dec 6 19:48:22 GMT 2011)CPUIntel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz (8 processors)RAM16GBHDDSMC2108 SAS 275GB X 3EA
| サイズ | スループット | 応答速度(ms) | クライアントのトラフィック(Mbps) | 元トラフィック(Mbps) | トラフィックの削減率(%) |
|---|---|---|---|---|---|
| 16KB | 720 | 19.32 | 46.32 | 92.62 | 49.99 |
| 32KB | 680 | 20.68 | 86.42 | 165.08 | 47.65 |
| 64KB | 285 | 50.16 | 80.67 | 150.96 | 46.56 |
| 128KB | 274 | 57.80 | 164.35 | 276.52 | 40.56 |
| 256KB | 210 | 80.74 | 99.42 | 432.35 | 77.00 |
| 512KB | 113 | 156.18 | 160.54 | 436.04 | 63.18 |
| 1MB | 20 | 981.07 | 90.62 | 179.88 | 49.62 |
約50％内外のトラフィックを削減がでいるのでで非常に有効です。最適化は非常に重い作業です。 参照表でわかるようにイメージサイズの影響が大きいです。
そのためサービスに適用するためには十分な検討が必須になります。 適切な Request hit ratio がある状況が望ましいがそうでない場合はサービスの規模に合わせて物理的なCPUリソースを十分に確保する必要があります。
注釈
メタ情報のみを削除したい場合は以下のコマンドを使用します。
http://image.example.com/img.jpg/dims/strip/true
カット (Cropping)¶
左上を基準でイメージを切り取ります。 範囲は width x height{+-}x{+-}y{%} で表現します。 次は左上端x = 20、y = 30を基準にwidth = 100、height = 200だけ切り取る例だ。
http://image.example.com/img.jpg/dims/crop/100x200+20+30/
イメージの中央を基準にしたい場合cropcenterコマンドを使用します。
http://image.example.com/img.jpg/dims/cropcenter/100x200+20+30/
Thumbnail生成¶
Thumbnailを生成します。 サイズとオプションは width x height{%} {@} {!} {<} {>} で表現します。 デフォルトはイメージの横と縦の最大値を使用します。 イメージを拡大または縮小してもアスペクト比は維持されます。 サイズを指定する場合は（！）を追加します。 640X480! という表現は正確に640x480サイズのThumbnailを生成します。 もし水平方向または垂直方向のサイズのみ指定した場合省略された値は水平/垂直比によって自動的に決定されます。
例えば /thumbnail/100/ は横幅に合わせて縦サイズが決定され /thumbnail/x200/ は縦サイズに合わせて横幅が決定されます。 水平/垂直サイズをイメージのサイズに合わせて割合（％）で表現することができます。 イメージのサイズを増やすには100よりも大きい値（例えば125％）を使用します。 イメージのサイズを小さくするには100未満の割合を使用します。 URL Encodingルールに基づいて％の文字が％25にエンコードされることを覚えておかなければならない。
例えば50％という表現は50％25でエンコードされます。 以下はwidth = 78、height = 110サイズのThumbnailを生成する例である。
http://image.example.com/img.jpg/dims/thumbnail/78x110/
Resizing¶
イメージのサイズを変更します。 サイズは width x height で表現します。 イメージは変更されても比率は維持されます。 以下は元のイメージをwidth = 200、height = 200サイズに変更する例です。
http://image.example.com/img.jpg/dims/resize/200x200/
その他のコマンドは、次のとおりである。
- resizec - 縮小するとresizeと同じですが拡大するとイメージは維持されてキャンバスサイズだけ拡大されます。
- extent - キャンバスのみ調節するコマンドです。 縮小するとcropと同じ効果を出すが、拡大するとresizecと同じように拡大される。
- trim - 上下左右の白い背景を削除します。
Format変更¶
イメージフォーマットを変更します。 サポートされるフォーマットは "png"、 "jpg"、 "gif" です。 以下はJPGをPNGへ変換する例です。
http://image.example.com/img.jpg/dims/format/png/
品質変更¶
画質を調節します。 この機能で送信されるイメージの容量が削減できます。 有効範囲は0から100までだ。 次はイメージの品質を25％に調節する例です。
http://image.example.com/img.jpg/dims/quality/25/
エフェクト¶
イメージに多様なエフェクトを与えることができます。
合成¶
二つのイメージを合成します。 前述の機能とは別の方法で合成条件はあらかじめ設定されてなければならない。 主にウォーターマーク効果を出すために使用されます。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<Dims Status="Active" Keyword="dims" port="8500">
<Composite Name="water1" File="/img/small.jpg" />
<Composite Name="water2" File="/img/medium.jpg" Gravity="se" Geometry="+0+0" Dissolve="50" />
<Composite Name="water_ratio" File="/img/wmark_s.png" Gravity="s" Geometry="+0+15%" Dissolve="100" />
</Dims>
<Composite>イメージ合成条件を設定します。 属性によって決まり別の値を持たない。
Name呼び出される名前を指定します。 '/'文字は入力できない。 URLの "/composite/" の後に位置します。File合成するイメージファイルのパスを指定します。Gravity (デフォルト: c)合成する位置は左上から9つのポイント(nw, n, ne, w, c, e, sw, s, se)が存在します。
Gravity基準点
Geometry (デフォルト: +0+0)Gravity基準で合成するイメージの位置を設定します。 {+ - } x {+ - } y。 赤丸はGravity属性に基づいて+ 0 + 0が意味する基準点に+ x + yの値が大きくなるほどイメージの中に配置されます。 緑の矢印は+ x紫の矢印は+ yが増加する方向です。 -x-yを使用すると対象イメージの外側に位置するようにされ結果のイメージは見られない。 この属性は多少複雑に見えますがイメージのサイズを自動的に計算して配置するので一貫性のある結果を得ることができて有効です。 また+ x％+ y％のように％オプションを与え割合で配置することもできる。Dissolve (デフォルト: 50)合成するイメージの透明度(0~100).
<Composite> を設定した場合 Name プロパティを使用してイメージを合成することができます。
http://image.example.com/img.jpg/dims/composite/water1/
オリジンのイメージの条件判断¶
元のイメージの条件に応じて動的に加工オプションを別の方法で適用することができます。 たとえば1024 X 768以下のイメージは品質を50％に落としそれ以上のイメージは1024 X 768にサイズ変換をするには次のように <ByOriginal> を設定します。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<Dims Status="Active" Keyword="dims" port="8500">
<ByOriginal Name="size1">
<Condition Width="1024" Height="768">/quality/50/</Condition>
<Condition>/resize/1024x768/</Condition>
</ByOriginal>
</Dims>
<ByOriginal>Name属性で呼び出します。 サブ多様な条件の<Condition>を設定します。<Condition>条件に満足している場合設定された変換を実行します。Width幅が設定値よりも小さい場合に適用されます。Height縦の長さが設定値よりも小さい場合に適用されます。
条件を設定しないと元のイメージのサイズに関係なく変換されます。
<Condition> は指定された順序で適用されます。 したがって小さなイメージの条件を最初に配置する必要があります。 次のように呼び出したら原本イメージの大きさに準じて合成が適用されます。
http://image.example.com/img.jpg/dims/byoriginal/size1/
別の例としてイメージサイズに応じて他の <Composite> 条件を与えることができます。 このような場合は次のように事前に定義された <Composite> の Name に設定します。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<Dims Status="Active" Keyword="dims" port="8500">
<Composite Name="water1" File="/img/small.jpg" />
<Composite Name="water2" File="/img/medium.jpg" Gravity="se" Geometry="+0+0" Dissolve="50" />
<Composite Name="water3" File="/img/big.jpg" Gravity="se" Geometry="+10+10" Dissolve="50" />
<ByOriginal Name="size_water">
<Condition Width="400">/composite/water1/</Condition>
<Condition Width="800">/composite/water2/</Condition>
<Condition>/composite/water3/</Condition>
</ByOriginal>
</Dims>
次のように呼び出すと元のイメージのサイズに応じて合成が適用されます。
http://image.example.com/img.jpg/dims/byoriginal/size_water/
Animated GIF¶
Animated GIFにもすべてのDIMS変換が同様に適用されます。 処理順序は次のとおりです。
- Animated GIFを別途のイメージに分解します。
- それぞれのイメージを変換します。
- 変換されたイメージをAnimated GIFに結合します。
結合されたイメージが多いほど処理コストが高くサービスの品質が低下することができます。 このような場合最初のイメージにのみ変換するように設定すると処理コストを下げることができます。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<Dims FirstFrameOnly="OFF" />
FirstFrameOnly (デフォルト: OFF)ONの場合Animated GIFの最初のシーンだけを変換します。
次のようにURLを呼び出すときに FirstFrameOnly オプションを明示的に指定することができます。
http://image.example.com/img.jpg/dims/firstframeonly/on/resize/200x200/
http://image.example.com/img.jpg/dims/firstframeonly/off/resize/200x200/
上記のようにURLに明示的に指定されている場合設定よりも優先されます。
注釈
limit コマンドを使用してAnimated GIFのフレーム数を調節することができます。
http://image.example.com/img.jpg/dims/limit/3
http://image.example.com/img.jpg/dims/limit/3/resize/200x200
その他¶
以上のデフォルト的な機能を組み合わせて複合的なイメージ処理を行うことができます。 たとえばThumbnail生成（78x110）はフォーマットをJPGからPNGに変換すると品質の50％以上のオプションを一度の呼び出しで実行することができます。
http://image.example.com/img.jpg/dims/thumbnail/78x110/format/png/quality/50/
DIMSはURLを利用してイメージ加工が行われる。 したがってURLに影響を与える他のオプションのために望ましくない結果が得られないように注意する必要があります。
QueryString区分 が
OFFであればキーワード前のQueryStringが無視されます。http://image.example.com/img.jpg?session=5234&type=37/dims/resize/200x200/
上記のような呼び出しにこの設定が
ONであれば入力されたURLのまま認識されOFFであれば次のように認識されます。http://image.example.com/img.jpg/dims/resize/200x200/
大文字と小文字の区別 が
OFFであればすべてのURLを小文字に変換して処理します。 したがってDIMSキーワードに大文字が含まれている場合キーワードを認識しません。 常にキーワードは小文字で使用するのがよい。
第18章 動画¶
この章ではビデオ/オーディオをスマートにサービスする方法について説明します。 クライアント側はシームレスなスムーズな再生が一貫性のある目的になりますが、サーバ側では非常に複雑です。 画像の画質向上はより大きな帯域幅とストレージ容量を必要とします。 STONは様々なOn-the-fly手法を用いて既存Back-Endの修正なし柔軟な転送機能を提供します。
MP4 HLS¶
MP4ファイルをHLS（HTTP Live Streaming）にサービスします。 オリジンサーバーはHLSサービスのためにファイルを分割保存する必要がない。 MP4ファイルのヘッダの位置に関係なくダウンロードと同時にリアルタイムで.m3u8/.tsファイルの変換後にサービスします。
注釈
MP4HLSはElementary Stream（VideoまたはAudio）を変換するトランスコーディング（Transcoding）ではない。 したがってHLSに適した形式でエンコードされたMP4ファイルに限って円滑な再生が可能です。 エンコーディングが適合しない場合は画面が割れたり音が再生されないことがあります。 現在（2014.2.20）Appleの言っているVideo / Audioエンコード規格は次のとおりです。
What are the specifics of the video and audio formats supported? Although the protocol specification does not limit the video and audio formats, the current Apple implementation supports the following formats:
[Video] H.264 Baseline Level 3.0, Baseline Level 3.1, Main Level 3.1, and High Profile Level 4.1.
[Audio] HE-AAC or AAC-LC up to 48 kHz, stereo audio MP3 (MPEG-1 Audio Layer 3) 8 kHz to 48 kHz, stereo audio AC-3 (for Apple TV, in pass-through mode only)
Note: iPad, iPhone 3G, and iPod touch (2nd generation and later) support H.264 Baseline 3.1. If your app runs on older versions of iPhone or iPod touch, however, you should use H.264 Baseline 3.0 for compatibility. If your content is intended solely for iPad, Apple TV, iPhone 4 and later, and Mac OS X computers, you should use Main Level 3.1.
従来の方式の場合Pseudo-StreamingとHLSのために以下のように元のファイルがそれぞれ存在する必要があります。 このような場合STONも元のファイルをそのまま複製してクライアント側にサービスします。 しかし再生時間が長いほど派生ファイルは多くなり管理の難しさは増加します。
手間が多くHLS
<MP4HLS> は元のファイルからHLSサービスに必要なファイルを動的に生成します。
スマートHLS
すべての.m3u8/.tsファイルは元のファイルから派生し別のストレージスペースを消費しません。 サービスすぐにメモリに一時的に生成されサービスされない場合自動的に消える。
# server.xml - <Server><VHostDefault><Media>
# vhosts.xml - <Vhosts><Vhost><Media>
<MP4HLS Status="Inactive" Keyword="mp4hls">
<Index Ver="3" Alternates="off">index.m3u8</Index>
<Sequence>0</Sequence>
<Duration>10</Duration>
<AlternatesName>playlist.m3u8</AlternatesName>
</MP4HLS>
<MP4HLS>Status (デフォルト: Inactive)の値がActiveの場合にのみ有効になる。Keyword (デフォルト: mp4hls)HLSサービスキーワード
<Index> (デフォルト: index.m3u8)HLSインデックス（.m3u8）ファイル名Ver (デフォルト 3)インデックスファイルのバージョン。 3である場合#EXT-X-VERSION:3ヘッダが指定されて#EXTINFの時刻の値が小数点3桁目まで表示されます。 1の場合#EXT-X-VERSIONヘッダがなく#EXTINFの時間値が整数（丸め）に表示されます。Alternates (デフォルト: OFF)Stream Alternates使用有無。
OFF.
<Index>でTSリストをサービスします。
ON.
<AlternatesName>でTSリストをサービスします。
<Sequence> (デフォルト: 0).tsファイルの開始番号。 このことに基づいて順次増加する。<Duration> (デフォルト: 10秒)のMP4 HLSに分割する基準時間（秒）。 分割の基準はVideo / AudioのKeyFrameです。 KeyFrameはギザギザすることができますので正確に分割されない。 もし10秒分割しようとしてKeyFrameが9秒と12秒の場合は近い値（9秒）を選択します。<AlternatesName> (デフォルト: playlist.m3u8)Stream Alternatesファイル名。http://www.example.com/video.mp4/mp4hls/playlist.m3u8
サービスアドレスは次のとおりである場合はそのアドレスにPseudo-Streamingを行うことができます。
http://www.example.com/video.mp4
仮想ホストは <MP4HLS> に定義された Keyword 文字列を認識することによりHLSサービスを進行します。 次のURLが呼び出されると/video.mp4からindex.m3u8ファイルを生成します。
http://www.example.com/video.mp4/mp4hls/index.m3u8
Alternates 属性がONであれば <Index> ファイルは <AlternatesName> ファイルをサービスします。
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=200000,RESOLUTION=720x480
/video.mp4/mp4hls/playlist.m3u8
#EXT-X-STREAM-INF のBandwidthとResolutionは映像を分析して動的に提供します。
注釈
Stream Alternatesを提供しますが現在のバージョンではindex.m3u8は常に一つのサブインデックスファイル（playlist.m3u8）だけを提供します。 キャッシュの立場ではvideo_1080.mp4とvideo_720.mp4が（エンコードオプションが他の）のような映像なのか知ることができないからです。
最終的に生成された.tsリスト（バージョン3）は次のとおりです。
#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:11.637,
/video.mp4/mp4hls/0.ts
#EXTINF:10.092,
/video.mp4/mp4hls/1.ts
#EXTINF:10.112,
/video.mp4/mp4hls/2.ts
... (中略)...
#EXTINF:10.847,
/video.mp4/mp4hls/161.ts
#EXTINF:9.078,
/video.mp4/mp4hls/162.ts
#EXT-X-ENDLIST
分割には3つのポリシーがあります。
- KeyFrame間隔よりも
<Duration>の設定が大きい場合 KeyFrameが3秒<Duration>が20秒であれば20秒を超えないKeyFrameの倍数である18秒に分割されます。 - KeyFrame間隔と
<Duration>が似ている場合 KeyFrameが9秒<Duration>が10秒であれば10秒を超えないKeyFrameの倍数である9秒分けられる。 - KeyFrame間隔が
<Duration>に設定よりも大きい場合 KeyFrame単位に分割されます。
次のクライアント要求に対してSTONがどのように動作するのかを理解しましょう。
GET /video.mp4/mp4hls/99.ts HTTP/1.1
Range: bytes=0-512000
Host: www.winesoft.co.kr
STON最初のロード（何もキャッシュされません。）ClientHTTP Range要求（100番目のファイルの最初の500KBリクエスト）STON/video.mp4ファイルのキャッシュオブジェクトの作成STON/video.mp4ファイルの分析のために必要な部分だけをオリジンサーバーからダウンロードSTON100番目（99.ts）ファイルサービスのために必要な部分だけをオリジンサーバーからダウンロードSTON100番目（99.ts）ファイルを作成した後RangeサービスSTONサービスが完了すると99.tsファイルpurge
注釈
MP4Trimming 機能が ON の場合TrimmingされたMP4をHLSに変換できる。 （HLSイメージをTrimmingすることができない。HLSのMP4ではなくMPEG2TSであることに注意しよう。）映像をTrimmingした後HLSに変換するため次のように表現するのが自然です。
/video.mp4?start=0&end=60/mp4hls/index.m3u8
動作には問題ありませんがQueryStringを一番後ろに付けるHTTP仕様に反します。 これを補完するために次のような表現も動作は同じです。
/video.mp4/mp4hls/index.m3u8?start=0&end=60
/video.mp4?start=0/mp4hls/index.m3u8?end=60
MP3 HLS¶
MP3ファイルをHLS（HTTP Live Streaming）にサービスします。
# server.xml - <Server><VHostDefault><Media>
# vhosts.xml - <Vhosts><Vhost><Media>
<MP3HLS Status="Inactive" Keyword="mp3hls" SegmentType="TS">
<Index Ver="3" Alternates="off">index.m3u8</Index>
<Sequence>0</Sequence>
<Duration>10</Duration>
<AlternatesName>playlist.m3u8</AlternatesName>
</MP3HLS>
すべての設定と動作が MP4 HLS と同じでさらにSegement形式を選択することができます。
<MP3HLS>SegmentType (デフォルト: TS)オリジンサーバーのMP3 MPEG2-TS(TS) またはMP3に分割します。
MP4/M4Aヘッダの位置を変更¶
通常MP4形式の場合エンコード処理中にヘッダを完成することができないため完了後にファイルの末尾に付ける。 ヘッダを前の部分に移動するには別の処理が必要です。 ヘッダが後ろにいる場合これをサポートしていないプレーヤーでPseudo-Streamingが不可能です。 ヘッダの位置の変更によりPseudo-Streamingを簡単にサポートすることができます。
ヘッダの位置の変更は送信段階でのみ発生するだけでテキストの形を変更しません。 別のストレージスペースを使用することもない。
# server.xml - <Server><VHostDefault><Media>
# vhosts.xml - <Vhosts><Vhost><Media>
<UpfrontMP4Header>OFF</UpfrontMP4Header>
<UpfrontM4AHeader>OFF</UpfrontM4AHeader>
<UpfrontMP4Header>OFF (デフォルト)何もしません。ON拡張子が.mp4でヘッダが続いている場合ヘッダーを今後移し送信します。
<UpfrontM4AHeader>OFF (デフォルト)何もしません。ON拡張子が.m4aでヘッダが続いている場合ヘッダーを今後移し送信します。
最初に要求されているコンテンツのヘッダを前に移動する必要が場合ヘッダを移すために必要な部分を優先的にダウンロードされます。 非常にスマートなだけでなく高速に動作します。 カーテンの後ろの複雑なプロセスとは関係なくクライアントはもともとヘッダが前にある完全なファイルをサービス受ける。
注釈
分析することができない場合または壊れたファイルであれば元の形のままサービスされます。
Trimming¶
時間値に基づいて必要な区間を抽出します。 Trimmingは送信段階でのみ発生するだけで元のファイルの形を変更しません。 別のストレージスペースを使用しません。
# server.xml - <Server><VHostDefault><Media>
# vhosts.xml - <Vhosts><Vhost><Media>
<MP4Trimming StartParam="start" EndParam="end" AllTracks="off">OFF</MP4Trimming>
<M4ATrimming StartParam="start" EndParam="end" AllTracks="off">OFF</M4ATrimming>
<MP3Trimming StartParam="start" EndParam="end">OFF</MP3Trimming>
<MP4Trimming><MP3Trimming><M4ATrimming>OFF (デフォルト)何もしません。ON拡張子(.mp4、 .mp3、 .m4a)が一致すると必要な区間だけサービスするようにTrimmingします。 Trimming区間はStartParam属性とEndParamに設定します。AllTracks属性OFF (デフォルト)Audio / VideoトラックのみTrimmingします。 （Mod-H264方式）ONすべてのトラックのTrimmingします。 使用前に必ずプレーヤーの互換性を確認する必要があります。
パラメータはクライアントQueryStringを介して入力されます。 たとえば10分の動画（/video.mp4）を特定区間だけTrimmingしたい場合はQueryStringに任意の時点（単位：秒）を指定します。
http://vod.wineosoft.co.kr/video.mp4 // 10分：全ムービー
http://vod.wineosoft.co.kr/video.mp4?end=60 // 1分：最初から60秒まで
http://vod.wineosoft.co.kr/video.mp4?start=120 // 8分：2分（120秒）から最後まで
http://vod.wineosoft.co.kr/video.mp4?start=3&end=13 // 10秒：3秒から13秒まで
StartParam 値が EndParam 値よりも大きい場合区間が指定されていないものと判断します。 この機能はHTTP Pseudo-Streamingに実装されたビデオプレーヤーのSkip機能のために開発された。 したがってRange要求を処理するようにファイルをOffsetに基づいて切らずに正常に再生されるようにキーフレームと時間を認知して区間を抽出します。
クライアントに配信されるファイルは次の図のようにMP4ヘッダが再生成された完全な形のMP4ファイルです。
完全な形のファイルが提供されます。
抽出された区間は別のファイルとして認識されるため200 OKで応答されます。 したがって次のようにRangeヘッダが記載されている場合抽出されたファイルからRangeを計算して 206 Particial Content で応答します。
一般的なRangeリクエストのように処理されます。
区間抽出パラメータがQueryString表現を使用するためややもすると QueryString区分 と混乱することができます。
<ApplyQueryString> の設定が ON の場合クライアントが要求されたURLのQueryStringがすべて認識され StartParam と EndParam は除去されます。
GET /video.mp4?start=30&end=100
GET /video.mp4?tag=3277&start=30&end=100&date=20130726
例えば上記のように StartParam が start で EndParam が end で入力された場合この値は区間を抽出するのに使われるだけでCaching-Keyを生成したりオリジンサーバーに要求を送信する場合は削除されます。 それぞれ次のように認識されます。
GET /video.mp4
GET /video.mp4?tag=3277&date=20130726
またQueryStringパラメータは拡張モジュールやCDNソリューションによって異なることができます。
JW Playerで提供しているModule / CDN星参考資料
以外のnginxの ngx_http_mp4_module とlighttpdの Mod-H264-Streaming-Testing-Version2 もすべて start をQueryStringに使用します。
Multi-Trimming¶
時間値に基づいて複数の指定された区間を一つの映像として抽出します。
/video.mp4?trimming=0-30,210-270,525-555
区間の指定方法が違うだけで動作は Trimming と同じです。
# server.xml - <Server><VHostDefault><Media>
# vhosts.xml - <Vhosts><Vhost><Media>
<MP4Trimming MultiParam="trimming" MaxRatio="50">OFF</MP4Trimming>
<M4ATrimming MultiParam="trimming">OFF</M4ATrimming>
<MP4Trimming><M4ATrimming>MultiParam (デフォルト: "trimming")に設定され名前をQueryString Keyとして使用して抽出区間を指定します。 一つの区間は "開始時刻 - 終了時刻" と表記し各区間はコンマ（、）で接続します。MaxRatio (デフォルト: 50%)Multi-Trimmingされた映像はオリジナルよりもMaxRatio (最大 100%)の割合だけまで大きくなることができます。MaxRatioを移る区間は無視されます。
例えば次のように起動すると3分の映像が生成されます。
http://example.com/video.mp4?trimming=10-70,560-620,1245-1305
同じ映像を繰り返したり前の背部変わった映像を作成することもできる。
http://example.com/video.mp4?trimming=17-20,17-20,17-20,17-20
http://example.com/video.mp4?trimming=1000-1200,500-623,1900-2000
http://example.com/video.mp4?trimming=600-,400-600
区間値を指定しない場合先頭または最後に意味します。
注釈
Multi-Trimming は Trimming より優先します。 QueryStringに Multi-Trimming キーが指定されている場合は Trimming キーは無視されます。
第19章 File System¶
この章ではSTONをローカルディスクのように使用する方法について説明します。 STONは FUSE をベースにLinux VFS（Virtual File System）でMountされる。 Mountされたパスのすべてのファイルは、アクセスされた瞬間Cachingますが、他のプロセスは、この事実を知らない。 Caching機能が搭載されたReadOnlyディスク に理解してよい。
構造File I / O関数の呼び出しをLinux KernelがSTONに直接伝達する過程でどのような要素（物理ファイルI / OまたはSocket通信など）も介入しません。 このような構造は非常に高い性能を実現します。 STONのメモリCachingを介して物理ディスクのアクセスよりも早い速度を期待することができます。
Mountする¶
グローバル設定（server.xml）に設定します。
# server.xml - <Server><Cache>
<FileSystem Mount="/cachefs" DotDir="OFF" Separator="^">OFF</FileSystem>
<FileSystem>OFF ((デフォルト)何もしません。ONSTONをMount属性のパスでMountします。
既存のHTTPの構造そのままでCacheモジュールにアクセスする方法（File System）が追加された構造で開発された。 したがって、どちらからのアクセスでもCachingは、最初一度だけ行われ、HTTPまたはFile I / Oにサービスされる。 FileSystemはCacheモジュールにアクセスするもう一つの新しい道になりました。
HTTPとFile I / OがCacheモジュールを共有します。
ソースサーバーのコンテンツをHTTPだけでなく、File I / Oの両方からアクセスすることができる。 これを活用すれば、ローカルファイルに基づいたソリューションの可用性をさらに高めることができる。
どのサーバーでもOK
現在STON File Systemがサポートしている関数の一覧は以下の通りです。
| FUSE | C | LINUX |
|---|---|---|
| open | fopen | open |
| release | fclose | close |
| read | fseek, fread | seek, read |
| getattr | fstat | stat |
| unlink | remove | unlink |
File I / Oは内部的にいくつかの段階を経る。 各ステップの理解が土台にならなければ最高のパフォーマンスを得ることができる。
仮想ホストを探す¶
最初のコースは、アクセスしようとする仮想ホストを見つけることです。 HTTPリクエストには、次のようにHostヘッダが指定されて、仮想ホストを簡単に見つけることができる。
GET /ston.jpg HTTP/1.1
host: example.com
File Systemは、最初のパスで、この問題を解決します。 例えば、STONが/ cachefsというパスでMountされている場合は、ローカルファイルにアクセスするには、次のパスを使用する必要がある。
/cachefs/example.com/ston.jpg
検索 も同じように動作します。 example.comの <Alias> に *.example.comが指定されている場合は、以下のアプローチは、すべて同じファイルを指す。
/cachefs/example.com/ston.jpg
/cachefs/img.example.com/ston.jpg
/cachefs/example.example.com/ston.jpg
たとえばApacheでexample.comを連動するためにはDocumentRootを/cachefs/example.com/に設定する必要がある。
ファイル/ディレクトリ¶
仮想ホストごとにFile Systemを設定します。 またはデフォルトの仮想ホストを使用して、すべての仮想ホストに一括設定することができる。
# server.xml - <Server><VHostDefault><Options>
# vhosts.xml - <Vhosts><Vhost><Options>
<FileSystem Status="Active" DotDir="OFF">
<FileTime>origin</FileTime>
<FileStatus>200</FileStatus>
<DirStatus>301, 302, 400, 401, 403</DirStatus>
<Unlink>Purge</Unlink>
</FileSystem>
<FileTime> (デフォルト: Origin)ファイルの時間を提供する際にOriginである場合、元ので答えたLast-Modified時刻、Localの場合、ローカルにキャッシュされた時間を整備します。 (Originの場合) オリジンサーバーで、Last-Modified時間を与えていない場合は、次のようにUnixの初期時間に提供される。
<FileSystem>Status属性がInactiveであれば、File Systemからアクセスすることができない。 Activeに設定する必要がある。<FileStatus> (デフォルト: 200)ファイルとして認識することが、オリジンサーバーHTTP応答コードを設定します。 一般的には200万を設定しますが、特別な制約はない。<DirStatus> (デフォルト: 301、 302、 400、 401、 403)ディレクトリとして認識することが、オリジンサーバーHTTP応答コードを設定します。 デフォルトで302、400、401、403などが設定される。
<Unlink> (デフォルト: Purge)ファイル削除要求が入ってきた場合、動作Purge、Expire、HardPurgeを設定します。
オリジンサーバーにHTTP応答コードが多様に解釈されることができる。 したがって、それぞれのHTTP応答コードの解釈方法を設定する必要がある。
ほとんどの場合、オリジンサーバーに存在するファイルの場合、 200 OK で応答します。 ディレクトリアクセスの場合 403 Forbidden 応答や 302 Found に別のページにRedirectさせたりします。 応答コード名をcomma（、）で区切って設定すると、HTTP応答コードのBodyをファイルまたはディレクトリとして認識します。 設定されていない応答コードには存在しないものと判断、File I / Oが失敗します。
ファイルのプロパティ¶
ほとんどFile I / Oの最初のステップは、ファイルの属性を取得するものです。 ファイルをopenする前に、ファイルの情報を得ることは当然の順だ。 Kernelこのファイルの属性をサービスする過程をSTONの観点から見ると、以下の通りです。 （/ cachefsはMountパスなので、Kernelが省略します。）
ファイルの属性を取得するプロセス
Linuxの場合、ファイルやディレクトリを別に区別しません。 したがって、特定のファイルの属性を取得するプロセスが思ったより複雑です。 上の図からもわかるように、ディレクトリが深ければ深いほど、中間過程の（=必要ない）仮想ホストを検索およびファイルアクセスが発生し、性能が低下します。 特に/ oneまたは/ one / twoよう、Webサービスであればアクセスされてもいないパスの要求が発生してオリジンサーバーの負荷を発生させる。 もちろんCachingされるとTTL（Time To Live）時間のアクセスは発生しません美しくないことだけは明らかだ。
このような構造の負荷をヒューリスティック（Heuristic）に解決するために DotDir 属性を追加した。
DotDir はdot（。）が要求されたパスに存在しない場合ディレクトリ（Dir）として認識される機能です。 前述の図は DotDir が OFF の状態です。
DotDir が ON である場合は次のように動作します。
全域 DotDir 有効( ON )
Kernelから呼び出される過程や回数は変わらない。 しかし要求されたパスにdot（。）がない場合は仮想ホストまで行かずにすぐにディレクトリに応答するため、必要な部分のみの仮想ホストとファイルが参照される。 この機能は、ほとんどのプログラマは、ファイルのみの拡張子を付与して、ディレクトリには、そうではないことに着目した機能です。 したがって、使用する前に、ディレクトリ構造については必ず確認が必要です。
<FileSystem> の DotDir 属性は、グローバルです。 簡単に言うと、すべての仮想ホストがディレクトリにdot（。）を使用しない場合、グローバル DotDir を ON に設定することは非常に有効です。 もちろん全域 DotDir を OFF に設定して、仮想ホストごとに個別に設定することもできる。 この場合、次の図のように、少しのパフォーマンス負荷が発生します。
仮想ホスト DotDir 有効( ON )
仮想ホストの検出は発生するが、ファイルの参照は、dot（。）がある状態でのみ発生します。 非常に頻繁に呼び出されるように、パフォーマンスと関連して、必ず理解するのをお勧めします。
ファイルの読み取り¶
ファイルの属性を取得するプロセスは複雑ですが、肝心のファイルの読み取りは簡単です。 まず、ファイルをOpenします。 すべてのファイルは、当然ReadOnlyある。 Write権限のファイルへのアクセスは失敗します。 最初のファイルがアクセスされる場合、HTTPと同様に、オリジンサーバーからファイルをCachingします。 ファイルを要求されたプロセスが待機しないようダウンロードを進めながら、同時にFile I / Oサービスが行われます。
ファイルOpen
以降の動作は、HTTPサービスと同じです。 ただしHTTPの場合、最初決定されたRangeで順次（Sequential）のファイルへのアクセスが発生するため、ファイル転送に有利な面がある。 一方、File I / Oの場合は、ファイルサイズに関係なく、非常に小さな1KB単位のreadアクセスが非常に多く発生することができる。 性能の最大化のためにSTONはCacheモジュールに Readahead を実装して、これにより、File I / Oパフォーマンスを最大化させた。
ファイルを閉じる（fcloseなど）関数が呼び出されるか、プロセスが終了した場合、ファイルhandleはKernelによって返却される。 これはHTTPトランザクションが終了するのと同じだ。
ファイルの削除¶
Cachingされたファイルは、STONによって管理されますが、プロセスが削除要求を送信することができる。 STONは、様々な Purge 方法を提供していますので、このような要求に容易に対応することができる。
例えば <Unlink> が expire に設定されている場合は、ファイルの削除要求に対して、そのファイルをexpireするように動作します。 Kernelで再びそのファイルにアクセスする場合expireされた状態なので、オリジンサーバーから変更有無を確認した後に変更されていない場合、そのファイルを再度整備します。
ファイルの拡張¶
HTTPの場合は、次のようにURLを利用して、元のファイルを動的に処理することができる。
# HTTP経由/video.mp4の0〜60秒の区間をTrimmingします。
http://www.example.com/video.mp4?start=0&end=60
このようなQueryString方式はHTTPとFile Systemの両方の呼び出し仕様を同じように使用することができる。
# "/video.mp4の0〜60秒の区間をTrimmingした" ローカルファイルにアクセスします。
/cachefs/www.example.com/video.mp4?start=0&end=60
しかし、MP4HLSやDIMSよう元のURLの後ろに加工オプションをディレクトリ形式で指定する方法は、File I / Oに問題がある。
/cachefs/image.winesoft.com/img.jpg/12AB/resize/500x500/
/cachefs/www.winesoft.com/video.mp4/mp4hls/index.m3u8
"ファイルのプロパティを取得" で説明したように、LINUXは、パスの各部分の属性を毎回尋ねる。 STON観点では現在求めてパスの後に追加のパスがあることを知ることができないため、加工されていないファイルをサービスすることになる。
この問題を克服するためにSTONは別の区切り文字として <FileSystem> の Separator (デフォルト: ^) 属性を使用します。
/cachefs/image.winesoft.com/img.jpg^12AB^resize^500x500^
/cachefs/www.winesoft.com/video.mp4^mp4hls^index.m3u8
MP4HLSアクセス
STON内部では Separator をslash（/）に変更して、HTTPと同じ呼び出し仕様を使用します。 これを積極的に活用する場合は、次のように不要File I / Oアクセスを完全に除去することができる。
極度に最適化されたアプローチ
Wowza連動¶
File Systemを利用して簡単にWowzaを連動することができる。 STONがMountされたパスをWowzaのファイルパスに設定すること、すべての設定が完了している。
1. [STON - グローバル設定] ファイルシステムの設定ON
グローバル設定（server.xml）には、次のように
<FileSystem>をONに設定します。 （例ではMountパスを "/cachefs"に設定します。）# server.xml - <Server><Cache> <FileSystem Mount="/cachefs" DotDir="OFF" Separator="^">ON</FileSystem>またはWMのグローバル設定 - ファイルシステムでは、次のようにファイルシステムを "使用する"に設定します。
設定後は、必ずSTONを再起動する必要がMountされる。
2. [STON - 仮想ホスト] ファイルシステムへのアクセスの許可及び応答コードの設定
仮想ホストのファイルシステムへのアクセスをActiveせる。 ソースサーバーの応答コードによるファイル/ディレクトリの判断ポリシーも設定します。 ここ仮想ホストの設定（server.xml）を例に説明するが、それぞれの仮想ホスト（vhosts.xml）で個別に設定することができる。
# server.xml - <Server><VHostDefault><Options> # vhosts.xml - <Vhosts><Vhost><Options> <FileSystem Status="Active" DotDir="OFF"> <FileStatus>200</FileStatus> <DirStatus>301, 302, 400, 401, 403</DirStatus> </FileSystem>またはWMの仮想ホスト - ファイルシステムでは、次のようにアクセスを "許可する" に設定します。
応答コードを設定します。
3. [Wowza] Storageパスの設定
Wowzaインストールパス/Conf/Application.xmlファイルを次のようにSTONがMountされたパスを眺めるよう編集します。
<Streams> <StreamType>default</StreamType> <StorageDir>/cachefs/example.com</StorageDir> <KeyDir>${com.wowza.wms.context.VHostConfigHome}/keys</KeyDir> </Streams>
4. [Wowza] VODパスの設定
Wowzaインストールパス/Conf/vod/Application.xmlファイルを次のようにSTONがMountされたパスを眺めるよう編集します。
<Streams> <StreamType>default</StreamType> <StorageDir>/cachefs/example.com</StorageDir> <KeyDir>${com.wowza.wms.context.VHostConfigHome}/keys</KeyDir> </Streams>
5. プレーヤーテスト
Wowzaテストプレイヤーにローカルに存在しない（= STONがキャッシュしなければなら）映像をRTMPで再生します。
テストは、適切な映像が必要です。
第20章 最適化とその他のもの¶
この章では最適化とその他の雑多が深みのあるトピックについて扱う。 最適化は高性能（High Performance）のための方法でありこれは私たちが追求する最大の価値だ。 エンタープライズ環境での高性能は与えられたハードウェアリソースを最大限に活用することを意味します。
その中でメモリはすべての設計とポリシーを決定する最も重要な資源です。 特にインデックス（要求されたURLを迅速に見つけること）には必ず理解する必要があります。インデックス速度がサービスの品質に直決するためです。 これから説明するすべての内容は次の表「物理メモリサイズに応じ設定」と関連があります。
| Physical RAM | System Free | Contents | Caching Count | Sockets |
|---|---|---|---|---|
| 1GB | 409.60MB | 188.37MB | 219,469 | 5,000 |
| 2GB | 819.20MB | 446.74MB | 520,494 | 10,000 |
| 4GB | 1.60GB | 963.49MB | 1,122,544 | 20,000 |
| 8GB | 3.20GB | 2.05GB | 2,440,422 | 20,000 |
| 16GB | 6.40GB | 4.45GB | 5,303,733 | 20,000 |
| 32GB | 12.80GB | 9.25GB | 11,030,356 | 20,000 |
| 64GB | 25.60GB | 18.85GB | 22,483,603 | 20,000 |
| 128GB | 51.20GB | 38.05GB | 45,390,095 | 20,000 |
Memory-Onlyモード¶
Memory-Onlyモードはディスクなしでコンテンツをメモリのみ積載する方式です。 Storage構成 をしない場合自動的にMemory-Onlyモードで動作します。
# server.xml - <Server><Cache>
<Storage />
このモードでは TTL (Time To Live) が短いかコンテンツのサイズが小さい場合に便利です。
- HLSライブ配信
- 価格/在庫
- チケット照会
- リアルタイム順位
- 検索
- API
反対にコンテンツのサイズがGB単位で大きいか TTL (Time To Live) が長いサービスでは不適合です。
注釈
v2.5.0からサポートされて動的に変更が不可能です。 設定の変更後は必ずサービスを再起動する必要があります。
インデックス¶
インデックスモードを説明する前にHotコンテンツとColdコンテンツの概念を理解します。
オリジンサーバーからキャッシュしたコンテンツはローカルディスクに保存されます。 そのコンテンツがアクセスされるたびに毎回ディスクから読み取る送信する当然の性能が低下します。 したがって頻繁にアクセスされるコンテンツをメモリにロードしておけば高性能を得ることができます。 このようにメモリにロードされたコンテンツをHotディスクのみあるコンテンツをColdと呼ぶ。
インデックスはHotとColdコンテンツを見つける方法を意味しこれは性能と直結されます。 デフォルトはメモリのインデックスです。
# server.xml - <Server><Cache>
<Indexing>Memory</Indexing>
メモリインデックスではColdが存在しません。 すべてのファイルに関する情報はメモリにロードされるためメモリで見つけることができない場合はオリジンサーバーから新規にダウンロードします。 検索時間が非常に短いためその分高性能と迅速なサービス品質を得ることができます。 しかしメモリ容量の制限によりキャッシュ数に限界があります。 その限界は先進表Caching Countを参照します。
ディスクインデックスはHotにない場合はオリジンサーバーに行く前にColdからコンテンツを探す。
# server.xml - <Server><Cache>
<Indexing>Disk</Indexing>
この方式はメモリの制限を受けないためCaching Countに制限がない。 Hotコンテンツの場合迅速な品質を保証しますがColdの場合はディスクを使用するため比較的遅い。 簡単に整理するとHotはメモリ速度Coldはディスク速度に収束します。
ディスクインデックスを使用する場合はSSDを使用することを強く推奨します。 インデックスはSTONがインストールされてディスクでのみ実行されます。 STONは一般的にOSと同じディスクにインストールされるのでOSディスクのみSSDに使用しても高性能を期待することができます。
注釈
SSDの寿命はアクセス頻度よりWriteされる量によって決定されます。 IntelやSamsungなど供給するSSDの場合最小600TBのWrite寿命を保証します。 これは単に計算してみると一日に20GBずつWriteする場合10年ほどの寿命を予測することができます。 STONからのWriteの99％はLogだ。 このような観点からLogをSSDではなく別のディスク（SASやSATAなど）に記録するようにすれば耐久性を確保することができます。
警告
インデックスは動的に変更することができないだけでなく変更しても安定性が保証されない。 したがってモードを変更した後 Caching初期化 を行わなければ安全にサービスすることができます。
メモリ構造¶
キャッシュサーバと汎用のWebサーバーの動作は同様の一つの目的は非常に異なっている。 STONの構造と動作を詳細に理解するとより最適化されたサービスが可能です。 最適化の目的は以下の通りです。
高スループット パフォーマンスの低下なしに数万のセッションを同時に処理することができます。
クイック反応 クライアントに遅れのないサービスを提供します。
オリジンサーバーの負荷を削減 オリジンサーバーの負荷はややもすると全体の障害につながる。
次の図はSTONを8GBと16GBのメモリ装置で駆動させた時のメモリ構成です。
メモリはSTONが使用するメモリと使用していないメモリ（Free）に分ける。 STONが使用するメモリはファイルソケットのようなサービスの規模に依存する資源の数と関連があります。
注釈
システム負荷の根本はディスクI / Oのためです。 サービス管理者は "どのように多くContentsをCachingするとディスクI / Oのを減らすことができるか。" を考慮する必要があります。
メモリコントロール¶
メモリ構造 は駆動されたとき物理メモリサイズに基づいて計算されます。
# server.xml - <Server><Cache>
<SystemMemoryRatio>100</SystemMemoryRatio>
<SystemMemoryRatio> (デフォルト: 100)物理メモリを基準として使用メモリの割合を設定します。
たとえば8GB機器で <SystemMemoryRatio> を50に設定すると物理メモリが4GBであるかのように動作します。 これはメモリを占有する他のプロセスのように駆動されるときに有用に使用することができます。
サービスの種類に応じてメモリにロードされるデータの割合を調整すると効果的です。
# server.xml - <Server><Cache>
<ContentMemoryRatio>50</ContentMemoryRatio>
<ContentMemoryRatio> (デフォルト: 50)STONが使用するメモリの合計のうちサービスデータメモリロードの割合を設定します。
例えばゲームのポータルのようなファイルの数は少ないがコンテンツのサイズが大きい場合にはこの数値を大きくするとファイルI / Oが減少されます。 反対に非常に小さなファイルが多い場合は減らす設定が役に立つことができます。
システムFreeメモリ¶
OS（Operating System）が遅い場合どのようなプログラムも性能が低下します。 STONはOSのために一部のメモリを予備としてのこします。OSのパフォーマンスを最大化するためにありこれをシステムFreeメモリといいます。
注釈
Freeメモリに対して客観的な説明を提示したいが残念ながら見つからなかった。 グーグリングを通じて最も多く 引用された文 を提示します。
| Physical RAM | System Free |
|---|---|
| 1GB | 409.6MB |
| 2GB | 819.2MB |
| 4GB | 1.6GB |
| 8GB | 3.2GB |
| 16GB | 6.4GB |
| 32GB | 12.8GB |
| 64GB | 25.6GB |
| 128GB | 51.2GB |
サービスに詳しいユーザーは状況に合わせてFreeメモリの割合を調節することができます。 Freeメモリが減らしたらより多くのContentsをメモリにロードすることができます。
# server.xml - <Server><Cache>
<SystemFreeMemoryRatio>40</SystemFreeMemoryRatio>
<SystemFreeMemoryRatio> (デフォルト: 40、 最大: 40)物理メモリに基づいて設定された割合だけをFreeメモリに残っている。
Cachingサービスメモリ¶
クライアントに配信するコンテンツをCachingするメモリになります。 一度ディスクからメモリにロードされたコンテンツはメモリが不足しないかぎり続けてメモリに常駐します。問題はメモリ不足は頻繁に発生するという点です。
上の図のように送信するコンテンツはディスクいっぱいなのに物理メモリにロードすることができる容量は非常に限られている。 32GBの物理メモリを搭載しても4K動画やMMOゲームクライアントのサイズを考慮するとあまりゆったり方ではない。 いくら効率的にメモリを管理しても物理的なディスクI / O速度に制限されます。
最も効果的な方法はContentsメモリ空間を最大限に確保してディスクI / Oの減らすことになります。 以下は物理メモリの基準でSTONがデフォルト的に設定する最大Contentsメモリサイズです。
| Physical RAM | Contents | Caching Count |
|---|---|---|
| 1GB | 188.37MB | 219,469 |
| 2GB | 446.74MB | 520,494 |
| 4GB | 963.49MB | 1,122,544 |
| 8GB | 2.05GB | 2,440,422 |
| 16GB | 4.45GB | 5,303,733 |
| 32GB | 9.25GB | 11,030,356 |
| 64GB | 18.85GB | 22,483,603 |
| 128GB | 38.05GB | 45,390,095 |
Socketメモリ¶
ソケットもメモリを消費します。 4GB以上の機器でSTONは2万個のソケットを基に生成します。 ソケット1個= 10KB、1万ソケットは97.6MBのメモリを使用するので約195MBのメモリがデフォルト的にソケットに割り当てられる。
| Physical RAM | Socket Count | Socket Memory |
|---|---|---|
| 1GB | 5千 | 50MB |
| 2GB | 1万 | 97.6MB |
| 4GB 以上 | 2万 | 195MB |
次の図のようにソケットをすべて使用すると自動的にソケットが増えます。
上の図のように増設され3万個のソケットを使用する場合は合計240MBのメモリがソケットに割り当てられる。 必要なソケットを必要分だけ使用することは何の問題もないように見える。 しかし使用しないソケットを過度に多く設定することはメモリの無駄だ。 例えば10Gbpsの装置ではユーザーごとに10Mbpsの伝送速度を保証することを前提したとき次の式によって最大同時ユーザーは1,000人です。
10,000Mbps / 10Mbps = 1,000 Sessions
この場合STONが最初に生成する2万のうち19,000個に相当する約148MBは無駄になります。この148MBをContentsに投資する場合の効率をより高めることができます。 最小ソケット数を設定するとメモリをより効率的に使用することができます。
最小ソケット数 最初に割り当てられているソケットの数です。
増設ソケット数。 ソケットがすべて使用中（Established）のときに設定した数だけソケットを増設します。
もう一つの重要な変数はクライアントKeep-Alive時間設定になります。 (セッション管理 を参照)
接続されたすべてのソケットがデータ転送中ではない。 IE、Chromeのようなブラウザは次に発生するHTTPトランスポートのためにソケットをサーバーに接続しておいた状態を維持します。 実際にショッピングモールの場合は接続されているセッションの中でidleセッションの割合は少なくは50％から多くは80％にのぼる。
Keep-Alive時間を長く与えるほどソケットの再利用は良くなりますが、維持されるIdleソケットの数が増加するのでメモリを無駄使いが悪化します。サービスに合わせたクライアントKeep-Alive時間を設定することが重要です。
TCP Segmentation Offload¶
.. important:
10G NICを使用する場合はTSO（TCP Segmentation Offload）のOFF設定がお勧めです。
TCPは送信時のパケットを分割（Segmentation）がこの作業をCPUではなくNICが実行するように設定することがTSOです。 （デフォルトはONです。）しかし10G NICサービス環境では我々はそれに関連する多くの障害を経験した。
- TCPパケットlossとdelay
- TCP disconnect
- Load Averageの異常増加
結論としてTSOはすべての期待ほど高い性能を出せないものと推定されます。 （NICのみ1Gに変えてもこのような問題は発生しませんでした。）結論としてTSOをOFFに設定することによりサービスは正常化された。 これによるCPU使用率は心配するレベルではなくサービスの規模と比例する正直な指標を示してくれる。
TSOの設定は次のように設定/確認することができます。 （Kの大文字/小文字に注意する必要があります。）
# ethtool -K ethX tso off // TSO OFF 設定
# ethtool -k ethX // 設定閲覧
...
tcp segmentation offload: on
...
クライアントアクセス制限¶
無制限にクライアント要求を許可するとシステムに過度な負荷が発生します。システムの過負荷は障害になります。適切な数値でクライアントの要求を拒否してシステムを保護します。
# server.xml - <Server><Cache>
<MaxSockets Reopen="75">80000</MaxSockets>
<MaxSockets> (デフォルト: 80000, 最大: 100000)の接続を許可するクライアントの最大ソケット数。 この数値を超えると新規クライアント接続をすぐに閉める。<MaxSockets>のReopen (デフォルト: 75%)の割合だけソケット数が減少すると再び接続を可能にします。
（デフォルト設定で）完全なクライアントソケットの数が8だけ超える新規クライアント接続は直ちに終了されます。全クライアントソケットの数が6万（8万75％）になると再びアクセスを可能にします。
例えば3万個のクライアントセッションを処理するときにオリジンサーバーがすべての制限に達するとこの数値を3〜4万程度に設定するのが良い。 これにより得られる効果は以下の通りです。
- 特特別Network構成（eg L4セッション制御など）が必要ない。
- 不要な（元の負荷で処理することができない）クライアントの要求を防止します。
- サービスの信頼性を高める。 サービスBurst以降の再起動など点検作業が必要ない。
HTTPクライアントセッション数¶
HTTPクライアントの接続を処理するための初期/増設セッション数を設定します。
# server.xml - <Server><Cache>
<HttpClientSession>
<Init>20000</Init>
<TopUp>6000</TopUp>
</HttpClientSession>
<Init>STON起動時にあらかじめ作成しておくソケット数<TopUp>生成しておいたソケットの数を超えたときに追加で作成することがソケット数
別に設定していない場合は物理メモリのサイズに応じて自動的に設定されます。
| 物理メモリ | <Init>、 <TopUp> |
|---|---|
| 1GB | 5000、1000 |
| 2GB | 10000、2000 |
| 4GB | 20000、4000 |
| 8GB 以上 | 20000、6000 |
限定的な環境で少ない数のソケットだけでサービスが可能な場合ソケットの数を減らすメモリを節約することができます。
Request hit ratio¶
まずクライアントのHTTP要求がどのように処理されるかを理解します。 キャッシュ処理の結果はSquidと同じようにTCP_*と命名され各表現ごとにキャッシュサーバが処理した方式を意味します。
TCP_HIT要求されたリソース（無期限）がキャッシュされてすぐに応答します。TCP_IMS_HITIMS（If-Modified-Since）ヘッダと要求されたリソースが有効期間ないでキャッシュされて304 NOT MODIFIEDに応答します。 TTLExtensionBy4xx、TTLExtensionBy5xx設定に該当する場合にもこれに該当します。TCP_REFRESH_HIT要求されたリソースが期限切れになってオリジンサーバーの確認（オリジン変更なし、304 NOT MODIFIED）後に応答します。 リソースの有効期限延長。TCP_REF_FAIL_HITTCP_REFRESH_HIT過程の中オリジンサーバーで確認が失敗（接続の失敗伝送遅延）した場合有効期限が切れたコンテンツで応答します。TCP_NEGATIVE_HIT要求されたリソースが異常状態（オリジンサーバー接続/送信の失敗4xx応答、5xx応答）にキャッシュされてその状態を応答します。TCP_REDIRECT_HITサービス許可/拒否/ Redirect条件によってRedirectを応答します。TCP_MISS要求されたリソースがキャッシュされていない（=最初の要求）。 オリジンサーバーから取得したコンテンツで応答します。TCP_REF_MISS要求されたリソースが期限切れになってオリジンサーバーの確認（オリジンサーバーの変更、200 OK）した後の応答します。 新しいリソースがキャッシュされます。TCP_CLIENT_REFRESH_MISS要求をオリジンサーバーにバイパス。TCP_ERROR要求されたリソースがキャッシュされていない（=最初の要求）。 オリジンサーバー障害（接続の失敗伝送遅延原稿排除）によりリソースをキャッシュできない。 クライアントに500 Internal Errorで応答します。TCP_DENIED要求は拒否されました。
以上を総合してRequest hit ratioの計算式は次の通りです。
TCP_HIT + TCP_IMS_HIT + TCP_REFRESH_HIT + TCP_REF_FAIL_HIT + TCP_NEGATIVE_HIT + TCP_REDIRECT_HIT
------------------------------------------------------------------------------------------------
SUM(TCP_*)
Byte hit ratio¶
クライアントに送信したトラフィック（Client Outbound）比オリジンサーバーから送信されたトラフィック（Origin Inbound）の割合を示す。 オリジンサーバーのトラフィックがクライアントのトラフィックよりも高い場合負のが出てくることができます。
Client Outbound - Origin Inbound
--------------------------------
Client Outbound
オリジンサーバーの障害状況ポリシー¶
ユーザーがいつでもオリジンサーバーをチェックできるようにすることがSTONの目標だ。 オリジンサーバーの障害が検出されるとサーバーは自動的に排除されてリカバリモードに転換されます。 障害サーバーが再起動されても通常のサービスの状態を確認しなければなら再度投入します。
もしすべてのオリジンサーバーの障害を検出した場合現在のキャッシュされたコンテンツへのサービスを行う。 TTLが期限切れコンテンツはオリジンサーバーが復旧するまで自動的に延長されます。 さらにPurgeされたコンテンツの場合でもオリジンサーバーからキャッシュすることができない場合は復旧させサービスに問題がないように動作します。 最大限クライアントに障害状況を公開してはいけないという方針です。 完全障害状況で新規コンテンツ要求が入ってくると次のようなエラーページと理由が指定されます。
まあまあの程とこのような画面は表示する嫌いだ。
時間単位の表現と範囲¶
基準時間が "超" の項目について文字列として時間表現が可能です。 以下はサポートされる時間の表現のリストと換算された秒（sec）です。
| 表現 | 換算 |
|---|---|
| year(s) | 31536000 秒 (=365 days) |
| month(s) | 2592000 秒 (=30 days) |
| week(s) | 604800 秒 (=7 days) |
| day(s) | 86400 秒 (=24 hours) |
| hour(s) | 3600 秒 (=60 mins) |
| minute(s), min(s) | 60 秒 |
| second(s), sec(s), (省略) | 1 秒 |
次のように組み合わせた時間の表現が可能です。
1year 3months 2weeks 4days 7hours 10mins 36secs
現在サポート対象は以下の通りです。
- Custom TTLの時間表現
- TTLのRatioを除くすべて
- ClientKeepAliveSec
- ConnectTimeout
- ReceiveTimeout
- BypassConnectTimeout
- BypassReceiveTimeout
- ReuseTimeout
- RecoveryのCycle属性
- Bandwidth Throttling
Emergencyモード¶
内部的にすべての仮想ホストがMemoryBlockを共有しながらデータを管理するように設計されている。 新規メモリが必要な場合は参照されない古いMemoryBlockを再利用して新規メモリを確保します。 このプロセスをMemory-Swapと呼ぶ。 このような構造により長期間運用しても安定性を確保することができます。
コンテンツデータはMemoryBlockに含まれてサービスされます。
上の図の右側の状況のようにすべてのMemoryBlockが使用中で再利用することができるMemoryBlockが存在しない状況が発生することができます。 この時Memory-Swapが不可能になる。 たとえばすべてのクライアントが異なるデータ領域を非常に少しずつダウンロードしたりオリジンサーバーから別のデータを非常に少しずつ送信する状況が同時に発生する場合が最悪です。 このような場合はシステムから新しいメモリを割り当てて使用することも方法です。 しかしこのような状況が続く場合はメモリ使用量が高くなる。 メモリ使用量が過度に高くなる場合はシステムメモリのスワップを発生させたり最悪の場合はOSがSTONを終了させる状況が発生することがあります。
注釈
Emergencyモードとメモリ不足の状況が発生した場合一時的に新規MemoryBlockの割り当てを禁止させる状況を意味します。
これは過剰メモリ使用からサービスを守るための方法であり再利用可能なMemoryBlockが十分に確保されると自動的に終了されます。
# server.xml - <Server><Cache>
<EmergencyMode>OFF</EmergencyMode>
<EmergencyMode>OFF (デフォルト)を使用しません。ONを使用します。
EmergencyモードのときSTONは次のように動作します。
すでにロードされているコンテンツはそのままサービスされます。
バイパスは通常行われる。
ロードされていないコンテンツについては503 service temporarily unavailableで応答します。 TCP_ERROR状態が増加します。
Idleクライアントソケットを素早く整理します。
新規コンテンツをキャッシュすることができない。
TTLが期限切れコンテンツを更新しません。
SNMPのcache.vhost.statusとXML / JSON統計のHost.State値が "Emergency" で提供されます。
InfoログにEmergencyモードに切り替え/オフを次のように記録します。
2013-08-07 21:10:42 [WARNING] Emergency mode activated. (Memory overused: +100.23MB) ...(省略)... 2013-08-07 21:10:43 [NOTICE] Emergency mode inactivated.
ディスクHot-Swap¶
サービスを中断せずディスクを交換します。必ず <Disk> 設定と同じパラメータにする必要があります。
http://127.0.0.1:10040/command/unmount?disk=...
http://127.0.0.1:10040/command/umount?disk=...
排除されたディスクはすぐに使用しないようになり、そのディスクに保存されたすべてのコンテンツは無効化されます。 管理者によって排除されたディスクの状態は "Unmounted" に設定されます。
ディスクをサービスに再投入するには次のように呼び出します。
http://127.0.0.1:10040/command/mount?disk=...
再投入されたディスクのすべてのコンテンツは無効化されます。
5部。 付録¶
Appendix A: Graph¶
すべてのMRTG統計はPNG形式のグラフで提供される。 呼び出し規約は、リソースの後に単位が付く形式である。
# 5つの CPU Graph (dash, day, week, month, year)
http://127.0.0.1:10040/graph/cpu_dash.png
http://127.0.0.1:10040/graph/cpu_day.png
http://127.0.0.1:10040/graph/cpu_week.png
http://127.0.0.1:10040/graph/cpu_month.png
http://127.0.0.1:10040/graph/cpu_year.png
すべてのグラフは、5つのタイプに提供される。
| タイプ | サイズ | 時間単位 | 期間 |
|---|---|---|---|
| dash | 205 X 175 | 5分 | 12時間 |
| day | 580 X 203 | 5分 | 2日 (48時間) |
| week | 580 X 203 | 30分 | 2週間 (14日) |
| month | 580 X 203 | 2時間 | 7週 |
| year | 580 X 203 | 1日 | 18ヶ月 |
グラフには、少なくとも1つから最大3つの線が描かれる。 Mainラインは緑、Sub行は青で描かれる。 また、"Week"のグラフ以上からPeakラインが提供される。 Peakラインは、以前の単位での最大の数値をピンクに描く。
注釈
あまりにも多くのグラフを同時に描画する場合、CPU使用率が過度に高くなり、サービス品質の低下が発生することができる。 これを防止するために、常に、一度に一つのグラフのみ描くように管理する。
グローバル・リソース¶
グローバル・リソースグラフは、システムの状態やSTONに関するリソースについてサービスする。 以下の表で *はタイプ（dash、day、week、month、year）のいずれかを意味する。
仮想ホスト¶
仮想ホストのグラフは、全体または個々の仮想ホストの状態についてサービスする。 vhostパラメータを利用して、特定の仮想ホストを指定することができ、省略された場合、全体の仮想ホストの合計を提供する。
http://127.0.0.1:10040/graph/vhost/mem_day.png?vhost=example.com
以下の表で *はタイプ（dash、day、week、month、year）のいずれかを意味する。
クライアントトランザクションの完了¶
/graph/vhost/client_http_res_complete_*.png
Main完了クライアントHTTP応答の数SubクライアントのHTTP要求の数
ソースサーバートランザクションの完了¶
/graph/vhost/origin_http_res_complete_*.png
Main完了ソースサーバーHTTP応答の数Sub元サーバーのHTTPリクエストの数
Appendix B：Cacti監視¶
この章では、 Cacti のGraph Treeを使用して、多数のSTONを統合監視する方法について説明します。 次の2つの条件が前提となります。
- Cactiをインストールするサーバー
- SNMPの有効化 ( 第11章 SNMP 参照)
Template追加¶
STONで提供されるHost Templateを使用すると、監視環境を容易に構築することができます。 ( ダウンロード )
Import Templatesメニューを選択します。
cacti_host_template_ston.xmlをImportします。
Device登録¶
STONをCactiのDeviceに登録します。
[Devices]メニューを選択します。
[Devices]メニューの[Add]ボタンをクリックします。
Devices項目を作成します。
- ① 対象STONの名前を作成します。
- ② 対象STONのIPアドレスを入力します。
- ③ ”STON” を選択します。
- ④ “Public” を選択します。
- ⑤ デフォルトのポート161を入力します。
Createボタンをクリックして、Deviceを連動します。
正常連動された。
連動に失敗しました。
注釈
SNMP連動失敗時
- STONのSNMPが有効になっていることを確認します。
- SNMP Port番号がSTONのSNMP Port番号と一致することを確認します。
Device連動に成功するとSTON Templateで提供される18種類の項目のグラフを使用することができます。
"Create Graphs for this Host" リンクをクリックします。
18種類のグラフが提供される。
[Create] ボタンをクリックして、生成されたグラフを確認します。
グラフが作成された。
Graph Tree生成¶
Graph Treeを生成します。
[Graph Trees] をクリックします。
右上の [Add]をクリックします。
Graph Tree生成します。
STONをGraph Treeに追加します。
[Tree Items] メニューから[Add]をクリックします。
[Tree Items]項目を作成します。
- ① “Host”を選択します
- ② 追加する “Devices” を選択します。
- ③ “Graph Template” を選択します。
Appendix C：動的ページの注意事項¶
動的ページとは、Webプログラミング言語（JSP、PHPなど）で開発されたWebページを意味し、主にクライアントの要求に応じ内容が変更される特徴を持つ。 次のような動的なページを適当時間キャッシュすると、Webサーバー/ WAS /データベースの負荷を大幅に減少させることができます。
- リアルタイム結果（リアルタイム検索語またはランキング）
- 検索結果
- 照会のためのAPI
- 商品詳細ページ（在庫）
キャッシュしてはならないページは、次のとおりであります。
個人アカウント
キャッシュするという意味は自分が閲覧したページが他の人にも共有されるという意味であります。 誰も私の個人情報が他の人に公開されることを望まない。 技術的にはほとんどのウェブサイトでの個人情報は、ログイン後に使用が可能であります。 Webサーバーからログインするかどうかを確認する条件をSTONに ‘バイパス’ するように設定する必要があります。
決済
非ログイン状態で決済が可能なサービスもあります。 決済段階のすべてのページは、キャッシュ例外条件に設定する必要があります。
Cookieの作成
Cookieは、クライアント固有の情報を含んでいる場合が多い。 Aユーザーのために作成されたCookieがBのユーザーに転送されると、大きな事故につながる。 このため、STONは、元のサーバーが提供するCookieヘッダーを無視するように開発されました。
‘書き込み(Write)’ API
読み取りAPIは1秒キャッシュしても効果がありますが「書く」のAPIをキャッシュする場合、無効な結果値が返され、誤動作することができます。
番号札発券
コンサートのチケットのように、先着順で前売りする場合を意味します。 通常WASや専用機器を使って行われる場合が多いです。
Appendix D: リリースノート [CDN]¶
v2.5.x¶
2.5.16 (2018.5.29)¶
機能改善/ポリシーの変更
- MP4 HLS - キーフレームの間隔が不規則な映像の互換性を強化
警告
以前のバージョンと MP4 HLS のMPEG2-TSは互換性がありません。
2.5.15 (2018.5.21)¶
バグ修正
- handling_http_requests_header_lastmodifiedcheck -
orlaterに設定する場合、最初のキャッシュ時に304応答をすることができる問題を修正
2.5.14 (2018.4.26)¶
- クライアントの要求 handling_http_requests_header_if_range ヘッダサポート
- オリジンの要求時に origin_header_if_range ヘッダサポート
- handling_http_requests_header_lastmodifiedcheck 設定機能を追加
2.5.13 (2018.3.27)¶
機能改善/ポリシーの変更
- クライアントの要求/応答ヘッダの変更 - CACHE-HIT 結果をレスポンスヘッダに追加します。
- WM - CI 変更
バグ修正
- TTLを0に設定し、すぐにコンテンツが更新されると、i-nodeが増加するバグ
- 特定の環境でIndexファイルが継続大きくなるバグ
2.5.11 (2018.1.25)¶
機能改善/ポリシーの変更
- SSL/TLS - CipherSuiteを選択 SHA384をサポート
- SSL/TLS - The ROBOT Attack 対応
- クライアントの要求/応答ヘッダの変更 - HTTPリクエストMethod条件を追加
- 仮想ホストへのアクセス制御 - POSTリクエストもアクセス制限が可能なように改善
- WM - キャッシュの状態確認ページへのHTTPSダウンロード機能を追加
2.5.10 (2017.12.18)¶
機能改善/ポリシーの変更
- DIMS - Round（画像の角を丸く処理）コマンドを追加
- クライアントの要求/応答ヘッダの変更 , オリジン要求ヘッダの変更 - #PROTOCOLキーワードを追加
- その他のCaching設定 - 空のディレクトリの削除ポリシーを追加
- XML設定アップロード 追加
バグ修正
- 一部API呼び出し結果のJSON文法エラーを修正
2.5.8 (2017.11.9)¶
- 送信元アドレスを使用ポリシー - DNSにResolvingされたIPアドレスの最大使用時間を設定する。
機能改善/ポリシーの変更
- DIMS -
ResizeCropコマンドを追加- DIMS - Animated GIF 変換時のフレーム数の制限コマンド
limit追加- 仮想ホストへのアクセス制御 - Redirect 条件に
PROTOCOL条件の追加
バグ修正
- 送信元アドレスを使用ポリシー - DNSにResolvingされたIPアドレスの累積数が多くなる場合、統計集計が遅れていたバグ
- [WM] 仮想ホストへのアクセス制御 UIが割れバグ
- [WM] クライアントの要求/応答ヘッダの変更 の設定が初期化されるバグ
2.5.7 (2017.10.13)¶
バグ修正
- [v2.5.5 ~ v2.5.6] Transfer-Encoding コンテンツのメモリが整理されていなかった問題を修正
- [v2.4.6 ~ v2.5.6] MP3 HLS - キャッシュされたコンテンツが更新される場合、異常終了する問題を修正
2.5.6 (2017.9.28)¶
- HTTP OPTIONS Methodサポート
バグ修正
- 設定が正常にバックアップされない場合、SNMP関連の設定が反映されなかった問題を修正
- 圧縮 - TTLが初期化された問題を修正
2.5.5 (2017.8.30)¶
- コンテンツ DRM をサポートする。
- 更新不可時のポリシー を設定することができる。
機能改善/ポリシーの変更
- Memory-Onlyモード の安定性を強化
- クラスタ情報照会 API を追加
- [WM] Apacheのセキュリティ勧告に反映
バグ修正
2.5.2 (2017.7.6)¶
機能改善/ポリシーの変更
バグ修正
- Memory-Onlyモード でDisk整理ロジックが実行されるバグの修正
- 仮想ホストのリンク から断続的に、次の仮想ホストに移らない問題を修正
2.5.1 (2017.6.8)¶
機能改善/ポリシーの変更
- POSTリクエストをキャッシュする場合、元のサーバーにクライアントが送信されるContent-Typeを送信するように変更
バグ修正
- [v2.5.0] Rangeリクエスト 機能が有効になっている場合、キャッシュされていたファイルが初期化される問題
- [v2.5.0] Rangeリクエスト 機能が有効になっているWrite統計が収集されていない問題
- WM – HTTPヘッダーの変更時、引用符（ "）が入力されない問題
2.5.0 (2017.5.25)¶
- HTTPS - SNI (Server Name Indication) をサポートする。
- Memory-Onlyモード をサポートします。
v2.4.x¶
2.4.9 (2017.4.24)¶
機能改善/ポリシーの変更
- MP4 HLS - エンコーディング情報がすべてのキーフレームに含まれている映像の互換性を強化
- ハイエンドサーバのメモリ使用ポリシーを最適化
バグ修正
- STON Edge Serverが実行中のシステム時間が変更されると、1時間の間の統計が欠落している問題
- Health-Checker セッションが有効になっている場合、非常に低い確率で異常終了することができる問題
- Bypassセッションが有効になっている状態で、Diskが排除された場合、低い確率で異常終了することができる問題
- （ログ圧縮機能を使用する場合）、ログが圧縮される時点で、ログが一部欠落することができる問題
- Rangeリクエスト 機能が有効にされた状態で、ヘッダが大きいメディアファイルをサービスする際に、最初の要求が断続的に切断されることがある問題
2.4.6 (2017.3.29)¶
- MP3 HLS MP3形式でSegementationが可能である。
機能改善/ポリシーの変更
バグ修正
- 低い確率で404の応答がメモリからSwapされる異常終了する問題
警告
以前のバージョンと MP4 HLS のMPEG2-TSは互換性がありません。
2.4.5 (2017.2.16)¶
バグ修正
- DIMS 処理時、元のサーバーがTransfer-Encoding：chunkedで応答する場合、異常終了したバグ
- SSL CipherSuiteをECDHEのみを選択するように設定する場合、Chromeブラウザでの接続が終了するバグ
- 非常に低い確率でログのクリーンアップ時に異常終了するバグ
2.4.2 (2017.1.18)¶
- 仮想ホストのリンク を追加
バグ修正
- オリジンサーバーがContent-Lengthヘッダに負の値を与える場合、異常終了したバグ
- MP3 HLS - オリジンサーバーとの通信が不安定な場合、断続的に異常終了されるバグ
v2.3.x¶
2.3.7 (2016.09.26)¶
機能改善/ポリシーの変更
- DIMS 機能を利用して画像変換時のシステムリソースの使用量を制限するようにポリシーの変更
- Health-Checker機能使用時Standby元サーバーもチェックするようにポリシーを変更する
バグ修正
- handling-http-requests-compression機能のON / OFF設定が反映されなかったバグを修正
2.3.6 (2016.08.16)¶
機能改善/ポリシーの変更
- 一部の透過PNGをJPGへフォーマット変換時の背景が黒に変更される問題を修正
- 異常クライアントソケットの処理ポリシーの強化
バグ修正
- DIMS変換中Hardpurge APIを呼び出す場合、断続的に異常終了いたバグ
2.3.5 (2016.07.01)¶
機能改善/ポリシーの変更
- Native HLSモジュールを使用しているプレイヤーとの互換性を強化
- DIMSのCrop機能は縦横比を維持せずに入力したサイズにCropするポリシーを変更
バグ修正
- Health-Checker機能が有効になっている状態で、元の状態の初期化API呼び出し時に断続的に異常終了する問題を修正
2.3.4 (2016.06.03)¶
機能改善/ポリシーの変更
- 32bit atomでエンコードされた4GB以上のMP4ファイルをサポート
- unknown accessログにHostヘッダを追加
- WM - セキュリティ勧告でSTON最初のインストール時にApache manualフォルダを削除する
- WM - STON最初のインストール時にApache駆動アカウントであるwinesoftアカウントをnologin権限で作成するように変更
バグ修正
- HLS - いくつかの映像では、CPUを寡占有していたバグ
- HTTP要求がバイパスされるときに、低確率で異常終了いたバグ
- AccessログにクライアントのIPアドレスが0.0.0.0に記録れたバグ
- 仮想ホストが260個以上の場合は、設定ファイルがバックアップされなかったバグ
2.3.3 (2016.04.26)¶
バグ修正
- [2.3.0 ~ 2.3.2] オリジンサーバーHostの設定とDims、圧縮設定が一緒にされている場合、404エラーコードを応答するバグ
- SNMP Viewの作成後、削除時CPU寡占有バグ
- WM - SNMP GlobalMin値を0に設定することができなかったバグ
2.3.2 (2016.03.22)¶
機能改善/ポリシーの変更
- mp3-hlsインデックスファイルの互換性を強化
バグ修正
- 通常のHandshakeなく、がん化/復号化が進むと異常終了いたバグ
- ACLが有効にされた状態で、断続的に異常終了するバグ
2.3.1 (2016.02.25)¶
- MP3をmp3-hlsに送信する。
機能改善/ポリシーの変更
- ユーザー定義のAccessログのフォーマット を追加 | %y リクエストのHTTPヘッダサイズ | %z 応答のHTTPヘッダサイズ
バグ修正
- WM - Destポートを入力しない場合は、設定されなかったバグ
v2.2.x¶
2.2.5 (2016.01.12)¶
機能改善/ポリシーの変更
- HTTP <451 Unavailable For Legal Reasons> 応答コードを追加
バグ修正
- TLS - 攻撃パケットの異常終了いたバグ（例外処理の強化）
2.2.2 (2015.12.04)¶
- 元に送信するHTTPリクエストのヘッダを変調する。
機能改善/ポリシーの変更
- handling-http-requests-modify-client - putアクションを追加。 同じ名前のヘッダをマルチラインに挿入する。
2.2.1 (2015.11.19)¶
バグ修正
- TLS - Handshake過程の中で、クライアントがChangeCipherSpecとClientFinishedを別に送信するときは、サーバーがChangeCipherSpecを重複して送ったバグ
- DIMS - Animated GIFをリサイズするときの比率が維持されなかったバグ
2.2.0 (2015.11.04)¶
- TLS 1.2をサポートする。 （+ Forward Secrecyなどの細かいセキュリティポリシーの強化）
バグ修正
ディスク情報を得られない場合、異常終了していたバグ
TLS - Handshake過程でMaxのバージョンを選択していなかったバグ
Before. TLSPlaintext.version使用After. ClientHello.client_version使用
v2.1.x¶
2.1.7 (2015.10.07)¶
- multi-trimming -時間の値を基準にし、複数の指定された区間を一つの映像として抽出する。
機能改善/ポリシーの変更
- access - X-Forwarded-Forヘッダ記録オプションTrimCIP追加
バグ修正
- HLS - いくつかのprofileでの画面震えのバグ
- DIMS - TTLが0に設定されているときに、断続的に500 Internal Errorで応答していたバグ
- X-Forwarded-For ヘッダをログにc-ipフィールドに記録する際に空白文字が含まれていたバグ
2.1.6 (2015.09.10)¶
機能改善/ポリシーの変更
- DIMS - Animated GIFの最初のシーンのみを変換することができる。
バグ修正
- ACL - IP許可/ブロックが正常に動作していなかったバグ
- DIMS - Cropなど+記号を用いた座標指定がされなかったバグ
2.1.5 (2015.08.18)¶
- sub-path -アクセスパスに応じて異なる仮想ホストに分岐する。
- facade -アクセスドメインに基づいて、クライアントのトラフィックの統計情報とAccessログを分離する。
2.1.4 (2015.07.31)¶
機能改善/ポリシーの変更
CPU使用率の改善
multi-nic - NICの名前でListenする。
アクセス制御視点変更
Before. クライアントが要求されたURIでキーワード（DIMSやMP4HLSなど）を削除した後の検査After. クライアントが要求したURIのそのまま検査
バグ修正
- DIMS - エンコードされた変換文字列を認識していなかったバグ
- hardpurgeが 大文字と小文字の区別 ポリシーに準拠していなかったバグ
- 設定バックアップするときpostが不足していたバグ
2.1.3 (2015.06.25)¶
機能改善/ポリシーの変更
- syncstale -管理（purge、expire、hardpurge）API呼び出しがインデックスに反映されない場合がないように、ログに記録して、サービスの再起動時に再反映する。
- ユーザー定義のAccessログのフォーマット に％u表現を追加。 クライアントが要求されたFull URIを記録する。
バグ修正
- DIMS - オリジンサーバーからLast-Modifiedヘッダを与えないときの画像が更新されなかったバグ
- trimmingされたMP4のサイズが4GBを超える場合のCPUを寡占有していたバグ
- エラーページを応答するときviaヘッダの設定が反映されなかったバグ
2.1.2 (2015.05.29)¶
- WM - 英語バージョンのサポート
機能改善/ポリシーの変更
- Single Core 機器サポート
バグ修正
- adv-topics-indexingモードでカスタマイズモジュールが誤動作したバグ
2.1.1 (2015.05.07)¶
- HLS - Stream Alternates形式を使用してBandwidth、Resolution情報を提供する。
バグ修正
- ヘッダが壊れたMP4映像分析の異常終了いたバグ
2.1.0 (2015.04.15)¶
機能改善/ポリシーの変更
第5章 Caching削除 APIからディレクトリ表現を削除
ディレクトリ表現（example.com/img/）は、そのURLに対応する（元のサーバーが応答した）ファイルだけを意味する。既存のディレクトリ表現（example.com/img/）はパターン（example.com/img/ * ）に統合する。API表現を追加
/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/coldfiledist.jsonWM - resolv.conf 編集機能の削除
v2.0.x¶
2.0.7 (2015.06.25)¶
バグ修正
- media_dims -オリジンサーバーからLast-Modifiedヘッダを与えないときの画像が更新されなかったバグ
- trimmingされたMP4のサイズが4GBを超える場合のCPUを寡占有していたバグ
- エラーページを応答するときviaヘッダの設定が反映されなかったバグ
2.0.5 (2014.04.01)¶
機能改善/ポリシーの変更
Trimmingされた映像をHLSにサービスすることができる。 次は、元の画像（/vod.mp4）の0〜60秒の区間をTrimmingした後、HLSにサービスする表現である。
/vod.mp4?start=0&end=60/mp4hls/index.m3u8/vod.mp4**/mp4hls/index.m3u8**?start=0&end=60/vod.mp4?start=0/mp4hls/index.m3u8?end=60HLS インデックスファイル（.m3u8）バージョンの改善
Before. バージョン 1After. バージョン 3 (バージョン1に変更可能)
バグ修正
- HLS変換中HTTPエンコードされている特殊文字がある場合、異常終了いたバグ
- ヘッダが壊れたMP4画像解析のCPUが過度に占有れたバグ
- AudioのKeyFrameが均一でないMP4映像をHLSにサービスするときAudioとVideoの同期が合わないバグ
- RRD - 統計情報の収集がされなかったバグは、応答時間が平均ではなく、合計で表示されたバグ
- WM - 新規ディスク投入時のフォーマットを強制していた条件を削除
2.0.4 (2015.02.27)¶
機能改善/ポリシーの変更
オリジンサーバーの選択 のHashアルゴリズムの変更
Before. hash(URL) / サーバー台数After. Consistent Hashing <http://en.wikipedia.org/wiki/Consistent_hashing>仮想ホストへのアクセス制御 を使用してRedirectすると、クライアントが要求したURIをパラメータとして入力することができる。
バグ修正
- キャッシュされたファイルが削除されず、ディスクがいっぱい冷たくバグ
2.0.3 (2015.02.09)¶
機能改善/ポリシーの変更
- DIMS 内在化と高度化
- WM - トラフィック関連のご案内メッセージを追加
バグ修正
- WM - 新規仮想ホストの作成に失敗するバグを修正
2.0.2 (2015.01.28)¶
- オリジンサーバーにキャッシュ要求したとき、クライアントが送信したUser-Agentヘッダの値を送ることができる。
バグ修正
- MDATの長さが1であるMP4ファイルのTrimmingがされなかったバグ
- WM - クラスタ内の他のサーバーのグラフが表示されなかったバグ
- WM - クラスタ内の他のサーバーが現在のサーバーに見えたバグ
2.0.1 (2014.12.30)¶
- HitRatioグラフが0と表示されていたバグ
2.0.0 (2014.12.17)¶
ソースからダウンロードされたサイズ分だけディスク領域の使用。 （origin-partsize参照）
メモリの制限 機能を追加
TLS 1.1 をサポート
AES-NIを使用して SSL / TLS加速 をサポート
ECDHE系のCipherSuiteをサポートします。 (CipherSuiteを選択 を参照)
DNSログ を追加
オリジンサーバーがDomainの場合、各IP別TTLを使用するようにポリシーの変更
元 障害の検知と復旧 を追加
元 Health-Checker を追加
システムFreeメモリ を追加
その他
最小実行環境に変更。 （Cent 6.2以上、Ubuntu 10.01以上）インストールパッケージにNSCDデーモンが搭載DIMS 標準搭載Caching初期化 後STON再起動するように変更<DNSBackup> 機能の削除<MaxFileCount> 機能の削除<Distribution> 機能削除します。 オリジンサーバーの選択 機能の統合
v1.4.x¶
1.4.2 (2014.12.08)¶
- Purge（自動回復）APIがHardPurge（回復不可）で動作するようにpurgeすることができる。
- ログローリング時圧縮するように設定することができる。
- FTPクライアント機能の強化 - 伝送時間、パス、削除、バックアップ機能を追加
バグ修正
- SSL/TLS Handshake過程の中で異常終了いたバグ
1.4.1 (2014.11.25)¶
- クライアントが送信したURIを処理せずに、元のサーバーに送信するように、 クライアントの要求を維持 することができる。
バグ修正
- MP4映像にSPS / PPSがない場合、異常終了いたバグ
- FTPクライアントがActiveモードで動作していなかったバグ
- WM - SNMPのVhostMin、ViewMinを0から設定できるように修正（従来1から）
v1.3.x¶
1.3.20 (2014.11.05)¶
- [全体]過負荷管理機能を追加。 設定された最大クライアント（ソケット）の数を越えるアクセスが発生した場合、クライアントの接続、すぐに接続を壊す。 これはソリューションとプラットフォームを保護するための最も強力な措置である。 全体ソケットが一定の割合以下に下がると、クライアントのアクセスを可能にする。
- 第9章 HTTPS プロトコル（SSL3.0またはTLS1.0）を選択可能
機能改善/ポリシーの変更
file-systemでファイルの時間を提供する方法を設定可能
Before. ローカルにキャッシュされた時間After. 元のLast-Modified時刻クッキー関連ポリシーの変更
Before. cookieヘッダを削除する。After. cookie、set-cookie、set-cookie2ヘッダを削除する。 WMで警告メッセージを強化WM - 仮想ホストの削除時に削除される仮想ホスト名を明示
WM - インストール時にcgi-binのパスにどのようなファイルをインストールしないように修正
WM - RRDメモリグラフのScaleを1000から1024に変更
バグ修正
- file-systemでファイルのアクセスに失敗した場合、異常終了することができたバグ
- WM - origin-exclusion-and-recoveryからCycleと値が互いに変わって保存ていたバグ
1.3.19 (2014.10.21)¶
機能改善/ポリシーの変更
trimmingポリシーの変更
Before. すべてのトラックをTrimmingする。After. Audio / VideoトラックだけTrimmingする。 AllTracksプロパティを介して、既存のように、すべてのトラックをTrimmingすることができる。
1.3.18 (2014.10.15)¶
バグ修正
- DIMS 処理では、クライアントが送信したQueryStringが反映されなかったバグ
- オリジンサーバーの両方が排除されたとき、特定の条件でキャッシュファイルが初期化されなかったバグ
- WM - セキュリティポリシーを強化し、仮想ホスト名にスペースが入らないように例外処理
- WM - Unmountされたディスクの状態を正しく認識していなかったバグ
1.3.17 (2014.09.22)¶
バグ修正
- SNMPWalkを通じてcache-host-traffic-filesystem統計が提供されなかったバグ
- WMを介してDIMS設定時に、その仮想ホストの 検索 が初期化れたバグ
1.3.14 (2014.08.13)¶
- 最大使用メモリを制限するように、 メモリの制限 することができる。
- SNMP - 許可されたCommunity以外にアクセスできないようにcommunityすることができる。
- WM - サービスListenポートをマルチに設定することができる。 クラスタ専用ポートを設定することができる。
機能改善/ポリシーの変更
ファイルインデックスポリシーの変更
Before. 完了したファイルだけをインデックスする。After. ダウンロード中のファイルもインデックスである。emergencyデフォルトOFFに変更
デフォルトのAccessログにsc-content-lengthフィールドの追加
1.3.12 (2014.07.10)¶
機能改善/ポリシーの変更
acl、 第8章 バイパス - 複合条件を設定するときの結合（AND）キーワードを"＆"で"＆"に変更。
Before. $ IP [AP]＆！HEADER [referer]表現可能After. $ IP [AP]＆！HEADER [referer]のように結合条件の間に必ず空白が必要SNMP - bytesHitRatioタイプが負の値を表現できるようにgauge32からintegerに変更
WM - 非対称キー認証ポリシーに変更
バグ修正
- 1MBよりも小さいMP4ファイルをmedia機能にサービスするとき誤動作したり、異常終了された問題
- 異常のHTTP要求の例外処理の強化
1.3.11 (2014.06.19)¶
- 最後（=現在）の設定状態を確認する（/ conf / lastest）APIを追加
機能改善/ポリシーの変更
第8章 バイパス 改善
Before. 明示的なURLまたはCookieなどにバイパス（または例外）の設定After. IP、Header、URLまたはこれを組み合わせた複合条件でバイパス可能。 Cookieバイパス削除します。クライアントのトラフィック - ディレクトリ別requestHitRaio追加
WM - hostnameとIPがログインしていない状態で表示されないように修正
バグ修正
- DNSがResolving応答を正常ますがアドレスが存在しないときに死ぬバグを修正。
- origin.log、filesystem.logローリングする際に、ファイル名がGMT時間で生成れたバグ。 現地時間で生成されるように修正。
- /monitoring/hwinfo APIでディスク使用量が表示されなかったバグ
- WM - 最終アクセス時間が正しく表示されなかったバグ
1.3.10 (2014.06.03)¶
- すべてのDiskが障害排除されたときの動作方式（再投入、Bypass、終了）をstorageできます。
- 元のHTTPリクエストのHostヘッダをクライアントが送信した値を使用するように設定することができます。
機能改善/ポリシーの変更
ファイルキャッシュの監視でQueryStringの特殊文字を含むURLを監視することができます。
第10章 モニタリング＆統計 で5分間の合計量が一緒に表記されます。
HTTP POSTリクエストのキャッシュとBypassポリシーが同時に設定されている場合、サービスポリシーが再確立されました。
Trimmingポリシーの変更
Before. Trimmingの終わり（end）の時間に最も隣接するように分割After. Trimmingの終わり（end）時間の前Key-Frameに分割
バグ修正
- MP4ファイルがサービスされず、CPUを占有していたバグ
1.3.9 (2014.05.21)¶
機能改善/ポリシーの変更
サービス拒否の条件での応答コードを設定することができます。
Before. エラーページに "401 Access Denied"と明示After. 別のページなしに設定され、応答コードのみ応答
バグ修正
- 不適切MP4映像trimmingの異常終了いたバグ。
- WM - Portバイパス設定が反映されなかったバグ
1.3.8 (2014.04.30)¶
- ログがローリングされるFTPに送信するように設定することができます。
- Emergencyモードが発動しないように設定することができます。
- オリジンサーバーのETagを認識するように設定することができます。
- SNMP Communityを設定することができます。
- TTL適用の優先順位を選択することができます。
- HTTPのPOST MethodリクエストのBodyをキャッシュすることに認識/無視するように設定することができます。
バグ修正
- HLS変換中のビデオが割れたバグ。
- 強制的にTTLを有効期限が切れたコンテンツが304 Not ModifiedによりTTLが再び決まる設定上の最大値が割り当てられていたバグ。 設定上の最小値が割り当てられるように変更します。
1.3.7 (2014.04.11)¶
バグ修正
- domain.com:80ようPortが指定されたHTTPリクエストに対して仮想ホストを検出できなかったバグ（v1.3.4〜1.3.6）
- 不適切MP4映像分析の異常終了いたバグ
1.3.6 (2014.04.09)¶
- Access.logをCustomに設定することができます。
- Viewを使用して、仮想ホストを統合して監視することができます。
- コントロールAPI（Purge、Expire、HardPurge、ExpireAfter）の対象がない場合、HTTP応答コードを設定することができます。
機能改善/ポリシーの変更
ログローリング条件
Before. 時間やサイズの選択1After. 時間とサイズの同時設定可能WM - ページの上部にサーバーのホスト名とIPアドレスを表示します。
バグ修正
- WM - 設定ファイルの中でCDATAとして保存された文字列がPlain Textに変わったバグ
1.3.4 (2014.03.26)¶
FileSystemアップグレード
メディア機能（Trimming、HLS、DIMSなど）は、HTTPと同様に動作します。XML / JSON、SNMP、詳細な統計が追加されました。正規表現を使用したURLの前処理が可能です。
システム（OS）のTCPソケットの状態をリアルタイムで監視します。 指標はすべてRRD Graphで提供されます。
仮想ホストがポートをListenしないように設定することができます。
バグ修正
- （FileSystemがMountされているとき）STONの正常終了が長くかかっていたバグ
- WM - （FileSystemを使用していない環境で）新規仮想ホストの追加時FileSystemページを有効にいたバグ
- WM - クラスタ構成の対象WMが一度も実行されていないとすれば設定が適用されなかっバグ
1.3.2 (2014.03.05)¶
- WMを介して最新のバージョンに更新することができます。
- STONのインストール/アップグレード時に進行状況をinstall.logに記録します。
バグ修正
- 不完全な（=リアルタイムで変換されている）MP4ファイルのキャッシュ中のサービスが停止踊っバグ
- WMでクラスタ全体に適用時の仮想ホストのファイルが初期化されたバグ
1.3.0 (2014.02.20)¶
- 第19章 File System 追加- STONをLinux VFS（Virtual File System）でMountます。 オリジンサーバーのすべてのファイルをローカルファイルI / Oとして使用することができます。
- caching追加-設定が変更されるたびに全体の設定を記録します。 API（リスト、ロール、ダウンロード、アップロード）とSNMPを介して閲覧、ダウンロード、アップロード、復元が可能です。
- MP4HLS追加 - 単一のMP4ファイルをHLS（Http Live Streaming）に転送することができます。
- 統計の追加 - 送信中のオリジンサーバーから先にソケットを終了させた回数
機能改善/ポリシーの変更
設定リロードAPIの変更
Before. /conf/reloadall, /conf/reloadserver, /conf/reloadvhostsが別途存在し機能を異にする。After. /conf/reloadで一括統一する。下位互換性のために、既存のAPIを維持する。
v1.2.x¶
1.2.14 (2014.02.06)¶
機能改善/ポリシーの変更
送信元アドレスDNSポリシーの変更
Before. 他の仮想ホストが送信元アドレスとして、同じDomainを使用する場合Domain Resolving結果を共有する。After. すべての仮想ホストは、独立してDomain Resolvingを行い、共有しない。
バグ修正
- WMを通じたDisk Hot-Swap誤動作修正。
1.2.12 (2014.01.02)¶
バグ修正
- 最新NEXUS機器からTrimmingされたMP4 / M4Aが再生されなかったバグを修正。（エラーメッセージ: The player doesn't support this type of audio file.)
1.2.11 (2013.12.20)¶
機能改善/ポリシーの変更
オリジンサーバーCache-Controlヘッダーを認識ポリシーの変更
Before. no-cacheまたはmax-ageだけ認識する。After. no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、private、max-ageを区別して認識する。customは無視する。5分平均Request Hit率の計算方法を変更する
Before. 各TCP_XXXの（単位時間の）平均を求めた後、Hit率を計算する。各平均値が単位時間よりも小さいとき失われることがあります。After. （平均を出さずに）の割合のみ計算して値が欠落していない。
1.2.10 (2013.12.13)¶
機能改善/ポリシーの変更
HTTPS通信では、Accessログの範囲を変更
Before. クライアントがSSL Server Finishedパケットを完全に受信したHTTPSトランザクションだけAccessログに記録する。After. クライアントがSSL Server Finishedパケットを完全に受信していない場合でもHTTP Requestパケットを送信したら、Accessログに記録する。
バグ修正
- 異常終了（物理セッション損失）されたHTTPSセッションが再利用される前に、要求されたコンテンツと、現在の要求されたコンテンツを同時に処理していた症状。2つのHTTP要求を同時に処理することができ、これは常に現在の要求された要求のみが有効になるよう修正。
1.2.9 (2013.12.09)¶
機能改善/ポリシーの変更
Bandwidth-Throttling
Before. Boost時間メディアを転送するときに、ヘッダーを含んでいる。ヘッダが大きい場合、メディアデータが送信されず、バッファリングが発生することができる。After. メディアヘッダーは帯域幅の制限なしで送信する。ヘッダの転送が完了した後、Boost時間が始まる。
バグ修正
- WM ポート変更後STONの更新時に変更されたポートが維持されなかった症状
1.2.8 (2013.11.14)¶
機能改善/ポリシーの変更
- 接続するHTTPクライアントごとに固有の番号（session-id）を付与します。session-idは、AccessログとOriginログに追加され、関連性を推測することができます。
- API호출의 파라미터로 https://... 形式を認識します。
バグ修正
- Content-DispositionヘッダがHTTP応答に2回表示された症状
- Bandwidth-Throttling設定がOFFのときTrimmingが動作しなかった症状
- WMアカウントに特殊文字（＆）使用時のログインアンドゥェドン症状
1.2.7 (2013.10.17)¶
- HTTP Connectionヘッダを設定することができます。
- HTTP Keep-Aliveヘッダを設定することができます。
機能改善/ポリシーの変更
- HTTP応答にConnectionヘッダとKeep-Aliveヘッダを基に設定します。
1.2.6 (2013.10.14)¶
- ソースサーバーの "Server" ヘッダーをクライアントに転送するように設定することができます。
1.2.5 (2013.10.10)¶
- Origin By Clientを設定することができます。
機能改善/ポリシーの変更
- 認識することができるメディアファイルに動的にBandwidth-ThrottlingのBandwidthを設定することができます。v1.2.4まで存在していたMedia.Pacingは、この機能に含まれ、削除されました。
バグ修正
- ごくまれに誤った文字列を参照エラーが原因で異常終了いた症状
1.2.4 (2013.09.27)¶
Bandwidth-Throttlingを介して送信帯域幅を多様に設定することができます。
Warning: 次のバージョンではMedia.PacingはBandwidth-Throttlingに統合されます。メディアファイル（現在MP3、MP4、M4Aサポート）のBitrateをBandwidth-Throttlingで認識することができる形になります。現在は、既存の機能Media.Pacingが優先するように開発されています。仮想ホストごとにクライアント最大Bandwidthを制限するように設定することができます。
ヘッダが背後にあるM4Aファイルをヘッダを前に移しサービスするように設定することができます。
M4Aファイルを必要な区間だけ切り取っサービスするように設定することができます。
機能改善/ポリシーの変更
- 仮想ホストAccessControlの条件に該当するクライアントの要求に対してRedirect（302 moved temporarily）に応答するようにアクセスを制御することができます。HIT率はTCP_REDIRECT_HITに別々に収集されます。
- TCP_REDIRECT_HITがすべての統計に追加されました。
- 仮想ホストAccessControl条件をANDで結合するように設定することができます。
バグ修正
- クラスタが構成されていなかった症状 - IPアドレスを抽出するときLoopbackが抽出れた症状
1.2.3 (2013.09.05)¶
- DIMS(Dynamic Image Management System) - ソースサーバーのイメージを加工（カット、サムネイル作成、サイズ変更、フォーマットの変更、品質コントロール、合成）するように設定することができます。
- MP3ファイルを必要な区間だけ切り取っサービスするように設定することができます。
- 特定のIPだけListenするように設定することができます。
- [WM] 新規仮想ホストを作成する際に、既存の仮想ホストを選択してコピーすることができます。
- [WM] 仮想ホストでDIMSを設定することができます。
機能改善/ポリシーの変更
- 元セッションを再利用しないように設定することができます。
バグ修正
- MP4 Trimming中の異常終了いた症状
- コンソールで変更した仮想ホストの設定がWMのクラスタに反映されなかった症状
1.2.2 (2013.08.16)¶
- HTTP Post要求をキャッシュするように設定することができます。
- STONこのサービスを買う余裕ができない状態にEmergencyに転換される。
機能改善/ポリシーの変更
- サービス許可/遮断条件に否定(!IP, !HEADER, !URL)の条件が追加されました。
- WMとコンソールで同時に設定を変更するときにWMでコンソールで変更した内容を認識するように変更されました。
- WMでIEの "互換表示" メニューを非表示に変更されました。
バグ修正
- CPU過負荷状態でバイパスセッションが正常にクリーンアップされない異常終了いた症状
- （vary設定で）元のサーバーから200 OKで応答していないコンテンツサービスの異常終了いた症状
- 仮想ホスト名とAliasが同じ場合Aliasを削除したときに、仮想ホストを見つけることができなかった症状
- WMクラスタに設定が反映されなかった症状
1.2.1 (2013.07.26)¶
- MP4ファイルを必要な区間だけ切り取っサービスするように設定することができます。
- ソースサーバーからコンテンツを最初にキャッシュしたり、更新したときにRange要求をするように設定することができます。
バグ修正
- WMでクラスタが構成されていなかった症状
- ログの設定を変更した後、 "/conf/reloadserver" APIを呼び出したときに反映されなかった症状
- SNMPでHost平均統計が平均ではなく、合計で計算れた症状
- 特定の状況では、クライアントのトラフィック統計数値が異常に高く計算れたバグ
1.2.0 (2013.07.01)¶
- WMが追加されました。すべての設定がWMを介して可能でMRTG（5種類 - ダッシュボード/ 5分/ 30分/ 2時間/ 1日）が最大18ヶ月分を提供します。WMを介してSTONをクラスタにまとめて簡単に管理することができます。
- Graph APIが追加されました。
- オリジンサーバーのVaryヘッダを認識するように設定することができます。
- クライアントと通信するHTTPリクエスト/レスポンスヘッダを変更するように設定することができます。
- オリジンサーバーのすべてのヘッダーをクライアントに転送するように設定することができます。
- オリジンサーバーでRedirectされたコンテンツを追跡してキャッシュするように設定することができます。
- 特定のURLにのみQueryStringを認識または無視するように設定することができます。
- マネージャーのポートACLごとにアクセス権を設定することができます。
- ログをON / OFFするように設定することができます。
- ローカル通信のログを記録しないように設定することができます。
- ローカル通信の統計情報を収集しないように設定することができます。
機能改善/ポリシーの変更
- ログTraceアクセスがあったとき、ログに記録します。
- ハードウェア情報を照会するときのCPUを高く使用していたバグが改善されました。
v1.1.x¶
1.1.17 (2013.05.27)¶
- Origin By Clientを設定することができます。
機能改善/ポリシーの変更
Transfer-Encodingに送信されたコンテンツを（伝送遅延などの理由で）完全にキャッシュしていない場合は、クライアントサービスポリシーの変更
Before. キャッシュに失敗した現在のコンテンツをサービスAfter. 以前に完全にキャッシュされたコンテンツがある場合は、以前のコンテンツへのサービス。ない場合は、500 Internal Error。
バグ修正
- RefreshExpiredがOFFの状態でPartSizeが0よりも大きく設定されている場合、コンテンツの更新がないバグ
1.1.16 (2013.05.15)¶
機能改善/ポリシーの変更
- Linuxのファイルの最大数の制限にFile I / Oが失敗しないように、ファイルの保存方法を変更する
- 通常の動作のために必要なサブファイルのチェックログを追加
バグ修正
- 更新中のファイルがHardPurgeされる異常終了いたバグ
- 仮想ホストごとにメディアの設定がされていなかったバグ
- syslogの設定が再ロードされなかったバグ
- OriginErrorログにsyslog設定時InfoログにInactiveに表示されたバグ
1.1.15 (2013.04.29)¶
- CPU 性能指標（Nice、IOWait、IRQ、SoftIRQ、Steal）統計を追加
バグ修正
- Track情報が多くMP4ファイル解析中異常終了いたバグ
- HTTP Transfer-Encodingされたコンテンツを転送するときに遅延れたバグ
1.1.14 (2013.04.10)¶
- SNMPに全体の "仮想ホストの合計"が追加されました。
機能改善/ポリシーの変更
(ファイルが存在しないとき) GeoIPファイルリスト照会結果を変更
Before. 404 NOT FOUNDAfter. 200 OK ("files": [] 応答)
バグ修正
- SSLv3でRSA_WITH_3DES_EDE_CBC_SHAでHandshakeがされなかったバグを修正
- Httpsに空の文字列入力時誤動作したバグ
1.1.13 (2013.03.29)¶
バグ修正
- ディレクトリごとの統計が設定された状態で、累積統計がOFFの場合、異常終了していた症状
- 初めてアクセスされるコンテンツは、元のサーバーからの応答を受信する前Purgeされる場合は、クライアントへの応答を与えなかった症状
- HTTPリクエストのURIが相対アドレスではなく、絶対アドレスの場合、サービスアンドゥェドン症状
1.1.12 (2013.03.27)¶
- No-Cacheリクエストが来ている場合、要求されたコンテンツをすぐに期限切れにさせるように設定することができます。
- CentOSパッケージにopenSUSEでインストールすることができます。
機能改善/ポリシーの変更
No-Cacheリクエスト認識条件を変更
Before. "pragma: no-cache" または "cache-control: no-cache"After. 既存の条件に "cache-control: max-age=0" を追加
バグ修正
- DNS更新時異常終了いた症状
- 最大ファイル数を渡るときにURLにVertical Bar(|)があるファイルが削除されなかった症状
- HTTP要求がバイパスされるHttpReqBodySizeとClientInbound値が正しくなかった症状
1.1.11 (2013.03.21)¶
- Disk障害条件を設定することができます。障害と判断されたディスクは、自動的に排除されます。
- Disk HotSwap用（実行中のディスク交換）APIが追加されました。
- ログをsyslogに送信するように設定することができます。
- 元のサーバーから一度にダウンロードされたコンテンツのサイズを設定することができます。
- GeoIPファイルリスト照会APIが追加されました。
- FAQに "マルチドメインのSSLを構成するには？" この追加されました。
機能改善/ポリシーの変更
ソースサーバーの障害コードの変更
Before. 数字で表示After. 読みやすい形式で表示(Connect-Timeout, Receive-Timeout, Server-Close)元のサーバー障害ログ記録時のコメントでエラー状況を記録していたことを取り除く。OriginErrorLogに統合。
バグ修正
- Manager Port変更後Reloadするとき異常終了されたバグの修正
1.1.10 (2013.03.07)¶
仮想ホストごとにアクセス/ブロック条件(IP, GeoIP, URI, Header)を設定することができます。関連統計が追加されました。
ドメインResolvingが失敗した場合、最近使用されたIPをすべて使用して、元のサーバーの負荷を分散するように設定することができます。
監視APIが追加されました。
仮想ホストのリスト参照ハードウェア情報照会HTTPS CipherSuite 照会アクセス遮断条件（acl.txt）照会Expiresヘッダの条件（expires.txt）照会
機能改善/ポリシーの変更
ログディスクの空き容量が不足する場合は、ポリシーの変更
Before. 介入しない。管理者が明示的に削除する必要がある。After. Accessログだけ削除します。もし現在使用中のログを消去する状況であれば、新しいログを作成した後削除。STON 終了後（vhosts.xmlから）削除された仮想ホストファイルのポリシーの変更
Before. 介入しない。管理者が明示的に削除する必要がある。After. ディスクの空き容量が不足すると、優先的に削除します。(仮想ホスト別) 再起動時に正常にロードされていないディスクのファイルへのポリシーの変更
Before. サービスの自然上書きされるように残しておくAfter. そのディスクを信頼することができないと判断してすべて無効に。クリーンアップ時間やディスクの空き容量が不足時点ですべて削除します。ドメインResolving結果照会APIの変更。
Before. /dns/listAfter. /monitoring/dnslistログトレースAPIの変更
Before. /logtrace/...After. /monitoring/logtrace/...ドメインResolving結果にバックアップされたIPのリストを追加
1.1.9 (2013.02.27)¶
- mod_expiresのようにExpiresヘッダを設定することができます。
- HTTPSのCipherSuiteを設定することができます。
- ファイルを管理(Purge/Expire/HardPurge/ExpireAfter)したときに、単一のURLを入力しても、QueryStringまですべて管理するように設定することができます。
- ETagヘッダを表示するかどうかを設定することができます。
- Ageヘッダを表示するかどうかを設定することができます。
機能改善/ポリシーの変更
HTTPS CipherSuiteが追加されました。
RSA_WITH_RC4_MD5TLS_RSA_WITH_3DES_EDE_CBC_SHA数字（秒= sec）のみだった表現を認識しやすい文字形式で表現可能
Before. /image/ad.jpg, 1800After. /image/ad.jpg, 6 hoursSNMPでの平均にのみ提供していた数値を累積的に提供（クライアント/ソース）
既存のCountという表現をAverageに変更。Averageは時間で割った平均を意味時間集計された合計数はCountで表現全体の要求/応答数を追加応答コード別の応答/終了数を追加Request Hit Count追加再起動/シャットダウン/キャッシュの初期化APIを呼び出すときに、 "確認" のプロセスなしで呼び出すことができます。
システムLoad Average - 1分/ 5分/ 15分の統計を追加
すべての仮想ホストの送信元サーバーを初期化することができます。
バグ修正
- Domain Resolving結果が変更されたときに、複数の仮想ホストに同時に反映さアンドゥェドンバグを修正
- Purge / ExpireでQueryStringがついているURLが処理できなかったバグを修正
1.1.8 (2013.02.21)¶
- クライアントの要求が常に同じ送信元サーバーとしてバイパスするように設定することができます。
- ドメインResolving結果を監視することができます。
- ドメインResolving結果が更新されたときにInfoログに記録するように設定することができます。
- ソースサーバーの使用と排除/回復状況を初期化することができます。
- Clean-up時間に一定期間アクセスされていないコンテンツを削除するように設定することができます。
- Clean-upを実行するAPIが追加されました。
機能改善/ポリシーの変更
Originログ強化
接続したポートの記録BypassとPrivateBypass区分可能ソースサーバーが送信されるContent-Encodingヘッダ記録Accessログ強化
クライアントが送信されるAccept-Encodingヘッダ記録BypassとPrivateBypass区分可能ソースサーバーがドメイン名に設定されているときに機能改善
Resolving結果がすぐに反映さ。| IPらに対し個別に排除/回復。
Purge/Expire/HardPurge/ExpireAfter呼び出しの結果応答コードの修正
正常。 200 OK仮想ホスト無し。 502 BAD GATEWAY不適切規格。 400 BAD REQUESTFAQのページを更新
ソースサーバーの使用/排除/回復ポリシーは？ディスクの空き容量はどのように保証できますか？
バグ修正
- ディスクの空き容量が不足してもスペースの確保がされていなかったバグを修正
1.1.7 (2013.02.16)¶
機能改善/ポリシーの変更
- Cent OS 5.5以上とUbuntu 10以上で同時接続ソケットが10万を超えると、システムのパフォーマンスが低下し、ソケットの処理が失敗している症状を確認しました。したがって、最大ソケットを10のみに制限します。
バグ修正
- 使用中のソケットが設定された最大ソケット数を超えたときの増設されなかったバグの修正
- Byte Hit Ratio結果が不正確に表示されたバグの修正
- 累積統計XMLでClientSessionが2回出てきたバグを修正。（ClientActiveSessionに変更）
- "abc*"にパターン設定した場合、 "abc"のようにパターン部分が空の文字列を認識していなかったバグを修正
1.1.6 (2013.01.30)¶
- ソースサーバーがマルチで構成されているときは、常にサーバーに同じように要求するように設定する。
機能改善/ポリシーの変更
ソースサーバーの負荷分散ポリシーがSessionでRoundRobinに変更されました。
グローバルログ（Info、Deny、OriginError）を時間的にローリングさせる。
Before. サイズのみローリング可能(Size属性のみ存在)After. 間/サイズでローリング可能 (Sizeプロパティを削除。Type、Unit属性の追加)無効な形式または存在しない仮想ホストを対象にPurge / Expire / ExpireAfter / HardPurge呼び出し時の応答コードを変更する
Before. 200 OKAfter. 400 BAD REQUEST または 404 NOT FOUND
バグ修正
- v1.1.5から元サーバーのアドレスのリストを変更して再ロードしたときに、断続的に異常終了いた症状
- 元のサーバーでトランザクションの完了回数を収集する際にContent-Lengthが0である応答がないていた症状
1.1.5 (2013.01.28)¶
- クライアントごとにバイパス専用のセッションを使用するように設定します。GETリクエストやPOSTリクエストを個別に設定することができます。
- クライアントCookieヘッダーに基づいてバイパスするように設定します。
機能改善/ポリシーの変更
元サーバーのアドレスが落ちるときの動作方法を変更する
Before. すでに接続されている場合は、再利用する。After. すぐに再利用していない。QueryStringを区別するように設定されたときPurge / Expire動作方法を変更する。
Before. 入力されたURLとそのURLにQueryStringがついたコンテンツPurge / ExpireAfter. 入力されたURLのみPurge / ExpireActiveセッション算出方法の変更
Before. 統計を抜く時にデータ転送が行われているセッションAfter. データ転送が発生したUniqueたセッション統計/パフォーマンスデータが追加/削除されました。
System統計を追加総合統計要請回数、Activeセッション統計を追加SSLクライアントセッションの数を削除
1.1.4 (2013.01.17)¶
- HTTPSをIPとPortに別の方法で結合することができます。
機能改善/ポリシーの変更
- 64GB機器でFreeメモリポリシーが16GBに変更されました。（前: 8GB)
- HTTP Methodをサービスポート（80）に呼び出すことができます。
- グローバル設定（server.xml）のHTTPSの設定が変更されなくてもリロードするとき、証明書ファイルが変更された場合に反映します。
1.1.3 (2013.01.15)¶
機能改善/ポリシーの変更
- 一度に記録することができるログの最大サイズを10MBに拡張（以前: 2KB)
- POSTで送信するURLのサイズを最大1MBに拡張（以前: 10KB)
バグ修正
- ログが時間あたりのローリングされるファイル名（日）が正確ではなかった症状
1.1.2 (2013.01.14)¶
- GeoIPでアクセス制御が可能です。クライアントが接続するとき、国コードで接続をブロックすることができます。
- アクセスブロックされたIPアドレスをdeny.logに記録します。
- ログを動的に変更することができます。
- AccessログキャッシュHIT結果（TCP_HIT、TCP_MISS、...）を追加
- 管理用HTTP Methodが追加されました。
- POSTを使用してPURGE、HARDPURGE、EXPIRE、EXPIREAFTERすることができます。
- stonapiを全体/一部のドメインを初期化することができます。
- APIのリストを閲覧するHelpコマンドを追加
機能改善/ポリシーの変更
ETagヘッダを提供する際に二重引用符("...")で囲んで表記
HIT率計算式を変更
Before. すぐに応答/すべての応答After. (TCP_HIT + TCP_IMS_HIT + TCP_REFRESH_HIT + TCP_REF_FAIL_HIT + TCP_NEGATIVE_HIT) / すべての応答統計/パフォーマンスデータが追加/削除されました。
平均統計統計を作成した日付/時刻を追加クライアントからSTONに接続/終了する統計の追加STONが元のサーバーに接続/終了する統計の追加System 追加"Cached" 統計の削除正規表現のパフォーマンスを向上 (X 20)
fileinfoから米キャッシュファイルである場合statusを "OK"で "NOT_CACHED"に変更
バグ修正
- SNMPでディスク情報（diskInfoPath、diskInfoStatus）を得たときにDisk数よりも大きな値がdiskIndexに入力されると、異常終了いた症状
- ディスクがいっぱいになる前に削除されなかった症状。ディスクAvailableスペースを空き領域として理解するように修正
- stonapiが管理ポートを認識していなかった症状
- Infoログに "Download-Range" メッセージを削除
1.1.1 (2012.12.24)¶
- すべての仮想ホストのソースサーバー上の動作を一つのファイル（originerror.log）に記録する。
- HTTP Multi-Range要求を処理することができます。
- ソースサーバーでno-cacheに応答しても、クライアントにはmax-ageを与えるようにTTLを設定することができます。
機能改善/ポリシーの変更
Accept-Encoding処理ポリシーの変更。
Before. クライアントと元サーバの圧縮に互換性がない場合は、500エラーで応答する。After. クライアントと元サーバの圧縮に互換性がなくても、元のサーバーの応答を送る。次のように統計/パフォーマンスデータが追加されました。
ソース/クライアントのActiveセッション数が追加されました。STONが使用するCPU（Kernel、User）性能の数値が追加されました。
バグ修正
- (設定: TTL=0, RefreshExpired=ON) 元のファイルが変更されたとき変更されたファイルの最初の応答コードを500に送った症状
1.1.0 (2012.12.17)¶
- 仮想ホストごとに最大Outboundを制限するように設定することができます。
- ヘッダが背後にあるMP4ファイルをヘッダを前に移しサービスするように設定することができます。
- MP4のBitrateだけ低帯域幅で送信するように設定することができます。
- 最大のサービスファイルの数を設定することができます。
- 最大HTTPセッション数を設定することができます。
- APIのすべての関数を、Linuxコンソールから呼び出すことができます。
- Log-Trace APIを介して記録されたログをリアルタイムで受け取ることができます。
- シェルでSTONを更新することができます。
機能改善/ポリシーの変更
メモリポリシーが変更されました。最大ファイル数と最大ソケット数を設定して、コンテンツメモリのサイズを変更することができます。
ドメインをリジョルビング（Resolving）した結果をキャッシュします。少なくとも1秒、最大10秒間キャッシュされます。
OriginOptionsのいくつかの設定（user-agent、host、WL-Proxy-Client-IP、xff-x-forwarded-for）をバイパスされるHTTP要求に選択的に適用することができます。
ソースサーバーから5xx系の応答コードがキャッシュされた場合、TTLが期限切れになるとRefreshExpiredがOFFであっても、常に元のサーバーから更新するかどうかを確認し、サービスします。
ソースサーバーにexample.com/dir1ようディレクトリ名をように指定することができます。クライアントが/test.jpgに要求する場合、元のサーバーに要求するアドレスはexample.com/dir1/test.jpgになります。
ファイルキャッシュの監視項目が強化されました。
ソースサーバーアドレスがドメイン名であれば、個別に<Host>を設定しなくても、ドメイン名でHostヘッダを送信するように修正しました。
次のように統計/パフォーマンスデータが追加されました。
ソース/クライアントのHTTPリクエストの数が統計に追加されました。正常に終了し、元のクライアント/ HTTPトランザクションの統計が追加されました。CPUとMemoryの統計情報が追加されました。Diskごとのパフォーマンス指標が追加されました。ソースログにcs-acceptencoding、sc-cachecontrolフィールドが追加されました。
バグ修正
ソースサーバー排除/回復過程（アドレス3個以上）で、後順位のソースサーバーが優先回復された時、異常終了いた症状
HTTPリクエストヘッダーがキーと値の間にスペースがない場合、解釈できなかった症状
ログを "Size"に設定したとき、中間ファイルが先にローリングされて削除いた症状
以下の状況での応答を与えなかった症状
Aファイルを元のサーバーに要求したが、404 Not Foundが発生Memory Swap過程の中でAファイルのBodyをMemoryから削除（AファイルはMetaだけ存在する状態になる）Aファイルサービス要求が入ってくるAファイルがサービスのためにBodyをLoadするしたが失敗しました。ファイルの初期化を実行Aファイルは、元のサーバーにダウンロードを進めようとしたが、元のサーバー排除に失敗する以後Aファイルは、初期化時に失われてしまって初期化状態で存在する次の状況では、Expire / Purgeが成功したかのように出てきて更新されなかった症状
Aファイルをバックグラウンドで更新しようとする元のサーバーからHTTP応答を受けた伝送遅延が発生する伝送遅延に接続が終了するか、セッションが異常終了した時、更新の失敗が正しくクリーンアップされていない状況が発生する
v1.0.x¶
1.0.17 (2012.11.29)¶
- HardPurge APIが新規に追加されました。HardPurgeしたコンテンツは、完全消去を意味します。修復が不可能です。
- 仮想ホストごとにクライアントKeep-Alive時間を設定することができます。
1.0.16 (2012.11.28)¶
SNMPWalkが動作するようにSNMPの機能が全体的に修正されました。
SNMPの[min]変数の初期値を設定することができます。SNMPWalkは設定値を参照して、[min]変数を設定します。全仮想ホスト名を付けて提供していた設定（VHostList）が削除されました。いくつかのOID値が拡張できるように再調整されました。ルート（/）ディレクトリのPurge / Expireを防ぐように設定することができます。
1.0.15 (2012.11.22)¶
- 通常のキャッシュ（200 OK）されているファイルを更新する過程で、元のサーバーから4xx応答を受けたとき、まるで304 not modifiedを受けたかのように動作するように設定します。これにより、サーバーの一時的な障害からのコンテンツを更新する行為を防止することができます。
- コンテンツの有効期限を強制的に指定するExpireAfter APIが追加されました。
- ソースサーバーのアドレス、ポートがように宣言されている場合は、ポートバイパスがされていなかった問題が修正されました。
- 累積統計がONである状態で、ポートバイパス統計を集計すると異常終了された問題が修正されました。
1.0.14 (2012.11.15)¶
- ディレクトリ毎の統計情報を設定したとき、統計監視中異常終了することができる問題が修正されました。
- カスタムTTLの変更が適用されなかった症状が修正されました。カスタムTTLは、すぐに反映されず、TTLが期限切れになる時点で再適用されます。
1.0.13 (2012.11.12)¶
- キャッシュされたファイルを最初に変更の確認（If-Modified-Since）にアクセスする場合は、ファイルが正常に初期化されなかったバグが修正されました。このバグにより、最初の応答時に500 Internal Errorを送信したり、TTLが非常に短く設定されている場合は、ファイルの有効性が問題になることがあります。
- 断続的に、元のサーバーからコンテンツが変更されていなくても（304 Not Modified）最初のアクセスしているクライアントを無条件200 OKで処理していた症状が修正されました。
- 通常のキャッシュ（200 OK）されているファイルを更新する過程で、元のサーバーから5xx応答を受けたとき、まるで304 not modifiedを受けたかのように動作するように設定します。これにより、サーバーの一時的な障害のためのコンテンツを無効化して、元のサーバーのトラフィックを加重させる行為を防ぐことができます。
- SNMPからの応答受信仮想ホストの最大数を設定することができます。
1.0.12 (2012.11.05)¶
- 要約統計の数値（元のトラフィックは、セッション）が合わなかった症状が修正されました。
1.0.11 (2012.10.31)¶
- 元のサーバーが排除された状況では、Purge / Expireが動作しません。
- 特定のPurgeコマンドがExpireで動作するように設定することができます。
1.0.10 (2012.10.29)¶
- 元のサーバーが排除された状況で、POSTリクエストがクライアントセッションから欠落していた症状が修正されました。
- ソースサーバーの障害が原因でPurgeされたコンテンツを復活させる過程で、まだディスクに保存されていないコンテンツを初期化していた症状が修正されました。
1.0.9 (2012.10.22)¶
- ソースサーバーHTTP応答のContent-Dispositionヘッダを認知するように修正されました。
1.0.8 (2012.10.19)¶
- ソースサーバーからTransfer-Encoding：chunkedオプションで応答を与えるとき、クライアントにContent-Lengthを与えないように修正しました。
- クライアントのIf-Rangeヘッダを認知するように修正しました。
1.0.7 (2012.10.18)¶
- HTTPリクエストのHostフィールドに仮想ホストを検索するとき、大文字と小文字を区別しないように修正されました。
1.0.6 (2012.10.12)¶
- SSLv2 ClientHelloを認識するようになりました。
- バイパス中ソースサーバーが最初に接続を終了したとき誤動作した症状が修正されました。
1.0.5 (2012.10.08)¶
- ソースサーバーの要求時に値が存在しないQueryString項目が欠落していた症状が修正されました。
1.0.4 (2012.10.04)¶
- 元のサーバーのログにQueryStringを記録していなかった症状が修正されました。
1.0.3 (2012.09.28)¶
- 設定ファイルを再ロードしても、OriginOptionsのHost設定が反映されなかった症状が修正されました。
1.0.2 (2012.09.27)¶
- 設定ファイルを再読み込みした後、Custom TTL設定が適用されなかった症状が修正されました。
1.0.1 (2012.09.20)¶
- QueryStringの設定がONの場合、Purge / Expireが過度にCPUを占有していた問題が改善されました。
1.0.0 (2012.09.18)¶
- 設定ファイルを動的にReloadすることができます。サービスを中断せず、仮想ホストの追加、削除、変更が可能です。
- ハードディスクの最大使用量を設定することができます。設定しなくても、常にディスクがいっぱいになってないように管理されます。
- 仮想ホストの順序が変更されても、常に同じSNMPのOIDで統計情報を収集することができるように、仮想ホストのOIDを設定することができます。
- AccessログをApacheとMicrosoft IIS形式に設定することができます。
- HTTP応答にViaヘッダーを挿入を設定することができます。
- クライアントのAccept-Encodingを無視するように設定することができます。
- コンソールまたはAPIを介してSTONバージョン確認が可能です。
- APIを介して設定ファイルの閲覧が可能です。
- 元のサーバーのログにQueryStringを記録します。
- SSLを使用しHTTP Post要求バイパスが誤動作したバグが修正されました。
- 仮想ホストサービスポートの設定が<Address>で<Listen>に設定された。
- 仮想ホストごとにディスクの設定を個別に行うことができません。すべての仮想ホストは<Storage>を介してディスクを共有するように設定しました。
- Infoログが見やすい形式に変更されました。
- fileinfo応答の時間表現が "2012.09.03 14:29:50" のように読みやすい形に変更されました。
v0.9.x¶
0.9.6.7 (2012.08.23)¶
- バイパス中のソースとクライアントのセッションが同時に切断されるSTONが異常終了していたバグを修正
- ソースサーバーが "Transfer-Encoding: chunked"で応答を与えるときReceive Timeoutが短く指定されたバグの修正
- APIレスポンスのMIMEタイプをapplication / jsonでは、text / plainに変更
0.9.6.6 (2012.08.01)¶
- 特定のIPのサービス（仮想ホスト）へのアクセスをブロックまたは許可するように設定することができます。
- ソースサーバーが過負荷状態と判断されると、有効期限が切れたコンテンツのTTLを元のサーバーに要求していない更新します。
- GETリクエストのデフォルトの動作を元のサーバーにバイパスするように設定することができます。
- Originログにバイパスされた要求であるか記録します。
- バイパスセッションのTimeout時間を設定することができます。
0.9.6.5 (2012.07.17)¶
- ソースサーバーをActive / Standbyに設定することができます。
- AccessログにクライアントのRangeフィールド（cs-range）を追加
- HTTP要求がInvalid Rangeを要求した場合の動作方法を変更しました。従来は、ファイルサイズを超えてRange要求は無条件416 Requested Range Not Satisfiableで処理された。今回のバージョンから終了オフセットがファイルサイズよりも大きい場合206 Partial Contentで処理されます。開始オフセットがファイルサイズよりも大きい場合は、既存のと同じように処理されます。
0.9.6.4 (2012.07.12)¶
- HTTP POSTリクエストの処理時に異常終了された問題を修正しました。
- HTTP POSTリクエストの送信元サーバーバイパスするかどうかを設定することができます。
- ソースサーバーのHTTP応答Content-Typeヘッダが明示されていない場合は、クライアントにもContent-Typeヘッダを与えません。（従来はtext / htmlに設定）
0.9.6.3 (2012.07.11)¶
- HTTPS要求を元のサーバーにバイパスすると、不適切なメモリ参照により誤動作/異常終了された問題が修正されました。
- 透明（Transparent）モードをサポートします。STONとソースサーバーのネットワーク区間の間に、元のサーバーの応答をSTONに転送する設定が必要です。
- Expiredされたコンテンツをサービスする前に、必ず元のサーバーで確認することができます。
- もはやURLBypass統計を別途収集しません。ソース/クライアントのトラフィックの統計情報に統合されました。
- IBM WebLogicクライアントAccessログを残すことができるようWL-Proxy-Client-IPヘッダを追加することができます。
- ソースサーバーに送信HTTPリクエストのX-Forwarded-ForヘッダのクライアントIPの後に設定することができます。
- エラーページ（500 Internal Error）でエラーの理由を表示します。
- 設定で、文字列の空白を削除していなかった問題が修正されました。すべての文字列の左右のスペースは削除されます。
0.9.6.2 (2012.06.19)¶
- キャッシュされていないファイルの最後の部分をRange Requestたとき（Rangeの範囲が1024 Bytes未満）のデータが転送されなかったバグを修正
0.9.6.1 (2012.06.14)¶
CacheClear機能を追加 - に設定され、すべてのディスクを削除します。STONのすべてのサービスは中断され、処理が完了した後、自動的に再開されます。
ログファイルのOriginOptionsのHost設定漏れが修正されました。
ログファイルのOptionsの設定表現が "TTL"から "Options"に変更されました。
0.9.6 (2012.06.12)¶
- SNMP（Simple Network Monitoring Protocol）をサポートします。STONは常に実行パスにMIB（Management Information Base）ファイルを生成します。STONのSNMPは、仮想ホスト別、リアルタイム、最近1〜60分までの統計を提供しています。最初の実行時に無効にされており、server.xmlを編集して活性化させることができつなぎます。
- 元のサーバーでContent Lengthない答えが来る場合は、Originログにソースサーバーエラーとして記録しないように変更されました。ソースサーバーから一方的に接続を終了した場合には、もしそのセッションがContent LengthがないHTTPトランザクションを実行しているとすれば、元のエラーとして記録されません。
Appendix E: リリースノート [Enterprise]¶
v18.x¶
18.05.1 (2018.5.29)¶
機能改善/ポリシーの変更
- MP4 HLS - キーフレームの間隔が不規則な映像の互換性を強化
警告
以前のバージョンと MP4 HLS のMPEG2-TSは互換性がありません。
バグ修正
- handling_http_requests_header_lastmodifiedcheck -
orlaterに設定する場合、最初のキャッシュ時に304応答をすることができる問題を修正
18.05.0 (2018.5.15)¶
- クライアントの要求 handling_http_requests_header_if_range ヘッダサポート
- 元の要求時 origin_header_if_range ヘッダサポート
- handling_http_requests_header_lastmodifiedcheck 設定機能を追加
- bypass-put 機能を追加