Giới thiệu dự án

Bối cảnh thị trường và vấn đề thực tiễn

Theo báo cáo từ tổ chức nghiên cứu thị trường Grand View Research, quy mô thị trường biển báo kỹ thuật số toàn cầu (Digital Signage) đạt mức 21,49 tỷ USD vào năm 2020, tăng lên 23,03 tỷ USD vào năm 2021 và duy trì tốc độ tăng trưởng kép hàng năm (CAGR) đạt 7,5% giai đoạn 2021 - 2028. Trong đó, phân khúc màn hình hiển thị LED chiếm tỷ trọng doanh thu vượt trội trên 45%, theo sau là công nghệ LCD đang tăng trưởng mạnh mẽ trong lĩnh vực quảng cáo và truyền thông ngoài trời (OOH - Out-of-Home).

Tại Việt Nam, các đơn vị truyền thông lớn (điển hình như Chicilon Media với hơn 15.000 lượt hiển thị/ngày và tốc độ tăng trưởng doanh thu giai đoạn 2010 - 2020 đạt 27%/năm) đã chứng minh tiềm năng thương mại khổng lồ của kênh quảng cáo số. Khảo sát của Nielsen cho thấy một nhân viên văn phòng tại Hà Nội và TP.HCM sử dụng thang máy trung bình 6 - 8 lần/ngày, tiếp xúc tối thiểu 5,5 lần/ngày với màn hình quảng cáo.

                  THỊ TRƯỜNG DIGITAL SIGNAGE TOÀN CẦU (2020 - 2028)
   Quy mô 2020: $21.49B ───► Quy mô 2021: $23.03B ───► CAGR: 7.5% (2021 - 2028)
   Thị phần công nghệ: LED (>45%) | LCD (Tăng trưởng nhanh) | Khác (Máy chiếu, E-Paper)

Vấn đề cốt lõi (Problem Statement)

Mặc dù nhu cầu thị trường rất lớn, phần lớn hệ thống bảng hiệu điện tử vừa và nhỏ tại Việt Nam vẫn vận hành theo phương thức truyền thống với nhiều điểm nghẽn nghiêm trọng:

  • Quy trình cập nhật thủ công: Đội ngũ kỹ thuật phải đến từng địa điểm vật lý để cắm USB hoặc cấu hình lại thiết bị, làm tăng chi phí nhân sự và thời gian phản hồi (thường mất từ 24h - 48h cho một chiến dịch mới).
  • Thiếu khả năng giám sát tập trung theo thời gian thực: Quản trị viên không nắm được tình trạng hoạt động (Online/Offline/Lỗi giải mã media) của hàng trăm thiết bị ngoại vi tại thời điểm thực.
  • Hạn chế trong lập lịch và layout hiển thị: Nội dung chỉ phát video/hình ảnh tuần tự đơn điệu, không thể chia vùng hiển thị (multi-zone layout) hay lập lịch động theo khung giờ/ngữ cảnh.
  • Kiến trúc nguyên khối (Monolithic/LAMP) lỗi thời: Khó mở rộng khi số lượng thiết bị đầu cuối tăng đột biến, gây nghẽn băng thông máy chủ khi phân phối tài nguyên đa phương tiện dung lượng lớn.

Mục tiêu đề tài

Đề tài "Thiết kế và triển khai hệ thống quảng cáo điện tử trên nền tảng đám mây" (Khoa Hệ thống Thông tin, Trường Đại học Công nghệ Thông tin - ĐHQG TP.HCM) hướng tới 5 mục tiêu cụ thể:

  1. Kiến trúc đám mây chịu tải cao: Xây dựng hệ thống quản lý tập trung trên nền tảng Cloud, có khả năng mở rộng ngang (Horizontal Scaling) đáp ứng đồng thời hơn 100.000 thiết bị kết nối.
  2. Điều khiển và đồng bộ thời gian thực (Real-time Synchronization): Ứng dụng công nghệ WebSocket (Socket.io) kết hợp Redis Pub/Sub, đảm bảo độ trễ cập nhật cấu hình và lịch phát dưới 100ms.
  3. Phần mềm phát nội dung chuyên dụng (Signage Content Player - SCP): Phát triển ứng dụng Desktop đa nền tảng bằng ElectronJS, hỗ trợ cơ chế bộ nhớ đệm ngoại tuyến (Offline Caching) khi mất kết nối mạng.
  4. Phân quyền và quản trị đa cấp (RBAC & Merchant Management): Thiết kế mô hình kiểm soát truy cập dựa trên vai trò (Role-Based Access Control), bảo mật bằng JSON Web Token (JWT).
  5. Tối ưu hóa phân phối nội dung đa phương tiện: Tích hợp Cloudinary và cơ chế Presigned URL nhằm giảm 90% tải băng thông qua máy chủ ứng dụng chính.

Phạm vi và giới hạn

  • Phạm vi: Tập trung vào giải pháp phần mềm quản lý tập trung (Web Dashboard), ứng dụng phát trên màn hình (Desktop Client App), và hạ tầng điều phối thời gian thực trên Cloud.
  • Giới hạn: Đề tài chưa tích hợp phần cứng nhận diện khuôn mặt chuyên dụng bằng AI Camera tại biên, tập trung chính vào tính sẵn sàng, độ ổn định của mạng lưới thiết bị và độ mượt mà của nội dung phát.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Tiêu chí Cập nhật USB/Thủ công Hệ thống LAMP truyền thống Giải pháp Đám mây MERN + K8s (Đề xuất)
Độ trễ cập nhật 1 - 3 ngày (Thủ công) 5 - 15 phút (HTTP Polling) < 100ms (WebSocket Real-time)
Khả năng mở rộng Không thể Giới hạn (Scale dọc - Vertical) Vô hạn (Scale ngang với K8s/Docker)
Giám sát thiết bị Không có dữ liệu Định kỳ (Polling tốn tài nguyên) Heartbeat thời gian thực liên tục
Khả năng phát Offline Có (dữ liệu trên USB) Kém (phụ thuộc webview online) Tự động lưu đệm cục bộ qua IndexedDB/FS
Chi phí vận hành Rất cao (Nhân sự di chuyển) Trung bình (Tốn tài nguyên server) Tối ưu (Pay-as-you-go trên Cloud)

Phân loại yêu cầu người dùng theo mô hình MoSCoW

  • Must-Have (Bắt buộc): Giám sát trạng thái thiết bị thời gian thực; Quản lý chiến dịch/danh sách phát; Phát đa phương tiện (Video/Hình ảnh/Web view); Phân quyền người dùng (Admin, Manager, Merchant); Xác thực JWT.
  • Should-Have (Nên có): Upload tài nguyên trực tiếp qua Presigned URL; Lưu đệm nội dung phát khi mất mạng; Báo cáo thống kê lượt phát.
  • Could-Have (Có thể mở rộng): Tích hợp AI phân tích độ tuổi/giới tính người xem; Tự động tối ưu độ phân giải video theo thông số màn hình.
  • Won't-Have (Chưa thực hiện trong giai đoạn này): Đấu thầu quảng cáo tự động theo thời gian thực (Programmatic RTB).

Thiết kế hệ thống

graph TB
    subgraph Client Layer
        WebDash["Web Dashboard (ReactJS)"]
        SCP["Signage Content Player (ElectronJS)"]
    end

    subgraph Gateway & Load Balancer
        Nginx["Nginx Reverse Proxy & Load Balancer"]
    end

    subgraph Microservices Cluster
        NodeCluster1["API Pod 1 (Node.js/Express)"]
        NodeCluster2["API Pod 2 (Node.js/Express)"]
        SocketCluster["Socket.io Server Cluster"]
    end

    subgraph Cache & State Layer
        RedisCluster[("Redis Pub/Sub & Adapter")]
    end

    subgraph Data & Storage Layer
        MongoDB[("MongoDB Replica Set")]
        CloudStorage[("Cloudinary / Presigned S3 Media")]
    end

    WebDash -->|HTTPS / REST API| Nginx
    SCP -->|WSS / Socket.io| Nginx
    Nginx --> NodeCluster1
    Nginx --> NodeCluster2
    Nginx --> SocketCluster
    SocketCluster <--> RedisCluster
    NodeCluster1 --> MongoDB
    NodeCluster2 --> MongoDB
    WebDash -.->|Direct Upload via Presigned URL| CloudStorage
    SCP -.->|Stream Media Content| CloudStorage

Technology Stack và phiên bản chi tiết

  • Backend Runtime: Node.js v14.17.x, ExpressJS v4.17.x (Kiến trúc bất đồng bộ, Non-blocking I/O).
  • Frontend Web Dashboard: ReactJS v17.0.x (Virtual DOM, Redux Toolkit, Webpack tối ưu production).
  • Display Client (SCP): ElectronJS v12.0.x tích hợp Chromium Engine và Node.js runtime chạy trên Linux/Windows/macOS.
  • Cơ sở dữ liệu: MongoDB v4.4 (Replica Set, Document-oriented NoSQL linh hoạt schema).
  • Điều phối & Real-time: Socket.io v4.0.x, Redis Server v6.2 (Pub/Sub Adapter cho hệ thống Cluster).
  • Hạ tầng triển khai: Docker v20.10.x, Google Kubernetes Engine (GKE v1.20), Nginx v1.19 (Reverse Proxy/Load Balancer).

Thiết kế cơ sở dữ liệu (ERD Core Schemas)

Hệ thống sử dụng MongoDB với các collection chính có liên kết logic chặt chẽ:

  • users: Lưu trữ thông tin người dùng, mật khẩu băm (bcrypt), role ID tham chiếu.
  • roles_permissions: Quản lý danh sách quyền chi tiết (resource, action: create|read|update|delete).
  • devices: Quản lý định danh màn hình (device_code, status: online|offline, ip_address, current_playlist_id, last_ping).
  • advertisements: Thông tin quảng cáo (title, duration, layout_config, media_assets).
  • playlists: Danh sách phát theo thời gian (schedules: [{start_time, end_time, days_of_week}]).

Thiết kế API Endpoints chính

POST   /api/v1/auth/sign-in         --> Xác thực người dùng, trả về JWT token
GET    /api/v1/devices              --> Lấy danh sách thiết bị kèm trạng thái kết nối
POST   /api/v1/devices/register     --> Màn hình SCP đăng ký token định danh vào hệ thống
POST   /api/v1/advertisements       --> Tạo mới quảng cáo với cấu hình phân vùng
PUT    /api/v1/devices/:id/assign   --> Gán danh sách phát cho thiết bị cụ thể
POST   /api/v1/media/presigned-url  --> Sinh URL tải lên trực tiếp lưu trữ đám mây

Phương pháp luận (Methodology)

Dự án áp dụng mô hình phát triển phần mềm Agile/Scrum với các chu kỳ Sprint 2 tuần:

  • Sprint 1 - 2: Khảo sát yêu cầu, thiết kế kiến trúc hệ thống, dựng khung REST API và Database Schema.
  • Sprint 3 - 4: Xây dựng module Real-time Socket Cluster với Redis Pub/Sub và Dashboard quản trị ReactJS.
  • Sprint 5 - 6: Phát triển ứng dụng Electron Player, cơ chế giải mã video phần cứng và lưu đệm Offline.
  • Sprint 7 - 8: Đóng gói Docker, cấu hình Deployment/Service trên Kubernetes và kiểm thử chịu tải.
┌────────────────────────────────────────────────────────────────────────────┐
│                    TIẾN ĐỘ THỰC HIỆN DỰ ÁN (16 TUẦN)                       │
├───────────────┬───────────────────────────────────────────┬────────────────┤
│ Tuần 01 - 04  │ Nghiên cứu lý thuyết & Thiết kế hệ thống  │ 25% hoàn thành │
│ Tuần 05 - 08  │ Lập trình Core API & Real-time Service    │ 50% hoàn thành │
│ Tuần 09 - 12  │ Phát triển Electron Player & Dashboard    │ 75% hoàn thành │
│ Tuần 13 - 16  │ Triển khai GKE, Load Test & Tối ưu hóa   │ 100% nghiệm thu│
└───────────────┴───────────────────────────────────────────┴────────────────┘

Implementation và kết quả

Quy trình phát triển và thuật toán cốt lõi

1. Xử lý đồng bộ dữ liệu đa Pod qua Socket.io Redis Adapter

Khi hệ thống scale ngang thành nhiều Pod trên Kubernetes, kết nối WebSocket của các màn hình SCP sẽ nằm rải rác ở các máy chủ khác nhau. Hệ thống sử dụng Redis Adapter để tạo cơ chế phát sóng sự kiện (Event Broadcast) đồng bộ tức thì.

// Cấu hình Socket.io Cluster với Redis Adapter trên Node.js Backend
const express = require('express');
const http = require('http');
const { Server } = require('socket.io');
const redisAdapter = require('socket.io-redis');

const app = express();
const server = http.createServer(app);
const io = new Server(server, {
  cors: { origin: "*", methods: ["GET", "POST"] },
  transports: ['websocket', 'polling']
});

// Kết nối Redis để đồng bộ trạng thái giữa các Pod
io.adapter(redisAdapter({ host: process.env.REDIS_HOST, port: 6379 }));

io.on('connection', (socket) => {
  const deviceId = socket.handshake.query.deviceId;
  if (deviceId) {
    socket.join(`device:${deviceId}`);
    console.log(`[SCP Connected] Thiết bị: ${deviceId} đã kết nối vào room.`);
  }

  socket.on('disconnect', () => {
    console.log(`[SCP Disconnected] Thiết bị: ${deviceId} ngắt kết nối.`);
  });
});

// Hàm phát lệnh thay đổi quảng cáo từ Dashboard xuống thiết bị cụ thể
function pushAdUpdate(deviceId, adData) {
  io.to(`device:${deviceId}`).emit('AD_UPDATE_EVENT', {
    timestamp: new Date().toISOString(),
    payload: adData
  });
}

2. Luồng tải lên media tối ưu qua Direct-to-Cloud Presigned URL

Nhằm tránh việc truyền tải file video hàng trăm Megabytes qua API Server gây nghẽn Event Loop của Node.js, hệ thống áp dụng luồng Presigned URL trực tiếp từ trình duyệt đến Cloud Storage:

[React Dashboard] ── 1. Request Presigned URL ──► [Express API Server]
[React Dashboard] ◄── 2. Return Signed Upload URL ─ [Express API Server]
[React Dashboard] ── 3. Upload Binary File Direct ──► [Cloud Storage (S3/Cloudinary)]
[React Dashboard] ── 4. Save Media Metadata URL ──► [Express API Server -> MongoDB]

3. Client Signage Content Player (ElectronJS) và cơ chế Offline

Ứng dụng SCP chạy trên máy client sử dụng mô hình 2 luồng (Main Process và Renderer Process). Main Process chịu trách nhiệm quản lý kết nối socket nền và tải trước (preload) các tài nguyên video vào ổ đĩa cục bộ.

// Electron Client - Quản lý lưu đệm và phát quảng cáo ngoại tuyến
const { app, BrowserWindow, ipcMain } = require('electron');
const io = require('socket.io-client');
const fs = require('fs');
const path = require('path');

let mainWindow;
const socket = io('https://ad-management.me', {
  query: { deviceId: 'DEVICE_ROOM_01' },
  reconnection: true,
  reconnectionDelay: 1000,
  reconnectionAttempts: Infinity
});

// Nhận sự kiện cập nhật quảng cáo từ Cloud
socket.on('AD_UPDATE_EVENT', async (eventData) => {
  const { mediaUrl, layoutConfig } = eventData.payload;
  // Tải trước tài nguyên xuống cache cục bộ trước khi hiển thị
  const localCachePath = path.join(app.getPath('userData'), 'cache_ad.mp4');
  await downloadMediaFile(mediaUrl, localCachePath);
  
  // Gửi chỉ thị sang giao diện Renderer để chuyển bài phát mượt mà
  mainWindow.webContents.send('RENDER_AD_EVENT', {
    localPath: `file://${localCachePath}`,
    layout: layoutConfig
  });
});

Kiểm thử và đánh giá hiệu năng

Kiểm thử hệ thống được thực hiện trên môi trường Google Kubernetes Engine với công cụ kiểm thử tải Artillery và JMeter.

Kịch bản kiểm thử Số lượng kết nối / Requests Thời gian phản hồi trung bình (ms) Tỷ lệ thành công (%) Tải CPU / RAM Máy chủ
REST API Query (Danh sách thiết bị) 5.000 req/s 38 ms 100% CPU 32%, RAM 45%
Socket Connection Spike (Màn hình mở đồng loạt) 20.000 concurrent sockets 74 ms (Handshake) 99.98% CPU 48%, RAM 62%
Broadcast Ad Event (Phát lệnh đổi quảng cáo) 10.000 devices cùng lúc 82 ms 100% CPU 55%, RAM 58%
Video Playback Offline Switch Ngắt đột ngột mạng Internet 0 ms (Phát từ Cache) 100% (Không đen màn hình) Ổn định ở mức 15% CPU Client 
KẾT QUẢ ĐỘ TRỄ PHẢN HỒI THEO TẢI KẾT NỐI
Độ trễ (ms)
 100 ┌─────────────────────────────────────────────────────────────┐
  80 │                                                 ● (82ms)    │
  60 │                                   ● (74ms)                  │
  40 │                     ● (38ms)                                │
  20 │       ● (18ms)                                              │
   0 └───────┴─────────────┴─────────────┴─────────────┴───────────┘
           1.000         5.000        10.000        20.000   (Connections)

Kết quả đạt được so với mục tiêu ban đầu

  • Chức năng hoàn thành: Đạt 100% các yêu cầu nghiệp vụ đề ra (Quản lý User/Merchant, Thiết bị, Quảng cáo, Lập lịch biểu, Cấu hình Layout, Tải media trực tiếp).
  • Tính sẵn sàng và độ tin cậy: Hệ thống chạy thử nghiệm liên tục trong 30 ngày trên cụm Kubernetes Cluster, không phát sinh tình trạng rò rỉ bộ nhớ (Memory Leak) trên cả máy chủ Node.js và ứng dụng Electron Player.
  • Trải nghiệm người dùng: Giao diện React Dashboard chuẩn Single Page Application (SPA), thời gian tải trang đầu tiên dưới 1,2 giây nhờ kỹ thuật Lazy Loading và tối ưu Bundle Size.

Đổi mới và đóng góp

Điểm đột phá kỹ thuật

  1. Kiến trúc phân tán thời gian thực chuẩn Cloud-Native: Thay thế toàn bộ kiến trúc Server-rendered (LAMP/PHP) bằng mô hình Single Page Application (ReactJS) kết hợp REST API microservices và Socket.io Cluster hỗ trợ bởi Redis Pub/Sub, cho phép đồng bộ hóa dữ liệu xuống màn hình dưới 100ms.
  2. Kỹ thuật Decoupled Media Streaming: Tách biệt hoàn toàn việc lưu trữ/phân phối tệp video ra khỏi máy chủ xử lý logic bằng Cloud Storage và Presigned URL, giúp tiết kiệm hơn 85% chi phí băng thông máy chủ.
  3. Player đa nền tảng với kiến trúc xử lý kép: Tận dụng Chromium và Node.js trong ElectronJS giúp chạy được trên nhiều hệ điều hành (Windows, Ubuntu, Raspberry Pi OS), hỗ trợ lưu đệm thông minh giải quyết triệt để lỗi màn hình đen khi đứt cáp mạng.
SO SÁNH CÁC CHỈ SỐ VẬN HÀNH GIỮA CÁC THẾ HỆ HỆ THỐNG
─────────────────────────────────────────────────────────────────────────────
Chỉ số                     Hệ thống USB cũ    Hệ thống LAMP    Giải pháp Đề tài
─────────────────────────────────────────────────────────────────────────────
Thời gian đẩy chiến dịch   24 - 48 giờ        15 - 30 phút     < 1 giây
Chi phí nhân sự cập nhật   Rất tốn kém        Thấp             Gần như bằng 0
Độ trễ báo lỗi thiết bị    Phải báo thủ công  5 - 10 phút      Thời gian thực
Hiệu suất giải phóng mạng  Không áp dụng      Kém              Tối ưu 85%
─────────────────────────────────────────────────────────────────────────────

Ứng dụng thực tế và triển khai

Kịch bản ứng dụng trong doanh nghiệp

  • Tòa nhà văn phòng & Chung cư cao tầng: Quản lý hàng nghìn màn hình thang máy, tự động đổi nội dung quảng cáo sang thông báo khẩn cấp (báo cháy, bảo trì tòa nhà) ngay lập tức từ trung tâm điều hành.
  • Chuỗi bán lẻ & Siêu thị: Điều chỉnh giá và menu điện tử (Digital Menu Board) theo khung giờ trong ngày (sáng/trưa/tối) trên toàn bộ hệ thống cửa hàng chỉ với một thao tác trên Dashboard.
  • Sân bay & Nhà ga: Hiển thị thông tin lịch trình chuyến bay đan xen các banner quảng cáo tương tác theo vị trí địa lý.
KỊCH BẢN TRIỂN KHAI PHÂN TẦNG VẬN HÀNH
[Trung tâm điều hành CMS]
        │
        ├──► Tòa nhà Landmark (50 màn hình thang máy) ──► Phát Video 4K + Tin tức
        ├──► Chuỗi Nhà thuốc (200 màn hình quầy thuốc) ──► Phát Banner khuyến mãi
        └──► Trường Đại học (30 Kiosk thông tin)     ──► Phát Thông báo lịch thi

Chiến lược triển khai hạ tầng (Deployment Blueprint)

Hệ thống được đóng gói hoàn toàn dưới dạng các Docker Container và triển khai qua Kubernetes Manifests:

# Cấu hình Kubernetes Deployment cho Backend Pods
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ad-management-backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ad-backend
  template:
    metadata:
      labels:
        app: ad-backend
    spec:
      containers:
      - name: backend-node
        image: gcr.io/uit-digital-signage/backend:v1.0.0
        ports:
        - containerPort: 5000
        env:
        - name: MONGO_URI
          valueFrom:
            secretKeyRef:
              name: app-secrets
              key: mongo-uri
        resources:
          limits:
            cpu: "1000m"
            memory: "1024Mi"
          requests:
            cpu: "250m"
            memory: "512Mi"

Đánh giá hiệu quả kinh tế và lộ trình hoàn vốn (ROI)

Khảo sát trên quy mô một doanh nghiệp vận hành mạng lưới 500 màn hình quảng cáo:

  • Chi phí định kỳ hệ thống cũ: Nhân sự bảo trì & cập nhật USB: ~40.000.000 VNĐ/tháng.
  • Chi phí vận hành hệ thống Cloud đề xuất: Máy chủ Cloud (GKE/MongoDB Atlas/Cloudinary): ~6.500.000 VNĐ/tháng.
  • Mức tiết kiệm chi phí: Giảm 83,75% chi phí vận hành hàng tháng, điểm hòa vốn đầu tư phần mềm đạt được sau 3,5 tháng.

Hạn chế và hướng phát triển

Những hạn chế kỹ thuật còn tồn tại

  • Tài nguyên phần cứng Client: ElectronJS yêu cầu cấu hình phần cứng tối thiểu RAM 1GB để vận hành mượt mà, gây khó khăn cho các vi máy tính (Single Board Computer) đời cũ có cấu hình quá yếu.
  • Xử lý băng thông cục bộ: Khi tải hàng loạt tệp video chất lượng 4K cùng lúc trong cùng một mạng LAN, hệ thống có thể gây nghẽn đường truyền cục bộ nếu không có cơ chế giới hạn tốc độ (Rate Limiting).

Hướng phát triển trong tương lai

  1. Tích hợp Trí tuệ Nhân tạo tại biên (Edge AI): Ứng dụng mô hình nhận diện khuôn mặt nhẹ (TensorFlow Lite/OpenCV) trên camera gắn kèm màn hình để đếm số lượng ánh nhìn, phân tích độ tuổi, cảm xúc và cá nhân hóa nội dung quảng cáo tức thì.
  2. Chuyển đổi Client sang WebAssembly / C++ Core: Tối ưu hóa Signage Player để chạy trên các thiết bị IoT nhúng cực nhẹ như ESP32 hoặc Android Box giá rẻ.
  3. Mở rộng sàn giao dịch vị trí quảng cáo (Programmatic Ad Network): Kết nối API với các mạng quảng cáo trực tuyến lớn nhằm tối đa hóa tỷ lệ lấp đầy màn hình trống (Fill Rate).

Đối tượng hưởng lợi

1. Sinh viên và Giảng viên ngành CNTT / Hệ thống Thông tin

  • Giá trị thực tiễn: Cung cấp tài liệu tham khảo hoàn chỉnh từ thiết kế kiến trúc phân tán, lập trình Fullstack (MERN + Electron) đến quy trình DevOps/Cloud Deployment chuẩn công nghiệp.
  • Ứng dụng: Làm mẫu nghiên cứu điển hình cho các môn học Kiến trúc phần mềm, Hệ thống phân tán và Phát triển ứng dụng Web/Desktop.

2. Kỹ sư phát triển phần mềm (Software Engineers)

  • Kinh nghiệm kỹ thuật: Nắm vững giải pháp xử lý kết nối WebSocket Cluster quy mô lớn thông qua Redis Adapter, phương pháp tối ưu tải tệp tin đa phương tiện qua Presigned URL và kiến trúc quản trị Desktop App bằng Electron.

3. Doanh nghiệp và Đơn vị vận hành quảng cáo (Media Agencies)

  • Hiệu quả kinh doanh: Cắt giảm hơn 80% chi phí vận hành bảo trì, giảm thiểu rủi ro phát sai lịch trình, tăng độ tin cậy của báo cáo nghiệm thu phát sóng đối với các nhãn hàng đối tác.

Câu hỏi thường gặp

1. Yêu cầu cấu hình tối thiểu để thiết bị đầu cuối chạy được Signage Player là gì?

Thiết bị cần CPU x86 hoặc ARM (tương đương Raspberry Pi 4), RAM tối thiểu 1GB (khuyến nghị 2GB), bộ nhớ trong trống 8GB (SSD/eMMC) và hệ điều hành Ubuntu 18.04 LTS, Windows 10 hoặc Android 8.0 trở lên.

2. Khi hệ thống mở rộng lên hàng trăm ngàn màn hình, cụm máy chủ cần cấu hình như thế nào?

Cần kích hoạt cơ chế Horizontal Pod Autoscaler (HPA) trên Kubernetes dựa trên chỉ số CPU (>70%) và số lượng Active Socket Connections. Tại tầng cơ sở dữ liệu, triển khai Sharding trên MongoDB theo merchantId và sử dụng Redis Cluster đa node để phân tải Pub/Sub.

3. Màn hình quảng cáo có hoạt động bình thường nếu bị đứt mạng Internet không?

Có. Nhờ cơ chế bộ nhớ đệm ngoại tuyến (Offline Local Storage) trên Electron Player, video và lịch phát đã tải về sẽ tiếp tục chạy lặp vô tận theo đúng cấu hình gần nhất cho đến khi có kết nối mạng trở lại để nhận cập nhật mới.

4. Hệ thống bảo vệ dữ liệu và ngăn chặn việc màn hình bị hack phát nội dung độc hại như thế nào?

Hệ thống sử dụng xác thực đa lớp: Giao thức mã hóa WSS/HTTPS với chứng chỉ TLS 1.3, định danh thiết bị bằng chuỗi mã hóa phần cứng duy nhất (Hardware Device Fingerprint), xác thực người dùng bằng JWT thuật toán RS256 và phân quyền nghiêm ngặt theo RBAC.

5. Chi phí triển khai hệ thống đám mây ban đầu có đắt không?

Mô hình đám mây cho phép bắt đầu với mức chi phí rất thấp (dưới $30/tháng cho cụm máy chủ thử nghiệm 50 màn hình) và chỉ tăng dần theo số lượng thiết bị thực tế nhờ tính chất linh hoạt của dịch vụ Cloud Pay-as-you-go.

Kết luận

Đề tài "Thiết kế và triển khai hệ thống quảng cáo điện tử trên nền tảng đám mây" của nhóm sinh viên Khoa Hệ thống Thông tin - Trường Đại học Công nghệ Thông tin (ĐHQG TP.HCM) đã giải quyết triệt để những bất cập cố hữu của các hệ thống Digital Signage truyền thống tại Việt Nam.

Bằng việc kết hợp nhuần nhuyễn giữa ngăn xếp công nghệ hiện đại MERN Stack, ứng dụng đa nền tảng ElectronJS, mạng lưới đồng bộ thời gian thực Socket.io/Redis, và hạ tầng ảo hóa Kubernetes/Docker, đề tài đã xây dựng thành công một giải pháp quản lý tập trung, có tính sẵn sàng cao, độ trễ cực thấp (<100ms) và tối ưu hóa chi phí vận hành cho doanh nghiệp.

Hệ thống không chỉ đóng vai trò là một công trình nghiên cứu tốt nghiệp xuất sắc mà còn là nền tảng vững chắc, sẵn sàng tích hợp các công nghệ tương lai như Trí tuệ nhân tạo (Edge AI) và Tự động hóa quảng cáo số nhằm thúc đẩy quá trình chuyển đổi số trong ngành truyền thông đa phương tiện.