Thực tế, việc chuẩn bị cho buổi talk này khiến mình phải suy nghĩ khá nhiều. Thay vì chỉ nói về những thứ hào nhoáng của AI, mình muốn chia sẻ một góc nhìn thực tế hơn của một Developer: Làm sao để chúng ta không chỉ "chat" với AI, mà thực sự điều khiển được nó.

Đừng chỉ đứng ngoài khung chat

Nhiều bạn vẫn quen với việc dùng Gemini hay ChatGPT qua giao diện chat thông thường. Nhưng với mình, sức mạnh thực sự nằm ở Google AI Studio. Mình gọi đây là phòng thí nghiệm. Bởi vì ở đó, chúng ta không còn là người dùng phổ thông nữa, mà là những người trực tiếp cài đặt Persona (nhân cách) cho mô hình thông qua System Instructions và các thông số khác như Temperature.

Một Persona chuẩn không chỉ là đặt tên cho Bot, mà phải bao gồm 4 thành phần:

• Identity: Nó là ai? (Ví dụ: Senior DevOps với 15 năm kinh nghiệm).

• Mission: Mục tiêu cụ thể là gì? (Review code hay tối ưu hệ thống?).

• Tone: Giọng văn ra sao? (Khắt khe hay vui vẻ?).

• Constraints: Những gì nó KHÔNG được phép làm. Đây là phần quan trọng nhất để Bot không bị lạc đề.

Trong buổi talk, mình đã cùng mọi người xây dựng "The Strict Code Reviewer" — một trợ lý AI chuyên mắng người dùng vì code ẩu. Qua ví dụ vui vẻ này, mình muốn chứng minh một điều: AI có thể làm việc cực kỳ chuyên nghiệp và nhất quán nếu chúng ta biết cách thiết lập các ràng buộc (Constraints) chặt chẽ.

Đối xử với AI như con người

Một trong những điều quan trọng nhất mình muốn truyền tải trong buổi talk là cách chúng ta đối xử với AI. Đừng coi nó là một cái máy tính chỉ biết nhận lệnh. Hãy tưởng tượng AI giống như một nữ trợ lý mới vào làm việc cho bạn.

Nếu bạn giao việc cho họ mà nói năng nửa vời, không có mục đích rõ ràng, cũng không cung cấp bối cảnh cụ thể, thì chắc chắn kết quả nhận lại sẽ không bao giờ đạt yêu cầu. AI cũng giống hệt như vậy. Để nó làm việc hiệu quả, chúng ta phải học cách "nói chuyện" có đầu có cuối và có trách nhiệm với những gì mình yêu cầu.

Vậy nên có 3 kỹ thuật cốt lõi mà mình muốn chia sẻ:

1. Framework CO-STAR: Để câu lệnh không bị sót ý, chúng ta cần bối cảnh (Context) và mục tiêu (Objective) rõ ràng.

1. Few-shot Prompting: Đừng chỉ ra lệnh suông. Hãy đưa ví dụ. AI học theo mẫu rất nhanh và chính xác nếu chúng ta làm mẫu cho nó.

2. Chain-of-Thought: Ép AI phải "suy nghĩ từng bước" thay vì đoán mò. Một câu thần chú đơn giản cũng có thể thay đổi hoàn toàn câu trả lời của AI.

Những gì mình nhận lại

Làm Speaker không phải là đứng ở vị thế "giảng viên" để dạy bảo ai cả. Với mình, đây là dịp để hệ thống lại kiến thức và chia sẻ những trải nghiệm thực chiến từ công việc tại MONA.Host và System443.

Nhìn thấy các bạn sinh viên chủ động, ham học hỏi, sẵn sàng trao đổi về bài Lab Prototype Applications in Google AI Studio, mình nhận ra rằng: Công nghệ chỉ thực sự thú vị khi nó giải quyết được những vấn đề thực tế, dù là nhỏ nhất.

AI đang tiến hóa rất nhanh. Nhưng sau cùng, công cụ vẫn chỉ là công cụ. Tư duy logic và cách chúng ta đặt câu hỏi và giải quyết vấn đề mới là thứ quyết định giá trị của sản phẩm.

Cảm ơn GDGoC SGU vì đã tin tưởng, trao cho mình cơ hội này và hỗ trợ mình hoàn thành buổi Talk này.

Thực ra, lúc đầu mình cũng định thế. Nhưng rồi cái duyên với Backend đến trước. Đến nay, mình đang là sinh viên năm cuối, nhưng đã có 2 năm kinh nghiệm làm Junior Backend. Trong quá trình đó, mình lại va thêm vào DevOps và Cloud (chủ yếu là GCP và AWS). Thật ra ở công ty startup thì thợ đụng cũng là một kỹ năng.

Mình nhận ra một điều: Code chạy được là một chuyện, nhưng code để nó an toàn và vận hành mượt mà trên hệ thống lại là câu chuyện hoàn toàn khác.

Tại sao mình viết blog này?

Mình viết không phải để dạy bảo ai, vì mình cũng chỉ đang là một đứa dev cày cuốc mỗi ngày như bao người khác. Mình viết để ghi lại những gì mình đã làm, những sai lầm mình từng mắc phải và cách mình giải quyết nó.

Trong ngành này, đôi khi đọc một bài chia sẻ về sự thất bại thực tế còn giá trị hơn nhiều so với việc đọc hàng chục trang tài liệu lý thuyết suông (Tutorial Hell đấy).

Bạn sẽ tìm thấy gì ở đây?

Blog của mình sẽ không có những thứ quá vĩ mô. Mình sẽ tập trung vào 4 nhóm nội dung chính mà mình đang làm mỗi ngày:

1. Giao điểm giữa ATTT và Backend: Cách mình áp dụng tư duy bảo mật khi viết code để tránh những lỗi bảo mật cơ bản hoặc sai logic.

2. Hành trình Junior: Những bài học rút ra từ công việc thực tế, những thứ mà trường đại học không dạy bạn.

3. Kỹ thuật về DevOps và Cloud: Các bài hướng dẫn dạng "hands-on" về cách mình build pipeline hay triển khai hệ thống trên AWS, GCP.

4. Tư duy hệ thống: Những góc nhìn cá nhân về việc thiết kế hệ thống, cách mình lựa chọn công nghệ. Ví dụ như: "Tại sao mình chọn SQL thay vì NoSQL cho dự án này?" hay "Cách mình tổ chức source code để dễ bảo trì khi dự án phình to ra".

Lời kết

Mình hy vọng những bài viết ở blog này sẽ giúp ích được phần nào cho các bạn sinh viên hoặc những bạn mới vào nghề như mình. Nếu bạn thấy có gì đó hay ho hoặc muốn góp ý cho những sai sót của mình, đừng ngần ngại để lại bình luận để mình cải thiện nhé.

Chúng ta cùng học, cùng làm và cùng tiến bộ.

Autoscaling là gì?

Compute Engine có một tính năng gọi là Autoscaling, giúp thêm hoặc xoá máy ảo dựa trên số liệu của ứng dụng. Tính năng này còn giúp cân bằng lưu lượng truy cập (traffic) giữa các máy ảo. Ví dụ: nếu CPU của ứng dụng tăng lên 80% thì Autoscaling sẽ khởi động thêm một máy ảo nữa để chia đôi công việc xử lý.

Trên thực tế, bạn có thể cấu hình các máy ảo rất lớn bằng Compute Engine, rất phù hợp cho các công việc phân tích cần sử dụng nhiều CPU. Nhưng hầu hết người dùng đều tiếp cận theo hướng mở rộng quy mô chứ không phải tăng quy mô.

Số lượng CPU tối đa trên mỗi VM đều phụ thuộc vào dòng máy ảo và zone. Bạn có thể tìm thêm các thông số kỹ thuật cho các loại máy VM hiện có tại đây.

Cloud Load Balancing là gì

Vậy là chúng ta đã tìm hiểu qua về Autoscaling, nhưng làm cách nào để người dùng sử dụng ứng dụng khi số lượng máy ảo của ứng dụng đó sẽ thay đổi theo thời gian. Tại thời điểm này thì ứng dụng sử dụng 4 máy ảo, nhưng thời điểm khác ứng dụng sử dụng 40 máy ảo thì sao?

Vấn đề này sẽ được giải quyết bằng Cloud Load Balancing. Nhiệm vụ của Load Balancing là phân phối lưu lượng người dùng giữa nhiều instance của ứng dụng. Bằng cách phân tán lưu lượng truy cập, Load Balancing giúp ứng dụng giảm nguy cơ gặp các vấn đề về hiệu năng.

Cloud Load Balancing là dịch vụ được quản lý toàn diện, tất cả lưu lượng truy cập đều được xác định bằng phần mềm. Load Balancing không chạy trong máy ảo của bạn nên bạn không cần lo về việc mở rộng quy vô hoặc quản lý chúng.

Bạn có thể đặt Load Balancing ở trước tất cả lưu lượng truy cập như HTTP/HTTPS, TCP, SSL cũng như UDP. Cloud Load Balancing có thể cân bằng tải giữa nhiều region, giúp chuyển lưu lượng truy cập nếu backend không ổn định. Nó còn phản ứng rất nhanh với những thay đổi trong mạng của người dùng, tình trạng backend, và các điều kiện khác.

Các loại Load Balancing

VPC cung cấp một bộ tùy chọn Load Balancing. Nếu bạn cần cân bằng tải theo region cho ứng dụng web, hãy sử dụng Global HTTP(S). Đối với lưu lượng truy cập liên quan đến tầng socket, bạn có thể sử dụng Global SSL Proxy. Nếu là lưu lượng TCP, hãy sử dụng Global TCP Proxy. Nếu bạn muốn cân bằng tải lưu lượng UDP hay bất kỳ port nào thì bạn có thể sử dụng Regional Load Balancing. Điểm chung của tất cả dịch vụ trên là chúng đều dành cho lưu lượng truy cập vào mạng Google từ Internet.

Nhưng nếu bạn muốn cân bằng lưu lượng bên trong dự án của mình thì sao? Ví dụ như giữa lớp Presentation và lớp Business. Bạn có thể sử dụng bộ cân bằng tải nội bộ theo region, Regional internal. Nó chấp nhận lưu lượng truy cập trên địa chỉ IP nội bộ của Google Cloud và cân bằng tải trên các máy ảo Compute Engine.

Cuối cùng, bộ cân bằng tải Internal HTTP(S) là bộ cân bằng tải layer 7 dựa trên proxy. Nó cũng cho phép bạn chạy và mở rộng quy mô dịch vụ của mình bằng địa chỉ IP cần bằng tải nội bộ.

Internal HTTP(s) LB là dịch vụ được quản lý dựa trên proxy mã nguồn mở, Envoy. Điều này cho phép nó kiểm soát lưu lượng dựa trên các thông số HTTPS. Sau khi Load Balancing được cấu hình, nó sẽ tự động phân bổ proxy Envoy để đáp ứng nhu cầu lưu lượng của bạn.

Và đó là tất cả về Autoscaling và Cloud Load Balancing trong Google Cloud.

Compute Engine là gì?

Compute Engine có thể tạo và chạy các máy ảo trên cơ sở hạ tầng của Google. Lợi ích của việc này là bạn cũng không cần phải đầu tư server hay cài đặt gì cả vì đã có Google lo hết tất cả rồi. Hàng nghìn con CPU ảo có thể chạy trên hệ thống được thiết kể để chạy nhanh và mang lại hiệu suất ổn định. Mỗi máy ảo đều có sức mạnh và đầy đủ chức năng như máy thật. Vậy nên bạn có thể cấu hình máy ảo như máy thật, bao gồm: loại ổ cứng, dung lượng ổ cứng, dung lượng RAM, CPU,... và hệ điều hành.

Bạn có thể instance (phiên bản) máy ảo bằng Google Cloud Console, Google Cloud CLI hoặc Compute Engine API. Instance có thể chạy các image của Linux và Window Server do Google cung cấp hoặc bất kỳ phiên bản custom nào của những image này. Bạn cũng có thể build và chạy image của các hệ điều hành khác và cấu hình lại máy ảo.

Cách nhanh nhất để sử dụng Google Cloud là Cloud Marketplace, nơi cung cấp các giải pháp từ Google và các nhà cung cấp bên thứ 3. Với những giải pháp này, thì bạn không cần phải tự cấu hình phần mềm hay instance máy ảo, storage hay cài đặt mạng. Bạn cũng có thể sửa đổi cấu hình của những giải pháp này trước khi chạy.

Hầu hết các gói phần mềm trong Cloud Marketplace đều được cung cấp miễn phí ngoài phí sử dụng đối với tài nguyên trên Google Cloud. Một số image của Cloud Marketplace tính phí sử dụng, đặc biệt là các image của bên thứ 3.

Chi phí của Compute Engine

Khi sử dụng máy ảo, Compute Engine tính phí theo giây với thời gian tối thiểu là một phút và tự động giảm giá khi máy ảo chạy càng lâu. Đối với mỗi máy ảo chạy hơn 25% thời gian trong một tháng, Compute Engine sẽ tự động giảm giá cho mỗi phút sử dụng thêm.

Bạn cũng có thể cam kết thời gian sử dụng để nhận giảm giá. Tuỳ chọn này sẽ phù hợp với những hệ thống chạy ổn định và bạn dự đoán được thời gian chạy của chúng. Bạn có thể mua lượng vCPU và RAM cụ thể với mức chiết khấu lên tới 57% so với giá thông thường, nhưng phải cam kết thời gian sử dụng là một hoặc ba năm.

Cuối cùng là máy ảo Preemptible và Spot. Giả sử bạn có một công việc không cần người xử lý và chỉ cần đợi nó hoàn thành, như phân tích dataset. Bạn có thể tiết kiệm chi phí lên tới 90%, bằng cách dùng máy ảo Preemptible hoặc Spot để xử lý công việc kiểu này. Máy ảo Preemptible hoặc Spot khác với máy ảo Compute Engine ở một điểm duy nhất là Compute Engine có quyền dừng công việc nếu tài nguyên của nó bị yêu cầu bởi công việc khác.

Máy ảo Spot khác với Preemptible ở chỗ nó cung cấp nhiều tính năng hơn, ví dụ: các máy ảo Preemptible chỉ có thể chạy tối đa 24 giờ một lần, còn máy ảo Spot không bị giới hạn thời gian chạy, tức là bạn có thể chạy vĩnh viễn. Tuy nhiên, chi phí của 2 loại máy ảo này là như nhau.

Compute Engine cho phép bạn chọn tuỳ chỉnh cấu hình của instance, như số lượng CPU, dung lượng RAM,... bằng cách chọn các máy ảo được cấu hình sẵn hoặc tự tạo cấu hình của riêng bạn.

Và đó là tất cả về Compute Engine trong Google Cloud.

VPC là gì?

Virtual Private Cloud hay VPC là một giải pháp bảo mật cho mô hình private cloud được đặt trong public cloud như Google Cloud. Nếu bạn chưa biết private cloud hay public cloud là gì thì đọc bài này nhé. Trên VPC, bạn có thể chạy code, lưu trữ dữ liệu, host website hoặc làm bất cứ thứ gì mà bạn có thể làm trong private cloud. Nhưng private cloud này được nhà cung cấp public cloud quản lý. Điều này có nghĩa là VPC kết hợp khả năng mở rộng và sự tiện lợi của public cloud, cùng với tính cô lập dữ liệu của private cloud.

Mạng VPC kết nối tài nguyên Goolge Cloud với nhau cùng với internet. Ngoài ra còn có phân đoạn mạng (Segment network) bằng cách sử dụng quy tắc tường lửa để hạn chế truy cập vào các instance và tạo các static route để chuyển tiếp lưu lượng truy cập. Bạn cũng có thể tạo ra các subnet là các mạng con của phân đoạn mạng. Kiến trúc này giúp dễ dàng xác định mô hình mạng trên phạm vi toàn cầu. Bạn thậm chí có thể đặt tài nguyên ở các khu vực khác nhau trên cùng một subnet.

Kích thước mạng con có thể tăng lên bằng cách mở rộng phạm vi IP mà không ảnh hưởng đến các máy ảo đã được cấu hình. Ví dụ: VPC ở region us-east1 có 3 máy ảo Compute Engine trên 1 subnet nhưng cả 3 máy ảo này đều ở các zone khác nhau.

Tính năng này có thể được sử dụng để xây dựng các giải pháp có khả năng phục hồi trước các sự gián đoạn (downtime, lỗi, thiên tai,...) nhưng vẫn giữ được mô hình mạng đơn giản.

Và đó là tất cả về VPC trong Google Cloud.

Tài khoản dịch vụ

Bạn có thể cấp quyền cho người dùng bằng IAM nhưng nếu như bạn không muốn cấp quyền cho người dùng mà chỉ muốn cấp quyền cho tài nguyên thì sao? Ví dụ như cấp quyền cho máy ảo trong Compute Engine. Đó là lúc tài khoản dịch vụ, service account phát huy tác dụng.

Giả sử dụng bạn có một ứng dụng chạy trong máy ảo cần lưu trữ dữ liệu trong Cloud Storage nhưng bạn không muốn ai truy cập vào dữ liệu đó, tức là chỉ có máy ảo mới có quyền này. Bạn có thể tạo tài khoản dịch vụ để xác thực (authentication) máy ảo đó với Cloud Storage.

Các tài khoản dịch vụ được đặt tên bằng email nhưng thay vì sử dụng mật khẩu thì chúng sử dụng các khóa (key) mật mã để truy cập tài nguyên. Vậy nên, nếu một tài khoản dịch vụ được cấp role Intance Admin của Compute Engine, thì tài khoản đó có thể tạo, chỉnh sửa, và xóa các VM khác.

Các tài khoản này cũng là tài nguyên (resources) nên bạn có thể quản lý chúng thông qua IAM và cấp role cho người dùng.

Cloud Identity

Nhiều người dùng Google Cloud thường sẽ đăng nhập vào Google Cloud Console bằng tài khoản Gmail, sau đó sử dụng Google Groups để cộng tác với những người đồng đội có vị trí tương tự. Mặc dù cách tiếp cận này dễ thực hiện nhưng bạn không thể quản lý tập trung danh tính của nhóm. Đó sẽ là vấn đề vì nếu ai đó rời khỏi nhóm thì bạn không thể xoá quyền truy cập vào tài nguyên của nhóm nhanh chóng với thiết lập này được.

Bạn có thể sử dụng Cloud Identity, để xác định chính sách cũng như quản lý người dùng và nhóm của mình bằng Google Admin Console. Người dùng (có thể là admin) có thể đăng nhập và quản lý tài nguyên Google Cloud bằng username và password họ sử dụng trong hệ thống Active Directory hoặc LDAP.

Khi sử dụng Cloud Identity, bạn có thể dùng Google Admin Console để vô hiệu hoá tài khoản và xoá người dùng khỏi Groups khi người đó rời khỏi nhóm.

Và đó là tất cả về Tài khoản dịch vụ và Cloud Identity trong Google Cloud.

Các hoạt động của IAM

Với IAM, bạn có thể áp dụng các chính sách xác định xem ai có thể làm gì và trên tài nguyên nào. "Ai" ở đây có thể là các tài khoản Google, Google group, tài khoản dịch vụ hoặc Cloud Identity. "Ai" còn được gọi là principal, ở bài này mình sẽ gọi nó là cá nhân. Mỗi cá nhân đều sẽ có một mã định danh riêng, thường là địa chỉ email. Cá nhân đó có thể làm gì sẽ phụ thuộc vào vai trò (role) của người đó. Role trong IAM là tập hợp các quyền. Khi bạn cấp role cho một cá nhân thì có nghĩa là bạn cấp tất cả các quyền có trong role cho cá nhân đó. Ví dụ để quản lý các phiên bản máy ảo trong một dự án, bạn phải có quyền tạo, xoá, khởi động, tắt và chỉnh sửa máy ảo. Các quyền này được nhóm thành một role để dễ hiểu và dễ quản lý hơn.

Khi cá nhân được cấp role trên một thành phần cụ thể của hệ thống phân cấp tài quyền, thì role đó sẽ được áp dụng cho cả thành phần được chọn và tất cả các thành phân bên dưới nó.

Bạn cũng có thể đặt ra các quy tắc chặn một số cá nhân sử dụng các quyền nhất định, bất kể họ có role là gì. Điều này là do IAM luôn kiểm tra cá nhân đó bị chặn quyền gì trước khi kiểm tra họ có quyền gì.

Các loại role trong IAM

Có 3 loại role trong IAM là Basic (cơ bản), Predefined (được xác định trước) và Custom (tuỳ chỉnh).

Basic

Role đầu tiên là Basic, role này khá rộng. Khi áp dụng role này cho một dự án Google Cloud, thì chúng sẽ ảnh hưởng đến tất cả các tài nguyên trong dự án đó. Role này bao gồm owner, editor, viewer, và billing admin.

Viewer có thể truy cập tài nguyên nhưng không thể chỉnh sửa hoặc thay đổi cài đặt. Editor có thể truy cập và chỉnh sửa tài nguyên. Owner cũng có quyền của Editor. Ngoài ra, Owner cũng có thể quản lý các role và quyền liên quan đến thanh toán. Thông thường, các công ty sẽ uỷ thác một người quản lý việc thanh toán cho dự án và không thể chỉnh sửa dự án. Việc này có thể được thực hiện bằng role Billing Admin.

Nhưng nếu có nhiều người cùng làm việc trong một dự án chứa nhiều dữ liệu nhạy cảm thì các role này quá chung chung. Vậy nên, IAM cho phép bạn gán các vai trò được tuỳ chỉnh cụ thể hơn để đáp ứng nhu cầu của bạn. Các vai trò này cũng là role thứ hai, role được xác định trước (predefined).

Predefined

Các dịch vụ cụ thể của Google Cloud cung cấp các role được xác định trước các quyền và nơi áp dụng những role đó. Ví dụ: Compute Engine có các role được xác định trước như Instance Admin, ai có role này đều có thể thực hiện các hành động trong role.

Custom

Nhưng nếu bạn cần tuỳ chỉnh role có các quyền cụ thể hơn thì sao? Đó là lúc bạn sử dụng Custom Role.

Nhiều công ty sử dụng mô hình "ít đặc quyền nhất", trong đó các cá nhân trong tổ chức sẽ được cấp tối thiểu các quyền cần thiết để thực hiện công việc. Ví dụ: bạn có thể cấp quyền "instanceOperator" để cho phép người dùng chỉ có thể dừng và khởi động máy ảo của Compute Engine.

Custom Role cho phép bạn tạo role có chính xác các quyền mà bạn muốn. Nhưng có 2 lưu ý mà bạn cần phải nhớ là bạn phải tự quản lý các role tuỳ chỉnh này và các role này chỉ có thể áp dụng ở cấp Projects hoặc Organization.

Và đó là tất cả về nhận dạng và quản lý truy cập (IAM) trong Google Cloud.

Resources

Ở cấp độ đầu tiên là tài nguyên. Tài nguyên ở đây có thể là các máy áo, storage, các table trong BigQuery hoặc bất cứ thứ gì trong Google Cloud. Các tài nguyên được tổ chức thành các dự án, nằm ở cấp độ thứ 2. Các dự án được tổ chức thành các thư mục hoặc thậm chí là các thư mục con nằm ở cấp độ thứ 3. Và ở cấp độ cao nhất là các Organization node (tổ chức), bao gồm tất cả các dự án, thư mục và tài nguyên trong tổ chức của bạn.

Hệ thống phân cấp tài nguyên rất quan trọng vì nó liên quan trực tiếp đến cách quản lý và áp dụng các chính sách khi bạn sử dụng Google Cloud. Các chính sách này có thể nằm ở cấp độ Projects, Folders và Organization. Một số dịch vụ của Google Cloud cũng có các chính sách riêng cho mỗi tài nguyên.

Các chính sách này cũng có tính chất kế thừa từ trên xuống. Nghĩa là nếu bạn áp dụng chính sách cho một Folder thì chính sách đó cũng sẽ được áp dụng cho tất cả dự án trong Folder đó.

Projects

Chúng ta sẽ tìm hiểu chi tiết hơn về cấp độ Projects mốt chút vì nó khá quan trọng. Projects (dự án) là cơ sở để kích hoạt và sử dụng các dịch vụ của Google Cloud như quản lý API, bật tính năng thanh toán, thêm và xoá cộng tác viên cũng như kích hoạt các dịch vụ khác của Google.

Mỗi dự án là một đối tượng độc lập trong tổ chức và mỗi tài nguyên chỉ thuộc về chính xác một dự án. Các dự án có thể có nhiều người dùng khác nhau vì mỗi người dùng sẽ có một nhiệm vụ riêng, ví dụ như quản lý hoặc thanh toán hoá đơn.

Mỗi dự án Google Cloud đều có 3 thuộc tính nhận dạng là ID, tên và mã số dự án. ID dự án là giá trị nhận dạng duy nhất do Google chỉ định và không thể thay đổi. ID dự án được sử dụng trong các ngữ cảnh khác nhau để Google Cloud phân biệt các dự án. Còn tên dự án là do người dùng tạo, có thể không phải là duy nhất và có thể thay đổi bất cứ lúc nào. Google Cloud cũng gán cho mỗi dự án một mã số duy nhất. Các con số này được Google Cloud sử dụng nội bộ để theo dõi tài nguyên.

Resource Manager Tool của Google có thể giúp bạn quản lý các dự án của mình. Công cụ này cung cấp các API có thể thu thập danh sách tất cả các dự án được liên kết với tài khoản, tạo dự án mới, cập nhật và xoá dự án. Nó thậm chí có thể khôi phục các dự án đã bị xoá trước đó và có thể truy cập thông qua RPC và REST API.

Folders

Cấp thứ 3 của hệ thống phân cấp tài nguyên trong Google Cloud là các Folders (thư mục). Các thư mục cho phép bạn áp dụng các chính sách cho tài nguyên. Các tài nguyên trong folder kế thừa các chính sách và quyền được gán cho folder đó.

Một folder có thể chứa dự án, folder khác hoặc cả hai. Bạn có thể sử dụng các thư mục để nhóm các dự án trong tổ chức. Ví dụ: Tổ chức của bạn có nhiều phòng ban, mỗi phòng ban đều có các tài nguyên Google Cloud riêng. Các thư mục cho phép bạn nhóm các tài nguyên này theo từng phòng ban. Các phòng ban cũng có thể áp dụng các chính sách độc lập để phù hợp với công việc.

Như mình đã nói ở trên, tài nguyên trong thư mục sẽ kế thừa các chính sách và quyề của thư mục đó. Ví dụ nếu bạn có hai dự án khác nhau do cùng một nhóm quản lý, bạn có thể áp dụng chính sách cho thư mục chứa hai dự án này để chúng có cùng quyền.

Organization

Để sử dụng các thư mục thì bạn phải có tổ chức (Organization), đây là tài nguyên cao nhất trong hệ thống phân cấp của Google Cloud. Tổ chức cung cấp một số vai trò đặc biệt. Ví dụ bạn có thể chỉ định quản trị viên chính sách của tổ chức để chỉ người này mới có quyền thay đổi chính sách. Bạn cũng có thể chỉ định người tạo dự án.

Nếu công ty bạn là khách hàng của Google Workspace (có domain riêng) thì các dự án mới mà bạn tạo sự tự động thuộc về tổ chức của bạn. Còn không thì bạn có thể sủ dụng Cloud Identity để tạo tổ chức. Sau khi tạo thì bất kỳ ai trong tổ chức cũng đều có thể tạo dự án và thanh toán.

Và đó là tất cả về hệ thống phân cấp tài nguyên trong Google Cloud.

Khi thời gian bạn chạy instance vượt hơn 25% của tháng đó, thì Compute Engine sẽ tự động giảm giá cho mỗi phút tăng thêm của instance này. Ngoài ra, bạn cũng có thể tuỳ chỉnh lượng tài nguyên mà ứng dụng sử dụng để tối ưu mức giá và khối lượng công việc.

Google Cloud cũng có một trang web giúp bạn tính toán chi phí là Google Cloud Calculator.

Câu hỏi mà mình nghĩ nhiều bạn sẽ đặt ra khi tìm hiểu về chủ đề này là Làm sao để Google Cloud không tiêu quá nhiều tiền hoặc vượt ngưỡng thanh toán?

Thật ra có rất nhiều giải pháp cho câu hỏi này, nhưng mình chỉ giới thiệu 4 giải pháp chính là Budgets, Alerts, Reports, và Quotas.

Đầu tiên là sử dụng Budgets (ngân sách) ở cấp tài khoản thanh toán hoặc ở cấp dự án. Budgets có thể là một giới hạn cố định hoặc linh hoạt theo một vài số liệu khác, ví dụ như phần trăm chi tiêu của tháng trước.

Bạn cũng có thể sử dụng Alerts (cảnh báo) để được thông báo khi chi phí đạt đến giới hạn ngân sách. Ví dụ: giới hạn ngân sách là 20 triệu và Alerts được đặt ở mức 90% thì bạn sẽ nhận được cảnh báo khi chi phí đạt tới 18 triệu. Alerts thường đượt đặt ở mức 50%, 80% nhưng bạn cũng có thể tuỳ chỉnh con số này.

Reports là một công cụ trực quan trong Google Cloud console, cho phép bạn theo dõi chi phí dựa trên dự án hoặc dịch vụ.

Cuối cùng, Quotas (giới hạn) được sử dụng để ngăn chặn dịch vụ sử dụng quá nhiều tài nguyên do lỗi hoặc các cuộc tấn công nhằm vào ứng dụng. Có 2 loại quotas là Rate quota và Allocation quota. Cả 2 đều được áp dụng ở cấp độ dự án. Rate quota (giới hạn tỷ lệ) được đặt lại sau một thời gian cụ thể. Ví dụ: GKE có quota là 3.000 lệnh call API trong 100 giây từ mỗi dự án Google Cloud. Sau 100 giây thì giới hạn này được đặt lại. Allocation quota (giới hạn phân bổ) chi phối số lượng tài nguyên mà dự án có thể sử dụng. Ví dụ: Theo mặc định, mỗi dự án Google Cloud có giới hạn phân phổ không quá 15 mạng VPC.

Các thiết kế bảo mật cũng được áp dụng phổ biến trên toàn bộ cơ sở hạ tầng mà Google Cloud và các dịch vụ của Google chạy trên đó.

Chúng ta sẽ tìm hiểu về một số cách Google thực hiện để giữ an toàn cho dữ liệu của khách hàng.

Thiết kế bảo mật mà Google áp dụng

Cơ sở hạ tầng của Google được bảo mật bằng các lớp (layer) khác nhau, bắt đầu từ lớp bảo mật vật lý của các data center, tiếp tục đến lớp bảo mật phần cứng và phần mềm làm nền tảng cho cơ sở hạ tầng và cuối cùng là các kỹ thuật và quy trình hiện có để hỗ trợ cho việc vận hành bảo mật.

Lớp bảo mật phần cứng

Lớp này bao gồm 3 tính năng bảo mật chính.

Đầu tiên là thiết kế và xuất xứ của phần cứng. Các bo mạch máy chủ và thiết bị mạng trong trung tâm dữ liệu của Google đều được Google thiết kế. Google cũng thiết kế các chip bảo mật phần cứng hiện đang được triển khai trên cả máy chủ và thiết bị ngoại vi.

Tính năng tiếp theo là ngăn xếp khởi động an toàn (secure boot stack). Các máy chủ của Google sử dụng nhiều công nghệ khác nhau để đảm bảo các thiết bị đang khởi động đúng, chẳng hạn như chữ ký mật mã trên BIOS, bootloader, kernel và image của hệ điều hành.

Tính năng cuối cùng của lớp này là bảo mật cơ sở (premises security). Google thiết kế và xây dựng các trung tâm dữ liệu của riêng mình, kết hợp nhiều lớp bảo vệ vật lý. Quyền truy cập vào các trung tâm dữ liệu này bị giới hạn cho một số lượng rất nhỏ nhân viên của Google.

Lớp triển khai dịch vụ

Tính năng chính của lớp này là mã hóa giao tiếp giữa các dịch vụ. Cơ sở hạ tầng của Google cung cấp quyền riêng tư và tính toàn vẹn bằng cơ chế giao tiếp RPC. Các dịch vụ của Google liên lạc với nhau bằng lệnh RPC. Cơ sở hạ tầng tự động mã hóa tất cả lưu lượng RPC đi qua các trung tâm dữ liệu. Google đã bắt đầu mở rộng phạm vi mã hóa cho tất cả lưu lượng RPC bên trong các trung tâm dữ liệu của Google.

Lớp nhận dạng người dùng

Dịch vụ nhận dạng của Google, thường hiển thị cho người dùng cuối dưới dạng trang đăng nhập Google, không chỉ yêu cầu tên người dùng và mật khẩu đơn giản. Dịch vụ này cũng bổ sung thêm các yếu tố rủi ro, chẳng hạn như liệu trước đây người dùng đã đăng nhập từ cùng một thiết bị hay một vị trí tương tự trong quá khứ hay chưa.

Người dùng cũng có thể sử dụng các yếu tố phụ khi đăng nhập, bao gồm các thiết bị dựa trên tiêu chuẩn Universal 2nd Factor (U2F) hay USB.

Lớp dịch vụ lưu trữ

Lớp này sẽ tiếp tục mã hóa phần còn lại của dữ liệu sau khi lớp triển khai dịch vụ. Hầu hết các ứng dụng tại Google đều truy cập vào bộ nhớ vật lý (nói cách khác là file storage) một cách gián tiếp thông qua các dịch vụ lưu trữ và mã hóa bằng key được áp dụng ở lớp này. Google cũng cũng hỗ trợ mã hóa phần cứng trong ổ cứng và SSD.

Lớp giao tiếp với internet

Lớp này bao gồm hai tính năng bảo mật chính.

Các dịch vụ của Google đang được cung cấp trên Internet sẽ tự động đăng ký với dịch vụ cơ sở hạ tầng có tên là Google Front End. Dịch vụ này đảm bảo rằng tất cả các kết nối TLS đều sử dụng cặp public-private key và chứng chỉ X.509 từ CA.

GFE áp dụng thêm các biện pháp bảo vệ chống lại các cuộc tấn công từ chối dịch vụ (Dos). Ngoài ra còn cung cấp tính năng bảo vệ khỏi các cuộc tấn tông Từ chối Dịch vụ (DoS). Quy mô của cơ sở hạ tầng cho phép Google dễ dàng xử lý nhiều cuộc tấn công DoS. Google cũng có các biện pháp bảo vệ DoS nhiều tầng, nhiều lớp giúp giảm thiểu bất kỳ tác động nào của DoS đối với dịch vụ chạy sau GFE.

Lớp bảo mật vận hành

Lớp bảo mật vận hành của Google có bốn tính năng chính.

Đầu tiên là phát hiện xâm nhập. Các Rules và AI có thể đưa ra cảnh báo cho nhóm bảo mật vận hành của Google về các sự cố có thể xảy ra. Google cũng thường xuyên tiến hành các cuộc diễn tập của Red team để đo lường và nâng cao tính hiệu quả của cơ chế phát hiện và phản hồi thâm nhập.

Tiếp theo là giảm rủi ro nội bộ. Google tích cực hạn chế và giám sát hoạt động của những nhân viên đã được cấp quyền quản trị cơ sở hạ tầng.

Nhân viên cũng phải sử dụng U2F. Để bảo vệ khỏi các cuộc tấn công lừa đảo nhắm vào nhân viên Google, tài khoản nhân viên yêu cầu sử dụng Security Key tương thích với U2F.

Cuối cùng, có những best practices dành cho việc phát triển phần mềm. Google sử dụng các trung tâm quản lý source code và yêu cầu ít nhất hai bên review code mới. Google cũng cung cấp các thư viện dành cho dev để ngăn họ gây ra một số loại lỗi bảo mật nhất định. Ngoài ra, Google còn triển khai Chương trình Vulnerability Rewards, trả tiền cho bất kỳ ai có thể phát hiện các lỗ hổng trong cơ sở hạ tầng hoặc ứng dụng của họ.

Bạn có thể tìm hiểu thêm về thiết bảo mật cơ sở hạ tầng kỹ thuật của Google tại cloud.google.com/security/security-design.

Mạng này được thiết kế để cung cấp cho các ứng dụng thông lượng (throughput) cao nhất và độ trễ thấp nhất có thể bằng cách tận dụng hơn 100 node caching nội dung trên toàn thế giới. Những nội dung nhiều lượt xem sẽ được lưu vào cache trên các node này để truy cập nhanh hơn, từ đó ứng dụng sẽ phản hồi yêu cầu của người dùng từ node có thời gian phản hồi nhanh nhất.

Region và Zone

Cơ sở hạ tầng của Google Cloud được đặt tại 5 vị trí chính là Bắc Mỹ, Nam Mỹ, Châu Âu, Châu Á và Úc. Việc đặt cơ sở hạ tầng ở nhiều vị trí rất quan trọng vì việc chọn vị trí đặt ứng dụng sẽ ảnh hưởng đến tính khả dụng (availability), độ bền (durability) và độ trễ (latency). Độ trễ là thời gian một gói tin (package) cần để di chuyển từ nguồn gửi đến đích.

Mỗi vị trí này được chia thành nhiều region và zone khác nhau. Region đại diện cho các khu vực địa lý độc lập và bao gồm các zone. Ví dụ London hoặc Europe-west2 là một region bao gồm ba zone khác nhau.

Zone là khu vực nơi tài nguyên Google Cloud được triển khai. Ví dụ: nếu bạn khởi chạy một máy ảo bằng Compute engine, nó sẽ chạy trong zone bạn chỉ định. Để dự phòng tài nguyên, bạn cũng có thể chạy các tài nguyên này ở các zone khác nhau.

Tính năng này rất hữu ích để ứng dụng có thể tiếp cận nhiều hơn với người dùng trên toàn thế giới và cũng để bảo vệ ứng dụng trong trường hợp có sự cố xảy ra trên toàn bộ region, như thiên tai chẳng hạn.

Một số dịch vụ của Google Cloud hỗ trợ chạy tài nguyên trên nhiều region, gọi là multi-region. Ví dụ: Tính năng đa vùng (multi-region) của Cloud spanner cho phép bạn sao chép dữ liệu của database ở nhiều zone trên nhiều region bằng cách cấu hình các instance. Những bản sao này cho phép ứng dụng đọc dữ liệu từ các vị trí ở gần với nó nhất như Hà Lan hoặc Bỉ, từ đó làm giảm độ trễ của ứng dụng.

Google Cloud hiện hỗ trợ 112 zone ở 37 region, và con số này vẫn không ngừng tăng lên. Bạn có thể tìm thấy những con số mới nhất tại đây.

IaaS và PaaS

Cơ sở hạ tầng dưới dạng dịch vụ thường được gọi là IaaS (Infrastructure as a service), giống như các công ty như google, amazon, microsoft,... sẽ cung cấp quyền truy cập vào một cơ sở hạ tầng nào đó như server ảo, ổ cứng, mạng,... để bạn chạy các ứng dụng trên đó.

Còn nền tảng dưới dạng dịch vụ thì được gọi là PaaS (Platform as a service). Các công ty sẽ cung cấp quyền truy cập đến một platform hoàn chỉnh, sẵn sàng sử dụng, được lưu trữ trên cloud để phát triển, chạy, bảo trì và quản lý các ứng dụng.

Các dịch vụ IaaS cung cấp khả năng tính toán, lưu trữ và mạng, được ảo hoá thành các tài nguyên tương tự như các server vật lý.

Các dịch vụ PaaS liên kết code với các thư viện, cung cấp quyền truy cập vào cơ sở hạ tầng mà ứng dụng cần. Điều này cho phép dev tập trung vào logic ứng dụng hơn.

Trong mô hình IaaS, khách hàng trả tiền trước cho các tài nguyên mà họ sử dụng. Còn trong mô hình PaaS, khách hàng trả tiền cho những tài nguyên họ thực sự sử dụng.

Khi điện toán đám mây phát triển, nó cũng góp phần thúc đẩy mô hình quản lý cơ sở hạ tầng và dịch vụ bởi nhà cung cấp.

Việc tận dụng các tài nguyên và dịch vụ được quản lý sẵn cho phép các công ty tập trung hơn vào các mục tiêu kinh doanh của mình và dành ít thời gian và tiền bạc hơn vào việc setup và duy trì cơ sở hạ tầng. Nó cho phép các công ty cung cấp sản phẩm và dịch vụ cho khách hàng nhanh chóng và ổn định hơn.

Serverless là một bước nữa trong quá trình phát triển của điện toán đám mây. Nó cho phép các nhà phát triển tập trung vào code, thay vì vào cấu hình máy chủ, bằng cách không cần quan tâm đến việc quản lý cơ sở hạ tầng.

Các công nghệ serverless do Google cung cấp bao gồm Cloud Functions, quản lý code theo hướng event dưới dạng dịch vụ trả phí khi được sử dụng. Và Cloud Run, cho phép khách hàng triển khai ứng dụng microservices dựa trên container.

Mặc dù nó nằm ngoài phạm vi của series này nhưng mình nghĩ chắc bạn đã nghe qua về Phần mềm dưới dạng dịch vụ, SaaS (Software as a service) và tự hỏi nó là gì cũng như nó phù hợp như thế nào đối với hệ sinh thái đám mây.

Phần mềm dưới dạng dịch vụ (SaaS) là phần mềm không được cài đặt trên máy tính của bạn. Các phần mềm này chạy trên cloud dưới dạng dịch vụ và được người dùng cuối sử dụng trực tiếp qua internet. Các ứng dụng phổ biến của Google như Gmail, Docs và Drive đều là ví dụ về SaaS.

Thuật ngữ "Điện toán đám mây" (Cloud computing) lần đầu tiên được công bố vào năm 2011 bởi Viện Tiêu chuẩn và Công nghệ Quốc gia hoa Kỳ (NIST - National Institute of Standards and Technology). Viện nghiên cứu cũng giải thích thuật ngữ này như sau:

Điện toán đám mây là mô hình cho phép truy cập theo yêu cầu, thuận tiện, ở mọi nơi vào một nhóm tài nguyên điện toán dùng chung có thể cấu hình (ví dụ: mạng, máy chủ, lưu trữ, ứng dụng và dịch vụ) có thể được cung cấp và phát hành (release) nhanh chóng với ít sự quản lý hoặc tương tác của nhà cung cấp dịch vụ. Mô hình đám mây này bao gồm 5 đặc điểm thiết yếu, ba mô hình dịch vụ và bốn mô hình triển khai.

Những đặc điểm quan trọng của Cloud

Đầu tiên, chúng ta sẽ tìm hiểu 5 đặc điểm quan trọng để hình nên một mô hình Cloud computing.

1. Khách hàng có được tài nguyên máy tính theo yêu cầu (on-demand) và có thể tự xử lý nhu cầu của mình. Hay nói cách khác, người dùng sẽ có được CPU, bộ nhớ (Disk, RAM) và mạng mà họ cần mà không cần sự can thiệp của con người. Ví dụ: Bạn không cần phải chạy ra cửa hàng để mua thêm RAM hay ổ cứng mà chỉ cần thêm những tài nguyên này vào Cloud của mình thông qua giao diện của website.

2. Khách hàng có quyền truy cập vào các tài nguyên đó thông qua internet từ bất kỳ nơi nào, miễn là họ có mạng.

3. Nhà cung cấp đám mây (cloud provider) phải có lượng lớn tài nguyên đó và có thể phân bổ chung cho người dùng. Khách hàng cũng không cần phải biết hoặc quan tâm đến vị trí thực tế của những tài nguyên này.

4. Những tài nguyên trên phải có tính linh hoạt (flexible) để phục vụ cho nhu cầu của khách hàng. Nếu khách hàng cần nhiều hoặc ít tài nguyên hơn thì họ cũng có thẻ được nhà cung cấp cloud đáp ứng.

5. Khách hàng chỉ trả tiền dựa trên thời gian hoặc dung lượng lưu trữ mà họ sử dụng. Đặc điểm này còn được gọi là on-demand. Nếu khách hàng không sử dụng tài nguyên thì họ cũng không cần phải trả tiền.

Đó là 5 đặc điểm quan trọng và cũng là định nghĩa của cloud.

Tại sao Cloud lại hấp dẫn?

Để hiểu được lý do tại sao Cloud lại hấp dẫn, chúng ta cần tìm hiểu một chút về lịch sử hình thành của Cloud.

Xu hướng Cloud hiện nay bắt đầu với làn sóng đầu tiên là Colocation. Colocation giúp người dùng tiết kiệm được nhiều tiền hơn khi chỉ cần thuê chỗ đặt server thay vì phải tự đầu tư và setup chỗ đặt server của chính mình.

Lấy một ví dụ cho dễ hiểu, khi bạn tự setup phòng server thì sẽ có rất nhiều vấn đề phát sinh như đảm bảo nguồn điện, nhiệt độ, băng thông mạng, độ ổn định, tiền điện,... và giá cả thì cũng không hề rẻ chút nào. Nhưng khi bạn thuê Colocation thì bạn không cần phải quan tâm đến những vấn đề đó, bạn chỉ cần đem server của mình cho nhà cung cấp Colocation tự setup (hoặc bạn phải tự setup). Hiện tại theo mình biết thì giá thuê Colocation trong Data Center của công ty F đang là từ 2xxx trở lên cho 1 rack.

Các trung tâm dữ liệu (data center) ảo hoá ngày nay là làn sóng thứ hai. Nó có nhiều điểm tương đồng với các trung tâm dữ liệu tư nhân và trung tâm colocation của nhiều năm trước. Những data center này cũng có các thành phần vật lý như Server, CPU, Disk, Load balancer nhưng ở dạng ảo hoá. Với công nghệ ảo hoá, doanh nghiệp vẫn duy trì được cơ sở hạ tầng nhưng người dùng vẫn có thể kiểm soát và cấu hình môi trường.

Vài năm trước, Google nhận ra rằng hoạt động kinh doanh của họ không thể phát triển đủ nhanh vì giới hạn của mô hình ảo hoá. Vì vậy, Google đã chuyển sang kiến trúc dựa trên Container. Đó cũng là làn sóng thứ ba của Cloud. Kiến trúc này linh hoạt hơn và hoàn toàn tự động, kết hợp giữa các dịch vụ tự động và dữ liệu có thể mở rộng (Scalability). Các dịch vụ tự động này cung cấp cơ sở hạ tầng được sử dụng để chạy các ứng dụng, và bạn cũng có thể cấu hình các cơ sở hạ tầng này. Đây cũng là làn sóng hiện tại của các nhà cung cấp đám mây như GCP, AWS, Azure.

Trong tương lai, mọi công ty bất kể quy mô hay ngành nghề sẽ tạo ra sự khác biệt so với các đối thủ cạnh tranh thông qua công nghệ.

Càng ngày, thứ công nghệ đó sẽ ở dạng phần mềm. Phần mềm tuyệt vời sẽ dựa trên dữ liệu chất lượng cao. Điều này có nghĩa là mọi công ty đều đang hoặc cuối cùng sẽ trở thành một công ty dữ liệu.

Lưu ý: Series này ở cấp độ cơ bản (fundamentals) nên nội dung sẽ hướng tới những người mới làm quen với công nghệ cloud.

Series này cũng sẽ bổ sung thêm kiến thức cho các bạn chuẩn bị thi Google Cloud Associate. Section 1 và Section 2 của đề thi sẽ liên quan đến việc setup môi trường và cấu hình các dịch vụ của Google Cloud. Nội dung của các bài trong series sẽ được dựa trên nhiều nguồn tài liệu chính thống của Google như Google Cloud Fundamentals: Core Infrastructure và Cloud Engineer Learning Path.

Các dịch vụ của Google Cloud có thể được phân loại thành 5 dịch vụ chính:

1. Compute

2. Storage

3. Big Data

4. Machine Learning

5. Application Services

Series GCP 101 sẽ phù hợp, hữu ích với những người đang ở vị trí:

• Solutions Developers

• Systems Ops

• Solution Architects

• Người ra quyết định kinh doanh (Business decision makers)

Trong series này, bạn cũng sẽ được làm quen với việc phát triển ứng dụng (Application development), hệ điều hành Linux, vận hành hệ thống (Systems operations), Data analytics/Machine learning để hiểu rõ nhất về các công nghệ được giới thiệu.

Mục tiêu của series GCP 101

Sau khi hoàn thành series này, mình hy vọng các bạn sẽ đạt được 6 mục tiêu sau:

1. Xác định được mục đích và giá trị của các sản phẩm và dịch vụ trên Google Cloud.

2. Cách tổ chức và kiểm soát cơ sở hạ tầng (infrastructure) trên Google Cloud.

3. Biết cách tạo các cơ sở hạ tầng cơ bản trên Google Cloud.

4. Chọn và sử dụng các dịch vụ lưu trữ trên Google Cloud.

5. Giải thích được mục đích và giá trị sử dụng của Google Kubernetes Engine.

6. Xác địch các trường hợp sử dụng (use case) các dịch vụ serverless của Google Cloud.

Chúc các bạn hoàn thành chặng đường học tập và phát triển của mình.