Đã đăng vào khoảng 14 giờ trước 10 phút đọc

#4 Cách mình tối ưu Cloud, Git workflow và Infrastructure

Đây là một phần trong series mình chia sẻ về những gì mình đã làm khi xây dựng và vận hành hạ tầng backend trên AWS cho công ty. Không phải là best practice hoàn hảo, cũng không phải kiến thức quá cao siêu. Chỉ đơn giản là những gì mình đã học được, thử nghiệm và áp dụng trong quá trình làm việc hằng ngày.

Mình đã chia sẻ cách tối ưu hoá đơn cloud cho công ty như thế nào trong bài trước, nhưng thực sự mọi thứ vẫn còn rất ngổn ngang.

Pipeline để deploy code

Công ty mình sử dụng Jenkins để chạy pipeline. Tất nhiên mình đã từng làm việc với GitLab CI/CD, nhưng với mình tất cả chỉ là công cụ. Argo CD, GitHub Actions, CodePipeline cũng chỉ là công cụ để build và deploy mà thôi. Về bản chất, mọi thứ là như nhau.

Lúc đầu, pipeline của công ty hiện tại chỉ có build stage cho các dự án backend, còn deploy thì vẫn chủ yếu làm bằng tay.

Chính vì thế, mình đã viết thêm pipeline để có thể deploy tự động lên staging và production.

Bây giờ mọi thứ hoàn toàn tự động sau khi git push (ngon ngay ).

Đến thời điểm hiện tại, tất cả các dự án mình làm đều đã có pipeline deploy tự động. Mọi việc bây giờ chỉ là thay đổi code và đẩy lên git mà thôi.

Quy trình làm việc với Git

Mình thú nhận là trước đó mình chưa có một quy trình làm việc với Git thật sự hiệu quả, mặc dù mình tiếp xúc với Git từ rất lâu.

Trong một team nhiều người, mọi thứ vẫn lẫn lộn và khó quản lý.

Mỗi lần test một tính năng mới phải hỏi dev khác:

deploy được chưa?
có mất code của feature khác không?
test xong chưa?
tới lượt tao test chưa?

Đơn giản vì lúc đó chúng ta chỉ có duy nhất một môi trường dev để test.

Trong đầu mình lúc đó vẫn rất mông lung về việc làm sao để có một Git workflow hiệu quả.

Cho đến một ngày, trên đường đi làm về, mình đang đi bộ dọc bờ sông để về nhà. Không xem điện thoại, chỉ hít thở không khí trong lành và nghĩ vu vơ về flow Git.

Đột nhiên nảy ra một sáng kiến, haha. (Mọi người thấy ích lợi của việc đi bộ chưa?)

Sau này mình tình cờ đọc một bài blog trên mạng, và về cơ bản thì giống y như vậy. Lúc đó mới biết là mọi người đã áp dụng flow này từ lâu rồi. Chỉ là mình chưa từng được tiếp xúc thôi.

Ở đây tất cả cũng chỉ là sự phù hợp.

Nguyên tắc của mình rất đơn giản:

Branch master là branch duy nhất luôn ổn định và đúng đắn nhất ở thời điểm hiện tại.
Tất cả feature mới hoặc fix bug phải checkout từ branch này.
Branch develop đóng vai trò branch để test.
Tất cả các branch feature hoặc fix bug sau khi code xong muốn test thì phải merge vào develop để deploy lên môi trường test.
Khi test trên develop ok, merge branch feature hoặc fix bug vào master để deploy lên production.

Với flow Git như vậy, team mình sử dụng và hoạt động rất trơn tru, chưa thấy có vấn đề gì.

Nếu có thì mình sẽ đi bộ bờ sông để suy nghĩ tiếp, haha.

Hạ tầng (Infrastructure as Code)

Ích lợi của Infrastructure as Code (IaC) thì chắc mình không cần phải nói nhiều. Bạn tìm trên mạng hoặc hỏi AI là ra ngay.

Sau khi deploy xong hạ tầng backend lên AWS, việc tiếp theo mình làm là viết IaC cho toàn bộ các dự án.

Thực ra suy nghĩ của mình rất đơn giản.

Một ngày nào đó, nếu mình không còn làm việc ở đây nữa, thì ít ra những người ở lại hoặc những người mới có một thứ gì đó để:

hiểu hạ tầng mình đã dựng
nhanh chóng xây dựng lại hệ thống nếu có sự cố

Mình sử dụng OpenTofu (fork của Terraform), mọi thứ gần như giống hệt.

Xin lỗi AWS, nhưng mình không thích AWS CloudFormation lắm. Nhìn code Terraform vẫn thấy đẹp hơn nhiều .

Monitoring

Có lẽ mình sẽ dành một bài viết riêng cho chủ đề này.

Sau 1 năm làm việc ở công ty, thứ mình tự hào nhất không phải là những thứ làm với AWS, mà là xây dựng được nền tảng monitoring cho công ty.

Ở công ty cũ mình đã từng làm việc với Datadog, nhưng lúc đó hiểu biết của mình về monitoring còn rất nguyên sơ.

Gần như chỉ dùng để đọc log.

Rõ ràng lúc đó mình chỉ là dev, lại không có ai hướng dẫn nên cũng không biết phải tìm hiểu sâu hơn như thế nào.

Thực ra Datadog là một nền tảng monitoring gần như toàn diện, nhưng không hiểu sao hồi đó mình không chịu tìm hiểu xem nó có những gì.

Sang công ty mới, mình khá ngạc nhiên khi thấy không có nền tảng nào để xem log. Muốn xem log phải SSH vào server.

Lúc đó mình cảm thấy phải có monitoring. Nếu không thì giống như tay không bắt giặc.

Có những lỗi chỉ xem log thôi thì không thể giải quyết được vấn đề.

Đến hiện tại, monitoring chiếm khá nhiều thời gian làm việc mỗi ngày của mình, nhưng giá trị nó mang lại giúp mình hiểu hệ thống sâu hơn rất nhiều.

Backup

Mọi người biết tài sản quý giá nhất của công ty là gì không?

Theo mình không phải con người, mà chính là dữ liệu.

Còn dữ liệu thì công ty còn sống. Mất dữ liệu thì công ty có thể phá sản.

Tầm quan trọng của nó là không thể bàn cãi.

Đã từng có một công ty sau khi bị hacker chiếm quyền root và xoá toàn bộ dữ liệu. Họ cầu cứu AWS để khôi phục nhưng không làm được, cuối cùng công ty cũng phá sản.

Công ty mình sử dụng RDS PostgreSQL làm cơ sở dữ liệu. Mình cũng nhiều lần suy nghĩ: nếu hacker chiếm được quyền root thì sao?

Mọi thứ có thể tan thành mây khói.

Sau đó mình đọc được về AWS Backup. Với cơ chế backup này, dữ liệu sẽ được bảo vệ và dù là root cũng không thể xoá được.

Ít nhất là trong tầm hiểu biết của mình thì tạm thời thấy an toàn. Trừ khi cả hệ thống AWS sập thì thôi… đi luôn (nhưng chắc cũng hơi khó).

CronJob

Cái này gần như không thể thiếu trong mọi công ty, nhất là khi cần xử lý những tập dữ liệu lớn.

Công ty mình trước đó sử dụng Spring Boot Scheduled Annotation để chạy các cron job. Cách này vẫn chạy ổn.

Nhưng có một vài vấn đề:

Debug job khá khó
Nếu scale service theo chiều ngang thì sẽ có nhiều server chạy cùng một job, dẫn đến trùng lặp

Cách làm của mình khá đơn giản và không cần refactor quá nhiều.

Mình chuyển phần quản lý job sang AWS Lambda + EventBridge.

EventBridge sẽ gọi HTTP API vào một controller của Spring Boot, sau đó controller sẽ switch đến các job tương ứng dựa trên type trong parameter.

Nhờ vậy mọi thứ trở nên đơn giản và dễ kiểm soát hơn.

Kết

Mình luôn suy nghĩ liên tục để tìm ra giải pháp cho những vấn đề trong hệ thống.

Có thể với người khác đó là những việc rất đơn giản, nhưng với mình khi tìm ra được giải pháp thì đó vẫn là một niềm vui nho nhỏ.

Và mình luôn tự hào về điều đó

Bài viết này cũng được mình dịch sang tiếng Anh trên blog substack của mình.

Mình viết lại những điều này như một cách để ghi nhớ hành trình làm nghề của mình. Nếu bạn cũng đang làm backend, devops hoặc cloud, hy vọng những chia sẻ này có thể giúp bạn một chút gì đó. Còn nếu có chỗ nào mình hiểu chưa đúng, mình vẫn luôn sẵn sàng học thêm.