對於大多數品牌,消息傳遞渠道是他們賴以保持顧客參與out-of-product的能力超越應用程序或網站捕捉用戶的attention-thimanbetx万博全站客户端nk電子郵件、短信或推送通知。但是這些通道隻能支持一個子集所需的用例驅動強勁的長期業績;釺調查顯示,美國消費者接受out-of-product和產品內看到一個消息會議,增加40%購買增長25%,19%用戶平均壽命更長。
為了滿足這種需求,釺創建了一個強大的新產品內頻道內容的卡片是為了支持更好的客戶互動。但推出一個全新的營銷渠道是一項具有挑戰性的任務,尤其是考慮到釺平台運作的規模。往下讀,了解我們麵臨的挑戰內容牌的世界和我們的技術團隊如何克服它們。
卡片內容非常靈活的天性和可以支持一係列自定義實例,品牌可以控製卡片內容存儲在哪裏以及如何呈現在他們的應用程序/網站,選擇自定義卡過期時間,利用基於api的交付執行的消息,和更多。使一個非常強大的工具來達到增加價值的方式活躍用戶的體驗你的品牌。
給定的,它不是震驚,釺客戶將湧向這個新通道一旦但使用的規模和速度增加超過了我們的想象。manbetx万博全站客户端通道的流行的一個諷刺的方麵是,它出現一些基礎設施的限製,威脅要緩慢增長的內容從長遠來看。為了防止這種情況的出現,我們知道我們需要快速的解決方案,我們需要他們。
幸運的是,我們的工程和DevOps團隊的挑戰。解決這個迫切的問題需要密切合作、研究、和很多teamwork-all而時鍾滴答作響。這是我們的故事。
卡片內容:建立一個新的消息通道
理解我們麵臨的一些挑戰與發射卡內容,你必須明白之前。
早在2013年,銅焊(然後被稱為Appboy)推出了新聞頻道,讓品牌內容提要包含在他們的移動應用程序。通道是我們獨有的平台,給營銷人員更多的選擇在與用戶在他們的移動應用程序;然而,渠道有一些限製時如何使用和品牌如何提供個性化的經驗。特別是,它與我們的不兼容連接的內容動態內容個性化功能,限製做實時定製品牌的能力。
當釺著手構建內容的卡片,其中一個主要目標是取代新聞Feed的渠道更加靈活,模塊化、個性化和能夠支持先進、即時即刻。發生,呼籲構建的平台和渠道團隊卡片的內容補充我們現有的存儲與Postgres。這些決策提供額外的靈活性和穩定性,卡片內容,目標是為品牌提供更多的控製他們的方式利用這一新的渠道,相比與新聞提要。
麵對規模限製
很明顯,當我們推出了內容的卡片,我們會實現我們的目標新通道比新聞更強大和靈活的,並且能夠支持先進的實時個性化的用例。但正如我們上麵所提到的,內容的流行牌迫使我們麵對一些重要的擴展和基礎設施有關的問題,有可能破壞一些通道的好處。
首先,高水平的使用意味著內容牌開始跑到輸入/輸出(I / O)的局限性與亞馬遜網絡服務(AWS)的雲服務器提供商釺平台架構。當我們開始看到這個問題,我們的團隊致力於擴大我們的規模情況下,但很快發現它並不足以給我們所需的帶寬。結果是,當使用過高,服務器開始會超載,增加了多長時間卡活動發送內容。因為這通道是為了支持實時觸發和個性化,任何延遲可能會造成潛在的問題。
另外,我們發現自己跑到scale-related Postgres問題。由於極高的使用內容卡片看到剛剛推出,我們使勁把數據庫,它無法有效地清理自己。在正常情況下,Postgres運行一係列的背景特別維護流程,日常吸塵——有助於保持係統正常運行,特別是在並發性。然而,由於我們使用透支資源在一個一致的基礎上,Postgres的多版本並發控製(MVCC)無法做到定期清理需要避免的事務ID疲憊。如果問題沒有解決,它可能會導致數據庫鎖定的經驗欠佳,導致品牌想要利用卡片的內容。
很明顯,這是我們非常希望避免的。
上麵所有的發生對我加入釺早在2019年6月,我很快就發現自己負責領導應對這些問題。但是因為我很新的團隊並想確保我有上下文和專家觀點有效地解決這一問題,我與利益相關者在工程和DevOps的團隊。
之前我們可以做任何有意義的改變,我知道我們需要更深的了解Postgres選項開放我們優化查詢。我們開始利用解釋和分析,這是命令,您可以使用在Postgres將向您展示更多的信息如何將運行查詢,然後使用這些信息來頭腦風暴的方法來優化我們的不同的索引和減少相關的服務器的負擔。和一個早期的發現是,所做的一些工作,試圖減少負擔我們看到已經使問題變得更糟。
與內容的卡片,每條消息發送附帶一個過期日期;當消息將自動消失,不再向觀眾展示部分被送到。試圖保持我們的數據庫在可控的範圍內,我們已經從數據庫刪除過期卡內容,同時刪除內容的卡片從團隊活動,被取消了發送。
理論上講,這應該減少數據庫的大小,但是,由於MVCC,存儲空間不是標記為自由真空過程完成之前,阻止那些刪除減少數據庫的大小。此外,每一個刪除操作增加最大事務ID,加速朝著事務ID的疲勞。
過渡到一個新的模式
一旦我們有一個更好地了解這個問題,我們大家集思廣益想辦法避免觸及限製最大事務ID。過程是令人振奮的,但也很有挑戰性,因為最初的解決方案,我們偶然發現了不可行。我們希望能找到一個開箱即用的工具,我們可以用它來處理這個問題,但沒有任何東西能讓我們過渡到一個新的模式在不觸發重大停機時間。事實上,當我們看著選項,我們發現外麵的操作要花費幾個小時的時間來完成這些方法,因為我們的數據庫是多個字節的大小,使其有問題的適合我們的需要。
然而,我們從調查收集的見解最終幫助自己找到一個方法來解決這個問題。期間我們的工作在這個項目中,我們構建了一個不同的模式Postgres允許我們做批量刪除過期卡內容,從而能夠減少數據庫的大小沒有跑到我們之前的問題。我們決定使用表分區將卡片內容分組為軍團的截止日期。當隊列傳遞的截止日期,我們可以刪除整個表。這是一個更有效的過程比手動刪除行的Postgres並立即釋放存儲空間。它還允許執行日常吸塵,消除事務ID疲憊的威脅。
要讓所有的可能,我們必須找到一個方法來遷移到新信息從我們最初的模式。因為現有的遷移工具做不到成功沒有引發巨大的成本或停機,我開發一個係統,使我們能夠進行無縫遷移。
停機時間會如此重要的原因之一與現有的工具,他們需要您構建一個完整的數據庫,所以你不得不花大量的時間等待新老模式互相鏡像。但因為我們已經過期的窗口,它允許我們逐步建立新的數據庫;即可以更新新的當舊還使用並行讀寫功能。
為了實現這一點,我們建立了一個可配置的連接管理係統,以確定哪些數據庫寫入,允許調度遷移時間表。然後我們整合內部切分係統(散列分布數據跨多個數據庫的用戶)進入這個係統。這使得我們橫向規模數據庫基礎設施通過添加其他關係數據庫服務(RDS)集群當我們需要他們時,給予我們穩定規模和靈活性,同時解決AWS I / O限製。
