CDNとうまく付き合う

Shohei Tanaka(@xcir)

Shohei Tanaka(@xcir)

• いわなちゃんさんと呼ばれてます
• グリーでインフラエンジニアをやってます
• 興味分野はHTTPとVarnishCache
• 以前Web配信の技術という本を書きました
• 旅行が好きなのでおすすめスポット教えてくれると嬉しい

CDNを使う目的はなんですか？

CDNを使う目的はなんですか？

• アセットを効率よく配信したい
• キャッシュしてオリジン負荷を下げて台数を減らしたい
• セキュリティ対策として
• などなど

CDNを使う目的はなんですか？

これらが何事もなく安定してパフォーマンスを出す運用をするのが大事

こういうところが多いのでは？

• 導入まではmetricsを頻繁に見てたが導入後はあまり見ない
• もちろん利用用途によるが、請求書を見る程度が多いのでは？
• パージぐらいはやる
• 404などのslack通知はやってるけど・・・
• そもそもCDN運用は業者がやっているし・・・
• CDNの障害なんで踏んだことないし・・・
• まぁ障害起きてもパージすればいいのでは？

そうCDNは安定している？

• プロダクトが何気なく行ったパージでサービスが死ぬことがある
• 障害は起きているが気付いてないだけ

今回は運用ミスで障害を起こしやすいパージとCDN障害の話をします

CDNのパージ

• CDNにおいてパージは比較的負荷が高い処理
• 多くのCDNでratelimitが設定されている
• ユーザの過剰なパージで全落ちしたCDNがある
• なのでパージをするときに微妙にこれが指定できればというのがある
• 具体的には正規表現
• 滅多に対応しているところを見ない

CDNのパージ

• パージで消すものを指定する方法は様々
• 大体のCDNであるもの
• 全消し・URL・パス前方一致
• 一部のCDNであるもの
• キャッシュタグ
• 削除する方法は２つ
• Invalidate
• キャッシュ期限切れ状態にする
• 次回リクエスト時にif-modified-sice/if-none-matchでの再検証が走る
• Delete
• キャッシュを削除する

これらを組み合わせて負荷をかけないパージを設定する必要がある

適したパージ方法を考える

• http://example.net/img/foo.jpg
• 静的コンテンツ
• オリジンはオブジェクトストレージ
• この場合のパージは難しく考える必要ない
• 消す対象が単一ならURL+Invalidate
• 複数で多いのであればパス指定(/img/*)+Invalidate
• 気を付ける事といえばInvalidateを行うこと
• 全消し・パス指定で更新不要なコンテンツも消したとしても再検証リクエストで済む

適したパージ方法を考える

• http://example.net/avatar/4e1243bd22c66e76c2ba9ed.jpg
• 複数の画像から動的に生成されたアバター画像（URL部はハッシュなど）
• 素材となった1画像を差し替えたのでそれを使っているアバターを全て消したい
• この場合のパージは非常に危険
• 素材がどのURLに含まれるか特定できない
• 問題無いものも含めて消す必要がある
• 高コストな生成コンテンツなためオリジンの負荷が急激に高まる
• 動的な場合ETagの生成自体にコストがかかるのでinvalidateでもコストがかかる
• サムネぐらいであればオリジナルのETagを使うとかで軽減する方法はあるが・・・

適したパージ方法を考える

どうすれば事故なくパージができるのか

適したパージ方法を考える

• 要はオリジンがパージでの再取得に耐えられれば良い
• 「キャッシュしてオリジン負荷を下げて台数を減らしたい」でCDNを使ってる場合は特に注意
• オリジンを強くする
• パージ前にスケールさせる
• パージを複数回に分割する
• URL構造を変えることで分割パージを行う
• /avatar/1/… /avatar/2/…
• サービス中に変更するのはなかなか難しいし柔軟性がない
• キャッシュタグを利用して分割パージを行う
• Akamai, Cloudflare(Enterprise), Fastly, Tencent(TEO)などで使える
• 途中からでも導入可能
• 導入後にTTL経過して古いキャッシュが消えればいける
• これによりスケールを最小限に抑えることができる

そもそもキャッシュタグとは

• オリジンからのヘッダなどでタグを指定することでグループ化ができる
• Edge-Cache-Tag: avatar_1, image_2, all_4
• 消す場合はavatar_1のようなタグ指定で消す
• 一番の利点はキャッシュキーと違いオブジェクトの関係が1:nになる
• キャッシュキーは1:1
• 1キャッシュタグの指定で100や200のオブジェクトを指定してパージすることができる
• これを利用することで高コストでも比較的安全に分割パージを行える
• 他にも便利に使える
• 動的サムネイル生成でタグを元ファイル名で設定
• 元ファイル＋サムネイルを一気に消せる

​

Akamaiでの設定例（全体4分割）

CDNの障害

• ​

大きく影響を受けるかどうかは置いておいて割と頻繁に障害は起きている

CDNの障害

• 自分は大小含めて1～2年に1回ほど何らかの障害を経験している
• —
• —
• —
• —
• —
• —
• —
• —
• などなど
• またCDNは障害時に非常に疑われやすいサービス
• ダウンロードできない→ユーザの自宅NWの問題だった
• ファイルが壊れている→オリジンのファイルがそもそも破損していた
• こういうのをCDN業者に問い合わせるのは恥ずかしい
• どうしろという障害もあるが切り分けて正しく問い合わせするのは大事

非公開

CDNに問い合わせる前に

• 障害が起こる前にやること
• CDNにあるモニタリングを一通り見て調査に役立ちそうなものを把握しておく
• アクセスログは有効にする
• 様々なQuota(bps/RPS/object-size/APIなど)を一通り見る
• 実は引っかかってたというのはある
• CDNの障害ポイントについて知っておく
• あやふやな問い合わせを行わない
• なんかおかしいんですがエッジでなんか起きてます！？と言われても困る
• AWSの技術的なお問い合わせに関するガイドラインをまず見よう

技術的なお問い合わせのガイドライン(AWS)

CDNについて

• CDN障害について考える前にCDNについて知っておきたい
• すごい雑に単純化すると2つのコンポーネントで構成されている
• リクエストルーティングするコンポーネント(DNS, BGP)
• 実際にHTTPを受け付ける（大量の）ReverseProxy
• CDNは障害範囲でどこに問題があるかを判断しやすい
• 範囲が広いほどオリジンに近い部分で障害
• 若しくはそもそもオリジンの障害
• 他にも処理順などを知っておきたい
• 大体はセキュリティ関連処理の後にCDNの処理となる
• CDNで障害ではなくセキュリティ側の誤チェストの可能性もある

​

CDN障害例

非公開

CDN障害例

非公開

CDN障害例

非公開

CDN障害例

非公開

まとめ

• パージは場合よってはサービス丸ごとが死ぬ
• オリジンがパージに耐えられるかを実行する前に考えよう
• CDNは思ったより障害が起きている
• 切り分けのためにちょっとしたことを事前学習しておくと良い