サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
blog.xcir.net
はじめに 少し前にHTTP関連のRFCが改訂されましたね!(RFC91XX) このあたりの全般的な話は既に詳しい方々が触れていますので(HTTP 関連 RFC が大量に出た話と 3 行まとめ)、基本的にはそっちを参照すればよいかなと思うのですが、何が変わったかというと大規模なリファクタリングがされたといっていいでしょう。(もちろん同時にHTTP/3やCache-Statusなどの新しい仕様もふえています) とはいえHTTPのリファクタリングってなに?と思うことも多いと思うのでHTTP/2の例示をしてみます。 皆さんご存じの通りHTTP/2、HTTP/1.1のどちらにおいてもAccept-Encodingなどのフィールド(改訂でヘッダからフィールドに用語が変わりました)は同様に使えます。 要はセマンティクスは同じなわけですが、RFC7231ではHypertext Transfer Proto
先日とらのあなラボ様の勉強会に参加していたところ「強いキャッシュ」「弱いキャッシュ」とキーワードが出てきました。 初めて聞く表現だったので質問したところやはり知らない定義だったため、少し調べてまとめてみたものです。 なお、強いキャッシュ・弱いキャッシュという説明を否定するものではなく、補完したいと考えています。 強いキャッシュ・弱いキャッシュの定義 ネット上を調べると日本語・中国語・英語で説明が出てきますが、調べた限りでは強いキャッシュ・弱いキャッシュの初出はWebフロントエンド ハイパフォーマンスで、定義は以下の通りです。 ExpiresヘッダーとCache-Controlヘッダーでは強いキャッシュを設定できます。 ETagヘッダーとLast-Modifiedヘッダーでは弱いキャッシュを設定できます。 Webフロントエンド ハイパフォーマンス p124 こちらの文書の前後に詳しい定義があ
VarnishのEnterprise版で利用できるパラレルESIがcommunity版でも使えるものをUPLEXが公開してくれました。 ヘビーにESIを利用する人はそこまでいない気もするのですが、これがまたなかなか便利なので紹介します。 ビルド方法 このvmodはVarnishの内部関数に深く依存しているため、ビルド時にはVarnishのコードが必要でビルドに癖があります。 また、動作時にはVarnishとビルドにつかったVarnishのコミットハッシュ値が一致している必要があります。 なお以下の環境で確認しています pesiは最新のコードを使えばよいかなと思いますが、もしビルドができない場合はもしブランチで7.0があればそちらを(現時点ではないですが)、もしくはコミットログを眺めて適度に巻き戻るとよいでしょう。 とりあえずVarnishとpesiのコードをダウンロードします。 ubunt
ローカル・経路上のキャッシュを併用しよう キャッシュは再利用されるほどいいものです。 サイトの規模にもよるのですが、ローカルと経路上のキャッシュはそれぞれ性質が異なるため、ブラウザキャッシュだけ適切に設定しておけば経路上では不要というわけではありません。 ローカルキャッシュはキャッシュを持つクライアント自身がサイトを再訪する場合は有効ですが、キャッシュを持っていない新規クライアントには無効です。 経路上のキャッシュは新規クライアントに対してもキャッシュを返すことができるため、例えばサイトへの流入が突然増えるといった事態でも対処がしやすいです。 そのためコンテンツ次第ではありますが、ブラウザキャッシュのように特定のクライアントでしか使えないprivate cacheにするよりも、 効率を考えてローカル・経路上のどちらでもキャッシュができ、多数のクライアントで共有できるshared cache
twitterでなんどもつぶやいてるので多分知られているとは思うんですが、Web配信の技術という本を書きました。 せっかくなんで、なんでまたこんな本を書いたのかとかどういう流れだったのかみたいなのを簡単に書いてみようかなと そもそもどういう本なのか 非常にタイトルを決めるのが難しい本でした。 サブタイトルに「HTTPキャッシュ・リバースプロキシ・CDNを活用する」とあるようにいわゆるHTTPキャッシュの本なわけですが、コンテンツ配信の技術といえばCDNの印象が強く出ますし(本書はCDNの使いかたというわけではないです)、Web配信といえば動画ストリーム配信(VTuberの配信とか)を思い浮かべる人も多いと思います。 今考えればWebコンテンツ配信の技術とすればよかったかもと思いつつ、今度は長くなりすぎるのでなかなか難しいです。 ということでHTTPキャッシュを使ってWebサイトを高速化した
こんな感じです。 VCLの記載の仕方は環境それぞれだとおもうのでなんともいえないのですが、 default.vclを起点として、includeしていくやり方であればdefault.vclを一旦4.1にしておくと良いのかなと思います。 とはいえ、4.0から4.1へのアップデートはそんなに難しくないのでやってしまったほうがいいんじゃないかなとは思います。 VCL変更点 4.0での変更点と4.1での変更点があります。 まずは共通の変更点から 変更点(4.0/4.1共通) return(fetch)がvcl_hitで使えなくなりました 個人的にはまだ残っていたのかといった感じですが(結構前からdeplicatedになってた) return(miss)を使いましょう req.storage / hash_ignore_busy / hash_always_missをclientスレッド側でアクセスで
VarnishCache5.2.0がリリースされました。 [changelog] [公式のリリース文] [パッケージDL] [ソースDL] バグの修正(特にh2関連で多くの修正入っています)はもちろんですが、 新しいvmodが提供されたり、影響の大きい(破壊的)変更があります。 また、VMOD/TOOL開発者向けの変更も多く、新しいツールなどが期待できます。 影響の大きい変更 VSMの抜本的な変更 Varnishの内部でログや統計の保存先に使用しているVSMの仕組みが変わりました。 これによりVSMを利用してログ(VSL)や統計(VSC)にアクセスしているサードパーティのプログラムについては対応が必要になります。 なお、VSMのラッパーであるVUTについても変更があるのでこれ関係は全部修正が必要と考えても差し支えありません。 (Varnish UTilities:VUTはVSMを使う上でl
4.0.0及び3.0.xは先に述べた通り、そもそも今回の機能がないので対象外です。 回避方法(VCL) VCLでの暫定的な回避方法があります。 これらはchunkedでリクエストしてきたものを503で落とすことで回避します。 大抵のブラウザの場合はTransfer-Encodingを指定したリクエストは行わない事が多いのですが、念のため確認すると良いでしょう。 varnishlog -cq ReqHeader:Transfer-Encoding -i ReqMethod -i ReqURL これで何かしら出てきて、正規のリクエストの場合はVCLでの回避は不可能ですのでバージョンを上げる必要があります。 なおここで紹介している回避コードは公式そのままなので公式も参考にしてください(VSV00001) 4.0.x向け インラインCを利用します。 そのためvcc_allow_inline_cをt
最近何かと話題なCDNですが、そもそもCDNってなんだろう・・・どんなことに使えるんだろう?的なことを書いてみようと思います。 一応先に言っておくと、私はCDN業者に所属したことないのであくまでも利用者として見た時の話を書きます。 また、私の考えであり、様々なワークロードがあるなかでこれがすべてではありませんので、こんな考えもあるんだなぁぐらいに思ってもらえると助かります。 そもそもCDNってなんだろうか そもそもCDNはContent Delivery Networkの略であってCache Delivery Networkの略ではありません。 要はコンテンツをクライアントに対して高速・効率的に配信するためのネットワークです。 良くCDNといえばその成り立ちからキャッシュというイメージはありますが、重要な要素の一つではあるもののCDNの全てではありません。 さらに言えばAkamaiのInt
5.0.0の後継の5.1.1がリリースされました。 [changelog] [リリース文] [changes] [Upgrading] また、今回からパッケージがpackagecloudで提供されるようになりました。(packagecloud) 5.1.0はどうなったの?という話ですが、ちょっと問題となるバグがあったため翌日にすぐ5.1.1を出した感じです。 今回のリリースでは4.1.4/4.1.5で変更された内容と細かい機能修正(VCL変更含む)があります。(それについては割愛してます) VCLの変更はあるものの修正しないと動かないような変更はないのでよほどのことがない限りそのまま動作するはずです。 なお、VMODについては動かなくなるものもあるので事前に使用しているものが動くかを確認したほうが良いでしょう。 また、累積バグも修正されているのですが、よほど修正されているバグで困ってない限
少し前にスロットルでサイトを守る(vmod-vsthrottle)で異常なリクエストに対してスロットルをかける方法を紹介しました。 しかしこれはあくまでリクエストレートのみで、そのリクエストがどれだけ帯域を使うかは制限しません。 例えば特定のリソースについては帯域を制限をかけたい場合や(動画のようにDL中でも再生できるのであれば、必要なビットレート+αでもいいかなとか) ユーザの属性(課金状況など)や、はたまたリクエストが多いユーザに対しては制限をかけたい場合などいろいろあるかと思います。 今回は帯域制限を行うvmod-tcp(ドキュメント)を紹介します。 環境について vmod-tcpでの帯域制限はtc-fqのSO_MAX_PACING_RATEを指定することによって実現しています。 これはカーネル3.13からの機能のためUbuntuであればTrusty以降が必要です、CentOSの場合
二年ぶりぐらいにメジャーバージョンが更新されました。[公式リリース] [ダウンロード] 今回の目玉機能としてHTTP/2対応とDirectorのConsistent Hash対応があります。 なにはともあれ、とりあえずHTTP/2を使うセットアップをしてみましょう。 Hitch1.4.0+Varnish5でHTTP/2を使う Varnishはよく知られてるようにHTTPSに対応していません。 HTTP/2に対応したこのバージョンにおいても、やはり本体では対応をしていません。 そのため通常のブラウザからVarnishに対してHTTP/2にアクセスするにはTLSを解かなくては行けません。 今回はVarnishSoftwareが提供しているHitchを利用します。 なお、HTTP/2を利用するには1.4.0以降のバージョンが必要です。 また、一部ディストリビューションではパッケージが提供されてい
キャパシティプランニングをする際に頭がいたいものの一つに通常ではないアクセスがあります。 ぱっと思いつくので 閲覧数がページに表示されているのでF5押しっぱなし スクリプトでスクレイピングしようとしているのか暴走している 足跡をつけるために尋常じゃない速度で訪問しまくる ログイン試行 画像をひたすらダウンロード などなどいろいろあります。 これらに共通なのが、通常ではないリクエストで大量のリソースを消費することです。(もちろん他の問題(セキュリティ)があるものもあります) もしキャッシュしていたとしても、アウトバウンド帯域を過剰に利用しますし、キャッシュが出来なければwsやdbなどでの負荷になります。 キャパシティプランニングをする際には様々な条件を考えて構築していきます。 単純にユーザーが増えて負荷が増えていくのは望ましく、喜んでインスタンスを増やしたり負荷対策をしますが そうでない場合
この記事はセカイエ Advent Calendar 2015とVarnish Cache Advent Calendar 2015の2日目の記事になります。 かなり前の話(8月)になるのですがリノコという定額リフォームサービスのサイトがTV東京のワールドビジネスサテライト(以下WBS)に取り上げられました。 ありがたいことにたっぷり取り上げていただきました。その際に少しだけVarnishを使って負荷対策をお手伝いしたのでその時のことを書きます。 (なおここでとった対策は緊急ということで外しています。) TV放映される上で負荷対策として検討したこと スケールアップ・アウト トップページ及びそこから回遊されるページの静的化 Varnish導入 動き的には1を検討してみてその結果たりなさそうという判断を行い2,3を並列で行った感じです。 スケールアウト リノコではクラウドを利用しているわけで当然
この記事はVarnish Cache Advent Calendar 2015の1日目の記事になります。 何回か散発的に取り上げたことはあるのですがVSL-Queryの使い方についてまとまっては書いていなかったので書いてみます。 varnishlogのフォーマットの説明についてはv3の頃の記事ですがVarnishのログにアクセスしてみよう!を参考にしてください。 Varnishは他のミドルウェアでよくあるようにアクセスログをファイルに直接書き込むということはせずにリングバッファな共有メモリ(VSM)に出力します。 その際に出力されるログ(VSL)は非常に多岐に渡ります ヘッダ(クライアントからのリクエストヘッダやバックエンドからのレスポンスヘッダなど) ヘッダへの操作 どのアクション(vcl_recvなど)が呼ばれて何をリターン(hashなど)したか std.logで出力した任意のログ な
Varnish4.1.0がリリースされました。 多くの新機能・改善・バグフィックスとほんの少しのVCLの変更があります。 特にバグフィックスを求めるユーザにとっては朗報です。 今までチケット上は修正されたけど各ブランチにマージされていなかったものが全て今回4.1ブランチにマージされたのでそれを求めるユーザにとっても更新するのも良いと思います。 割と大規模な変更があるので安定性について気になっている方もいると思いますが、4.1.0-beta1を2週間強ほど知り合いのサイト(ESI含む)に入れて運用しましたが 踏んだバグは一つ(#1792)で修正済みで安定して動いています。 また、CPUの使用率も下がっているようです。 ダウンロードはこちら VCLの変更について 本家のアップデートガイドでも書いてある通り4.0.xのVCLをそのまま使用することが出来ます。 但しdeprecated的なのが増え
ここ最近いくつかのサイトを見ていて、アレ?妙に重くない?とDevTools等を見てみたらいろいろな問題点を見つけました。 例えばベースページが重いというのもあるのですが、単純にリソースが大きすぎる、ヘッダがおかしい等少しの工夫で閲覧をする人たちは快適になるだろうというのを思いました。 正直なところ今回記述する内容はいろんなサイトや書籍では触れられてはいるのですが、サイトを見回って共通で考慮が漏れていて、余りサイトに変更を加えずに効果がでそうなのを纏めてみました。 そのページを見るのにどれだけのダウンロードが必要ですか? 最近はPC環境もモバイル環境もより強力になり、リッチなコンテンツをストレスなく見ることが可能になりました。 マシンスペックやブラウザの高速化等いろいろありますが、ラストワンマイルのNW帯域が改善したのが大きいと個人的には感じています。 しかし、それに甘えて不必要なリソースを
小ネタです Varnishを使う上で冗長化をどうしようと悩むことが多々有ります。 単純に横に並べてLBでバランシングしてもキャッシュの同期をどうしようという問題にぶち当たります。 VarnishSoftwareがサブスクリプションで提供しているVarnishPlusでは同一階層のVarnishにおいてキャッシュオブジェクトのレプリケーションを行うVarnish High Availabilityという機能が存在しますがコミュニティ版のVarnishでは存在しません。 (VarnishPlusについてはそのうち記事書こうと思います) 強引にVCLでSquidのsiblingのような動きをするように書くことも出来なくないのですが個人的にはオススメできません。 幾つか理由があるのですが一番大きい理由がRace conditionに陥るからです。 VarnishはこれはThundering Her
このブログを見てる人だとご存知だとは思うのですが、Varnishはいろんな機能があるリバースプロキシです。 VCL、ヘルスチェック、強力なログ機能、そしてESIなどの機能が存在します。 ESI以外の記事は偶に見かけるのですがESIはあまりみないなーというのと 僕が入社するとVarnishがもれなくついてきます 遊びに行っただけでもVarnishが導入されるケースがあるようです — \いわなちゃんさん/ (@xcir) November 18, 2014 こんな乗りで去年の10月あたりから知り合いのサイト(一般的には大規模にあたるぐらいのPV)にESIを入れたので (特定できてもそっとしておいてください) その時に効果や注意したことをメモ的に残そうと思います。 まずESIって何かというとESIタグをページ中に挿入することでVarnish側でそのURLの内容で置換してくれる技術です。 詳しくは
Varnish4.0.1が公開されました。 ついでに公式サイトもデザインが新しくなって見やすくなりました。 バージョンアップ自体は主にBugfixで、4.0.0がリリースされて報告されていたバグが基本的に修正されています。 幾つか重要度の高いbugfixがあるので4.0.0を入れた人は適用するのをおすすめします。 (僕が報告してたスレッドが開放されないなどのバグも修正されてました) また、今回も機能変更と追加がかなりされています。 動作に関わるところをについて抜粋して紹介します。 公式Changes ダウンロード 機能変更 Persistent storageがdeprecatedになりました ML見てたら不穏な動きが出てたのでどうなるかなーとおもってたんですがさっくり廃止予定になりました。 4.0.0になって多少使いやすくなったとおもったんですがパフォーマンスを維持しつつ整合性を確保する
4/29に全世界同時でVarnish4のリリースパーティーがありまして、東京もやるぞーということでクックパッド様でピザ食べながら発表してきました。 v4rpのタグを眺めていると野外BBQしながらブロック壁に投影しているところもあったりとなかなか良い感じでした。 で、前回と同様にVarnish4での新機能や変更点を発表しようと思いまして、GWもあるしと資料をのんびり書いてましたら結局尻に火がついてしまって前日ぐらいまでガリガリ涙目で書いていました。 2->3の時も涙目だった記憶があるのですが、今回は変更点がかなり多いこともありまして、途中でこれ間に合うんかな・・・とかんがえる事も・・ ということであまり発表練習が出来なかったのでお聞き苦しいところがありましたら申し訳ありませんでした。 で、私の発表資料はこちらです。 GoogleDocs版(アニメーションする) また、発表の際に忘れていて触れ
今回もgifを撮ってみました。 取得に3秒かかるコードでTTLは10秒です。expire時の動きを見てみてください。 検証コード ■date.php <?php header('Cache-Control: max-age=20'); echo date("Y/m/d H:i:s")."\n"; sleep(3); ■vcl@3.0.5 sub vcl_fetch{ set beresp.do_stream = true; set beresp.ttl = 10s; set beresp.grace = 10m; } ■vcl@4.0.0 sub vcl_backend_response{ set beresp.do_stream = true; set beresp.ttl = 10s; set beresp.grace = 10m; } grace動作 3.0.5 4.0.0 3.0で
6ヶ月ぐらい前の話になるんですがVarnish User Group7(VUG7)で発表してきました。 下書きは書いたものの発表後の燃え尽きと、時期逃したかなと放置していたのですが、先日VUG8もあったのでせっかくなので書きました。 資料はこれです。 話した内容は古い配信システムをマイグレーションした話とその過程で作った、使ったツールの紹介です。 会社のシステムなので細かいことは書けないのですが、所属している会社を考えて頂ければそれなりの規模だと想像していただけると思います。更にいうと単一ではなく複数のシステムの統合です。 また、スライドにも書いてあるとおりなのですが、マイグレーションはダウンタイムなしで最初の1台を入社後の一月以内で投入というスピード感で行われました。 どのようなマイグレーションでもそうだと思うのですが、今回私が特に気をつけて行ったのが以下です。 ・キャパシティプランニン
Varnish3.0.5が公開されました。 今回はBugfixですが varnishlogの-mオプションで動きが変わったため一瞬戸惑うかもしれません。 修正された項目は以下になります。 varnishd ■ESIのパースに失敗した場合に標準出力にメッセージを出していたのをやめました (Stop printing to stdout on ESI parse warnings) デバッグの時の消し忘れっぽいですね。 ■syntheticの最初のパートでNULLを指定した場合segfaultで落ちるのを修正しました (#1287) vcl_error内でstd.filereadを使ってNULLが帰ってきた場合や存在しないヘッダを指定したときなどに出ると思いますが 普通はしないと思います。 ■streamを利用した際にContent-Lengthが重複してクライアントに送信されるのを修正しまし
少し前にサムネイルの作り方をチームの人に聞かれて教えていたのですが 座標の関係がすらすら言えなかったので備忘録的にまとめてみました。 ついでに他の事もまとめてみました。 サムネイルの座標 サムネイルを使う場面はいろいろあると思うのですが大きく分けると2つあると思います。 ・単純に小さくする(例:640×480 -> 320×240) ・指定サイズにする(例:640×480 -> 60×60) 単純に小さくする場合はあまり気にしないのですが 指定サイズに収まるようにサムネイルを作る場合は座標を気にする必要があります。 例えば、上記の例のように縦長の画像を日記のアイコンに使うような正方形のサムネイルにしたい場合において できれば顔のある可能性が高いあたりをサムネイルとしたいケースがあります。 その場合は何をどのように指定すればよいでしょうか? 使う画像処理エンジンによって、呼び名は変わったりす
Varnish3.0.4が公開されました。 今回はほとんどBugFixですが、いくつかの機能改善があります。 公式リリースノート(3.0.4) バグフィックス ■CVE-2013-4090 特定条件でACLで想定外のマッチ・マッチ漏れが起こる #1312 対象は3.0.3までの全てのバージョンです 引っかかる条件は以下だと思います ・CIDR形式の定義が存在(/8,/16,/24を除く) ・単一のIPアドレスを指定している ・その定義範囲が重複している こんな感じです VCLコード acl foo { "127.0.0.2"; "127.0.0.0"/19; //(127.0.0.1 ~ 127.0.31.254で127.0.0.2を含む) } Cに変換したコード(3.0.3) static int match_acl_named_foo(const struct sess *sp, co
みなさんお久しぶりです。いわなちゃんさんです。 最近会社で、「○○さんっていわなちゃんですよね?」と確認されたりしていますが元気しています。 さて、来週の5月30日~31日にかけてニューヨークで行われるVarnish User Group Meeting 7(VUG7)で発表する機会を頂けましたので、先日会社のブログでちらっと触れたレガシーシステムを載せ替えた話といくつか作ったツールについて発表してきます。 本当はVMODの話でもしようかなと考えていたのですが、MLとかIRCを見てて困ってる人が多いのはツールかなと感じたので、そっちの話をしてきます。 ツール自体の記事は、また帰ってきたら書こうと思いますがgithubにはあげていますので見てもらえれば嬉しいです。 あと、ニューヨークで美味しいものを食べたいので、おすすめのお店・ここは見とけといったスポットを教えてもらえると嬉しいです。 飛行
_人人人人人人人人_ > 退職しました <  ̄^Y^Y^Y^Y^Y^Y^ ̄ twitter.com/xcir/status/27… — \いわなちゃんさん/ (@xcir) December 14, 2012 なんとなく突然の死ジェネレータを使って退職しましたと呟いてみたら ネタと思われたのか、数人の方から「リアルな話ですか?」とリプライが帰って来ましたが本当に退職です。 正確には有給消化中で年内は在籍しています。 僕がクルーズに入社した2009年当時はまだ社名はウェブドゥジャパンでオフィスも麹町で ブログ、携帯公式コンテンツなどが主力コンテンツでしたが 今ではモバゲー向けのソーシャルゲームとコマースを主力でやってます。 いろいろ環境が激動するなかでコードを書くことはもちろん、 ネットワークまで幅広い分野で貴重な経験をさせていただきました。 何やってたの? ・社内PHPフレームワーク ・画
次のページ
このページを最初にブックマークしてみませんか?
『cat /dev/random > /dev/null & – お絵かき上手くなりたいです』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く