在线观看www成人影院-在线观看www日本免费网站-在线观看www视频-在线观看操-欧美18在线-欧美1级

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

上云還是下云:章文嵩博士解讀真正的云原生Kafka十倍降本方案!

jf_WZTOguxH ? 來源:AI前線 ? 2023-12-08 15:52 ? 次閱讀

近日,AutoMQ 團隊發布了基于云的開源云原生 Kafka——AutoMQ for Kafka,所有的代碼采用 Apache 2.0 開源許可。AutoMQ 充分挖掘了云原生的技術紅利和成本優勢,再結合 Serverless 彈性技術,實現了 Apache Kafka 十倍的降本增效。本文從技術架構的角度,來揭秘 AutoMQ 為 Kafka 量身打造的云原生十倍降本方案。

今天,我們看到云計算帶來了兩個趨勢,一個是“上云的趨勢”,另一個是“下云的趨勢”,相信大家都關注到了最近 X(原 Twitter) 全力“下云”,成本降低了 60%。“上云”亦或是“下云”,到底誰在節約成本,誰在增加成本,這其中的差異可能三言兩語很難講清楚,但就 AutoMQ 核心團隊在阿里云多年的工作經歷來看,頭部云廠商一直是以“讓算力普惠、釋放技術紅利”為使命的,那到底為什么“上云”會給企業一種更貴的感受呢?

AutoMQ 團隊認為這其中最主要的差異在于云原生(Cloud Native)和云托管(Cloud Hosted)的差異。以云托管的姿勢上云,最終會發現云上成本比自建機房還高,將傳統的軟件架構 Rehost 到云上,其本質是將 IDC 架構平移上云,是無法發揮出云基礎設施的規?;瘍瀯?,也享受不到成本紅利。只有以云原生的姿勢上云,充分利用云的彈性能力,服務化的產品和自動化的 API,才能做出云上最優的成本解決方案。

云原生的能力

在引出 AutoMQ 為 Kafka 打造的云原生架構之前,我們先來看一下云的基礎設施已經進化到什么程度了,有哪些能力和優勢是跟成本息息相關的,而且是傳統的 IDC 架構無法充分利用起來的。

服務化的產品

云計算技術迭代的路線可以總結為:云先用軟件定義硬件,再把軟件變成了服務。所以,我們今天看到網絡環境變成了 VPC,存儲介質變成了云盤,物理主機變成了虛擬的云主機 ECS。

這些云提供的基礎產品在今天已經蛻變成了服務,服務一定是具備生產可用的 SLA,比如阿里云單個 ECS 實例的可用性達 99.975%,這意味著一個單節點的微服務也可以是生產可用的,這在 IDC 環境是無法想象的事情。再例如云盤 EBS,相對于物理存儲介質,EBS 天然具備 3 副本,提供 5 個 9 ~ 9 個 9 的數據可靠性,同時具備可用區內和區域內的容災能力。

所以,我們今天做云原生架構,第一個共識就是需要意識到,基于云的架構設計已經從依賴軟硬件,變為依賴云服務了,真正的云原生架構一定要充分發揮出云產品的服務化能力。

彈性

彈性可以說是云最大的優勢,云積累了大規模的算力,給了單個租戶無限計算資源的視圖,云原生的架構完全可以假設,在云上一切資源都是無限的,都是唾手可得的。

對于 IDC 環境,因為機器資源至少月級的交付時間,傳統的軟件架構并不會面向彈性能力進行設計,一般都會假設保有一定的機器資源來提供軟件服務。這也意味著,當傳統的軟件 Rehost 到云上后,也是以預留資源的形式使用云資源,一方面存在資源的極大浪費,另一方面也無法享受到云的彈性能力。

不難發現,彈性能力的來源并不是資源交付時間變快了,完全是因為云廠商通過預留大量資源實現了租戶級無限的彈性的能力,所以說“世上本沒有真正的彈性,都是云廠商在負重前行”。正因為這樣,云廠商各個地域都有大量的閑置資源,云廠商為了盡可能將閑置的資源轉換為營收,推出了 Spot 計算實例,Spot 類型的實例相較于正價的 ECS 實例,至多有 90% 的成本節約。如何充分發揮出 Spot 實例的成本優勢,也是云原生架構需要重點考慮的地方。

API 定義一切

云計算所有的能力都是通過 API 來進行描述的,比如用 API 創建一臺 ECS,用 API 重新掛載一塊云盤,用 API 去調整云服務的 Quota 和 Limitation。

正因為此,云原生的軟件有機會利用 API 去編排資源,去實現 Auto Scaling,實現容災的切換。通過利用云的 API 完成軟件核心的能力建設,甚至容災能力的建設,這也是傳統的軟件架構無法辦到的事情。

云服務依賴選型

云廠商提供了數百種的全托管云服務,但這些云服務成熟度完全不一樣,不少小的云服務研發團隊僅僅有個位數的人力投入。所以,我們在進行云原生架構設計時,需要謹慎進行云服務依賴選型,我們總結了兩個原則:

選擇云廠商投入最大、規模最大的云服務,這類服務成熟度往往是最高的,不能單純看云廠商承諾的 SLA。

選擇標準化的云服務以避免廠商鎖定,我們設計的云原生架構必須是所有云的原生架構,而不能單純是某朵云的原生架構。

在這兩個原則的約束下的云服務,也是云廠商真正釋放云原生能力的出口,它們往往有以下幾個特征:

真正的按量計費,以最小的資源粒度按使用量進行計費,比如 Lambda 按調用次數計費,沒有任何保有成本。將實例規格包裝成按時間進行計費不是真正的按量計費。

無限的容量,給單個租戶的視圖一定是無限的容量,無限的存儲和計算資源,業務再也不需要進行容量評估了。

低成本,真正地通過技術而不是通過虧損,通過規模去優化成本,比如對象存儲 S3 是業界最便宜的存儲產品之一。

選擇性地依賴云服務,可以讓我們的云原生架構更加靈活,充分享受到云的紅利,多云原生的靈活度,更高的穩定性保障。

AutoMQ 云原生架構

AutoMQ 將消息和流存儲最流行的兩款開源軟件 Kafka 和 RocketMQ 基于云重新設計,將這兩款面向 IDC 進行架構的軟件帶向云原生領域。Kafka 和 RocketMQ 的核心分別是流存儲和消息存儲,對于存儲類型的軟件,要完全把云的能力用起來并不是一件容易的事情。

AutoMQ 在進行 Kafka 和 RocketMQ 重新設計之初,就定義了幾個設計目標:

盡可能發揮出云的彈性能力,將彈性作為核心能力去設計,根據負載變化系統能進行彈性伸縮。

盡可能使用 Spot 實例,Spot 實例有隨時被中斷的風險,能否實現存儲軟件的“無狀態”是能否利用 Spot 實例的關鍵。

盡可能將數據全放在對象存儲上,S3 極具成本優勢,存儲系統降本的關鍵一定在于能否將 S3 的能力發揮到極致。

盡可能利用 EBS 的低延時和高性價比,解決業務對數據寫入的低延時需求,通過 EBS 和 S3 組合出高可用能力即可提供低成本、高可用和高可靠的存儲服務。

結合云已經有的能力,以及我們對流存儲和消息存儲軟件的理解,我們設計了一套真正的云原生架構,同時滿足了以上幾個設計目標。

7a877728-9592-11ee-8b88-92fbcf53809c.png

該架構主要包含三個核心設計思想。

一、存算分離至服務

存算分離擁有狀態卸載、彈性等好處,這已經是行業共識,但如何實現存算分離沒有統一的方案,我們今天認為存算分離的核心是將存儲分離至服務而不是軟件。如果,我們為了存算分離將存算一體架構的存儲部分,分離出一套分布式存儲軟件,這會帶來額外的部署、運維以及治理的復雜度。

RocketMQ 早期的架構是完全零依賴,正因為架構極簡,讓它在生產系統的實際可用性非常高,今天存算分離的優勢已經被眾多開發者所喜愛,但是任何一個軟件的可用性是由軟件本身和后臺運維的工程師組成,如果這個軟件還依賴其他軟件,那么它就類似一個串聯電路,任何一個環節出問題,就會影響最終用戶,尤其是依賴一個無人運維的存儲系統,更是會讓整個系統的復雜度和可用性失控。而云廠商的對象存儲、塊存儲等大規模使用的系統背后有全世界最優秀的工程師在運維,理論上這樣的系統一定是可用性最高的。

另外一點就是存儲能否做到完全卸載,有些觀點認為多級存儲也是存算分離,實際上業界大部分多級存儲方案都有很重的一級存儲,一級存儲包含了大量的存儲狀態。如果無法做到存儲的完全分離,也就無法將存算分離的彈性優勢發揮到極致。

我們對存算分離理念的實踐都體現在 S3 Stream 這一基于 S3 的流存儲庫之上,S3 Stream 組合 EBS 和 S3 的能力,實現了低成本、高可用、高可靠以及無限容量的流存儲能力,更多的技術細節詳見我們的文檔(https://docs.automq.com/)。

二、共享存儲優于 Shared Nothing 架構

Shared Storage 和 Shared Nothing 架構各有優劣,但今天在云上,存儲已經變得彈性,容量近乎于“無限”,我們認為共享存儲是一個更優的架構。

通過將存儲單元進行共享,狀態可以快速轉移,分區遷移、節點擴縮容將變得非常簡單。共享存儲也是云原生架構能否充分利用 Spot 實例的關鍵。

三、可靠性與可用性實現

回到 Kafka 和 RocketMQ 的核心能力上,這兩款軟件都自帶多副本機制,目前分布式架構不管是 Raft 共識算法還是其他變種的副本機制,都是通過副本的冗余,一方面實現數據的高可靠,另一方面多余的副本可以快速提供故障轉移的能力,從而實現高可用。

但在云上,云存儲 EBS 已經自帶 3 副本了,如果上層應用繼續采用復制的方案,將帶來 9 副本的數據冗余,以及多倍的存儲和網絡成本。所以,在 Kafka 和 RocketMQ 層面沒有必要自己實現 3 副本。另外,EBS 是第二大存儲系統,僅次于第一大存儲系統 S3,云廠商對 EBS 進行深入的軟硬一體優化,把 EBS 客戶端卸載到神龍 CIPU(智能網卡)通過硬件來做,EBS 客戶端跟 EBS 服務器的通訊針對數據中心內低延時低丟包率的特點實現自定義的傳輸協議而不是用 TCP,這些軟硬一體優化帶來的效果遠遠好于自己搭建的 3 副本高可靠系統。還有,在云上使用 EBS 來存儲不消耗網絡帶寬,自建的 3 副本復制會大量消耗網絡帶寬。

鑒于此,AutoMQ 提出了服務的可靠性與可用性實現方案,依賴 EBS 的可靠性,可以采用單個寫入計算節點,把數據先寫入到存儲在 EBS 裸設備的 WAL 中,若當前寫入計算節點故障了,其他計算節點接管這個 EBS,從 WAL 中恢復數據。通過基于 EBS 的 Detach/Attach API 以及 NVMe 相關的 API 實現一次只有一個計算節點可以寫入 EBS,確保 EBS 數據寫入的一致性。

架構優勢

AutoMQ 云原生架構為 Apache Kafka 帶來了單副本高可用,秒級分區遷移,持續數據重平衡,分鐘級平滑擴縮容等技術架構優勢(更多細節參看官方文檔)。

7aaa2836-9592-11ee-8b88-92fbcf53809c.png

十倍降本增效解讀

AutoMQ 團隊將云原生架構的技術優勢,兌現為成本優勢和運維效率,為 Apache Kafka 帶來的十倍的降本增效。

7ab79386-9592-11ee-8b88-92fbcf53809c.png

運維效率提升

Kafka 運維有兩個痛點,給運維人員帶來了極大的運維成本:

分區遷移,Kafka 遷移分區需要進行數據復制,一方面額外的復制流量對生產環境會產生穩定性影響,另一方面復制耗時一般比較長,導致遷移分區的操作需要長時間進行觀察,以確保系統達到終態。

擴容,當 Kafka 集群流量不足時,運維人員需要對集群進行擴容,但擴容后的節點無法承擔任何流量,需要從其他節點移動分區過來,也就是說擴容需要移動大量的分區,才能達到流量的重平衡。擴容操作需要提前擴容,如果在業務高峰時進行擴容是無法緩解生產壓力,反而會進一步將生產集群推向高風險狀態。

AutoMQ 的云原生架構得益于將存儲狀態卸載到共享存儲上,移動一個 TB 級的分區能將時間從 3 小時縮減為 1.5 秒,擴容后流量重平衡時間從 43 小時縮減為 1 分鐘,成功地將 Kafka 高風險的常規運維動作,變成了可自動化,基本無感的低風險運維操作,大幅度降低了運維人員的工作負擔。

計算和存儲降本

成本方面,我們提供了一個 80 MB/s ~ 1 GB/s 的彈性工作負載用于壓測真實的云賬單,在該負載下,AutoMQ 提供的云原生 Kafka 版本每月僅需 5632 元,相比于自建 Apache Kafka 承擔該負載需要 62,431 元,AutoMQ 的云原生架構成功降本 11.09 倍。AutoMQ 獲取成本優勢的核心主要有幾點:

充分利用對象存儲和 EBS 的低成本特性,將存儲成本降低了 90%。

通過無狀態的架構設計,內置 Auto Balancing 組件,實現自動擴縮容能力,再充分利用 Spot 實例,能做到計算成本降低 11.09 倍。

近期,我們發布了完整的成本分析報告,詳情見 AutoMQ 的官方文檔。

總結

AutoMQ 團隊通過對 Apache Kafka 進行全新的云原生架構設計,成功做到了 10 倍的降本增效,充分驗證了真正的云原生架構是能充分發揮云的規?;瘍瀯莸?,能做到超出預期的、十倍的降本效果,能大幅度降低運維復雜度,真正做到共享云的一切優勢。

云計算,開辟了一個新的時代,以云原生的姿勢上云,是不會有下云的憂慮,我們堅信,所有的基礎軟件,都值得基于云重新設計,以發揮出云全部的優勢。

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • 架構
    +關注

    關注

    1

    文章

    519

    瀏覽量

    25553
  • 云盤
    +關注

    關注

    0

    文章

    37

    瀏覽量

    9828
  • kafka
    +關注

    關注

    0

    文章

    52

    瀏覽量

    5243

原文標題:上云還是下云:章文嵩博士解讀真正的云原生 Kafka 十倍降本方案!

文章出處:【微信號:AI前線,微信公眾號:AI前線】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏

    評論

    相關推薦

    云原生AI服務怎么樣

    云原生AI服務,是指采用云原生的原則和技術來構建、部署和管理人工智能應用及工作負載的方法和模式。那么,云原生AI服務怎么樣呢?下面,AI部落小編帶您了解。
    的頭像 發表于 01-23 10:47 ?112次閱讀

    華為 FlexusX 實例Kafka 集群部署實踐與性能優化

    前言 華為 FlexusX 實例,以創新的柔性算力技術,為 Kafka 集群部署帶來前所未有的性能飛躍。其靈活的 CPU 與內存配比,結合智能調度與加速技術,讓 Kafka 在高并發場景
    的頭像 發表于 01-07 17:23 ?185次閱讀
    華為<b class='flag-5'>云</b> FlexusX 實例<b class='flag-5'>下</b>的 <b class='flag-5'>Kafka</b> 集群部署實踐與性能優化

    云原生LLMOps平臺作用

    云原生LLMOps平臺是一種基于計算基礎設施和開發工具,專門用于構建、部署和管理大型語言模型(LLM)全生命周期的平臺。以下,是對云原生LLMOps平臺作用的梳理,由AI部落小編整理。
    的頭像 發表于 01-06 10:21 ?110次閱讀

    什么是云原生MLOps平臺

    云原生MLOps平臺,是指利用計算的基礎設施和開發工具,來構建、部署和管理機器學習模型的全生命周期的平臺。以下,是對云原生MLOps平臺的介紹,由AI部落小編整理。
    的頭像 發表于 12-12 13:13 ?163次閱讀

    梯度科技入選2024云原生企業TOP50榜單

    近日,國內專業咨詢機構DBC德本咨詢發布“2024云原生企業TOP50”榜單。梯度科技憑借自主研發的“梯度智能平臺”入選該榜單,彰顯公司在該領域的行業競爭力。
    的頭像 發表于 12-06 11:35 ?331次閱讀

    容器服務引擎是什么意思?

    容器服務引擎是什么意思?容器服務引擎是一種基于云原生架構的容器編排工具,能夠幫助用戶快速構建、部署和管理容器化應用。它支持容器化應用的全生命周期管理,包括部署、管理和擴展,旨在簡化云原生
    的頭像 發表于 10-19 17:08 ?210次閱讀

    容器服務引擎是什么?如何使用

    容器服務引擎(CloudContainerEngine,簡稱CCE),是一個企業級的Kubernetes集群托管服務,提供高度可擴展、高性能的云原生應用部署和管理方案。容器服務引擎
    的頭像 發表于 09-30 10:17 ?242次閱讀

    云原生和非云原生哪個好?六大區別詳細對比

    云原生和非云原生各有優劣,具體選擇取決于應用場景。云原生利用計算的優勢,通過微服務、容器化和自動化運維等技術,提高了應用的可擴展性、更新速度和成本效益。非
    的頭像 發表于 09-13 09:53 ?465次閱讀

    KubeCon China 2024全球大會在香港舉行,京東受邀參加探討云原生、開源及 AI

    和數字化大潮一樣,在AI化的革命,云端也在全面擁抱AI,并在方方面面變得更安全、更高效,讓全球各行各業受益。2024年8月21日,由云原生計算基金會(CNCF)和?Linux?基金會聯合主辦
    的頭像 發表于 08-23 13:42 ?383次閱讀

    京東云原生安全產品重磅發布

    “安全產品那么多,我怎么知道防住了?”“大家都說自己是云原生的,我看都是換湯不換藥”在與客戶溝通云原生安全方案的時候,經常會遇到這樣的吐槽。越來越的客戶已經開始了云原生化的技術架構改造
    的頭像 發表于 07-26 10:36 ?538次閱讀
    京東<b class='flag-5'>云原生</b>安全產品重磅發布

    從積木式到裝配式云原生安全

    云原生安全風險 隨著云原生架構的快速發展,核心能力逐漸穩定,安全問題日趨緊急。在云原生安全領域不但有新技術帶來的新風險,傳統IT基礎設施的安全威脅也依然存在。要想做好
    的頭像 發表于 07-26 10:35 ?349次閱讀
    從積木式到裝配式<b class='flag-5'>云原生</b>安全

    基于DPU與SmartNic的云原生SDN解決方案

    隨著計算,大數據和人工智能等技術的蓬勃發展,數據中心面臨著前所未有的數據洪流和計算壓力,這對SDN提出了更高的性能和效率要求。自云原生概念被提出以來,Kubernetes為云原生應用的落地提供了一
    的頭像 發表于 07-22 11:44 ?790次閱讀
    基于DPU與SmartNic的<b class='flag-5'>云原生</b>SDN解決<b class='flag-5'>方案</b>

    云原生轉型中從理念到實踐的探索與挑戰

    以“全面智能化,躍升數智生產力”為主題的華為第21屆全球分析師大會近日在深圳舉行。在本次大會的“5.5G Core,智能化點亮世界”核心網分論壇,廣東移動網絡運維總監王喆發表了“云原生
    的頭像 發表于 04-23 11:45 ?499次閱讀

    ?!?!這難倒了孫悟空!

    還是”,這的確是個問題!
    的頭像 發表于 03-14 02:42 ?1237次閱讀
    <b class='flag-5'>上</b><b class='flag-5'>云</b>?!<b class='flag-5'>下</b><b class='flag-5'>云</b>?!這難倒了孫悟空!

    云原生是大模型“降本增效”的解藥嗎?

    云原生AI正當時
    的頭像 發表于 02-20 09:31 ?436次閱讀
    主站蜘蛛池模板: 天天更新影院 | 色综合久久天天综合绕观看 | 天天操夜夜欢 | cao榴| 日韩图区| 日日夜夜操天天干 | 久久99热精品免费观看k影院 | 天天色天天综合 | www干| 日本免费福利视频 | 亚洲香蕉毛片久久网站老妇人 | 天天在线天天在线天天影视 | bt天堂网在线资源www | 亚洲综合色婷婷中文字幕 | 天天色天天操天天 | 成人最新午夜免费视频 | 日本一区二区三区在线 视频观看免费 | 日本污污视频 | 免费a大片| 五月婷婷 六月丁香 | 欧美区一区 | baoyu污污网站入口免费 | 五月激情啪啪 | 免费在线观看污视频 | 超级碰碰青草免费视频92 | 国产永久视频夜色资源网 | 日本www色视频成人免费网站 | 88av在线视频 | 国产天天色 | 午夜剧院免费 | 国产亚洲精品久久久久久午夜 | 中文字幕亚洲一区二区三区 | 嫩草影院永久入口在线观看 | 人人澡人人草 | 久久亚洲精品玖玖玖玖 | 2021国产精品午夜久久 | 亚洲vv| 制服丝袜中文字幕第一页 | 亚洲综人网 | 福利社藏经阁 | 特黄视频免费看 |