คร่าวๆก็คือว่า

(จาก https://www.youtube.com/watch?v=rgfww8tLM0A )

Netflix เปลี่ยนจากวัฒนะธรรมที่ว่า ถ้าระบบ fail จะต้องทำอะไร
ไปเป็น เมื่อไหร่ระบบจะ fail

ทาง Netflix จึงสร้าง chaos platform ใว้ เพื่อหาว่า traffic เท่าไหร่จะกระทบระบบ หรือ เมื่อไหร่ระบบจะ fails

คือจะมีการทดลองบน production ก่อนที่ลูกค้าจะเจอ issues

โดยใช้เครื่องมือชื่อว่า ChAP: Chaos Automation Platform (จะมี Chaos Monkey , และ อื่นๆ)

แล้ว chaos engineering ต่างจาก testing อย่างไร

ในหนังสือ Oreilly (มีทฤษฎีเยอะมาก) เขากล่าวว่า testing โดยพวก fault injection ก็จะได้แค่ผลลัพธ์แค่ผลลัพธ์เดียว

แต่าถ้าอยากที่จะหาว่ามีวิธีอะไรบ้างที่ complex system จะ fail ได้ ก็อาจใช้แนวทาง testing แบบ injecting communication failures เช่น latency และ errors (งง หาอ่านอีกทีครับ)

แต่ experiment ที่ทำกับ chaos engineering เราจะได้ knowledge ใหม่ (หรือความรู้ใหม่), information ใหม่ๆ และแนวทางใหม่ๆ

ในหนังสือบอกว่า chaos engineering คือรูปแบบของ experimentation ที่จะ gernerate ความรู้ใหม่ๆของระบบ (infra/cluster) ให้กับเรา , ซึ่งจะเรียกว่า testing ไม่ได้ !!

คอนเซ็ปหลักการทำ (ยังไม่ชัวร์)

สร้างสมมติฐาน (hypothesis) และสรุป เช่น ถ้าเราทำบางสิ่งบางอย่าง ระบบจะ fail
Vary Real World Events (แก้อีกที)
เพราะการทำ chaos นี้มันจะทำให้เกิดบางเหตุการณ์ real world event เช่น
ถ้าตัดการเชื่อมต่อระหว่าง server กับ internet ดังนั้น server ก็จะ down แน่นอน ,
เพิ่ม event ที่คาดไม่ถึง เพื่อให้รบกวน (disturb) ตัว system/application (Steady State)
รันบน production
ทำการ automate บ่อยๆ
ระบุผลกระทบ และหาวิธีลดผลกระทบที่จะเกิดขึ้น

เนื่องจาก run บน production , จะไม่ให้กระทบกับ users

🛠 เครื่องมือในการทำ Chaos Engineering ดังนี้

บางเครื่องมือเริ่มต้นจาก Netflix , บางอันอาจไม่ใช่
บางเครื่องมืออาจจะไม่ถูก support แล้ว (อาจต้องหาตัวอื่นแทน)

Chaos Monkey

จะ random เข้าไป kill ตัว services/micro-services แล้วดูว่าตัว server จะเป็นยังไง

มีสอง dependencies ที่ใช้ คือ MySQL และ Spinnaker (คือที่ Netflix ใช้)

MySQL ใช้ track ตัว termination, schedule
Spinnaker คือ continuous delivery platform

*** ถ้าใน GitLab ใช้ ChaosKube แทน (มันคือ Chaos Monkey นะครับ)

🛠 Chaos Gorilla

จะ kill ทั้ง Availability Zone

🛠 Chaos Kong

จะ kill ทั้ง region เลย

🛠 Latency Monkey

จะสร้าง delay ให้กับ requests

แล้วเราค่อยมาดูว่าจะเกิดอะไรขึ้นกับ cluster

🛠 Janitor Monkey

หาว่า resources อะไรที่ไม่ถูกใช้งาน
ถ้าไม่ใช้ก็ต้องลบทิ้ง

🛠 Security Monkey

หาว่ามีการตั้งค่าอะไรที่ไม่ถูกต้องบ้าง เช่น มีการคอนฟิก security group ที่ผิด , คอยดูว่า SSL certificates ยังมีความถูกต้อง (ไม่ใกล้หมดอายุ)

🛠 Facebook Storm

เกี่ยวกับปัญหาใดๆใน data center

🛠 Litmus Chaos

(จาก https://github.com/litmuschaos/litmus)

เป็น Chaos Engineering platform
ทำ chaos บน K8s on-premises ได้
ทำบน staging ก่อน แล้วค่อยไปทำบน production เพื่อหา bug หรือข่องโหว่ได้
มีหลายๆ experiments ให้ที่ https://hub.litmuschaos.io/

โปรแกรมนี้ ถ้ามองจาก high-level ก็จะประกอบด้วย

(1) Chaos Control Plane : เป็น management tool , ใช้ทำ workflows
(2) Chaos Execution Plane Services : เป็น agent ที่จะ execute & monitor การ experiment ใน K8s

Use cases ของ Litmus Chaos

สำหรับ Developers : ให้เป็น extension ของ unit testing หรือเป็นส่วนหนึ่งของ testing
สำหรับคนทำ CI/CD pipeline : ทำ stage ให้กับ Litmus นี้ เพื่อหาว่า pipeline มัน fail เพราะ bug อะไร
สำหรับ SREs : ใช้บอกจุดอ่อนของ system/infra ก็เพิ่มเพิ่มความทนทาน (resilience)

🛠 Gremlin

เป็น Software-as-a-Service หรือ Chaos-as-a-Service
จะโจมตี system , network เพื่อทดสอบความทนของ system
เราต้องกำหนดเองว่าการโจมตีไหนเหมาะกับเรา (เราต้องรับผิดชอบตัวเอง)
อาจต้องมีการติดตั้ง agent ใน server/container/pods ของเป้าหมาย

ตอนติดตั้ง

allow port 11371 สำหรับ gpg ด้วย
ถ้าใช้ port ของ gpg ไม่ได้ ให้เปลี่ยนไปใช้ port 80 แทน ดังนั้น คำสั่งในการติดตั้งคือ

# Install Gremlin
echo "deb https://deb.gremlin.com/ release non-free" | sudo tee /etc/apt/sources.list.d/gremlin.list

sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 9CDB294B29A5B1E2E00C24C022E8EF3461A50EF6

sudo apt-get update && sudo apt-get install -y gremlin gremlind

# Register Gremlin client to its Control Plane
gremlin init

https://gremlin.com/

ตัวฟรีทำอะไรได้บ้าง

ใช้ได้ 1 team
ติดตั้งได้ 1 agent
2 Targets ต่อเดือน (แต่ละ target โจมตีได้ไม่จำกัด)

ตย scenario

💻 [เกี่ยวกับ Blackhole]

Unavailable Dependency: ถ้า dependency มัน unavailable จากนั้น users จะเจออะไร

Database Secondary Failover Time: เมื่อมีการ failover ที่ database ทดสอบว่าจะเร็วเท่าไหร่ที่ app จะเปลี่ยน connection จาก primary database ไปยัง secondary database

Kubernetes - Availability - Blackhole a Kubernetes node : จะเกิดอะไรขึ้นถ้า 1 node ของ K8s ไม่สามารถใช้งานได้

💻 [เกี่ยวกับ CPU]

Find Anomalous CPU Consumption : ทดสอบ CPU consumption บน host หรือ บน containers แบบ random จากนั้นเราก็จะเห็นว่าตัว monitor ของเราตรวจจับการใช้งาน CPU ได้อย่างถูกต้องหรือไม่

Monitoring & Alerting Verification : โปรแกรม Gremlin จะรัน CPU attack ให้กับ VM แล้วเราก็จะสามารถเห็น CPU มัน spike ขึ้นสูง

💻 [เกี่ยวกับ Disk]

Testing Kubernetes Storage Volume Limits : ทดสอบว่าขนาดพื้นที่ space ที่ pod ใช้ ยังไม่ถึง limit ที่กำหนดไว้ตรงคอนฟิก Deployment, นอกจากนี้เราก็จะเห็นว่าจะเป็นอย่างไรถ้ามี disk เต็ม (ตัว workload จะ handle อย่างไร , จะ crash หรือ data loss หรือไม่)

💻 [เกี่ยวกับ DNS]

Kubernetes - Availability - DNS outage : จะทดสอบให้ DNS ใช้งานไม่ได้, แล้วมาดูว่าตัว app ยังสามารถรับส่ง traffic ระหว่าง users ได้หรือไม่ , (K8s จะ handle อย่างไร ซึ่งถ้ามีการตั้งค่า DNS failover อย่างถูกต้อง ทาง users ก็ไม่ควรที่จะได้รับผลกระทบ)

💻 [เกี่ยวกับ IO]

💻 [เกี่ยวกับ Latency]

Unreliable Networks : เนื่องจาก microservice ต้องมีการเรียกใช้ API , จะกระทบกับ users อย่างไร ถ้าเรียก API ใช้เวลา 100 วินาที หรือ 1,000 วินาที

💻 [เกี่ยวกับ Memory]

Kubernetes - Validate Container Resilience Mechanism: OOMKiller - ปกติตัว Linux จะมีเครื่องมือจัดการ Memory ที่ชื่อว่า OOMKiller , การทดสอบนี้จะดูว่าจะเกิดอะไรขึ้นถ้ามีการใช้งาน Memory สูง , ตัว OOMKiller ของ Linux จะ work หรือไม่

ที่เห็น : Lens หลุด

Test Monitoring and Alerting for the Basics : จะทดสอบใช้งาน memory ให้สูงๆ แล้วเราก็ดูว่า เครื่องมือ monitoring ของเราสามารถตรวจจับการใช้งาน memory ได้อย่างถูกต้องหรือไม่

💻 [เกี่ยวกับ Package Loss]

💻 [เกี่ยวกับ Process Killer]

💻 [เกี่ยวกับ Shutdown]

💻 [เกี่ยวกับ Thread Bomb]

💻 [เกี่ยวกับ Time Travel]

DynamoDB Timeout Testing : ตรวจสอบว่า DynamoDB Java client ถูกคอนฟิกด้วย 500ms connection timeout

เพิ่มเติม

ถ้าใช้ scenarios ประเภท attack CPU แล้วถ้าใช้คำสั่ง ps -ef | grep gremlin จะเห็นว่า จริงๆแล้ว ตัว agent ก็รันโดยการส่ง parameter เข้าไปดังรูป

วิธีที่มีคนทำ

อาจเอาขั้นตอนของ chaos ไปอยู่ใน CD pipeline
ส่วนเครื่องมืออย่าง Gremlin ไม่จำเป็นต้องเอากระบวนการ chaos นี้ไว้ใน CD pipeline คือ ถ้าอยากจะทดสอบ VM หรือ cluster ก็เริ่มทดสอบเมื่อไหร่ก็ได้