Cloud DE 1 — Tổng quan điện toán đám mây cho dữ liệu

Vì sao đám mây thay đổi cách làm dữ liệu

Với một data engineer, điện toán đám mây (cloud computing) không đơn thuần là "thuê máy chủ của người khác". Nó thay đổi tận gốc cách chúng ta thiết kế, vận hành và trả tiền cho hệ thống dữ liệu. Trước đây, muốn chạy một job Spark lớn cuối tháng, ta phải mua sẵn một cụm máy đủ mạnh cho ngày cao điểm nhất — rồi để nó ngồi không 29 ngày còn lại. Trên cloud, ta bật cụm khi cần, tắt khi xong, và chỉ trả tiền cho vài giờ thực chạy. Đây là bước dịch chuyển từ tư duy CapEx (chi phí vốn — mua tài sản, khấu hao) sang OpEx (chi phí vận hành — trả theo mức dùng).

Có năm đặc tính cốt lõi khiến cloud đặc biệt phù hợp với công việc dữ liệu:

• Co giãn (elasticity): Cấp phát tài nguyên tăng/giảm theo tải trong vài phút, thậm chí tự động (auto-scaling). Workload dữ liệu vốn "gợn sóng" — im ắng phần lớn thời gian rồi bùng nổ khi chạy pipeline hằng đêm hay đóng sổ cuối tháng — nên co giãn là món quà đúng nhu cầu nhất.
• Trả theo dùng (pay-as-you-go): Không dùng thì không trả. Một cụm phân tích chạy 3 tiếng/đêm chỉ tính tiền 3 tiếng đó. Điều này biến nhiều kiến trúc "trước đây quá đắt" thành khả thi.
• Managed service (dịch vụ được quản lý): Nhà cung cấp lo phần "nặng nhọc không tạo giá trị" — vá lỗi hệ điều hành, thay ổ cứng hỏng, backup, HA (high availability — sẵn sàng cao). Đội dữ liệu tập trung vào logic nghiệp vụ thay vì làm sysadmin.
• Tách compute và storage (decoupling): Đây là thay đổi kiến trúc quan trọng nhất. Trên hệ thống truyền thống (như Hadoop cổ điển), tính toán và lưu trữ dính chặt vào cùng một cụm máy — muốn thêm dung lượng phải thêm cả CPU và ngược lại. Trên cloud, dữ liệu nằm trên object storage rẻ và gần như vô hạn (S3/ADLS/GCS), còn compute là những cụm tách rời, bật lên đọc dữ liệu rồi tắt đi. Nhiều đội có thể đọc cùng một bản dữ liệu song song mà không tranh chấp tài nguyên. Đây chính là nền tảng kỹ thuật của kiến trúc lakehouse.
• Triển khai nhanh (speed): Dựng một data warehouse mới mất vài phút bằng vài dòng lệnh, thay vì vài tháng đặt mua và lắp đặt phần cứng. Tốc độ thử nghiệm này thay đổi cả văn hoá làm việc: sai thì xoá, làm lại, rẻ.

Mặt trái cần nhớ ngay từ đầu: sự tiện lợi ấy dễ dẫn tới lãng phí. Một cụm quên tắt hay một truy vấn quét nhầm terabyte có thể tạo hoá đơn bất ngờ. Kỷ luật chi phí (FinOps) vì thế là kỹ năng bắt buộc, không phải tuỳ chọn — chủ đề của bài 7 trong series này.

Mô hình dịch vụ: IaaS, PaaS, SaaS

Dịch vụ đám mây được phân theo mức độ nhà cung cấp lo hộ bạn bao nhiêu. Hình dung như một cái thang: càng lên cao, bạn càng ít phải quản lý hạ tầng, nhưng cũng càng ít quyền kiểm soát chi tiết.

Mô hình	Nhà cung cấp lo	Bạn lo	Ví dụ dịch vụ dữ liệu
IaaS (Infrastructure)	Máy ảo, mạng, lưu trữ, ảo hoá	HĐH, runtime, cài đặt phần mềm, dữ liệu	EC2, Azure VM, Compute Engine (tự dựng Spark/Postgres lên đó)
PaaS (Platform)	Thêm HĐH, runtime, scaling, vá lỗi	Cấu hình dịch vụ, dữ liệu, quyền truy cập	BigQuery, Redshift, Databricks, RDS, Cloud Composer
SaaS (Software)	Gần như toàn bộ, kể cả ứng dụng	Chỉ dữ liệu và người dùng	Snowflake (dạng SaaS), Power BI Service, Looker

Ý nghĩa với data team: Xu hướng của kỹ thuật dữ liệu hiện đại là dịch chuyển lên cao — ưu tiên PaaS/managed service thay vì tự dựng mọi thứ trên IaaS. Tự cài một cụm Kafka hay Airflow lên máy ảo (IaaS) cho bạn toàn quyền nhưng đổi lại gánh nặng vá lỗi, scaling, HA. Dùng bản managed (PaaS) giải phóng đội để làm việc tạo giá trị. Quy tắc thực dụng: chỉ tự quản khi có lý do rõ ràng (kiểm soát đặc thù, chi phí ở quy mô cực lớn, hoặc ràng buộc tuân thủ). Ranh giới IaaS/PaaS cũng chính là nơi mô hình trách nhiệm chia sẻ (bên dưới) dịch chuyển.

Ba nhà cung cấp lớn và bản đồ dịch vụ dữ liệu

Thị trường bị chi phối bởi ba "ông lớn": AWS (Amazon Web Services), Azure (Microsoft) và GCP (Google Cloud Platform). Cả ba đều đủ trưởng thành để chạy một nền tảng dữ liệu nghiêm túc; khác biệt nằm ở thế mạnh, hệ sinh thái và mức độ tích hợp với công cụ sẵn có của tổ chức. AWS rộng và trưởng thành nhất; Azure mạnh khi doanh nghiệp đã dùng Microsoft (AD, Office, SQL Server); GCP nổi bật ở phân tích và ML (BigQuery, Vertex AI).

Điểm khiến người mới bối rối là mỗi cloud đặt tên dịch vụ khác nhau cho cùng một khái niệm. Bảng dưới đây ánh xạ các dịch vụ dữ liệu cốt lõi theo lớp chức năng — hãy dùng nó như một từ điển:

Lớp chức năng	AWS	Azure	GCP
Object storage (lưu trữ file thô)	S3	ADLS Gen2 / Blob	Cloud Storage (GCS)
Data warehouse (kho phân tích SQL)	Redshift	Synapse / Fabric	BigQuery
Compute / Spark (xử lý lớn)	EMR / Glue	Databricks / Synapse Spark	Dataproc
Streaming (dữ liệu thời gian thực)	Kinesis / MSK	Event Hubs	Pub/Sub
Orchestration (điều phối pipeline)	MWAA (Airflow) / Step Functions	Data Factory	Cloud Composer (Airflow)
Serverless SQL / query engine	Athena	Serverless SQL Pools	BigQuery (mặc định)
Managed relational DB	RDS / Aurora	Azure SQL / PostgreSQL	Cloud SQL / AlloyDB

Lưu ý: đây là ánh xạ theo vai trò, không phải tương đương 1-1 tuyệt đối về tính năng. Databricks và Snowflake còn chạy xuyên cloud (cùng một trải nghiệm trên cả ba). Bản đồ này được đào sâu qua các bài sau: storage (bài 2), compute (bài 3), và managed data services (bài 5).

Mô hình trách nhiệm chia sẻ (Shared Responsibility)

Đây là khái niệm bảo mật quan trọng nhất khi bước lên cloud, và cũng là nơi các sự cố rò rỉ dữ liệu ngân hàng hay xảy ra nhất. Nguyên tắc cốt lõi: an ninh trên cloud là trách nhiệm được CHIA SẺ giữa nhà cung cấp và khách hàng — không phải ai đó lo hết.

Ranh giới thường được diễn đạt là: nhà cung cấp chịu trách nhiệm security of the cloud (an ninh của đám mây — hạ tầng vật lý, phần cứng, ảo hoá, mạng lõi, trung tâm dữ liệu). Còn khách hàng chịu trách nhiệm security in the cloud (an ninh trong đám mây — cấu hình dịch vụ, phân quyền IAM, mã hoá, và chính dữ liệu của bạn).

Hạng mục	IaaS	PaaS	SaaS
Trung tâm dữ liệu, phần cứng, mạng vật lý	Nhà cung cấp	Nhà cung cấp	Nhà cung cấp
Hệ điều hành, vá lỗi máy chủ	Khách	Nhà cung cấp	Nhà cung cấp
Cấu hình ứng dụng / dịch vụ	Khách	Khách	Nhà cung cấp
Phân quyền truy cập (IAM), cấu hình mạng	Khách	Khách	Khách
Dữ liệu và phân loại dữ liệu	Khách	Khách	Khách

Điểm mấu chốt cần khắc sâu: dữ liệu, quyền truy cập và cấu hình luôn là trách nhiệm của khách hàng ở mọi mô hình. AWS không bao giờ chịu trách nhiệm nếu bạn cấu hình một bucket S3 chứa dữ liệu khách hàng ở chế độ public — đó là lỗi cấu hình của bạn. Phần lớn các vụ rò rỉ dữ liệu lớn trên báo chí không phải do hacker phá được hạ tầng Amazon, mà do bucket bị để hớ (misconfiguration). Với ngân hàng, hệ quả rất cụ thể: mã hoá dữ liệu nhạy cảm, cấu hình IAM theo nguyên tắc least privilege (đặc quyền tối thiểu), bật audit log — tất cả nằm ở phía khách, không phải nhà cung cấp. Chủ đề này được đào sâu ở bài 4 về mạng & bảo mật và bài Bảo mật dữ liệu ngân hàng.

Region, Availability Zone và Data Residency

Hạ tầng cloud được tổ chức theo địa lý ở hai cấp:

• Region (vùng): Một khu vực địa lý độc lập, ví dụ ap-southeast-1 (Singapore) của AWS hay southeastasia của Azure. Mỗi region là một biên giới độc lập về pháp lý và vật lý. Chọn region quyết định độ trễ (region gần người dùng thì nhanh hơn) và nơi dữ liệu cư trú.
• Availability Zone (AZ — vùng sẵn sàng): Trong mỗi region có nhiều AZ — là các trung tâm dữ liệu tách biệt về nguồn điện, làm mát và mạng, nhưng nối với nhau bằng đường truyền tốc độ cao độ trễ thấp. Triển khai dịch vụ trên nhiều AZ cho phép chịu được sự cố hỏng cả một trung tâm dữ liệu mà không gián đoạn — đây là nền tảng của HA (high availability) và dự phòng (redundancy).

Nguyên tắc kiến trúc: AZ để chống lỗi cục bộ trong region; nhiều region để chống thảm hoạ diện rộng và phục vụ người dùng ở xa. Cân bằng độ trễ và độ tin cậy là chủ đề của bài 7.

Data residency (nơi cư trú dữ liệu) là ràng buộc pháp lý về việc dữ liệu được phép lưu ở đâu — và nó là vấn đề sống còn với ngân hàng Việt Nam. Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân (NĐ13) cùng quy định của Ngân hàng Nhà nước (NHNN) đặt ra yêu cầu chặt chẽ về lưu trữ và xử lý dữ liệu người dùng Việt Nam. Chọn sai region — ví dụ để dữ liệu PII của khách hàng Việt trên một region ở nước ngoài mà không có cơ sở pháp lý — có thể vi phạm quy định. Vì thế, việc chọn region không phải quyết định kỹ thuật thuần tuý mà là quyết định tuân thủ, thường cần đội pháp chế và tuân thủ ký duyệt trước khi kỹ sư đụng vào hạ tầng.

Cloud vs On-prem vs Hybrid

Không phải cứ lên cloud là đúng cho mọi thứ. Có ba lựa chọn triển khai, và ngân hàng thường phải cân nhắc rất kỹ:

• On-premises (on-prem — tại chỗ): Hạ tầng đặt trong trung tâm dữ liệu của chính ngân hàng. Ưu điểm: kiểm soát tuyệt đối, dữ liệu không rời khỏi tường lửa, dễ chứng minh tuân thủ. Nhược: đắt đỏ (CapEx lớn), chậm mở rộng, tự gánh toàn bộ vận hành.
• Public cloud (đám mây công cộng): Toàn bộ trên AWS/Azure/GCP. Ưu: co giãn, nhanh, ít vận hành. Nhược: câu hỏi về kiểm soát và data residency với dữ liệu cực nhạy.
• Hybrid (lai): Kết hợp — dữ liệu nhạy cảm nhất (thông tin định danh, số dư, giao dịch core) giữ on-prem hoặc private cloud (đám mây riêng), còn workload phân tích, ML, hay dữ liệu ít nhạy cảm hơn đẩy lên public cloud. Đây là mô hình phổ biến nhất trong ngành ngân hàng Việt Nam hiện nay.

Bốn trục cân nhắc chính khi quyết định:

1. Tuân thủ (compliance): Ràng buộc NHNN, NĐ13, và phân loại dữ liệu. Đây thường là yếu tố quyết định đầu tiên với ngân hàng.
2. Độ nhạy cảm dữ liệu: PII, dữ liệu tài chính khách hàng thường được giữ ở nơi kiểm soát chặt nhất.
3. Chi phí: On-prem đắt trả trước nhưng có thể rẻ hơn ở quy mô ổn định lớn; cloud rẻ để bắt đầu và cho workload gợn sóng.
4. Kiểm soát vận hành: Đội có đủ năng lực tự quản hạ tầng hay muốn nhượng cho nhà cung cấp?

Multi-cloud và bài toán khoá nhà cung cấp

Vendor lock-in (khoá nhà cung cấp) là rủi ro bị phụ thuộc sâu vào một nhà cung cấp tới mức khó rời đi — vì đã dùng các dịch vụ độc quyền của họ, dữ liệu bị nhốt trong định dạng riêng, và đội đã quen công cụ đặc thù. Multi-cloud (dùng nhiều cloud) đôi khi được nêu ra như cách giảm rủi ro này, cùng lợi ích tận dụng thế mạnh từng nhà cung cấp và tăng khả năng thương lượng giá.

Nhưng multi-cloud không miễn phí: nó nhân đôi độ phức tạp vận hành, đòi hỏi đội thạo nhiều nền tảng, và việc di chuyển dữ liệu giữa các cloud phát sinh phí egress (phí truyền dữ liệu ra) đắt đỏ. Cách tiếp cận thực dụng hơn là giảm lock-in bằng chuẩn mở thay vì dàn trải nhiều cloud: dùng định dạng file mở (Parquet, Delta, Iceberg) trên object storage của chính mình, dùng công cụ chạy được đa nền (Spark, dbt, Airflow), và tách logic nghiệp vụ khỏi API độc quyền của nhà cung cấp khi khả thi. Đây cũng là lập luận cốt lõi của kiến trúc lakehouse.

Lộ trình series

Bài này là điểm khởi đầu. Toàn series đi từ nền tảng tới kiến trúc thực chiến trong ngân hàng:

• Bài 2 — Storage: Object storage, block/file storage, lớp lưu trữ (tiering), vòng đời dữ liệu.
• Bài 3 — Compute: Máy ảo, container, serverless, và compute cho xử lý dữ liệu lớn.
• Bài 4 — Mạng & Bảo mật: VPC, IAM, mã hoá, private endpoint — trọng tâm ngân hàng.
• Bài 5 — Dịch vụ managed cho dữ liệu: Warehouse, streaming, orchestration được quản lý.
• Bài 6 — IaC & DevOps: Terraform, hạ tầng như mã, CI/CD cho hạ tầng dữ liệu.
• Bài 7 — Chi phí & Độ tin cậy: FinOps, SLA, dự phòng, tối ưu hoá đơn.
• Bài 8 — Kiến trúc dữ liệu cho ngân hàng: Ghép mọi thứ thành một nền tảng tuân thủ thực tế.

Use case thực tế

Bối cảnh: Khối Dữ liệu NCB muốn xây một nền tảng phân tích rủi ro tín dụng có thể co giãn theo mùa (cao điểm cuối quý khi đóng sổ báo cáo), nhưng vẫn phải tuân thủ NHNN và NĐ13 về dữ liệu khách hàng. Hệ thống on-prem hiện tại phải mua sẵn phần cứng cho ngày cao điểm nhất, để không phần lớn thời gian, và mỗi lần cần thêm năng lực tính toán mất 2-3 tháng đặt mua thiết bị.

Quyết định kiến trúc hybrid (minh hoạ):

1. Phân loại dữ liệu: Đội phối hợp bộ phận tuân thủ chia dữ liệu làm hai nhóm. Nhóm nhạy cảm cao (PII, số tài khoản, số dư từ core banking) — giữ trên private cloud / on-prem trong biên giới ngân hàng. Nhóm đã khử định danh và dữ liệu tổng hợp — được phép đưa lên public cloud.
2. Chọn region: Cho phần public cloud, chọn region trong khu vực được đội pháp chế duyệt, và ghi rõ ràng buộc data residency vào tài liệu kiến trúc trước khi triển khai.
3. Tận dụng co giãn: Cụm compute phân tích trên cloud tự bật vào 22h mỗi đêm chạy pipeline, tự tắt lúc 3h sáng khi xong — chỉ trả tiền ~5 giờ/ngày thay vì cả tháng. Cao điểm cuối quý, cụm tự nhân đôi số node trong vài phút rồi thu về sau.
4. Trách nhiệm chia sẻ: Đội bật mã hoá at-rest cho object storage, cấu hình IAM least-privilege (analyst chỉ đọc bảng đã ẩn PII), và bật audit log toàn bộ — vì đây là phần trách nhiệm của khách hàng, không phải nhà cung cấp.

Kết quả (minh hoạ): Chi phí compute cho phân tích giảm mạnh nhờ trả theo dùng; thời gian mở rộng năng lực từ vài tháng xuống vài phút; dữ liệu nhạy cảm nhất vẫn nằm trong biên giới ngân hàng, qua được vòng đánh giá tuân thủ.

Ghi nhớ

• Cloud thay đổi cách làm dữ liệu qua năm đặc tính: co giãn, trả theo dùng, managed service, tách compute-storage, triển khai nhanh — chuyển từ tư duy CapEx sang OpEx.
• Tách compute-storage là thay đổi kiến trúc quan trọng nhất: dữ liệu nằm trên object storage rẻ, compute bật/tắt độc lập, nhiều đội đọc chung một bản dữ liệu.
• IaaS/PaaS/SaaS là thang trách nhiệm: càng lên cao càng ít quản hạ tầng nhưng ít quyền kiểm soát. Kỹ thuật dữ liệu hiện đại ưu tiên PaaS/managed, chỉ tự quản khi có lý do rõ ràng.
• Ba nhà cung cấp lớn AWS / Azure / GCP đều đủ trưởng thành; khác nhau ở tên gọi dịch vụ và thế mạnh — hãy dùng bảng ánh xạ theo lớp như một từ điển.
• Trách nhiệm chia sẻ: nhà cung cấp lo an ninh của cloud (hạ tầng); khách lo an ninh trong cloud (cấu hình, quyền, dữ liệu) ở mọi mô hình. Phần lớn rò rỉ là do misconfiguration của khách.
• Region quyết định độ trễ và data residency; nhiều AZ trong region cho HA và dự phòng. Chọn region là quyết định tuân thủ, không chỉ kỹ thuật.
• Data residency với ngân hàng Việt Nam gắn chặt NHNN và NĐ13 — cần pháp chế duyệt trước khi đụng hạ tầng.
• Hybrid (dữ liệu nhạy cảm on-prem/private, phân tích trên public cloud) là mô hình phổ biến nhất trong ngân hàng Việt Nam; cân nhắc theo bốn trục: tuân thủ, độ nhạy cảm, chi phí, kiểm soát.
• Giảm vendor lock-in hiệu quả nhất bằng chuẩn mở (Parquet/Delta/Iceberg, Spark/dbt/Airflow) hơn là dàn trải multi-cloud — vốn nhân đôi độ phức tạp và tốn phí egress.