Slide 1

Slide 1 text

CDNのログでLPの可観測性を高めた話 株式会社BuySell Technologies 福本 隆弘 2024.09.11 1

Slide 2

Slide 2 text

自己紹介 名前  福本隆弘 所属  株式会社BuySell Technologies テクノロジー戦略本部  開発1部 SREグループ (おそらく)初めての社外 LTなので緊張 Twitter (X)  @tak_0x00 2

Slide 3

Slide 3 text

3 事業紹介 買取・販売の循環を実現する総合リユースビジネスを展開しています。 お客様のニーズに合わせた各種買取・販売チャネルで、自宅に眠るさまざまな不要なものを、誰かの必要なものへと変えています。

Slide 4

Slide 4 text

4 プロダクト群「バイセルリユースプラットフォーム Cosmos」の開発が進行中 リユースに必要なすべての機能を提供する「リユースプラットフォーム Cosmos」の開発が進行中です。 Cosmosを活用して、バイセルグループ全体での業務効率改善やデータドリブン経営の深化を目指しています。 リユースプラットフォーム Cosmos 自社開発のリユース特化業務基幹システムでありサービス群の集合体 買取申込 買取・査定 在庫管理 販売 多様なチャネルで収益最大化 CRM -顧客対応 - 買取種別に応じた最適なシステム構 築 Visit -訪問買取 - Store -店舗買取 - Promas -商材マスタ - Appraisal -専門査定 - Stock -在庫管理 - EXS -販売管理 - Core -会員管理 - Portal -データ利用 - Pocket -データ基盤 - 買取 専門チームによる真贋・査定と連携 査定 申込 効率的な顧客対応 在庫 在庫管理の最適・効率化 販売 データ 各事業プロセスにある データを一元管理 :基幹システム

Slide 5

Slide 5 text

今回はLPの話 お客さまが弊社にたどり着くための 大事な経路のひとつ 5

Slide 6

Slide 6 text

LPの構成について ・CDNはLPごとに  ディストリビューションを確保 ・ページの運用管理もCDNごしに  操作を行っている ・DBはコスト面から共通のクラスタを  利用している Wordpressを用いたLPで サイトごとにEC2上に構築している 6

Slide 7

Slide 7 text

可観測性に対する課題 01 監視している項目が少ない EC2/RDSのCPUやメモリ状況のみの監視と最低限 CloudFront上からのメトリクス起点のものは無い 02 専用ダッシュボードが無い アラート時にEC2/RDSのインスタンス情報から みれるダッシュボードのみでみていたため、 確認に至るまでの動線が長く 得られる情報も少ない (かつ、拡張メトリクスは無効...) 7

Slide 8

Slide 8 text

専用ダッシュボード 全体・各URLごとでのPVや貫通率、40xの出て いるページの検出、特定IPやUserAgentからの アクセス量も確認可能 ログ転送においてはコスト低減の観点から必要 なフィールドのみに絞る形で実装した CloudFrontからのリアルタイムログを New Relicへ転送することで 詳細な状況確認が可能に 8

Slide 9

Slide 9 text

CDN Hit Ratioの可視化 LP本体とアセット類を同じoriginから配信しているため これらを分けて表示できるように ヒット率のNRQLを調整した また、ヒット率とPVを併記することにより、 PV変動によるヒット率の悪化が発生していないかの検出を可能 とした 9

Slide 10

Slide 10 text

パス別 ヒット率表示 10 キャッシュ設定の見直しのために オリジン側の送出設定やCDN側の設定ミスによりキャッシュできてないファイルが発生する事が多いため、PVの 多い順に各パスのキャッシュヒット状況を表示している (´・ω・)o0O( なんで静的ファイルのヒット率がこんなに悪いのか... )

Slide 11

Slide 11 text

パス別 ヒット率表示 オリジン側の送出設定やCDN側の設定ミスによりキャッシュできてないファイルが発生する事が多いため、PVの 多い順に各パスのキャッシュヒット状況を表示している (´・ω・)o0O( なんで静的ファイルのヒット率がこんなに悪いのか... ) 11 キャッシュ設定の見直しのために

Slide 12

Slide 12 text

Bot・DoS確認の容易化 WAFのManagedRuleを有効化したいが 現状は一部のUAを明示拒否しているのみ に留まっている そこでBotやDoSなどを確認できるよう ClientIP・UA別でのアクセス状況を Barと折れ線で合わせて表示している 12

Slide 13

Slide 13 text

Bot・DoS確認の容易化 WAFのManagedRuleを有効化したいところだが、 現状は一部のUAを明示拒否しているのみに留まっている そこでBotやDoSなどを確認できるよう、 ClientIP・UA別でのアクセス状況を Barと折れ線で合わせて表示している 13

Slide 14

Slide 14 text

突然の貫通率悪化、原因は? CDNからの貫通が急激に増え、 EC2やRDSが高負荷となった このときのダッシュボードを見る 14

Slide 15

Slide 15 text

突然の貫通率悪化、原因は? CDNからの貫通が急激に増え、 EC2やRDSが高負荷となった このときのダッシュボードを見る 15 PVがあるのにHitRatioが0%に なっている

Slide 16

Slide 16 text

突然の貫通率悪化、原因は? CDNからの貫通が急激に増え、 EC2やRDSが高負荷となった このときのダッシュボードを見る 16 pageへのアクセスが急増している

Slide 17

Slide 17 text

突然の貫通率悪化、原因は? CDNからの貫通が急激に増え、 EC2やRDSが高負荷となった このときのダッシュボードを見る 17

Slide 18

Slide 18 text

突然の貫通率悪化、原因は? CDNからの貫通が急激に増え、 EC2やRDSが高負荷となった このときのダッシュボードを見る 18 特定のIPアドレス・UAからの アクセスが多い

Slide 19

Slide 19 text

突然の貫通率悪化、原因は? CDNからの貫通が急激に増え、 EC2やRDSが高負荷となった このときのダッシュボードを見る 19 特定のIPアドレスからのアクセスが ページリクエストに偏っている

Slide 20

Slide 20 text

突然の貫通率悪化、原因は? CDNからの貫通が急激に増え、 EC2やRDSが高負荷となった このときのダッシュボードを見る 20 様々なページへのアクセスをしている

Slide 21

Slide 21 text

まとめ CloudFrontのログをNew Relicに流すことでダッ シュボードを作成した 01 PV、ヒット率の可視化 全体でのPVやヒット率のみにならず、ファイル単位で の可視化を行った これによりCDNの設定ミスや不適切なファイル設置の 検出が容易となった 02 ページ単位での PV可視化 高負荷・攻撃時などにおいて、 どのページが根源となっているのかを可視化した 21

Slide 22

Slide 22 text

THANK YOU 22

Slide 23

Slide 23 text

補足資料 23

Slide 24

Slide 24 text

CDN Hit Ratioの可視化 WITH capture(`cs-uri-stem`, r'.+/(?P[^?/]+)(/)?(\?.+)?') as (`uri-stem-filename`), –- QueryStringの除去、ディレクトリの場合の/有無を正規化したもの if(position(`uri-stem-filename`, '.') is null, 'page', 'asset') as `page-or-asset`, -- 正規化されたファイルパートを元に、拡張子有無でアセット類かどうかを判別 if(`x-edge-response-result-type` in ('Hit', 'RefreshHit'), 'hit', 'miss') as `hit-or-miss` -- CloudFrontでのキャッシュ状況 SELECT filter(count(*), WHERE `hit-or-miss` = 'hit') / count(*) * 100 as 'overall', filter(count(*), WHERE `hit-or-miss` = 'hit' AND `page-or-asset` = 'page') / filter(count(*), WHERE `page-or-asset` = 'page') * 100 as 'page', filter(count(*), WHERE `hit-or-miss` = 'hit' AND `page-or-asset` = 'asset') / filter(count(*), WHERE `page-or-asset` = 'asset') * 100 as 'asset' FROM Log WHERE `client-ip` IS NOT NULL AND `cs-host` = {{hostname}} SINCE 30 minutes ago TIMESERIES 24 NRQLの紹介

Slide 25

Slide 25 text

転送対象とした フィールド リアルタイムログの転送においては63 個のフィールドから最大40個を選択で きるが、コストを勘案し11個を選択した 25 timestamp エッジサーバーがリクエストへの応答を終了した日時 c-ip リクエスト元のビューワーの IP アドレス sc-status サーバーのレスポンスの HTTP ステータスコード cs-method ビューワーから受信した HTTP リクエストメソッド cs-host ビューワーが、このリクエストの Host ヘッダーに追加した値。 (代替ドメイン名 ) cs-uri-stem クエリ文字列 (存在する場合 ) を含むが、ドメイン名を含まないリクエスト URL 全体 x-host-header CloudFront ディストリビューションのドメイン名 (d111111abcdef8.cloudfront.net など) time-taken サーバーが、ビューワーのリクエストを受信してからレスポンスの最後のバイトを出力キューに書き込むまでの秒 数 cs-user-agent リクエスト内の User-Agent ヘッダーの値 cs-referer リクエスト内の Referer ヘッダーの値 x-edge-response-result-type ビューワーにレスポンスを返す直前にサーバーがレスポンスを分類した方法 引用元 : https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/real-time-logs.html