Twilio團隊分享了他們的初次混沌工程實踐，他們使用Gremlin往自家的隊列系統中注入故障，測試系統的自動恢復能力。
Twilio提供SMS和電話網關服務，開發者可以在他們的代碼中調用Twilio的API。Twilio架構的核心部分是他們的分布式隊列系統和速率限定系統。它提供了持久化的隊列，解決了系統故障和消息處理的延遲問題，避免消息丟失。這個隊列系統叫作Ratequeue，由Twilio團隊開發。Ratequeue對消息出隊速率進行了限定——每個電話號碼都有一個自己的臨時隊列。因為開發者有可能以很快的頻率調用API，所以速率限定是很有必要的，而Twilio將消息推送到電話網絡的速度也需要加以控制。Ratequeue是基于Redis開發的，可以進行橫向擴展。單個分片故障并不會影響到其他分片。另外，為了高可用，每個分片都有自己的主節點和副本。
之前，如果有分片發生故障，需要由人工手動將副本提升為主節點。這就要求先定位到擁有相同分片數量的主機，然后把它加到負載均衡器中。Twilio團隊開發了兩個系統，旨在對這一過程進行自動化——一個自動化的失效備援系統和一個用于測試前者的故障注入系統。故障注入系統屬于混沌工程，通過制造隨機的故障來測試系統的自我恢復能力。
測試的首要目的是保證零數據丟失，其次要保證能夠自動檢測出故障，并推舉出新的主節點。Twilio團隊基于Amazon Kinesis、Nagios和Lazarus開發了自己的解決方案——也就是他們的集群自動化服務。每個Ratequeue副本將主節點的心跳情況發送給Nagios，如果達到某個閾值，Nagios就向Kinesis推送通知。Lazarus監聽Kinesis，檢查集群的健康狀況，如果出現故障，就進行恢復。
為了測試自動故障恢復能力，Twilio團隊開發了一個叫作Ratequeue Chaos的工具，它會選擇一個分片，停掉它的主節點，然后監控其自我恢復過程。他們有一個叫作Gremlin的服務，用于將故障注入到系統中，觸發失效備援。Gremlin支持可控的故障注入，Ratequeue Chaos通過Gremlin提供的API來調用它。Twilio的staging環境每4個小時會重復一次這個過程。
Twilio團隊也分享了他們從這一實踐中學到的東西——基于測試模型的假設、用于運行測試的框架、在生產環境中需要有一個回退計劃。
查看英文原文：Chaos Engineering at Twilio
京公網安備 11010502049343號