Open Graph คืออะไร
Open Graph Meta Tags คือชุดโค้ดในส่วนของ Metadata ถูกสร้างขึ้นครั้งแรกโดย Facebook เป็นส่วนที่เอาไว้ preview ตัว content ที่เราแชร์ไปบน social media platform ต่างๆไม่จะเป็น Facebook, Twitter, LinkedIn เพื่อให้ content มีความหน้าสนใจและกดเข้าไปดูมากขึ้น
OgXYZ Power — “พลังของ Service ของเรา”
OgXYZ เป็น Service ที่สร้างมาสำหรับการสร้าง Open Graph ให้กับ website ที่ไม่ได้มีการ implement ตัว metadata มาตั้งแต่ต้น หรือเพื่อนๆคนไหนที่อยากเปลี่ยน metadata เดิมให้เป็นข้อมูลใหม่ๆก็สามารถมาใช้งานได้ด้วยเช่นกัน ทำให้เพิ่มความน่าสนใจของ website หรือ content ต่างๆได้อย่างไม่มีสิ้นสุด ช่วยลดเวลาการทำงาน และเพิ่มโอกาศในการขายของได้มากขึ้นสุดๆ
OgXYZ Challenge — “ความท้าท้ายขั้นสุด”
ขอยกตัวอย่างการทำงานเพื่อให้เห็นภาพที่ชัดเจนยิ่งขึ้น Marketing-A เข้ามาใช้งาน OgXYZ แล้วได้ URL ที่เป็น Open Graph ที่ต้องการ ( จุดนี้ client ของเราจะมีแค่คนเดียวคือ Marketing-A ) จากนั้นนำไปโพสต์ลงใน Platform ของตัวเอง “นี่แหละคือจุดแห่งความพีค” เพราะ URL ที่ Marketing-A ได้ไปมันคือ Redirect url เท่ากับว่าระบบขอเราต้องรองรับลูกค้าทั้งหมดของ Marketing-A ให้ได้ ซึ่งเราแทบจะคาดเดาไม่ได้เลยว่าจะเจอการ request เข้ามาเท่าไหร่บ้าง
Architect
จากที่เกริ่นไปความท้าทายในการออกแบบของเราก็คือ
- เป็นระบบที่ห้ามล่ม ( ระบบล่ม redirect ไม่ได้เท่ากับแตก )
- รองรับผู้ใช้งานได้เป็นจำนวนมาก
- เร็ว แรง และได้ข้อมูลที่ถูกต้อง
- เข้าถึงได้เร็วไม่ว่าจะเรียกใช้งานจากที่ไหน
Infrastructure — “”
เมื่อต้องการระบบที่ให้ทุกคนเข้าถึงได้รวดเร็วและเข้าถึงได้ทุกที่แบบไม่ติดขัด Cloud service ยังเป็นสิ่งที่เรารักเสมอ
Cloud ☁️
- AWS — เป็น Cloud ที่เราเลือกใช้งาน โดย service ที่เราเลือกใช้งานหลักๆก็ยังเป็น serverless ที่เป็นตัวหลักในการทำงาน ผสมผสานกับ IaaS สำหรับบาง module
- MongoDB-Atlas - Cloud database service ที่เราเลือกมาใช้เป็น database infrastructure ของ MongoDB โดยเราเลือกใช้ Service Serverless MongoDB
Frontend — “หน้าบ้านของเรา”
โดยภาพรวมเรายังใช้งาน Stack เดิมเหมือนกับ ImageXYZ อีกหนึ่ง Service ของเรา การ design frontend ให้มีความ simple และใช้งานได้ง่าย
User Facing
- NextJs — เราเลือกใช้งาน Nextjs (React-Framework) ในการพัฒนา Website ทั้งหมด และใช้ความสามารถในการ Build และ Export Static File ไปเพื่อนำไปใช้ในการ Hosting ต่อ
Languages
- TypeScript/Javascript — เป็นภาษาหลักที่เราใช้ในการพัฒนาตัว Website ของเรา
- HTML, CSS — อีกภาษาหนึ่งที่ขาดไม่ได้ในการพัฒนา frontend
Serve Static Content
- Amazon S3 — ใช้สำหรับ Serve static content ที่เราได้ทำการ Build ออกมา เพื่อให้บริการผู้ใช้งานของเรา ซึ่งความสามารถในการทำ Static Hosting ของ S3 เป็นส่วนที่ช่วยให้ความตั้งใจของเราประสบความสำเร็จอย่างมาก
Edge Network
- Cloudflare — ใช้เป็น CDN รวมถึงเป็น Domain management ของ Web Application ของเรา
Backend — “เรียบง่ายแต่ทรงพลัง”
Languages
- Nodejs — เลือกด้วยเหตุผลง่ายมาก นั้นคือเราถนัดเขียน Nodejs เป็นหลัก แต่เนื่องจาก Constrait ที่เราต้องรองรับ Load แบบมหาศาล เราเลยต้องแค้นประสิทธิภาพของ Nodejs ให้ออกมามากที่สุด บวกกับการทำ Profiling เพื่อหาจุดที่มีโอกาส Bottom neck
Instance
- EC2 — เราไม่อยากให้เกิด Cold start จึงเลือกใช้งาน Backend server แบบท่ามาตรฐานที่สุด แต่เลี่ยงใช้งานตระกูล T serise นะ เพราะถ้าเกิด Burst request เข้ามาจริงๆ มันจะแตกได้ เราเลยเลือกใช้ตระกูล C6a.large สำหรับใช้งานเป็น Server
LoadBalancer
- NLB — เรานำมาใช้งานสำหรับเป็น LB ในการรองรับ Request ที่จะเข้าแล้วเพื่อกระจายไปยัง backend server ของเรา รวมไปถึงเพื่อเป็นการเพิ่ม Availability ให้กับระบบเราอีกด้วย
Database
- MongoDB — เราเลือก MongoDB เพราะเราอยากได้ Key-Value Database สำหรับรองรับการค้นหาข้อมูลจำนวนมหาศาลและต้องการจะตอบสนอง Request ให้เร็วที่สุดเท่าที่จะเป็นไปได้ และเหตุผลที่เราไม่ใช้ DynamoDB เพราะเรามีประสบการณ์ที่แย่กับการถูก Vendor Lock-in
Gateway
- Amazon API Gateway — การเลือกใช้งาน API Gateway ในแบบที่เป็น SaaS ช่วยให้เราลดความยากในการรับมือ request จำนวนมากลงไปได้ ทำให้เราไม่ต้องกังวลถึงการ scale หรือการใช้งานเมื่อมี request เข้ามามากๆ
A lot of tools — “ตัวช่วยที่แสนดี”
CI/CD Tools
- Jenkins — Tools หลักที่นำมาเป็นตัวทำ pipeline สำหรับการ build และ deploy service ต่างๆของเรา
Collaborate
- Figma — Prototype collaborate tools เอาไว้ทำงานร่วมกันกับ UX/UI Designer
User Feedback Tools
- Sleekplan — pluging ที่เอามาช่วยในการเก็บ user feedback ที่ implement กับ frontent ได้ง่ายมาก
Logging and Monitoring
- AWS Cloudwatch — Cloudwatch เป็น service ที่เราหยิบใช้ในการเก็บ Logs และ Monitor การทำงานของ service ของเรา เป็น centralize logs ที่ใช้ในการเก็บข้อมูลและยังมี tools ที่นำ logs กลับมาวิเคราะห์ได้ง่ายอีกด้วย
ปัญหาที่เราพบ
- Nodejs เราต้องมั่นใจว่า Function ที่เราเขียนนั้นเป็น Asynchronus 100% เพื่อให้สามารถรองรับ Concurrentcy ได้อย่างเต็มประสิทธิภาพ ซึ่งเทคนิคที่เราใช้ใน Nodejs นั้นคือการครอบ Function ด้วย SetImmediate() เพื่อโยนงานนั้นไปทำใน Thread ที่ว่างอยู่และใช้ Main Core ในการจัดการกับ Request ถัดไป
- Load Test เราได้ทำการทดลองทำ Load Test โดยใช้ตัว k6 ผ่าน Grafana lab เลย
ซึ่งผลลัพธ์คือตัว EC2 Instance ของเราสามารถรองรับ Request ได้โดยที่ยังไม่เกิด Error response และตัว EC2 ของเราใช้งาน CPU อยู่ที่ประมาณ 25-30% เท่านั้น
