Những quyết định hạ tầng tôi thấy đúng đắn/hối tiếc (gần như) toàn bộ sau 4 năm vận hành hạ tầng tại một startup

 (cep.dev)
87 điểm bởi xguru 2024-02-28 | 4 bình luận | Chia sẻ qua WhatsApp
  • Với mọi lựa chọn, tác giả đều đánh dấu là Endorse (ủng hộ) hoặc Regret (hối tiếc)

Lựa chọn AWS

  • Chọn AWS thay vì Google Cloud: Ủng hộ quyết định chọn AWS. AWS tập trung vào khách hàng. Google Cloud tạo cảm giác phụ thuộc vào robot và tự động hóa.
  • EKS: Ủng hộ việc dùng EKS. EKS cung cấp tích hợp sâu với các dịch vụ AWS, và Kubernetes cũng đã bắt kịp trên nhiều phương diện (ví dụ tích hợp với Route53 bằng externaldns).
  • Managed Add-on của EKS: Hối tiếc vì dùng managed add-on của EKS. Có nhu cầu phải tùy biến cài đặt, và sau khi chuyển sang helm chart thì trải nghiệm vận hành tốt hơn.

Cơ sở dữ liệu và caching

  • RDS: Ủng hộ việc dùng RDS. Dữ liệu là phần quan trọng nhất của hạ tầng, và chi phí dùng RDS là xứng đáng.
  • Redis ElastiCache: Ủng hộ việc dùng Redis. Redis rất hiệu quả cho caching và cả các nhu cầu sử dụng tổng quát.
  • ECR: Ủng hộ việc chuyển từ quay.io sang ECR. ECR ổn định hơn và tích hợp phân quyền sâu hơn.

Mạng và hỗ trợ

  • AWS VPN: Ủng hộ việc dùng AWS VPN. VPN rất đơn giản để thiết lập và dễ hiểu. Tác giả dùng Okta để quản lý quyền truy cập VPN và có trải nghiệm rất tốt.
  • AWS Premium Support: Hối tiếc. Chi phí của AWS Premium Support rất đắt, và nếu không thiếu kiến thức nội bộ về AWS thì nó không đáng giá.
  • Control Tower Account Factory for Terraform: Ủng hộ tích hợp AFT. Nó giúp tự động hóa việc tạo account và hỗ trợ chuẩn hóa tagging.

Tự động hóa quy trình

  • Tự động hóa postmortem bằng bot Slack: Ủng hộ việc tự động hóa quy trình postmortem. Nó giúp thúc đẩy mọi người viết postmortem.
  • Dùng incident template của PagerDuty: Ủng hộ việc dùng template khi xảy ra incident. Có thể tận dụng tính linh hoạt của Notion để tùy biến một chút.
  • Rà soát định kỳ ticket PagerDuty: Ủng hộ việc rà soát định kỳ cấu hình cảnh báo. Điều này giúp đảm bảo ngay cả những cảnh báo không quan trọng cũng không bị bỏ mặc.
  • Quản lý postmortem trong Datadog hoặc PagerDuty: Hối tiếc vì dùng công cụ quản lý tập trung cho postmortem. Cả hai đều khó tùy biến quy trình hậu sự cố. Tác giả cho rằng dùng một công cụ mạnh như Notion sẽ tốt hơn.

Khác

  • Họp theo dõi chi phí hàng tháng: Ủng hộ việc họp hàng tháng để rà soát chi phí SaaS. Việc này giúp xác nhận chi phí có hợp lý hay không và đưa ra hành động cần thiết. Trên AWS, tác giả nhóm các khoản mục theo tag và tách theo account. Tác giả khuyến nghị không chỉ dừng ở AWS mà nên xem xét mọi nguồn chi tiêu lớn của công ty.
  • Không dùng FaaS nhiều hơn: Hối tiếc vì không thể dùng FaaS một cách triệt để do không có lựa chọn FaaS cho workload GPU. Nhiều workload CPU lẽ ra có thể xử lý bằng FaaS. Một lợi ích ẩn khác của Lambda là rất dễ theo dõi chi phí với độ chính xác cao.
  • GitOps: Ủng hộ việc dùng GitOps. Tác giả đang dùng GitOps cho nhiều phần của hạ tầng và đầu tư phát triển công cụ để hiểu trạng thái triển khai.
  • Ưu tiên hiệu quả của đội ngũ: Ủng hộ việc ưu tiên nâng cao hiệu quả của team. Tác giả chưa từng hối tiếc vì đã đầu tư thời gian vào tự động hóa hay tài liệu hóa.
  • Nhiều ứng dụng dùng chung một cơ sở dữ liệu: Hối tiếc vì để nhiều ứng dụng dùng chung một cơ sở dữ liệu. Điều này gây ra nhiều vấn đề.

Áp dụng SaaS

  • Triển khai nền tảng định danh quá muộn: Trước đây tác giả dùng Google Workspace để gán quyền, nhưng hối tiếc vì đã không triển khai sớm hơn một giải pháp định danh như Okta. Okta tích hợp tốt và giúp giải quyết các vấn đề về bảo mật và tuân thủ.
  • Notion: Ủng hộ việc dùng Notion để viết tài liệu. Notion là lựa chọn tuyệt vời và dễ dùng hơn nhiều so với các công cụ từng dùng trước đây (Wikis, Google Docs, Confluence, v.v.). Khái niệm database để tổ chức trang rất hữu ích.
  • Slack: Ủng hộ việc dùng Slack. Đây là công cụ hiệu quả làm nền tảng cho giao tiếp.

Công cụ và dịch vụ phát triển

  • Chuyển từ JIRA sang Linear: Ủng hộ việc dùng Linear thay cho JIRA. Tác giả thấy JIRA quá phức tạp và nặng nề.
  • Không dùng Terraform Cloud: Không hối tiếc vì không dùng Terraform Cloud do không thể biện minh cho chi phí. Tác giả đã chuyển sang Atlantis và thêm phần tự động hóa cần thiết vào pipeline CI/CD.
  • GitHub Actions cho CI/CD: Khá ủng hộ việc dùng GitHub Actions. Các action trên marketplace và cú pháp của nó khá dễ dùng. Nhược điểm là hỗ trợ cho workflow self-hosted còn hạn chế.

Lựa chọn công nghệ

  • Datadog: Hối tiếc vì dùng Datadog. Chi phí rất đắt, và mô hình giá không phù hợp với các cụm Kubernetes và các công ty AI.
  • PagerDuty: Ủng hộ việc dùng PagerDuty. Sản phẩm tốt và giá cả hợp lý.
  • Schema migration by Diff: Khá ủng hộ việc dùng công cụ cho schema migration. Dữ liệu rất quan trọng và schema migration có thể mang rủi ro.
  • Ubuntu for dev servers: Ủng hộ việc dùng Ubuntu cho máy chủ phát triển. Nó được hỗ trợ tốt và có sẵn hầu hết các package cần thiết.
  • AppSmith: Ủng hộ việc dùng AppSmith để tự động hóa quy trình cho các kỹ sư nội bộ. Tác giả self-hosted nó và thấy đủ hài lòng. Ban đầu đã thử dùng retool để tìm kiếm tích hợp sâu hơn, nhưng khi đó không thể biện minh cho mức giá chỉ để có vài tích hợp.
  • helm: Ủng hộ việc dùng Helm v3. Có vấn đề với triển khai CRD và việc đào tạo cho developer, nhưng nó đủ tốt để đóng gói và triển khai các đối tượng Kubernetes.
  • helm chart trong ECR (oci): Ủng hộ việc lưu helm chart trong OCI registry. Cách này ít vấn đề hơn so với cách cũ dùng S3 và plugin.
  • bazel: Chưa chắc chắn về bazel. Nó có vẻ quá mức cần thiết cho triển khai dịch vụ Go, và GitHub Actions dễ tiếp cận hơn với nhiều kỹ sư.
  • Không dùng OpenTelemetry: Hối tiếc vì gửi metric bằng cách dùng trực tiếp DataDog API. Tác giả khuyến nghị dùng OpenTelemetry ngay từ đầu.
  • Chọn renovatebot thay vì dependencyabot: Hối tiếc vì lẽ ra nên nghĩ sớm hơn về việc giữ dependency luôn cập nhật. Renovatebot có thể tùy biến nhưng cấu hình và debug khá phức tạp.
  • Kubernetes: Ủng hộ việc dùng Kubernetes. Cần một phương thức để host các dịch vụ chạy dài hạn, và Kubernetes phổ biến cũng như hoạt động tốt.
  • Mua IP riêng: Ủng hộ việc mua block IP riêng khi làm việc với đối tác bên ngoài. Điều này giúp cung cấp cho đối tác một CIDR block lớn hơn để whitelist.
  • Chọn Flux cho k8s GitOps: Không hối tiếc khi chọn Flux làm công cụ GitOps cho Kubernetes. Cần phát triển thêm công cụ để hiểu trạng thái triển khai.
  • Karpenter cho quản lý node: Ủng hộ việc dùng Karpenter khi sử dụng EKS. Nó đáng tin cậy và hiệu quả chi phí hơn các autoscaler khác.
  • Dùng SealedSecrets: Hối tiếc vì dùng SealedSecrets. Nó phức tạp với developer và làm mất đi khả năng tự động xoay vòng mật khẩu sẵn có của AWS.
  • Dùng ExternalSecrets: Ủng hộ việc dùng ExternalSecrets để đồng bộ mật khẩu AWS -> Kubernetes. Cách này dễ hiểu hơn với developer và có thể dễ dàng tạo/cập nhật mật khẩu trong AWS bằng terraform.
  • Dùng ExternalDNS: Ủng hộ việc dùng ExternalDNS. Nó đồng bộ bản ghi DNS Kubernetes -> Route53 và gần như không có vấn đề gì trong 4 năm qua.
  • Dùng cert-manager: Ủng hộ việc dùng cert-manager để quản lý chứng chỉ SSL. Nó rất trực quan cho việc tạo chứng chỉ Let's Encrypt và không gặp vấn đề gì.
  • Bottlerocket cho EKS: Hối tiếc vì vận hành cụm EKS với Bottlerocket. Các vấn đề về networking CSI xảy ra thường xuyên và khó debug.
  • Chọn Terraform thay vì CloudFormation: Ủng hộ việc dùng Terraform. Nó dễ mở rộng sang các nhà cung cấp SaaS khác và có cú pháp dễ đọc hơn CloudFormation.
  • Không dùng giải pháp IaC dạng code: Không hối tiếc. Terraform và CloudFormation dùng file dữ liệu, trong khi Pulumi hay CDK mô tả hạ tầng bằng code. Tính chất hạn chế của HCL trong Terraform giúp giảm độ phức tạp.
  • Không dùng network mesh: Không hối tiếc. Network mesh rất hay, nhưng các công ty thường có xu hướng đánh giá thấp độ phức tạp của nó. Một lời khuyên chung về hạ tầng là “càng ít càng tốt”.
  • Nginx load balancer cho EKS ingress: Không hối tiếc. Ủng hộ việc dùng Nginx. Đây là công nghệ cũ nhưng ổn định và đã được kiểm chứng.
  • homebrew cho company scripts: Ủng hộ việc dùng homebrew để phân phối script của công ty. Nó đủ tốt để phân phối script và binary cho cả người dùng Linux lẫn Mac.
  • Go cho services: Ủng hộ việc dùng ngôn ngữ Go cho các service. Nó dễ để kỹ sư mới học và nhìn chung là lựa chọn tốt.

Bài viết liên quan

4 bình luận

 
nicewook 2024-02-28

Cả bài viết lẫn bình luận đều rất đáng giá.
 
mhj5730 2024-02-28

Chà... đây đúng là thông tin thực tiễn rất khó tìm được ở nơi khác.
 
xguru 2024-02-28

Ý kiến trên Hacker News

  • Chi phí bổ sung khi dùng RDS là xứng đáng

    • Phần chi phí cộng thêm khi dùng RDS nghe buồn cười vì đắt một cách phi thực tế mỗi khi cân nhắc thay thế nó bằng một cụm SQL server colocated. Mức giá này vượt xa rất nhiều so với số tiền tôi sẵn sàng trả, đến mức có thể trang trải rack colocated, AWS Direct Connects, server, SAN, giấy phép SQL Server, hợp đồng bảo trì, và cả lương của một DBA nội bộ làm toàn thời gian.
    • Tổng chi phí 12 tháng: 547,441.85 USD
    • Khi mức markup đủ lớn để trả lương cho một hoặc nhiều nhân sự toàn thời gian, bạn nên cân nhắc tuyển người thay vì cứ mở rộng RDS một cách mù quáng. Khi dùng RDS, bạn thực sự đang trả rất nhiều tiền, và cần đánh giá lại quyết định đã đưa ra ở giai đoạn khởi nghiệp ban đầu.

  • Có thể đây là ý kiến không phổ biến, nhưng Google Cloud tốt hơn AWS; với Google Cloud Run, việc chạy Docker container trên cloud đúng là như mơ. Tên dịch vụ đơn giản, số lượng dịch vụ quan trọng cần quan tâm ít hơn so với hệ dịch vụ phức tạp của AWS, và UI trực quan hơn. Nhược điểm là thiếu tutorial do cộng đồng nhỏ hơn, khó tìm người có kinh nghiệm, và ít công cụ bên thứ ba hơn. Tôi khuyên nên thử.

  • Dùng EC2 + ASG rất thoải mái. Về mặt khái niệm thì đơn giản: triển khai image lên ASG rồi thiết lập policy auto scaling. Gần như không phải lo gì cả. Trong khi đó, dùng k8s lúc nào cũng là việc lớn. Người ta lập cả một đội chỉ để quản lý k8s. Họ đưa vào hàng chục khái niệm của k8s hoặc đầu tư hàng người-năm vào “platform engineering” để che giấu các khái niệm đó. Họ phát hành guideline, SDK và đủ loại validator để mọi người có thể dùng k8s “đúng cách”. Dù vậy, họ vẫn viết hàng chục nghìn dòng YAML và code để triển khai operator. Đôi khi tôi tự hỏi liệu k8s có quá xâm lấn hay không.

  • Ý kiến về các sản phẩm SaaS

    • Tôi không hiểu việc chuyển từ JIRA sang Linear. Linear ổn, nhưng tôi thường xuyên gặp những thứ nó không làm được hoặc tôi không biết cách làm.
    • Tôi nhìn chung khuyến nghị dùng Terraform Cloud. Việc tự nuôi một hệ thống tại nhà có thể ổn trong vài năm đầu, nhưng về lâu dài có thể rất tốn kém.
    • Tôi phần nào ủng hộ việc dùng GitHub Actions cho CI/CD. Thay vào đó, tôi đề xuất dùng GitLab.
    • Tôi phản đối mạnh ý kiến về Datadog. Đây là công cụ monitoring/observability tốt nhất trên thị trường. Phàn nàn phổ biến nhất là chi phí, nhưng phần lớn là do cấu hình Datadog sai cách khiến chi phí tăng bùng nổ.
    • Tôi đồng tình về Pagerduty. Pagerduty đắt hơn Opsgenie khoảng 10 lần mà không cung cấp tính năng tốt hơn. Khi gia hạn hợp đồng với Pagerduty, tôi hỏi nhân viên kinh doanh rằng họ có tính năng gì mà Opsgenie không có, và họ trả lời rằng họ đang cố định vị mình là thương hiệu cao cấp trên thị trường. Vậy nên tôi thấy hài lòng khi dùng thương hiệu bình dân cho incident reporting.

  • Tôi tưởng tượng các lập trình viên từ thập niên 90/00 sẽ đọc danh sách này và thấy bối rối trước độ phức tạp cũng như thuật ngữ.

  • Bài đọc khá thú vị, nhưng tôi không chắc tác giả có hối hận đủ nhiều để phải viết hẳn một bài blog hay không.

  • Tôi cảm thấy thôi thúc muốn thử quay lại với một server khổng lồ giá $100k và chạy mọi thứ trong một cỗ máy duy nhất.

  • Tôi đã học được những điều cơ bản của Kubernetes / EKS, nhưng đang cân nhắc chuyển sang ECS. Kubernetes quá phức tạp so với nhu cầu của chúng tôi. Nó khó kiểm soát bằng thứ như CloudFormation. Load balancer được provision từ các add-on cũng khó tham chiếu từ bên ngoài Kubernetes. Việc logging từ EKS Fargate sang Cloudwatch dường như không hoạt động dù đã làm theo tài liệu. Các metric CPU/memory cũng không hoạt động như trên EKS EC2, và có vẻ cần ADOT. Với ECS, tôi có thể dựng lại môi trường trong 1/10 thời gian và mọi thứ đều hoạt động tốt.

  • Tôi thích cách bài này được viết và cả nội dung của nó. Tôi không đồng ý với một số quyết định và khuyến nghị, nhưng ngay cả trong những trường hợp đó, việc đọc lý do vẫn rất hữu ích. Sẽ rất hay nếu có thêm nhiều bài tương tự được xuất bản để có thể so sánh. Tôi thấy được truyền cảm hứng để tự viết một bài tương tự.

  • Cơ sở dữ liệu kiểu “bồn rửa chén” mà ai cũng dùng là một vấn đề phổ biến, nhưng nó cứ lặp đi lặp lại. Khi hệ thống phát triển, nó trở thành khoản nợ kỹ thuật đáng kể và nút thắt hiệu năng. Dùng managed DB như RDS giúp bạn dễ dàng vận hành các cụm DB riêng cho từng ứng dụng chính.