なぜCDNを移行をしようと思ったか/ DAC 's CDN Migration Case Study

Transcript

1. なぜCDNを移行をしようと思ったか Fastly 移行事例 春名 光一 (デジタル・アドバタイジング・コンソーシアム株式会社) Fastly Yamagoya Meetup 2019

   　2019/10/23 1

2. 自己紹介 • 春名 光一 • デジタル・アドバタイジング・コンソーシアム株式会社 (DAC) • インフラエンジニア •

   GitHub: @k-hal • Twitter: @_k_hal_ 2

3. 会社説明 3 　DAC は、インターネット広告の黎明期にあたる 1996 年にメディアレップとして設立されて以来、市場の形成と業界の成長を 牽引し、情報や生活のデジタル化とともに事業を拡大、発展させてきました。現在は、デジタルマーケティングにおける広告を基 点としたさまざまなサービスを国内外で展開しています。 　媒体社と広告会社などのパートナーとして双方に向けたシームレスなサービスを提供。広告枠の仕入れ・販売、コンサルテー ションからプランニング、運用、結果の解析までをトータルに支援する広告取引関連サービス、メディアの特性を活かしたクリエ

   イティブ制作、豊富なデータと高度なテクノロジーを掛け合わせたソリューション開発・提供や、グローバルなプロモーション支援 などを行っています。 　"Empowering the digital future" というブランドスローガンのもと、これからのマーケティングのあり方を追求し、新たな事業を 生むイノベーションの創出をリードしていきます。 デジタル・アドバタイジング・コンソーシアム 1996 年 設立 40 億円 資本金 1,302 名 役職員数 (DAC 単体) ※2019 年 4 月 1 日現在

4. 4 国内最大規模の オーディエンスデータ 研究機関との共同開発や特許取得技術 により向上した推計技術 1,400種類 の嗜好性データ、 郵便番号データ単位での位置情報データ など 多岐に渡るデータ項目

   データの量 データの質 データの種類 AudienceOne®とは 月間4.8億ユニークブラウザと1億以上のモバイル広告ID、2兆レコード以上の膨大な3rdパーティデータと、 多様なデータパートナーから提供された専門領域データ（2ndパーティデータ）を保有し、そのデータを解析して 高精度なセグメントデータを生成・提供する国内最大級のデータ・マネジメント・プラットフォーム（DMP）です。 Cookie数：月間 4.8億 UB 広告ID数：月間 1億超 ID から収集した2兆を超えるオンライン行動データ 各パートナー企業保有のデータ 信用スコア リサーチパネル 企業属性 電子チラシ クレジットカード情報 データの拡充 3rdパーティデータ 2ndパーティデータ

5. 5 LINE と Messenger に連携したメッセージング管理ソリューション 集客からカスタマーサポートまで一連のコミュニケーションを様々な機能でサ ポート。LINE 向けサービスでは、国内で唯一 ４ 期連続

   LINE Biz-Solutions Partner Program において最上位パートナーに認定。

6. 今日お話すること • 以前のCDN構成と問題点 • 移行と改善を図ったこと • 実際の構成と管理 • ログとモニタリング •

   今後の課題 • まとめ 6

7. 以前のCDN構成と問題点 7

8. DACでのCDN用途 • JavaScriptやクリエイティブなどの配信に利用 • 基本的に静的なファイルのみ ◦ Set-Cookie: はしていない ◦ Cache-Control:

   private で配信すべきものはない(はず 8

9. 以前の構成 • 昔から使っていた某CDNと某クラウドのCDN ◦ プロダクトによりバラバラ ◦ オリジンもバラバラ、設定もバラバラ 9

10. 問題点 • ガバナンス不全 ◦ 多数設定され定価での配信費用がえらいことに • 配信ドメイン名ばらばら ◦ 上記にも関連するが、自社管理ドメイン名でないためロックイン •

    Cache-Control 不備 ◦ Cache-Control: private ? ◦ EC2, GCE から S3, GCS にオリジンを移す中多数出る ◦ CDN側で設定を上書きし、握りつぶしていたりもしたが見通しがわるい ◦ 移行の障害にもなる • 過去の経緯が不明 ◦ 使わなくなった設定が残りっぱなし • 呼び出し元がわからない ◦ 広告のタグって契約終了しても剥がしてもらえないことがある ◦ ロックインが尾を引く • ログをいまいち活用できてない 10

11. 改善したかったところ • 一度設定リセットしたい ◦ 棚卸して必要な設定だけ残す /移す • ログを見やすくしたい ◦ 取るなら見やすく必要な情報は残す

    ◦ 配信実績の費用按分もあるので • オリジン設定もCDN設定もコード管理したい ◦ ちゃんと?管理したい • セルフサービス化 ◦ お願いしますではなく、インフラでなくても設定変更をできるように ◦ ガバナンスは効かせたい • CDNを集約してボリュームディスカウント ◦ まとめて恩恵を受けたい 11

12. 移行と改善を図ったこと 12

13. 移行で改善を図ったこと • 設定のコード化 ◦ Custom VCL という方法もあったが、一旦Terrafrom で管理することに ▪ Terraform

    provider のGoogle Credential の扱いに多少ハマる ▪ サブルーチンとパス単位でSnippet化 13

14. 移行で改善を図ったこと • GitHub に入れて CircleCI から Terraform apply ◦ Issue

    や commit log に意図を残す ◦ Terraform workspace で staging 環境も用意 ◦ Terraform のヒアドキュメントだと terraform apply まで記述ミスに気が付かな い事がある ▪ Fiddle で確認 14

15. Fastly Fiddle • Fastlyが提供している VCLの検証ツール ◦ https://fiddle.fastlydemo.net/ ◦ サブルーチン単位に記述 •

    Snippetとの相性も悪くな い 15

16. 移行で改善を図ったこと • Cache-Control ◦ 当面CDN側での設定を原則とし、オリジンはCDNへの指示のみとする ◦ Cache-Control: s-maxage に •

    ログ ◦ 一旦 GCS に出力し、BigQuery へ Cloud Function で Load ◦ Data Portal で可視化 • CDN費用 ◦ 全部まとめてボリュームディスカウント 16

17. 移行前準備 1. オリジンはそのままに既存設定をFastly向けにおこす ◦ 複雑なことはしていなかった(はずだった)ので 2. オリジンアクセスの挙動差異吸収 ◦ Cache-Control: private

    などが問題に ◦ 上記オリジン側設定の書き換え 3. HTTP Header などの差異、挙動確認 ◦ CORSなど 4. PURGE 処理の準備 ◦ 並行稼動を見据えて 17

18. CDN移行 静的なコンテンツしか配信しないことと、一気に切り替える必要性もなかったので、DNS の重み付け振り分けで少しづつ切り替え DNS振り分け設定を以下で順次変更 1. 1 % 2. 10 %

    3. 50 % 4. 100 % 18

19. TLS Version • Fastlyが通常提供しているTLSネゴシエーションは1.2以上 • プロダクト側から安全側に倒してTLS1.0, 1.1 を有効にしたい と要望 ◦

    専用IPオプションの導入とTLS1.0, 1.1 のサポート有効化 ◦ 急にお願いしましたけど素早く対応して頂けました 19

20. Query Parameterの扱い • GET で送られてくる文字列 ◦ キャッシュとして別のものとして扱われる ▪ 比率を上げたときにオリジンが耐えきれず死んでしまいかねない ◦

    Query Parameter を切り捨てるように設定 ◦ 反映速いのでこういう時助かります 20 If ( 条件 ) { set req.url = req.url.path; }

21. ログとモニタリング 21

22. リクエストログ出力 22 • 必要な項目やフォーマット、出力先を定義できる ◦ BigQueryへの取り込みを決めていたためJSON形式で出力 ▪ リクエスト先 ▪ レスポンスサイズ

    ▪ TLS ver ▪ エッジのロケーション ▪ etc..

23. リクエストログ可視化 • 以前のメルカリさんの資料ほぼそのままの構成 • Google Cloud Storage + BigQuery +

    DataPortal 23

24. リクエストログ可視化 • JSON形式で必要な項目をGCSへエクスポート ◦ 1時間ごとに出力 • GCS書き込み終了をトリガーにCloud Functionを起動してBigQueryへロード ◦ 非同期で取り込み

    ◦ 取り込み失敗はStackdriver Logging で BigQueryのInsertJob失敗を検知 ◦ Data Studio/Portal で良きに可視化 • 5xx とかのリクエスト内容も比較的すぐわかるように • Streaming Insertではないので、リアルタイムなモニタリングには適さない 24

25. リクエストログ可視化 • リクエスト数上位や配信量上位などを表示 25

26. モニタリング • Data Portal で確認 • Datadog とも連携 ◦ これも以前のメルカリさんの資料ほぼそのままの構成

    ◦ リクエスト数、キャッシュヒット率など • リアルタイム性が必要なときはFastly管理画面かDatadogで確認 26

27. モニタリング • ヒット率 ◦ 一部静的で無いものもあった が、かなり高い数字を維持 • TLS Ver ◦

    心配したほど絶対値としては 大きくはなかった 27

28. 今後の課題 28

29. 今後の課題 • Fastly への完全移行 ◦ 実を言うと全部移行できてません ▪ ドメイン名が変更になる部分 ◦ 自社管理ドメイン名は移したが、CDN変更でのドメイン名変更でタグの置き換

    えが必要な部分は今後も移行作業を引き続き実施 ◦ 来年度以降は総コストが安くなる予定 • TLS 1.0, 1.1からの脱却 • 静的なコンテンツのオリジンオブジェクトストレージ化 • Custom VCL化 ◦ Snippet の見通しが悪くなる前に • CDN利用用途の拡大 29

30. まとめ 30

31. まとめ CDN周りの抱えていた問題点を移行で解決を図ろうとしてい ること 移行でいくつか問題にぶつかったが対応したこと どのようなFastlyモニタリング環境を構築しているということ 31

32. ありがとうございました 32