Experimental Banking Ep.2 — เทคโนโลยีที่ช่วยขับเคลื่อน Mobile Banking สำหรับคนรุ่นใหม่
เนื่องจากพวกเราชาว KBTG มีเป้าหมายที่จะเป็นผู้นำทางด้านเทคโนโลยีของเอเชีย เราจึงมีการทดลองผลิตนวัตกรรม (Innovation) อย่างไม่หยุดนิ่งอยู่เสมอ และทางผู้บริหารก็ได้เปิดโอกาสให้เราจับแนวคิดมาผลิตเป็น Product ใหม่ๆ ออกมาให้ลูกค้าได้ทดลองใช้กัน รวมไปถึงการพัฒนา MAKE by KBank แอป Mobile Banking เพื่อคนรุ่นใหม่ขึ้นมาให้สามารถตอบโจทย์ลูกค้าได้หลากหลายขึ้น ซึ่งกระบวนการในการทำ Product นี้มีหลากหลาย ตั้งแต่การทำ User Research (สามารถอ่านรายละเอียดเพิ่มเติมได้ใน Ep.1) ไปจนถึงการสร้าง IT Infrastructure ที่ทำให้การใช้งานของแอปทำงานได้ดีที่สุด
MAKE by KBank มีแนวคิดที่แตกต่างจาก Mobile Banking อื่นๆ เนื่องจาก Product ตัวนี้จะเน้นหนักไปในด้านของ Experimental Banking หรือการทดลองสิ่งต่างๆ ในแอป ไม่ว่าจะเป็นในส่วนของ Design (UX/UI), Technology และ Working Process ทำให้ตัวแอปจำต้องมีความยืดหยุ่นสูงเพื่อรองรับการทดลองเหล่านี้ วันนี้ทางทีม Developer ผู้สร้างแอป Experimental Banking ดังกล่าว ขอมาแชร์ตัวอย่างของ Technology และ Software ที่ใช้ในชิ้นงานนี้ โดยจะขอเล่าในเชิงการทำงานของ Development เพื่อให้เข้าใจได้ง่ายขึ้น แบ่งออก 3 ส่วน คือ Front End, Backend และ Test & Deployment
1. Front End
Flutter
แอป Experimental Banking ตัวนี้จะต้องตอบโจทย์การผลิต Product ที่สามารถ Test & Learn ได้อย่างอิสระและรวดเร็ว ในส่วน Front End หรือหน้าตาของแอปพลิเคชันที่ลูกค้าเห็นและใช้งานจริงนั้น เราจึงเลือกใช้ซอฟต์แวร์ชื่อ Flutter ในการพัฒนา UI เจ้าตัว Flutter นี้ถูกพัฒนาขึ้นโดย Google จากภาษาที่เรียกว่า Dart Software ซึ่งเป็น Software Framework ที่มีบริษัทระดับโลกหลายแห่งเลือกใช้ ไม่ว่าจะเป็น Google, Alibaba Group หรือ Tencent
Flutter มีประโยชน์อย่างไรบ้าง? ต้องเกริ่นก่อนว่าการทำ Front End ในอดีต ทาง Developer ต้องเขียนโค้ดแยกระหว่าง iOS และ Android ความแตกต่างของภาษาในแต่ละ Operating System ทำให้ต้องพัฒนา Business Logic Test ซ้ำซ้อนใน 2 รูปแบบและภาษา หากเกิด Defects ก็ต้องแก้ทั้งสองระบบ ทำให้การทำงานเพิ่มขึ้นเกือบ 2 เท่า
การใช้ Flutter จึงเข้ามาช่วยแก้ไขปัญหาตรงนี้ โดยแทนที่จะต้องมานั่งเขียนหลายภาษา Front End Developer ก็สามารถเขียนเป็นภาษา Hybrid Mobile App Development ที่พัฒนาเพียงครั้งเดียวก็สามารถใช้ได้ทั้ง IOS และ Android เลย นอกจากจะลดการทำงานไปได้เกือบครึ่งหนึ่งแล้ว ยังช่วยให้คนทำงานสามารถควบคุม Business Logic ของแอปได้ในที่เดียว
ในส่วนของแสดงผล Flutter ยังมีฟีเจอร์ปุ่มที่เราเรียกกันว่า Hot Reload เมื่อ UI ของเราเกิดการเปลี่ยนแปลง เราสามารถเปลี่ยนโค้ดใหม่และกดดู Preview ผลลัพธ์แบบเรียลไทม์ได้เลย ช่วยประหยัดเวลาในการพัฒนาขึ้นไปอีก ในกรณีที่เราพัฒนาแอปขนาดใหญ่ บางครั้งอาจจะใช้เวลา Compile นานถึง 30 นาที เราก็สามารถใช้ Hot Reload แก้ปัญหาดังกล่าวได้ นอกจากนี้การ Compile เป็น Native ทำให้ UI Performance Speed เทียบได้กับการพัฒนา IOS และ Android ปกติ พร้อมเพิ่ม Security ตามมาตรฐานซอฟต์แวร์ด้วย จะเห็นว่า Flutter มีข้อดีมากมาย ที่ช่วยให้นักพัฒนาสามารถพัฒนา Product ใหม่ออกสู่ตลาดได้รวดเร็วขึ้น
2. Backend
เราเลือกให้ส่วน Backend ของเราทำงานอยู่บน Google Cloud เพื่อความยืดหยุ่นในการปรับขนาดของแอปและไม่ต้อง Maintain ระบบเอง แต่การนำ Google Cloud มาใช้กับระบบธนาคารก็มากับความท้าทาย เนื่องจากปัจจุบันเซิร์ฟเวอร์ส่วนใหญ่ที่ทางธนาคารกสิกรไทยมีเป็นแบบ On Premise และมีการใช้ Cloud ของเจ้าอื่นอยู่ไม่มากนัก ทำให้การทำ Mobile Banking หรือแอปที่เกี่ยวข้องกับธุรกรรมทางการเงินบน Cloud จะต้องผ่านการประเมินความเสี่ยงอย่างรัดกุม ทั้งในส่วนของการประเมินข้อมูลเกี่ยวกับ Vendor ของ Cloud นั้นๆ ไม่ว่าจะเป็นลักษณะธุรกิจ สัญญาต่างๆ หรือตรวจสอบว่า Security Report ของบริษัทนั้นเป็นอย่างไร นอกจากนี้ยังต้องทำแบบประเมินเพื่อเปรียบเทียบว่าหากใช้ Google Cloud แล้วจะมีความเสี่ยงระดับไหนในด้านต่างๆ ดังนี้
- ด้านการให้บริการลูกค้า (Customer) เช่น การคำนวณจำนวนผู้ใช้บริการของเราและผลกระทบที่อาจเกิดกับคนเหล่านั้น รวมถึงการประเมิน Risk Acceptance
- ด้านการเงิน (Financial) หากการใช้ Cloud นี้ส่งผลกระทบต่อระบบ ทำให้ทำงานไม่ถูกต้อง ต้องประเมินค่าใช้จ่ายออกมาเป็นกี่บาท
- ด้านกฎหมายและกฎระเบียบ (Legal & Compliance)
- ด้านชื่อเสียง (Reputation) ประเมินว่าการใช้ Google Cloud นี้จะส่งผลกระทบทางด้านชื่อเสียงอย่างไรกับธนาคาร เช่น ในเชิงข่าว สื่อมวลชน และอื่นๆ
นอกจาก Google Cloud แล้ว ขอกล่าวถึงซอฟต์แวร์เทคโนโลยีอีก 3 ตัวที่เราเลือกใช้เป็นหลัก คือ Kubernetes, Micro Service, Service Mesh (ISTIO)
Kubernetes
Kubernetes เป็นซอฟต์แวร์อีกตัวหนึ่งจาก Google ทำหน้าที่เป็น Container Orchestration ใช้จัดการและควบคุมการทำงานของ Container หรือศูนย์รวมซอฟต์แวร์และ App Services ต่างๆที่จำเป็นไว้ อย่างที่ทราบกันดีว่าแอป Mobile Banking ประกอบไปด้วย App Services ต่างๆมากมาย ทั้งฟีเจอร์มาตรฐาน (จำพวกโอน เติม จ่าย ถอนเงิน) ไปจนถึงการเพิ่มฟีเจอร์ที่ต้องการวิจัยอีกมาก จึงประกอบไปด้วยหลาย Container เช่นกัน เราสามารถใช้ Kubernetes มาช่วยจัดระเบียบและทำการ Orchestrate หรือจับคู่ Container กับการ Cluster เข้าด้วยกัน ทำให้แอปสามารถทำงานได้ราบรื่น และยังช่วยลดงาน Manual ของนักพัฒนา ลดความผิดพลาดและความซับซ้อนที่จะต้องเขียน Script หลายชุดเพื่อตอบสนองการเพิ่มหรือหดตัวตามจำนวนการใช้งานของลูกค้าที่ใช้แอป ระบบ Kubernetes จะทำการสื่อสารกันระหว่างสิ่งที่เรียกว่า Node (ภาพด้านล่าง) ทำให้ในแต่ละครั้งที่เราต้องการนำ App Services หรืออัพเดตเวอร์ชันใหม่ๆ ใน Container ขึ้นระบบ แต่ละ Node จะสื่อสารกันและนำงานไปรันให้เราเอง
ในแต่ละ Node จะมีสิ่งที่เรียกว่า Pod หรือ ก้อนรวมของ App Services + Volume (Storage) ต่างๆ ที่จำเป็นในการรันแอป ใน Node จึงสามารถรันงานได้หลาย Pod ทำให้ทั้งการ Scale up ง่ายขึ้น และไม่ต้องทำแบบ Manual
Micro Service
เดิมทีเราพัฒนาระบบ Backend โดยรวมบริการทุกอย่างอยู่บนระบบเดียวกัน หรือที่เราเรียกกันว่า Monolithic Architecture ทำให้การ Scale up บางบริการทำได้ยากและใช้เวลานาน ยกตัวอย่างเช่น ในช่วงวันเงินเดือนออก ลูกค้าจะใช้บริการโอนเงินเยอะเป็นพิเศษ เราจึงต้อง Scale Function โอนเงิน แต่เนื่องจากมีระบบอื่นๆอยู่ในที่เดียวกัน เราเลยต้องขยายทุกฟังก์ชันนอกเหนือจากระบบการโอนเงิน ทำให้แก้ไขยากและใช้เวลานาน ในขณะเดียวกัน หากบริการนึงล่ม ก็จะส่งผลกระทบต่อบริการอื่นๆ ทำให้ล่มทั้งระบบ ดังนั้นการใช้งาน Micro Services จึงสามารถช่วยแก้ไขจุดพกพร่องนี้ การทำงานของ Micro Services คือการแตกกระจายแต่ละ Functions หรือ App Services ออกเป็นหลายก้อน โดย API จะเข้ามาเชื่อมต่อทุกบริการด้วยกัน นอกจากนี้ Micro Services ยังมีความยืดหยุ่นสูงและสามารถรองรับการเขียนได้หลายภาษาโปรแกรม
ประโยชน์หลักๆ จากการใช้งานจริงของ Micro Services ที่เราพบมีดังนี้
การกำจัดขอบเขตของปัญหาและ Defects ต่างๆให้เล็กลงและสามารถแก้ไขได้รวดเร็วขึ้น
- การ Build & Deploy ของ App Services แต่ละอันได้ด้วยตัวเอง
- การทำงานของแต่ละ App Services ทำได้ด้วย Process ของตัวเอง
- การเชื่อมต่อ Integrate กับระบบอื่นได้ง่ายขึ้น ผ่าน Interface ที่กำหนด
- การเก็บข้อมูลและมี Database ของตัวเอง ช่วยป้องกันไม่ให้การล่มของ Service บางตัวพาส่วนอื่นล่มตามไปด้วย
การใช้ Micro Services นี้ได้รับความนิยมแพร่หลายทั่วโลก อีกทั้งยังง่ายในการเชื่อมต่อกับบริการใหม่ๆ ของพาร์ทเนอร์อีกด้วย
Service Mesh (ISTIO)
Service Mesh (ISTIO) เป็นอีกหนึ่งซอฟต์แวร์ที่สร้างขึ้นมาเพื่อจัดการการทำงานของ Micro Service Infrastructure ช่วยให้นักพัฒนาสามารถ Set Rule และ Policy ที่เป็น Standard Protocol ไว้ล่วงหน้าได้ ขจัดปัญหาในการที่จะต้องมาแก้ไขโค้ดในแต่ละครั้งที่เกิด Error ในระบบ เป็นวิธีการแก้ไขปัญหาได้แบบ Proactive มากขึ้น ทั้งเรื่องของการติดต่อระหว่างบริการ การจัดการเรื่อง Circuit Breaker และการจัดการเรื่อง Retry ยกตัวอย่างเช่น Service A ต้องการสื่อสารกับ Service B แต่ระบบ B เกิดปัญหา ISTIO จะช่วยในการ Hold Request ไว้ก่อนและ Retry การเรียก Service B มาใช้อีกครั้งเมื่อใช้งานได้โดยอัตโนมัติ ลดการทำงาน Manual และความซับซ้อนในการเขียนโค้ดของแต่ละบริการ ในตัวของเครื่องมือนี้ยังมีระบบ Monitor Performance และ Dashboard เพื่อตรวจเช็คการทำงานต่างๆ ได้ในระบบเดียว อีกส่วนที่สำคัญไม่แพ้กันคือสามารถช่วยเรื่อง Traffic Routing หรือ Dynamic Routing แบ่ง Traffic การใช้งานของแอปแยกเป็นเวอร์ชันได้ เช่น 70% ให้ทำงานบนบริการเวอร์ชัน 1 อีก 30% ให้ทำงานบนบริการเวอร์ชัน 2 เพื่อจัดการและแบ่งจำนวนการโหลดของระบบ ทำให้เราสามารถทดลอง Canary Deployment หรือการขึ้นระบบแบบจำกัดจำนวนและกลุ่มลูกค้าได้
3. Test & Deployment
Canary Deployment
ส่วนสุดท้ายนี้คือการทำ Test & Deployment ซึ่งเทคนิคใหม่ที่ทาง KBTG ใช้ในการทำ Experimental Banking คือ Canary Deployment หรือ การ Rolling out Releases ของแอปเวอร์ชั่นใหม่ๆ โดยจะไม่ Deploy เวอร์ชั่นใหม่ขึ้นให้ลูกค้าทั้งหมด แต่เป็นการเลือกกลุ่มเป็น Batch หรือแบ่งตามจำนวนและกำหนดกลุ่มลูกค้าที่จะได้ลองใช้แอปก่อน ที่มาของการใช้วิธีการนี้คือแต่เดิมการอัพเดต Service ในแอปเป็นเวอร์ชั่นใหม่แต่ละครั้ง ถ้าเกิดปัญหาไม่ว่าจะเป็นตัว Coding หรือระบบต่างๆ ก็จะส่งผลกระทบต่อลูกค้าในวงกว้าง แต่การใช้วิธีการใหม่นี้จะช่วยให้เราจำกัดปัญหาดังกล่าวได้ ทั้งยังตรงกับคอนเซ็ปต์ Experimental ของแอปใหม่นี้ด้วยเช่นกัน การใช้ Canary Deployment จะสามารถเลือกกลุ่ม Pilot เพื่อทดลองประสบการณ์ของฟีเจอร์ใหม่ ซึ่งซอฟต์แวร์ที่เราเลือกใช้ คือ Spinnaker ที่จะช่วยทำสรุปผล App Performance เป็น Automated Canary Analysis และยังช่วยในการเปรียบเทียบผลกับเวอร์ชั่นเก่า
ประโยชน์ที่สำคัญของ Canary Deployment คือนักพัฒนาสามารถทำการตั้งค่า Routing Ratio เพิ่มขึ้นเรื่อยๆ ได้ เลือกได้ทั้งเวลาของการ Deploy เวอร์ชั่นใหม่ จาก 0% ถึง 100% ยกตัวอย่างเช่น การตั้งค่าให้ Deploy ขึ้นวันละ 10% ทุกๆ วัน จนครบ 100% นั่นหมายความว่าวันที่ 10 ลูกค้าทุกคนที่ใช้แอปจะได้ใช้เวอร์ชันใหม่ ในทางกลับกันก็สามารถตั้งค่าให้ลดการ Rolling out เมื่อพบปัญหาระหว่างทางได้ เช่น ถ้าลูกค้าใช้แล้วไม่ดี ก็จะหยุดการให้อัพเดต กลับมาแก้ไขปัญหาระบบก่อน และทำการ Deployment ใหม่อีกครั้ง ท้ายสุดคือเราสามารถทำ A/B Testing ด้วยการเชื่อมต่อกับ Firebase Remote Config ที่สามารถเลือกกลุ่มลูกค้าเพื่อเทสการเห็นหน้าจอและฟีเจอร์ที่แตกต่างกัน ทำให้เราสามารถปรับแอปได้ตามความต้องการของลูกค้า
ทั้งหมดนี้เป็นเพียงการไฮไลต์ Technology & Software Tool ส่วนหนึ่งที่ KBTG นำมาใช้ในการพัฒนาแอป MAKE by KBank ของเรา ยังมีเครื่องมืออื่นๆ อีกมากมายที่อาจจะนำมาเล่าให้ฟังกันอีกในอนาคต ทั้งนี้เราหวังเป็นอย่างยิ่งว่าการใช้ New Technology ดังกล่าวจะมอบประสบการณ์ที่ดีที่สุดและตอบโจทย์การใช้ของลูกค้าได้อย่างรอบด้าน ขอให้ทุกคนอดใจรอแอป Mobile Banking ตัวใหม่นี้กันด้วยนะครับ
