本篇文章是個技術分享文，Netflix 分享內部過去四年來是如何打造一個分散式的 Tracing System。
Netflix 的串流服務想必大家都很熟悉，但是作為服務提供者來說，要如何維運這套分散式的串流服務就沒有這麼簡單。
舉例來說，當一個特定的使用者回報其服務有問題時，內部的系統要如何把下列資訊給全部串接起來組合出一個可以讓內部工程人員除錯的機制
1. Streaming Session
2. 微服務之間的流量
3. CDN 的處理
對使用者來說就是串流有問題，但是背後的網路封包實際上經過哪些 app，走過哪些節點，踏過哪些機房都是很複雜的事情，不把這些全部資訊都組合起來則非常困難除錯。
Netflix 決定要針對這個問題打造一個分散式的 Tracing 平台，而那時還沒有這麼多如 Opentracing, Zipkin, Jaeger 等相關的開源專案可以用，所以 Netflix 必須要自己去打造這套系統。
這套系統的組成跟現今常見的架構雷同，Application 本身要透過 Library 來產生出 Tracing 需要的資料，接者透過一套串流處理將資料給傳送到後端的儲存空間，最後則是由UI等相關服務來讀取資料方便使用
本篇文章基於這種架構下去探討 Netflix 的心路歷程，其中幾個比較有趣的問題這邊列出來
1. Tracing 資料的取樣該如何設計，過於頻繁會造成資料空間使用過量，過於稀少則會造成資料不夠完整，這部分 Netflix 採用基於 hybrid head-based 的取樣方式，針對特定區間採用 100% 的取樣方式，而其餘則是根據設定來隨機取樣
2. 資料儲存的部分則是有非常豐富的變化歷史，早期使用 ElasticSearch 後來對其 R/W 的效能感到不滿而輾轉到使用 Cassandra，而 Cassandra 最初使用 AWS 的 SSD 做為底層應用，後來改轉使用 EBS 並且搭配資料壓縮與一些過濾機制， 2021 決定要引入 Storage Gateway 的方式來處理
儲存方面幾乎是每年都在改善與改進，真的要遇到問題才有辦法針對問題下藥，這也是架構方面很難一口氣做到最好，隨者業務與流量擴大，很多現有的架構可能都需要打掉重來才有辦法應付
全文不算太短，但是推薦有興趣的人可以閱讀全文來看看 Netflix 是如何打造這套系統的
https://netflixtechblog.com/building-netflixs-distributed-tracing-infrastructure-bb856c319304
