Architecture ของ CU Get Reg ฉบับแรก Q1 ปี 2022

สวัสดีครับ จากตอนก่อนหน้านี้เรื่อง เบื้องหลังของ CU Get Reg เราทำอะไร? และเราทำยังไง? วันนี้เลยผมกะว่าจะมาเล่าว่าปัจจุบัน Architecture ของ CU Get Reg ตอนนี้ว่าเป็นประมาณไหน และมันมีปัญหาอะไรหรือเปล่า? เชิญรับชมกันได้เลยครับ

ก่อนอื่นเรื่อง Server ที่ใช้ตอนนี้เป็น Server จากทาง สำนักทะเบียน จุฬาลงกรณ์มหาวิทยาลัย ซึ่งมี Spec ตามนี้เลย

• OS: Ubuntu 20.04.2 LTS
• CPU: 4 core
• RAM: 8 GB
• Disk space: 200 GB

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

เราเอา Server อันนี้ไปทำอะไรบ้าง?

เป้าหมายในการใช้ Server จริง ๆ ก็ค่อนข้างจะตรงไปตรงมา นั่นก็คือ เราเอาไปใช้สำหรับ เก็บข้อมูลเข้า Database, run Backend Server สำหรับประมวลผลข้อมูลและเก็บลง Database, และ Frontend Server สำหรับ Serve หน้าเว็บไซต์ให้ Client Browser

และเป้าหมายรองก็คือ เราใช้ Server นี้เป็นเป็นตัวเก็บ Log และใช้สำหรับ Admin Dashboard เพื่อเอาไป Operate งานหลังบ้าน และอื่น ๆ อีกเล็กน้อยเกี่ยวกับการดำเนินงาน

ซึ่ง Service ทั้งหมดจะอยู่ในรูปแบบของ Docker Container ตาม Diagram นี้เลย

ความสัมพันธ์ของแต่ละ Service ใน CU Get Reg Server

อธิบาย

สำหรับ User ทั่วไป พวกเขาจะเข้ามาใช้งาน CU Get Reg ได้ผ่าน HTTP(S) เท่านั้นโดยมี Reverse Proxy เป็น Traefik จากนั้นมันจะส่ง Request ไปหา Web Service (สีน้ำเงิน) ส่วนที่เป็น Frontend บน Production จากนั้นผู้ใช้ก็จะใช้งาน Website ได้ปกติ

ในส่วนที่เป็น Internal Tools (e.g. Dashboard, LDAP, Management, Logging) User ทั่วไปจะไม่สามารถเข้าใช้งานได้ เพราะติดตัว LDAP Middleware ซึ่งเราจะต้องยืนยันตัวตนเป็นสมาชิกในทีมผู้พัฒนาก่อน ถึงจะผ่าน Middleware ตัวนี้ได้

นอกจากเส้นที่ออกมาจาก Traefik แล้ว (เส้นสีดำ ๆ) Service ทั้งหมดจะคุยกันผ่าน Internal Network (Docker Network) ทั้งหมด ทำให้ผู้ใช้ทั่วไปไม่สามารถเข้าถึง Service เหล่านั้นได้

Web Service

เราจะมี Environment ทั้งหมด 3 อัน

1. Dev Environment — จะเป็นที่ที่ให้ Developer ได้ลอง Deploy Feature ที่ตัวเองทำขึ้น Server จริง ๆ อีกทั้งยังเป็น Environment ที่ใช้สำหรับการ Demo ตอนที่เราเปิด Pull Request เพื่อให้ง่ายต่อการ Review Code
2. Beta Environment — จะเป็นที่ที่เราเอา Feature ที่ผ่านการ Review แล้ว มาปล่อยรวมกันไว้ที่นี่โดยยังไม่ขึ้น Production จริง ๆ เพราะเราจะดูก่อนว่าเมื่อรวม Feature ที่ทำมาทั้งหมดใน Sprint แล้วมีปัญหาหรือไม่ จากนั้นค่อยปล่อยขึ้น Production ทีเดียว อีกทั้ง Environment นี้ยังเป็นที่ที่ใช้สำหรับการรัน E2E Test (ซึ่งตอนนี้ยังไม่มี)
3. Production Environment — ตามชื่อเลยคือเป็น Environment ที่ User ใช้งาน CU Get Reg จริง ๆ

โดยในแต่ละ Environment จะใช้ Service เหมือน ๆ กันโดยจะขอลงรายละเอียดไปทีละ Service

1. NextJS (Frontend) — Service นี้คือ Service หลักที่ใช้ในการส่งหน้าเว็บไซต์ให้กับ Client Browser โดยในส่วนของ Frontend จะมีการติดตั้ง Google Tag Manager เพื่อเอาไว้ติดตั้ง External Tools ต่าง ๆ เช่น Google Analytics สำหรับเก็บข้อมูลและวิเคราะห์ข้อมูล, Google Optimize สำหรับการทำ A/B Testing, Hotjar เป็น Analytics อีกตัวที่จะแสดงพฤติกรรมการใช้งานของ User เพื่อเอาไปวิเคราะห์ปัญหาด้าน UX/UI ต่อไป อีกทั้งเรายังเก็บ Log โดยใช้ Graylog อีกด้วย เพื่อนำข้อมูลไปใช้ต่อสำหรับงาน Data Science
2. NestJS (Backend) — Service นี้เป็น API หลักที่ใช้ในการประมวล Request และส่ง Response กลับไปให้ Frontend รวมไปถึงสร้าง/แก้ไข/ลบ Document ต่าง ๆ ใน Database อีกทั้งเรายังเก็บ Log โดยใช้ Graylog อีกด้วย เพื่อนำข้อมูลไปใช้ต่อสำหรับงาน Data Science
3. NestJS (Scraper) — Service นี้เป็น Service พิเศษที่จะคอย “ขูด” ข้อมูลรายวิชาสาธารณะจากสำนักทะเบียน เป็นระยะ โดย Service นี้เกิดขึ้นมาเพราะว่าทางสำนักทะเบียนไม่มี API สำหรับการ GET ข้อมูลรายวิชาทั้งหมดให้ใช้ พวกเราจึงทำได้แค่ขูดข้อมูลจาก Official Website เท่านั้น ซึ่งข้อมูลที่ได้ตรงนี้จะ Delay จากความเป็นจริง 1 วัน ทำให้ CU Get Reg ยังมีปัญหาเรื่องการ Sync ข้อมูลจากสำนักทะเบียน

นอกจากนี้เรายังมี Service พิเศษที่ทำขึ้นโดยทีม Data Science นั่นก็คือ Computation ซึ่ง Service จะนำข้อมูลจาก Graylog และ MongoDB มาใช้เพื่อใช้สร้าง Recommender System (ระบบแนะนำรายวิชา)

Database

Database ที่พวกเราใช้ตอนนี้จะเป็น MongoDB จะเก็บข้อมูลรายวิชา รีวิว และข้อมูล course cart ของผู้ใช้ โดยมีการสร้าง index เพื่อให้สามารถ query ได้รวดเร็วมากขึ้น

Dashboard

ใส่ส่วนนี้ตอนนี้เราจะมีอยู่ 2 Services

1. Traefik Dashboard — ใช้สำหรับการดูว่าตอนนี้ Route ไหน Active อยู่บ้าง สามารถอ่านรายละเอียดเพิ่มเติมได้ที่
2. Lighthouse — เป็น Service ที่ใช้เพื่อดู Quality ของ Web Application ในทุก ๆ Environment ตามหลักการของ Lighthouse โดยจะมี 4 เรื่องที่ต้องดู Performance, Accessibility, Best Practices และ SEO แต่หลัก ๆ เราจะเน้นไปดูที่ Performance และ SEO เพราะคะแนนตอนนี้ยังไม่ค่อยดีเท่าไร แหะ ๆ

LDAP

ใส่ส่วนนี้จะเป็นส่วนที่ใช้สำหรับการจัดการ LDAP เพื่อจำกัดสิทธิ์ในการเข้าถึง Internal Tools ต่าง ๆ โดยจะมี Service หลัก ๆ 3 อย่าง

1. PHP LDAP Admin — เป็น Web-based LDAP Client ที่ใช้สำหรับการจัดการ LDAP User และ Hashed Password และจัดการเกี่ยวกับระบบ LDAP
2. OpenLDAP — เป็น LDAP Server
3. Authelia — เป็นระบบ Authentication และ Authorization สำหรับป้องกัน Internal Services ซึ่งสามารถใช้ร่วมกับ Reverse Proxy เจ้าดัง ๆ เช่น Nginx หรือ Traefik ได้

Management

ส่วนนี้จะเป็นส่วนที่ใช้สำหรับการจัดการข้อมูลหรือระบบหลังบ้านแบบง่าย ๆ

1. Portainer — เป็น UI Platform สำหรับการจัดการ Docker, Docker Swarm และ k8s โดยเฉพาะ ซึ่งเราเอาตัวนี้มาใช้จัดการพวก Docker Container เพราะต้องการลดการใช้ SSH และลดความยุ่งยากในการเข้าในใช้ Docker ใน Server
2. Appsmith — เป็น low-code Platform ที่ใช้สำหรับการทำเว็บไซต์ที่ต้องการใช้ Data Source จาก API หรือ Database โดยตรง ซึ่งเหมาะมากสำหรับการเอามาใช้เป็น Admin Dashboard เพราะเราไม่ต้องเขียน Code อะไรเยอะแยะ แค่ลากวางก็ได้ UI พร้อมใช้แล้ว (เน้นใช้งาน แต่ก็สวยงามพอประมาณ) ณ ตอนนี้เราใช้ Appsmith สำหรับการกรอง Review (Approve/Reject) จากผู้ใช้ว่าผิดกฎการรีวิวของเราหรือไม่

Logging

1. Apache Drill — ใช้สำหรับการ Query ข้อมูลหรือ Data Set ที่มีขนาดใหญ่ ซึ่งรองรับหลาย Data Source (แน่นอนว่ารองรับ MongoDB เหมือนกัน) ซึ่งทำให้การ Query ข้อมูลบน MongoDB เป็นเรื่องที่ง่าย และที่น่ามหัศจรรย์คือเราสามารถ Query ข้อมูลใน MongoDB ในรูปแบบ SQL ได้ด้วย เหมาะกับงานที่ต้องใช้ข้อมูลจำนวนมาก ๆ มาวิเคราะห์
2. Elasticsearch — ใช้สำหรับการจัดการ Log โดย Graylog จะส่ง Log มาให้ Elasticsearch จัดเก็บและจัดการอีกที
3. Graylog — ใช้ในการเก็บและวิเคราะห์ Log ซึ่งส่งมาจากทั้งทาง Frontend และ Backend อีกทั้งเรายังสามารถนำข้อมูลที่เก็บได้มาแสดงผลผ่าน Graylog ได้ด้วย

Deployment Automation

ใน Story หน้า เราจะเล่าเกี่ยวกับ Deployment Automation ที่ CU Get Reg ใช้ว่าเป็นอย่างไร? มี Sequence แบบใด รอติดตามกันได้เลยครับ

• ตอน Development Workflow สไตล์ CU Get Reg ฉบับคนไม่ค่อยว่าง

ทิ้งท้ายเล็กน้อย

ขอบคุณที่อ่านมาถึงตรงนี้นะครับ ตอนนี้ CU Get Reg ยังต้องการคนมา Operate งานต่อ (เพราะตอนนี้หลาย ๆ อย่างก็ยังต้องใช้มนุษย์ในการดูแลอยู่) และอีกไม่กี่ปีข้างหน้าทีมงานชุดปัจจุบันก็จะจบการศึกษาและคงไม่ได้ดูแล Project นี้ต่อแล้ว เพราะต่างคนก็คงทำงานประจำของตัวเองไป เพราะฉะนั้นหากท่านผู้อ่านท่านใดสนใจที่จะมาช่วยสร้างคุณภาพชีวิตที่ดีขึ้นให้กับชาวจุฬาฯ สามารถ Email ได้ที่ dev@cugetreg.com