ClickHouse Analytics Chaos Engineering | SiamCafe Blog

Chaos Engineering บน ClickHouse คืออะไร — ทำความเข้าใจจากพื้นฐาน

Chaos Engineering บนระบบวิเคราะห์ข้อมูลอย่าง ClickHouse คือกระบวนการจงใจสร้างความผิดพลาดขึ้นในระบบแบบควบคุมได้

เพื่อทดสอบว่าคลัสเตอร์ของเราจะยังทำงานต่อได้หรือไม่เมื่อเกิดเหตุการณ์ไม่คาดคิดจริง หลายคนอาจสงสัยว่าทำไมต้องทำลายระบบตัวเองด้วยตัวเอง คำตอบก็คือถ้าเราไม่ค้นพบจุดอ่อนก่อน ปัญหาจริงก็จะค้นพบแทนเรา และมักค้นพบตอนที่แพงที่สุด ผมอ.บอม ทำงานกับระบบฐานข้อมูลมากว่าสิบสามปี ตั้งแต่ระบบเทรดอัตโนมัติที่รับข้อมูลราคาตลาดตลอด 24 ชั่วโมง จนถึงงานวิเคราะห์ข้อมูลขนาดใหญ่ และเรียนได้บทเรียนเดียวกันทุกครั้ง คือระบบที่ไม่เคยถูกทดสอบในสภาวะล้มเหลว จะล้มเหลวในแบบที่เราไม่เคยคิดถึงเสมอ

ClickHouse เป็นฐานข้อมูลแบบคอลัมน์ที่ออกแบบมาเพื่อการวิเคราะห์ข้อมูลจำนวนมหาศาล รองรับการสอบถามข้อมูลพันล้านแถวได้ในเวลาไม่กี่วินาที ระบบที่ใช้งานประเภทนี้มักเป็นงานสำคัญขององค์กร เช่น แดชบอร์ดยอดขาย ระบบตรวจจับการทุจริต หรืองานวิเคราะห์ข้อมูลการเทรดแบบเรียลไทม์ ซึ่งหมายความว่าเวลาที่คลัสเตอร์ล่ม การตัดสินใจทั้งหมดขององค์กรก็หยุดตามไปด้วย Chaos Engineering จึงไม่ใช่เรื่องของความหวาดระแวง แต่เป็นวินัยทางวิศวกรรมที่ต้องทำ

แนวคิดนี้ไม่ได้เกิดขึ้นใหม่ในวงการเทคโนโลยี บริษัทใหญ่ ๆ ด้านระบบคลาวด์ได้ทำมานานกว่าสิบปีแล้ว โดยเริ่มจากการทดลองปิดเซิร์ฟเวอร์สุ่มตัวหนึ่งในร้อยตัวในสภาพแวดล้อมการผลิตของตัวเอง เพื่อพิสูจน์ว่าระบบลูกค้าไม่รู้สึกอะไรเลย แนวคิดเดียวกันนี้นำมาปรับใช้กับฐานข้อมูลวิเคราะห์ได้ แต่ต้องปรับสเกลและวิธีการให้เหมาะ เพราะคลัสเตอร์วิเคราะห์ขององค์กรทั่วไปมีจำนวนโหนดน้อยกว่ามาก แต่ละโหนดจึงมีน้ำหนักต่อความพร้อมใช้ของระบบมากกว่า การถอดบทเรียนจากวงการระบบคลาวด์ขนาดใหญ่มาใช้ต้องพิจารณาสัดส่วนความเสี่ยงใหม่ทั้งหมด

หลักการพื้นฐานมีสี่ข้อ ข้อแรกคือสร้างแบบจำลองสภาวะปกติหรือสิ่งที่เรียกว่าสถานะเสถียร วัดตัวชี้วัดที่สำคัญไว้ เช่น ความเร็วในการตอบคำสอบถาม อัตราการส่งข้อมูลเข้า และความสามารถในการจำลองข้อมูลข้ามโหนด ข้อสองคือตั้งสมมติฐานว่าระบบจะยังคงอยู่ในสถานะเสถียรแม้เกิดความผิดพลาด ข้อสามคือฉีดความผิดพลาดเข้าไปจริง เช่น ปิดโหนดหนึ่ง ทำให้ดิสก์ช้าลง หรือจำกัดแบนด์วิดท์ระหว่างโหนด และข้อสี่คือวัดผลเทียบกับสมมติฐาน ถ้าระบบไม่เป็นไปตามที่คิด เราก็ได้พบจุดอ่อนที่ต้องแก้ก่อนถึงวันจริง

สิ่งที่แยกการทำ Chaos Engineering ที่ดีออกจากการก่อวินาศกรรมโดยไม่ได้ตั้งใจ คือขอบเขตและการควบคุม เราเริ่มจากสภาพแวดล้อมทดสอบ เริ่มจากความผิดพลาดเล็กที่สุด และมีสวิตช์หยุดฉุกเฉินเสมอ เพื่อหยุดการทดลองทันทีเมื่อสถานะเสถียรถูกทำลายเกินกว่าที่ยอมรับได้ ความแตกต่างระหว่างวิศวกรที่ทดสอบระบบกับคนที่ทำระบบพังโดยไม่ได้ตั้งใจอยู่ตรงที่คนแรกมีแผน มีการวัดผล และรู้ว่ากำลังทำอะไรอยู่ตลอดเวลา ส่วนคนที่สองค้นพบความล้มเหลวโดยบังเอิญและไม่มีข้อมูลอะไรเลยตอนที่ต้องหาสาเหตุ

หลายทีมมักคิดว่าฐานข้อมูลวิเคราะห์เป็นระบบอ่านอย่างเดียว ล่มก็ค่อยแก้ ข้อมูลยังอยู่ในที่เก็บต้นทางอยู่แล้ว แต่ในความเป็นจริงแล้ว

ระบบวิเคราะห์สมัยใหม่กลายเป็นส่วนหนึ่งของกระบวนการทำงานแบบเรียลไทม์ไปนานแล้ว แดชบอร์ดที่ผู้บริหารดูทุกเช้า ระบบแจ้งเตือนสัญญาณผิดปกติ หรืองานกำหนดการรายงานอัตโนมัติ ล้วนพึ่งพาคลัสเตอร์วิเคราะห์ให้พร้อมใช้ตลอดเวลา เมื่อบทบาทเปลี่ยนไป ความเสี่ยงก็เปลี่ยนตาม

ความเข้าใจผิดที่ว่าฐานข้อมูลวิเคราะห์ล่มแล้วไม่เสียหายอะไร มักพังทลายในวันที่เกิดเหตุจริง เพราะระบบปฏิบัติการที่พึ่งพาคลัสเตอร์วิเคราะห์มีมากขึ้นทุกปี ตัวอย่างที่เห็นบ่อยคือระบบตรวจจับการทุจริตที่ต้องตัดสินใจภายในไม่กี่วินาทีว่าจะอนุมัติธุรกรรมหรือไม่ ถ้าคลัสเตอร์วิเคราะห์ล่ม ระบบอาจตัดสินใจผิดในทางที่เสียเงินทอง หรือหยุดอนุมัติทุกธุรกรรมจนกระทบลูกค้าจำนวนมาก ความเสียหายแบบนี้ไม่ได้วัดกันที่ค่าเช่าเซิร์ฟเวอร์ แต่วัดกันที่ความเชื่อมั่นของลูกค้าที่กลับมายากมาก

จุดเปราะบางของคลัสเตอร์ ClickHouse มีอยู่หลายชั้น ชั้นแรกคือชั้นจัดเก็บข้อมูล เมื่อเราใช้การจำลองข้อมูลแบบสามโหนด หนึ่งโหนดตายเรายังอยู่รอดได้ แต่คำถามที่ต้องทดสอบคือระหว่างที่โหนดหนึ่งกำลังกู้คืนข้อมูลกลับมา ประสิทธิภาพของทั้งคลัสเตอร์จะได้รับผลกระทบแค่ไหน ผมเคยเห็นกรณีที่โหนดกลับมาหลังหยุดทำงานเพียงสองชั่วโมง แต่การกู้คืนข้อมูลกินทรัพยากรจนทำให้การสอบถามอื่นช้าลงหกเท่า ซึ่งเป็นสิ่งที่ไม่มีใครคาดคิดจนกว่าจะทดลองจริง

ชั้นที่สองคือชั้นประสานงานแบบกระจาย คำสอบถามที่ส่งไปยังคลัสเตอร์จะถูกแยกย่อยไปทำงานหลายโหนดพร้อมกัน ถ้าโหนดใดโหนดหนึ่งตอบช้าหรือตายกลางทาง ทั้งคำสอบถามจะล้มเหลวหรือค้าง พฤติกรรมพวกนี้ต้องทดสอบด้วยการฉีดความล่าช้าหรือตัดการเชื่อมต่อเครือข่ายแบบจำลอง ไม่ใช่เดาจากเอกสาร

ชั้นที่สามที่มักถูกลืมคือชั้นของผู้ดูแลระบบเอง เวลาเกิดเหตุจริงตอนตีสอง คนที่ตื่นมาแก้ปัญหาคือคนที่เพิ่งลืมตา ไม่ใช่ทีมวิศวกรเต็มตัวที่พร้อมทำงาน การทดสอบความล้มเหลวที่ดีควรจำลองสถานการณ์นี้ด้วย คือให้คนที่ไม่ใช่ผู้เชี่ยวชาญหลักของระบบเป็นคนทำตามคู่มือกู้คืน ถ้าคู่มือทำตามไม่ได้ในสภาวะเครียด แปลว่าคู่มือนั้นยังไม่พร้อมใช้ในวันเกิดเหตุจริง บทเรียนนี้เรียนรู้ได้ถูกกว่าการเกิดเหตุจริงหลายเท่า

ตารางต่อไปนี้สรุปจุดเปราะบางที่พบบ่อยและวิธีทดสอบที่แนะนำ

จุดเปราะบาง	ตัวอย่างความล้มเหลว	วิธีฉีดความผิดพลาด	สิ่งที่ต้องวัด
โหนดจัดเก็บข้อมูล	ดิสก์เต็มหรือดิสก์เสีย	ปิดโหนดหรือเติมดิสก์จนใกล้เต็ม	การเขียนข้อมูลยังทำงานไหม เวลากู้คืน
เครือข่ายระหว่างโหนด	แพ็กเก็ตหายหรือหน่วง	จำกัดแบนด์วิดท์ เพิ่มความล่าช้า	เวลาตอบคำสอบถามกระจาย
ตัวประสานงาน	ตัวคุมคลัสเตอร์ล้มเหลว	หยุดตัวประสานงานชั่วคราว	การเลือกผู้นำใหม่ การเขียนข้อมูล
แหล่งข้อมูลเข้า	สายการส่งข้อมูลสะดุด	หยุดโปรแกรมส่งข้อมูลสิบนาที	การกู้คืนจากจุดตรวจ ข้อมูลซ้ำหรือขาด
ทรัพยากรระบบ	หน่วยความจำเต็ม	จำกัดหน่วยความจำต่อกระบวนการ	การตัดงานสอบถามที่ใช้ทรัพยากรมาก

การออกแบบการทดลองความล้มเหลวแบบมีวินัย

การทดลองที่ดีเริ่มจากคำถามที่ชัดเจน ไม่ใช่การไล่ปิดของไปเรื่อย ๆ รูปแบบที่ผมใช้และแนะนำให้ทุกทีมคือการเขียนแผนการทดลองหนึ่งหน้าก่อนลงมือ ประกอบด้วยสมมติฐาน ขอบเขต ตัวชี้วัด และเงื่อนไขยุติ เช่น สมมติฐานว่าถ้าโหนดจัดเก็บหนึ่งในสามหยุดทำงาน แดชบอร์ดสำคัญควรยังตอบได้ภายในสามวินาที ขอบเขตคือทดสอบเฉพาะสภาพแวดล้อมจำลองในสัปดาห์แรก แล้วจึงขยับไปช่วงเวลาที่มีผู้ใช้น้อยที่สุดของระบบจริง เงื่อนไขยุติคือถ้าความเร็วในการตอบเกินสิบวินาทีหรืออัตราความผิดพลาดเกินห้าเปอร์เซ็นต์ ให้หยุดการทดลองทันที

การเขียนสมมติฐานให้ชัดเจนมีคุณค่ามากกว่าที่คิด เพราะบังคับให้ทีมต้องเข้าใจระบบก่อนทดสอบ ถ้าทีมเขียนสมมติฐานไม่ได้ แปลว่าทีมยังไม่รู้ว่าระบบควรทำงานอย่างไรอยู่แล้ว การทดลองจะไม่ให้บทเรียนอะไรเลย นอกจากนี้แผนหนึ่งหน้ายังเป็นเอกสารสื่อสารกับผู้บริหารที่ดี เพราะอธิบายได้ว่าเราจะทำอะไร ความเสี่ยงที่ยอมรับได้อยู่ตรงไหน และจะหยุดเมื่อไร ซึ่งเป็นสิ่งที่ผู้บริหารต้องรู้ก่อนอนุมัติให้เราไปเล่นกับระบบที่องค์กรพึ่งพา

การสื่อสารกับผู้เกี่ยวข้องก่อนเริ่มการทดลองเป็นขั้นตอนที่ห้ามข้าม ทีมที่ดูแลระบบแจ้งเตือนต้องรู้ว่ากำลังมีการทดสอบ เพื่อไม่ให้การแจ้งเตือนจากการทดลองถูกเข้าใจว่าเป็นเหตุจริงแล้วตื่นตระหนก ทีมที่ดูแลระบบรองเช่นระบบสำรองข้อมูลหรือระบบตรวจสอบความพร้อมใช้ก็ต้องรู้ด้วย เพราะการทดลองอาจกระตุ้นให้ระบบรองทำงานผิดปกติไปด้วย ผมเคยเห็นทีมทดสอบปิดโหนดแล้วระบบสำรองข้อมูลเข้าใจว่าเกิดเหตุจริง เริ่มกู้คืนข้อมูลใหญ่ ทำให้เครือข่ายอืดไปทั้งคลัสเตอร์ ความล้มเหลวรองแบบนี้แก้ได้ด้วยการสื่อสารก่อนเริ่มงานห้านาทีเท่านั้น

ลำดับการทดลองที่แนะนำคือเริ่มจากความล้มเหลวเดี่ยวและสั้น จากนั้นจึงขยายเป็นความล้มเหลวซ้อนกัน ลำดับที่ผมใช้ประจำมีดังนี้

• หยุดโหนดหนึ่งเป็นเวลาห้านาที วัดว่าระบบยังให้บริการไหม และเวลากู้คืนข้อมูลกลับเข้าโหนดกินเวลาเท่าไร
• ทำให้ดิสก์ของโหนดหนึ่งช้าลง โดยจำกัดอัตราการอ่านเขียน เพื่อจำลองดิสก์เสื่อมสภาพ ซึ่งพบบ่อยกว่าดิสก์ตายทันทีในโลกจริง
• จำกัดเครือข่ายระหว่างโหนดสองกลุ่ม เพื่อทดสอบพฤติกรรมเมื่อการประสานงานช้าลง ระบบควรหน่วงแทนที่จะทำข้อมูลขัดแย้งกัน
• หยุดโปรแกรมส่งข้อมูลแล้วรีสตาร์ท ทดสอบการกู้คืนจากจุดตรวจและการตรวจสอบข้อมูลซ้ำ
• เพิ่มภาระการสอบถามปลอมพร้อมกับความล้มเหลวเดี่ยว เพื่อดูว่าระบบจัดสรรทรัพยากรอย่างไรเมื่อแรงกดดันสองด้านพร้อมกัน

แต่ละขั้นในลำดับนี้ควรทำซ้ำหลายรอบในเวลาต่างกันก่อนขยับขึ้น ตัวอย่างเช่นการหยุดโหนดห้านาที ถ้าทำตอนที่ระบบกำลังรวมข้อมูลพื้นหลังอยู่ ผลอาจต่างจากการทดสอบตอนระบบว่างมาก ความล้มเหลวที่แท้จริงในโลกไม่เลือกเวลาให้เราเลย การทดสอบซ้ำหลายเวลาจึงให้ภาพที่สมจริงกว่า นอกจากนี้ยังควรทำซ้ำหลังจากแก้ไขปัญหาที่พบแล้ว เพื่อยืนยันว่าการแก้ไขได้ผลจริง ไม่ใช่แค่ผ่านตาไปครั้งเดียว

การบันทึกผลก็ต้องเป็นระบบ ทุกการทดลองควรจบด้วยรายงานสั้นสามส่วน คือสิ่งที่คาดไว้ สิ่งที่เกิดขึ้นจริง และรายการงานที่ต้องแก้ งานแก้ต้องถูกใส่ในระบบติดตามงานจริง มีผู้รับผิดชอบและกำหนดเวลา ไม่ใช่แค่บันทึกไว้ในเอกสารที่ไม่มีใครเปิดอีก การทดลองที่ไม่นำไปสู่การแก้ไขเท่ากับเสียเวลาเปล่า

เครื่องมือและการตั้งค่าที่ใช้งานจริง

เครื่องมือฉีดความผิดพลาดที่นิยมใช้กับคลัสเตอร์ที่รันบนลินุกซ์มีหลายตัว หากระบบรันในคอนเทนเนอร์ เครื่องมือยอดนิยมคือกลุ่มที่ทำงานร่วมกับระบบจัดการคอนเทนเนอร์ได้โดยตรง สามารถกำหนดได้ว่าจะลบพ็อดไหน ลบกี่ตัว ถี่แค่ไหน ส่วนระบบที่รันบนเซิร์ฟเวอร์เปล่า คำสั่งระดับระบบปฏิบัติการก็เพียงพอสำหรับเริ่มต้น

ก่อนเลือกเครื่องมือ ควรถามตัวเองสามคำถาม คำถามแรกคือเราต้องการฉีดความผิดพลาดชนิดไหนบ้าง ถ้าต้องการแค่หยุดกระบวนการและจำกัดเครือข่าย คำสั่งพื้นฐานของระบบปฏิบัติการก็เพียงพอ ไม่จำเป็นต้องติดตั้งอะไรเพิ่ม คำถามที่สองคือทีมเรามีความคุ้นเคยกับเครื่องมือแค่ไหน เครื่องมือที่ซับซ้อนแต่ทีมไม่คุ้น มักทำให้เกิดความผิดพลาดของตัวทดสอบเอง ซึ่งเป็นตัวแปรที่ปนเปื้อนผลการทดลอง คำถามที่สามคือเครื่องมือมีสวิตช์หยุดฉุกเฉินชัดเจนหรือไม่ ในวันที่การทดลองเลยขอบเขต เราต้องหยุดทุกอย่างได้ในไม่กี่วินาที ไม่ใช่ไล่ค้นหาวิธียกเลิกในเอกสารตอนระบบกำลังโกลาหล

ตัวอย่างคำสั่งพื้นฐานที่ผมใช้ทดสอบบ่อย

systemctl stop clickhouse-server sleep 300 systemctl start clickhouse-server

tc qdisc add dev eth0 root tbf rate 1mbit latency 50ms burst 32k

tc qdisc del dev eth0 root

watch -n 2 "clickhouse-client --query 'SELECT eventtime, querydurationms, readrows FROM system.querylog WHERE eventtime > now() - 300 ORDER BY event_time DESC LIMIT 20'"

คำสั่งหยุดและเริ่มเซิร์ฟเวอร์เป็นการทดสอบที่ง่ายที่สุดแต่ให้ข้อมูลมากที่สุดชุดหนึ่ง เพราะครอบคลุมทั้งพฤติกรรมตอนโหนดหาย ตอนโหนดกลับมา และตอนกู้คืนข้อมูล ส่วนคำสั่งจำกัดแบนด์วิดท์ใช้จำลองเครือข่ายช้าแบบที่พบในศูนย์ข้อมูลจริง โดยเฉพาะเวลาหลายงานแย่งแบนด์วิดท์กันในช่วงเวลาเดียว ควรทดลองหลายระดับความเร็ว ตั้งแต่หนึ่งเมกะบิต

คำถามที่พบบ่อย

Chaos Engineering บน ClickHouse คืออะไร และทำไมองค์กรจึงต้องทำลายระบบของตัวเอง?

Chaos Engineering บน ClickHouse คือกระบวนการจงใจสร้างความผิดพลาดขึ้นในระบบแบบควบคุมได้ เพื่อทดสอบว่าคลัสเตอร์จะยังทำงานต่อได้หรือไม่เมื่อเกิดเหตุการณ์ไม่คาดคิดจริง หลายคนอาจสงสัยว่าทำไมต้องทำลายระบบตัวเองด้วยตัวเอง คำตอบคือถ้าเราไม่ค้นพบจุดอ่อนก่อน ปัญหาจริงก็จะค้นพบแทนเรา และมักค้นพบตอนที่แพงที่สุด ClickHouse เป็นฐานข้อมูลแบบคอลัมน์ที่ใช้ในงานสำคัญขององค์กร เช่น แดชบอร์ดยอดขาย ระบบตรวจจับการทุจริต หรืองานวิเคราะห์แบบเรียลไทม์ เมื่อคลัสเตอร์ล่ม การตัดสินใจทั้งหมดขององค์กรก็หยุดตามไปด้วย จึงถือเป็นวินัยทางวิศวกรรมที่จำเป็น ไม่ใช่ความหวาดระแวง

หลักการพื้นฐานของ Chaos Engineering มีกี่ข้อ และแต่ละข้อคืออะไร?

หลักการพื้นฐานมีสี่ข้อ ข้อแรกคือการสร้างแบบจำลองสภาวะปกติหรือที่เรียกว่าสถานะเสถียร โดยวัดตัวชี้วัดที่สำคัญไว้ เช่น ความเร็วในการตอบคำสอบถาม อัตราการส่งข้อมูลเข้า และความสามารถในการจำลองข้อมูลข้ามโหนด ข้อสองคือการตั้งสมมติฐานว่าระบบจะยังคงอยู่ในสถานะเสถียรแม้เกิดความผิดพลาดขึ้น ข้อสามคือการฉีดความผิดพลาดเข้าไปจริง เช่น ปิดโหนดหนึ่ง ทำให้ดิสก์ช้าลง หรือจำกัดแบนด์วิดท์ระหว่างโหนด และข้อสี่คือการวัดผลเทียบกับสมมติฐานที่ตั้งไว้ ถ้าระบบไม่เป็นไปตามที่คิด เราก็ได้พบจุดอ่อนที่ต้องแก้ไขก่อนถึงวันเกิดเหตุจริง

จะแยกความต่างระหว่าง Chaos Engineering ที่ดีกับการก่อวินาศกรรมโดยไม่ได้ตั้งใจได้อย่างไร?

สิ่งที่แยกการทำ Chaos Engineering ที่ดีออกจากการก่อวินาศกรรมโดยไม่ได้ตั้งใจคือขอบเขตและการควบคุม ทีมที่ทำถูกต้องจะเริ่มจากสภาพแวดล้อมทดสอบก่อน แล้วค่อยเริ่มจากความผิดพลาดเล็กที่สุด และที่สำคัญคือต้องมีสวิตช์หยุดฉุกเฉินเสมอ เพื่อหยุดการทดลองทันทีเมื่อสถานะเสถียรถูกทำลายเกินกว่าที่ยอมรับได้ ความแตกต่างระหว่างวิศวกรที่ทดสอบระบบกับคนที่ทำระบบพังโดยไม่ได้ตั้งใจอยู่ตรงที่คนแรกมีแผนชัดเจน มีการวัดผล และรู้ว่ากำลังทำอะไรอยู่ตลอดเวลา ส่วนคนที่สองค้นพบความล้มเหลวโดยบังเอิญและไม่มีข้อมูลอะไรเลยตอนที่ต้องหาสาเหตุ

คลัสเตอร์ ClickHouse มีจุดเปราะบางตรงส่วนไหนบ้างที่ควรทดสอบ?

จุดเปราะบางของคลัสเตอร์ ClickHouse มีอยู่หลายชั้น ชั้นแรกคือชั้นจัดเก็บข้อมูล เมื่อใช้การจำลองข้อมูลแบบสามโหนด หากหนึ่งโหนดตายระบบยังอยู่รอดได้ แต่สิ่งที่ต้องทดสอบคือระหว่างที่โหนดกำลังกู้คืนข้อมูลกลับมา ประสิทธิภาพของทั้งคลัสเตอร์จะได้รับผลกระทบแค่ไหน เคยมีกรณีที่โหนดกลับมาหลังหยุดทำงานเพียงสองชั่วโมง แต่การกู้คืนข้อมูลกินทรัพยากรจนทำให้การสอบถามอื่นช้าลงถึงหกเท่า ชั้นที่สองคือชั้นประสานงานแบบกระจาย เพราะคำสอบถามจะถูกแยกย่อยไปทำงานหลายโหนดพร้อมกัน ถ้าโหนดใดตอบช้าหรือตา

แนะนำเพิ่มเติม

🎯 เปิดบัญชี XM Forex → สมัคร

📱 แอป iCafeFX → ดาวน์โหลด

📊 สัญญาณฟรี → รับสัญญาณ

📚 คู่มือเทรด → SiamCafeBook

🤝 สมัคร Partner XM → pipaffiliates.com/c?c=72816&l=th&p=6