智能擴展：成功使用雲原生技術擴展基礎架構的4個關鍵技巧
作者：Reda Benzair
今天的帖子來自CNCF大使兼Streamroot工程副總裁Reda Benzair。文章最初在Streamroot技術開發者的博客上發佈。
在這篇文章中，我想與工程經理和後端團隊分享一些高級別的要點，以幫助他們成功擴展業務，同時避免一些最常見的陷阱和短視決策。
本文伴隨Streamroot首席後端工程師Jordan Pittier發佈的第一篇文章，以及我們去年11月在HighLoad Moscow的歷程演講。這些分享了我們在從基於VM的架構遷移到基於容器的架構，以及將我們的基礎架構遷移到運行在Google Cloud上的Kubernetes的整個過程中所面臨的經驗和挑戰。
介紹和背景
首先，我將向你介紹Streamroot的一些背景知識，以及爲什麼我們花時間調整我們的Kubernetes Engine架構，不僅要擴展規模，還要使我們的架構更具容錯性。
Streamroot是一家爲主要內容所有者提供服務的技術供應商 - 媒體集團、電視網絡和視頻平臺。我們的點對點視頻傳輸解決方案爲廣播者提供了更高的質量和更低的成本，並與現有的CDN基礎設施協同工作。
去年我們（以及我們客戶）面臨的最大挑戰之一是擴大到FIFA世界盃的破紀錄的觀衆。事實證明，2018年世界盃是有史以來規模最大的直播賽事，Akamai在峯值時的記錄的速度爲22 Tbps，超過了之前超級碗記錄的兩倍。Akamai測量的峯值量超過22 Tbps。這是他們在2014年看到的峯值的3倍。
Streamroot爲法國最大的私人廣播公司TF1，以及南美洲的國家電視網絡提供了世界盃。爲了能夠以這種規模爲我們的客戶服務，我們需要擴展我們自己的Kubernetes引擎並能夠更快地擴展。我們需要：
- 處理大量流量，每分鐘有數十萬個請求到我們的後端
- 在每屆世界盃比賽開始時，在幾分鐘內達到巨大的峯值
- 確保100％防故障、完全容錯、堅固的後端能夠承受任何故障。作爲一名體育愛好者，我知道在現場直播期間甚至有兩分鐘的停機時間是完全不可接受的...
最後但並非最不重要的是，我們必須通過只有少數後端工程師的創業規模團隊完成所有這些工作...
如果你對我們過去幾個月的擴展歷程感興趣，並希望深入瞭解技術細節，你可以在Jordan Pittier和Nikolay Rodionov在莫斯科舉行的HighLoad++會議演講，以及我們的幻燈片中查看。
技巧＃1：新事物並不總是好事：使用雲原生技術輕裝上陣。
自加入雲原生計算基金會（CNCF）以來，Kubernetes已呈指數級增長，對這一複雜解決方案的興趣日益濃厚，這是一種開源雲原生技術的組合。去年12月，CNCF的KubeCon + CloudNativeCon在西雅圖集合了來自世界各地的8000多名與會者。
Kubernetes是雲原生技術組件之一。還存在許多其他組件，有一些在CNCF託管（https://landscape.cncf.io/），有一些在CNCF之外，如Istio。
雲原生技術還很年輕，每月在不同領域涌現出各種新組件：存儲、安全性、服務發現、軟件包管理等。
我們的建議：謹慎使用這些新組件，並保持簡單（、傻瓜）。這些技術是新的，有時仍然比較粗糙，並以令人難以置信的速度發展。嘗試使用所有最新的閃亮技術是沒有意義的，特別是在生產中，除非這些技術是出於真正的需要。即使你擁有龐大的優秀工程師團隊，你也需要考慮維護、運營和調試這些有時缺乏穩定性的新技術的成本（資源和時間）。
作爲經理和CNCF大使，我建議遵循CNCF分類（https://www.cncf.io/projects/）來選擇具有足夠成熟度級別的原生組件。CNCF定義的標準包括採用率、壽命以及是否可以依賴開源項目來構建生產工具。今天，Streamroot只利用了3個項目（Kubernetes、Prometheus和Envoy），這些項目處於成熟水平，並根據CNCF基金會已經“畢業”。那裏的大量組件仍處於孵化階段或沙箱階段。你仍然可以使用這些，但請記住，你將面臨一些風險：穩定性、錯誤、有限的社區、學習曲線等。
最重要的是，要明白，即使可能普遍相信孵化或沙箱階段的所有原生項目都可以填補空白併成熟生產，但這也需要考慮不會增加架構複雜性的問題。在從CNCF或CNCF外部添加任何新組件之前，請務必先問自己以下事項：
- 我真的需要這個組件嗎？
- 我在解決一個真正的基礎設施問題嗎？
- 我的工程師現在和從長遠來看能夠應付它嗎？
圖：CNCF分類
技巧＃2：控制你的成本
當啓動一個重要的項目，比如將服務從基於VM的服務，轉移到Kubernetes支持的基於容器的體系結構時，你的主要關注點可能不是成本，而是成功遷移。雖然你的後端成本可能不是一個即時或中期的問題，但從第一天開始就要考慮到這一點。我強烈建議你儘早跟蹤Kubernetes Engine擴展成本，原因如下：
- 清楚地瞭解你的資源使用情況和軟件效率。後端團隊的主要關注點是交付，從管理角度來看，通常很難傳達高效軟件和資源使用的重要性。
- 在你的架構中發現改進的空間。對來自監控和成本進展的信息進行三角測量，有助於我們確定架構的改進。通過簡單地使我們的實例適應我們的使用，並更好地瞭解資源的使用和消耗方式，我們能夠將成本降低22％。
- 利用基於數量的成本節約。大多數雲供應商（包括Google Cloud和Amazon AWS）都會爲提交的實例提供有趣的折扣。不要猶豫，爲你的利益使用基礎設施成本覈算（和減少）。一旦達到一定的支出，即使降低10％的成本，也可以在預算中增加幾千甚至幾十萬美元，這可以用來派遣你的團隊參加會議，甚至可以僱用一個新資源來構建你的產品更快！
爲了說明我的第三點，GCP提供持續使用折扣選項，爲長期承諾的實例提供顯着折扣。例如，如果你承諾一整年的資源，你可以獲得30％的折扣（就只一次，實際上很高興在月底看到賬單！）。這些折扣最高可達57％（！），爲期3年。當然，我建議在承諾任何內容之前至少等待6個月，以便確定你最少使用的平均CPU和RAM資源。
別怕！你無需成爲公司財務或計費方面的專家即可有效跟蹤你的成本。例如，如果你希望跟蹤每月使用情況，則可以默認爲每個項目啓用費用提醒，然後使用CSV導出功能輸入你喜歡的電子表格工具。或者，在GCP上，你可以啓用Bigquery Billing Export選項，以便每日導出資源消耗的所有詳細信息。然後，花幾分鐘時間構建一個帶有SQL導出或Excel的簡單儀表板（不要忘記讓工程師正確設置資源標籤以識別不同的行）。
技巧＃3：隔離並保持你的生產安全
許多博客和文章建議你僅使用一個K8羣集，但爲不同的環境使用不同的命名空間（例如，Dev、Staging和Production）。命名空間是一個非常強大的功能，可以幫助你組織Kubernetes資源並提高團隊的速度。但是這種設置並不容易：你需要確保有一個完善的CI/CD環境，以避免你的staging和prod環境之間的任何干擾，以及像部署錯誤組件在錯誤的命名空間中的“愚蠢”錯誤。讀到這篇文章時，你可能會想：“當然，但我們有一個超級聰明的團隊，所以我們能夠處理它。”在那裏停一停：每個人都犯愚蠢的錯誤，錯誤越愚蠢，它會發生的機會越多...所以，除非你想要在生產中救火過最緊張的日子，只因爲你在那裏推動了一個Staging版本，如果使用命名空間的選項，你必須花幾周的時間建立一個頂級的CI/CD工作流程。
在我們這邊，我們選擇了另一個選項來保持我們的環境分離：我們決定爲我們的登臺（Staging）和生產環境創建完全自治的集羣。這消除了人爲錯誤和安全性故障傳播的所有風險，因爲兩個集羣都是完全隔離的。這種方法的缺點是它會增加你的固定成本：你需要更多的計算機來保持兩個集羣的正常運行。但它帶來的安全和安心對我們來說是非常值得的。
此外，你可以通過使用GCP的短暫實例來降低成本開銷，這比普通實例便宜80％。當然，這有一個問題：如果Google Cloud需要其他客戶，那麼這些實例可能會隨時關閉。但是當我們僅將它們用於我們的臨時環境時，丟失一臺機器並不會真正影響我們，我們甚至學會了利用它來發揮我們的優勢。對我們來說，完美的測試是看看我們的架構如何對我們的一個組件的隨機故障作出反應：一種完全不可預測的紅隊試圖摧毀系統，由Google Cloud免費提供給你
技巧＃4：從一開始就統一併自動化你的工作流程
當你開始一個新項目時，你考慮的最後一件事是如何與其他開發者共享代碼，或者在需要執行緊急回滾時如何在生產和Staging之間推送構建。這是正常而且非常明智：在你真正構建了可以向世界展示的任何東西之前，沒有必要進行過度優化。但另一方面，讓這些問題潛伏在永恆中是一個常見的錯誤。因爲你沒有時間，需要發佈下一個功能，使你的產品最終跨越鴻溝並神奇地帶來數百萬用戶。我對此的建議是花時間儘早創建一個簡單有效的工作流程。
首先，一旦你開始與其他人合作，你應該退後一步，創建一個統一且易於轉移的開發環境。10年前，這不是一件容易的事：你需要在每個人的計算機上配置特殊虛擬機，或者在Mac和Windows用戶之間進行修改。這是一場真正的噩夢，並引發了許多不必要的和調試不了的問題。今天，多得了像Docker這樣的容器化工具，它可以在不到幾天的時間內完成，那麼爲什麼不從一開始就實現呢？這將大大簡化所有開發者的生活，並使新員工的入職變得簡單直接。對於你將節省的所有調試和設置週數來說，這是一筆非常小的投資。
其次，一旦你有生產流量，就應該考慮創建一個簡單但有效的QA/CI/CD工作流程。不需要過早設計過度，但我們非常幸運地生活在自動化和CI工具的黃金時代，這使你可以毫無困難地實現自動化的一流CI和CD。符合kubernetes API的CI工具列表很長，例如10.1版GitLab引入了與Kubernetes或Jenkins X的集成。大多數公司爲小規模項目提供低成本計劃，併爲開源項目提供免費計劃，所以你真的沒有任何藉口不使用它們！這不是火箭科學，它將爲你節省時間、精力和無數頭痛，讓你的開發者的生活更輕鬆！
總結一下
Kubernetes和雲原生提供了出色的技術，可以簡化和支持在雲上構建可擴展且靈活的解決方案。不久之後，我們將Kubernetes視爲雲技術中無處不在的一部分，就像我們現在使用Linux和TCP/IP等技術。
由於我們成功地遷移到這些服務，我們能夠將我們的基礎設施持續擴展到世界盃觀衆及其他人。在歷史上規模最大的體育賽事中，我們提供超過1.2 Tbps的流量，零停機時間 - 所有這一切都只有兩名後端工程師。我們現在能夠處理數百萬觀衆的視頻流，峯值每秒有數萬個新請求到達。
歸功我在本文中討論過的最佳實踐，我們不僅能夠從架構、成本和資源角度實現我們的短期交付目標，還能實現基礎架構的長期可擴展性。總結我們的主要內容：
- 當工具符合實際需要時，請小心謹慎地使用Kubernetes和雲原生。
- 今天就想想未來，無論是成本、分離環境還是實施自動化工作流程。從第一天開始就把這些挑戰有效地融入你的項目中，當這些考慮成爲關鍵任務時，你將浪費更少的時間資源進行調整。
作爲一家初創公司，我們一直在努力不斷改進我們的技術和工作流程，並且在我們的擴展過程中學到的所有經驗教訓之後，我們期待着應對下一個挑戰：構建多雲架構！
KubeCon + CloudNativeCon + Open Source Summit大會日期：
- 會議日程通告日期：2019 年 4 月 10 日
- 會議活動舉辦日期：2019 年 6 月 24 至 26 日
KubeCon + CloudNativeCon + Open Source Summit贊助方案
KubeCon + CloudNativeCon + Open Source Summit多元化獎學金現正接受申請
KubeCon + CloudNativeCon和Open Source Summit即將首次合體落地中國
KubeCon + CloudNativeCon + Open Source Summit購票窗口，立即購票！
CNCF邀請你加入最終用戶社區