การดำเนินการ static web app เพื่อติดตั้งบนแอปพลิเคชัน NoSQL ด้วย Azure Cosmos DB

Azure Cosmos DB คืออะไร?

ฟีเจอร์ต่างๆ ที่ Azure Cosmos DB มอบให้คุณล้วนเป็นความสามารถในการจัดการ conflict การผสานขั้นตอน ทริกเกอร์ ฟังก์ชันที่ผู้ใช้กำหนดเงื่อนไขได้เอง และการ procedure โดนขั้นตอนที่ต้องจัดการกับ conflict และ procedure ระบบของ Cosmos DB จะดำเนินการเองแบบอัตโนมัติ

อย่างไรก็ตาม คุณสามารถกำหนดค่าต่างๆ ได้ด้วยตัวเองเพื่อจัดการกับ conflict ได้ หลังจากนั้นหากมี conflict เกิดขึ้นมาอีก Cosmos DB ก็จะรวบรวม procedure เหล่านั้นให้เอง โดย Cosmos DB มีจุดเด่นที่ได้รับการออกแบบให้ปรับขนาดได้ทั่วโลก ดังนั้นให้คิดว่าเมื่อมีใครบางคนเพิ่มรายการใหม่ลงในคอนเทนเนอร์ที่ต้องจัดการในช่วงเวลาเดียวกัน conflict ก็จะต้องได้รับการแก้ไข

Cassandra API – Multi key-values model
Cassandra API พร้อมด้วย multi key-values model ซึ่งค่าหนึ่งๆ สามารถเป็น key-value structure แบบเรียกใช้ซ้ำได้ ดังนั้น ใน Cassandra คุณจะมีคีย์ ซึ่งเชื่อมโยงกับคีย์นี้ คุณสามารถมีคอลัมน์ที่สามารถมีได้เพียงค่าเดียว หรือคอลัมน์ที่สามารถมีได้หลายค่า และเรียกว่า column family สิ่งนี้มีประโยชน์มากสำหรับการ mapping ความสัมพันธ์แบบ many-to-many แม้ว่ายังมีข้อจำกัดบางประการ แต่ก็จะสะดวกยิ่งขึ้นเมื่อแบบจำลองข้อมูลของคุณมีความสัมพันธ์แบบ many-to-many หรือแบบ one-to-many เป็นจำนวนมาก

Gremlin API – Graph model
กราฟคือแบบจำลองทางคณิตศาสตร์ที่อ้างอิงจาก 2 วัตถุง่ายๆ ได้แก่ จุดยอด (ขอบหรือโหนด) และขอบ ซึ่งแต่ละขอบสามารถเป็นได้ทั้งแบบสองทิศทางหรือทิศทางเดียว

Storage Table API
ในบัญชีที่เก็บข้อมูลของ Azure คุณมีฟีเจอร์ซึ่งเป็นบริการที่เรียกว่า ‘storage table’ ซึ่งเป็นหนึ่ง key value model และตอนนี้ก็ถูกรวมอยู่ใน Azure Cosmos DB แน่นอนว่า API นี้มีประโยชน์มากในบริบทของ IoT เนื่องจากค่าใช้จ่ายในการจัดการข้อมูลจำนวนมากนั้นสะดวกกว่าตารางบัญชีการจัดเก็บ

Azure Cosmos DB – First Contact

แค็ตตาล็อกผลิตภัณฑ์
ในแค็ตตาล็อกผลิตภัณฑ์นั้น คุณเลือก Core API เนื่องจากคุณมีข้อมูลแบบ semi-structured data สำหรับผลิตภัณฑ์ที่คุณมี ได้แก่ รหัสเฉพาะ ชื่อผลิตภัณฑ์ คำอธิบาย ผู้ขายรายเดียวหรือผู้ขายหลายราย หลังจากนั้น เมื่อเวลาผ่านไปคุณก็จะมีค่า not-common values ซึ่งจะใช้หรือไม่ก็ได้

ดังนั้นคุณต้องมีความสามารถมากพอในการกรองและจัดเรียงสินค้าระหว่างขั้นตอนการดึงข้อมูลเหมือนที่ E-Commerce หลายๆ แห่งเคยทำมาแล้ว เช่น Lazada, Agoda, Shopee เป็นต้น การใช้ Core/SQL API ใน Cosmos DB จะช่วยลดขั้นตอนง่ายๆ พร้อมกับเพิ่มประสิทธิภาพที่เป็นไปได้ทั้งหมดและจัดการกับความซับซ้อนสำหรับการดำเนินการเหล่านี้

ประวัติการสั่งซื้อ
สำหรับประวัติการสั่งซื้อ ควรใช้ MongoDB ประการแรกเนื่องจากมันเป็นส่วนที่ไม่ได้เปิดโอกาสให้ผู้ใช้ค้นหาอะไรในนี้ คุณก็เพียงอัปโหลดเอกสารด้วยรหัสหรือคีย์ของเอกสาร ประการที่สอง โดยโครงสร้างข้อมูลแล้ว คำสั่งซื้อหนึ่งรายการก็เหมือนเอกสารหนึ่งฉบับ มันมีโครงสร้างที่ค่อนข้างดีอยู่แล้ว เพราะระบุทั้งชื่อผู้ขาย ผู้ซื้อ สินค้าที่คุณสั่งซื้อ แต่ละรายการมีปริมาณเท่าไร รายละเอียด ราคาต่อหน่วย ฯลฯ เป็นต้น

การวิเคราะห์เว็บไซต์
การวิเคราะห์เว็บเป็นตัวอย่างสุดคลาสสิกสำหรับการรวบรวมข้อมูลที่มาจากแหล่งต่างๆ โดยการใช้ Cassandra API คุณจะสามารถรวบรวมข้อมูลทั้งหมดที่มาจากเว็บไซต์ของคุณ โดยจำแนกตามประเภทของเบราว์เซอร์ เส้นทางการใช้เว็บ ช่วงเวลาระหว่างการคลิก การโหลดหน้าเว็บ และอื่นๆ ข้อมูล key-values ประเภทนี้มีเพียงคีย์เดียว เนื่องจากเป็นข้อมูลที่เกี่ยวกับเว็บไซต์หรือเซสชันของคุณ เป็นต้น ข้อมูลทั้งหมดสามารถเป็นค่าที่คุณสามารถรวบรวมและจัดเก็บไว้ใน Azure Cosmos DB ได้โดยใช้ Cassandra API

เครื่องมือที่แนะนำให้ใช้
Gremlin API เป็น graph API ที่ดีที่สุดเมื่อคุณต้องการใช้งานระบบที่ให้คำแนะนำที่เป็นประโยชน์แก่คุณ ซึ่งเจ้าคำแนะนำนี้ก็จะทำงานเหมือนกับสมองของเรา ตามแนวความคิดที่มีความเชื่อมโยงกัน ตัวอย่างเช่น ฉันชอบเค้กช็อกโกแลต ถ้าคุณชอบเค้กช็อกโกแลต ก็หมายความว่าคุณชอบเค้กและช็อกโกแลต หากเน้นไปที่ช็อกโกแลต ในอนาคตคุณก็มีแนวโน้มที่จะเลือกไวต์ช็อกโกแลตหรือดาร์กช็อกโกแลตก็ได้

มีจุดยอดเพิ่มเติมที่สามารถรวมเอาไว้ในเค้กหรือให้ดาร์กช็อกโกแลตเพื่อให้ฉันมีตัวเลือกมากขึ้น ดูตรงไปตรงมาดีใช่ไหม? เมื่อเลื่อนไปรอบๆ กราฟ ผลลัพธ์ที่ได้จะบ่งบอกถึงเค้กช็อกโกแลต

ระบบ IoT
ระบบ IoT ควรใช้ Storage Table API โดยคุณควรใช้เพื่อจัดเก็บเท่านั้น เพราะสิ่งแรกที่เกิดขึ้นใน IoT คือการบันทึกข้อมูลที่คุณได้รับ สิ่งต่อมาคือข้อมูล structural data ที่ประกอบด้วย 1 id, 1 partition key และ 1 timestamp ส่วนข้อมูลที่เหลือประกอบด้วยข้อมูลเซนเซอร์ที่ได้มาจากอุปกรณ์ IoT นอกจากนี้คุณต้องใช้พื้นที่มหาศาลเพื่อจัดเก็บข้อมูลอีกต่างหาก

ตัวอย่างที่น่าสนใจก็คงเป็นที่จัดเก็บข้อมูลสำหรับอุปกรณ์ IoT ที่ใช้พยากรณ์อากาศ ซึ่งจำเป็นต้องมีการอัปเดตข้อมูลอย่างต่อเนื่อง ในระดับชั้นบรรยากาศที่แตกต่างกัน ตั้งแต่โซนสูง กลาง ต่ำ และระดับความสูงของแต่ละภูมิประเทศ ดังนั้นเราจึงจำเป็นต้องรวบรวมข้อมูลทั้งหมดนี้ไว้ที่ใดที่หนึ่งและส่งข้อมูลนี้เป็นระยะๆ ด้วยการใช้วิธีนี้ ทำให้เมื่อมีการรายงานข่าวในช่วงเที่ยงวัน สำนักข่าวก็จะมีข้อมูลการพยากรณ์อากาศแบบหนึ่ง และเมื่อถึงการรายงานข่าวในช่วงเย็น ข้อมูลการพยากรณ์อากาศสำหรับวันพรุ่งก็อาจมีการเปลี่ยนแปลงได้

ยิ่งคุณให้ข้อมูลสำหรับการพยากรณ์อากาศมากเท่าใด การพยากรณ์ของคุณก็ยิ่งแม่นยำมากขึ้นเท่านั้น ข้อมูลสำหรับการพยากรณ์อากาศอยู่ที่ประมาณ 20-50 GB ต่อระยะเวลา 6 ชั่วโมง ดังนั้น หากคุณคำนวณโดยคูณเป็น 24 ชั่วโมง คุณก็จะเริ่มเข้าใจจำนวนข้อมูลที่คุณต้องใช้เพื่อคำนวณหาว่าสภาพอากาศในวันพรุ่งนี้เป็นอย่างไร

Azure Cosmos DB ในเชิงลึก

Azure Cosmos DB มีแนวคิดที่เรียกว่าระดับความสม่ำเสมอ (consistency level) ที่มีทั้งหมด 5 ระดับ ได้แก่ strong, bounded, session, consistent และ eventual พวกเขาเป็นผู้กำหนดระดับของการซิงโครไนซ์ข้อมูลสำหรับฐานข้อมูลเดียวกันทั่วโลก

ขั้นแรก ให้เริ่มเรียงลำดับระดับตามความสม่ำเสมอ ซึ่งที่ระดับ strong หมายความว่าข้อมูลของคุณจะถูกซิงโครไนซ์ในความเร็วระดับมิลลิวินาทีในทุกภูมิภาคทั่วโลกที่คุณเลือก โดยค่าเริ่มต้นก็คือค่าระดับความสม่ำเสมอที่ session ในขณะที่ระดับที่เบาที่สุดคือระดับ eventual โดยที่ข้อมูลจะซิงโครไนซ์เป็น “eventual” (ในความหมายของอาจจะ)

ในการอธิบายเรื่อง replication และการซิงโครไนซ์ข้อมูล Azure ได้ทำให้เข้าใจด้วยการใช้ตัวอย่างเป็นโน้ตดนตรี และตามความเห็นของ Giorgio เขาระบุว่ามันเป็นตัวอย่างที่ดีจะอธิบายแนวคิดที่ยากเหล่านี้ให้ทำความเข้าใจได้ง่ายขึ้น

คุณต้องชำระเงินในการใช้งาน Cosmos DB อย่างไร?

Azure จะเรียกเก็บเงินจากการใช้งาน Cosmos DB ของคุณ โดยคิดจากหน่วยคำขอ (request unit) ที่ส่งเข้ามาในระบบ ตั้งแต่การดึงหรือจัดเก็บข้อมูลของคุณ และนี่คือสามสิ่งหลักที่คุณควรทำความเข้าใจเอาไว้

Request unit คืออะไร?

Request unit ก็คือค่าใช้จ่ายในการอ่านพอยต์ (เช่น การดึงข้อมูลรายการเดียวด้วยค่า ID และพาร์ทิชันคีย์) สำหรับรายการขนาด 1 KB คือ 1 หน่วยคำขอ (หรือ 1 RU)

อันดับแรกเลยคือคุณต้องเลือกรุ่น API หนึ่งรุ่นสำหรับ Azure Cosmos DB อย่างต่อมาคุณต้องเลือกระดับความสม่ำเสมอ และสุดท้ายคุณต้องเลือกปริมาณงานสำหรับหน่วยคำขอของฉัน

ประการสุดท้าย การทดสอบอย่างเข้มงวดนั้นเป็นสิ่งสำคัญต่อความสำเร็จ ทุกแง่มุม รวมถึงจุดบกพร่องและความสำเร็จ โดยเฉพาะในอดีต จะต้องได้รับการทดสอบอย่างถี่ถ้วนพร้อมกับดูว่าประสิทธิภาพมากขนาดไหน เมื่อประเด็นสำคัญทั้งสองนี้ถูกทดสอบจนครบถ้วนแล้ว ให้ตรวจสอบรายงานและประเมินผลลัพธ์เทียบกับ Azure Cosmos DB ซึ่งการตรวจสอบข้อมูลทั้งสองทางเป็นสิ่งสำคัญที่ตรวจสอบให้แน่ใจว่าคุณได้เลือกตัวเลือกที่ถูกต้องแล้ว ถ้าไม่โอเค ให้พิจารณาเพิ่ม RU/s และทำขั้นตอนการทดสอบซ้ำ

ตรวจสอบโมเดลข้อมูลของคุณ และหากคุณไม่เข้าใจโมเดล API ที่ถูกต้อง ให้เลือกใช้ Core API เริ่มต้น ประการที่สอง สร้างหลักฐานของแนวคิดและกำหนดฟีเจอร์ที่มีค่าที่สุด ตัวอย่างเช่น หากคุณตั้งใจที่จะพัฒนาแพลตฟอร์มอีคอมเมิร์ซ ฟังก์ชันการเข้าสู่ระบบและออกจากระบบอาจไม่ใช่คุณสมบัติหลักที่ควรพิจารณาสำหรับการใช้ Cosmos DB ให้เน้นที่แค็ตตาล็อกผลิตภัณฑ์ซึ่งมีความสำคัญมากที่สุดแทน

สร้างฟีเจอร์ต่างๆ ที่คุณคิดว่ามันสำคัญที่สุด โดยเริ่มจากจำนวนหน่วยคำขอขั้นต่ำต่อวินาที ตามภูมิภาคที่เลือก

การพิจารณา

การย้ายข้อมูลไปยังระบบคลาวด์

ประการแรกให้พิจารณาสิ่งที่คุณมี ตัวอย่างเช่น ฉันต้องการใช้ Cosmos DB เพื่อย้าย MongoDB ปัจจุบันของฉัน ใช่ เสร็จแล้ว จบ

ประการที่สอง ให้วางแผน API ตามรูปแบบข้อมูลที่คุณมีหรือที่คุณกำลังจะมี โดยคำนึงถึงความเบี่ยงเบนที่สามารถเป็นไปได้ทั้งหมดของ API เหล่านี้

ประการที่สาม พิจารณาการใช้ข้อมูลนี้ รวมถึงวิธีที่คุณค้นหา แทรก อัปเดต และลบข้อมูล เพราะจำเป็นอย่างยิ่งที่จะต้องคำนึงถึงแบบจำลองของการทดสอบอย่างรอบคอบ ซึ่งทำหน้าที่เป็นหลักฐานของแนวคิด เพื่อช่วยให้ทำการตัดสินใจได้อย่างถูกต้อง

ความเสี่ยงประการแรกคือแบบจำลองนี้อาจไม่สอดคล้องกับความเป็นจริง

ความเสี่ยงประการที่สองเกี่ยวข้องกับการตรวจสอบกระบวนการผลิตเพื่อคาดการณ์การเปลี่ยนแปลงที่อาจเกิดขึ้น เช่น ความถี่ของการอัปเดตนโยบายความเป็นส่วนตัวของ Facebook

ความเสี่ยงที่สามเกี่ยวข้องกับความจำเป็นในการแก้ไขแบบจำลองหรือการพิสูจน์แนวคิดเนื่องจากความยืดหยุ่นไม่เพียงพอ ตัวอย่างเช่น ข้อจำกัดอาจเกิดขึ้นเมื่อดำเนินการบางอย่าง เช่น การสร้างแค็ตตาล็อกผลิตภัณฑ์เป็นไปได้ ในขณะที่ฟังก์ชันการเข้าสู่ระบบไม่สามารถใช้งานได้ เนื่องจากว่ามันไม่ใช่ฟีเจอร์ที่มีมูลค่าสูงนั่นเอง

ทำความรู้จักกับ Azure Static Web Apps

Azure Static Web Apps เป็นส่วนเสริมล่าสุดในกลุ่มผลิตภัณฑ์ Azure Web Apps ซึ่งมีตัวเลือกการโฮสต์สำหรับ static file ที่พัฒนาโดยใช้ HTML และ JavaScript

Azure Static Web Apps ได้รวมบริการต่างๆ ของ Azure เข้าไว้ด้วยกัน ซึ่งมอบประสบการณ์การพัฒนาแบบ full stack ที่ครอบคลุม ตั้งแต่ซอร์สโค้ดไปจนถึงความพร้อมในการใช้งานระดับสูงทั่วโลก นอกจากนี้เวิร์กโฟลว์ยังได้รับการปรับแต่งให้เหมาะกับกิจวัตรประจำวันของนักพัฒนา นอกจากนี้ ยังเข้าถึง GitHub ที่เป็นพื้นฐานสำหรับการสร้างและปรับใช้แอปโดยใช้ Azure Static Web Apps ได้อีกด้วย

บริการนี้ไม่เพียงแต่สนับสนุนการปรับใช้เนื้อหาแบบ static แต่ยังรวมถึง API ด้วย

คุณคาดหวังว่าจะได้ใช้อะไรบ้างเมื่อใช้ Azure Static Web Apps:

• เว็บโฮสติ้งสำหรับเนื้อหาคงที่ เช่น HTML, CSS, JavaScript และรูปภาพ
• รองรับ API ในตัวผ่าน Azure Functions
• การรวม GitHub ช่วยให้สามารถสร้างและปรับใช้ที่ทริกเกอร์โดยการเปลี่ยนแปลงพื้นที่เก็บข้อมูล
• การกระจายเนื้อหาไปทั่วโลก ทำให้เข้าถึงผู้ใช้ได้มากขึ้น
• ต่ออายุใบรับรอง SSL ฟรีโดยอัตโนมัติ
• ตัวเลือกโดเมนที่กำหนดเองสำหรับการปรับแต่งแอปที่มีตราสินค้า
• โมเดลความปลอดภัยที่ไร้รอยต่อพร้อมพร็อกซีย้อนกลับสำหรับการเรียก API โดยไม่ต้องมีการกำหนดค่า CORS
• การรวมผู้ให้บริการการรับรองความถูกต้อง รวมถึง Azure Active Directory, Facebook, Google, GitHub และ Twitter
• การกำหนดบทบาทและการมอบหมายสิทธิ์ที่ปรับแต่งได้
• กฎการกำหนดเส้นทางแบ็กเอนด์สำหรับการควบคุมเนื้อหาและเส้นทางที่ให้บริการอย่างสมบูรณ์
• เวอร์ชันการจัดเตรียมที่สร้างขึ้นเพื่อขับเคลื่อนโดยคำขอดึงข้อมูล และเปิดใช้งานเวอร์ชันตัวอย่างสำหรับไซต์ของคุณก่อนที่จะเผยแพร่

การสนับสนุน: Azure Static Web Apps รองรับอะไรบ้าง

Front-End Frameworks – Static Web Apps เข้ากันได้กับแอปฯ front-end ที่สร้างขึ้นด้วย JavaScript และ TypeScript รวมถึงที่สร้างโดยใช้เฟรมเวิร์กยอดนิยม เช่น Vue.js, React, Angular และอื่นๆ

ภาษาการเขียนโปรแกรมสำหรับฟังก์ชัน Azure:

• Static Web Apps รองรับ JavaScript
• TypeScript
• Python
• C#
• Azure Functions apps

ปรับใช้แอปพลิเคชันคอนเทนเนอร์กับ Azure App Service อย่างต่อเนื่อง

ทำไมผู้คนถึงชื่นชอบ app service? เหตุผลหนึ่งเป็นเพราะแนวคิดของสล็อตการปรับใช้ ด้วย app service จึงทำให้คุณสามารถมีได้หลายสล็อต (หนึ่ง สอง สาม หรือแม้แต่สี่สล็อต) สำหรับหนึ่งเว็บไซต์ โดยปกติสล็อตแรกจะใช้สำหรับการผลิต

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

อีกเหตุผลหนึ่งที่ทำให้ app service เป็นที่นิยมก็เพราะช่วยให้ผู้ใช้สามารถกำหนดค่าและรวมตัวเลือกการรับรองความถูกต้องต่างๆ ได้อย่างง่ายดาย ไม่ว่าจะผ่านเว็บเบราว์เซอร์หรือวิธีอื่นๆ ยิ่งไปกว่านั้น app service ยังนำเสนอการผสานรวมกับเครื่องมือที่เรียกว่า app insights ซึ่งช่วยให้คุณตรวจสอบและรับข้อมูลเชิงลึกเกี่ยวกับประสิทธิภาพและการใช้งานแอปพลิเคชันของคุณ ตลอดจนความสัมพันธ์ใดๆ กับบริษัทหรือบริการอื่นๆ

App service เป็นที่นิยมเนื่องจากมีการสำรองข้อมูลรายวันในตัวสำหรับซอร์สโค้ดและบริการที่ผสานรวมอย่างแน่นหนา เช่น เซิร์ฟเวอร์ฐานข้อมูล อีกเหตุผลหนึ่งที่ทำให้ได้รับความนิยมก็คือการมีตัวเลือกในการปรับใช้ชื่อโดเมนที่กำหนดเองสำหรับเว็บไซต์ของคุณเอง แต่สิ่งนี้จะมีค่าใช้จ่ายเพิ่มเติม

หากคุณอยากทำให้เว็บไซต์ของตัวเองได้รับความนิยม สิ่งสำคัญคือต้องใช้ SSL กับเว็บไซต์ของคุณเองอย่างไรก็ตาม หากเว็บไซต์ของคุณเรียบง่าย เช่น www.something.com คุณสามารถรับสิทธิประโยชน์ SSL ได้ฟรีโดยไม่ต้องเสียค่าใบรับรองแต่อย่างใด

เมื่อพูดถึงเว็บไซต์ สิ่งแรกที่นึกถึงเมื่อใช้บริการ app service ก็คือการปรับใช้ซอร์สโค้ดหรือโปรแกรม ตัวเลือกที่สองคือการปรับใช้คอนเทนเนอร์ ซึ่งได้รับความนิยมมากขึ้นเรื่อยๆ

ตามความเข้าใจของฉัน Seven Peaks Software ได้มีการใช้คอนเทนเนอร์อย่างกว้างขวาง ซึ่งหมายความว่าด้วยฟังก์ชันการทำงานเต็มรูปแบบของ app service ทำให้คุณมีทางเลือกเพิ่มขึ้น โดยคุณสามารถปรับใช้โปรแกรมภายในเฟรมเวิร์กหรือสรุปทุกอย่างใน docker เมื่อคุณทำเสร็จแล้ว คุณก็สามารถวางอิมเมจ docker ลงใน app service ได้

ข้อดีอีกประการหนึ่งคือการผสานรวมกับไปป์ไลน์ CI/CD เช่น Azure DevOps ซึ่งเป็นโปรแกรมดั้งเดิมของ Microsoft นอกจากนี้ หากคุณต้องการไปป์ไลน์ CI/CD อื่น เช่น Jenkins ก็สามารถกำหนดค่าให้ทำงานได้อย่างราบรื่นอีกด้วย

หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการใช้ GitHub Actions, Azure App Service, Docker Container, Azure Container Registry, Node.js + Express.js และ Azure Cosmos DB ร่วมกัน สามารถรับชมเซสชันแลกเปลี่ยนความรู้ของเราได้ตอนนี้!