Shipyard: Cách Slack xây dựng nền tảng EC2 thế hệ tiếp theo

• Slack đã chuyển từ cách cũ là liên tục chỉnh sửa các EC2 chạy dài hạn sang triển khai thay thế dựa trên AMI bất biến, áp dụng phương thức triển khai hiện đại ngay cả với những workload khó chuyển sang container
• Trên ảnh nền dùng chung slack-zero, Slack xếp chồng các ảnh riêng cho từng dịch vụ; phần cấu hình nặng được xử lý khi bake image, còn chỉ bí mật theo môi trường và metadata mới được áp dụng lúc khởi động
• Bộ điều phối triển khai Gondola quản lý AMI và artifact Chef được gán phiên bản như một đơn vị triển khai duy nhất, đồng thời thực hiện triển khai theo từng bước dựa trên chỉ số, dừng lại và tự động rollback
• Peekaboo cung cấp toàn bộ inventory EC2 gần như theo thời gian thực, còn The Reaper thay thế các instance đã bị nhiễm bẩn hoặc quá tuổi thọ dưới cơ chế giới hạn tốc độ và tạm dừng khẩn cấp
• Cách này hiệu quả với các dịch vụ chạy ngắn hạn, nhưng với instance chạy dài hạn như data node, GitHub Enterprise hay Atlassian JIRA, vốn không thể thay thế nhanh, vẫn cần cơ chế vá riêng và executor triển khai chuyên biệt

---

Giới hạn của mô hình EC2 bị chỉnh sửa liên tục

• Slack đã thay đổi Chef stack đơn lẻ trước đây thành cấu trúc nhiều stack có khả năng phục hồi, đồng thời đưa vào triển khai cookbook theo phiên bản và quy trình nâng cấp an toàn để tăng độ tin cậy và khả năng kiểm soát vận hành cho hàng chục nghìn EC2 instance
  • Có thể xem quá trình liên quan tại Advancing Our Chef Infrastructure
• Sau đó, Slack đưa vào môi trường production được phân tách, thực thi Chef theo tín hiệu và cách rollout được cải thiện, giúp giảm mạnh phạm vi ảnh hưởng của sự cố mà không buộc các nhóm phải viết lại cookbook
  • Ở giai đoạn Safety Without Disruption, họ có thêm thời gian để lên kế hoạch cho kiến trúc tương lai trong khi vẫn giữ ổn định nền tảng cũ
• Tuy nhiên, mô hình tiếp tục cập nhật các instance chạy dài hạn khiến việc triển khai theo từng dịch vụ trở nên khó khăn, không thể tránh khỏi infrastructure drift, và càng phức tạp hơn khi phải điều phối thay đổi qua nhiều lớp
• Container đã giải quyết một phần vấn đề cho một số workload, nhưng không phải hệ thống nào cũng có thể di chuyển dễ dàng, nên Slack cần một nền tảng áp dụng trực tiếp tính bất biến, triển khai theo từng bước và cơ chế an toàn tự động cho EC2

Mô hình vận hành EC2 mà Shipyard mang lại

• Shipyard là nền tảng EC2 thế hệ tiếp theo của Slack, coi hạ tầng là artifact có thể triển khai thay vì là các instance cần bị chỉnh sửa liên tục
• Bằng cách kết hợp khả năng triển khai theo đơn vị dịch vụ với hệ thống build và điều phối, nó áp dụng cho cập nhật EC2 mức độ an toàn và khả năng dự đoán tương đương nền tảng triển khai ứng dụng

• Hỗ trợ nhiều kiến trúc và hệ điều hành

  • Hỗ trợ nhiều kiến trúc CPU, bao gồm AMD64 và Graviton dựa trên ARM, đồng thời có thể dùng Ubuntu, RHEL và Amazon Linux
  • Các nhóm có thể chọn instance và hệ điều hành theo chi phí, hiệu năng và mức độ tương thích mà không cần triển khai nền tảng riêng
  • Đặc biệt phù hợp với thành phần hạ tầng khó chuyển sang container, các Kubernetes worker node và egress network stack

• Triển khai an toàn dựa trên chỉ số

  • Mỗi dịch vụ được tích hợp với Gondola để thực hiện rollout theo từng bước, bao gồm kiểm tra an toàn tự động dựa trên chỉ số
  • Tùy theo tín hiệu sức khỏe dịch vụ, hệ thống có thể tự động dừng triển khai hoặc rollback tự động về phiên bản ổn định trước đó

• Provisioning nhanh và dễ dự đoán

  • Sử dụng cấu trúc layered image tương tự container để xây dựng image riêng cho từng dịch vụ trên một golden base image dùng chung
  • Giảm công việc phải làm lúc chạy, giúp instance khởi động nhanh và nhất quán trên nhiều region

• Quản lý cấu hình đơn giản hơn

  • Trước đây, các job Chef theo lịch sẽ định kỳ kiểm tra và áp lại cấu hình, đưa những thay đổi thủ công hoặc ngoài dự kiến quay về trạng thái mong muốn
  • Trong Shipyard, cấu hình chỉ được áp dụng ở những giai đoạn vòng đời rõ ràng như bake image và provisioning ban đầu
  • Công cụ quản lý cấu hình chủ yếu được dùng để triển khai dịch vụ, thay vì liên tục sửa đổi toàn bộ hệ thống
  • Nhờ vậy, tải nền và việc ghi đè ngoài ý muốn giảm xuống, còn instance không tiếp tục thay đổi theo thời gian nên hành vi của chúng dễ suy luận hơn

• Instance có tuổi thọ giới hạn

  • Mỗi instance được gán tuổi thọ giới hạn và được tự động thay thế định kỳ
  • Điều này rút ngắn khoảng thời gian mà lỗ hổng tiềm ẩn có thể gây ra vấn đề, đồng thời buộc các nhóm thay thế thay vì chỉnh sửa instance đang chạy

Inventory Peekaboo và khả năng quan sát toàn fleet

• Peekaboo là hệ thống inventory hiển thị trạng thái fleet EC2 gần như theo thời gian thực bằng cách dùng cloud event và metadata instance thay cho Chef Server
• Nó cũng theo dõi cả những instance được triển khai ngoài Shipyard, cho phép xem toàn bộ fleet tại một nơi
• Được xây dựng bằng AWS EventBridge, OpenSearch và Lambda, và cung cấp các giao diện sau
  • UI để khám phá fleet
  • API để tích hợp hệ thống
  • CLI để kiểm tra nhanh trên dòng lệnh
• Bằng cách tập trung hóa thông tin EC2, hệ thống thống nhất telemetry và điểm quản lý trên toàn môi trường

Golden base image slack-zero

• slack-zero là machine image dùng chung do Compute Platform Team xây dựng và đồng quản lý cùng các nhóm bảo mật và giám sát
• Đây là nền tảng tiêu chuẩn, đáng tin cậy mà mọi dịch vụ kế thừa, còn các nhóm dịch vụ sẽ tự cấu hình môi trường runtime của họ trên đó
• Image bao gồm các thành phần sau
  • Baseline hệ điều hành và thiết lập hardening bảo mật
  • Cấu hình networking và service discovery
  • Agent giám sát và bảo mật
  • Công cụ dùng chung và cấu hình hệ thống nền tảng
• Base image được coi là đối tượng bất biến nhưng tạm thời
  • Khi cần bản vá bảo mật, cập nhật giám sát hoặc cải tiến mạng, Slack tạo image slack-zero mới
  • Các service image cấp dưới được build lại trên nền tảng mới để kế thừa các thay đổi

• Vì sao chọn AWS Image Builder

  • slack-zero được xây dựng bằng AWS Image Builder thay cho Packer trước đây
  • Lifecycle policy tự động dọn dẹp các AMI cũ để giảm chi phí lưu trữ
  • Khi tạo image mới, hệ thống cập nhật tham số AWS Systems Manager (SSM) trỏ tới AMI mới nhất của từng account, và pipeline dịch vụ sẽ đọc tham số này để dùng base image mới nhất
  • Khi bake image thành công, EventBridge và Lambda tự động khởi chạy các pipeline cấp dưới trong account của chủ sở hữu dịch vụ
  • Trước khi publish AMI, hệ thống chạy test xác minh trên các instance tạm thời để giảm rủi ro rollout lên production

Bake và provisioning cho service image

• Mỗi nhóm dịch vụ tạo AMI riêng dựa trên slack-zero, kế thừa các thành phần nền tảng chung trong khi vẫn kiểm soát môi trường runtime của mình
• Pipeline service image định nghĩa các mục sau
  • Phần mềm cần cài đặt
  • Cách cấu hình dịch vụ
  • Quy trình khởi tạo instance cho dịch vụ đó
• Phần lớn cấu hình được đưa sẵn vào image để tăng tốc độ chạy, tính nhất quán và giảm thiểu configuration drift

• Tách biệt vai trò thành hai giai đoạn

  • Ở giai đoạn baking, hệ thống cài đặt package và cấu hình dùng chung giữa các môi trường, để instance ở trạng thái tốt và gần như sẵn sàng trước khi khởi chạy
  • Ở giai đoạn provisioning, chỉ những thiết lập phụ thuộc môi trường như bí mật, cấu hình theo region và metadata triển khai mới được áp dụng lúc boot
  • Thông thường chỉ thực hiện đặt file cấu hình, lấy bí mật và khởi động dịch vụ
  • Việc chuyển các tác vụ nặng như cài package sang baking giúp instance có thể khởi động trong vài giây thay vì vài phút
  • Khởi động nhanh rất quan trọng với sự kiện scale, triển khai tuần tự và thay thế instance tự động, còn provisioning tối thiểu giúp hạn chế drift phát sinh trong quá trình thích nghi khi runtime

Cập nhật fleet xoay quanh thay thế AMI

• Các thay đổi được rollout qua pipeline triển khai sau khi tạo AMI mới, và fleet được làm mới bằng thay thế có kiểm soát thay vì vá các instance hiện có
• Auto Scaling Group (ASG) dùng AWS Instance Refresh, còn Kubernetes worker fleet dùng Karpenter
• Những dịch vụ có yêu cầu triển khai đặc biệt có thể thêm executor riêng, và Gondola hợp nhất các mô hình khác nhau thành một trải nghiệm triển khai nhất quán

• Đường xử lý khẩn cấp

  • Trong tình huống khẩn cấp, có thể áp dụng thay đổi cấu hình giới hạn lên instance đang chạy, nhưng sau đó vẫn phải thay thế instance đó thông qua pipeline triển khai chuẩn
  • Hệ thống dùng tài liệu định nghĩa sẵn trong AWS Systems Manager để chạy recipe Chef được chọn nhằm áp dụng bản sửa khẩn cấp
  • Khi hệ thống ổn định trở lại, các instance sẽ được luân chuyển để quay về trạng thái bất biến mong muốn

Triển khai theo từng bước với Gondola

• Pipeline của khách hàng có thể được cấu thành từ nhiều giai đoạn phù hợp với yêu cầu dịch vụ và vận hành
• Mỗi giai đoạn trong Gondola đại diện cho một đơn vị triển khai như ASG, Kubernetes cluster hoặc nhóm EC2 instance
• Egress Team tách riêng ASG canary và production ở từng availability zone, rồi sắp xếp các giai đoạn để cập nhật chảy tuần tự
• Gondola theo dõi các chỉ số quan trọng trong khi cập nhật từng giai đoạn, và nếu phát hiện vấn đề sẽ tự động rollback để ngăn sự cố lan rộng

• Artifact triển khai và executor

  • Gói triển khai do Gondola tạo ra gồm hai phần
    • AMI để triển khai lên fleet
    • Chef artifact chứa recipe được gán phiên bản và liên kết với Git commit
  • Hai thành phần này được xử lý như một đơn vị triển khai duy nhất, và mỗi giai đoạn sẽ rollout thông qua executor do dịch vụ định nghĩa
  • Với triển khai ASG, executor cập nhật launch template bằng AMI và cấu hình mới
  • Mã Chef được đóng gói vào Amazon S3
  • Bootstrapper tích hợp trong instance mới sẽ lấy đúng artifact và chạy recipe liên quan
  • Hệ thống dùng metadata cấu hình để chỉ áp dụng đúng thiết lập cho vai trò tương ứng
  • Trong Kubernetes worker fleet, executor truyền cho Karpenter AMI và cùng metadata cấu hình như vậy, và node cũng được bootstrap theo cùng cách
  • Kể cả khi thêm executor cho các kiểu triển khai đặc thù, cách dùng AMI, artifact cấu hình có phiên bản và bootstrap dựa trên metadata vẫn được giữ nguyên

Phân chia trách nhiệm giữa nhóm nền tảng và nhóm dịch vụ

• Các nhóm Compute, Security và Monitoring quản lý các thành phần hạ tầng toàn cục ở lớp nền, bản vá bảo mật và cấu hình bắt buộc
• Các nhóm dịch vụ xây dựng AMI riêng bằng cách thêm phần mềm của họ và cấu hình đặc thù dịch vụ lên trên nền tảng đó
• Khi nhóm Compute triển khai bản vá bảo mật, monitoring agent hoặc thay đổi networking, các nhóm dịch vụ phải đưa base image đã cập nhật vào AMI của riêng mình
• Mô hình trách nhiệm chia sẻ này dung hòa tính tự chủ theo từng dịch vụ với sự nhất quán, bảo mật và độ tin cậy của toàn fleet

Ngoại lệ bí mật, không phải bất biến hoàn toàn

• Package và cấu hình trên các Shipyard instance phần lớn được cố định từ lúc baking, nhưng bí mật là ngoại lệ
• Dịch vụ Consul Template trên từng instance phân phối bí mật mới từ Vault mà không cần thay cả fleet
• Vì thông tin xác thực hay chứng chỉ có thể được làm mới động, Shipyard là hạ tầng bán bất biến, chỉ cố định lớp hệ thống cốt lõi và lớp dịch vụ
• Cách này vẫn giữ được độ ổn định và khả năng dự đoán, đồng thời cho phép cập nhật các bí mật runtime quan trọng khi cần

Chính sách thay thế của The Reaper

• The Reaper quyết định mục tiêu thay thế dựa trên hai loại đầu vào
  • Tín hiệu nhiễm bẩn từ hệ thống bên ngoài như công cụ bảo mật hoặc sự kiện AWS EC2, cho biết instance đã lệch khỏi trạng thái mong muốn
  • Kiểm tra định kỳ để xem instance có chạy quá tuổi thọ tối đa cho phép hay không
• Khi thỏa mãn một trong hai điều kiện, hệ thống sẽ lên lịch thay thế instance theo chính sách của dịch vụ
• Truy cập từ xa thủ công vẫn được cho phép trong tình huống khẩn cấp, nhưng nếu đăng nhập trực tiếp vào node cấp production thì một tín hiệu sẽ được phát ra để đánh dấu instance đó là mục tiêu thay thế trong tương lai
• Hệ thống tích hợp với Peekaboo để theo dõi tuổi của instance trên toàn fleet, và các node chạm ngưỡng tuổi thọ tối đa cũng đi theo cùng quy trình kết thúc bình thường và thay thế
• Trong tương lai, Slack dự định bổ sung khả năng nhận biết ngữ cảnh để chỉ những thay đổi có ý nghĩa như cập nhật phần mềm hoặc configuration drift mới kích hoạt thay thế, còn các thao tác chỉ đọc hoặc rủi ro thấp sẽ không gây ra việc luân chuyển không cần thiết

• Tốc độ thay thế và kiểm soát khẩn cấp

  • Cơ chế giới hạn tốc độ tích hợp sẵn quy định số instance có thể được thay thế cùng lúc theo từng dịch vụ, region và availability zone để tránh ảnh hưởng đột ngột tới năng lực
  • Một cơ chế tạm dừng toàn cục tên “big red button”, dựa trên việc đặt control object vào S3, có thể dừng toàn bộ hoạt động của Reaper trong thời gian sự cố hoặc giai đoạn rủi ro cao
  • CLI dùng để quản lý giới hạn tốc độ, kiểm tra cấu hình và bật hoặc tắt trạng thái tạm dừng toàn cục
  • Trong các tình huống break-glass cần điều tra sâu, có thể dùng các phương thức truy cập được kiểm soát như chứng chỉ SSH thời hạn ngắn

Kiểm thử hạ tầng thực tế bằng Ship Quick

• Ship Quick là workflow dành cho nhà phát triển, cho phép nhóm nền tảng và chủ sở hữu dịch vụ chạy các bài test baking và provisioning sát thực tế trên hạ tầng thật trước khi merge pull request
• Nhà phát triển chạy lệnh CLI trong kho cookbook và định nghĩa ca kiểm thử bằng file YAML
• Ship Quick xử lý theo thứ tự sau
  • Đóng gói cookbook và tải lên S3
  • Gửi thông điệp workflow vào hàng đợi
  • Worker instance do Longshoremen quản lý lấy tác vụ
  • Worker tách khỏi Auto Scaling Group và chạy workflow Chef
  • Ghi log được stream về CLI rồi instance kết thúc; nhà phát triển cũng có thể chọn giữ lại để debug

• Fleet worker theo từng lớp nền tảng

  • Do cấu trúc bootstrap, Slack vận hành hai fleet worker tách biệt
  • Fleet Ubuntu cơ bản dùng để bake và kiểm thử base image trên AMI Ubuntu sạch, vì slack-zero không thể tự build trên chính nó
  • Fleet slack-zero dùng để kiểm thử cookbook của các nhóm dịch vụ vốn phụ thuộc vào slack-zero đã được bake sẵn
  • Nó xác minh provisioning trên cùng nền tảng như production
  • Các fleet này liên tục được cập nhật bằng image mới nhất để phản ánh môi trường production hiện tại
  • Cả hai fleet đều tự động scale theo nhu cầu
  • Những nhóm tạo image trong AWS account riêng có thể cấu hình fleet worker chuyên dụng và gửi tác vụ Ship Quick tới đó để giữ tính cách ly

Mở rộng sang workload chạy dài hạn

• Hiện tại Shipyard hoạt động hiệu quả với dịch vụ chạy ngắn hạn, và Slack vẫn đang tiếp tục onboard các nhóm từ nền tảng EC2 cũ
• Thách thức tiếp theo là các instance chạy dài hạn, không thể luân chuyển nhanh
  • Data node của Slack
  • Các dịch vụ singleton như GitHub Enterprise
  • Các instance công nghệ nghiệp vụ bên thứ ba như Atlassian JIRA
• Những workload này cần cách vá và cập nhật an toàn, cùng chính sách vòng đời để The Reaper có thể xử lý đúng
• Slack đang hợp tác với các nhóm dịch vụ để phát triển executor cho workload chạy dài hạn dành cho Gondola, và sẽ tiếp tục cải thiện công cụ, workflow nhà phát triển và trải nghiệm triển khai khi phạm vi áp dụng mở rộng
• Trong tương lai, Slack sẽ đề cập riêng đến API của Shipyard, pipeline image, workflow nhà phát triển, các thành phần của hệ thống inventory và những vấn đề phát sinh trong quá trình mở rộng nền tảng