สรุปสิ่งที่ได้เรียนรู้จากงาน AWS Cloud Day Thailand (ส่วน Developer Lounge)

เมื่ออาทิตย์ก่อนได้มีโอกาสเข้าไปร่วมงาน AWS Cloud Day Thailand ที่เป็นการรวมกันของฝั่ง business และ technical ในการใช้งาน Amazon Web Services (AWS) เพื่อสร้างนวัตกรรมใหม่ ๆ ในงานก็จะมีกิจกรรมและการแบ่งปันประสบการณ์ในการใช้งาน AWS โดยส่วนใหญ่ก็จะเน้นเรื่องที่เป็น trend อยู่ในขณะนี้อย่าง Serverless, Machine learning (ML), Generative artificial intelligence (AI) นอกจากนี้ก็จะมี booth ต่าง ๆ ตามความสนใจของเรา เช่น game, startup, เรียนรู้ฝึกการใช้งาน AWS หรือ software development เป็นต้น

Session ช่วงเช้า

โดยใน session ช่วงเช้าก็จะมีการพูดถึง use case ของบริษัทในแถบ South East Asia ที่นำ AWS ไปใช้งานจริง เช่น

• SCG นำ AWS Internet of Things ไปใช้ทำ smart home (ปล. ทาง CEO บอกว่า IoT จะแซง application development ในอนาคต รีบเข้าไปศึกษาก่อนจะได้เปรียบ)
• เงินเทอร์โบ นำ AWS ไปทำ analytics สำหรับดูความเสี่ยงในการปล่อยสินเชื่อแบบ data-driven
• 2C2P นำ AWS ไปใช้ในด้าน payment, security, data analytics และ observability

ต่อมาก็เป็น session ในการปล่อยของ AWS ใหม่ ๆ โดยในปีนี้ทาง AWS ก็ได้นำ services ที่มีอยู่แล้วไปพัฒนาให้รองรับ Serverless มากขึ้น เช่น Amazon Aurora (มาในรุ่น Serverless v2) และตระกูล Analytics ต่าง ๆ นอกจากนี้ยังดันเรื่อง services ที่เกี่ยวกับ AI และ ML เต็มตัว โดยเค้ามี service ใหม่ที่รองรับการทำ Generative AI โดยเฉพาะอย่าง Amazon Bedrock (ยังเป็น preview mode อยู่นะ)

นอกนั้นก็เป็นการ showcase ของ partner ของ AWS อย่างเช่น AWS Prime Day, Amazon Go, runway, Canva, autodesk เป็นต้น

Session ช่วงบ่าย

หลังจากพักกินข้าวแล้วก็ต่อกับช่วงบ่ายโดยคนก็จะแยกกันไปตาม booth ต่าง ๆ ไม่ก็เข้าห้องประชุมฟัง session ต่อ โดยเราจะปักหลักอยู่ที่ Developer Lounge โดยมีหัวข้อน่าสนใจมากมาย เราเลยสรุปเท่าที่เราได้เข้าตามนี้

Chalk Talk: Building modern applications? Let’s talk about serverless

ใน session นี้จะเน้นไปที่การใช้ AWS ในการสร้างระบบงานขึ้นมาโดยยังคงเน้นไปในด้าน serverless อย่างเช่น Simple Queue Service (SQS), Simple Notification Service (SNS), EventBridge และ Lambda เป็นต้น และมีการยกตัวอย่างระบบงานสมมติขึ้นมาแล้วช่วยกันออกแบบโดยใช้ AWS services ต่าง ๆ โดยเราสามารถเข้าไปศึกษาและดูตัวอย่างของระบบ serverless เพิ่มเติมได้ผ่าน https://serverlessland.com

Serverless Land

Practical cost-saving automation for AWS accounts

ผู้พูดได้เล่าถึงประสบการณ์ในการจัดการค่าใช้จ่ายใน AWS ซึ่งเป็นหนึ่งในความเจ็บปวดที่คนหรือองค์กรที่ใช้ AWS ต้องเคยพบเคยเจอ โดย resource ที่กินค่าใช้จ่ายเยอะที่สุดได้แก่ Elastic Compute Cloud (EC2 และ EC2 serverless), Elastic Container Service (ECS) และ Elastic Kubernetes Service (EKS) และกลุ่ม database (SQL vs NoSQL) ซึ่งค่าใช้จ่ายจากทุก resource ที่ไม่จำเป็นมาจากหลายสาเหตุด้วยกัน ได้แก่

• Overprovisioning: สร้าง resource ที่มีขนาดใหญ่หรือเยอะเกินที่จะใช้จริง
• Un-tag resources: มี resource ที่อยากจะลบเพราะไม่ได้ใช้แล้วแต่ลบไม่ได้เพราะไม่รู้ว่าเป็นของใคร
• Idle resources: มี resource ที่มีเจ้าของแต่ใช้แค่บางเวลาเท่านั้น เช่น ตอนเวลาทำงาน แต่หลังเลิกงานก็ปล่อยทิ้งไว้ข้ามคืน ไปจนถึง เสาร์-อาทิตย์

แนวทางการลดค่าใช้จ่ายสามารถทำได้หลายทาง เช่น

• Economies of scale: ยิ่งใช้งานเป็นจำนวนเยอะ ๆ ค่าใช้จ่ายต่อหน่วยการใช้งานก็จะยิ่งถูกลง
• Architecture: ปรับระบบงานและเลือกใช้ technology ที่เหมาะสมกับ scale ของงาน
• Operation: การจัดการ resource ซึ่งอันนี้คือแนวทางที่เราจะเน้นในหัวข้อนี้

ผู้พูดได้เสนอวิธีแก้ปัญหาด้วยการใช้ AWS ดังนี้

1. สร้าง Maintenance Window หรือ Automation Documents บน AWS Systems Manager เพื่อทำการลบทุก resource ที่ไม่ติด tag หรือไม่ได้ใช้แล้ว
2. ใช้ Run Command บน AWS Systems Manager เพื่อทำการ scale EC2 ลงหลังเวลาเลิกงานบนบาง environment
3. ตรวจสอบและปรับการใช้งาน EC2 ผ่าน AWS Compute Optimizer เพื่อเลือกราคาและ performance ของ EC2 ที่เหมาะสม
4. ตั้งเวลา scale ตามต้องการผ่าน AWS Instance Scheduler สำหรับ EC2
5. เปิดใช้งาน Application Auto Scaling สำหรับ Fargate

Implementing DevOps to deploy and run web applications on AWS

ผู้พูดได้แนะนำให้รู้จักกับ JavaScript library สำหรับสร้าง static website อย่าง Nuxt ที่พัฒนาต่อยอดจาก Vue.js อีกที โดยเราสามารถสร้างและแน่นอนว่าเราสามารถ deploy static website ด้วย AWS มีขั้นตอนประมาณนี้

Workflow ของระบบงาน static website คร่าว ๆ

โดยปกติแล้ว entrypoint ของ S3 จะเป็น HTTP ซึ่งไม่ปลอดภัย เราสามารถใช้ AWS ในการทำให้ระบบงานของเราเป็น production grade โดยใช้ services ต่าง ๆ ดังนี้

• ใช้ AWS Certificate Manager ในการสร้าง SSL certification
• เก็บ certification ไว้ใน AWS Cloudfront เพื่อส่งให้ server
• จด domain ผ่าน AWS Route 53 แล้วชี้ไปที่ AWS CloudFront
• ด้าน security เราก็จำกัด การเข้าถึง AWS S3 เป็น private access หรือถ้าจำเป็นต้องใช้ public access จริง ๆ ก็ให้ใช้ท่าตั้งค่า BucketPolicy ด้วย aws:Referer
• ตั้งค่า retention ใน AWS S3 เพื่อลบ artifact ที่ไม่ได้ใช้แล้วออกไป

เข้าไปดูตัวอย่าง code ได้ที่ https://github.com/jumpbox-academy/cloud-day

GitHub - jumpbox-academy/cloud-day

Unveiling Saga Pattern: A beginner’s exploration into Microservices orchestration

ใน session นี้จะเป็นการแบ่งปันเรื่องของ Saga pattern โดยเมื่อเราพูดถึงระบบงานที่มี database ในการเก็บข้อมูล จะต้องมีคุณสมบัติ 4 ข้อ ACID

• Atomicity: ถ้ามีการบกพร่องหรือข้อผิดพลาดเกิดขึ้นกลางทาง การทำงานทั้งหมดในรายการ (transaction) จะถูกยกเลิก และไม่มีการเปลี่ยนแปลงใด ๆ ใน database
• Consistency: หลังจากที่การดำเนินการ (operation) ของ transaction เสร็จสมบูรณ์ database จะต้องเข้าสู่สถานะที่สอดคล้องกันหรือแสดงผลถูกต้อง
• Isolation: operation ของ transaction หนึ่งจะไม่ส่งผลกระทบต่อ operation ของ transaction อื่น
• Durability: หลังจากที่ operation ทุกอันของ transaction เสร็จสมบูรณ์ การเปลี่ยนแปลงจะถูกเก็บไว้ใน database โดยถาวร แม้ว่าระบบจะเกิดความขัดข้องข้อมูลก็จะไม่หายไป

ซึ่งแนวทางการสร้างระบบงานตามคุณสมบัตินี้ก็ขึ้นอยู่กับการออกแบบ architecture ด้วย หากเป็นลักษณะแบบ monolith การใช้งาน database transaction ก็จะตอบโจทย์นี้ได้ แต่เนื่องจาก monolith มีข้อจำกัดเพื่อระบบมีความซับซ้อนขึ้น การ scale ก็จะทำได้ยากขึ้น ปรับแก้ได้ยากชึ้น เมื่อเกิดปัญหาขึ้นที่จุดใดจุดหนึ่งก็มีโอกาสสูงที่ระบบจะพังทั้งหมด จึงมีแนวคิดเรื่องของ microservices ขึ้นมาแก้ปัญหาดังกล่าว

Microservices from https://martinfowler.com/articles/microservices.html

แต่การวางระบบในรูปแบบ microservices ก็แลกกับการจัดการที่ซับซ้อนขึ้น เช่นการ deploy, การ monitor, การจัดการ infrastructure และแน่นอนว่ารวมถึงคุณสมบัติ ACID ด้วย เช่น

• เราจะรักษาคุณสมบัติ Atomicity และ Isolation ไว้ได้อย่างไรในเมื่อระบบมี database มากกว่า 1 อันแล้ว
• Logic ในการร้อยเรียง operation ของระบบจะอยู่ตรงไหน

โดยปัญหาดังกล่าวส่วนใหญ่มักจะเกิดขึ้นในระบบงานที่ใช้เวลานานกว่าจะจบ business operation นึงอย่างเช่น ระบบ e-commerce, ระบบ food delivery เป็นต้น

Saga pattern ตอบโจทย์เรื่อง Atomicity ว่าในการทำ operation ต่อ ๆ กัน ถ้ามี operation ใด ๆ อันหนึ่งมันผิดพลาดเกิดขึ้นกลางทาง ระบบของเราจะย้อนการเปลี่ยนแปลงจะถูกเก็บไว้ใน database เหล่านั้นกลับโดยสร้าง transaction อีกรูปแบบนึงแยกออกมาต่างหากเพื่อทำการหักล้างสิ่งที่เกิดขึ้นจาก transaction แบบปกติ (เรียกว่า compensating transaction) เช่น ในระบบ food delivery หาก operation ในการจัดการอาหารมีปัญหาอย่างร้านดันปิดไปหลังจากกดสั่ง order ไปแล้ว ตัว compensating transaction ก็จะประกอบด้วย operation ที่ต้องยกเลิก order ของเราและคืนเงินที่โอนไป

การออกแบบ compensating transaction ก็จะขึ้นอยู่กับลักษณะของ operation ด้วย เช่น

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

ข้อสำคัญที่สุดของ operation คือไม่ว่า operation ข้อมูลเดิมจะเกิดขึ้นกี่ครั้งซ้ำ ๆ กันกี่ครั้งก็ตาม ผลลัพธ์ก็จะต้องได้เท่าเดิม (เรียกว่า idempotent) เพื่อที่จะทำให้ operation สามารถทำซ้ำ (retry) ในกรณีที่เกิดปัญหาได้

ทีนี้ Saga pattern ก็ยังไม่ตอบโจทย์เรื่อง Isolation เพราะปัญหาที่เจอใน database transaction ก็จะมาเจอใน Saga pattern เช่น dirty reads, lost updates, non-repeatable reads ซึ่งเราก็ต้องใช้ท่าอื่น ๆ มาช่วย เช่น

• Semantic locks: เก็บสถานะไว้ข้อมูลเพื่อจำกัดให้มี transaction เดียวที่สามารถแก้ไขข้อมูลแล้วเปลี่ยนแปลงสถานะได้ เช่น ในระบบจองที่นั่งดูหนังที่ให้จองที่นั่งได้ทีละคน หากจองที่นั่งแล้วใน database ก็จะตั้งสถานะในข้อมูลเป็น RESERVATION_PENDING ทำให้คนอื่นไม่สามารถจองที่นั่งนี้ได้ แต่ถ้าไม่สามารถจ่ายเงินภายในเวลาที่กำหนดก็จะปลดสถานะออกเพื่อให้คนอื่นมาจองแทน
• Pessimistic view: คล้าย ๆ กับ Semantic locks แต่ใช้ database lock เฉพาะ row หรือทั้ง table ไปเลย
• Commutative updates: ทำให้ operation สามารถทำสำเร็จได้โดยสุดท้ายแล้วจะได้ผลเท่ากันแม้ว่าลำดับจะเป็นอย่างไรก็ตาม เช่น ในระบบสมาชิกสะสมแต้ม การใช้คูปองส่วนลดและการสะสมแต้มเพิ่มสามารถทำสลับกันได้เพราะสุดท้ายแล้วผลลัพธ์ก็ได้เท่ากัน
• Rereading value: นำข้อมูลที่อ่านออกมาครั้งแรกมาเทียบกับข้อมูลที่อ่านออกมาก่อนจะทำการ update ว่ามันต่างกันไหม เช่น ในระบบจองห้องโรงแรมที่ให้คนจองห้องพร้อม ๆ กันได้ ก่อนที่ user จะกด confirm การจอง ระบบก็จะไปอ่านข้อมูลก่อนว่าตอนนี้ห้องนั้นยังว่างอยู่ไหม ถ้าไม่ว่างแล้วแปลว่ามีคนอื่นจองไปก่อนหน้านี้แล้ว ระบบก็จะไม่ให้เราจองซ้ำนั่นเอง

ในส่วนของ logic ในการร้อยเรียง flow ของระบบจะอยู่ตรงไหนนั้น ทาง Saga pattern ก็แนะนำแนวปฏิบัติมา 2 วิธีด้วยกันที่ต้องใช้ร่วมกันกับ Event-driven architecture ได้แก่

• Cheoreography: ไม่มีคนคุม workflow ทุกคนรู้หน้าที่ว่าจะต้องทำอะไรเมื่อได้รับ event มา ข้อดีคือทำได้ง่าย ข้อเสียคือถ้า workflow มันซับซ้อนจะยากขึ้น เช่นระบบจะต้องรอ 2 event ที่มาไม่พร้อมกันมารวมกันเมื่อจะได้ทำงานถูก นอกจากนั้นจะต้องระวังเรื่อง cyclic dependencies เพิ่มด้วย

Choreography-based saga

• Orchestrator: มีตัวคุม workflow เพื่อส่งคำสั่งไปให้ service อื่น ๆ ข้อดีคือเหมาะกับ workflow ที่ซับซ้อน ข้อเสียคือทำยาก และอาจจะเกิด single point of failure เพิ่มในส่วนของตัวคุม workflow ได้

Orchestration-based saga

วิธีการแก้ปัญหานอกจาก Saga pattern ก็มี two-phase commit ในทางทฤษฎีคือมันดูดีนะ แต่ทางปฏิบัติจากประสบการณ์ของหลาย ๆ องค์กรคือไม่ค่อย work เพราะในระหว่างที่เวลาระบบแต่ละตัวมันรอให้พร้อม แล้วมันรับ load อื่นไม่ได้ ทำให้เสีย availability ไป

ปัญหาอื่น ๆ ที่จะพบเจอใน Saga pattern คือ states และ event หายไป ซึ่งโจทย์นี้ก็ต้องนำ Outbox pattern มาช่วยแก้ (ขอไม่ลงลึกในบทความนี้)

ปิดท้ายด้วยการแนะนำ framework และเครื่องมือที่ช่วยทำ Saga pattern ให้ง่ายขึ้น อย่าง AWS Step Functions และ Netflix Conductor เป็นต้น

Software craftsmanship

ผู้พูดเล่าเรื่องของความรักและความเป็นมืออาชีพในการพัฒนา software ว่าจริง ๆ แล้ว ทีมพัฒนาต่างหากที่มีอำนาจสูงสุดในการตัดสินใจ ดังนั้นทีมไม่ควรปลุกปีศาจ ความซับซ้อน (complexity) และ technical debt ขึ้นมาโดยที่ไม่รู้ว่าจะควบคุมมันอย่างไร หากมีปัญหาเกิดขึ้นจากทีมนี้และถูกปล่อยหลุดออกมา อาจจะเป็นอันตรายและสามารถก่อให้เกิดความเสียหายได้ ทีนี้วิธีการควบคุมปีศาจเหล่านี้คือการฝึกฝนและลงมือทำเพื่อเวลาลงงานจริงจะมีโอกาสพลาดน้อยที่สุด

แต่ในโลกของการพัฒนา software เวลาลงงานจริงมันเยอะกว่าเวลาฝึกฝน (สมมติทำงานวันละ 8 ชั่วโมง) อย่างน้อยให้เราปันเวลา 2-3 ชั่วโมงต่ออาทิตย์มาฝึกฝนบ้าง แต่สิ่งที่สำคัญไม่น้อยไปกว่าจำนวนวันคือการฝึกฝนอย่างมีคุณภาพด้วย ผู้พูดได้แนะนำ https://exercism.org/ เป็น website สำหรับการฝึกฝนและเรียนรู้การเขียน program จากโจทย์เดียวกันด้วยหลากหลาย programming language ทำให้เราได้เห็นแนวทางการแก้ปัญหาด้วยวิธีการที่ต่างกันไป

Exercism

นอกจากนั้นแล้วเราสามารถฝึกด้วยการเข้ากิจกรรมต่าง ๆ เช่น coding dojo, code retreat, การร่วมเขียนโปรแกรมใน open source project เป็นต้น

ต่อมาคือแนวทางปฏิบัติอื่น ๆ ที่สะท้อนให้เห็นถึงความรักและความเป็นมืออาชีพที่เราสามารถนำไปปรับใช้ได้ทันที เช่น

• รับผิดชอบในงานที่ทำ
• คุณภาพเป็นสิ่งที่ต่อรองไม่ได้ (Quality is not an option)
• หลีกเลี่ยงสร้างสิ่งที่เป็นผลเสียต่อคุณภาพเพื่อไม่ให้คนอื่น ๆ ที่มาเห็นเริ่มทำตาม (No Broken Windows)
• สื่อสารผ่านการเขียน documentation ที่ชัดเจนเข้าใจง่าย

อีกสิ่งหนึ่งที่ผู้พูดฝากไว้คืออย่าปล่อยให้ใครก็ไม่รู้มาดันเราออกจากการเป็น developer ที่เก่ง ๆ ไปเป็น manager ที่ห่วย ๆ โดยไม่เต็มใจเพราะประเทศไทยต้องการ developer ที่แก่ประสบการณ์เยอะกว่านี้

ปิดท้ายบทความนี้ด้วย Manifesto for Software Craftsmanship

ว่าด้วยเรื่อง Software Craftsmanship

สรุป

โดยรวมแล้วงาน AWS Cloud Day Thailand เป็นงานที่ได้สาระความรู้โดยเฉพาะการประยุกต์ใช้งาน AWS ให้เกิดประโยชน์ในระบบงานของเราให้สูงที่สุด

นอกจากเรื่องเกี่ยวกับ AWS แล้ว ขอฝากบทความอื่น ๆ ให้ติดตามกันได้ทั้งภาษาไทยและอังกฤษด้วยนะ ขอบคุณที่เข้ามาอ่านกันนะครับ

NonTechCompany