使える!サーバ運用の実践テクニック

第12回 [キャリアアップ編④]varnishを使おう②─特定のコンテンツを配信するために

この記事を読むのに必要な時間:およそ 2 分

varnish2.1.4が発表されたようで,一部ユーザの間ではリリースノートから新しい機能について解読,評価したりと盛り上がっているようです。

キャッシュシステムは,比較的トラフィックが大きなシステムで検討されるものかもしれませんが,varnishをはじめ,squidなどでも比較的簡単に実装できるため,⁠今はそんなにトラフィックがないので」というシステムでも積極的に評価し,トラフィックの少ないうちであればなおさら適用する事をお進めします(httpサーバ等との同居でも十分に効果が得られる事もあります)⁠

筆者の経験上,クリスマス,年末年始,あるいは,昨今のSNSのように,爆発的なトラフィックは突然やってきます。

今回も,今までキャッシュシステムに無関係だったり,新しくインフラ関連の仕事に就いた人で概念が理解できる事を目標に,キャッシュの仕組みはvarnishを使う前提で,特定のコンテンツだけをvarnishに向けたりと,いくつかのシチュエーションを考えてみようかと思います。

多段キャッシュ構成の基本

前回は,varishを親子階層に定義する所まで説明したかと思います(図1)⁠

図1 前回の構成

画像

これを親子関係がわかりやすい図(シーケンスイメージ)で記載すると,図2のようになります。

図2 構成図(多段)イメージ

画像

①balance

HTTPなどのリクエストを受け付け,適切なサーバへ割り当てます。大規模,高負荷システムの場合,この機器自体がL7の分散機器であったり,分散方法もLVS等ではなく,(2)Cacheサーバのヘルスをウォッチし,適切なロード分散を行うミドルウェアなど,トラフィックの規模に応じて検討します。

②Cache #1

多段キャッシュ構成では「子」に位置します。

varnishの場合「子」が独立してしまうなど,ミドルウェアによって違いが出てくる部分でもありますので,システムに適したミドルウェアや運用を検討する部分でもあります。

③Cache #2

多段キャッシュ構成では「親」と位置付けられます。この「親」サーバでリクエストが解決できない場合,実際のAPサーバへ問い合わせを行います。

②でも記載しましたが,varnishの場合は図2で言えば水平(横)にの動きに対しては大変パフォーマンスが良いのですが,垂直(縦)の動きに対してはかなりクセがあるというか,varnish以外の方法も含めて検討が必要です。これらに関しては後述します。

④Origin

実際のAP(アプリケーション)サーバになります。たとえば静止画像のみをvarnishでキャッシュするとした場合,htmlやスクリプト系のファイルはAPサーバに存在しますので,最初のhtmlファイルのリクエストは直接このサーバにアクセスし,html中に記載されている静止画像等のパス(URL)がLVS(varnish側)へリクエストされれば良いことになります。これらの構成を「コンテンツキャッシュ」⁠外に散らす」などと言われることがあります。

アニメ風に解説すると以下の通りになります。

  1. まず「client」から「http://gihyo.jp/」にアクセスしたとしましょう。
  2. gihyo.jpでは,⁠index.html」などのテキスト形式のhtmlを返します。
  3. 再び「client」では,レスポンスで得た「index.html」ファイルを(ブラウザが)解読します。
  4. 複雑な処理は割愛して,サイトを表示するための画像ファイルは以下のように記載されているとしましょう。⁠コンテンツキャッシュの例)
<img src="http://pict.gihyo.jp/xxx/logo.gif" alt="xxx" width="xxx" height="xxx" />
<img src="http://pict.gihyo.jp/xxx/title.gif" alt="xxx" width="xxx" height="xxx" />
<img src="http://pict.gihyo.jp/xxx/prof.gif" alt="xxx" width="xxx" height="xxx" />

5.⁠client(ブラウザ)⁠は取得したHTMLファイルに指定された「http://pict.gihyo.jp」配下にあるgifファイルを探しにいきます。http://pict.gihyo.jp はDNS(など)によって図2の①側のシステムへ振り分けられ,目的のファイルが解決されるまで,varnishなどのプロダクトの定義に従ったルートの通り進み,画像があればそのまま返信され,無ければ「backend」定義に従って次のマシンへ問い合わせます。④の「親」でも無かった場合は,HTMLがあったOriginサーバへ問い合わせ,解決します(ここで無ければユーザ「client」へは404となり,システムとしては何らかの障害となるでしょう)⁠

図3 多段キャッシュにおけるデータの流れ

画像

このような構成を構築することにより,実際に課金をするようなシステムやデータベースへの格納,その他重要な処理を行うサーバは④側へ分離することができますので,静的コンテンツを表示するためにセッションや(ネットワークも分けることができれば)帯域の消費が削減されます。

静的画像の他に,容量の大きいFLASHや音楽(楽曲)や動画系のコンテンツ等もランキングとダウンロードの割合に応じてあらかじめキャッシュ系(②~③)へ配置しておくことにより,④側の負荷を下げることができます。特に大きな容量のファイルをダウンロードする場合,④に対して,数秒~1分という単位でセッションを占有する場合もありますので,ピーク時のアクセスからシステムダウンしないような設計を検討すると良いでしょう。

著者プロフィール

高岡将(たかおかすすむ)

大手金融,独立系SIerにて気がつけば計18年以上のキャリアを重ねる。バランス感覚に長け,インフラ/アプリ,プレイヤ/マネージャなど関係なくこなし,「いそうだけどいないタイプ」と評価される。

仕事以外では,自転車,ジョギング,サックス等を趣味にし,密かに「エンジニアと健康」についてダイエット成功論の連載を企む。

コメント

コメントの記入