- Do các vấn đề về chủ quyền dữ liệu và tuân thủ GDPR phát sinh từ dịch vụ đám mây của Mỹ, nhu cầu chuyển sang đám mây châu Âu đã xuất hiện
- Dù phải từ bỏ hoàn toàn sự tiện lợi và các dịch vụ tích hợp của AWS, việc chuyển sang dịch vụ lưu trữ châu Âu như Hetzner vẫn mang lại khả năng cắt giảm chi phí ngay lập tức và làm rõ vị trí dữ liệu
- Để nâng cao hiệu quả vận hành hạ tầng, đã xây dựng tự động hóa dựa trên Ansible và một hệ thống giám sát tự quản
- Việc tự xây dựng giúp thiết lập thiết kế bảo mật nghiêm ngặt và cấu trúc hỗ trợ kiểm toán minh bạch
- Về mặt kinh doanh, cũng đạt được các lợi thế chiến lược như giảm 90% chi phí và giảm rủi ro giám sát từ Mỹ
Quá trình chuyển từ AWS sang đám mây châu Âu (Hetzner) và chiến lược duy trì ISO 27001
Trăn trở của một CTO châu Âu: vấn đề tuân thủ khi rời AWS
- Nỗi băn khoăn điển hình mà nhiều lãnh đạo công nghệ gặp phải bắt nguồn từ giới hạn của các nhà cung cấp đám mây Mỹ
- Dù hài lòng với các dịch vụ mạnh mẽ đạt chứng nhận ISO 27001 mà AWS cung cấp, vẫn không thể tránh được việc dữ liệu khách hàng tại châu Âu bị đặt dưới thẩm quyền pháp lý của Mỹ do CLOUD Act và FISA của Mỹ
- Một tình huống phát sinh là rất khó giữ đúng cam kết GDPR bất kể máy chủ thực tế được đặt ở đâu
- Nhận ra chi phí sử dụng đám mây lên tới $24,000 mỗi năm là quá mức so với nhu cầu thực tế
- Cảm nhận rõ rằng việc phụ thuộc tương lai công ty vào một nhà cung cấp có trụ sở tại Mỹ là rủi ro về mặt chiến lược
Giới thiệu trường hợp thực tế của Datapult
- Datapult là một công ty phần mềm quản lý nhân sự của Đan Mạch, nơi các chức năng như lập lịch làm việc cho nhân viên, điều chỉnh phụ cấp làm thêm và quản lý dữ liệu chấm công đòi hỏi mức độ tin cậy tương đương lĩnh vực tài chính
- Công ty đã đáp ứng các yêu cầu pháp lý theo quy trình làm việc dựa trên AWS, nhưng việc chuyển sang on-premise hoặc các dịch vụ thay thế độc lập cần thêm quá trình rà soát pháp lý
Những lo ngại khi rời AWS và các yếu tố mất mát thực tế
- Việc từ bỏ sự tiện lợi tích hợp của AWS tạo ra rào cản tâm lý lớn
- Sẽ mất đi sự đơn giản và tự động hóa như Lambda, RDS chỉ với một cú nhấp chuột, cùng nhiều công cụ tuân thủ tích hợp
- Đồng thời chuyển từ dịch vụ managed sang tình huống tăng quyền kiểm soát trực tiếp và trách nhiệm
Hiệu quả kỳ vọng và lợi ích thực tế của đám mây châu Âu
- Chuyển sang các nhà cung cấp dịch vụ châu Âu (Hetzner, OVHcloud) mang lại lợi ích tức thì về chủ quyền dữ liệu, GDPR và ISO 27001
- Giao tiếp với khách hàng và ứng phó kiểm toán minh bạch hơn nhờ chứng minh được nơi lưu trú dữ liệu thực sự
- Đạt được mức tiết kiệm chi phí ngoài dự kiến (90%) và tính minh bạch ngân sách
- Dù từ bỏ sự tiện lợi của AWS, về mặt kỹ thuật lại có được quy trình tự động hóa mạnh hơn (cấu hình bằng Ansible) và cải thiện bảo mật
- So với trước đây, đạt được tính tự chủ, khả năng đổi mới và hạ tầng có thể kiểm chứng
Chiến lược chuyển đổi cụ thể và các bài học chính
- Tự động hóa tuân thủ bằng Ansible
- Hiện thực hóa quản lý hạ tầng tự ghi chép theo cách liên kết mọi cấu hình máy chủ trực tiếp với các biện pháp kiểm soát trong ISO 27001 Annex A
- Xây dựng hệ thống giám sát thay thế AWS
- Với tổ hợp Prometheus, Grafana, Loki, có thể đạt mức giám sát doanh nghiệp tương đương AWS CloudWatch và phản ứng nhanh với sự cố
- Triển khai security-by-design để tăng cường thiết kế bảo mật
- Trong bối cảnh không còn các công cụ bảo mật managed, tự động hóa bằng Ansible giúp tăng cường ISMS (hệ thống quản lý an toàn thông tin) và khiến nhà phát triển dễ tuân thủ hơn
Hiệu quả chiến lược vượt ra ngoài công nghệ
- Giảm thiểu rủi ro tuân thủ do các luật giám sát của Mỹ
- Tận dụng hạ tầng lưu trữ châu Âu như một điểm khác biệt trong kinh doanh để nâng cao độ tin cậy và giá trị thương hiệu
- Tạo ra cơ chế tái đầu tư chi phí đám mây tiết kiệm được (90%) vào hoạt động kinh doanh cốt lõi
Hướng dẫn áp dụng chiến lược chuyển đổi
- Dựa trên kinh nghiệm migration từ hạ tầng AWS hiện có sang đám mây châu Âu có chủ quyền và duy trì ISO 27001, có thể cung cấp bộ hướng dẫn có thể tái lập
- Khi CTO hoặc nhà sáng lập cân nhắc chuyển từ AWS sang đám mây châu Âu, có thể tư vấn phù hợp về phân tích chi phí, rủi ro tuân thủ, lịch trình triển khai
- Trong vòng một giờ, có thể sắp xếp khác biệt chi phí, các rủi ro pháp lý chính và các bước đầu của migration
1 bình luận
Ý kiến Hacker News
Chúng tôi đã tiết kiệm chi phí bằng cách tự tái triển khai các chức năng cốt lõi của AWS, nhưng nhiều người bỏ qua chi phí thực sự của kiểu hosting DIY, đặc biệt là những phần như hỗ trợ 24/7. Nếu cố tự dựng những thứ đó trong nội bộ thì ngược lại có thể tốn khá nhiều tiền. Mức phí AWS $24.000/năm tương đương 1–2 tháng thuê một freelancer DevOps giỏi hoặc khoảng 1/3 FTE của một lập trình viên lương thấp, và với ngân sách đó thì khó có thể kỳ vọng hỗ trợ phản ứng 24/7. Tất nhiên lựa chọn này có thể hợp lý, nhưng tôi thấy tiếc vì họ không công khai thẳng thắn toàn bộ chi phí thực tế như thời gian phát triển hay vận hành. Tôi cũng đang cân nhắc lựa chọn tương tự, nhưng là vì yêu cầu kinh doanh như khách hàng Đức hơn là để tiết kiệm chi phí. Tuy nhiên mọi thứ sẽ phức tạp hơn và cũng cần mở rộng đội ngũ. Với tư cách CTO, thời gian của tôi có hạn, mà tự lao vào việc này thì là cách dùng thời gian tệ nhất. Tôi nghĩ nên tập trung hơn vào sự phát triển của công ty và sản phẩm. Cá nhân tôi thấy ở quy mô nhỏ như vậy thì Terraform là quá mức cần thiết, còn Ansible phù hợp hơn như một trường hợp YAGNI (You Ain’t Gonna Need It).
Mọi người hay hiểu lầm rằng các nhà cung cấp cloud lớn như AWS, Azure, GCP thật sự cung cấp hỗ trợ ứng dụng 24/7, nhưng thực tế không phải vậy. Chỉ là hạ tầng của họ nhìn chung chạy ổn mà thôi, còn để dùng cho ra hồn thì vẫn cần chuyên gia tự kiểm tra các hóa đơn chi phí khổng lồ hay vấn đề tích hợp. Nói chi phí cloud là TCO (tổng chi phí sở hữu) thực sự là một huyền thoại sai hoàn toàn.
Nếu cố sao chép 100% tính năng của AWS thì có thể rất tốn kém, nhưng nếu chỉ cần 80% thì câu chuyện lại khác. Ngoài ra cũng không thể xem nhẹ công sức thiết lập AWS và liên tục rèn kỹ năng với nó. Ví dụ, thay vì dashboard AWS thì có thể dùng những công cụ tốt hơn như Grafana. Cuối cùng vẫn phụ thuộc vào quy mô và mức độ đa dạng của yêu cầu. Không phải lúc nào cái búa đắt nhất cũng là đáp án đúng.
Nếu chỉ nhìn vào khoản tiết kiệm thì tức là tiết kiệm $21.600/năm, tương đương 90% của $24.000 ban đầu. Nhưng với từng đó ngân sách thì không thể tuyển một kỹ sư SRE/DevOps ở châu Âu. Tôi còn nghĩ rằng theo thời gian, vì phải tự quản toàn bộ hạ tầng nên tổng chi phí sở hữu về dài hạn sẽ còn tăng. Dù vậy tôi vẫn ủng hộ thử thách này.
Nếu tính tới rủi ro chính phủ Mỹ có thể ép Amazon đình chỉ tài khoản thì dùng AWS có thể là một rủi ro. Trong bối cảnh gần đây còn xuất hiện các câu chuyện về chiến tranh giữa Mỹ và châu Âu (Greenland), tôi càng thấy vậy.
Tôi nghĩ cách tính đơn giản $24.000/năm là quá ngây thơ. Tôi cảm giác đang thiếu phần ước tính cụ thể chi phí nhân sự, như cần bao nhiêu người để dựng các dịch vụ này trên AWS, hay cần bao nhiêu nhân lực để giảm từ $48.000–100.000 xuống còn $24.000.
Tôi nghĩ chỉ riêng bộ Prometheus, Grafana, Loki cũng đã có thể tự tái tạo, thậm chí vượt qua, mức độ giám sát từng có trên AWS. Các công cụ này tuyệt vời đến vậy mà dịch vụ monitoring của AWS vẫn đắt, chậm và UX gây thất vọng, điều đó luôn làm tôi ngạc nhiên. Thực tế, chi phí monitoring là phần nhanh chóng trở thành trải nghiệm khó chịu nhất với AWS.
Nhược điểm chính của Hetzner là vấn đề IP bị ô nhiễm do người dùng xấu và nhu cầu xử lý hỏng hóc/nâng cấp phần cứng. Tôi tò mò không biết họ có lo ngại điều đó không. Ngoài ra, họ giải quyết vấn đề Loki ngốn bộ nhớ đột biến thế nào, có phương án thay thế nào khác không.
Vấn đề IP bị ô nhiễm được xử lý bằng cách proxy lưu lượng người dùng qua Cloudflare, rồi cấu hình firewall (ufw) và chỉ cho phép truy cập từ các nguồn được whitelist là IP của Cloudflare, tức là chặn luôn truy cập từ bên ngoài. Với lỗi phần cứng/nâng cấp, thiết lập Terraform cho phép thay thế và mở rộng dung lượng trong thời gian ngắn. Họ giám sát phần cứng bằng Prometheus và node exporter để nhận cảnh báo sớm, và trong 9 tháng chưa có sự cố nào. Ứng dụng gần như không có nhiều dữ liệu, còn cơ sở dữ liệu thì được kiểm thử phục hồi thường xuyên. Vấn đề bộ nhớ của Loki được giải quyết bằng cách kết hợp nhiều biện pháp như chỉnh retention policy và tách index, tinh chỉnh concurrency truy vấn và giới hạn bộ nhớ, dùng nhãn kiểu promtail và structured logging, đồng thời thay các bản ghi cũ bằng backup object storage hoặc grep.
Vấn đề Loki mà chúng tôi gặp phải xuất phát từ việc cấu hình triển khai mặc định như helm chưa được tối ưu đủ tốt. Sau khi làm theo các mẹo hiệu năng được nhắc trong blog như đặt lại index, thêm instance chỉ đọc và áp dụng các khuyến nghị khác, chúng tôi đã thấy hiệu năng cải thiện rõ rệt. Tôi nghĩ họ có ý hướng người dùng sang dịch vụ cloud riêng của họ hơn là bản open source, nên lúc đầu phải tự mò mẫm khá nhiều.
Về lựa chọn thay thế Loki, tôi khuyên dùng Victoria. Nó nhanh hơn nhiều và có danh tiếng tốt, nhưng chúng tôi chọn Loki vì cân nhắc mức độ đa dạng của đội ngũ maintainer của dự án. Các nhược điểm đã được bù lại bằng những cách nói ở trên.
Chia sẻ link https://en.wikipedia.org/wiki/Sybil_attack. Các nhà cung cấp cloud đắt tiền có lợi thế là xây được uy tín IP theo kiểu tương tự PoW (proof of work).
ISO 27001 là tiêu chuẩn quản lý bảo mật quốc tế và là bộ hướng dẫn phổ biến ở châu Âu. Ở Mỹ thì hầu như không áp dụng, và nhiều công ty châu Âu thường khó chấp nhận sự khác biệt này. Nền tảng của tiêu chuẩn bảo mật tại Mỹ là SOC 2, ít nghiêm ngặt hơn ISO 27001 và quen thuộc hơn với thị trường Mỹ.
ISO 27001 vốn không phải một bộ tiêu chí quá cứng nhắc hay hà khắc, mà thường chỉ yêu cầu những điều cơ bản cần làm khi sử dụng phần mềm. Tuy nhiên phần khó là phải chứng minh bằng tài liệu, còn SOC 2 thì gánh nặng giấy tờ nhẹ hơn đáng kể.
Với tư cách người đã trải nghiệm cả SOC 2 lẫn ISO 27001, tôi thấy việc đánh giá SOC 2 có phần bị chi phối quá nhiều bởi năng lực và trực giác của kiểm toán viên, hơn là bởi các kiểm soát thực tế, nên khá đáng tiếc. Tôi thấy ISO 27001 rõ ràng và công bằng hơn nhiều trong kiểm toán.
Có người hỏi hãy nêu tên chỉ một ông lớn cloud của Mỹ mà không có chứng nhận ISO 27001.
Tôi cũng đã làm cấu hình tương tự trên Azure và giảm được 90%. Tôi cảm thấy các tập đoàn lớn cố tình ép người dùng vào trải nghiệm trừu tượng hóa dịch vụ quá phức tạp, khiến việc vận hành đơn giản ngày càng khó hơn.
Một trong những lý do trả tiền cho AWS là để giảm gánh nặng vận hành, và đúng là từ khi dùng managed DB của AWS thì tôi không còn bị stress như trước mỗi lần phải nâng cấp cụm mysql. Tất nhiên chỉ riêng điểm này không thể biện minh cho mức giá cao, nhưng tôi nghĩ nó có giá trị đáng kể.
Tôi không hiểu các con số này. Từ $24.000/năm giảm 90% thì còn $200/tháng, tức chỉ bằng giá một máy chủ Hetzner. Nếu vậy có vẻ chỉ cần một single server, không cần hệ thống phân tán; tôi tò mò lưu lượng request thực tế mỗi giây hay số lượng người dùng là bao nhiêu.
Để tuân thủ ISO 27001 thì không thể vận hành bằng single server, mà còn cần máy chủ riêng cho log và monitoring. Dù tải thế nào thì độ phức tạp bắt buộc vẫn sẽ xuất hiện. Nhân viên không đăng nhập mỗi ngày, và do đặc thù ứng dụng lập lịch nên nhiều người chỉ kiểm tra 1–2 lần mỗi tuần. DAU ở mức 10.000–20.000, peak concurrent users khoảng 1.500–2.000, còn concurrent trung bình là 50–150. Lý do chi phí cloud tăng cao là vì ứng dụng có gánh nặng xử lý dữ liệu lớn từ các tính năng thời gian thực và các quy tắc lao động phức tạp. Ví dụ, việc phân ca còn khác nhau ở cả quy tắc tính thưởng, và tối ưu lịch làm việc cũng đòi hỏi nhiều tính toán.
Có người đính chính rằng đó không phải $2.400 mà là $200.
Tôi tò mò việc mã hóa đĩa được thực hiện thế nào. Trên AWS thì tự động, còn ở các nhà cung cấp hosting thông thường tôi chưa thấy cách triển khai nào thực sự tốt. Cũng có ý kiến chỉ ra rằng nếu lưu khóa mã hóa ở phân vùng boot thì gần như vô nghĩa.
Tôi thật sự rất thích Hetzner nên cả công cụ tìm kiếm của tôi cũng chạy ở đó. Tôi nghĩ dùng máy chủ vật lý là tuyệt nhất.
Ngoài OVH và Hetzner, tôi cũng muốn giới thiệu UpCloud như một cloud châu Âu đáng cân nhắc. Điểm mạnh của UpCloud là có vẻ toàn bộ CPU core đều là core thật, không phải vCPU dựa trên thread. Tuy nhiên tôi thấy tiếc vì thiếu tài liệu tham chiếu chính thức. Việc so sánh OVH, Hetzner với HyperScaler là không đơn giản; riêng Hetzner thì khác biệt một phần vì họ chủ yếu dùng linh kiện cấp độ consumer. Giới thiệu UpCloud