Details
軟體工程師
Daemyeong Kang
有英文字幕! Redis練習的高容量服務後端指南
「你有沒有想過,像Kakao 、Naver這樣擁有海量學員的IT巨頭,是如何能夠為10萬甚至100萬人提供穩定的服務而不出現故障的?”
沒有地方可以學習如何建構高容量服務
除了已經建立高容量服務的大公司。
所以我帶來了我從開發中獲得的所有經驗
Naver 的 Naver Mail 和Kakao的 KakaoStory。
由來自 Naver、 Kakao和 Udemy 的開發者開發
點擊以了解基本的後端概念!
* 可擴充性:如果刪除額外的伺服器,服務效能必須相應提高。
* 故障復原能力:甚至服務的某些API伺服器、DB伺服器等發生故障,服務也必須持續可用。
* 自動化:服務部署或新增/刪除伺服器應透過腳本自動完成,而不是手動完成。
* 監控:監控至關重要,因為最重要的是了解服務是否正常運作。
* ngrinder:了解服務可以承受多少負載以及瓶頸發生在哪裡很重要。 ngrinder 是負載測試工具。
* prometheus:使用導出器收集服務索引。普羅米修斯儲存它們並顯示它們。
* Grafana: Grafana 用於可視化 Prometheus 收集的指標。
* 負載平衡-ServerSide: ServerSide負載平衡是一種客戶端只看正面實際服務的負載平衡器,負載平衡器將負載分配到後面的服務伺服器的方法。
* 負載平衡-ClientSide: ClideSide負載平衡是客戶端知道實際服務主機List,直接控制負載的方法。
* 服務發現-Zookeeper:一種管理和尋找服務字體以及屬於該服務的伺服器List的方法。
*Circuit Breaker:當外部服務失敗並且響應由於此呼叫而減慢時,允許快速失敗的方法。
*Replication:資料的複製。為了保證服務可用性,需要Replication。
*Failover:當伺服器發生故障時,將服務移交給另一伺服器來取代它。為了確保服務可用性,需要Failover。
*Consistent Hashing:大規模服務中Cache的資料缺失可能會影響服務回應。每當新增/刪除Cache伺服器時,資料可能會消失,而Consistent Hashing可以最大限度地減少資料遺失。
* Sharding-Index:當資料量較大時,將資料分開儲存的一種方法。索引方法很複雜,但它指定每個資料應分配在哪個伺服器上,因此最大限度地減少了資料移動。
* Sharding-Range:應用Sharding的最簡單方法。根據key範圍分配伺服器。
* Sharding-Modular:與Range方法相比,一種均勻分片資料的方法。但是,如果伺服器的可擴展性最終受到限制。
*GUID:在大規模服務中創建Sharding的唯一密鑰非常重要。 GUID有效地創建了唯一的金鑰。
* 非同步Queue:如果將資料從 API伺服器直接儲存到資料庫,它最終會增加資料庫伺服器的負載,就像 API伺服器中的資料變得擁擠一樣。如果使用Queue非同步處理數據,同時控制負載,可以提供更穩定的服務。
* Deploy-BlueGreen:滾動更新所花費的時間隨著部署和回滾情況下伺服器數量的增加而增加。藍綠部署解決了這個問題。
* Deploy-Canary:甚至部署是藍綠的,如果新版本部署到大量伺服器上,一旦出現bug,很多學員也會遇到bug。canary部署僅部署新版本的一部分以防止這種情況發生。
* Timeout:如果在呼叫外部服務時set了錯誤的Timeout值,可能會出現資料重複等問題。這是有關如何防止這種情況的提示。
* Caching-Look Aside:通常,如果Cache中沒有數據,則透過從DB中讀取相應數據來建立Cache。這就是我們所謂的 Look-Aside 快取方法。
* Caching-Write Back: Write-back 方法先將資料寫入Cache,然後再將實際資料儲存在儲存中,因為寫入 DB 會產生負載。根據具體情況,可能存在資料遺失的風險。
*Hot Key問題:當大量資料擠在特定鍵中超過Cache或資料庫伺服器效能容量時,Hot Key會導致問題。解決Hot Key問題的方法有本Cache、使用唯讀副本、多寫讀一等。
Daemyeong Kang是 2016 年第一個在 RedisConf 上發表演講的韓國人,目前在Redis貢獻者中排名第 22 位
(*開源開發專案貢獻者)全世界!
在本課程中,我們將與Daemyeong Kang一起學習建立高容量服務的基本知識以及Redis技術。
Daemyeong Kang,2009 年至 2021 年全球Redis貢獻者排名第 22 位(*截至 2021 年 7 月)
什麼是Redis ,為什麼它很重要?點擊了解!
它是Facebook、Naver、 Kakao等IT巨頭以及BaeMin、Coupang等獨角獸新創公司用來處理來自學員的大規模訊息的分散式Cache技術。 Redis 的優點是可以減少開發人員的工作量,提供快速的速度,同時也提供開發人員可以輕鬆使用的資料結構。
4課程練習
-
實踐1.服務發現
(#可擴展性#FaultResilience #自動化)透過重複新增和刪除Callee,我們可以看到Caller自動識別並處理它。
透過此過程使用服務發現,當新增/刪除伺服器時,您可以了解到Caller可以自動反映它,而無需更改任何其他設定。 -
實踐 2.Consistent Hashing
(#故障恢復)透過新增/刪除充當Cache的Redis伺服器的練習,您可以親眼看到,由於Consistent Hashing,資料分佈被最小化。
在大規模服務中,甚至遺失的數據是Cache數據,效能也會下降。如果使用Consistent Hashing,實際上可以看到甚至添加/刪除Cache伺服器,Cache資料遺失也減少了,並且可以稍後應用!
-
實踐 3. 自動化我將向您展示使用Ansible和Terraform上傳簡單 GeoIP 服務的流程。透過建立 1 個AWS來部署 GeoIP伺服器。
這個過程表明,相同的基礎設施總是可以“自動化”,並且透過 IaC(Infrastructure as Code)輕鬆建置和部署,而不是手動建置它。了解 IaC 對於建立大規模服務至關重要。 -
實踐 4. 監控要求一個grafana儀表板,您可以在其中監視基本節點,部署一個簡單的GeoIP並透過prometheus簡單地監視結果。
如果超過set值發生錯誤,將透過 Slack 發送通知。監控對於查明是否發生故障至關重要。了解應從課程上監控哪些資訊。
*這些是示例圖像,以便更好地理解。
軟體工程師
Daemyeong Kang
故障隨時隨地發生。所以關鍵不是防止服務故障,而是在故障發生時快速找到故障原因,或是故障復原的速度有多快。
大規模服務的發展最終取決於服務擴展的難易度,以及建構能夠輕鬆應對故障的結構。然而,僅僅聽一次課程並簡單地學習是很難應用的。
所以在這課程中,我會透過練習向大家展示大規模服務開發所必需的基礎知識,以及真正影響性能的物件,幫助大家提高理解,並將其運用到實際工作中。
軟體工程師,
Daemyeong Kang
[現職的]
• 2021 年
LemonTree /軟體工程師
- 管理AWS Infra設計與實施服務架構的Tech Lead Managing
• 2020 ~ 2021
Weverse本公司/軟體工程師
-Data Pipeline管理(EMR、Databricks、Snowflake、Structured Streaming、Kafka)
-Airflow管理與DAG開發(k8s)
- 透過 Databricks DeltaLakeChanged Data Capture處理
- BI服務Backend API設計與實作伺服器
• 2017 ~ 2020
Udemy /軟體工程師
-Data Pipeline管理
- Data Pipeline OnPremise 遷移至AWS
- GDPR相關處理
• 2013 ~ 2017
Kakao /軟體工程師
- Kakao Story發展
- Kakao Home開發
• 2008 ~ 2012
Naver /軟體工程師
- Naver郵件開發
- Naver Windows行動應用程式開發
• 2002年~2008年
FINALDATA/軟體工程師
-Final Forensics
可識別
項目及獎項
[前職的]
<書籍>
• 2002年~2008年
- Redis Operation Management(Hanbit Media)
- 用於建構高層的 Memcached 和Redis
容量伺服器(Hanbit Media)
- Windows Network Programming(Daelim)
<課程>
• 2019 ~ 2020
- 釜山大學SW教育中心
-DevGround Junior
- Woowahan Redis (Woowahan Brothers)
- 安東大學公開SW Camp
- 國內在職人員公開SW班
-NetMarble
- 慶北國立大學
• 2017 ~ 2018
- 首爾國立科技大學
-KOSSCON
-Kakao
- SW Maestro
-Zum internet
-Hanium
• 2013 ~ 2016
- Redis Conf 2016(舊金山)
- NHN
-Hanium
- Naver D2SF
-Open SW Day
-Deview 2014
-NDC 2014
課程亮點
讓我們先來看看 Daemyoung Kang 的Redis練習「Multi-Write Read One」方法。
當發生Hot Key時,甚至高效能的伺服器Cache無法接收超出其容量的資料。
為了解決這個問題,您是否知道可以使用 Multi-Write, Read One 方法來解決這個問題,即在幾個位置寫入快取並隨機讀取Cache?
該問題是透過以下過程解決的。
- 設定Redis
-Cache Write儲存在 2 個位置。
-Cache Read從 1 個位置讀取。
▼ 透過以上的過程和練習,你就可以學會『這個』了! ▼
在大規模服務中,可能會出現熱鍵,即對Cache提供的效能進行更多存取並降低效能。您可以了解如何處理熱鍵以防止效能下降。
- Unlimited Access
- Best Price
Buy now, get unlimited access.
12/31 (Sat) (UTC-7) Special offer ends soon.
This special offer ends soon.
Buy now and save!
課程
深入觀察
訪談
Daemyeong Kang
“我正在Weverse本公司參與一個針對全球競爭激烈的娛樂行業的全球學員的開發項目。”
我負責製作一個Data Pipeline,從 Weverse 和 Weverse Shop 收集數據,Weverse Shop 是一個全球社群和服務平台,為 Weverse本公司的藝術家和粉絲、內容和服務提供交流。將收集到的資料進行處理,以便資料分析師可以對其進行分析。日誌可以穩定地處理有關存取 Weverse 和 Weverse 商店的學員數量以及他們採取的操作的資料。
“我參與了 Naver 的行動應用程式/Mail、 Kakao的 KakaoHome/KakaoStory 的開發專案。”
我也能夠在 Naver 和Kakao中使用許多Cache伺服器。我還嘗試處理記憶體超過 3TB 的 Memcached 伺服器和記憶體超過 5TB 的Redis伺服器。我還致力於在一個日活量超過 1000 萬的服務上將 Ruby 轉換為 Java,這通常被描述為更換經營的火車的輪子。在大規模服務中,很好地解決問題很重要,但我了解到我必須盡可能地自動化從簡單到困難的物件,並監控盡可能多的物件才能運行服務。
「在我 20 年的開發生涯中,我總是經歷新的失敗。”
在一個月活躍用戶數超過1000萬的服務中,一天之內就會有多台伺服器無緣無故出現故障。在某些故障中,我必須使用 Linux 核心原始碼實際找出並修復為什麼在 32 位元核心中使用 RAM 磁碟時核心記憶體耗盡,為什麼伺服器經營時在某些連接埠帶可能會崩潰。我還遇到過 DNS 快取問題、從 Java 1.7 升級到 1.8 時發生的內部問題引起的問題、美國東部和西部之間的延遲問題以及韓國地區之間的延遲引起的問題。在 Udemy,我在將服務從本地轉移到AWS時遇到了很多問題。
“Redis是我的秘密武器。”
目前,高容量服務隨著各種社群媒體服務(包括網路服務)而增加。正因如此,人們對大容量資料處理技術的興趣與日俱增。分散式Cache技術可以分散伺服器並承受大量流量,在建立高容量伺服器方面發揮關鍵作用。所以我認為Redis不僅可以成為我的秘密武器,而且可以成為所有後端開發人員的秘密武器。透過這次課程,我想幫助很多後端開發人員,讓他們能夠輕鬆工作。
您會向誰推薦這課程?
我認為這個課程對於那些願意從事後端開發人員,或者有1~5年經驗的初級後端開發人員來說是最有幫助的。
具體來說,第一部分是針對初學者的,第二部分是針對初級人員教授大規模服務相關的實際知識的。如果你有實際工作經驗,我建議你專注於第三部分,它涉及實際工作中需要思考的事情。
這課程所需的背景知識基本上就是知道什麼是後端。對於有創建簡單 Web 服務經驗的人來說,課程會更容易理解。
如果您參加了這門課程,我相信您一定會獲得建立大規模服務所需的所有知識。
所需軟體
本課程將使用 Linux 或 Mac、Python 3(3.8.6)、 Ansible、 Terraform、 AWS 帳戶和存取鍵。
請購買並安裝這些軟體以獲得最佳的課程體驗。
*這些軟體和/或材料不會隨課程一起提供。
※關於Mac和Windows的可用性,課程是在Windows(Windows 10,64位元)上拍攝的,但實際練習是在Mac或Linux上完成的。
(我將遠端打開一個 Linux伺服器並展示進行方式的。)
※練習時有使用AWS伺服器的物件,但需要AWS帳戶,且為付費服務。不過,大部分練習都可以在地完成。(只有少數練習需要在AWS上完成。)
