VNeID – Khi hệ thống quốc gia đối mặt traffic toàn dân

Hung Nguyen 0 Nhận xét


Bối cảnh Case Study

Ứng dụng VNeID – Cơ sở dữ liệu quốc gia về dân cư vừa gặp sự cố quá tải khi hàng chục triệu người dân đồng loạt đăng nhập để xác thực, nhận hỗ trợ 100k.
  • Bình thường: người dân chỉ vào 1–2 lần/năm.
  • Cao điểm: toàn dân truy cập trong vài giờ -> traffic tăng hàng trăm lần.
Đây chính là case study điển hình về burst traffic – một trong những thách thức lớn nhất khi thiết kế hệ thống quy mô quốc gia.

Anh em kỹ thuật thì nhìn chung đang chia ra 2 quan điểm để tranh luận

Quan điểm: Dev kém, hệ thống không tối ưu nên sập

Lập luận của quan điểm này thường thấy là: 
  • Ứng dụng quản lý dữ liệu dân cư quốc gia là national critical system -> không được phép downtime trong tình huống cao điểm quốc gia.
  • Kiến trúc tốt phải anticipate peak traffic, ví dụ như tax filing season (Mỹ), election day (Ấn Độ), hoặc Black Friday (Amazon).
  • Công nghệ hiện nay hoàn toàn có giải pháp:
    • Autoscaling cloud infra: scale-out thêm node khi tải tăng.
    • Queue + async processing: người dùng vào xếp hàng, không timeout 500.
    • Caching + CDN: không để 100% request đâm thẳng vào DB.
  • Thực tế, nếu app sập chỉ vì vài triệu request cùng lúc -> cho thấy chưa làm kiến trúc hiệu năng nghiêm túc.
Ví dụ tương đồng:

=> Ở góc nhìn này: đúng là có lỗi ở khâu thiết kế hệ thống và quản lý hạ tầng.

Quan điểm: Đây là case đặc biệt, đầu tư dự phòng là lãng phí

Lập luận của quan điểm này thường thấy là: 
  • Bình thường người dân 3–6 tháng mới vào 1 lần -> hệ thống idle, chỉ vài nghìn concurrent user.
  • Đầu tư hạ tầng “luôn luôn chịu tải 100% dân số là over-provisioning, cực kỳ tốn kém.
  • Ví dụ:
    • Để chịu nổi peak vài chục triệu user, bạn cần cluster khủng, băng thông khủng, DB phân tán → chi phí hạ tầng & vận hành hàng trăm tỷ/năm.
    • Trong khi bình thường thì cluster đó gần như… ngồi chơi xơi nước.
  • Giải pháp thường thấy:
    • Accept partial outage (người dân vào chậm hơn, retry sau vài giờ).
    • Truyền thông phân tán thời gian truy cập (giống kiểu chia theo ngày sinh vào nộp hồ sơ).
    • Vì hệ thống hành chính không phải e-commerce -> trải nghiệm chậm 1–2 ngày vẫn chấp nhận được.

=> Ở góc nhìn này: sập trong vài ngày cao điểm là trade-off hợp lý giữa chi phí & lợi ích.


Quan điểm cá nhân của mình

Mình thiên về hướng thứ 2 nhưng với trách nhiệm kỹ thuật vẫn phải có phương án kỹ.
  • Không thể đổ hết lỗi cho dev.
  • Đây là use case burst traffic bất thường -> giải quyết bằng design for peak, operate for average.
Nếu là SA của VNeID, mình nghĩ mình sẽ duy trì mindset là:
  • Không duy trì hạ tầng khủng thường xuyên, mà:
    • Sử dụng cloud burst / elastic scaling -> khi có sự kiện, tự động mở rộng ( mình không nghĩ phương án này khả thi, vì đây là dữ liệu dân cư, nó như chủ quyền lãnh thổ, cần bảo mật tuyệt đối)
    • Nếu vẫn on-prem -> có phương án thuê tạm thời (hybrid cloud) các server của các nhà cung cấp "nhà nước" như ViettelIDC, VNPT
  • Có queue/virtual waiting room: tránh cảnh toàn dân bấm vào cùng lúc rồi 500 error. Người dùng thấy Bạn đang trong hàng chờ số 123456 → chấp nhận hơn là crash.
  • Phân tầng truy cập: thông tin tĩnh (CMND, hộ khẩu, profile) nên cache/CDN ( cũng cần phải sử dụng hàng nội địa của Viettel, VNPT), chỉ khi nộp hồ sơ/tương tác nhạy cảm mới đi vào core DB.
Mình nghĩ, context khi để trade-off của dự án này với mình sẽ là
  • Traffic pattern:
    • 95% thời gian: thấp, thậm chí idle.
    • 5% thời gian: burst cực lớn, toàn dân truy cập.
  • Trade-off hạ tầng:
    • On-premise cluster luôn-on: tốn kém, lãng phí.
    • Cloud-native elastic: tối ưu hơn, nhưng cần chuẩn bị sẵn policy scale và ngân sách
  • Chiến lược kiến trúc khả thi:
    • Elastic scaling / Hybrid cloud
      • Ngày thường: hệ thống chạy on-prem ổn định.
      • Khi cao điểm: mở rộng sang cloud provider (Viettel, Mobifone, VNPT Cloud…), không sử dụng với các cloud ngoài Việt Nam.
    • Queue + Virtual Waiting Room
      • Người dân vào hệ thống nhưng được “xếp hàng ảo” thay vì crash.
      • UX chấp nhận được: “Bạn đang ở số 120.000 trong hàng chờ, vui lòng đợi 5 phút”.
    • Caching + CDN
      • Thông tin tĩnh (hồ sơ, dữ liệu cơ bản) cache toàn quốc với các POP đặt ở Viettel, VNPT Cloud
      • Giảm 70–80% áp lực DB core.
    • Event-driven architecture
      • Xử lý bất đồng bộ, tách load thành batch thay vì dồn một lúc.
      • Ví dụ: nhận yêu cầu trong queue, xử lý sau vài phút nhưng người dùng không bị timeout.

=> Nếu app sập hoàn toàn, không có queue, không có plan B -> thì đó là lỗi kiến trúc và triển khai (dev/ops).
=> Nhưng nếu chỉ chậm hoặc nghẽn vài ngày -> mình xem là acceptable trade-off, vì việc scale để chịu peak cực lớn mà hiếm khi xảy ra thì không cost-effective.

Kết luận

Sự cố của VNeID không nên nhìn đơn giản là “dev kém” hay “sự kiện bất khả kháng”.
  • Đây là bài học điển hình cho việc thiết kế hệ thống quốc gia: phải tính đến burst traffic, nhưng cũng phải cân nhắc chi phí dài hạn.
  • Giải pháp nằm ở kiến trúc linh hoạt:
    • Thiết kế cho peak, vận hành cho average.
    • Dùng elastic scaling, queue, cache để vừa tiết kiệm, vừa tránh crash toàn diện.
Biết đâu, sau đợt này, VNeID lại nuột gấp tỉ lần :D full-width
Tags

Hung Nguyen

Post a Comment

Đăng nhận xét

Mới hơn Cũ hơn