จัดบ้านด้วยอัลกอริธึม

ตะกี้สอนลูกจัดห้องด้วยอัลกอริธึม ‘คิวบิก’
สมมติฐานคือ ของทุกอย่างยังอยู่ในห้อง แค่ย้ายที่สลับเปลี่ยน เพื่อให้แต่ละจุดในห้องเป็นระเบียบขึ้น

แต่ก็อยากใส่ Evictor Pattern (POSA3) เข้าไปด้วย เพื่อเฝ้าข้าวของที่ไม่มีผลต่อจิตใจที่เข้าข่ายอัลกอริธึม LRU & LFU (lease recently use & least frequently use) จะได้มาทริกเกอร์ garbage collector อย่างผมเข้าไปจัดการ 😆

ของเยอะแต่เป็นระเบียบและเป็นพวก MRU & MFU (most recently use & most frequently use) ก็ว่าไปอย่าง 😄

การออกแบบสถาปัตยกรรมซอฟต์แวร์ก็ไม่ต่างกัน
ต้องวาง architectural structure ก่อน behavior
แต่ต้องเข้าใจ behavior ก่อนวาง structure….

มาใช้ Parallelization ลดเวลารันงานกันเถอะ

เจองานที่นึงใช้ stored procudure รัน 400,000 งาน แบบวนลูป 400,000 รอบ โดยแต่ละงานเป็นอิสระกันทั้งการประมวลผลและข้อมูล เลยแนะนำให้ปรับเป็น parallelization กระจายงานไปรันในหลายคอร์ซีพียู

nl = j / (nc * 2)

nl = จำนวนลูปทั้งหมด
j = จำนวนงาน
nc = จำนวนคอร์ซีพียู

สมมติปัจจุบัน 1 วินาทีรันได้ 20 งาน เท่ากับต้องใช้เวลาทั้งหมด 400,000 / 20 / 3,600 = 5.55 ชั่วโมง
รันลูป 1 รอบต่อ 1 งาน ใช้เวลา 1/20 = 0.05 วินาที

สมมติเครื่องมีซีพียู 32 คอร์ ปกติ 1 คอร์รันได้ 2 thread
จำนวนลูปเหลือ -> 400,000 / (32 * 2) = 6,250 รอบ
รันลูป 1 รอบต่อ 64 งานใช้เวลา 0.05 วินาที (ไม่นับรวมการเข้าถึง shared hardware resources เช่น memory, I/O, network ฯ)
เท่ากับต้องใช้เวลาทั้งหมด 6,250 * 0.05 = 5.208 นาที

จาก 5 ชั่วโมงครึ่ง เหลือ 5 นาที !!!!

หรือคำนวณง่ายๆ -> (400,000 * 0.05) / 64 = 312.5 วินาที หรือ 5 นาที 12 วินาที

NOTE: การออกแบบ parallelization ต้องมีความเข้าใจพื้นฐานหลายด้าน เช่น pass by value, pass by reference, object reference, object propery & state, CPU, memory, I/O (bus หรือ PCI lane), multiprocessing, multithreading, latency, race condition/mutually exclusive, synchronization, ฯลฯ

ถ้าเป็น parallelization ผสม distributed computing ที่ต้องกระจายงานไปรันหลายเครื่อง อันนี้ก็จะปวดหัวเพิ่มนิดนึง ต้องเข้าใจเพิ่มพวก network computing, master-slaves, event-driven, proactor-reactor, stub-skeleton, distributed data, share data

ไอเดียออกแบบระบบจอง

เมื่อเช้าวันที่ 24 มกราคม 2564 มีคนแห่จองหุ้น OR ทางเว็บ K-My Invest เป็นจำนวนมาก จนเว็บล่มเป็นระยะๆ เลยจะมาเล่าไอเดียการออกแบบระบบจอง แบบสนุกๆ กัน 😉 (แต่ผมจองได้นะ เจอหน้า error ไม่กี่ครั้ง สาเหตุปลายทางน่าจะ test พลาด สาเหตุต้นทางน่าจะประเมิน scenario พลาด และการพัฒนาระบบพลาด แต่ก็เอาใจช่วยครับ สู้ๆ เลิฟๆ ปรึกษาอดีตผู้บริหารที่ย้ายไปอยู่ KTB ได้ครับ ว่าเขาทำยังไงให้รับมือคนเข้ามาสมัครสิทธิโครงการคนละครึ่งได้ 1.34 ล้านคนเสร็จใน 9 นาที)

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

ระบบแบบนี้มีคุณลักษณะ (characteristics) คล้ายกันหลักๆ ได้แก่

1. คนจำนวนมากจากทุกสารทิศเข้ามา access ระบบพร้อมๆ กัน
2. สินค้า (ตั๋ว/ที่นั่ง/สิทธิ/จำนวนหุ้น) มีจำนวนจำกัด
3. มีความต้องการจองสินค้าเดียวกันพร้อมกัน (แบบจองตั๋วหนักสุด)
4. มีระยะเวลาจองจำกัด

technical concern สำคัญ ได้แก่

1. load & I/O ไล่ตั้งแต่เน็ตเวิร์กยัน bus ในเครื่องเลย
2. state ของสินค้า
3. operation เช่น ค้นหา แสดงผล จอง ยกเลิก ชำระเงิน
4. ลูกค้า/ผู้ใช้บริการ ซื้อ/จอง/ใช้สิทธิ ได้ครั้งละเท่าไหร่ เช่น โครงการคนละครึ่งใช้ได้ 1 คน/1 สิทธิ, จองหุ้น OR ขั้นต่ำ 300 หุ้น
5. resource utilization เช่น IT resource capacity ที่มีในมือ
6. existing resources เช่น database, web/app server เป็นแบบไหน รองรับ scale out ได้หรือไม่ และยิ่งถ้ามีแต่ RDBMS ก็ฉิบหายแน่ ไม่ต้องเปิดตัว รอล่มได้เลย

โซลูชั่น คร่าวๆ แบบไม่แตะทฤษฎีและศัพท์เฉพาะ และขออธิบายเฉพาะท่อนสินค้า เพราะท่อนจัดการ load & scale out สมัยนี้ทำไม่ยากแล้ว ใช้ตังค์โยนงานขึ้นไปรันบนเมฆโลด

ทำไม Apple M1 ถึงเริ่ด – เล่าในมุมมอง software architect

ผมได้อ่านเรื่องราวความเป็นมาและรายละเอียดของชิป M1 ของ Apple แล้วรู้สึกทึ่ง และหมั่นไส้นิดๆ จึงอยากมาเล่าถึงความดีงามของชิป M1 (ส่วนความหมั่นไส้ไว้เล่าช่วงท้าย) ในมุมมอง software architect

จุดเด่นสุดๆ ในมุมมองผมคือ การที่ Apple ออกแบบชิป M1 ในแบบ ‘centralization‘ ซึ่งทาง Apple เรียกแนวคิดนี้ว่า ‘System on Chip (SoC)’ ที่เป็นการรวมส่วนการประมวลผลสำคัญๆ มาไว้ในชิปเดียวกัน โดยการทำงานของแต่ละส่วนการประมวลผลถูกแยกออกอย่างเป็นอิสระกันอีกที ดูได้จากรูปด้านล่าง (รูปจาก https://www.apple.com/th/mac/m1/)

ผมขออธิบายมุมมองผมออกเป็นข้อย่อยๆ ดังนี้นะครับ

• แต่ละส่วนการประมวลผลทำหน้าที่เฉพาะของตัวเองชัดเจน (high modularity & separation of concerns)
• มีการออกแบบ communication path เพื่อเชื่อมแต่ละส่วนการประมวลผล ให้แต่ละส่วนเชื่อมต่อ รับ/ส่ง ข้อมูลกันบน shared communication path เดียวกัน และเมื่อทุกส่วนอยู่บนชิปเดียวกันทำให้ระยะทางที่ข้อมูลต้องเดินทางสั้นลง เวลาหน่วง (latency) ในการเดินทางของข้อมูลจึงน้อย จึงทำให้แต่ละส่วนการประมวลผลรับ/ส่งข้อมูลระหว่างกันได้รวดเร็วกว่าสถาปัตยกรรมคอมพิวเตอร์แบบเดิมๆ ที่ฮาร์ดแวร์ส่วนต่างๆ ทั้ง CPU, RAM, GPU (การ์ดจอ) ติดตั้งแยกกันบนเมนบอร์ด การรับ/ส่งข้อมูลระหว่างกันต้องอาศัย bus บนเมนบอร์ด ทำให้เกิด dependency กับประสิทธิภาพของเมนบอร์ดแต่ละรุ่นแต่ละยี่ห้อ ซึ่งส่งผลต่อ stability หรือความเสถียรต่อการรันแอพพลิเคชั่น เช่น การเซ็ตอัพเครื่องคอมพิวเตอร์ 2 เครื่องโดยใช้ CPU, RAM, GPU สเป๊กเดียวกันเป๊ะ แต่ใช้เมนบอร์ดคนละรุ่นกัน จะไม่สามารถรับประกันได้ว่าการรันแอพพลิเคชั่นเดียวกันบน 2 เครื่องจะให้ประสิทธิภาพ เช่น ความเร็ว ได้เท่ากันเสมอไป
• นอกจากการใช้ communication path ร่วมกันแล้ว แต่ละส่วนการประมวลผลยังใช้ shared memory pool ร่วมกันอีกด้วย ทำให้แชร์ข้อมูลร่วมกันได้สะดวก ต่างจากฮาร์ดแวร์แบบเดิมๆ ที่ข้อมูลต้องวิ่งผ่าน bus บนเมนบอร์ดก่อน
• ในการประมวลผลอัลกอริธึมด้าน machine learning นั้น การแลกเปลี่ยนข้อมูลกันระหว่าง CPU กับ GPU ถือเป็นเรื่องสำคัญคอขาดบาดตายมากๆ เพราะมีผลต่อ latency มาก หาก latency สูง ก็จะเกิดคอขวด ทำให้การประมวลผลระหว่าง CPU กับ GPU จะช้าไปด้วย
• ยิ่งข้อมูลมีขนาดใหญ่ หากต้องรับ/ส่งกันผ่าน bus บนเมนบอร์ดแบบฮาร์ดแวร์แบบเดิมๆ ก็จะยิ่งช้า และหากรับ/ส่งข้อมูลไปมากันบ่อยๆ จะยิ่งใช้พลังงานมาก ส่งผลให้ใช้ไฟมากขึ้น หากเป็นโน้ตบุ๊กก็จะกินไฟจากแบตเตอรี่มากนั่นเอง
• แนวคิดของ pool คือการรวมทรัพยากรที่ใช้ร่วมกันและเข้าถึงบ่อยๆ มาเก็บไว้ที่เดียวกัน ช่วยลด latency จากการ instantiate ข้อมูลเดิมซ้ำๆ บ่อยๆ จึงช่วยเพิ่มความเร็วในการเข้าถึงข้อมูลได้ดี และยังสามารถ จองและจัดสรรปริมาณ ให้เหมาะสมกับปริมาณและความถี่ในการใช้งานโดยแต่ละส่วนการประมวลผล และยังช่วย หมุนเวียนการใช้ทรัพยากร (recycle) ภายใต้ข้อจำกัดของทรัพยากร (resource constraint) อย่างขนาดและปริมาณของฮาร์ดแวร์ที่มีได้อย่างดี
• ยกตัวอย่างเช่น การใช้ object pool ในงานซอฟต์แวร์ เช่น สมมุติระบบพีควันละ 4 ชั่วโมง มี request เข้ามาเฉลี่ย 1,000 request/วินาที ทุก request ต้องใช้อ็อบเจ็คต์ CommonAppService จะทำให้ต้อง instantiate อ็อบเจ็คต์ CommonAppService ถึง 1,000 (request) x 3,600 (วินาที) x 4 (ชั่วโมง) = 14.4 ล้านอ็อบเจ็คต์!!! แต่หากสามารถคุมอัตรา execution time ของรอบการทำงานของแต่ละ request ให้ สามารถคาดการณ์ได้ เช่นไม่เกิน 1 วินาทีแน่ๆ แบบนี้หากเปลี่ยนมาใช้ pool เพื่อเก็บอ็อบเจ็คต์ ก็จะสร้างอ็อบเจ็คต์ CommonAppService อย่างน้อยเพียง 1,000 อ็อบเจ็คต์!!! ก็พอ เพราะเมื่ออ็อบเจ็คต์ใดถูกใช้งานเสร็จก็ไม่จำเป็นต้องลบทิ้ง (ต้องเช็ก state ก่อนนะ) แค่เอาไปเก็บใน pool ต่อ ไม่ต้อง instantiate ใหม่นั่นเอง แต่สร้างแค่พันนึงมันปริ่มๆ ไป ควรสร้างเผื่อๆ ไว้หน่อย จากตัวอย่างดังกล่าว pool ช่วยลดโอเวอร์เฮดในการ instantiate อ็อบเจ็คต์ และหน่วยความจำในการจัดเก็บอ็อบเจ็คต์ได้มหาศาล ใช้ทรัพยากร (หน่วยความจำ, I/O ฯลฯ) น้อยลงมาก
• Apple ยังได้ออกแบบชิป M1 ให้แต่ละส่วนการประมวลผลใช้ memory pool ร่วมกันได้ เปรียบเทียบเช่น แต่ละห้องในบ้านมีตู้เสื้อผ้าเป็นของตัวเองเพื่อเก็บเสื้อผ้าของแต่ละคนเอง แต่ก็แชร์ตู้เย็นในห้องครัวร่วมกันได้ เช่น การแชร์ข้อมูลร่วมกันระหว่าง CPU กับ GPU ในชิป M1
• เมื่อความเร็วโดยรวมในการประมวลผลรวดเร็วปรู๊ดปร๊าดขึ้นมากๆๆๆ ข้อมูลที่วิ่งไปมาระหว่างแต่ละส่วนก็รวดเร็วมหาศาล เปรียบเสมือนน้ำป่าไหลบ่ามารวดเร็ว เพื่อไม่ให้น้ำท่วม ก็ต้องมีแก้มลิงเอาไว้พักน้ำ ไม่อย่างนั้นอาจเกิด missed rate ในการประมวลผลสูงได้ นี่จึงเป็นที่มาของการมี shared cache เพื่อให้แต่ละส่วนใช้ ‘แก้มลิง’ ร่วมกัน ไม่ต้องแยกกันมี cache (แคช) เป็นของตนเองแบบฮาร์ดแวร์แบบเดิมๆ ที่ CPU ก็มี cache เป็นของตนเอง, GPU ก็มี cache เป็นของตนเอง, RAM ก็ยังมี cache เป็นของตนเองอีก อย่างนี้ก็เปลืองสิ เปลืองทั้งการประมวลผลเพื่อจัดการ cache เปลืองทั้งการใช้พลังงาน แล้วฮาร์ดแวร์แต่ละรุ่นยังมีขนาดและความเร็วของ cache แตกต่างกันอีก การคุม latency และความเสถียรจึงยาก
• แนวคิดของ cache คือการเป็น buffer เพื่อพักข้อมูลชั่วคราว ให้นึกถึงการบวกเลข หากบวกกันแค่ 2 จำนวน เราอาจคิดในใจได้ แต่หากต้องบวกกัน 20 จำนวนอาจต้องพึ่งกระดาษทดเลข ซึ่งเจ้ากระดาษทดเลขนี้ก็คือ cache นั่นเอง
• การออกแบบแต่ละส่วนการประมวลผลให้ทำงานแยกอิสระกัน เปรียบแล้วเหมือนกับห้องต่างๆ ในบ้านหลังเดียวกัน ที่แชร์บันไดร่วมกัน แชร์ท่อประปาและไฟฟ้าร่วมกัน แชร์ห้องครัวร่วมกัน แชร์ที่จอดรถร่วมกัน แชร์สวนร่วมกัน ขณะที่แต่ละห้องสามารถตกแต่งภายในเป็นอิสระจากกันได้ การพัฒนาเพื่อเพิ่มประสิทธิภาพหรือ customize การประมวลผลแต่ละส่วนจึงเป็นอิสระกัน เพียงแค่ยึด interface เดิมที่แชร์ใช้ร่วมกันกับส่วนอื่นๆ ไว้เหมือนเดิม เป็นการคุม governance ระหว่างส่วนการประมวลผลให้ดี เปิดโอกาสให้เกิด intrinsic modification ภายในแต่ละส่วนได้
• เมื่อ Apple สามารถออกแบบชิปที่รวบการประมวลผลสำคัญๆ มาไว้ด้วยกัน จึงส่งเสริม product line architecture เพื่อช่วยให้ลดต้นทุนทั้งค่าใช้จ่ายและเวลาในการผลิตผลิตภัณฑ์หลายชิ้นที่ Apple วางแผนจะใช้ชิป M1 ได้ ทำให้ควบคุม stability + variability + compatibility หรือเรียกได้ว่า overall hardware control ได้เป็นอย่างดี แน่นอนเมื่อคุมได้เบ็ดเสร็จขนาดนี้ ในแง่ customer support, technical support, sales support ก็จะง่ายสะดวกและประหยัดขึ้น การออกแบบและผลิตผลิตภัณฑ์ใหม่ๆ ที่จะใช้ชิป M1 ก็จะใช้เวลาน้อยลง เพราะลดการพึ่งพาฮาร์ดแวร์จากผู้ผลิตรายอื่นลง นี่จึงส่งผลต่อราคาผลิตภัณฑ์ที่ใช้ชิป M1 มีราคาถูกลงไปด้วย
• Apple เพียงทุ่มเทออกแบบสถาปัตยกรรมชิป M1 กำหนดสเป๊กของแต่ละส่วนการประมวลผล แต่… Apple ไม่จำเป็นต้องเสียเวลาและงบประมาณค้นคว้าวิจัยและผลิตฮาร์ดแวร์แต่ละส่วนเองเลย เพียงแค่ซื้อสิทธิบัตรแล้วว่าจ้างผลิต แล้วเน้นคุมสเป๊ก คุมภาพรวม คุมการทำงานร่วมกัน นี่เป็นตัวอย่างที่ดีมากๆ ในด้าน agile product development โดยการมุ่งเน้นไปที่ ‘การออกแบบและคุมสถาปัตยกรรม‘
• หนึ่งในหัวใจของ architecture คือ business กับ IT ต้อง align กัน ต้องเดินไปด้วยกัน

Design Communication

จำได้ว่าข้อสอบ Certified Enterprise Architect ที่เคยสอบเมื่อเกือบ 20 ปีก่อน ข้อสอบปรนัยที่เกี่ยวกับ Design Pattern, Architectural Pattern เขาให้โจทย์มายาวเฟื้อย แล้วถามว่าควรใช้ pattern อะไรแก้ปัญหา บางข้อก็ให้เลือก pattern ที่จะใช้แก้ปัญหานี้มา 3 ตัว จากตัวเลือก

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

ส่วนข้อสอบออกแบบ ต้องออกแบบ architecture แล้วส่งไปให้ฝรั่งที่เมกาตรวจ แล้วให้ไปสอบบรรยายที่ศูนย์สอบ บรรยายข้อละ 1 หน้า เป็นการอธิบาย Design Rationale.ข้อสอบเขาไม่สนใจ implementation เท่าไหร่เลย เขาสนใจที่ pattern ที่เลือก และ เหตุผลในการออกแบบ ว่าทำไม…ถึงเลือกใช้โซลูชั่นนี้แก้ปัญหา

นั่นเพราะ… ในโลกการทำงาน (ไม่ใช่ตอนสอบ) เมื่อนึก pattern ได้ว่าจะใช้ตัวไหนแก้ปัญหา ที่เหลือก็แค่… เปิดหนังสือ​ได้ ในนั้นมีอธิบายข้อดีข้อเสีย แนวทางนำไปใช้ มีตัวอย่างซอร์สโค้ด มี class diagram, sequence diagram ให้ดูเป็นแนวทาง.และเมื่อเลือกโซลูชั่นแล้ว ต้องมีเหตุผลรองรับ เมื่อมีคนถามคนสงสัยมีคนไม่เข้าใจ ต้องชี้แจงได้ ต้องมี Design Communication ไม่งั้นไม่มีใครเชื่อถือดีไซน์

แก้ปัญหาระบบแบงก์ล่ม ขำๆ

เมื่อระบบธนาคารชอบล่ม แก้ไงดี? (ยาวหน่อย ไม่มีรูปประกอบด้วย ขี้เกียจวาด)

เตรียมพร้อมก่อน

1. วาดรูป blueprint มีสัญลักษณ์แค่ 5 อย่างพอ คือ 1) วงกลมหมายถึงระบบ/webservice/microservice 2) เส้นทึบคือโฟลว์การ call (หันหัวลูกศรให้ถูกฝั่งด้วย) 3) เส้นประคือโฟลว์ข้อมูล 4) กล่องสีเหลี่ยคือnode/instance/server 5) สัญลักษณ์อะไรก็ได้ที่ไม่ซ้ำกับ 4 อันก่อนหน้า คือ resource/database/infra instance แล้วโยงเส้น call กับ data flow (ทั้ง input/output) ไล่ตั้งแต่ปุ่มบนหน้าจอหลักทุกปุ่มทุกเมนู หากไคลเอ็นต์เป็น third part เข้าถึงระบบธนาคารผ่าน API ก็ไล่ตั้งแต่ API เข้ามา วาดกล่องโยงเส้นไล่ไปให้สุดๆ
2. จากข้อ 1. ต้องวาดจนกว่าจะเคลียร์กับ I/O, process, thread (ถ้าไล่ลงลึกไประดับ thread ได้จะแจ่มมาก), shared resource?, synchronisation & scheduling algorithm
3. จากข้อ 1. ต้องระบุคุณสมบัติแต่ละจุด เช่น stateless, stateful แล้วระบุช่วงเวลาว่าจุดนั้นๆ peak ช่วงวันไหน ช่วงเวลาไหน มีกี่ request/sec (เอา log มาวิเคราะห์) แล้ว event source ที่ทำให้ peak คืออะไร เช่น บริการโอนเงิน peak วันสิ้นเดือนเพราะคนโอนเงินกันเยอะ, บริการชำระค่าสินค้า/บริการ peak วันสิ้นเดือนเพราะจ่ายค่าสาธารณูปโภคกันเยอะ แล้วมีจุดใดบ้างที่ไป call external system นอกแบงก์ เกี่ยวข้องกับบริการอะไร
4. หาจุดที่มีโอเวอร์เฮดสูงๆ (มักเป็น shared resource) ทั้ง ระบบไอที ฮาร์ดแวร์ เน็ตเวิร์ก ดูว่ามีอะไรอยู่ในนั้น 
5. ก่อนจะไปขั้นต่อไป ปรับทัศนคติก่อน เลิกการคิดว่า ฟังก์ชั่นคล้ายกันต้องอยู่ด้วยกัน ระบบคล้ายกันต้องอยู่ที่เดียวกัน การทำงานเกี่ยวข้องกันต่อเนื่องกันต้องอยู่บนเครื่องเดียวกัน
6. เปลี่ยนทัศนคติเป็น ต้องสนใจที่ ‘พฤติกรรมระบบ กับ พฤติกรรมการใช้ทรัพยากร’ ของระบบ/ซอฟต์แวร์/service/microservice/database ฯลฯ บางเครื่องควรมีแต่ระบบที่มีพฤติกรรมเหมือนกัน บางเครื่องควรมีแต่ระบบที่มีพฤติกรรมต่างกัน เช่น เอา microservice ที่ใช้ซีพียูหนักๆ เวลา 7:00 – 21:00 ตลอดวันสิ้นเดือน มารันบนเครื่องเดียวกับ microservice อีกตัวที่ใช้ซีพียูหนักในช่วงเวลาเดียวกันเลย แบบนี้มันก็แย่งกันสิ…. กรุณาอย่าแถว่าเครื่องที่ใช้มีซีพียูหลายตัว หลายคอร์ แต่ซีพียูยังไม่สาหัสเท่า…หน่วยความจำครับ ระบบที่ใช้หน่วยความจำหนักๆ ต้องจับแยกเครื่อง การใช้หน่วยความจำหนักมี 2 แบบ คือ ใช้เยอะ กับใช้นาน สิ่งที่เราต้องการคือ ใช้น้อย และ ใช้เสร็จเร็ว
7. ระบบแบงก์มักล่มวันสิ้นเดือน แบบนี้แก้ง่าย เพราะเป็น periodic event คาดการณ์ได้ ทำแผนสำรองได้ และๆๆๆๆ เอา AI มาช่วยได้…ง่ายเลย (แต่ยังไม่บอก เอาไว้ก่อน อิอิ)

Market Classification Using Deep Neural Network

วันนี้หัวไม่แล่น พักเขียนโค้ด template สำหรับเทรด FOREX แป๊บ มาทำ predictive model เล่นๆ แต่ไปๆ มาๆ ผลออกมาดีกว่าที่คิด เลยดื่มด่ำต่อทั้งวัน เลยคิดว่าเสร็จแล้วก็จะเอาไปใช้จริงซะเลย ตั้งใจเอาไปใช้ร่วมกับกลยุทธ์ที่ใช้ multiple-timeframe

เนื่องจากผมและกลุ่มของเรามักเทรดด้วย timeframe เล็กๆ กันมากกว่า ดังนั้นมุมมองของการแบ่งรูปแบบตลาดจึงมองจากสไตล์การเทรดสั้น ต้องบอกไว้ก่อนเพราะเดี๋ยวดูรูปด้านล่างแล้วอาจงงได้ เพราะเรื่องของเทรนด์และรูปแบบตลาด เราไม่จำเป็นต้องมองเหมือนกัน เพราะกลยุทธ์เราอาจต่างกัน… เหมือนขงเบ้งประเมินสมรภูมิรบ….

โมเดลที่ทำเล่นในวันนี้เป็น predictive model ใช้ Deep Neural Network (DNN) ซึ่งเป็น Deep Learning สายหนึ่งที่เป็นที่นิยมกัน เอามาใช้ classify รูปแบบตลาด โดยใช้ข้อมูล end of day ของ SET index

Design Thinking

ช่วงนี้มีคนฝึก Design Thinking (https://en.m.wikipedia.org/wiki/Design_thinking) กันเยอะ เลยมาเสนอไอเดียเสริม
.
แนะนำศึกษาเรื่องเหล่านี้ประกอบ:

• การตลาดพื้นฐาน เน้นไปทางด้านวิเคราะห์ตลาด ลูกค้า ผลิตภัณฑ์ แผนการตลาด
• product design & production design
• การออกแบบ/วางแผนยุทธศาสตร์และกลยุทธ์
• การวิเคราะห์เชิงบูรณาการ

เพราะจะช่วยเสริมความเข้าใจได้ลึกขึ้น

เนื่องจากเราควรกำหนดเป้าหมายก่อนค้นหาและประเมินปัญหา วิเคราะห์ปัจจัยรอบด้านโดยไม่มีอคติ คิดโซลูชั่นทั้งแบบในกรอบและนอกกรอบ ประเมินผลกระทบระหว่างกัน และฝึกมองสิ่งต่างๆ ทั้งแบบ inside-out และ outside-in สำหรับนักไอทีต้องเน้น outside-in เยอะๆ โดยเฉพาะในมุมมองของ user หรือลูกค้า เวลาพิจารณาสิ่งใดก็คำนึงถึง goal constraint concern who what when where why how value impact opportunity solution ให้ชิน
.
อ้อออ… แนะนำศึกษา consulting นิดก็ดีครับ เช่น เทคนิควิเคราะห์ปัญหาและออกแบบโซลูชั่นในแบบที่ปรึกษา รวมถึงการคิดเชิงคุณภาพและปริมาณควบคู่กันเสมอ
.
ฝึก Design Thinking จะช่วยให้เป็น strategist และ solution architect ที่ดีได้มาก
.
โชคดีครับ… ทุกปัญหาแก้ได้ด้วย Design ^_^

ประยุกต์ Software Product Line กับการพัฒนา Algo Trading Robot

ตัวอย่างการนำแนวคิด Software Product Line มาใช้กับการพัฒนา Algorithmic Trading Robot ด้วยการวาง Product Line Architecture โดยจัดระดับการ reuse เป็นขั้นๆ ล่างสุดมีระดับการ reuse มากสุด วัตถุประสงค์หลักคือ เพื่อ reuse core asset, ลดต้นทุน คน เงิน เวลา ในการพัฒนาและดูแล, ลดความซ้ำซ้อน, คุมความซับซ้อนหลากหลายให้เรียบง่าย

จากรูปไล่จากล่างสุดขึ้นมา:

• Common reusable elements : แบ่งเป็น 2 ชั้นย่อย ชั้นล่างสุดคือกลไกการทำงานที่ไม่อิงกับสินค้าและตลาดใดๆ ชั้นถัดขึ้นมาคือ กลไกที่อิงกับสินค้าหรือตลาด เช่น กลไกการเชื่อมต่อตลาด, กลไกการตรวจสอบออร์เดอร์
• Robot template : เป็นเทมเพลตซอร์สโค้ดสำหรับบอทที่เทรดในสินค้าหรือตลาดนั้นๆ ประกอบด้วยเทมเพลตการทำงานพื้นฐานในส่วนต่างๆ อาทิ endpoint, strategy controller, alpha model, risk model, transaction cost model, portfolio construction model, execution model, robot context, robot config
• Robot blueprint : คือพิมพ์เขียวของบอทสำหรับเทรดสินค้าหรือตลาดนั้นๆ โดยการก๊อปปี้ robot template ที่ต้องการมาใส่รายละเอียดการทำงานเพิ่มเติม ให้มีความเฉพาะเจาะจงขึ้น ก่อนนำไปสร้างจริงเพื่อนำไปใช้เทรดจริง โดยพิมพ์เขียวแต่ละตัวมีความเฉพาะเจาะจงแตกต่างกันไป อาทิ trading strategy, rules, regularization/validation, predictive model, strategy setting, time frame ฯลฯ พิมพ์เขียวของบอทแต่ละตัวจะมีชื่อของตัวเอง เช่น ผมชอบใช้ชื่อปลาเพราะสมัยก่อนชอบดำน้ำ ผมก็มีพิมพ์เขียวบอทชื่อ Nemo, Goby, Barracuda, Orca, Whale Shark,…
• Robot product : คือบอทที่จะนำไปใช้เทรดจริง เป็นการก๊อปปี้ robot blueprint มาใส่เงื่อนไขเพิ่มเติม ปรับค่า strategy setting และค่า setting อื่นๆ ตามที่ต้องการ

อย่า Forward Test เพื่อดู Trading Performance

ถ้าตั้งใจจะดู trading performance จริงๆ ต่อให้ทำ forward test ไปหนึ่งปีก็ไม่เห็นผลชัดเจน บางระบบอาจจะกำไรสูงมากในหนึ่งปีที่ทำ forward test แต่อาจเพราะบังเอิญตลาดปีนั้นมันเหมาะเจาะกับระบบเราพอดี แต่ใครจะไปรู้ว่าปีต่อไปๆๆ มันจะทำกำไรดีอย่างนี้แค่ไหน นั่นหมายถึงมันจะมี robustness & reliability ดีๆ อย่างนี้ไปได้อีกนานแค่ไหน

เครดิตภาพจาก https://exceltradingmodels.com/step-9-forward-test-your-excel-trading-model/

.

เจอใครหลายคนมักถามถึง forward test กับระบบ Algorithmic Trading System & Robot

.

อธิบายงี้ครับ การทำ forward test ไม่ได้เอาไว้เพื่อดู ‘trading performance‘ นะครับ คนส่วนมากมักเข้าใจผิด เช่นทำระบบเสร็จก็ลองรันเดือนสองเดือนเพื่อดู performance

.

คำว่า ‘performance’ นี้ หลายคนเข้าใจคลาดเคลื่อน ศัพท์คำนี้มันกว้าง ต้องโฟกัสให้แคบว่าเราสนใจ ‘ประสิทธิภาพ’ ของ ‘อะไร’

.

forward test มีไว้เพื่อดู system performance กับ overall performance เช่น ดูว่าระบบมีเสถียรภาพดีมั้ย มีดีเลย์บ้างมั้ย ช้ามั้ย สะดุดบ้างมั้ย เวลาเจอเน็ตช้า ไฟตก ระบบค้างมั้ย เจอ bug อะไรบ้างมั้ย มีฟังก์ชั่นไหนทำงานจริงแล้วไม่ตรงเหมือนตอนทดสอบบ้าง ฯลฯ

.

ถ้าจะดู trading performance ในการทำ forward test ควรเน้นไปที่การได้รันกับสภาพแวดล้อมจริง เรียลไทม์ ข้อมูลจริง เพื่อดูว่า slippage กับ spread จริงมันคลาดเคลื่อนจากที่ทดสอบมากมั้ย ออร์เดอร์ match เร็ว/ช้ายังไงบ้าง ตลาดมีดีเลย์บ้างหรือเปล่า (บางทีระบบเราไม่ช้า แต่ตลาดช้า เช่นช่วง panic) และยังใช้ประเมินความโลภของตนเองได้ เพราะบ่อยครั้งตอนทำ backtest เราอาจเผลอโลภเมื่อเห็นผลกำไรหลังทดสอบ และเผลออยากได้เพิ่มก็เลยปรับ position size ให้ใหญ่ขึ้น ปรับความเสี่ยงให้สูงขึ้น แต่พอมาลองรันจริงเทรดจริง เราอาจเกิดความกลัวขึ้นบ้าง จะได้ใช้ผล forward test มาปรับลด position size และความเสี่ยงลง เพื่อให้เราไม่กลัว

ความห่วย 3 แบบของ Algo Trading System & Robot ที่ไม่ควรมี

ระบบ Algorithmic Trading System & Robot หรือมักเรียกกันสั้นๆ ว่า ‘Algo Trading‘ คือ โปรแกรมคอมพิวเตอร์ที่ใช้ในการเทรด/ลงทุนแทนคนหรือสนับสนุนคนอีกที เพื่ออำนวยความสะดวกและทดแทนข้อจำกัดของมนุษย์

ระบบ Algo Trading ประกอบด้วยส่วนสำคัญ 3 ส่วนได้แก่ System, Trading Model และ Predictive Model

• System คือ ส่วนระบบโครงสร้าง, กลไกการทำงานและระบบควบคุมต่างๆ เช่น ส่วนเชื่อมต่อกับตลาด, ส่วนเชื่อมต่อระบบฐานข้อมูล, ส่วนจัดการ state, ส่วนรายงาน, ส่วนจัดการ cache, ส่วนจัดการความปลอดภัย, ส่วนจัดการ process และ thread, ส่วนจัดการ ฯลฯ
• Trading Model คือ โมเดลระบบเทรด/ลงทุน เช่น ส่วนจัดการการเปิด/ปิดสถานะ, ส่วนจัดการความเสี่ยง, ส่วนจัดการ transaction cost, ส่วนส่งคำสั่งซื้อ/ขาย, ส่วนจัดการคำสั่งซื้อ/ขาย, ส่วนจัดการพอร์ตโฟลิโอ, ส่วนควบคุมลำดับการเทรด/ลงทุน ฯลฯ
• Predictive Model คือ โมเดลส่วนทำนายต่างๆ เช่น ส่วนทำนายจุดเข้าซื้อ/ขาย, ส่วนทำนายจุดไม่เข้าซื้อ/ขาย, ส่วนทำนายจุดวาง stop loss, ส่วนทำนายการ scale in/out, ส่วนทำนายรูปแบบตลาด ฯลฯ

สงคราม Algo Trading Robot

ต่างประเทศและในบ้านเราเริ่มมีหลายคนหันมาทำหลักสูตรและเผยแพร่ความรู้ผ่านสื่อออนไลน์ในการสร้างหุ่นยนต์เทรด (Alrotihmic Trading Robot หรือ เรียกสั้นๆ ว่า Algo Trading Robot หรือสั้นขึ้นอีกเป็น Trading Robot) บางคนก็รับเขียนโปรแกรม Algo Trading Robot ให้ผู้ที่สนใจอยากลงทุนผ่านหุ่นยนต์ บางองค์กร เช่น กองทุนและโบรกเกอร์หลายราย (ซึ่งกำลังมีจำนวนเพิ่มมากขึ้นเรื่อยๆ) ได้เปิดให้บริการ Algo Trading Robot แก่ลูกค้าอย่างเป็นทางการ… จึงเป็นที่มาของข้อสงสัยที่เคลือบแคลงใจคนจำนวนมากว่า หุ่นยนต์เหล่านั้นน่าเชื่อถือเพียงใด และ ผู้ที่ทำหลักสูตร, เผยแพร่ความรู้, และที่ให้บริการที่ไม่ใช่สถาบันการเงิน น่าเชื่อถือเพียงใด

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

และยิ่งในปัจจุบันที่มีการนำ AI, Machine Learning และ Data Science มาใช้ในการสร้าง Algo Trading Robot กันมากขึ้น มันจะฉลาดขึ้นจริงหรือ? คนที่ใช้จะคุ้มค่าได้กำไรจริงหรือ? เมื่อแนวโน้มจะมีคนหันมาลงทุนผ่านหุ่นยนต์เหล่านี้กันมากขึ้น

credit ภาพ: http://www.smh.com.au/

หลักสูตรอบรม Algo Trading

หลักสูตรอบรม: ออกแบบและสร้าง Algorithmic Trading System & Robot

รายละเอียดล่าสุดของคอร์สนี้ดูในลิงค์นี้ครับ -> https://deepquantspace.com/2021/08/15/algo-trading-course/

สำหรับผู้ที่ต้องการมีหุ่นยนต์เทรด/ลงทุนไว้ใช้งานส่วนตัว หรือผู้สนใจงาน Quant, Quant Developer, Quant Architect

*ผู้สนใจสมัครเรียน รบกวนส่ง message มาที่เฟสบุ๊กผมได้ครับที่ https://web.facebook.com/narong.chansoi.5

หรือที่ Line ID: tuminimaliz

ผู้ที่ไม่ได้เรียนและทำงานด้านไอทีก็เรียนได้ครับ ไม่มีประสบการณ์เทรดก็เรียนได้แค่ต้องฝึกหนักหน่อย

เป็นกิจกรรมแบบฮาร์ดคอร์ ต้องการคนที่ซีเรียสจริงจังนะครับ

ผู้เรียนจะได้เรียนตั้งแต่พื้นฐานการเทรด/ลงทุน ไปจนถึงการนำ Deep Learning, AI, Machine Learning มาใช้

เครดิตรูปภาพ: http://jonathankinlay.com/

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

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

สำหรับผู้ที่สนใจอยากเป็นสปอนเซอร์สนับสนุนโครงการพัฒนาระบบ Algorithmic Trading มันๆ เข้มข้นๆ และ/หรืออยากมี trading robot และระบบไอทีไว้ใช้งาน (เฉพาะตลาดหุ้น, TFEX, FOREX, gold future, oil future) หรืออยากได้ผลงานไปใช้ต่อยอด ก็ติดต่อได้ครับ

จำนวนวันอบรม: 10 วัน (ทำไมตั้ง 10 วันแน่ะ! รบกวนอ่านไปเรื่อยๆ และอ่านหัวข้อดูก่อนครับ) เรียนทุกวันอาทิตย์ จะแจ้งวันเรียนทางเฟสบุ๊กนะครับ

R&D Statement

ผมกำลัง R&D เกี่ยวกับ Algorithmic Trading System Architecture for Multi-Asset and Multi-Market โดยสร้าง Trading Platform ขึ้น ความคืบหน้า ณ ปัจจุบัน คือกำลังสร้าง trading robot ต้นแบบ โดยใช้ Machine Learning และ Deep Learning แบบจัดเต็ม เพื่อนำตัวต้นแบบไปโคลนนิ่งสร้างเป็น trading robot ตัวใหม่ๆ สำหรับเทรด/ลงทุนในสินทรัพย์ต่างๆ ได้รวดเร็วและประหยัดเวลาเขียนโปรแกรมสร้าง trading robot ตัวใหม่ๆ ลง เพื่อให้สามารถรองรับกลยุทธ์การเทรด/ลงทุนที่หลากหลายได้

ปัจจุบันผมสร้าง trading engine และ trading robot ใช้งานจริงอยู่ ใช้มาสักพักใหญ่แล้ว โดย trading robot แต่ละตัวใช้เวลาเขียน โปรแกรม, ทดสอบ และ optimize นานมากกว่าจะเสร็จ งาน R&D นี้ ได้นำหลายหลักการมาใช้ เพื่อให้สามารถสร้าง trading robot ตัวใหม่ๆ ได้อัตโนมัติหรือกึ่งอัตโนมัติ เพื่อประหยัด โดย เฉพาะตอนทดสอบ และ ตอน optimize

จุดเริ่มต้นของผมกับ Algo Trading

หลายปีมานี้ผมหันมาสนใจงานด้าน Algorithmic Trading หรือมักเรียกสั้นๆ ว่า ‘Algo Trading’ เนื่องจากตอนแรกตั้งใจว่าฝึก ‘เล่น’ หุ้น หารายได้เสริม ไปๆ มาๆ ดันชอบและคิดว่าเข้ากับนิสัยผมมาก…

ต่อมาจึงเริ่มศึกษาด้านการเทรดและลงทุนอย่างจริงจัง และเนื่องด้วยประสบการณ์ด้านไอทีทำให้ผมมองโลกการลงทุนแบบนักไอที ใช้ logical thinking, systematic thinking ตีความทุกอย่างเป็นตรรกะและเป็นระบบ และจากประสบการณ์ในงาน software architecture ทำให้ถนัดมองภาพรวมและการคิดและวิเคราะห์ข้อมูลแบบบูรณาการ (integrated thinking & analysis) และในการทำงานด้าน Software Architecture และ Enterprise Architecture ผมต้องคลุกคลีอยู่กับการบริหารความเสี่ยงจนรู้สึกไม่ได้กลัวความเสี่ยงเว่อร์มากแบบคนจำนวนมาก ความเสี่ยงมีไว้ให้บริหารก็แค่นั้น ไม่ต้องไปกลัวมัน

เพียงไม่กี่เดือนหลังเข้าสู่ตลาดหุ้นผมก็เริ่มออกแบบระบบเทรด (Trading System) ใช้เวลาอยู่ 1 ปี จากนั้นจึงนำมาเขียนเป็นโปรแกรม และศึกษาด้าน Machine Learning, AI, Deep Learning, Data Science, Data Analytics อย่างบ้าคลั่ง ผมออกแบบและพัฒนาระบบพวกนี้มาราว 3 ปีแล้ว เป็นงานที่ทำแล้วมีความสุขและสนุกมาก ในอดีตเคยแต่ไปสอนหนังสือ เป็นที่ปรึกษา และทำงานให้ลูกค้า การมาทำโปรเจ็คต์นี้มันเป็นการได้ออกแบบระบบและเขียนโปรแกรมใช้งานเอง คิดเอง เลือกใช้สิ่งต่างๆ เอง อยากเพิ่มอยากปรับอะไรก็ลุยไม่ต้องไปถามใครหรือขออนุญาตใคร ผลงานที่ได้ออกมาดีทีเดียว เกินคาดและมาไกลกว่าที่คิดไว้ในตอนเริ่มต้น ผมจึงมุ่งมั่นทำมันต่อมาเรื่อยๆ จนปัจจุบัน

การสร้างระบบนี้ขึ้นมาตั้งใจให้กองทัพ Trading Robot ของผมออกไปทำมาหากินให้ เพราะผมมีความฝันที่อยากจะทำอะไรต่างๆ หลายอย่าง ที่อยากทำก่อนตาย Algorithmic Trading System จึงเป็นเครื่องจักรหาเงิน ส่วนผมก็ออกไปทำตามฝัน

โครงการที่ผมตั้งใจจะทำในอนาคต:

• เผยแพร่ความรู้ผ่านออนไลน์
• เขียนหนังสือ
• ทำมูลนิธิเกี่ยวกับเด็ก คนพิการ คนชรา
• ทำมูลนิธิช่วยเหลือผู้มีไอเดียแต่ขาดแรงบันดาลใจและการสนับสนุน
• ทำธุรกิจ social enterprise ช่วยเหลือองค์กรที่ประสบปัญหาด้านไอที โดยจะสร้างบุคลากรด้าน solution architect จำนวนมากเพื่อเข้าไปช่วยองค์กรเหล่านั้น
• ทำโรงเรียนพัฒนาครูแนววอลดอร์ฟ และโรงเรียนเด็กเล็กแนววอลดอร์ฟ
• เทคโอเวอร์โรงเรียนเด็กเล็กขนาดเล็กที่ประสบปัญหาธุรกิจมาปรับปรุงระบบการสอน
• ทำโครงการฝึกอบรมการเทรด/ลงทุนสำหรับผู้พิการและคนชรา
• การเกษตรแนว smart farming, digital farming
• ทำธุรกิจ social enterprise เกี่ยวกับการท่องเที่ยวพร้อมไปทำบุญและไปช่วยเหลือชุมชนยากไร้ห่างไกล
• ทำรีสอร์ทเล็กๆ แนวบ้านๆ เน้นธรรมชาติ