หัวข้อที่ 1 What new in Elastic 8.6

ว่าด้วยเรื่องของวิวัฒนาการของ Elastic ว่าเป็นอย่างไรบ้าง
ซึ่งเริ่มจากระบบการค้นหา
ตามมาด้วย analytic
จากนั้นเริ่มเข้าสู่ APM, logging, tracing, metric หรือ Observability นั่นเอง
และเข้าสู่เรื่องของ security, ทางการแพทย์
นั่นคือ การเข้าสู่ Data Intelligence Platform นั่นเอง

แต่ปัญหาที่ตามมาคือ เรื่องของ ค่าใช้จ่ายที่สูงขึ้น
ทั้งการประมวลผล และ ที่จัดเก็บข้อมูลที่สูงขึ้น
ยิ่งต้องทำการ scale และ replicate data (redundant data)
ยิ่งสูงขึ้นเรื่อย ๆ

ดังนั้นเรื่องของ Data tier กับ ILM (Index Life cycle Management)
เช่น Hot, Warm และ Cold data เป็นต้น
ช่วยให้เก็บข้อมูลตามการใช้งานได้

ปัญหาอีกเรื่องที่ต้องการจัดการคือ Ingest data

ซึ่งใช้งาน resource สูงมากทั้ง CPU และ storage
จะ share CPU ทั้ง search และ ingest ด้วยกันก็เปลืองมาก ๆ

โดยนี้กำลังจัดการเป็น early ingest management
หรือเปลี่ยนจาก stateful เป็น stateless
ซึ่งใช้ CPU น้อยลงอย่างมาก
น่าสนใจมาก ๆ ตามรูปนี้

ไว้เจอกันรอบหน้าครับ

จากบทความเรื่องการ scale ระบบของ Levels.fyi
พบว่าน่าสนใจมาก ๆ สำหรับการเริ่มต้นทำ product
เริ่มแบบเรียบง่ายเพื่อ validate ว่า product จะไปได้ไหม
จากนั้นค่อย ๆ optimize หรือปรับเปลี่ยนไปตามความต้องการ
หรือตาม business และคนใช้งานที่สูงขึ้น
ดังนั้นจึงสรุปสิ่งที่น่าสนใจไว้นิดหน่อย

สิ่งที่ได้ใจมาก ๆ คือ เริ่มด้วยการเน้นไปที่การสร้าง product

ว่าสิ่งที่คิด มันจะ work หรือมีผู้ใช้งานหรือไม่
เพราะว่า แนวคิดที่คิดหรือทำมานั้น อาจจะเป็นเพียงสิ่งที่เราต้องการเองเท่านั้น !!
ดังนั้นการลงทุนสร้างระบบจึงเรียบง่ายมาก ๆ
คือเริ่มจาก Google Forms และ Google Sheets เท่านั้น (No Code ชัด ๆ)
ไม่ต้องมาเสียเงินพัฒนา และดูแลหลังบ้านอะไร

• Frontend = Google Forms
• Database = Google Sheets

ตรงนี้เรียกว่า version 0

ต่อมาเพิ่มส่วนของ User Interface เข้ามา เพราะว่าข้อมูลเริ่มซับซ้อนขึ้น

เช่นข้อมูลเงินเดือน
จากนั้นก็เพิ่ม API gateway และ AWS Lambda (serverless) เข้ามา
เพื่อทำการตรวจสอบข้อมูล และ บันทึกข้อมูลไปยัง Google Sheets ต่อไป
ส่วนนี้เรียกว่า version 1

แต่การดึงข้อมูลจาก Google Sheets จะยากและประสิทธิภาพไม่ดี
จึงทำการสร้างข้อมูลเป็นไฟล์ JSON ขึ้นมา
จากนั้นทำการเก็บไฟล์ไว้ใน Amazon S3
เป็นการจัดเก็บแบบ upsert คือ
ถ้าไม่มีก็ insert หรือสร้างใหม่ ถ้ามีก็ทำการ update นั่นเอง
และการใช้งานจาก web browser ก็เข้าถึงข้อมูลผ่าน CDN
ด้วยข้อมูลในไฟล์ JSON จะมีขนาดใหญ่
ดังนั้นก็ทำ caching ไว้ใน web browser อีกด้วย

โครงสร้างนี้ทำงานได้ดีมาเรื่อย ๆ ( 24 เดือนหรือ 2 ปี)

แต่เมื่อมีผู้ใช้งานสูงขึ้น ก็เจอปัญหาเหล่านี้

• ขนาดของไฟล์ JSON มีขนาดใหญ่ขึ้น จาก KB มาเป็น MB ดังนั้นเมื่อผู้ใช้งานใหม่ เข้ามาพร้อม ๆ กัน ทำให้ loading time เยอะมาก ๆ
• AWS Lambda ทำการช้า จน timeout กันไปเลย
• ขาดวิธีการนำ data มาวิเคราะห์ เพื่อใช้ในการตัดสินใจ ซึ่งเป็นปัญหาที่ใหญขึ้น
• Google Sheets API มาถึง rate limit ของมัน สำหรับการเขียนข้อมูล
• ง่ายดูการ scrape ข้อมูลมาก ๆ เพราะว่า return เป็น JSON กลับมายัง web browser

ดังนั้นจึงได้เวลาของการปรับเปลี่ยนครั้งใหญ่ของ Architecute ระบบ

โดยในฝั่ง backend ได้นำ database มาใช้เก็บข้อมูลแทน Google Sheets
เป็นแนวทางที่ขับเคลื่อนด้วยปัญหาที่พบ

รวมทั้งทำการแบ่งข้อมูลที่อยู่ในไฟล์ JSON เป็นไฟล์เล็ก ๆ

โดยทำการสร้าง API ใหม่ขึ้นมาเพื่อให้ทาง frontend เรียกใช้งาน
ทำแบบค่อยเป็นค่อยไป จนย้ายทุกส่วนมายัง API ใหม่
ฝั่งของ API server พัฒนาด้วย Node.js ทำงานบนเครื่องเดียว
สามารถรองรับผู้ใช้งาน 60K request ต่อชั่วโมง

จะเห็นได้ว่าการออกแบบระบบนั้น เป็นไปแบบธรรมชาติ

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

จากนั้นก็ค่อย ๆ ปรับปรุง ปรับเปลี่ยน ให้เหมาะสมต่อไป
ช่วยลดความเสี่ยงในเรื่องต่าง ๆ ลงไปได้เยอะ
มันคือ Evolution Architecture นั่นเอง

จากบทความเรื่อง Law of Demeter (LoD) ในการเขียน code นั้น
เพื่อช่วยลด coupling ระหว่าง class
หรือเป็นแนวคิดที่ช่วยให้เรามีความรู้เกี่ยวกับปลายทางที่จะเรียกให้น้อยลง
ทำให้มีอิสระมากยิ่งขึ้น

โดยถ้าเรานำแนวคิดนี้ มาใช้กับการแยก service ด้วย
ก็น่าจะได้ผลดีเช่นกันนะ

ยกตัวอย่างเช่น

เรื่องแรก แต่ละ service ควรมีข้อมูลที่จะใช้เป็นของตัวเอง

ไม่ให้ใครมาใช้งานตรง ๆ
หรือไม่ไปดึงข้อมูลจาก service มาใช้งานทุกครั้ง
มองเป็นเรื่องของ local data ให้มากขึ้น
ก็น่าจะช่วยเพิ่มความรวดเร็วในการทำงาน
และเป็นอิสระจาก service อื่น ๆ มากขึ้น
ทำให้ scale และ deploy ง่ายขึ้นอีก

เรื่องที่สอง ถ้าแต่ละ service ต้องใช้ข้อมูลจาก service อื่น ๆ ก็ควรมี interface ให้ใช้งาน

ไม่ว่างจะเป็น REST API, gRPC, messsaging หรือ protocol อื่น ๆ
เพื่อซ่อนการทำงานหรือข้อมูลภายในไว้
จะช่วยให้ระหว่าง consumer และ provider เป็นอิสระแก่กัน
แต่ก็ต้องระวังเรื่องการเปลี่ยนแปลงรูปแบบข้อมูลที่ตกลงกันไว้
ดังนั้นเรื่อง compatability ก็สำคัญมาก ๆ

หรืออาจจะต้องเรื่องของ validate schema ข้อข้อมูลเอาไว้ด้วย

เรื่องที่สาม แต่ละ service จะติดต่อกัน ก็ไม่ควรเรียกกันตรง ๆ

ดังนั้นเพื่อลดการผูกมัด ควรใช้งาน service discovery/registry เข้ามาช่วย
ทำให้เรียกใช้งานผ่านชื่อ ส่วนที่อยู่จริง ๆ สามารถเปลี่ยนได้ง่าย
โดยไม่กกระทบต่อผู้ใช้งาน

หรือถ้าต้องการลดข้อผู้มัดไปอีก ก็ไปทาง event-based ไปเลย
โดยฝั่ง provider ก็ไม่รู้ด้วยว่าฝั่ง consumer มีใครบ้าง
ยิ่งทำให้เป็นอิสระต่อกันมากยิ่งขึ้น
แต่ก็ตามมาด้วยระบบ observability ที่ดีด้วย
มีได้ก็ต้องมีเสีย

จะเห็นได้ว่า เราเน้นไปที่ความเป็นอิสระต่อกัน

เพื่อให้พัฒนา ทดสอบ deploy scale และ maintain ได้ง่าย
รวมไปถึงเรื่อง resielince ของระบบด้วย
แต่ไม่ใช่จะแยก service เสมอไปนะ
ต้องดูการทำงานใช้งานด้วยว่า เป็นแบบใด
แยกมาก ๆ อาจจะแย่ก็ได้ ตรงนี้ต้องระมัดระวัง

หรือแทนที่จะเรียกต่อกันยาว ๆ
อาจจะใช้แนวคิด composition ก็ได้
มีหลายแนวทางที่น่าสนใจ

ปัญหาที่พบเจอเกี่ยวกับ mvnw (Apache Maven Wrapper) ของ Spring Boot
กับ Docker ใน windows

โดยปัญหาที่เจอคือ เมื่อเราทำการ copy สิ่งต่าง ๆ เข้าไปยัง Docker
ผ่านการกำหนดใน Dockerfile เลยเกิดปัญหา ./mvnw not found

โดยที่ Dockerfile เป็นดังนี้

เท่าที่ไปดูปัญหาหลัก ๆ มี 2 เรื่องคือ

• อย่างแรกเรื่อง permission ของไฟล์ mvnw ที่ไม่สามารถ execute ได้ ก็ chmod +x เข้าไปได้
• อย่างที่ 2 เป็นเรื่องของ end of line ของ Windows กับ Linux ที่ต่างกันคือ \r\n หรือ CRLF (Carriage Return and Line Feed) ดังนั้นกเปลี่ยนเป็น LF ได้เลย

โดยแก้ไขปัญหาเฉพาะหน้าแบบนี้ไป

ปกติจะใช้งาน OctoTree เป็นประจำ สำหรับดู code ใน GitHub แบบ tree
แต่เพิ่งรู้ว่าใน GitHub มีความสามารถเดียวกัน
โดยสามารถไปเปิดใช้งานในส่วนของ Preview Feature
ซึ่งอยู่ในส่วนของ user setting ดังรูป

จากนั้นทำการ enable ได้เลย ดังรูป

เพียงเท่านี้ก็สามารถใช้งานได้แล้ว
โดยเข้าไปที่ menu Go to file ใน repository ของเรานั่นเอง
ชีวิตง่ายขึ้นเยอะ

วันนี้ต้อง share หน้าจอของ app ใน Android phone นิดหน่อย
ไหน ๆ ก็ใช้งาน Android Studio อยู่แล้ว
ก่อนหน้านี้ใช้งาน scrcpy ไป
แต่ไม่อยากติดตั้งอะไรเพิ่ม เลยแนะนำให้ใช้งาน Device mirroring
ซึ่งเป็น preview feature นั่นเอง

การเปิดใช้งานก็ไม่ยาก
ไปเปิดที่ Settings/Preferences -> Tools -> Experiment

จากนั้นก็ใช้งานใน tab Running devices ได้เลย

มาแล้วนะสำหรับ OWASP Kubernetes Top 10
โดยทำการสรุปความเสี่ยงที่อาจจะเกิดขึ้นทั้งจาก application และ infrastructure
ที่ทำการ deploy บน Kubernetes cluster
ซึ่งจะเป็นแนวทางช่วยเหลือสำหรับ security, system admin และ developer อีกด้วย
มีความเสี่ยง 10 ข้อที่แนะนำมา ดังนี้
ลองดูรายละเอียดกันนะครับ น่าจะมีประโยชน์

• K01: Insecure Workload Configurations
• K02: Supply Chain Vulnerabilities
• K03: Overly Permissive RBAC Configurations
• K04: Lack of Centralized Policy Enforcement
• K05: Inadequate Logging and Monitoring
• K06: Broken Authentication Mechanisms
• K07: Missing Network Segmentation Controls
• K08: Secrets Management Failures
• K09: Misconfigured Cluster Components
• K10: Outdated and Vulnerable Kubernetes Components

แสดงเป้าหมายของแต่ละข้อด้วยภาพดังนี้

เท่าที่ดูคร่าว ๆ จะแบ่งออกเป็น 3 กลุ่มใหญ่ ๆ คือ

• Misconfiguration หรือ configuration ไม่ถูกต้อง คือ 1, 3, 7 และ 9
• ปัญหาเรื่อง visibility ของระบบ เช่น logging, monitoring, การจัดการ policy และ secret management คือ 4, 5 และ 8
• การจัดการเรื่องการโจมตีในรูปแบบต่าง ๆ ที่ยังไม่ดี เช่น authentication และการ update component ต่าง ๆ คือ 2, 6 และ 10

ดูเพิ่มเติมได้ที่ GitHub :: Kubernetes Top 10

อ่านบทความเรื่อง Docker is deleting Open Source organisations - what you need to know
ซึ่งทาง Docker ได้ส่ง email ถึง Docker Hub user ทุกคน
ที่สร้างหรือใช้งาน organisation
ว่าจะถูกลบ account และ image ทั้งหมด
ถ้าไม่ทำการ upgrade plan ไปใช้ paid plan

ปล. ถ้าใช้แบบ personal จะไม่มีผลกระทบอะไร
แต่ถ้าใครสร้าง organisation ขึ้นมาจะโดนหมด
และส่วนใหญ่ที่ได้รับผลกระทบมาก ๆ คือ Open source community

โดยผลกระทบหลัก ๆ คือ พวก official image นั่นเอง

และถ้าลบทิ้งไปแล้ว account เหล่านั้นจะไม่สามารถใช้งานจากคนอื่นได้
หรือมาสมัครซ้ำได้

โดยในตอนนี้รายละเอียดยังไม่แน่ชัดเท่าไร
แต่ก็มีแนวทางการแก้ไขหรือรับมือของคนที่ได้รับผลกระทบแล้ว
ยกตัวอย่างเช่น

• ย้ายไปที่ใช้งาน Container Registry อื่น ๆ เช่น GitHub, Quay และ ใน cloud provider ต่าง เป็นต้น
• ทำการ migrate ไปใช้งาน account อื่น ๆ
• เปลี่ยนไปใช้ paid price plan

แต่ก็เหมือนใน Docker มี OOS program ด้วยนะ น่าจะเป็นอีกทางเลือก

ต้องติดตามข่าวสารกันต่อไป ว่าจะเป็นอย่างไร
เนื่องจากหลัง ๆ ทาง Docker เปลี่ยนแนวทางไปเยอะเช่นกัน

ลองถาม ChatGPT ว่า Top 50 คำถามหรือ prompt
ที่สามารถถามได้นั้นมีอะไรบ้าง
ก็ได้คำตอบมาน่าสนใจมาก ๆ
ซึ่งเป็นชุดคำถามพื้นฐานที่เอาไปใช้งานได้เลย

• What is the difference between front-end and back-end development?
• How do you choose the best programming language for a project?
• What are the most important software development methodologies?
• How can you ensure the quality of your code?
• What is version control and why is it important in software development?
• What is an API and how do you use it in software development?
• What are the benefits of agile software development?
• How do you manage dependencies in software development?
• What is a software development life cycle?
• How do you handle errors and exceptions in software development?
• What are the key principles of object-oriented programming?
• How do you design a database schema?
• What is test-driven development and how does it work?
• How do you optimize the performance of your code?
• What are the best practices for code documentation?
• How do you design a user interface?
• What are the most common design patterns in software development?
• How do you implement security measures in software development?
• What is DevOps and how does it relate to software development?
• What is continuous integration and why is it important in software development?
• How do you handle concurrency and synchronization in software development?
• What are the best practices for code reviews?
• How do you manage technical debt in software development?
• What is the role of a software architect?
• What is the difference between a framework and a library in software development?
• What is the SOLID design principle in software development?
• How do you debug a program?
• What are the most important design considerations for mobile app development?
• What are the best practices for testing and debugging web applications?
• How do you implement caching in software development?
• What is the difference between a unit test and an integration test?
• How do you handle user authentication and authorization in software development?
• What are the most common types of software bugs and how do you fix them?
• How do you implement machine learning algorithms in software development?
• What is the role of artificial intelligence in software development?
• How do you design a scalable system architecture?
• What is the difference between a monolithic and microservices architecture?
• What are the most common data structures used in software development?
• How do you implement real-time communication in software development?
• What is the role of containers in software development?
• How do you implement multithreading in software development?
• How do you optimize database performance?
• What are the best practices for version control using Git?
• How do you handle database migrations in software development?
• What is the role of software testing in agile development?
• What is the difference between a bug and a feature in software development?
• How do you implement a RESTful API in software development?
• What is the role of cloud computing in software development?
• How do you implement a scalable data storage system?
• What are the best practices for data security in software development?

ลองดูว่า แต่ละ promt นั้น จะได้คำตอบอะไรกันบ้าง ?
ดังนั้น เรื่องการตั้งคำถาม จึงสำคัญมาก ๆ

หลังจากที่แบ่งปันเรื่อง Robot Framework ไป
ก็เห็นว่าเพิ่งปล่อย version 6.1 alpha 1 ออกมาให้ลองใช้งาน
โดยใน version นี้จะมี feature ใหม่ที่น่าสนใจ เช่น

• การ convert พวก test case ต่าง ๆ ไปเป็น JSON file หรือสามารถ backward กลับได้ด้วย
• การใช้งาน JSON สำหรับกำหนด Variable ใน test
• ใน keyword สามารถใช้งาน embedded argument และแบบปกติ ได้
• ลดขนาดของไฟล์ output.xml ให้เล็กลง ด้วยรูปแบบข้อมูลใหม่ ด้วย robot:flatten

ตัวอย่างของการ convert test case ที่เขียนไปเป็นไฟล์ JSON

ตัวอย่างของไฟล์ JSON ที่ได้

ใช้งาน Argument ใน keyword

ทำการอ่าน variables จากไฟล์ JSON

ตัวอย่างของไฟล์ JSON

จากนั้นทำการเขียน Robot framework script ในการใช้งาน

ลองใช้งานดูครับ
เริ่มด้วยการ upgrade ก่อน

ทาง Oracle ได้ปล่อย Java 20 GA ออกมาแล้ว
โดย JEPs หลัก ๆ ใน release นี้จะมีอยู่ 7 ตัว
มาจาก project ต่าง ๆ เช่น Amber, Panama และ Loom เป็นต้น
ดังนั้นมาดูกันว่า feature ที่นักพัฒนาควรรู้และสนใจมีอะไรบ้าง ?

ตัวแรกคือ Record pattern (preview ที่ 2)

เปิดตัวมาตั้งแต่ Java 19 แล้ว
สามารถทำการทำการตรวจสอบด้วย instanceof และ switch-case
โดยไม่ต้องทำการ cast type

หรือการใช้งาน Record ใน for loop ก็สามารถเข้าถึง property ได้ด้วยวิธีแปลก ๆ

ตัวที่สองคือ Pattern matching ใน switch (preview ที่ 4 จะเยอะไปไหน)

มีมาตั้งแต่ Java 17 แล้ว
ทำให้ใน switch สามารถตรวจสอบได้ทั้ง
class และ condition ได้เลย

ไป Download มาลองใช้งานกันได้ที่ Download

Reference Websites

คำถามจากการแบ่งปันการทดสอบระบบ web
ด้วย Robot Framework และ SeleniumLibrary คือ
ทำไม web browser มันปิดเองอัตโนมัติ
หลังจากเมื่อทำการทดสอบเสร็จแล้ว
ทั้ง Google Chrome และ Microsoft Edge

โดยใช้งาน library ดังนี้

• robotframework 6.0
• robotframework-seleniumlibrary 6.0

จากที่ไปอ่านเนื่องจากมีการเปลี่ยนแปลงที่ค่า setting นั่นเอง
เพื่อไม่ให้เกิด process ของ webdriver ค้างในระบบ
แต่ถ้าไม่ต้องการให้ปิด
ก็สามารถใส่ option เข้าไปใน Open Browser ได้ดังนี้

จากบทความ De-cloud and de-k8s — bringing our apps back home
ที่ทาง 37signals ทำการย้ายระบบที่อยู่บน cloud
ไปยัง data center/server ของตัวเอง
โดยเท่าที่อ่านพบว่า ไม่ใช่แค่การย้ายเท่านั้น
แต่ยังรวมไปถึงการจัดการ dependency
แก้ไข code
การสร้างเครื่องมือสำหรับการย้าย และ deploy
และ update software ต่าง ๆ อีกด้วย

เริ่มที่ผลของการเปลี่ยนแปลง ประกอบไปด้วย

• แน่นอนว่าต้องลดค่าใช้จ่าย
• ลดความซับซ้อนของ infrastructure ลง
• ปรับปรุง deployment strategy
• ปรับปรุงการ provisioning ให้เร็วขึ้น
• ลดเวลาในการ deploy ลงไปอีก เหมือนได้มาทำความสะอาดบ้านใหม่
• ทำการ refactoring code ทำให้ code clean ขึ้น ส่วนที่ไม่ได้ใช้ก็เอาออกไป ลด code ไปได้เยอะ
• ปรับปรุงและ upgrade สิ่งต่าง ๆ เช่น version mysql ที่ใช้งาน และ configuration ต่าง ๆ

ในมุมมองของ tools ที่ใช้งาน

• ใช้ Docker อยู่แล้ว
• CDN มาใช้ Cloudflare
• Logging ใช้ ELK stack และ Filebeat อยู่แล้ว
• CI/CD มาใช้ GitHub Actions
• Databasae ใช้ Percona MySQL 8 ซึ่งทำการ migrate data จาก RDS มาด้วย
• Provisioning ใช้ Chef
• เปลี่ยนมาใช้งาน Redis สำหรับการ share ข้อมูล
• ในการ deploy ทำการสร้าง tool ขึ้นมาใช้เองเรียกว่า MRSK :: deploy webapp everywhere

เป็นอีก case study ที่น่าสนใจ

ใน Playwright 1.32 นั้นได้เพิ่ม UI mode (preview) เข้ามา
โดยที่เราสามารถ test, debug และ preview
สามารถ filter test ตาม status ของการ test
อีกทั้งเลือก browser ที่จะทดสอบได้
รวมทั้ง watch การเปลี่ยนแปลง เพื่อ run test ให้อีกด้วย
คุ้น ๆ เหมือนกับ Cypress เลย
น่าจะช่วยเพิ่มความสะดวกในการใช้งานอีกเยอะ

การใช้งาน UI mode ก็ง่าย ๆ ด้วยคำสั่ง

ปล. ไม่ต้องกลัวเหงา เพราะว่า Bug เพียบ

ใน version นี้จะมี breaking change นิดหน่อย
คือ component test กับ React นั่นเอง
เนื่องจากแยกกันระหว่าง react 18 และ 16/17

ดู VDO สำหรับ feature ใน verison 1.32 เพิ่มได้

เพิ่งเห็นว่าทาง Postman ได้ปรับปรุงทั้ง User Interface และการทำงานที่รวดเร็วขึ้น
สำหรับการจัดการ และใช้งาน Variable
โดยได้เพิ่มเรื่องของ การ filter และ sort ข้อมูล
อีกอย่างที่เพิ่งสังเกตเห็นคือ data type ของ variable
ที่เลือกได้ทั้ง default และ secret

ตัวอย่างของ User Interface ของการจัดการ Variable

ในส่วน Variable ที่เป็น secret type ก็ช่วยลดความเสี่ยง
เรื่องของ sensitive data ทั้ง user/pass และ token เป็นต้น

ลองใช้งานกันดูครับ

อีกอย่างเพิ่งรู็เลย ว่าในส่วนของ request นั้น จัดการ Path Variable ได้ง่ายดี

เห็นว่ามีการ share บทความเรื่อง
HOW DISCORD STORES TRILLIONS OF MESSAGES ?

ซึ่งเป็นบันทึกการเปลี่ยนแปลง database ที่ใช้เก็บข้อมูล
ที่พูดคุยต่าง ๆ ในระบบ Discord
จาก MongoDB -> Cassandra -> ScyllaDB
ทำให้เราเห็น use case และ เหตุผลในการเปลี่ยนแปลง
นั่นคือการแก้ไขปัญหานั่นเอง
จึงทำการสรุปสิ่งที่สนใจเอาไว้ดังนี้

สิ่งที่ผมสนใจคือ database ที่เลือกใช้
โดยเริ่มต้นจากการใช้งาน MonogoDB
เป็น NoSQL แบบ Document-based
ซึ่งมีโครสร้างแบบ primary for write + secondary for read (Replication)
ตัวอย่างการ deploy แบบ replica set

แต่เมื่อข้อมูลมีเกิน 100 ล้าน document แล้ว
ทำให้ข้อมูลใหญ่กว่า memory
ส่งผลให้เวลาการจัดการข้อมูลผ่าน MongoDB มีปัญหา ช้าบ้างเร็วบ้าง
ทำให้เกิดปัญหาต่อระบบ

ดังนั้นจึงต้องทำการเปลี่ยนแปลง !!
โดยสิ่งที่เลือก ต้องตรงกับความต้องการดังนี้

• Linear Scalability
• การดูแลรักษาง่าย
• เมื่อเกิดปัญหาสามารถ recovery แบบอัตโนมัติได้
• รองรับอัตราการ read/write แบบ 50/50 ได้ดี
• รองรับการทำ caching ของแต่ละกลุ่มข้อมูลของ user
• รองรับ full text search

ซึ่งจากความต้องการเหล่านี้ จึงเลือก Cassandra มาใช้งาน
เป็น NoSQL แบบ Wide-column based
เน้นที่ Availability มากกว่า Consistency
ในเรื่องความถูกต้องจึงต้องมีวิธีการตรวจสอบข้อมูลเยอะหน่อย

ผลจากการเปลี่ยนแปลงทำให้การ write และ read เร็วขึ้นอย่างมาก

• Latency ของการ write < 1 ms
• Latency ของการ read < 5 ms

ระบบทำงานได้ปกติ ไม่มีปัญหาอะไร
จนมาถึงปี 2022 นั้น ข้อมูลที่จัดเก็บมาถึงหลักล้านล้าน (trillion)!!
พร้อมกับ Cassandra 177 node
มาพร้อมกับปัญหาเรื่อง latency ที่เหวี่ยงไปมา
จากเรื่องการทำงานของ Garbase Collector(GC) ของ JVM !!
และปัญหา Hot partition ที่มาจากการแบ่งข้อมูลตาม key ที่กำหนด
ดังนั้นถ้ามีข้อมูลใน partition ไหนใช้งานสูง ก็ส่งผลต่อความเร็วอีก !!

จึงได้เวลาของการเปลี่ยนแปลงอีกครั้ง
นั่นคือการเลือกใช้ ScyllaDB
เป็นตัวแทนของ Cassandra
พัฒนาด้วยภาษา C++ จึงไม่มีปัญหาเรื่อง GC
และยังมี API ที่ compatibility กับ DynamoDB และ Cassandra อีกด้วย
แต่เรื่องของ Hot partition ยังคงมี

จึงทำการแก้ไขด้วยการสร้าง Data Layer ขึ้นมาด้วยภาษา Rust
อยู่ระหว่าง API ที่เขียนด้วยภาษา Python กับ Database นั่นเอง
ของเดิม API ยิงไปที่ Database ตรง ๆ เลย

โดยใน Data Layer ทำหน้าที่ดังนี้

• ถ้ามีการดึงข้อมูลเดิม ๆ ซ้ำกันมา จะมีเพียง request แรกเท่านั้นที่วิ่งไปยัง Database ทำหน้าที่ Caching data นั่นเอง

• ทำการเตรียม routing key ไว้สำหรับการจัดการ message ให้ไปอยู่ใน channel ต่าง ๆ เพื่อดึงข้อมูลจาก database เป้าหมายเพื่อลดปัญหาเรื่อง Hot partition

นั่นหมายความว่าทางทีม Discord พยายาม
ลดจำนวน request ที่วิ่งไปยัง Database ลงให้มากที่สุด

อีกเรื่องที่น่าสนใจคือ การ migrate data จาก Cassandra มายัง ScyllaDB
แบบไม่ให้มี downtime !!
ต้องไปอ่านรายละเอียดเพิ่มอีก

ดูเพิ่มเติมได้ที่

• Slideshare
• Diagram จาก Twitter ของ ByteByteGo

เรื่องมีอยู่ว่าต้องทำพัฒนา frontend ด้วย ReactJS
สิ่งหนึ่งที่ต้องทำเลยคือ การจำลองฝั่ง API ที่ต้องใช้งาน
เพื่อให้สามารถพัฒนาและทดสอบได้ง่ายขึ้น
หนึ่งในวิธีการก็คือ การใช้งาน MirageJS
มาดูการใช้งานกันดู

ปล. สามารถใช้งาน MirageJS ได้ทั้ง frontend และ backend
และยังทำงานร่วมกัย Cypress ได้ด้วย

ความสามารถพื้นฐานของ MirageJS เช่น

• ทำ dynamic data ได้
• กำหนดความสัมพันธ์ของ model/entity database เพื่อสร้างข้อมูล
• ทำการ route ของ HTTP request
• มี factory และ fixture สำหรับการ stub data (static)
• มีตัว serialize สำหรับ HTTP response ให้ด้วย

ขั้นตอนการใช้งาน

ขั้นตอนที่ 1 ติดตั้งเข้าไปใน project

ขั้นตอนที่ 2 สร้างไฟล์ server.js เข้ามาใน project

ในไฟล์นี้จะประกอบไปด้วย

• สร้าง web server (Mock) ด้วย MirageJS
• สร้าง seed data ขึ้นมา ตรงนี้สามารถใช้งาน FakeJS เข้ามาร่วมได้
• สร้าง route ของ API ที่ต้องการจำลอง และใส่ timing เพื่อจำลองความช้าได้อีกด้วย
• กำหนด model และ factory

ขั้นตอนที่ 3 สามารถใช้งานได้ทั้ง development และ testing

ตัวอย่างใช้ใน development mode
ก็ทำการสร้าง Mock API server ขึ้นมาได้เลย

ส่วนในชุดการทดสอบ เขียนแบบนี้

เพียงเท่านี้เราก็สามารถจำลอง
และเรียกใช้งานใน development mode ได้แล้ว
เนื่องจากตัว MirageJS จะคอยดัก request ที่ออกจาก web browser ให้

ขอให้สนุกกับการ coding

จากเหตุการณ์ที่ระบบ Reddit ล่มจากการ upgrade Kubernetes นั้น
ก็ไปเจอการอธิบายเรื่องการสร้าง platform ของระบบ Ranking
หรือระบบแนะนำ post ต่าง ๆ ในหน้า feed นั่นเอง
ซึ่งพัฒนามาจาก service จนกลายเป็น platform ที่ให้ใช้งาน
โดยทำการพัฒนาใหม่ด้วยภาษา Go
มีแนวทางที่น่าสนใจดังนี้

โดยการทำงานของระบบ Ranking จะมี 3 ขั้นตอนหลัก

• Candidate Generation ทำการดึงข้อมูลที่จะทำการ ranking เช่น post, user เป็นต้น
• Filtering ทำการกรองข้อมูล
• Scoring ทำการให้คะแนนและจัดเรียงข้อมูล ก่อนส่งกลับไปให้ user

แสดงดังรูป

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

ดังนั้นจึงได้เวลาปรับเปลี่ยนโครงสร้างการทำงาน
จากเดิมที่ทุก ๆ ขั้นตอนจะผูกมัดกันไปหมด (Tight coupling)
จึงทำการแก้ไขตามหลักของ UNIX ดังนี้

UNIX Toolbox Philosophy

• Write programs that do one thing and do it well.
• Write programs to work together.
• Write programs to handle text streams, because that is a universal interface.

ซึ่งทำการแบ่งแต่ละขั้นตอนเป็น stage แยกกันไปเลย (input -> output)
เพื่อให้แต่ละ stage มีการทำงานเรื่องใดเรื่องหนึ่งไปเลย
โดยตั้งชื่อ project ว่า PipeDreme ขึ้นมา

พร้อมกับใช้งาน Go concurrency ด้วย
ในการทำงานหนึ่งพร้อมกัน
แต่การดึงข้อมูลจากที่ต่าง ๆ ไม่ว่าจะเป็น post, image และ vdo เป็นต้น
แสดงการทำงานดังรูป

ทีมพัฒนาเรื่องใช้งาน package errgroup ในการจัดการ
ซึ่งก็คือ sync.WaitGroup นั่นเอง
ทำให้จัดการเรื่อง error propagation และ context cancellation ได้ง่าย
ข้อมูลในแต่ละ stage จะทำการ copy มาเลย ไม่แก้ไขที่ original data
อีกทั้งจะรอให้แต่ละ stage ทำงานเสร็จก่อน จึงจะทำงานต่อไปได้
เพื่อลดปัญหาเรื่องของ data race

ยกตัวอย่าง เช่น ต้องดึงข้อมูลจากทั้ง 3 ที่มาให้เสร็จก่อน
จึงจะทำการ merge เป็นต้น

เป็นอีกแนวคิดที่น่าสนใจมาก ๆ
ลองนำไปใช้งานกันดู

จากงาน Firebase Dev Day 2023 นั้น
เข้ามาฟังเรื่อง Building a more Efficient Firestore Web App พอ
เป็นเรื่องที่น่าสนใจมาก ๆ สำหรับการใช้งาน Firestore ใน web application ของเรา
เน้นในเรื่องของการใช้งานให้ถูกต้องตามที่ต้องการ
รวมทั้งยังช่วยลดค่าใช้จ่ายลงไปอีกด้วย

เนื่องจากระบบงานส่วนใหญ่อัตราการ read จะมากกว่า write มาก ๆ
ดังนั้นถ้านำ Firestore มาใช้ในงานที่อ่านเยอะ ๆ
ค่าใช้จ่ายก็สูงตาม
ดังนั้นเราจำเป็นต้องรู้และเข้าใจวิธีการจัดการ หรือ แก้ไขด้วย
มิใช่ ใช้ไปเรื่อย ๆ แล้วก็เปลี่ยน free plan ไปเป็นเสียเงิน
แบบที่ยังไม่รู้ปัญหาว่าเพราะว่าอะไร

ยกตัวอย่างเช่น

• เช่น ความแตกต่างของการใช้งาน getDocs() และ onSnapshot() ?
• ระบบแสดงผลจ้อมูลที่ไม่ค่อยเปลี่ยนแปลง แล้วมีผู้ใช้งานจำนวนมาก การไปอ่านจาก firestore ทุกครั้งคงไม่ดี
• การนับจำนวนของเอกสาร เช่นการใช้ count() นั้น ก็ทำให้การ read สูงเยอะอีก แนะนำให้ใช้ aggregate query จะดีกว่านะ

การแก้ไขเรื่องการอ่านมาก ๆ ก่อนหน้านี้อาจจะแก้ไขด้วย
การเอา CDN มากั้นไปเลยในฝั่ง frontend

ส่วนทาง Firestore ก็แนะนำมา 2 ทางคือ

• การใช้งาน Firestore data bundle
• การใช้งานร่วมกับ Readtime database

การใช้งาน Firestore data bundle

จะทำการสร้างข้อมูลที่ใช้งานบ่อย ๆ ขึ้นมา และไม่ค่อยเปลี่ยนแปลง
หรือเป็นพวก configuration ต่าง ๆ ที่ต้อง load ตอน startup หน้าจอ

มีรูปแบบเป็น binary นั่นหมายถึงเราสามารถไปเก็บใน binary storage ได้
ดังนั้นในฝั่งของ client นั้นสามารถนำ bundle ที่สร้างไปใช้งานได้เลย
เหมือนกับ caching data นั่นเอง
ทำให้ลดการเข้าถึง Firestore ลงไป

แต่ถ้ามีข้อมูลที่เป็น private/sensitive data ก็ไม่ควรเก็บใน bundle นะ !!
รวมทั้งข้อมูลที่เปลี่ยนบ่อย ๆ

แต่ปัญหาที่ตามมาคือ ถ้า Data Bundle มีขนาดใหญ่ละ ?
จะจัดการอย่างไร
เพราะว่าแน่นอน caching data ฝั่ง client ใหญ่ขึ้น ภาระหนัก !!
หรือการเข้าถึง หรือ ค้นหาข้อมูลก็ช้าลงไปอีก

ดังนั้นจากปัญหาก่อนหน้า ก็ได้ปัญหาใหม่มาอีก
ซึ่งแนวทางการแก้ไขก็คือ Client-Side Indexing
มีมาใน Firestore SDK นั่นเอง
ปกติทำในฝั่ง server เท่านั้น แต่ก็มีใน client ด้วยเช่นกัน

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

Reference Websites

• Firestore best practice

Microsoft Teams ได้ปล่อย public preview ออกมาให้ลองใช้งาน
ซึ่งทำการเปลี่ยนทั้ง Architecture, User interface และ technology ที่ใช้พัฒนา
เพื่อให้ตอบโจทย์เรื่อง

• Speed
• Performance
• Flexible
• Intelligence

หรือจะเรียกว่า "reimagining of Teams from the ground up"

ถ้าใครใช้งาน Microsoft Teams มา จะรู้ว่า
การทำงานจริง ๆ นั้น ตรงข้ามกันเลย !!
นั่นจึงเป็นเป้าหมายหลักของ version ใหม่
เนื่องจากได้รับ feedback ด้านลบเยอะมาก ๆ

โดยผลการทำงานใน version ใหม่นี้
ความเร็วของการทำงานเพิ่มขึ้น 2 เท่าจากเดิม
รวมทั้งใช้งาน resource น้อยลงกว่าเดิมอีก ทั้ง CPU และ Memory
นั่นคือการ optimize เรื่องของข้อมูลที่ต้องใช้งาน
จัดการระบบ network ให้ดีขึ้น
รวมทั้งปรับปรุง architecture ของ chat และ VDO

ในส่วนของ User Interface ได้เปลี่ยนยกแผง

• หน้าตาเรียบง่าย ใช้งานง่าย
• ลดการ click

อ่านเพิ่มเติมเรื่องการออกแแบได้ที่ Designing the new era of Teams

ในฝั่ง User Interface หรือ Frontend นั้น

ทำการเปลี่ยนจาก Electron มาเป็น Microsoft's Edge WebView 2
รวมทั้งเปลี่ยนจาก AngularJS มาเป็น ReactJS
เน้นด้วยว่า AngularJS นะ ไม่ใช่ Angular

และทีมได้สร้าง standard UI ขึ้นมาสำหรับ ReactJS
ในชื่อ project Fluent UI React Components

โดยรวมแล้ว Microsoft Teams ตัวใหม่จะเน้นสิ่งต่าง ๆ ดังนี้

ส่วนของ Architecture ของง App ก็น่าสนใจ

ลองทดสอบกันดูครับ ว่าเป็นอย่างไรกันบ้าง ?