Blockdit Logo (Mobile)
ณัฐมาคุย
ยืนยันแล้ว
•
6 ก.ย. 2022 เวลา 13:27 • ความคิดเห็น
การรองรับสถานการณ์แอปล่ม ตอนที่ 3: ต้นกำเนิดปัญหาส่วนที่สอง
ในตอนที่แล้ว ผมเกริ่นถึงความสำคัญของสถาปัตยกรรมองค์กรไปบ้างแล้ว ในตอนนี้จะมายกตัวอย่างมุมมองให้เห็นชัดเจนมากขึ้นว่ามันมีความสำคัญอย่างไรกับการออกแบบระบบให้ไม่ "ล่ม"
เพื่อให้ท่านผู้อ่านที่อาจจะไม่ได้อยู่ในวงการไอทีเข้าใจ ผมขอยกตัวอย่างเป็นเรื่องที่พอเข้าใจได้ล่ะกันครับ
หากใครเคยทำหนังสือเดินทางในอดีต คงจะจำภาพเก่า ๆ กันได้ที่ความสามารถในการทำหนังสือเดินทางที่กองหนังสือเดินทาง กรมการกงสุล กระทรวงการต่างประเทศกันได้ ว่ามันยุ่งยาก ยาวนาน และซับซ้อนเพียงใด
เราต้องเริ่มจากถ่ายสำเนาบัตรประชาชน สำเนาสูติบัตร สำเนาทะเบียนบ้านต่าง ๆ มากมาย
เสร็จแล้วก็ต้องกรอกข้อมูลลงในใบสมัคร ไปรอเจ้าหน้าที่ให้ตรวจใบสมัคร เสร็จ ต้องไปวัดส่วนสูง พิมพ์ลายนิ้วมือ ถ่ายรูป ชำระค่าธรรมเนียม รับบัตรนัดมารับหนังสือเดินทาง หากขั้นตอนใด ทำงานล่าช้า เราก็มักจะสังเกตเห็นคิวรอที่ขั้นตอนนั้นที่ยาวตามไปด้วย
ดังนั้น ตรงจุดนี้ หากเราสังเกตกัน การทำงานของลูกค้าจะมีลักษณะที่เป็นลำดับการทำงาน (sequential) หากลูกค้าเกิดสะดุดตรงจุดหนึ่งจุดใด ไม่ว่างานในขั้นตอนนั้นจะเล็กน้อยเพียงใด เขาจะไม่พอใจทันที เพราะ job to be done ของเขาก็คือ การทำหนังสือเดินทางให้สำเร็จ
ระบบไอทีก็ไม่ได้ต่างกันเลย กว่าที่จะประมวลผลธุรกรรมต่าง ๆ ได้นั้น มีขั้นตอนในการทำงานหลายขั้นหลายตอนเลยทีเดียว ในตัวอย่างของแอปธนาคารนั้น ก็มักจะมีขั้นตอนคร่าว ๆ ดังนี้
  • 1.
    เริ่มต้นจากแอปของลูกค้า เวลาลูกค้าใช้ก็ต้องมีการตรวจสอบยืนยันตัวตนกันก่อน
  • 2.
    หลังจาก login ระบบก็จะพามาสู่หน้าหลัก ซึ่งจะมีข้อมูลต่าง ๆ มากมาย
  • 3.
    ลูกค้าก็ต้องเลือกรายการจากเมนูที่มีอยู่ กรอกข้อมูลที่ต้องการทำ
  • 4.
    และทำตามขั้นตอนไปเรื่อย ๆ ทีละหน้าจนกว่าจะจบ
  • 5.
    ถึงจะรู้สึก Happy ว่าได้ธุรกรรม
แต่การทำงานในระบบไอทีนั้นมีความซับซ้อนกว่านั้นมากมายหลายเท่าตัว เพราะแอปที่ส่งคำสั่งมา ก็จะต้องทำงานได้ถูกต้อง สามารถส่งคำสั่งนั้นมาประมวลผลที่ทางฝั่งเซอร์เวอร์ได้ถูกต้อง และสามารถรับคำตอบกลับไปและประมวลผลจนถึงแสดงผลให้ลูกค้าได้ถูกต้องเช่นกัน
ซึ่งต้องผ่านกระบวนการมากมาย ไม่ว่าจะเป็นการเชื่อมต่อไปหา server ด้วย HTTPS ผ่านการเข้ารหัส SSL/TLS ส่งข้อมูลผ่าน TCP protocol โดยทำงานอยู่บน IP วิ่งผ่านอุปกรณ์เครือข่าย (network equipment) ต่าง ๆ เช่น cell site, router, switch จนกระทั่งถูก route ไปยังเครื่องปลายทางได้
ส่วนในระดับแอปที่ทางฝั่งเซอร์เวอร์เองนั้น ก็มีความซับซ้อนมาก ไม่ว่าจะต้องรับข้อมูลที่เข้ารหัสผ่าน TLS มา และต้องถอดรหัสเหล่านั้น (SSL Termination) ส่งเลือกข้อมูล (load balancing) นั้นไปยังเว็บเซอร์เวอร์ (web server) ที่พร้อมรับคำสั่ง
เว็บเซอร์เวอร์เองก็ต้องตีตวามคำสั่งเหล่านั้น ตรวจสอบว่าคำสั่งนั้นส่งมาจากคนนั้นจริงๆ (authentication) และมีสิทธิ์นั้นจริง ๆ (authorization) และต้องทำการส่งคำสั่งนั้น (routing) ไปยังหน่วยประมวลผลที่ถูกต้อง
ส่วนหน่วยประมวลผลเอง ก็ต้องตรวจสอบข้อมูลว่าถูกต้อง ทำการติดต่อฐานข้อมูล หรือระบบอื่นเพื่อสั่งการให้ระบบทำงาน ก่อนที่จะส่งคำตอบคืนกลับไป
เราจึงเห็นได้ว่า มีจุดที่สามารถที่จะล้มเหลวได้เต็มไปหมดตลอดทาง และหากใครที่ประสบปัญหาในจุดหนึ่งจุดใด คน ๆ นั้นก็จะไม่ Happy ทันทีเหมือนตัวอย่างในเรื่องการทำหนังสือเดินทางที่เล่าให้ฟัง
หากสมมติว่า งานหนึ่งมีขั้นตอนการทำงานต่อเนื่อง 100 ขั้นตอน และมีโอกาสทำสำเร็จ 99% (ซึ่งถือว่าสูงมาก) งานนั้นจะมีโอกาสทำสำเร็จเพียง 36.60% เท่านั้น!
การออกแบบที่ดี จึงต้องออกแบบให้ลูกค้าสามารถมีโอกาสทำงานเหล่านี้ได้สำเร็จให้มากที่สุด และมีจุดที่ล้มเหลวให้น้อยที่สุด ซึ่งมีเทคนิคมากมายในโลกไอทีเช่น
  • ✓
    ถ้าระบบมันห่วย มีปัญหามาก ๆ ก็เสริมระบบการลองทำซ้ำ (retry) เข้าไป ซึ่งสามารถทำได้โดยลูกค้าไม่รู้เสียด้วยซ้ำ
  • ✓
    ระบบไหนมีโอกาสล้มเหลว เสียหายบ่อย เราก็อาจจะเพิ่มระบบสำรองเข้าไป (redundancy) เวลาที่มีความเสียหาย เราจะได้มีระบบสำรองที่พร้อมจะทำงานทดแทน
  • ✓
    ระบบไหนทำงานช้า เราก็อาจจะ upgrade ไปใช้ระบบที่มีประสิทธิภาพมากขึ้น (vertical scaling)
  • ✓
    หรือไม่ก็เพิ่มจำนวนหน่วยประมวลผลเข้าไป (horizontal scaling)
  • ✓
    ส่วนหากปริมาณงานมีการเปลี่ยนแปลงมากน้อยไม่เท่ากัน เราก็อาจจะทำระบบให้รองรับงานสูงสุดและบวกเผื่อไปอีก (overcapacity) หรือไม่ก็ออกแบบระบบให้สามารถขยายกำลังได้อัตโนมัติ (automatic scaling) ได้เป็นต้น
  • ✓
    หรือไม่ก็ลดขั้นตอนทำงานที่สามารถที่จะล้มเหลวให้ได้มากที่สุด
เห็นไหมครับ นี่ขนาดยังไม่ได้เริ่มทำงานเลย เราก็มีอะไรที่ต้องคิดกันมากขนาดนี้แล้ว แล้วเวลาทำงานจริงล่ะจะยากขนาดไหน ไว้เรามาติดตามกันต่อครับ
สามารถติดตามตอนอื่นๆ ได้จากซีรีย์ "การรองรับสถานการณ์แอปล่ม" ด้านล่างนี้ครับ

ดูเพิ่มเติมในซีรีส์

โฆษณา