Cloud DE 8 — Kiến trúc nền tảng dữ liệu cloud ngân hàng

Từ các mảnh rời tới một bức tranh

Bảy bài trước đã tháo rời nền tảng dữ liệu cloud thành từng bộ phận: tổng quan mô hình dịch vụ & vùng, lưu trữ, tính toán, mạng & bảo mật, dịch vụ managed, hạ tầng bằng mã (IaC), và chi phí & độ tin cậy. Bài cuối này lắp chúng lại thành một kiến trúc tham chiếu (reference architecture) — bản vẽ mà một team dữ liệu ngân hàng Việt Nam có thể dùng làm điểm khởi đầu, rồi cắt gọt theo ràng buộc thực tế.

Điểm mấu chốt: với ngân hàng, kiến trúc không chỉ là các hộp kỹ thuật xếp cạnh nhau. Nó bị ràng buộc trước bởi tuân thủ, chủ quyền dữ liệu (data residency) và khẩu vị rủi ro. Vì vậy bài này đi theo trình tự: (1) kiến trúc phân lớp end-to-end, (2) các mảng bao quanh (mạng, bảo mật, governance, FinOps, DR), (3) landing zone, (4) tuân thủ & data residency đặc thù VN, (5) chiến lược migration, (6) bảng chọn cách tiếp cận, (7) checklist go-live và cạm bẫy.

Kiến trúc phân lớp end-to-end

Nền tảng dữ liệu hiện đại chia thành các lớp (layer) nối tiếp nhau: dữ liệu chảy từ nguồn nghiệp vụ tới nơi phục vụ báo cáo, mô hình và API. Mỗi lớp dùng lại đúng các dịch vụ đã bàn ở bài trước.

Nguồn (source)

Trong ngân hàng, nguồn dữ liệu thường là hệ thống lõi chạy on-prem: core banking (sổ cái, tài khoản, khoản vay), hệ thống thẻ (card management, giao dịch thẻ), kênh số (mobile app, internet banking, ATM), cùng dữ liệu bên thứ ba (credit bureau, tỷ giá). Đặc điểm: dữ liệu nhạy cảm, thay đổi liên tục, và không được phép làm chậm hệ thống giao dịch trực tuyến (OLTP).

Ingestion & CDC

Có ba kiểu nạp dữ liệu:

• CDC (Change Data Capture) log-based: đọc redo/binlog của database nguồn để bắt thay đổi gần thời gian thực mà không truy vấn trực tiếp bảng nghiệp vụ (tránh tải OLTP). Đây là cách ưu tiên cho core banking.
• Batch ETL / file: bảng snapshot cuối ngày, file trích xuất — hợp với dữ liệu ít biến động hoặc hệ thống không mở CDC.
• Streaming events: sự kiện từ kênh số (đăng nhập, giao dịch) qua message bus.

Landing / Raw trên data lake

Dữ liệu nạp vào rơi xuống object storage (bài 2) ở dạng thô, bất biến (immutable), có phân vùng theo ngày/nguồn. Đây là "nguồn sự thật" nguyên bản để tái xử lý khi logic thay đổi.

Lakehouse: bronze / silver / gold

Trên nền lake, dùng table format (Delta Lake, Apache Iceberg, Hudi) để có giao dịch ACID, time-travel và schema trên object storage — đó là ý tưởng cốt lõi của kiến trúc lakehouse. Dữ liệu đi qua ba tầng medallion:

• Bronze: dữ liệu thô đã gắn schema, gần như 1-1 với nguồn.
• Silver: đã làm sạch, khử trùng lặp, chuẩn hoá kiểu, ghép CDC thành trạng thái hiện tại.
• Gold: mô hình nghiệp vụ sẵn dùng — dim/fact, aggregate, feature.

Warehouse / Serving

Tầng Gold được nạp (hoặc query trực tiếp) qua data warehouse hoặc engine serving/OLAP tốc độ cao (bài 5) để BI truy vấn với độ trễ thấp và đồng thời cao.

Tiêu thụ (consumption)

Ba nhóm người dùng: BI/dashboard (báo cáo quản trị, giám sát rủi ro), ML/feature store (mô hình chấm điểm tín dụng, phát hiện gian lận), và Data API / data product (cung cấp dữ liệu cho ứng dụng khác qua giao diện có kiểm soát).

Các mảng bao quanh (cross-cutting)

Bảy mảng dưới đây không nằm ở một lớp mà xuyên suốt toàn kiến trúc. Bỏ sót bất kỳ mảng nào cũng biến nền tảng thành nợ kỹ thuật.

Nguyên tắc chung với ngân hàng: mọi luồng dữ liệu nhạy cảm phải đi qua mạng riêng, mã hoá đầu-cuối, khoá do ngân hàng quản (BYOK/CMK), và mọi truy cập đều để lại vết audit.

Landing zone ngân hàng

Landing zone là bộ khung nền — cách tổ chức tài khoản/subscription, mạng, bảo mật và guardrail — được dựng trước khi bất kỳ workload nào lên cloud. Với ngân hàng, một landing zone điển hình gồm:

• Multi-account / multi-subscription: tách account theo mục đích và môi trường (security, network hub, log-archive, shared-services, và account riêng cho dev/test/prod của nền tảng dữ liệu). Tách account = tách "bán kính nổ" (blast radius) và tách hoá đơn.
• Guardrail: chính sách tổ chức (SCP/Policy) chặn cứng những hành vi cấm — ví dụ cấm tạo tài nguyên ngoài region cho phép, cấm bucket public, buộc bật mã hoá.
• Security baseline: bật log trung tâm (audit trail), giám sát cấu hình sai lệch, quét lỗ hổng, quản khoá tập trung — đồng nhất mọi account ngay từ đầu.
• Network hub-spoke: một hub mạng kết nối on-prem (qua kênh riêng/VPN), các spoke là môi trường workload, đi kèm firewall tập trung.

Landing zone nên được sinh bằng IaC để mỗi account mới ra đời đã tuân thủ baseline, không phụ thuộc thao tác tay.

Tuân thủ & data residency (đặc thù VN)

Đây là mảng khác biệt lớn nhất giữa nền tảng dữ liệu ngân hàng và một startup thông thường.

• Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân (NĐ13): đặt ra yêu cầu về sự đồng ý, mục đích xử lý, quyền của chủ thể dữ liệu, đánh giá tác động và nghĩa vụ bảo vệ dữ liệu cá nhân/dữ liệu cá nhân nhạy cảm.
• Yêu cầu của NHNN và quy định ngành ngân hàng về an toàn hệ thống thông tin, lưu trữ, sao lưu và kiểm soát truy cập dữ liệu khách hàng.
• Data residency / localization: nhiều loại dữ liệu (đặc biệt dữ liệu khách hàng nhạy cảm) trên thực tế được nhiều ngân hàng chọn giữ trong nước hoặc trong hạ tầng do ngân hàng kiểm soát, để giảm rủi ro pháp lý và tuân thủ.

Hệ quả kiến trúc: phân loại dữ liệu (data classification) trở thành bước bắt buộc trước khi quyết định cái gì được lên cloud công cộng.

Vì vậy nhiều ngân hàng VN chọn hybrid: lõi giao dịch và dữ liệu tối nhạy cảm ở on-prem/private cloud trong nước, còn phân tích, ML trên dữ liệu đã ẩn danh/giả danh (anonymize/pseudonymize) hoặc token hoá thì đưa lên cloud công cộng. (Tình hình pháp lý thay đổi theo thời gian — luôn kiểm tra quy định hiện hành với bộ phận pháp chế/tuân thủ.)

Migration on-prem → cloud

Ngân hàng hiếm khi "xây mới trên nền trống". Thường là di chuyển một nền tảng dữ liệu on-prem có sẵn. Khung phổ biến là 6R — sáu chiến lược ứng với từng workload:

Lift-and-shift vs re-architecture: lift-and-shift đi nhanh, rủi ro thấp lúc đầu nhưng thường không tận dụng ưu thế cloud (vẫn trả tiền cho máy chạy 24/7, khó co giãn). Re-architecture cho lợi ích dài hạn (tách lưu trữ khỏi tính toán, serverless, chi phí theo dùng) nhưng tốn công và rủi ro cao hơn. Thực tế ngân hàng thường kết hợp: rehost trước để rời data center, sau đó tái kiến trúc dần từng workload.

Về di chuyển dữ liệu: khối lượng lớn nên chuyển tải nền (bulk) một lần qua kênh riêng băng thông cao, rồi bật CDC để đồng bộ delta cho tới khi cắt chuyển. Kỹ thuật chạy song song (parallel run) — vận hành cả hệ cũ và mới, đối chiếu kết quả cho tới khi khớp — là chuẩn mực với hệ thống rủi ro cao như ngân hàng, vì nó cho phép rollback an toàn.

Ví dụ minh hoạ logic đối chiếu (reconciliation) giữa nền tảng cũ và mới (chỉ minh hoạ, không đánh dấu chạy được):

-- Đối chiếu số dư tổng theo loại tiền giữa hệ cũ (nguồn) và Gold (đích)
-- Minh hoạ ý tưởng parallel run; giả định có 2 view legacy_balances và gold_balances
SELECT
  COALESCE(l.currency, g.currency)      AS currency,
  l.total_balance                       AS legacy_total,
  g.total_balance                       AS cloud_total,
  g.total_balance - l.total_balance     AS diff
FROM legacy_balances l
FULL OUTER JOIN gold_balances g ON l.currency = g.currency
WHERE l.total_balance IS DISTINCT FROM g.total_balance;

Rủi ro migration cần quản: mất/lệch dữ liệu (giải bằng đối chiếu), tăng độ trễ khi cắt chuyển, phụ thuộc chuyên gia hệ cũ, và chi phí chạy song song đội lên trong giai đoạn chuyển tiếp.

Chọn cách tiếp cận theo ràng buộc ngân hàng

Không có kiến trúc "đúng cho mọi ngân hàng". Bảng dưới giúp chọn theo ràng buộc:

Đa số ngân hàng VN hiện thực dụng: single-cloud + hybrid — một nhà cung cấp chính để đơn giản hoá, kết hợp on-prem cho phần lõi. Multi-cloud thật sự (chạy cùng workload trên nhiều cloud) tốn chi phí phức tạp lớn và thường chỉ dùng cho DR hoặc yêu cầu chính sách cụ thể.

Checklist go-live nền tảng dữ liệu cloud

Trước khi đưa nền tảng vào vận hành thật:

• Landing zone dựng bằng IaC, guardrail & security baseline đã bật trên mọi account.
• Data classification hoàn tất; đã map dữ liệu nào được lên cloud công cộng, dữ liệu nào không.
• Mọi luồng nhạy cảm đi qua mạng riêng + Private Link, không lối ra internet.
• Mã hoá at-rest/in-transit bật toàn bộ; khoá quản qua KMS (ưu tiên BYOK/CMK).
• IAM least-privilege; không còn quyền admin rộng; MFA bắt buộc cho quyền cao.
• Catalog + lineage hoạt động; kiểm soát truy cập theo cột/hàng cho PII.
• Observability: log tập trung, cảnh báo chất lượng dữ liệu & độ trễ pipeline.
• DR đã kiểm chứng: đo được RTO/RPO, đã chạy thử failover thật.
• FinOps: tag chi phí đầy đủ, ngân sách & cảnh báo, đã right-size.
• Đối chiếu parallel run đạt ngưỡng khớp; có kế hoạch rollback.
• Ký duyệt của bộ phận tuân thủ/pháp chế & bảo mật thông tin.

Cạm bẫy thường gặp

• Vendor lock-in: dùng dịch vụ độc quyền quá sâu khiến khó rời. Giảm nhẹ bằng table format mở (Iceberg/Delta), lưu ở object storage chuẩn, và tách logic khỏi dịch vụ độc quyền khi hợp lý.
• Chi phí vượt (cost overrun): cụm chạy 24/7 không cần thiết, dữ liệu không tiering, không tag. FinOps phải bật từ ngày đầu, không phải khi hoá đơn giật mình.
• Cấu hình sai lộ dữ liệu (misconfiguration): bucket để public, security group mở toang — nguyên nhân số một của rò rỉ dữ liệu cloud. Guardrail và quét cấu hình liên tục là bắt buộc.
• Bỏ qua tuân thủ: đưa PII lên cloud công cộng mà chưa phân loại/ẩn danh, không có vết audit. Với ngân hàng, đây là rủi ro pháp lý nghiêm trọng, không chỉ là nợ kỹ thuật.

Tổng kết series — bản đồ 8 bài

Tám bài đi từ khái niệm nền (bài 1) qua từng khối xây dựng (bài 2–6), tới cách vận hành tốt (bài 7), và cuối cùng ghép tất cả thành kiến trúc tham chiếu có ràng buộc ngân hàng (bài 8). Trục xuyên suốt: object storage làm nền → lakehouse ở giữa → serving/BI/ML/API ở trên → mạng-bảo mật-governance-FinOps-DR bao quanh.

Use case thực tế

Bối cảnh: Một ngân hàng VN có core banking on-prem, muốn xây nền tảng phân tích & ML rủi ro tín dụng trên cloud, nhưng dữ liệu khách hàng thuộc diện phải kiểm soát chặt theo NĐ13 và quy định NHNN.

Cách làm (hybrid, single-cloud):

1. Phân loại dữ liệu: đánh nhãn PII (họ tên, CMND/CCCD, số tài khoản) là "bảo mật", số thẻ đầy đủ là "tối mật". Bảng tổng hợp/hành vi đã ẩn danh là "nội bộ".
2. Landing zone: dựng multi-account bằng IaC, bật guardrail cấm bucket public và cấm region ngoài danh sách; log tập trung.
3. Ingestion: CDC log-based từ core banking đẩy qua kênh riêng (Private Link) vào landing zone; token hoá số thẻ/CCCD ngay tại biên trước khi ghi vào lake.
4. Lakehouse: Bronze→Silver→Gold trên table format; Gold chứa feature đã ẩn danh phục vụ mô hình chấm điểm tín dụng.
5. Serving: warehouse cho BI rủi ro; feature store cho ML.
6. Vận hành: DR multi-AZ với RTO/RPO đo được; FinOps tag theo phòng ban; audit mọi truy cập PII.
7. Kết quả: dữ liệu tối nhạy cảm (số thẻ gốc) không rời vùng ngân hàng kiểm soát; cloud chỉ giữ dữ liệu đã token hoá/ẩn danh — vừa tận dụng sức tính, vừa giữ đúng ranh giới tuân thủ.

Ghi nhớ

• Kiến trúc tham chiếu = các lớp (nguồn → ingestion/CDC → raw → lakehouse bronze/silver/gold → serving → BI/ML/API) + các mảng bao quanh (mạng riêng, IAM/KMS, governance, observability, IaC, FinOps, DR).
• Với ngân hàng, tuân thủ & data residency đi trước kiến trúc: phân loại dữ liệu quyết định cái gì được lên cloud công cộng; NĐ13 và quy định NHNN là ràng buộc thật.
• Landing zone (multi-account, guardrail, security baseline) phải dựng bằng IaC trước mọi workload.
• Migration theo 6R; thực tế thường rehost trước rồi tái kiến trúc dần. Dùng CDC + parallel run + đối chiếu để cắt chuyển an toàn.
• Đa số ngân hàng VN chọn single-cloud + hybrid: lõi & dữ liệu tối nhạy cảm giữ trong nước, phân tích/ML chạy trên dữ liệu ẩn danh/token hoá.
• Cạm bẫy lớn: lock-in, chi phí vượt, cấu hình sai lộ dữ liệu, bỏ qua tuân thủ — phòng bằng format mở, FinOps từ ngày đầu, guardrail, và ký duyệt tuân thủ trong checklist go-live.