- ใช้ Cloud Run ในการให้บริการไฟล์ Static - 1
- บทความบล็อกเกี่ยวกับวิธีการใช้ Google Cloud Run ในการให้บริการไฟล์แบบคงที่ มุ่งเน้นไปที่การเปลี่ยนเส้นทางและการปรับปรุงประสิทธิภาพ
โพสต์นี้แปลโดย AI
บทสรุปของโพสต์โดย durumis AI
- เราได้สร้างระบบ CDN ที่ผสาน Google Cloud Storage (GCS) และ Cloud Run เพื่อจัดการรูปภาพและทรัพยากรเว็บอย่างมีประสิทธิภาพ และให้บริการไฟล์ที่ปรับให้เหมาะสมกับสภาพแวดล้อมของเว็บเบราว์เซอร์
- รูปภาพที่อัปโหลดจะถูกแปลงและจัดเก็บในรูปแบบต่างๆ เช่น webp, avif และไฟล์ข้อความจะถูกบีบอัดด้วย gzip, br เพื่อให้เนื้อหาที่เหมาะสมที่สุดแก่ผู้ใช้
- การวาง Cloud Storage และ Cloud Run ใน 8 ภูมิภาคทั่วโลกช่วยให้ทรัพยากรสามารถส่งมอบจากภูมิภาคที่ใกล้ที่สุดกับตำแหน่งของผู้ใช้ได้ ส่งผลให้ลดเวลาแฝงและปรับปรุงประสบการณ์ของผู้ใช้
บทความก่อนหน้าได้อธิบายเกี่ยวกับการให้บริการไฟล์แบบคงที่โดยใช้ Cloud Run ซึ่ง durumis (두루미스) กำลังใช้
แต่ไฟล์ต่างๆ เช่น robots.txt หรือ favicon.ico นั้นแตกต่างจากไฟล์รูปภาพที่โพสต์ในบล็อกหรือทรัพยากรของเว็บเพจเอง เนื่องจากไม่สามารถจัดการเป็นไฟล์แบบคงที่ได้อย่างง่ายดาย
ดังนั้น ไฟล์ประเภทนี้จึงจำเป็นต้องใช้ Cloud Run ที่เชื่อมต่อกับ Google Cloud Storage (หรือ GCS)
แนวคิดพื้นฐานนั้นค่อนข้างง่าย เมื่อมีการอัปโหลดไฟล์รูปภาพแบบเรียลไทม์หรือมีการอัปเดตเว็บไซต์ ทรัพยากรใหม่ๆ จะถูกอัปโหลดไปยัง GCS และเมื่อมีการร้องขอจากภายนอก Cloud Run จะตรวจสอบว่ามีไฟล์อยู่ใน GCS หรือไม่ และหากมี ก็จะส่งไฟล์นั้นไปให้
อย่างไรก็ตาม กระบวนการทำงานจริงนั้นซับซ้อนกว่าที่กล่าวมา
โดยทั่วไปแล้ว เมื่ออัปโหลดรูปภาพไปยัง GCS durumis (두루미스) จะแปลงไฟล์รูปภาพเป็น 3 รูปแบบ
เมื่ออัปโหลดไฟล์ jpeg หรือ png ไฟล์รูปภาพเหล่านั้นจะถูกแปลงเป็น webp และ avif พร้อมกัน และเก็บไว้ในที่เก็บข้อมูล
ไฟล์รูปภาพทั้งหมดจะใช้ URL ในการร้องขอโดยไม่มีส่วนขยาย และเมื่อมีการร้องขอ Cloud Run จะตรวจสอบส่วนหัวของเว็บเบราว์เซอร์ที่ร้องขอ เพื่อดูว่าเว็บเบราว์เซอร์รองรับไฟล์ avif และ webp หรือไม่ หากไม่รองรับทั้งสองไฟล์ ก็จะส่งไฟล์ jpeg หรือ png แทน นอกจากการเปลี่ยนรูปแบบแล้ว ยังมีการปรับขนาดรูปภาพให้เหมาะสมกับขนาดที่เว็บเพจต้องการก่อนที่จะเก็บไว้และส่งต่อไปด้วย
ไดอะแกรม
ไฟล์ข้อความก็เช่นเดียวกัน
ทรัพยากรจำนวนมากที่เว็บไซต์ต้องการนั้นไม่ใช่แค่รูปภาพเท่านั้น แต่ยังรวมถึงไฟล์ข้อความ เช่น js และ css ด้วย
ไฟล์ js และ css ก็คล้ายกับรูปภาพ ในขณะที่อัปโหลดจะถูกบีบอัดด้วย gzip และ br และเมื่อมีการร้องขอ จะส่งไฟล์ที่เว็บเบราว์เซอร์รองรับไปให้
บทบาทของ CDN นั้นไม่ได้จำกัดอยู่แค่การแคชเนื้อหาเท่านั้น ในกรณีของ Google Cloud Platform (GCP) สามารถเชื่อมต่อฟังก์ชัน Cloud CDN กับ Google Cloud Load Balancer (GCLB) ได้โดยตรง ทำให้มีฟังก์ชันที่ทรงพลังยิ่งขึ้น
Cloud CDN จะรับข้อมูลจาก Backend Service และจัดเก็บไว้ก่อนส่งไปยังไคลเอ็นต์ ในขั้นตอนนี้ Cloud CDN สามารถส่งไฟล์ที่เหมาะสมที่สุดตามส่วนหัวของการร้องขอของไคลเอ็นต์ได้ ซึ่งช่วยให้สามารถส่งเนื้อหาในรูปแบบต่างๆ สำหรับ URL เดียวกันได้
ตัวอย่างเช่น สำหรับ URL เดียวกัน เช่น '/image/tempImage'
- ในกรณีของไฟล์รูปภาพ
- จะส่งไฟล์รูปภาพในรูปแบบต่างๆ ตามส่วนหัว 'Accept' ของเบราว์เซอร์
- โดยทั่วไป เบราว์เซอร์ Chrome จะแสดงลำดับความสำคัญเป็น 'image/avif,image/webp,image/apng'
- CDN จะส่งไฟล์รูปภาพในรูปแบบที่เป็นไปได้ตามลำดับนี้ และหากไม่รองรับ ก็จะใช้ไฟล์ jpeg หรือ png แทน
- ในทำนองเดียวกัน ในกรณีของไฟล์ข้อความ
- จะพิจารณาลำดับความสำคัญของวิธีการบีบอัดด้วย
- เบราว์เซอร์ Chrome รองรับวิธีการบีบอัด เช่น 'gzip, deflate, br, zstd' เป็นต้น
- ตัวอย่างเช่น ในบริการของ durumis (두루미스) ปัจจุบันรองรับ gzip และ br ดังนั้นจึงจะส่งไฟล์ที่บีบอัดด้วย br ก่อนเป็นอันดับแรก
ฟังก์ชันขั้นสูงของ CDN เหล่านี้ช่วยให้สามารถส่งเนื้อหาที่เหมาะสมที่สุดสำหรับสภาพแวดล้อมของผู้ใช้ได้ ซึ่งจะช่วยเพิ่มประสิทธิภาพและประสบการณ์การใช้งานเว็บไซต์ได้อย่างมาก
แม้ว่าจะเป็น Cloud CDN แต่โดยพื้นฐานแล้ว CDN ก็ยังต้องร้องขอไฟล์จาก Cloud Run ดังนั้น durumis (두루미스) จึงใช้ Cloud Storage และ Cloud Run ใน 8 ภูมิภาคทั่วโลก เพื่อเตรียมทรัพยากรไว้ล่วงหน้า และส่งทรัพยากรเหล่านั้นไปให้ ดังนั้นแม้จะมีต้นทุนเพิ่มขึ้นเล็กน้อยและภาระงานที่มากขึ้น แต่ผู้ใช้ก็จะได้รับประสบการณ์การหน่วงเวลาที่ดีขึ้น
แม้ว่าจะใช้ Cloud CDN แต่โดยพื้นฐานแล้วก็ต้องดึงไฟล์จากเซิร์ฟเวอร์ต้นทาง (ในกรณีนี้คือ Cloud Run) durumis (두루미스) ได้ปรับโครงสร้างนี้ให้เหมาะสมที่สุด เพื่อให้บริการที่ดีขึ้นสำหรับผู้ใช้ทั่วโลก
กลยุทธ์การปรับให้เหมาะสมทั่วโลกของ durumis (두루미스):
- เตรียม Cloud Storage และ Cloud Run ไว้ล่วงหน้าใน 8 ภูมิภาคทั่วโลก
- แจกจ่ายทรัพยากรที่จำเป็นไปยังแต่ละภูมิภาคก่อนล่วงหน้า
- ส่งทรัพยากรจากภูมิภาคที่ใกล้ที่สุดเมื่อผู้ใช้ร้องขอ
วิธีการนี้แม้จะมีต้นทุนเพิ่มขึ้นเล็กน้อยและงานเพิ่มเติม แต่ก็ให้ประโยชน์แก่ผู้ใช้ดังนี้:
- การหน่วงเวลาที่ดีขึ้นอย่างมาก
- เวลาในการโหลดเนื้อหาที่เร็วขึ้น
- ประสบการณ์การใช้งานโดยรวมดีขึ้น
โครงสร้างนี้สามารถแสดงภาพได้ดังนี้:
ด้วยโครงสร้างนี้ durumis (두루미스) สามารถให้บริการที่รวดเร็วและสม่ำเสมอแก่ผู้ใช้ทั่วโลกได้ เนื่องจากผู้ใช้จะได้รับเนื้อหาจากภูมิภาคที่ใกล้ที่สุดโดยไม่คำนึงถึงตำแหน่งที่ตั้ง ดังนั้นจึงสามารถใช้บริการได้ด้วยการหน่วงเวลาต่ำทั่วโลก
วิธีการนี้แม้จะต้องใช้ความพยายามในการตั้งค่าและบำรุงรักษามากขึ้น แต่ก็มีข้อดีที่ช่วยเพิ่มประสบการณ์ของผู้ใช้ปลายทางอย่างมาก โดยเฉพาะอย่างยิ่งสำหรับบริษัทที่ให้บริการระดับโลก โครงสร้างนี้สามารถช่วยให้สามารถให้บริการที่แข่งขันได้
ในบทความ CDN ในวันนี้ เราได้กล่าวถึงแนวคิดพื้นฐานเท่านั้น
อันที่จริง เราอาจจะพูดถึงรายละเอียดการตั้งค่าได้ แต่เนื่องจากแตกต่างกันไปตามผู้ให้บริการคลาวด์ (GCP, Azure, AWS) และค่อนข้างน่าเบื่อ จึงได้อธิบายเฉพาะแนวคิดเท่านั้น
ในโอกาสต่อไป เราจะมาพูดถึงรายละเอียดเพิ่มเติมในส่วนต่างๆ
ดังนั้นในบทความถัดไป เราจะมาพูดถึงวิธีการซิงค์ Cloud Storage ในหลายๆ ภูมิภาค (ของเราถึง 8 ภูมิภาค!)
ขอขอบคุณ