สรุปงาน Software Architecture Meetup 2022

ดีใจมากที่งานนี้มี Live เพราะพี่มาร์คทำให้เห็น Feed ช้าไปหลายวัน 55 โดยหัวข้อที่ฟังมา มีดังนี้ครับ

CALM Theorem, Distributed Make Easy

• CALM Theorem - Proof ที่บอกว่า Distributed System ที่มันง่าย และอันไหนที่ซับซ้อน
• คล้ายกับ CAP Theorem ที่ให้เราเข้าใจถึงข้อจำกัด-เข้าใจถึงกฎการแลกเปลี่ยนที่เท่าเทียม

- ยกตัวอย่าง Program

• Distributed Deadlock Detection
  • หน้าที่ เอาหา Deadlock จากรูป เรามองแล้วรู้ทันทีว่าตัวที่ Deadlock คือ (T1/T3) และ (T5/T6)
  • แต่ถ้า Program มันไม่ได้เห็นภาพรวม เห็นแต่เฉพาะ Node หล่ะ เกิด Partition Break (แต่ละ Node Communication หลุดไป) คำตอบเปลี่ยนไปเลยนะ กลายเป็นว่า (T1/T3) = deadlock แต่ (T5/T6) ไม่เป็น deadlock ไม่เห็นความสัมพันธ์ของ T5 กับ T6
  • NOTE คำตอบ (T1/T3) = deadlock ยังใช้ได้นะ เพราะ ยังช่วยให้เราแก้ปัญหาบางส่วนได้อยู่ คำตอบยังเป็น Subset ของทั้งหมด

• Distributed Garbage Collection
  • หน้าที่ ถ้าเราให้กลุ่มของ Object ไป โปรแกรมตอบว่า อะไรควรจะถูก Garbage ออกไป เคสนี้ภาพรวม O1/O3 ที่ Node 1 และ O7 สามารถ Clear ได้ เพราะไม่มี Link เชื่อมกับ Root (Procedure หลัก)
  • แต่ถ้า App ของเราเจอสถานการณ์แบบ App ที่แล้ว มันอ่านได้เพียง Node เดียว (Partition Break ) คำตอบกลายว่า O1/O3 + O2 ที่ Node 1 สามารถ Clear ได้ แต่จริงๆ แล้ว O2 มัน Link กับ O4 ซึ่งเชื่อมกับ Root อยุ่ ถ้าไป Clear จะบึ้มแน่นอน
  • จาก Scenario ข้างต้น จะพบมันมีความสัมพันธ์ Computation require coordination of node เช่น Path Node2:ROOT > NODE2:O4 > NODE1:O2 จำเป็นต้องให้ทุก Node Link กัน เพื่อให้ได้คำตอบทั้งหมด เอาบางส่วนมาใช้งานไม่ได้

- Two types of distributed Program

• จากตัวอย่างข้างต้น แยกได้ว่า
  • แบบแรก - คำตอบบางส่วนถูกต้อง นำไปใช้งานได้ อย่างตัว Distributed Deadlock Detection
  • แบบสอง ถ้าพังบางส่วนไประบบล่มหมด ดังนั้นจำเป็นต้องมีขั้นตอนการ Consensus / Vote ขึ้นมา อย่างตัว Distributed Garbage Collection
• แล้วเราจะรู้ได้ไง distributed program แบบไหนที่แบบที่ 1 หรือ 2 วัดจาก key เรื่อง coordination + consistency //หาว่าใครถูกผิดในแต่ละ node ตัดสินยังไง ?
  • ก่อน 2010 เมื่อก่อนใช้ Sense จากคนออกแบบระบบ
  • หลัง 2010 มีคน Proof ตัว CALM Theorem จากคุณ JOE HELLERSTEIN

- Consistency As Logical Monotonicity Theorem (CALM Theorem)

• App ของเราไม่จำเป็นต้องทำส่วนที่ต้อง coordination ถ้า App ของเราเป็น monotonic

• monotonic คือ อะไร โปรแกรมที่คำตอบบางส่วนยังใช้ได้ จากตัวอย่างข้างต้นจะเป็นตัว Distributed Deadlock Detection แม้ว่ามี Data + Worker/Node เพิ่มขึ้น ผลลัพธ์ไม่ได้ลดลง + Trend ไปทางเดียว เช่น Union / Intersect (ลดลงไปในทางเดียวกัน) / Sum / Count ทำให้ทราบว่า App ของเราไม่ต้องเก็บ State ไว้ เอา result ออกมาแล้ว clear ได้เลย คุม memory ได้

- ตัวอย่างใกล้ตัว Shopping Cart

• Scenario Add Orange / Add Book / Add Beacon / Remove Beacon ออก และทำ HA แบบปกติ มี Load Balancer + Node 3 อัน

• แต่ถ้า Node นึงล่มไปทำยังไง ตอนนี้ แต่ละ Node รับรู้ต่างกัน ตรวจยังไง
  • Consensus ยาก + เปลืองไหม ?
  • กลับมามอง Common Design - Event Souring เพราะทุก Node รับ Event ไป ตัวไหนมี Event มาสุดน่าเชื่อถือได้
• จริงๆแล้ว ใน Node หนึ่งๆ เราใช้ monotonic อย่างเดียว หรือป่าว ? //ไม่นะ มันแยกได้ 2 ส่วน Event Concatenator
  • ส่วนแรก Event Concatenator - มี Union Event - monotonic
  • ส่วนสอง Event State Calculation - เอา Event มาคำนวณ
  • Note พอเรารู้ความสัมพันธ์ของ Event Concatenator > Event State Calculation แทนที่จะต้องรอผลลัพธ์ จากส่วนที่สอง เราสามารถหาทางลัด ดูจากของ Event Concatenator ที่รวดเร็วกว่า

• ดังนั้นจะเห็น Design Pattern จากส่วนซับซ้อน พยายามแยก Sub-System ย่อยที่เป็น monotonic / non-monotonic หา Boundary ให้พบ ทำไมนึกถึง DDD หว่า

- CALM Theorem >> Event Souring อย่างเดียว ?

• ยกตัวอย่างของระบบ Amazon ที่มัน Event เยอะม๊ากก ถ้าใช้ Event Souring ไม่น่าจะไหว เพราะ load ระบบเยอะ แทนที่จะเก็บ ก็กำหนดเป็น Set ของที่เพิ่ม และ Set ของที่ลบ แทน
  • ถ้ามี node1 ตาย ใช้หลักการเดียวกับตัวอย่างก่อนๆเลย ดูจากส่วนของ monotonic แล้วตัดสินใจได้เลย

• คำถามที่สำคัญของการเสนอ Design?
  • How do we know is it safe
  • Do we need whole event for co-ordination, in case anything goes wrong ?
    จาก CALM Theory ที่ Proof มาแล้ว ถ้าส่วนใหญ่เป็น monotonic แล้ว + non-monotonic ที่ถูกลำดับ จะไม่เกิดปัญหาที่มาใช้ Consensus

- Summary

• Distributed - Make Easy โดยลดส่วนของ coordination / consensus ทำให้เราหาคำตอบได้ง่าย ว่าถูก / ผิด
• พยายาม Design ให้ส่วนของ Monotonic ออกมาให้มาก และ non-Monotonic ที่เล็กที่สุด จะได้ลดความซับซ้อน
• Q&A
  • ตอนสุดท้ายมีคำถามเกี่ยวกับ CRDT (conflict-free replicated data type) ไม่รู้ว่าเกี่ยวกับอันนี้ไหม CRDTs in Production (infoq.com)
  • Event ไม่เป็น monotonic เสมอไป ขึ้นกับการ Implement ถ้า Order มีความสำคัญจะไม่เป็น Monotonic ถ้ามี Timestamp อาจจะทำได้ เป็นต้น
• มีเพิ่มเติมด้วย ลองไปอ่านเพิ่มกันครับ

บอกลา Shared Secret ด้วย OpenID Connect

• ทำงานข้าม Cloud กันตอนนี้ทำอย่างไรกัน เช่น จาก GitHub Action > GCP หรือ S3 ตอนนี้ทำอย่างไร ? Hard Code ไหม >> ใช่ 555
• จะเป็นปัญหาว่า Integrate ระบบหลายๆ เช่น Cloud หลายๆเจ้า เราต้องมา manage secret ซึ่งหลายท่า
• ท่าแรก กำหนด Secret Key เอามาใช้กัน ฝั่ง Server มาตรวจว่าใช่ไหม ส่วน Client ส่งมาถ้าต้องการใช้
  • Setup ได้ง่าย
  • ต้องมาจัดการ Secret นี้แทน ว่าจะจัดการยังไง เช่น เปลี่ยนเครื่อง หรือทำหลุดเป็นต้น
• ท่าสอง Credential - เช่น พวก CMS
  • Familiar
  • ทุก Credential ของทุกคนลง DB เรา จัดการว่าใครแก้ไข จัดสิทธิได้
  • Dev ต้องมาจัดการพวกนี้แทน
    • ถ้าลืม pass ต้องทำยังไง ? Reset ทิ้ง เป็นต้น
    • admin ใครถือ pass hard code ระบบไว้ หรือใช้ชุดเดียวทั้งหมด หรือ กำหนดสิทธิตาม RBAC << ถ้าใครออกไปมารปรับตาม Role
• ท่าสาม OAuth 2.0
  • สิ่งที่มาช่วยให้ง่าย SSO อย่าง Sign-in with Google ที่ใช้ OAuth2.0 ที่ใช้ Client Id + Client Secret
  • ถ้าทำงานกันเป็นทีม ก็เอาไฟล์ env มาส่งให้ทีม เค้าบอกว่าส่งผ่าน One Password เราส่งผ่าน Line ใช้ใน Dev เนอะ 555 หรือทำ Shared App
  • แต่พวก Open Source จะบังคับให้ไป register app กับ Google Provider

Root Cause ที่เกิดขึ้นมาจากสิ่งที่เรียกว่า Share Secret

- แล้วจะเอาอะไรมาแก้ OIDC (Build on Top OAuth 2.0)

• OAuth 2.0 เดิมทำยังไง ? >> An Introduction to OAuth 2

• OIDC (OpenID Connect)
  • จากเดิม OAuth 2.0 มันจะได้ Access Token สำหรับยืนยันตัวตน ซึ่งไปสิทธิเยอะไป ตัว OIDC ใช้ ID_TOKEN (Implicit Flow) ที่มาสร้าง Session ได้เลย ไม่ต้องใช้ Access Token และ Client Secret เลย
  • ID_TOKEN เป็น JWT
    • header บอก Algorithm + Type
    • json บอก token นี้
      • Issue โดยใคร
      • Audience Service - Client Id ที่ใช้เป็นอันไหน
      • หมดอายุตอนไหน ?
    • Signature - เอาไว้ verify กับ public key ที่ได้อีกที
  • ถ้าต้องการสิทธิอื่นๆเพิ่มเติมใช้ Access Token //implement เพิ่มเติมกัน
  • Step มันอาจจะเยอะ แต่มี library มาช่วย JWT, JWS, JWE, JWK, and JWA Implementations | OpenID //C# ก็มีนะ

• Recap เวลาทำ SSO
  • เมื่อก่อนจะเป็น Share Secret ต้องรู้ Client Id / Client Secret ตอนทำ OAuth แต่ถ้าใช้ OIDC ไม่ต้องมาใช้ 2 ตัวนี้
  • ตอนนี้ ใช้ ID_TOKEN (ลึกๆมันหลักการ Public key / Private Key) เพื่อเอามายืนยันตอนตัวตน ไม่ต้องมาแจก Client Id / Client Secret ทำให้ Loosely Coupling และ ลดความเสี่ยงด้วย
  • CI/CD ของ GitHub Action เมื่อก่อนเราอาจจะ Hard Code ไว้ใน Repo เลย แต่ตอนนี้ เราสามารถใช้ OIDC ได้ ตัว Aws มี Identity Federation / Azure > OpenID Connect authentication with Azure AD ทำให้ไม่ต้องกังวลว่าจะยัด Secret ลงไปใน Repo ของเรา
  • เวลาเรา Protect-End Point พยายามใช้ IdPs ที่เป็น Open-Id Connect เพื่อลด Effort การ Manage Secrets อย่างตัว Google จะมี Google Identity Service
  • เวลา Intergrated System เข้าด้วยกัน พยายามใช้ OIDC
• Q/A
  • Q: ทำ OIDC ข้าม Domain ได้ไหม
    A: Issue ต้องเป็น Domain เดียวกันเจ้าของ

ฟัง live จบสิ่งที่ต้องทำหลังจากนี้เรียน Course Software Architecture Design ของคุณชาคริตใน Skooldio ให้จบก่อน ดองไว้อยู่ 555

มี Live ด้วยนะ

• เผื่อผมอาจจะตกหล่นอะไรไป ^__^ >> Software Architecture Meetup 2022 Live

Reference

• Software Architect MeetUp Bangkok | Facebook
• Software Architecture Meetup | Eventpop | Eventpop