เนื่องจากต้องพัฒนาระบบงานโดยใช้งาน DynamoDB ของ Amazon
แต่การใช้งานอาจจะไม่สะดวกมากนัก
และอาจจะต้องมีค่าใช้จ่ายมากขึ้น
จึงเปลี่ยนมาใช้งานและทดสอบบน localhost ไปเลย
โดยใช้เครื่องมือต่าง ๆ ดังนี้
การใช้งานง่าย ๆ
[gist id="3580f87692e35474cae870dda0b1420d" file="1.txt"]เพียงเท่านี้ก็สามารถพัฒนาและทดสอบระบบงานแบบง่าย ๆ ได้แล้ว
ที่สำคัญสามารถทำการสร้าง test data ได้ตามที่ต้องการอีกด้วย
ขอให้สนุกกับการ coding ครับ
GitHub เพิ่งเปิดให้ public repository ใช้งาน template
สำหรับการสร้าง issue ได้แล้ว
นั่นทำให้เราสามารถกำหนด template ในรูปแบบของ Markdown
ให้ใช้งานง่ายขึ้น รวมทั้งสามารถ custom ตามที่ต้องการได้
ยกตัวอย่างเช่นการ custom form ของ issue ดังนี้
สามารถเข้าไปสร้างในส่วนของ Settings ของ repository นั้น ๆ ได้เลย
โดยมี template เริ่มต้ยให้ใช้ดังนี้
ตัวอย่างของ Feature request template
วันนี้เห็น VDO แนะนำ Qodana จาก JetBrains ใน Youtube
ซึ่งเป็น static code analysis หรือ code quality monitoring
ซึ่งทำงานอยู่ในเครื่องมือของ JetBrains เลย
ยกตัวอย่างเช่น IntelliJ IDEA นั่นเอง
ทำให้นักพัฒนาสามารถตรวจสอบปัญหาได้อย่างรวดเร็ว
โดยก่อนหน้านี้อาจจะใช้งาน SonarQube มาก่อน
ในตอนนี้ Qodana เป็น early access version เท่านั้น
นั่นคือยังไม่ใช่ statble version
อาจจะมีการทำงานที่ไม่เสถียร
และเต็มไปด้วยข้อผิดพลาดต่าง ๆ
แน่นอนว่าสามารถแจ้งปัญหากลับไปได้
อีกทั้งยังสามารถยังมี Docker Image ให้ใช้งานอีกด้วย
เป็นอีกเครื่องมือที่น่าสนใจ
สำหรับการ monitoring เรื่องของ code quality ให้นักพัฒนาสะดวกยิ่งขึ้น
อ่านบทความเรื่อง Best practices for writing code comments จาก StackOverflow
ทำการสรุปและคำแนะนำเกี่ยวกับการเขียน comment ใน code ที่ดี
เพื่อช่วยให้คุณภาพของ code ดีขึ้น
มีประโยคที่น่าสนใจคือการเขียน comment ที่แย่ ๆ มันแย่กว่าการไม่เขียนอีกนะ
ดังนั้นเราไม่ควรเขียน comment ใช่หรือไม่ ?
เพราะว่า แม้จะเขียนไม่ดี compiler ก็ไม่ได้ตรวจสอบให้
ถ้า comment ไม่ตรงกับการทำงานจริง ก็ไม่มีอะไรเกิดขึ้น
ดังนั้นการเขียนมันใช้ทั้งเวลาและความพยายาม !!
แต่ในการทำงานนั้น จำเป็นต้องเขียน comment
เพื่อทำการอธิบาย codeว่าทำงานอย่างไร
ว่าใช้งานอ่างไรว่าแก้ไขหรือปรับปรุงอะไร
ในบทความจึงมีคำแนะนำต่าง ๆ ดังนี้
ข้อที่ 1 ไม่ต้องเขียน comment ซ้ำกับ code
[gist id="f236d5815683d63f9441e781fb695c16" file="1.java"]ข้อที่ 2 comment ที่ดี ไม่ใช่การอธิบาย code ที่ไม่ดีหรืออธิบายตัวเองไม่ได้
[gist id="f236d5815683d63f9441e781fb695c16" file="2.java"]ข้อที่ 3-5 ถ้าเขียน comment ไม่ชัดเจน คลุมเครือ นั่นหมายความว่า code ที่เขียนมักจะมีปัญหาเสมอ
comment ที่ดีต้องไม่ทำให้เกิดความสับสน
ข้อที่ 6 ถ้าทำการ copy code มาใช้งาน ควรมีที่มาเสมอ
ควรใส่ที่มาหรือ link ด้วยเสมอรวมทั้งข้อมูลอื่น ๆ เช่น
ข้อที่ 7 ต้องเขียน commnet เสมอเมื่อทำการแก้ไข bug ต่าง ๆ
[gist id="f236d5815683d63f9441e781fb695c16" file="7.java"]ข้อที่ 8 เขียน comment เพื่อระบุหรือบอกว่า ส่วนไหนยังพัฒนาไม่เสร็จหรือสมบูรณ์
[gist id="f236d5815683d63f9441e781fb695c16" file="8.java"]
น่าจะมีประโยชน์นะครับ
ขอให้สนุกกับการ coding
เพิ่งเห็นว่า go ได้ปล่อย Go 1.17 RC1 ออกมาแล้ว
ซึ่งเราสามารถ download มาทดลองใช้งานได้เลย
อยู่ในส่วนของ Unstable version นั่นเอง
มีอะไรเปลี่ยนแปลงบ้าง ไปอ่านกัน Draft :: Release Notes
ว่าง ๆ มาดูกันหน่อยว่าระบบ web application นั้น
ควรจะต้องมีการทำ performance testing บ้าง
ยกตัวอย่างเช่น การทำงาน load testing
เพื่อทำให้มั่นใจในระดับหนึ่งว่า
ระบบงานของเรานั้น น่าจะรองรับจำนวนผู้ใช้งานพร้อม ๆ กันเท่าไร
จะได้ไม่ตายกลางอากาศ !!!
โดยที่เครื่องมือก็มีเยอะให้เลือก ซึ่งเน้นไปที่ open source กัน
มาดูว่ามีอะไรบ้าง ?
วันนี้ทำ performance testing กันหรือยัง ?
ที่สำคัญคือ ทำตอนไหน ?
หรือ คนจริงไปวัดกันบน production เลย
หลังจากอ่านหนังสือเรื่อง Flow: The Psychology of Optimal Experience
มีหลายเรื่องที่น่าสนใจ เท่าที่พอจะเข้าใจ
ยกตัวอย่างเรื่องของ Flow State Killer
หรือสิ่งที่มาทำลาย Flow ของการทำงาน
โดยเฉพาะนักพัฒนา
โดยแยกออกได้ 3 กลุ่ม ดังนี้
กลุ่มที่ 1 Clarify killer
เรื่องของเป้าหมายงานไม่ชัดเจน คลุมเครือ
แผนงานคร่าว ๆ ทำ ๆ ไปก่อน แล้วเอามาดูกัน
รวมทั้งกรอบเวลาที่ไม่สัมพันธ์กับขอบเขตของงาน
กลุ่มที่ 2 Focus killer
งานเยอะเกินไป
มีแต่งานด่วน ด่วนมาก และด่วนที่สุด
สิ่งแวดล้อมในการทำงานไม่เอื้อต่อการทำงาน
หรืออาจจะมีสิ่งที่มาขัดจังหวะในการทำงานเยอะมาก ๆ
กลุ่มที่ 3 Energy killer
เกิดความเบื่อหน่ายทั้งเรื่องของงาน เรื่องของคน เรื่องขององค์กร
อีกทั้งมีสิ่งที่ก่อให้เกิดความกังวล หรือ วิตกกังวล
หรืออาจจะมีความใจร้อนมากจนเกินไป
แต่อาจจะเป็นผลมาจากกลุ่มที่ 1 และ 2 ก็ได้
ดังนั้นน่าจะต้องมีการปรับปรุงให้ดีขึ้นบ้างไหมนะ
ยกตัวอย่างเช่น ทำให้ชัดเจนมากยิ่งขึ้น
GitHub Copilot (Technical preview) เป็นระบบที่น่าสนใจมาก ๆ
เป็นระบบที่ใช้งาน OpenAI Codex Model ที่สร้างโดย OpenAI
โดยทำการเรียนรู้รูปแบบต่าง ๆ ของ code จาก GitHub ที่เป็น public repository
ซึ่งตอนนี้สนับสนุนภาษาต่าง ๆ ดังนี้
มีโครงสร้างดังรูป
จากการใช้งานโดยทั่วไปพบว่า
โดย GitHub Copilot นั้นไม่ใช่แค่การ suggestion หรือ autocomplete code เท่านั้น
แต่ยังวิเคราะห์ context ในตอนนั้น ๆ ด้วย
ทำให้สามารถแนะนำ code ให้ได้ตรงมากยิ่งขึ้น
อีกอย่าง ถ้า code ไหนมันเป็นแบบซ้ำ ๆ
ก็ยิ่งลดเวลาในการเขียน code ไปได้อย่างมาก
ในขณะที่เราเขียน code ไปนั้น
ทาง GitHub Copilot ก็จะแนะนำทางเลือกอื่น ๆ ให้อีกด้วย
ช่วยให้เราเห็นว่า มีวิธีการอื่น ๆ
จากนั้นเราสามารถคิด วิเคราะห์ และเลือกได้ว่า
จะใช้หรือไม่
ทำให้ GitHub Copilot ทำการเรียนรู้เราไปด้วย
ว่าเรานั้นมี style การเขียนแบบไหน
เพื่อจะแนะนำได้ตรงมากยิ่งขึ้น
สิ่งที่ชอบมาก ๆ คือ แนะนำ test library/dependency
ที่เหมาะสมกับ code นั้น ๆ ให้อีกด้วย
ช่วยลดงานไปได้เยอะมาก ๆ
แต่ต้องระวังด้วยว่า code ที่แนะนำหรือ auto suggestion/generate มานั้น
อาจจะไม่สามารถ compile หรือ run ไม่ผ่าน
ดังนั้นเราต้องดูและปรับปรุงหรือแก้ไขอีกด้วย
รวมทั้งอาจจะมี code ที่ใช้ library/dependency ที่ล้าสมัยก็เป็นได้
เพราะว่า code ที่นำมาเรียนรู้ มาจาก public repository
ที่ไม่สามารถควบคุมอะไรได้เลย
อีกเรื่องที่ต้องระวังคือ licence ของ code !!
สิ่งที่เราหรือนักพัฒนาต้องพึงระวังให้มากคือ
ควรต้องเรียนรู้จากคำแนะนำต่าง ๆ จาก GitHub Copilot
เพื่อปรับปรุงความสามารถของเราให้ดียิ่งขึ้น
มิเช่นนั้น มันจะเหมือนกับการไป copy code จาก stack overflow มาใช้งาน
ที่ทำงานได้ตามที่ต้องการ
แต่กลับไม่เข้าใจว่า code เหล่านั้นทำงานอย่างไร
สำหรับใครที่ใช้งาน Zoom ในการประชุมหรือคุยงานแบบ Remote
และใช้งาน Miro สำหรับการออกแบบ วางแผน
จะพบปัญหาว่า ต้องสลับหน้าจอไปมา
ซึ่งทำให้การทำงานไม่ราบรื่นมากนัก
จากปัญหานี้ ทาง Zoom และ Miro จึงร่วมมือกัน
ให้สามารถใช้งาน Miro ใน Zoom ได้เลย
"The Miro app for Zoom makes meetings more human"
โดยสามารถเพิ่ม Miro app เข้าไปใน Zoom ได้เลย
ดู demo การใช้งานที่ Miro app for Zoom
เมื่อระบบงานมีจำนวนการใช้งานที่สูงขึ้น (Work load) แล้ว
ปัญหาที่มักจะตามมาเช่น
มาดูกันว่า ต้นเหตุของปัญหามีอะไรบ้าง ?
0. เรื่องโครงสร้างและขั้นตอนขององค์กร !!
1. Code ที่แย่
คงปฏิเสธไม่ได้ว่า code ที่แย่ ๆ เป็นต้นเหตุสำคัญ
ซึ่งอาจจะทำงานได้ดีในระดับหนึ่ง
แต่เมื่อมีผู้ใช้งานถึงระดับหนึ่งแล้ว ปัญหาก็ต้องเห็นได้ชัดเจนยิ่งขึ้น
ทั้ง code/service ที่ผูกมัดกันสูง หรือ แยกกันมากเกินไป
ทั้งการใช้ algorithm ที่มี Big-O สูงเกินไป
2. การเลือกใช้เทคโนโลยีที่ไม่เหมาะสม ทั้งภาษาโปรแกรม และ Database
ยกตัวอย่างเช่นDatabase
บางอย่างเหมาะกับการอ่านข้อมูลDatabase
บางอย่างเหมาะกับการเขียนข้อมูลหรือต้องการ transaction
หรือ ความถูกต้องของข้อมูลสูงรวมทั้งการ scale ตามความต้องการ
3. ทำการเขียน business logic ไว้ใน Database
บางระบบทำการเขียน business logic ไว้ใน database
อาจจะด้วยเหตุผลใด ๆ ก็ตาม
ผลที่ตามมาคือ Database นั้นอาจจะ scale ไม่ทัน
ทำให้ยากต่อการรับมือเพราะว่า business logic ผูกติดกับ Database มากเกินไป
4. จัดการ caching ไม่ดี
ยกตัวอย่างเช่น การอ่านข้อมูลจาก Database ตรง ๆ ทุกครั้ง
เป็นเรื่องยากมาก ๆ สำหรับการ scale
ดังนั้นจึงต้องทำการ reuse connection database ด้วย Connection pool
หรือจำเป็นต้องทำการ caching data ที่ใช้งานบ่อย ๆ
เพื่อลดการเข้าถึง database ลงไป
หรือไปถึงพวก static data ต่าง ๆ
เพื่อทำ response time เร็วขึ้นหรือลด hop ของ request ลงไปให้มากที่สุด
5. การ configuration load balance ไม่ดี
บ่อยครั้งระบบงานตายเพราะว่า Load balance ไม่สามารถ scale หรือรองรับได้ทัน
6. รูปแบบการติดต่อสื่อสารระหว่าง service หรือ client-server
ไม่ว่าจะเป็น REST API หรือนำ GraphQL มาใช้
จนถึงการใช้งาน binary protocol เช่น Protocol buffer อย่าง GRPC
เพื่อเพิ่มประสิทธิภาพของการติดต่อสื่อสาร
หรือลดการใช้งาน bandwidth ของ network ลงไป
รวมทั้งการเลือกใช้รูปแบบการติดต่อสื่อสารให้เหมาะสมทั้ง Sync และ Async
แต่เหนือสิ่งอื่นใด ควรจะมีระบบหรือเครื่องมือช่วยตรวจสอบปัญหา
เพื่อให้เราสามารถรู้หรือเข้าไปยังปัญหาได้อย่างรวดเร็วเพื่อแก้ไขได้ทันที
รวมทั้งควรมีระบบการทำ performance test ที่ดีอีกด้วย
อีกทั้งความรู้ของคน ทีม และ องค์กร ก็เช่นกัน
Reference Websites
https://blog.devgenius.io/7-bottlenecks-that-hurt-the-scalability-of-your-system-4aa8b75627bf
อ่าน research paper ของ Microsoft
เรื่อง RESTler: Stateful REST API Fuzzing
เป็นเครื่องมือสำหรับการทดสอบ REST API
แบบ Fuzz testing หรือ Fuzzing
คือรูปแบบหนึ่งของการทดสอบแบบ blackbox
โดยจะพยายามหา bug หรือ ข้อผิดพลาดจาก input ในรูปแบบต่าง ๆ อย่างอัตโนมัติ
โดยที่ Fuzzing จะมีอยู่ 3 รูปแบบ
ทำไมต้องใช้ Fuzzing ด้วย เพื่อทดสอบ
สำหรับ Paper นี้จะทำการทดสอบ REST API
โดยทำการสร้างเครื่องมือชื่อว่า RESTler มาให้ใช้งาน
พัฒนาด้วยภาษา Python 3.8.2 และ .NET 5
หรือจะใช้งานผ่าน Docker ก็ได้
การทำงานของ RESTler จะทำการวิเคราะห์จาก Open API Specification หรือ Swagger นั่นเอง
เพื่อทำการสร้างรูปแบบของ input
จากนั้นทำการส่ง input นั้น ๆ ไปยัง API
รวมทั้งยังทำการเรียนรู้จาก response ที่ได้มาจาก input ก่อนหน้า
ทำให้เป็นเครื่องมือที่เรียกว่า Stateful นั่นเอง
แสดงดังรูป
ลองดูจาก Demo project ได้เลย
เริ่มด้วย start api server ก่อน
จากนั้นทำการ run RESTler ใน command line
แต่ระวังด้วยนะครับ เพราะว่า server อาจจะล่มได้เลย
เนื่องจากยิง request มาเยอะมาก ๆ
Reference Websites
https://owasp.org/www-project-web-security-testing-guide/v41/6-Appendix/C-Fuzz_Vectors
เขียนรูปนี้ใน feed facebook แล้ว
ทำให้คิดถึงปัญหาอย่างหนึ่งในการพัฒนา software
นั่นก็คือ ค่าใช้จ่ายสำหรับการแก้ไขข้อผิดพลาด
ยิ่งข้อผิดพลาดเกิดบน production server แล้ว
ยิ่งมีค่าใช้จ่ายในการแก้ไขสูงขึ้นอย่างมาก
เนื่องจากไม่ใช่เพียงแก้ไขให้ทำงานถูกต้อง
แต่ยังมีค่าใช้จ่ายอื่น ๆ ที่อาจจะกระทบต่อธุรกิจ
หรือกระทบต่อผู้ใช้งานไม่มากก็น้อย
และจะพบว่า ค่าใช้จ่ายก็จะสูงเป็นทวีคูณ
ประเด็นที่น่าสนใจคือ ทำไมถึงเกิดข้อผิดพลาดใหญ่ ๆ บน production server ?
ทั้ง ๆ ที่แต่ละที่มีกระบวนการทำงานที่รัดกุม
มีการตรวจสอบที่หลากหลาย หลายขั้นตอน
มีการ approve ต่าง ๆ มากมาย
มี environment ในการพัฒนา และ ทดสอบมากมาย
หรือว่า สิ่งที่เราทำกันนั้นมันไม่ถูกต้อง ?
ซึ่งตรงนี้น่าคิดมาก ๆ
จะดีกว่าไหม ถ้าเราสามารถป้องกัน หรือ ค้นหาความผิดพลาดต่าง ๆ เหล่านั้น
ได้บ่อยและรวดเร็ว ก่อนที่จะนำขึ้น production server
นั่นคือ การปรับปรุง workflow การทำงานให้มีประสิทธิภาพมากยิ่งขึ้น
ให้เป็นการทำงานที่รวดเร็วมากขึ้น
โดยที่ลด effort ลงไปให้มากขึ้น
หรืออาจจะปรับปรุงจากความผิดพลาดที่ผ่านมา
นั่นหมายความว่า เราต้องไม่พลาดซ้ำที่เดิมนั่นเอง
ว่าแต่เราได้เรียนรู้อะไรบ้าง ?
วันนี้ทำการแก้ไข code ที่พัฒนาด้วยภาษา Dart
ก็ไปเจอรูปแบบการจัดการ exception/error หลายรูปแบบ
ที่ทำงานกับ async function
จึงลองทำการสรุปไว้นิดหน่อย
พื้นฐานเล็กน้อยสำหรับ Dart
โดยที่ Dart จะแยก Error กับ Exception ออกจากกัน
Error นั้นจะใช้สำหรับปัญหาในระดับ system เช่น memory error เป็นต้น
แน่นอนว่าเราไม่สามารถคาดเดาได้เลย
ส่วน Exception นั้นใช้สำหรับระดับ application
เพิ่มเติมคือ รายละเอียดของปัญหาต่าง ๆ มาด้วย
ซึ่งทำให้สามารถดักจับได้ง่าย
รวมทั้งแก้ไขได้ง่ายขึ้น
แน่นอนว่าเรารู้ว่า น่าจะมีปัญหาอะไรเกิดขึ้นมาบ้าง
โดยการใช้งานทั้งคู่ ควรที่จะสร้าง custom error/exception ขึ้นมาใช้
จะดีกว่าการใช้งานตรง ๆ ไปเลย
รูปแบบที่น่าสนใจประกอบไปด้วย
มาดูตัวอย่าง code ในแต่ละรูปแบบกัน
แบบที่ 1 try-catch-finally ปกติ + async-await
[gist id="07e05a7ed212eee368d352906a1b95a3" file="1.dart"]แบบที่ 2 catchError()
[gist id="07e05a7ed212eee368d352906a1b95a3" file="2.dart"]แบบที่ 3 onError ในการเรียกพวก async generator
[gist id="07e05a7ed212eee368d352906a1b95a3" file="3.dart"]แบบที่ 4 ใช้งาน Zone class มาช่วย
[gist id="07e05a7ed212eee368d352906a1b95a3" file="4.dart"]ปล. Exception ทุกอย่างของ Dart นั้นจะเป็น unchecked exception ทั้งหมด
ดูเพิ่มเติมได้ที่
เห็นใน Dart community และใน GitHub issue ของ Dart
มีการพูดถึงการทำงานร่วมกันระหว่าง Dart กับ WebAssembly
ซึ่งดูแล้วมีความเป็นไปได้ และน่าจะให้คลอดออกมา
เนื่องจากตอนนี้อยู่ในขั้นตอนของการทดลอง (ยังไม่ official)
หลังจากที่ติดตามมาได้นิดหน่อย
พบว่ามีแนวทาง 2 แนวทางคือ
ซึ่งทั้งสองแนวทาง ก็มี implementation ออกมาให้ลองใช้งาน
ทั้ง Dart to Wasm Prototype
และ package wasm ที่ให้เรียกใช้งาน Wasm จาก Dart ได้เลย
เป็นอีกแนวทางหนึ่งของการพัฒนา web application ที่น่าสนใจ
โดยการแปลงจากภาษาต่าง ๆ ไปยัง Wasm
ก็มี implementation หนึ่งคือ Wasmer
วันนี้อ่านหนังสือเจอแนวปฏิบัติในการเขียน program
ที่ใช้ชื่อว่า Voodoo programming
เนื่องจากไม่เคยได้ยินมาเลย
ดังนั้นลองไปหาข้อมูลกันหน่อยว่าคืออะไร เป็นอย่างไร
จาก Wikipedia
เป็นแนวทางในการเขียน program อย่างหนึ่ง
โดยใช้หลักการ trail and error
แทนที่จะทำจากความเข้าใจ แต่กลับทำจากการเดา
รวมทั้งไม่เข้าใจจริง ๆ ว่าสิ่งที่กำลังทำหรือปัญหาที่กำลังแก้ไข คืออะไรกันแน่
เทียบได้กับการทำด้วยวิธี brute force
แนวทางที่ใช้งาน Voodoo programming มักจะมีรูปแบบดังนี้
ว่าแต่เราทำกันไหมนะ ?
มันดีไหมนะ ?
ทาง JetBrains ได้ออกผลการสำรวจ
เรื่อง The State of Developer Ecosystem 2021
โดยสำรวจนักพัฒนามากกว่า 30,000 คน จาก 183 ประเทศทั่วโลก
ประมาณ 71% เป็น backend developer
เพื่อสำรวจว่านักพัฒนาทำอะไรกันบ้าง
มาดูผลที่น่าสนใจว่ามีอะไรกันบ้าง
JavaScript คือภาษา program ที่ใช้งานมากที่สุด
Python มีความนิยมกว่า Java (52% vs 49%)
แต่ถ้าภาษาหลักในการพัฒนา จะเรียงจาก JavaScript, Java และ Python ตามลำดับ
และยังมีภาษาที่ใช้การสูงขึ้น ดังนี้
ในการทำงานก็เป็นแบบ Remote และ Work From Home ตามสถานการณ์ปัจจุบัน
โดยใช้งาน Zoom, Ms Team และ Google Meet ตามลำดับ
เวลาว่าง นักพัฒนาเล่นเกมส์เยอะสุด
รองลงมาคือ เขียน program, ฟังเพลง และ อ่านหนังสือ
มีเล่นกีฬา 31% เท่านั้นเอง
สิ่งที่น่าสนใจคือ กว่า 74% ใช้โปรแกรมในการ block พวกโฆษณาจาก website ต่าง ๆ
รวมใช้งาน Editor ใน Dark theme ถึง 84%
และมากกว่า 80% กินขนมระหว่างที่ coding (จะอ้วนไหมนะ)
35% ของนักพัฒนา ทำการพัฒนาระบบตามแนวคิด Microservices
ซึ่งใช้ภาษา Java, JavaScript และ Python ตามลำดับ
จากรายงาน ทาง Jetbrain คิดว่าน่าจะมีเยอะกว่านี้ !!
แต่เมื่อไปดูในเรื่องของการออกแบบระบบแล้ว
ส่วนการติดต่อสื่อสารระหว่าง service
ยังคงเป็น REST จำนวนมาก
แต่ก็มี messaging ตามมาที่ 47%
และมี Websocket และ RPC ตามมาห่าง ๆ
ในการพัฒนา API นั้นมี 44% ที่บอกว่า Specification first
ส่วน code first มีจำนวน 16% เท่านั้น
ส่วนพวก Database ยังคงเป็น RDBMS เป็นหลัก
ทั้ง MySQL, PostgreSQL, SQLite และ MariaDB
แต่ก็มี NoSQL มาด้วยเช่นกัน ทั้ง Redis, MongoDB เป็นต้น
และที่น่าสนใจคือ มากกว่า 50% บอกว่า
เก็บ Database script ไว้ใน Version Control System
ในสาย DevOps Tool นั้น เรื่องของ Container ยังคงเป็นตัวหลัก
การทำงานเป็นทีม ใช้เครื่องมืออะไรกันบ้าง
มีอีกหลายเรื่องที่น่าสนใจ ลองอ่านเพิ่มเติมได้ครับ
ไปเจอ code สำหรับการสร้าง Date หรือวันที่ใน project หนึ่ง
พออ่านแล้วก็รู้สึกแปลก ๆ ว่าใน Utility class
ทำไมมี method createDate() ให้ใช้งานด้วย
แถมจริงจังด้วย
ไม่พอ เป็นการ copy มาจาก project ก่อนหน้านี้
และคิดว่า คง copy กันมาต่อเนื่องมาก ๆ
เนื่องจากใน code ต้นทางมีเขียน comment ตัวอย่างใช้งาน เป็นปี 20xx ด้วย
ตัวอย่างของ code ส่วนหนึ่งเป็นดังนี้
[gist id="b82148828ce700a00dc4ebfff8322d0a" file="1.java"]ว่าแต่เขียนสั้น ๆ ด้วย LocaDate ก็จบแล้วดังนี้
[code]LocalDate.of( 2021 , 7, 31 );[/code]
ในระบบงานมักจะมีการติดต่อสื่อสารระหว่างระบบหรือ service
ผ่านระบบ network ที่ขึ้นชื่อว่า พร้อมพัง ได้เสมอ
ดังนั้นในการออกแบบ พัฒนา และ ทดสอบระบบ
ต้องทำให้มั่นใจว่าการติดต่อสื่อสารจะต้องทำงานตามที่เราต้องการเสมอ
ทั้งการทำงานให้เสร็จ
ทั้งการทำงานอย่างไรเมื่อเกิดปัญหาขึ้นมา
เพื่อให้ระบบงานมีความน่าเชื่อถือมากยิ่งขึ้น
โดยรูปแบบยอดนิยมของการจัดการ มีดังนี้
แบบที่ 1 Timeout
เป็นรูปแบบที่ถูกใช้งานมากที่สุด
เพราะว่า service หรือ ระบบปลายทาง อาจจะเกิดปัญหาขึ้นมา
ส่งผลให้ตอบกลับได้ช้ากว่าปกติ
ดังนั้นเพื่อป้องกันการทำงานที่นาน หรือใช้ resource มากจนเกินไป
จึงทำการกำหนด timeout ของการใช้งานไว้
เมื่อถึง timeout ก็จะตัดการเชื่อมต่อ หรือ คืน resource ให้ระบบกลับไป
ยกตัวอย่างการใช้งาน Database connection pool
หรืออาจจะเป็น network connection
ดังนั้นทางผู้เรียกใช้งานจะได้ระบบผลกลับมาว่า Connection timeout
จากนั้นก็ต้องจัดการว่าจะทำอย่างไรต่อไป
คำถามที่น่าสนใจคือ
ระบบปลายทางยังมีปัญหาแล้ว request อื่น ๆ ยังจะเรียกอีกหรือ ?
แบบที่ 2 Retry
เป็นอีกรูปแบบที่ถูกใช้งาน เพื่อแก้ไขปัญหาที่เกิดจากความผิดพลาด
อาจจะไม่เรียกว่าเป็นการแก้ไขปัญหา
แต่เป็นวิธีการที่จะทำต่อ หลังจากการทำงานมีปัญหา
ยกตัวอย่างเช่น เกิด timeout หรือ ระบบล่ม ขึ้นมา
ดังนั้นทางฝั่งคนเรียกใช้ ก็ต้องจัดการต่อไป
การ retry คือการทำซ้ำไปเรื่อย ๆ ตามจำนวนครั้ง และ interval ที่กำหนด
ทำไปจนกว่าจะทำงานสำเร็จ !!
มักจะเจอบ่อยกับงานที่เป็น batch job
หรือเป็นพวกระบบ messaging นั่นเอง
คำถามที่น่าสนใจคือ
ระบบปลายทางยังมีปัญหายังจะ retry อีกหรือ ?
หรื retry กันตอนไหน ?
แบบที่ 3 Circuit breaker
เป็นอีกวิธีที่ได้รับความนิยมในปัจจุบัน
แต่หลาย ๆ คนไม่รู้จัก ไม่เข้าใจส่งผลให้ไม่ได้ใช้งานกัน
โดยใช้หลักการเหมือนการตัดไฟเมื่อเกิดการช๊อตขึ้นมา
ถ้าเทียบกับระบบคือ
ผู้เรียกใช้งานจะไม่เรียก service หรือ ระบบปลายทาง
เมื่อมีปัญหาตามรูปแบบที่ตกลงร่วมกันไว้ยกตัวอย่างเช่น
โดยทางผู้เรียกใช้งานจะรู้ทันทีว่าปลายทางมีปัญหา
ทำให้สามารถจัดการได้ว่า
เมื่อมี request เข้ามาหลังจากนี้จะจัดการอย่างไร
วิธีการที่ได้รับความนิยมคือ fail fast
นั่นคือ ส่งผลการทำงานที่ fail กลับไปทันที
ไม่ต้องส่ง request ไปยังปลายทาง
เป็นการลดภาระไปในตัว
พร้อมทั้งช่วยให้ service ปลายทาง สามารถ recovery กลับมาได้ง่ายขึ้น
หรืออาจจะใช้วิธีการอื่น ๆ นอกเหนือจาก fail fast เช่น
แบบที่ 4 Bulkhead
เป็นหลักการที่ใช้สำหรับป้องกันปัญหาที่เกิดจากระบบหนึ่งทำงานผิดพลาด
แล้วอาจจะส่งผลให้ทั้งระบบพังได้
จึงมักจะทำแผนสำรองไว้
ยกตัวอย่างเช่น Active-stand by หรือเป็น Muti-data center เป็นต้น
เมื่อเกิดปัญหาขึ้นมาที่หนึ่ง แล้วจะทำการเปลี่ยนไปใช้อีกที่โดยอัตโนมัติ
อย่าลือซ้อมบ่อย ๆ ละ !!
ยังมีแนวทางอื่น ๆ ช่วยจัดการปัญหาที่เกิดขึ้นอีก
ยกตัวอย่างเช่น Feature toggle
ทำการเปิดหรือปิด feature ของระบบได้ทันที
เพื่อลดความผิดพลาดและปัญหาอื่น ๆ ที่จะตามมา
วิธีการต่าง ๆ ไม่ได้ทำให้ความผิดพลาดหายไป
แต่เป็นการลดผลที่เกิดจากความผิดพลาด
ไม่ให้มันกระทบไปทั้งระบบ
ไม่ให้กระทบกับผู้ใช้งานโดยรวม
ความผิดพลาดเกิดขึ้นได้
แต่เราต้องเรียนรู้ที่จะปรับปรุงและจัดการมันเช่นกัน
ปัญหาการ scale Redis บน Google Cloud Memorystore for Redis
เนื่องจาก Redis ทำงานแบบ Single thread
ทำให้ถ้ามีการทำงานที่ช้า ๆ อาจจะส่งผลต่อการทำงานอื่น ๆ ได้
แต่ละ scale ด้วยการขยายเครื่อง ก็ไม่การันตีว่าจะดีขึ้น
หนึ่งในคำแนะนำคือ การใช้งาน Proxy มาช่วย
โดยตัวที่น่าสนใจคือ Twemproxy
ซึ่งพัฒนาจาก Twitter
ดังนั้นจึงมาลองทำความรู้จักกันหน่อย
การทำงานแสดงดังรูป
เป้าหมายของ Twemproxy
ไว้ลองใช้งานดูหน่อย
สายนักวิ่ง นักปั่น หรือ นักกีฬา น่าจะรู้จักและใช้งาน Strava
ซึ่งแต่ละคนสามารถ update activity ต่าง ๆ
รวมทั้งสร้างหรือร่วม Club ต่าง ๆ
เพื่อบันทึก แข่งขัน หรือ ดูสถิติต่าง ๆ
หนึ่งใน feature หลักของ club คือ Leaderboard
ทำการสรุปการ scale ระบบ Leaderboardให้รองรับจำนวนการใช้งานที่สูงขึ้น
รวมทั้งจำนวนผู้ใช้งานในแต่ละ club ที่สูงมาก ๆ
จำนวนสมาชิกต่อ club ที่สูงสุดคือ 2 ล้านคน !!
มาดูกันว่า Strava ทำอย่างไร ?
เริ่มต้นในการพัฒนานั้น ทีม Strava มองว่า
จำนวนสมาชิกใน club ไม่น่าเยอะอาจจะเป็นกลุ่มเล็ก ๆ เท่านั้นเอง
แต่เมื่อเวลาผ่านมาเรื่อย ๆ จำนวนสมาชิกแต่ละ club สูงขึ้นเยอะมาก
ทำให้ระบบมีปัญหาด้าน performance
การพัฒนาจะใช้ Ruby on Rail (RoR) + Active Record
สำหรับการดึงข้อมูลจาก database มาประมวลผลใน Leaderboard
จะทำการดึงข้อมูล activity ในแต่ละชนิดของแต่ละคน
จากนั้นนำมาสรุป และจัดเรียงข้อมูลจากมากไปน้อย
มีการจัดทำ index ต่าง ๆ เรียบร้อย
แต่ก็ยังรองรับจำนวนผู้ใช้งานไม่เยอะ
ดังนั้นจึงทำ caching data โดยมีการ update ข้อมูลทุก ๆ 6 ชั่วโมง
ซึ่งทำให้ระบบรองรับได้มากขึ้นแต่ข้อมูลไม่ realtime
ทำให้ user experience ไม่ดีเลย
รวมทั้ง caching data ไม่ใช่การแก้ไขที่ต้นเหตุ !!
ยิ่งเจอ club ที่มีสมาชิกเป็นล้านคนการ query ข้อมูลมาใหม่
ต้องใช้เวลามากถึง 20 นาที !!
ผลที่ตามมาคือ เจอ error 500 เยอะและบ่อยมาก ๆ
จึงน่าจะได้เวลาแก้ไขที่ต้นเหตุกันได้แล้ว
การแก้ไขปัญหา คือ การเขียนส่วน backend ใหม่
วิธีคิดคือ
เมื่อผู้ใช้งานทำการ upload ข้อมูล activity ใหม่เข้ามายังระบบ
จะทำการ update ข้อมูลใน leaderboard ของแต่ละ club ทันที
แต่ไม่ต้องการให้ rebuid data ใหม่
ดังนั้นจึงทำการเก็บข้อมูลของ leaderboard ไว้ใน Redis แทน database หลัก
ด้วยการใช้ data structure ที่เหมาะสมคือ Sorted Set
นั่นคือ ข้อมูลจะไม่ซ้ำ และจะเรียงจากมากไปน้อยให้ทันที
ส่วนข้อมูลรายละเอียดต่าง ๆ จะเก็บข้อมูลในรูปแบบ Hash
การ Rollout ระบบใหม่ จะทำแบบค่อยเป็นค่อยไป
โดยออกแบบให้ระบบสามารถเปลี่ยนมาใช้งาน feature ใหม่รายคนได้
มีขั้นตอนดังนี้
แสดงดังรูป
ผลการทำงานจากระบบใหม่ ดีขึ้น
เป็นข้อมูลที่น่าสนใจ
ซึ่งเราสามารถนำมาเรียนรู้ ศึกษา และนำไปใช้งานได้
