Các thuật ngữ kỹ thuật thường khá rối rắm và khó hiểu. Trong số tạp chí này, hãy thử trò chuyện với Thịnh từ team SRE để nhập môn “Đại cương Cơ sở Hạ tầng” cho người mới bắt đầu nhé.
Chào Thịnh! Đã lâu lắm rồi team SRE mình chưa lên sóng. Gần đây mọi người đang làm gì nhỉ?
Nổi bật nhất là dự án chuyển đổi sang Cơ sở Hạ tầng dạng Code (Infrastructure as Code - IaC), dự án này thì bên mình đã đang tiến hành được một thời gian rồi. Đây là xu hướng mới nhất trong ngành SRE.
Trước khi đến với Cơ sở Hạ tầng dạng Code, chắc ta sẽ nhắc lại một chút về cơ sở hạ tầng?
Nói một cách tối giản thì cơ sở hạ tầng bao gồm các máy chủ (server) và định tuyến trong mạng máy tính (routing network). Trong công ty, cơ sở hạ tầng thường không ồn ào và nổi bật so với các phương diện khác chẳng hạn như marketing, nhưng nếu nó không chạy bình thường thì sản phẩm của chúng ta sẽ ngay lập tức chịu ảnh hưởng nghiêm trọng.
Công việc của SRE, nói đơn giản là tính toán, sắp xếp, đảm bảo sao cho cơ sở hạ tầng chạy bình thường.
Vậy khi sắp xếp mọi thứ chuẩn chỉnh xong rồi thì mình cứ kệ cho nó tự hoạt động?
Rất tiếc là không. Team SRE thực ra phải theo dõi hạ tầng gần như liên tục, bởi vì hệ thống luôn luôn có biến động không ở chỗ này thì ở chỗ khác. Biến động có thể đến từ những thay đổi bên trong công ty như thay đổi mã nguồn. Cũng có thể đến từ bên ngoài công ty, như lưu lượng tăng giảm hoặc như khi nền tảng mình bị tấn công. Ngoài ra, một sản phẩm tiêu dùng như BAEMIN luôn luôn chạy các chiến dịch, chương trình khuyến mãi với nhiều hình thức và yêu cầu khác nhau. Tất cả những biến động đó đều tác động lên hệ thống, bởi vậy team mình phải cấu hình hạ tầng để có thể xử lý được các biến động đó.
Làm sao để cấu hình hạ tầng?
Trước đây, mình dùng máy chủ tại chỗ (on-prem) hoặc máy ảo ở Việt Nam là thiết bị vật lý (physical hardware). Lúc đó phải cấu hình tay. Dù cẩn thận đến mấy thì cũng không thể tránh khỏi những lỗi do con người (human error), nên hồi đó công việc SRE khá vất vả và căng thẳng.
Hiện nay, các ngành nghề hiện nay có xu hướng tự động hoá nhiều hơn, và ngành SRE cũng không ngoại lệ. Với sự phổ cập của công nghệ điện toán đám mây, chúng ta có thể dùng hạ tầng trên cloud, nhu cầu tới đâu thì trả tiền tới đó. Mình không cần phải cài đặt các máy chủ từ a đến z nữa, chỉ cần lựa chọn cấu hình máy chủ có sẵn để điều chỉnh cho phù hợp. Tất nhiên không phải tất cả mọi thứ đều được tự động hoá. Một số thứ vẫn cần phải cấu hình tay, còn API thì chỉ ở mức sử dụng nội bộ team hoặc cá nhân thôi. Nhưng dù sao đó vẫn là một bước tiến lớn so với thời các công ty sử dụng phần cứng vật lý.
Hiện nay, chúng ta đang ở trong thời đại mới, đó là Hạ tầng dạng Code, hay IaC.
Vậy IaC là gì?
IaC nghĩa là hệ thống tính toán của chúng ta không được thiết lập bằng tay hay bằng các thiết bị vật lý, mà được định nghĩa trong một tệp tin. Một công cụ tự động hoá sẽ đọc tệp tin này, sau đó xây dựng nên một hệ thống đáp ứng đúng định nghĩa của chúng ta. Hiện nay công cụ mà BAEMIN đang sử dụng là Terraform do HashiCorp phát triển.
Một cách ngắn gọn & khái quát, Terraform hoạt động như sau:
- Team SRE định nghĩa cấu hình mong muốn trong tệp tin cấu hình (configuration file). File này được viết theo Hashicorp Configuration Language (HCL). Đây là cú pháp cấu trúc nền tảng cho ngôn ngữ cấu hình của Terraform. Nếu không muốn học HCL, bạn có thể cân nhắc Cloud Development Kit for Terraform (CDKTF). CDKTF hỗ trợ sử dụng các ngôn ngữ lập trình phổ biến như TypeScript, Python, Java, C#, and Go.
- Terraform tạo kế hoạch thực thi (Terraform Plan), mô tả cơ sở hạ tầng nó sẽ thực hiện thay đổi dựa trên hạ tầng hiện tại và định nghĩa cấu hình của mình.
- Sau khi được duyệt, Terraform tiến hành xây dựng theo đúng kế hoạch nó đề xuất.
Thịnh có thể cho 1 ví dụ cụ thể khi sử dụng Terraform được không?
Chắc chắn rồi. Đây là biểu đồ thể hiện workflow khi team SRE ra mắt 1 module và thực hiện cấp phát cho 1 hạ tầng nào đó.
Các bước phía trên là các bước thực hiện khi ra mắt, gắn phiên bản cho 1 module Terraform. Khi quản lý hạ tầng cho nhiều dịch vụ, một số dịch vụ sẽ có kết cấu hạ tầng giống nhau. Mình đóng gói các hạ tầng vào 1 module và gắn phiên bản lại để quản lý, tái sử dụng được cho các dịch vụ khác. Dĩ nhiên quy trình này được thực hiện theo các tiêu chuẩn về an ninh lẫn tiêu chuẩn của team SRE.
Các bước phía dưới là khi thực hiện cấp phát cho 1 hạ tầng. Khi 1 hạ tầng được cấp phát, phiên bản mới nhất của module Terraform được sử dụng. Tệp code miêu tả hạ tầng được lưu trữ lên Git, khi có event Merge trên Git vào nhánh Master, quy trình CI/CD được kích hoạt. Đầu tiên là chạy Terraform Plan để chaỵ thử (dry run) xem các thay đổi hoặc các thành phần được tạo mới như thế nào. Sau khi chạy thử, xem xét kỹ lưỡng, xác định ổn thoả thì bấm nút Approve. Lúc này Terraform Apply là bước thực hiện cấp phát hạ tầng hoặc thay đổi hạ tầng đang chạy. Bước cuối cùng là thực hiện Merge vào nhánh Master trên Git để cập nhật hạ tầng. À, thông thường quá trình review sẽ có sự tham dự của nhiều thành viên trong team. Terraform khá thuận tiện trong việc giúp cả team nắm tình hình và dễ dàng theo dõi các thay đổi, giúp teamwork hiệu quả.
Bên cạnh teamwork hiệu quả, cách này còn có gì hơn phương pháp truyền thống?
So sánh với phương pháp cấu hình phần cứng vật lý thì mình đánh giá IaC là giải pháp tốt hơn. Có thể xem xét 3 yếu tố chi phí, tốc độ triển khai và rủi ro.
- Về chi phí, thực tế việc triển khai và áp dụng IaC hoàn toàn không tốn tiền vì team mình đang sử dụng phiên bản mã nguồn mở của Terraform.
- Về thời gian và công sức, trước đây team mình mất khoảng 4-8 tiếng để thiết lập hạ tầng cho một dịch vụ. Hiện nay chỉ mất nửa tiếng.
- Việc triển khai thường đi liền với rất nhiều rủi ro, nhưng về mặt này thì có thể nói IaC có ưu thế hơn vì ít xảy ra biến cố. Ngoài ra các module cũng có thể được tiêu chuẩn hoá theo yêu cầu bảo mật chung trên toàn bộ nền tảng, từ đó chúng ta có thể đồng bộ và hạn chế rủi ro xảy ra tấn công từ bên ngoài.
Từ các yếu tố trên, mình cho rằng IaC là một giải pháp tương đối toàn diện.
IaC có bao nhiêu phương pháp?
Có 2 cách là Khai báo (declarative) và Mệnh lệnh (imperative). 2 thuật ngữ này mô tả cách chúng ta tạo nên một bộ hạ tầng.
Vậy 2 phương pháp này có gì khác biệt? Cùng xem xét trên 1 ví dụ là tạo 2 servers.
- Với Khai báo, bạn chỉ cần định nghĩa kết quả mong đợi, mà không cần đi vào diễn giải chi tiết các bước thực hiện quá nhiều. Lấy ví dụ là tạo 2 servers, bạn chỉ cần khai báo “tạo 2 servers" là xong.
- Ngược lại, với Mệnh lệnh, bạn cần liệt kê các câu lệnh theo từng bước cụ thể. Để tạo 2 servers, bạn cần liệt kê cụ thể các bước như “tạo 1 server" -> “thêm 1 server" -> “xác nhận tiến hành".
Các công cụ Khai báo thường được ưa chuộng hơn vì chỉ cần quan tâm đến kết quả cuối mà không cần phải thao tác quá nhiều, đặc biệt hữu ích khi xây dựng các cơ sở hạ tầng với quy mô lớn. Ở BAEMIN mình đang dùng Terraform, cũng là một công cụ khai báo.
Tại sao mình chọn dùng Terraform?
Xét về kỹ thuật, team cân nhắc các công cụ có trong danh sách hỗ trợ của Terraform để đáp ứng quy trình hiện tại. Bên cạnh Git, mình đang dùng Terragrunt - 1 wrapper giúp sắp xếp mã nguồn tinh giản và CircleCI cho nhu cầu CI/CD. Bên cạnh đó, việc quản lý state của hạ tầng cũng là 1 ưu điểm của Terraform.
Để mình giải thích một chút về khái niệm quản lý state. Tưởng tượng như bạn đang chuẩn bị lắp ghép 1 ngôi nhà với một “bản thiết kế vĩ đại” trong tay, Terraform cũng có một “bản thiết kế" tương tự cho cấu hình hạ tầng của bạn. “Bản thiết kế" này chính là state. Giống như bạn không thể lắp ghép mà không có 1 bản thiết kế, Terraform không thể xây dựng cấu hình mà không có state. Terraform sử dụng tệp state để quản lý các tài nguyên mà nó quản lý. Tệp state này thể hiện trạng thái mong muốn của cơ sở hạ tầng, giúp Terraform hiểu rõ những tài nguyên hiện đang triển khai. Điều này đảm bảo Terraform có thể xác định chính xác những thay đổi cần thực hiện để xây dựng cơ sở hạ tầng như mong muốn. Giả sử là bạn thay đổi ý định và xoá thứ gì đó ra khỏi cấu hình, Terraform vẫn đảm bảo kết quả đúng bởi nó đã ghi nhớ các yếu tố phụ thuộc trong tệp state và tự thực hiện các thay đổi cần thiết. Các tệp state này được lưu trữ từ xa, trên cloud (gọi là Remote State) để thuận tiện cho việc quản lý version, tăng cường bảo mật, dễ dàng chia sẻ cho các thành viên trong team và giúp điều phối làm việc nhóm hiệu quả. Hiện tại mình đang lưu các state đó ở AWS S3 bucket.
Ngoài ra, tính cộng đồng cũng là một yếu tố mà các team thường suy xét khi cân nhắc một công cụ mới. Terraform thoả mãn yêu cầu này khá tốt, vì được sử dụng rất rộng rãi, có nhiều tài nguyên miễn phí mà mình có thể tận dụng. Cộng đồng người dùng cũng rất lớn, nên có thể hỗ trợ mình xử lý cả những vấn đề hiếm gặp.
Tổng kết lại thì đây là một công cụ dễ sử dụng, dễ tùy chỉnh và có hệ sinh thái đi kèm lớn.
Vậy công ty mình đã được lợi gì từ việc sử dụng IaC?
Với các ưu điểm của IaC như trên mình đã chia sẻ, chúng ta có thể cụ thể hoá nó thành một con số chính xác cho dễ hình dung. Với chi phí là 0đ, chúng ta có thể giảm thời gian triển khai từ 3 ngày xuống còn 1 ngày cho mỗi dịch vụ.
Nếu chúng ta cân nhắc thêm cả về tốc độ đưa sản phẩm ra thị trường và các rủi ro từ lỗi của con người mà IaC giúp chúng ta tránh được, thì lợi ích của nó còn lớn hơn rất nhiều chứ không chỉ đơn giản là vấn đề chi phí.
Team mình đã hoàn tất dự án IaC này chưa?
Dự án này đã tiến hành được một thời gian rồi nhưng chưa xong hẳn. Sắp tới team SRE sẽ hoàn thiện toàn bộ quy trình CI/CD và IaC cho các dịch vụ của BAEMIN.
Có điều gì khác cần lưu ý khi thực hiện IaC không?
Một kinh nghiệm nho nhỏ từ team là nên tách nhỏ các thành phần của hạ tầng nếu có thể, hay còn gọi là module hoá hạ tầng (modularization). Việc này sẽ hạn chế tối đa conflict có thể xảy ra khi thay đổi hoặc thêm mới hạ tầng trong tương lai.
Rất cám ơn team SRE đã chia sẻ. Chúng ta cùng chờ đón những dự án tiếp theo của team nhé!
__________
Tác Giả: Thịnh Lê - Site Reliability Engineering
Biên Tập: Thuyên Vũ - Developer Relations Associate
