登壇資料_SplunkExperienceDay2023_ZOZO.pdf

;0;0508/ʹ͓͚Δ*5ӡ༻ͱ 4QMVOLͷ׆༻ʹ͍ͭͯ 4QMVOL&YQFSJFODF%BZ גࣜձࣾ;0;0 ٕज़ຊ෦43&෦σΟϨΫλʔ ౉ᬒએ඙ $PQZSJHIU;0;0 *OD 1

;0;0 *OD 株式会社ZOZO 技術本部 SRE部ディレクター渡邉宣彦金融系ソフトウェア開発、ECサイトの構築運用を経て 2019年2月、前身である株式会社ZOZOテクノロジーズへ入社
2021年10月より現職技術本部SRE部のディレクターとして ZOZOTOWNのサービスを構成するインフラの構築運用を担当 2

;0;0 *OD IUUQT[P[PKQ 3 ˔ ϑΝογϣϯ&$ ˔ Ҏ্ͷγϣοϓɺ Ҏ্ͷϒϥϯυͷऔΓѻ͍
˔ ৗ࣌ສ఺Ҏ্ͷ঎඼ΞΠςϜ਺ͱຖ೔ฏۉ ఺Ҏ্ͷ৽ண ঎඼Λܝࡌʢ೥݄຤࣌఺ʣ ˔ ϒϥϯυݹணͷϑΝογϣϯκʔϯʮ;0;064&%ʯ΍ ίεϝઐ໳Ϟʔϧʮ;0;0$04.&ʯɺۺͷઐ໳Ϟʔϧ ʮ;0;04)0&4ʯɺϥάδϡΞϦʔˍσβΠφʔζκʔϯ ʮ;0;07*--"ʯΛల։ ˔ ଈ೔഑ૹαʔϏε ˔ ΪϑτϥοϐϯάαʔϏε ˔ πέ෷͍ͳͲ

;0;0 *OD IUUQTXFBSKQ 4 ˔ ϑΝογϣϯίʔσΟωʔτΞϓϦ ˔ ສμ΢ϯϩʔυಥഁɺίʔσΟωʔτ౤ߘ૯਺͸ ສ
݅Ҏ্ʢ೥݄຤࣌఺ʣ ˔ ϐοΫΞοϓλά͔Β࠷৽ͷτϨϯυΛνΣοΫ ˔ ίʔσΟωʔτண༻ΞΠςϜΛެࣜαΠτͰߪೖՄೳ ˔ 8&"3ެೝͷਓؾϢʔβʔΛ8&"3*45"ͱೝఆɻϞσϧɾλϨ ϯτɾσβΠφʔɾΠϯϑϧΤϯαʔͱ͍֤ͬͨքஶ໊ਓ΋ࢀՃ

;0;0 *OD ・ZOZOTOWNのシステム概要とリプレイス・Splunk導入に至る背景・導入当初の状況を振り返る・Splunkの活用シーン・Splunkの現在の利用状況とまとめ 5 Agenda

;0;0 *OD ZOZOTOWNのシステム概要とリプレイス 6

;0;0 *OD サービス開始当初のZOZOTOWN 7

;0;0 *OD アーキテクチャに手を入れずに規模を拡大特徴 •OS：Windows Server WEB：IIS Application：VBScript + Classic
ASP •DB : SQL Server + ストアドプロシージャ •データに近い場所で処理するため高速 •ZOZOTOWN開始当時のベストプラクティス 8

;0;0 *OD 当時のインフラ構成 9 Load Balancer •Webサーバ、参照系のデータベースはセール時期に合わせて物理筐体を増設する運用 •ピークをあらかじめ予測しハードウェアを調達 •5年間の成長を加味して、スペックの選定を実施

;0;0 *OD 当時のインフラ構成 10 Load Balancer •データセンターのラック状況にも左右される HWの調達にはリードタイムも発生する •正確なピークを予測できない長年の経験と勘に頼るしかない
•年間で見ると余剰リソースになるかも？非効率な投資に

;0;0 *OD 課題に直面するスケールしづらい開発効率の低下古い技術要素難航する採用 11

;0;0 *OD 2017年 4月遂にZOZOTOWNリプレイスを決断スケールしづらい開発効率の低下古い技術要素難航する採用 12

;0;0 *OD そもそもリプレイスの目的とは l お客様にいつでも快適に買い物をしていただけるサービスを提供 l ZOZOTOWNをより成長させるためにリプレイスを行う柔軟なシステム開発生産性技術のモダン化
採用強化 • セール時期に合わせてスケール可能 • 技術情報のアウトプットによるプレゼンス向上 • レガシー技術による独自実装の減少 • 汎用ミドルウェア、 SaaSを利用可能 • 並行開発 • リリースの自動化 13

;0;0 *OD Splunk導入に至る背景 14

;0;0 *OD クラウド移行の開始 15 Load Balancer 参照系ワークロードからクラウド移行を開始リプレイスを進める専門チームが発足オンプレミス⇆Public Cloud間は専用線

;0;0 *OD クラウドとオンプレミスの併用で複雑性が増した 16 Load Balancer 初期の移行計画は成功したもののトレーサビリティが低く当時の監視や運用に改善すべき課題が３つ生じていた

;0;0 *OD 17 課題①既存のアプリケーション構成 •OS：Windows Server WEB：IIS Application：VBScript + Classic
ASP •DB : SQL Server + ストアドプロシージャ & クラウドSQL Server + Java API 事業成長の速度に追随するために従来の環境で開発を続けてきたこともありAPMが対応していないリプレイスでAPMが導入できないだけで難易度が数段あがる感覚

;0;0 *OD 18 課題②組織構造と監視のサイロ化オンプレミスクラウド

;0;0 *OD 19 課題②組織構造と監視のサイロ化クラウド環境はリプレイス運用チームで監視オンプレミス環境は既存環境の運用チームで監視オンプレミスクラウド
環境と運用チームを分けたことで責任分界点も明確になった

;0;0 *OD 20 課題②組織構造と監視のサイロ化オンプレ側でエラー吐いてない？クラウド側の問題では？監視する製品のサイロ化によって見える範囲が異なってくる運用する組織も分かれた事でセクショナリズムが生じたオンプレミス
クラウド

;0;0 *OD 21 課題③従来の監視手法過去はCPU,Memory,Networkといったメトリクスのデータを一枚の画面に並べて確認していたため問題特定に時間がかかる

;0;0 *OD 22 リプレイスを円滑に進めるために監視する製品のサイロ化によって見える範囲が異なってくる運用する組織も分かれた事でセクショナリズムが生じてくるモノリス→マイクロサービスへの移行で運用する組織が分かれるのは必然であるプロダクトに関連するサービスはできうる限り網羅できるよう可視化を進めていくことで
運用面の改善だけではなく組織面の改善にも寄与することができる →Splunkの導入を決定

;0;0 *OD 導入当初の状況を振り返る 23

;0;0 *OD 24 2019年10月利用開始時利用製品 Splunk Cloud 契約体系 Ingest Pricing
利用者数 5-6名取り込みデータ量 400GB/Day

;0;0 *OD 25 導入当初の構成 Universal ForwarderとAdd-onを活用し IISのLogとメトリクスを合わせてSplunk Cloudへ転送メトリクスも併用した可視化ができた

;0;0 *OD 26 導入当初の構成 Universal ForwarderとAdd-onを活用し IISのLogとメトリクスを合わせてSplunk Cloudへ転送メトリクスも併用した可視化ができたサーバごとに
インストール当初は450vm

;0;0 *OD 27 SplunkのAdd-Onとは？ Splunk Add-on データの収集をサポートし対象のデータ取り込みに併せてフィールドの定義を提供 Splunk Apps
取り込んだデータをもとに可視化するためのツール(ダッシュボードなど)を提供いずれもSplunkbase上でユーザーに提供されている https://splunkbase.splunk.com/

;0;0 *OD 28 採用したAdd-on① サーバのパフォーマンスを Universal Forwarder経由で Splunk Cloudに転送できる https://splunkbase.splunk.com/app/4217

;0;0 *OD 29 Splunk Add-on for Infrastructureの導入 Logだけではなく、サーバのパフォーマンス状況も収集することができるAdd-onの中でも優れものしかもSearchする時に軽い

;0;0 *OD 30 採用したAdd-on② サーバ上で動くパケットキャプチャ TCP,UDP,HTTP,DNS,TDSが対象 https://splunkbase.splunk.com/app/1809

;0;0 *OD 31 Splunk Add-on for Stream Forwardersの導入サーバからAPIへの内部通信の状況が把握できた事でデータをもとに会話をすることが可能になった

クラウド側APIとのレスポンス状況を把握することが可能に

データのIngest量が激増するため利用する際は注意が必要

;0;0 *OD 34 採用したAdd-on③ データベースの情報を Splunkのクエリやダッシュボードに簡単に統合できるAdd-on 直接クエリを実行し Splunkに結果をIngestすることも可能 https://splunkbase.splunk.com/app/2686

;0;0 *OD 35 DB Connectの導入 https://splunkbase.splunk.com/app/2686 データベースのパフォーマンスもSplunk上で可視化できるため調査など迅速な対応が可能に従来確認しづらかった領域も可視化された

;0;0 *OD Splunkの活用シーン 36

;0;0 *OD 37 ①情報が集まっているダッシュボードを作る現状でのアクセス状況がわかるダッシュボードを作成過去60分程度のタイムレンジで描画

;0;0 *OD 38 ①情報が集まっているダッシュボードを作る【メトリクス＋レスポンス】【アクセス数＋レスポンス】など同じグラフに描画して生成することで状況をより把握しやすくなり因果関係を調べるために、複数の画面を遷移する必要がなくなった前述の関連APIと並べることでどこにボトルネックが生じているかより明確に

;0;0 *OD 39 ②簡潔に状況を把握しやすい画面を作る CPUの負荷をレンジで色分けし一目で状況がわかるように、パネル表示赤橙黄の順で負荷の高さを表現し
台数もすぐわかるように

;0;0 *OD 40 ②より簡潔に状況を把握しやすい画面を作る Drilldown Editorを使ってダッシュボード間の連携を組むことで他のダッシュボードに遷移させてから情報の深掘りをできるように 1つの画面を簡素化させるのに特に有効

;0;0 *OD 41 ③エラー状況も判断しやすい形へエラーの発生状況に特定の偏りがないか判断できるようにTimeChartとTableで情報をダッシュボードなどで表現可能に「特定のサーバだけが多く発生していないか？」や「特定のURIだけが
多く発生していないか？」

;0;0 *OD 42 ④月次で確認するSLOダッシュボードをSplunkで作る１ヶ月分のデータを使ってSPLを駆使すると長時間かかってしまうため集計Jobを毎日Cronで組んでおくことでひと月分のデータを表示させても時間をあまりかけずに出力可能になっている

;0;0 *OD 43 ④月次で確認するSLOダッシュボードをSplunkで作るレスポンスタイムなど過去数ヶ月の推移を追い続けていくとどこでおかしな挙動を示しているか、確認することが容易になるこれはSLOに影響をあたえる現象があった場合に発生時期や原因を特定するために利用している

;0;0 *OD Splunkの現在の利用状況とまとめ 44

;0;0 *OD 45 2023年7月時点利用製品 Splunk Cloud 契約体系 Ingest Pricing→Workload
Pricing 利用者数 5-6名→40名強取り込みデータ量 400GB/Day→ 4500GB/Day データを取り込む容量ベースでの契約から CPUベースの契約に切り替えを行った容量に関して制約を受けないため Splunkの自由度が高くなった一方で次のような注意点も

;0;0 *OD Workload Pricingへ移行したことによる注意点 46 •重いSPLを実行してしまう •リアルタイムサーチをふんだんに駆使したダッシュボードを動かしてしまう •長期間のTime_Rangeでサーチをかけてしまう Splunk
Cloud全体のパフォーマンスに悪影響になるため取り締まる警察や啓蒙活動が必要になるかも

;0;0 *OD 47 Splunkで実現できた点と変化 •ZOZOTOWNの可観測性は大きく進歩 •データを用いて会話することが基本に SREの当たり前レベル向上にも寄与 •以前のようにVPNで監視サーバにログインする必要なく監視運用業務を行うことが可能になった •SREだけではなく開発者もSplunkで
サービスの稼働状況を把握できるようになった総じてSRE部の組織力向上だけではなく開発組織のコミュニケーションの改善にも寄与したと言える

;0;0 *OD 48 今後のSplunk Cloudに対する要望点 •Splunk CloudとSplunk Enterpriseでは対応する機能にまだ差がある •ダッシュボード作成に関してもtipsがかなり多いがもっと世の中に広く出していってほしい
•手作業がまだまだ多く、ダッシュボードの作成も属人化してしまう可能性が高い求む「Infrastructure as Code」

登壇資料_SplunkExperienceDay2023_ZOZO.pdf

登壇資料_SplunkExperienceDay2023_ZOZO.pdf

More Decks by Nobuhiko Watanabe

Other Decks in Technology

Featured

Transcript