ページの先頭です


ページ内移動用のリンクです

キャッシュエンジンの比較(2/3)

2012年6月19日

前回は、キャッシュサーバに期待される役割と、キャッシュサーバやキャッシュエンジンについて説明をしました。ここでは、そのうちの3つのキャッシュエンジン、Varnish Cache、Apache Traffic Server、nginxについて、IIJで行った比較実験の結果を交えて更に詳しく説明します。

キャッシュエンジンの比較

まずは、Varnish Cache、Apache Traffic Server、nginxの各機能についての比較表です。

Varnish Cache Apache Traffic Server nginx
スレッド方式 ×
マルチプロセス ×
イベント駆動
キャッシュ削除機能 ×
Internet Cache Protocol(ICP) × ×
Edge Side Include(ESI) ×
Request Consolidation
複数のオリジンサーバを指定できる ×

Varnish Cache

Varnish Cacheは、前回述べたVCLという設定ファイルの記述方法において、下記のような特徴があります。

  • 設定ファイルの動的読み込み
  • インラインCによる設定
  • Varnish Modules(VMODs)による拡張
  • probeによるオリジンサーバのヘルスチェック

まず、Varnish CacheではVCLで記述された設定ファイルをC言語として解釈します。設定をC言語として解釈した後に設定ファイルをコンパイルし、共有ライブラリを作成します。最終的には、Varnish Cacheが設定ファイルから生成された共有ライブラリをリンクすることで、設定が反映されます。このような実装により、Varnish Cacheではプログラムを作成する感覚で、柔軟性に富んだ設定ファイルを作成できます。また、コンパイルした結果をリンクさせているため、全体的に速度向上を期待できるというメリットもあります。

更に、Varnish Cacheでは様々なツールが提供されており、ソースコードからコンパイルしただけで、キャッシュのヒット率やCLIによるコンソールなどが使用できます。

ただし、他のキャッシュサーバプロダクトではキャッシュの永続性が保たれるのに対し、Varnish Cacheではキャッシュの永続性が保たれません。つまり、Varnish Cacheではプロセスの再起動が発生すると、直前まで貯めていたキャッシュを忘れてしまいます。キャッシュに永続性を持たせるために、キャッシュストレージのオプションとしてpersistentが用意されていますが、使い勝手が良いとは言えません。

Apache Traffic Server(ATS)

ATSは前回紹介した機能のほかに、下記のような特徴を持っています。

  • Split DNS
  • キャッシュ領域におけるRaw Disk(未フォーマットのドライブ)の使用
  • Web UIによるキャッシュ操作
  • CLIによる設定変更
  • Internet Cache Protocol(ICP)に対応

Split DNSでは、オリジンサーバを指定する時などにシステムで使用しているDNSサーバではなく、ATSのみで使用できるDNSサーバを指定できます。名前検索のオーバヘッドを招くことになりますが、オリジンサーバの変更でATS側への操作が必要なくなるため、運用時の負荷の低減が期待できます。また、名前検索のオーバヘッドを軽減するためにHost DBという機能も実装されています。

また、キャッシュしたコンテンツの保存領域として、未フォーマットのディスクドライブをRAW Diskとして指定できます。RAW Diskは様々なオーバヘッドを除いた状態で使用できるため、処理速度の維持とキャッシュ領域の容量の確保を両立できます。効果は、SSDなどの高速なデバイスをRAW Diskとして使用したときに感じられます。

ATSは、設定内容や稼働状況の確認などのために簡単なWeb UIを提供しており、これを使用してキャッシュ済みオブジェクトの検索と削除ができます。なお、ATSには、設定ファイルが種類ごとに複数あるため管理が煩雑になりやすい、という問題があります。これを解決するには、「traffic_line」というCLIコマンドを使用し、ATSを止めずに設定の変更と設定ファイルの更新をします。ただし、一部の設定項目にはこのコマンドが対応していないため、設定ファイルを直接書き換える必要があります。

更に、ATSは紹介している3つプロダクトの中で唯一、Internet Cache Protocol(ICP)に対応しています。ICPは同一のpeerに所属しているノード間でキャッシュの状況を共有し、効率よくキャッシュを保持する仕組みです。他にもクラスタリングの機能を実装しているため、効率よくキャッシュすることが期待できます。

以上、Varnish Cache、Apache Traffic Serverについて、IIJで行った比較実験の結果を紹介しました。次回は、nginxについて取り上げます。

渡辺 道和

執筆者プロフィール

渡辺 道和(わたなべ みちかず)

IIJ プロダクト本部 基盤プロダクト開発部 配信技術課
2011年に入社。IIJ大規模コンテンツ配信サービスの「中の人」として小さく吸って大きく吐く、をモットーに運用と開発に携わる。

関連リンク

  • 最新の技術動向 「Webサーバの性能を測る」
    UNIX系のOSで利用できるWebサーバの性能測定ツールといえば、Apache Benchやhttperfを思い浮かべる人が多いのではないでしょうか。これらの計測ツールは、残念ながら最近の高速なWebサーバを計測するには非力です。この記事では、高速なWebサーバにも負けないweighttpの使い方を紹介します。 (2012年12月18日)
  • IIJ Technical WEEK 2012 講演資料 「リバースプロキシプロダクトの比較」 [PDF:1.78MB]PDF
    大規模なWebサイトではリバースプロキシを使用し、コンテンツの配信効率の向上を目指しています。本講演では、IIJホームページに掲載した「最新の技術動向」の「キャッシュエンジンの比較」の連載で紹介しきれなかった細かい内容などをご紹介します。 (2012年11月16日)
  • 最新の技術動向 「キャッシュエンジンの比較(1/3)」
    大規模なサイトでは、クライアントからのアクセスを効率よく受け付けるためにオリジナルのコンテンツを保持するオリジンサーバのほかに、何らかのリバースプロキシも運用してコンテンツの配信をしています。まず、ここではリバースプロキシとして利用できるプロダクトの中からコンテンツキャッシュの機能(キャッシュサーバ)について説明します。 (2012年6月12日)
  • 最新の技術動向 「キャッシュエンジンの比較(3/3)」
    前回前々回は、キャッシュサーバに期待される役割と、キャッシュサーバやキャッシュエンジン、特にVarnish Cache、Apache Traffic Serverについて、IIJで行った比較実験の結果を交えて詳しく説明しました。最後に、nginxについて取り上げます。 (2012年6月26日)
  • 最新の技術動向 「高速WebサーバMighttpdのアーキテクチャ」
    IIJ-II技術研究所では、2009年の秋からMighttpdblank(mightyと読む)というWebサーバの開発を始め、オープンソースとして公開しています。この実装を通じて、マルチコアの性能を引き出しつつ、コードの簡潔性を保てるアーキテクチャにたどり着きました。ここでは、各アーキテクチャについて順を追って説明します。 (2012年5月29日)

ページの終わりです

ページの先頭へ戻る