This Week I Learned #3
The Weekly TWIL Newsletter
How to have buckets of time
เทคนิคหนึ่งที่ใช้ในการจัดการเวลาคือมี bucket สำหรับเวลาไว้ แล้วก็เติมงานต่าง ๆ เข้าไปใน bucket นั้นจนเต็ม เสร็จแล้วก็ทำรวดเดียวเลยให้หมด bucket นั้น เมื่อก่อน DHH พยายามจะทำ inbox zero ตอนที่ใช้ Gmail อยู่ ถึงแม้จะทำได้ แต่ก็ไม่ได้รู้สึกว่า productive เท่าไหร่ เพราะว่าไม่ได้ focus ด้วยเหตุนี้ก็เลยมีฟีเจอร์ Reply Later ใน HEY รวมไปถึงทำแบบเดียวกันใน GitHub issues ทำให้สามารถทำในเวลา schedule ของตัวเองจริง ๆ ได้
https://world.hey.com/dhh/how-to-have-buckets-of-time-38693993
The early bird sees the sunrise
ธรรมชาติสวยงามอย่างไร ก็สวยงามอย่างนั้น home office ของ DHH ที่ Malibu เป็น home office ที่สวยมาก แล้วก็เพิ่งรู้จักคำว่า forest bathing นี่แหละ ที่ช่วยลดความเครียด และความดันได้เป็นอย่างดี
https://world.hey.com/dhh/the-early-bird-sees-the-sunrise-aa97c012
Software Architecture Meetup 2023 #2
ดูวีดีโอต่อจากอาทิตย์ที่แล้ว
Saga Pattern
เวลาทำงานกับ database ทั่วไปจะมีเรื่องคุณสมบัติ ACID transaction แต่ว่าเวลาทำงานกับ distributed system เราจะมีปัญหาเกี่ยวกับ ACID เราจะเสียตัว A กับ I (ทำให้อาจจะเกิด race condition) ไป ทำให้เราต้องจัดการเรื่องพวกนี้อีก มีวิธีแก้วิธีหนึ่งคือใช้ Two-Phase Commit แต่อาจจะไม่เหมาะในกรณีที่เรามี services เยอะ ๆ หรือว่าต้องไปต่อกับ service อื่น ๆ ของระบบคนอื่น
ก็จะมีอีกวิธีหนึ่งคือใช้ Saga Pattern (จะเห็นใน event-driven architecture หรือ EDA อยู่บ่อย ๆ) จะเป็นการที่เราแตก transaction หนึ่ง ๆ ออกมาเป็น step ย่อย ๆ แล้วก็แต่ละ step จะถูกรันในแต่ละ service แล้วแต่ละ step ถ้าเป็นการ create ก็ต้องมีเรื่องย้อนกลับ undo หรือ cancel อยู่ในตัวมันเองด้วย เราเรียก transaction เส้นที่ย้อนกลับว่า compensating transaction ซึ่งเส้นนี้เราต้องคุยกับทาง business ด้วยว่า ถ้าเกิด failures ต่าง ๆ พวกนี้แล้วจะให้ระบบทำงานอย่างไร และพวก compensating transaction พวกนี้ต้อง idempotent ด้วย คือสามารถทำซ้ำได้หลาย ๆ ครั้ง อย่างปลอดภัย ไม่เกิด side effect ก็จะเป็นการแก้ปัญหาของตัว A ส่วนการแก้ปัญหาตัว I เราก็จะต้องมาทำเอง ใช้วิธี semantic locks, commutative updates, pessimistic views และ reread value
Prove Distributed System with TLA+
ระบบของเรายิ่งซับซ้อนมากขึ้น (เป็น distributed system) โอกาสที่จะเจอ failures ต่าง ๆ ก็จะเยอะขึ้นตามด้วย หรือว่าเวลาที่เราจะเพิ่มของเข้าไปในระบบ เราจะมั่นใจได้อย่างไรว่าระบบทั้งหมดยังคงทำงานถูกต้องอยู่ ตัว TLA+ ที่เป็นภาษา formal language จะสามารถเข้ามาช่วยเราในการออกแบบก่อน และทำ verification กับระบบของเราได้ก่อนที่จะไปลงมือทำจริง น่าสนใจดี
สามารถตามไปดู TLA+ ต่อได้ที่ Learn TLA+
https://www.facebook.com/100045274272935/videos/3420939444885146
Microservice Pattern — 2 Phase Commit ฉบับย่อ
2 Phase Commit หรือ 2PC ยกตัวอย่างเช่นเรามี 2 services (Customer กับ Order) เวลาที่ลูกค้าจะซื้อของ สิ่งที่เราต้องทำคือ สร้าง unique ID มาสักตัวหนึ่ง หรือ เป็น transaction ID ก็ได้ เสร็จแล้วก็แจ้ง หรือ request ตัว Customer ว่าเดี๋ยวจะมีการสร้าง order ของ customer คนนี้นะ จะมีการหักยอดเงิน ให้ lock database object ไว้ด้วย เสร็จแล้วก็ค่อยส่งไปแจ้ง Order ว่าเดี๋ยวจะมีการสร้าง order มานะ หลังจากนั้นค่อย commit การหักยอดเงินจาก customer แล้วก็ไปสั่งซื้อ order ต่อ จะเห็นว่ามี phase คือ
Commit request
Commit
ซึ่งถ้าเกิดข้อผิดพลาดขึ้น เราก็ abort หรือ rollback โดยใช้ unique ID ที่เราสร้างขึ้นไว้ตอนแรก
The Journey of Deploying Apache Airflow at Grab
ที่ Grab ใช้ Airflow ในการจัดการข้อมูลในด้านต่าง ๆ แล้วตอนแรกก็มีแต่ละทีมมี Airflow ของตัวเอง ซึ่งก็กลายเป็นทำเรื่องซ้ำ ๆ กันหลายอย่าง จนเกิดแนวคิดที่ว่าจะมี dedicated ทีมหนึ่งที่คอยดูแลจัดการ Airflow ไปเลย มีการทำ CI/CD ขึ้นไปบน Kubernetes (ใช้ EKS บน AWS) ซึ่งตัว instance ก็มีแบ่งเป็น small, medium แล้วก็ large ด้วย เพื่อจัดการ resources ในการรัน เรื่องโค้ดก็มีทำ common plugins/operators/hooks ต่าง ๆ มีการเชื่อมต่อกับ LDAP เพื่อทำ authentication มีการใช้ Vault เก็บ secrets มีการใช้ ELK จัดการ logs ส่วนเรื่อง monitoring ก็ใช้ Datadog กับ PagerDuty แล้วก็เรื่อง infrastructure ก็จัดการโดยใช้ Terraform
จากที่อ่าน ๆ ดูแล้วก็เป็น stack โดยปกติในการ scale ตัว Airflow ไม่เห็นว่ามี customize อะไรเพิ่มเติม ซึ่งถ้าใครที่กำลังจะ scale Airflow ของตัวเองอยู่ก็สามารถมาดูที่ Grab เค้าทำได้เลย
https://medium.com/grab/the-journey-of-deploying-apache-airflow-at-grab-493d778c73a8