แชร์เรื่องนี้
โดย Seven Peaks เมื่อ 22 ธ.ค. 2021, 10:43:00
เมื่อวันที่ 8 ธันวาคม 2021 Seven Peaks Software ได้จัดงาน meetup ทั้งในรูปแบบออนไลน์และใช้ออฟฟิศของเราเป็นสถานที่จัดงาน ในหัวข้อเกี่ยวกับตัวอย่างการพัฒนาระบบคลาวด์และ API สำหรับธนาคาร ซึ่งหัวข้อที่เราเลือกนำเสนอคือการพัฒนา API โดยมีวิทยากร 3 ท่านที่เป็นผู้เชี่ยวชาญด้านคลาวด์ที่จะมามอบความรู้และถ่ายทอดประสบการณ์ให้คุณได้รับทราบถึงแนวทางการพัฒนาระบบคลาวด์ให้ประสบความสำเร็จ
สรุปสาระสำคัญจากงาน meetup – การบริหารจัดการ API ของ Azure และตัวอย่างการใช้งาน API ในธุรกิจธนาคาร
งาน meetup ครั้งนี้เปิดงานโดยคุณ Satish Kamalchand Dadha ซึ่งเขาเป็น Senior Specialist ที่เน้นการสร้างนวัตกรรมดิจิทัลและแอปพลิเคชันที่ Microsoft โดยมานำเสนอแนวทางการบริหารจัดการ Azure API และการนำ API ไปใช้ในธุรกิจธนาคาร
เซสชันของเขาเน้นการพูดถึงการนำ API ไปใช้กับธุรกิจธนาคารและบริการทางการเงิน ขีดความสามารถที่ควรพิจารณาในโซลูชันบริหารจัดการ API และภาพรวมของโซลูชันบริหารจัดการ API ของ Azure
ในการบรรยายครั้งนี้ คุณ Satish ได้ลงลึกถึงสาเหตุว่าทำไมองค์กรมากมายจึงควรพิจารณาถึงการลงทุนด้านโซลูชันบริหารจัดการ API
เขาได้พูดต่อถึงสิ่งที่จำเป็นต้องคำนึงถึงในการบริหารจัดการ API ขีดความสามารถที่ควรมองหาในโซลูชันบริหารจัดการ API มีอะไรบ้าง และเมื่อมีการสร้างเคสขึ้นมาด้วยชุดเครื่องมือบริหารจัดการ API แล้ว มันควรมีความสามารถแบบไหนบ้าง นอกจากนั้นเขายังพูดถึงการตรวจสอบความสามารถและข้อเสนอด้านการบริหารจัดการ API อีกด้วย
ในตอนท้าย คุณ Satish สรุปการบรรยายของเขาด้วยเคสการใช้งานจริงของ API ในธุรกิจธนาคารจากมุมมองของบริการด้านการเงิน
แล้วทำไมองค์กรของคุณถึงควรพิจารณาถึงการลงทุนด้านการบริหารจัดการ API กันล่ะ?
เมื่อองค์กรลงทุนในโซลูชันการบริหารจัดการ API พวกเขาต้องการลงทุนโดยการนำเสนอความสามารถทางธุรกิจด้วย API ซึ่งช่วยให้พวกเขาขยายขีดความสามารถทางธุรกิจได้
ดังนั้น ถ้าสมมติว่าธุรกิจของคุณคือธนาคาร ร้านค้า โรงแรม ธุรกิจท่องเที่ยว และคมนาคม เมื่อธุรกิจต้องการเริ่มนำเสนอความสามารถหลักๆ API จะช่วยเปิดโอกาสในการสร้างพันธมิตรทางธุรกิจได้ ซึ่งสำคัญมากในยุคปัจจุบัน เนื่องจากมีหลายสิ่งหลายอย่างรอบตัวเราที่กำลังเปลี่ยนไปทำงานบนแอปฯ เป็นหลัก
เมื่อธุรกิจเริ่มเปิดเผยว่าใช้ API เป็นเครื่องมือหลักในการให้บริการ สิ่งนี้ได้ช่วยเปิดโอกาสในการเป็นพาร์ตเนอร์กับสตาร์ตอัปด้วยการสร้างแอปฯ จากนั้นก็จะเพิ่มขีดความสามารถให้ธุรกิจได้ ซึ่งเป็นสิ่งที่สำคัญอย่างยิ่ง
ในประเด็นต่อไป Satish ได้อธิบายว่ามีขีดความสามารถแบบใดที่จำเป็นต้องนำมาพิจารณาบ้าง ซึ่งแนวทางการบริหารจัดการ API แบบใดก็ตามที่มีคนใช้งานมากทั้งในด้านของลูกค้าและพาร์ตเนอร์ ก็ถือว่าแนวทางนั้นประสบความสำเร็จ.
ดังนั้น เราต้องระวังหรือรู้อยู่เสมอว่าผู้บริโภคคาดหวังอะไรจาก API ซึ่งการที่แนวคิดการบริหารจัดการ API จะประสบความสำเร็จได้นั้นจำเป็นต้องรู้ก่อนว่าผู้บริโภคและผู้ให้บริการ API มีความคาดหวังอย่างไรบ้าง
ความคาดหวังของผู้บริโภค API
- นักพัฒนาจะค้นหา API ได้อย่างไรบ้าง
- นักพัฒนาจะสมัครการใช้งาน API อย่างไร
- สามารถทดลองใช้ API ก่อนลงทุนลงแรงใช้งานจริงได้หรือไม่
- มีเอกสารคู่มือไหม
- API มีสิ่งที่ผู้บริโภคต้องการมองหาหรือเปล่า หรือผู้ให้บริการสามารถทำอะไรได้บ้าง
ความคาดหวังของของผู้ให้บริการ API
- ตัวเลือกในการสร้าง API ด้วยการทำงานแบบอัตโนมัติ การแสดงผล และการเขียนโค้ด
- Lifecycle และ governance สำหรับ API และสินค้า
- ควบคุมการเข้าถึงข้อมูลของ API และผลิตภัณฑ์ต่างๆ ของ API
- มี Developer Portal แบบบริการตัวเองที่ปรับแต่งได้ตามต้องการสำหรับการเผยแพร่และใช้งาน API
- มีนโยบายในการดูแลรักษาความปลอดภัย
- ระบบวิเคราะห์การใช้งาน API ขั้นสูง
- รองรับรูปแบบ hybrid-cloud, multi-cloud, และ on-premise
- สามารถปรับขยายได้ตามต้องการ
ระบบบริหารจัดการ API ของ Azure ประกอบด้วย 3 องค์ประกอบต่อไปนี้
- API – Management Plane
- Developer portal – User Plane
- Gateway – Data Plane
การออกแบบบนพื้นฐานของ API
วิทยากรคนต่อไปคือ คุณ Bjorn Harvold ซึ่งเป็น co-founder ของ iko.travel และ TripPay ซึ่งเป็นแพลตฟอร์ม inventory distribution และการชำระเงินสำหรับธุรกิจท่องเที่ยว ที่จะมาพูดถึงเรื่องการออกแบบบนพื้นฐานของ API ในเซสชันนี้เขาจะเน้นนำเสนอโดยใช้ API เป็นตัวอธิบายเป็นหลัก เพื่อเป็นแนวทางที่จะ ช่วยให้ธุรกิจและพาร์ตเนอร์สามารถเติบโตได้.
คุณ Bjorn เริ่มการบรรยายด้วยการอธิบายว่า การออกแบบบนพื้นฐานของ API คืออะไร ต่อด้วยการสาธิตการทำงาน และปิดท้ายด้วยการพูดถึงวงจรชีวิตของ API ประเด็นแรกที่เขาพูดถึงคือ HATEOAS หรือ hypermedia as the engine of application stateที่ทำให้คอมพิวเตอร์สามารถทำความเข้าใจ API ได้โดยไม่ต้องสร้างเอกสารเกี่ยวกับ API ขึ้นมา
ดังนั้น HATEOAS จึงเป็นสิ่งที่มีประโยชน์มาต่อคอมพิวเตอร์ จากนั้นต้อด้วย verb ซึ่งมี verb บางอย่างที่คุณ Bjorn พูดถึง ได้แก่
ต่อมา เขาก็ได้อธิบายถึง error code ซึ่งได้แก่
100x คือ informational code ที่แสดงข้อมูลการตอบสนอง 200x เป็น success code ซึ่งหมายถึงทุกอย่างทำงานได้เรียบร้อยดี ส่วน 300x คือ redirect code ที่บอกว่ามีบางอย่างเปลี่ยนแปลง และจำเป็นต้องอัปเดต URL ไปยังที่ที่กำหนด ทั้งนี้ 400x หมายถึงเกิดข้อผิดพลาดขึ้นในฝั่ง client และสุดท้ายคือ 500x ที่หมายถึงมีข้อผิดพลาดในฝั่งเซิร์ฟเวอร์
GraphQL หรือ rest API ก็ยังคงเป็นตัวเลือกที่ดี เทคโนโลยีทุกอย่างมีรูปแบบการใช้งานของตัวมันเอง และเจ้าสิ่งนี้ก็เหมาะมากสำหรับ Facebook นั่นจึงเป็นสาเหตุว่าทำไมมันถึงถูกสร้างขึ้นมา ซึ่งก็เพื่อนำมันมาใช้ในการแยกข้อมูลและอาจเป็นประโยชน์อย่างยิ่งสำหรับบางแอปพลิเคชัน นักพัฒนาอาจต้องมีการเรียนรู้เพิ่มเติมเล็กน้อย แต่ก็สามารถนำไปใช้งานได้ง่ายๆ
มาถึงเรื่องของวงจรชีวิต API ซึ่งมีบางแง่มุมที่คุณจำเป็นต้องทำความเข้าใจ ได้แก่
- การแก้ไข/เลิกใช้งาน: features, entities, format
- การกำหนดเลขเวอร์ชัน – พิจารณาถึงเรื่องของ backwards compatibility, decouple storage/conceptual model
- URL-based เช่น /v1/ => /v2/
- Header based: Accept / Content-Type: application/vnd.my-product-v1+json
Custom: “my-product-version” – 1
คุณสามารถอ่านรายละเอียดเพิ่มเติมเกี่ยวกับการบรรยายของ Bjorn ได้ที่ลิงก์ข้างล่างนี้
https://github.com/bjornharvold/pizza-delivery-network
การติดตามผลและเก็บ log ของ API
วิทยากร 2 ท่านสุดท้ายของงาน meetup ครั้งนี้เป็นผู้เชี่ยวชาญด้านระบบคลาวด์ที่ Seven Peaks Software ซึ่งได้แก่คุณ Giogio Desideri and Nicolas Piersen ในหัวข้อ การติดตามผลและเก็บ log ของ API
เซสชันนี้เน้นไปที่เรื่องของการเก็บ log, การ trace, และการติดตามผล เนื่องจากแง่มุมที่สำคัญที่สุดของการพัฒนา API โดยเฉพาะอย่างยิ่งในโลกที่ขับเคลื่อนด้วย microservice นั้น การทำความเข้าใจ message flow, ธุรกรรมที่เกิดขึ้น, และกระบวนการประมวลผลของคอมพิวเตอร์ นั้นสำคัญมาก เนื่องจากเราต้องควบคุมและติดตามผลแอปพลิเคชันอยู่เสมอ
เราสามารถบรรลุเป้าหมายนี้ได้อย่างง่ายดายด้วย Azure Application Insight และบริการจากคลาวด์ที่ทำให้เรามีฟีเจอร์ดีๆ ไว้ช่วยให้เราไม่ต้องเปลืองแรงและประหยัดเวลาได้เป็นอย่างดี
เอาละ มาดูกันว่า เราสามารถติดตามข้อมูลของทุกสิ่งทุกอย่างได้อย่างไร และเราจะมั่นใจได้อย่างไรว่าผู้ใช้ของ API นั้นยังคงได้รับข้อมูลที่ต้องการและ API ยังทำงานได้ดีอยู่ หรือผู้ใช้สามารถเข้าถึงไฟล์เอกสารในบัญชีของพวกเขาได้หรือไม่ ก่อนที่จะไปพบคำตอบ คุณต้องทำความเข้าใจเอกสารสัญญาและข้อตกลงกันก่อน ซึ่งแบ่งออกเป็น 3 แบบ ได้แก่ SLA, SLO, และ SLI
SLA = Service Level Agreements คือข้อตกลงที่ระบุและบังคับใช้กับผู้ใช้แบบเปิดเผยต่อสาธารณะ
- ผู้ใช้สามารถเป็นได้ทั้งลูกค้า ภายใน หรือจากภายนอก
- ข้อตกลงอาจรวมถึงผลกระทบทางเศรษฐกิจ
SLO = Service Level Objectives คือวัตถุประสงค์ที่กำหนดระดับของการให้บริการ
- วัตถุประสงค์แต่ละข้ออาจวัดผลโดยตัวชี้วัด
SLI = Service Level Indicators คือหน่วยวัดที่ระบุว่าบริการนั้นๆ มีคุณภาพดีแค่ไหน
- Latency
- การใช้งานพื้นที่บนดิสก์
- CPU
- อื่นๆ
พีระมิดแบ่งออกเป็น 3 ส่วน ได้แก่ การวิเคราะห์ การติดตามผล และ observability หรือการตรวจสอบ การวิเคราะห์ผลนั้นใช้ทั้งการติดตามผลและตรวจสอบเพื่อที่จะทำความเข้าใจว่าสถานะของแพลตฟอร์มเป็นอย่างไร
การติดตามผลนั้นคือการระบุข้อมูลที่จะช่วยให้คุณสามารถป้องกันไม่ให้เกิดปัญหาได้ ซึ่งสามารถทำได้ด้วยการรวบรวมมุมมองของข้อมูล จนเกิดเป็นมุมมองแบบ 360 องศา
การตรวจสอบคือการสร้างและรวบรวมข้อมูลจนเพียงพอเพื่อที่จะรู้ว่าสถานะของระบบนั้นเป็นอย่างไร ซึ่งการตรวจสอบนั้นแบ่งออกเป็น 3 องค์ประกอบ ได้แก่ การเก็บ log, หน่วยชี้วัด, และการ trace
คุณอาจจะสงสัยว่า แล้วเป้าหมายของการติดตามผลคืออะไร ซึ่งเป้าหมายนั้นได้แก่
จากหน่วยชี้วัดและ log ที่รวบรวมมา เราสามารถระบุข้อมูลที่สำคัญแล้วนำมาจัดกลุ่มตามรูปแบบการใช้งานได้
- มุมมองสำหรับการบริหารจัดการต้นทุน
- มุมมองสำหรับการบริหารงานฝ่ายผลิต (ขีดความสามารถ, ปัญหาคอขวด)
- มุมมองสำหรับการติดตามผลการทำงานแอปพลิเคชัน (ความสามารถในการรองรับ queue, จำนวนของการทำซ้ำ)
- การเข้าถึงข้อมูลต้องปกป้องด้วยการกำหนดบทบาทหน้าที่และการอนุญาตการเข้าถึง
แนวทางการปฏิบัติที่เหมาะสมในการติดตามผล ได้แก่
- สร้างแดชบอร์ดเฉพาะขึ้นมาบนแพลตฟอร์ม เนื่องจากการนำแดชบอร์ดจากหน่วยชี้วัดอื่นมาใช้ซ้ำอาจทำให้ผู้ใช้เข้าใจข้อมูลคลาดเคลื่อน
- ปรับเปลี่ยนและสร้างแดชบอร์ดขึ้นมาหลายอันหากจำเป็น
- ควรเข้าถึงข้อมูลบนแดชบอร์ดได้ง่าย
ต่อมาในเรื่องการเก็บ log คุณอาจสงสัยว่า log คืออะไร ซึ่งอาจทำความเข้าใจได้จากประเด็นต่อไปนี้
- เป็นการสร้างข้อมูลขึ้นมาระหว่างการประมวลผล ซึ่งข้อมูลนี้ควรจะเพียงพอต่อการทำความเข้าใจว่าเกิดอะไรขึ้นบ้าง (เจาะจงถึงการใช้งาน ไม่ว่าจะเป็นด้านการพัฒนา หรือการผลิต)
- อ่านง่าย
- สามารถกรองข้อมูลได้ง่าย (จาก correlation id, ระดับ, และ service ต่างๆ)
- สามารถลบทิ้งหรือ archive ได้ตามต้องการ
- ปลอดภัย
การเก็บ log คือข้อมูลที่ซอฟต์แวร์สร้างขึ้นเพื่อบอกว่าเกิดอะไรขึ้นบ้างระหว่างกระบวนการทำงาน
ทีนี้มาดูกันว่าเราควรเก็บ log อย่างไรให้มีประสิทธิภาพ มีอยู่หลากหลายวิธีที่สามารถทำได้
ซึ่งแนวทางปฏิบัติที่แนะนำได้แก่
- ห้ามเก็บข้อมูลส่วนตัว (เช่น ชื่อ, นามสกุล, ทะเบียนรถ, หมายเลขประกันสังคม เป็นต้น)
- เก็บ log ทุกอย่างที่เข้าไปหรือออกมาจากแพลตฟอร์ม (เช่น service หรือ request จากภายนอก)
- ใช้ decorator pattern ในการ implement log จาก request ทั้งขาเข้าและขาออก
- เมื่อถึงขั้นตอน debug ในกระบวนการพัฒนา พยายาม debug โดยไม่ต้องดูโค้ด
- ระดับในการทำงานคือ การ trace, การ debug, การแจ้งข้อมูล, การแจ้งเตือน, และการแจ้งข้อผิดพลาด
นอกจากนี้ยังกำหนดโดยสิ่งต่อไปนี้
- นำตัวเลขไปใส่ในกระบวนการทำงานที่ผ่านการ implement ซึ่งหน่วยชี้วัดจะสร้างขึ้นในหลายๆ ระดับตั้งแต่ระดับสถาปัตยกรรม ไปจนถึงระดับแอปพลิเคชัน
- ตรวจจับการใช้งานต่ำกว่าขีดจำกัดและปัญหาคอขวด
- ตัดสินใจดำเนินการจากข้อมูลที่จับต้องได้เมื่อต้องการปรับปรุงประสิทธิภาพการทำงาน
- ประหยัดต้นทุนในการทำงานของแพลตฟอร์ม
แนวทางปฏิบัติที่เหมาะสมได้แก่สิ่งต่อไปนี้
- สร้างหน่วยชี้วัดให้มากที่สุดเท่าที่จะเป็นไปได้ เพราะมันจะช่วยให้คุณเข้าใจแพลตฟอร์มได้ดีขึ้น
- Instrumentation เป็นสิ่งที่ถูกประเมินค่าต่ำกว่าที่ควรจะเป็น ซึ่งมันสามารถสร้างคุณค่าได้มากมาย และทำให้เราเข้าใจกระบวนการทำงานของแอปพลิเคชันได้่
อันดับสุดท้ายคือการ trace ซึ่งหมายถึง การเชื่อมโยงหน่วยชี้วัดและ log เข้าด้วยกันในบริบทใดบริบทหนึ่ง เช่น request เป็นต้น
การ trace นั้นเป็นตัวแทนของชุด event ที่แจกจ่ายออกไปและมีความสัมพันธ์กันแบบหลวมๆ โดยมีหน้าที่เข้ารหัสโฟลว์ของ end-to-end request ผ่านทางระบบที่ทำการแจกจ่ายข้อมูล
เมื่อทำการ trace แล้ว เราก็ต้องนำแนวทางปฏิบัติที่เหมาะสมมาใช้ นั่นก็คือ นำการ trace มา implement ตั้งแต่ตอนเริ่มโปรเจกต์ ซึ่งจะส่งผลต่อ interface contract