Bài đăng trên blog này là về cách đã gỡ bỏ các phần cơ sở hạ tầng cuối cùng của mình trên DigitalOcean, đánh dấu quá trình chuyển đổi sang AWS là hoàn tất. ChartMogul Hành trình không phải là quá trình di chuyển AWS thông thường của bạn vì nó liên quan đến việc di chuyển cơ sở hạ tầng của chúng tôi từ các máy ảo cổ điển sang các vùng chứa do Kubernetes điều phối. Trong loạt bài viết, chúng tôi sẽ chia sẻ kinh nghiệm của mình về: Hành trình của chúng tôi đến AWS EKS (dịch vụ do Kubernetes quản lý). Một số rào cản quan trọng nhất mà chúng tôi gặp phải. Ngăn xếp và công cụ hiện tại của chúng tôi. Các kế hoạch cơ sở hạ tầng của chúng tôi trong tương lai, hy vọng chúng có thể hữu ích cho toàn bộ cộng đồng. Cuộc sống với DigitalOcean Kể từ khi thành lập vào năm 2014 và đến giữa năm 2021, toàn bộ cơ sở hạ tầng của chúng tôi đã chạy trên các giọt DigitalOcean (máy ảo đám mây tự quản lý). Chúng tôi cần một nhà cung cấp đám mây để giúp chúng tôi khởi động nhanh chóng, đáng tin cậy và tiết kiệm chi phí. DigitalOcean rất có ý nghĩa và là một lựa chọn tuyệt vời. Chúng ta ở đâu vì chúng. Lựa chọn đó giúp chúng tôi tự do tập trung vào việc xây dựng sản phẩm mà không phải lo lắng về khả năng mở rộng và sự phức tạp của cơ sở hạ tầng - những khía cạnh thường phát sinh ở giai đoạn sau. Mọi khía cạnh của cơ sở hạ tầng của chúng tôi đều được cung cấp, định cấu hình và quản lý nội bộ. Chúng tôi đã sử dụng quản lý cấu hình và Cơ sở hạ tầng làm công cụ Mã (Saltstack và Terraform) để quản lý mọi thứ. Chúng tôi liên tục phát triển trong những năm qua và đến năm 2019, chúng tôi nhận thấy mình đang xem xét một nhóm khoảng 50 máy có nhu cầu liên tục về quản lý, cập nhật phần mềm, bản vá bảo mật, v.v. Và với các dự án mới đang được triển khai, chúng tôi dự kiến nhu cầu năng lượng máy tính của chúng tôi sẽ tăng gấp đôi vào cuối năm 2020. Tại sao di chuyển và tại sao ngay bây giờ? DigitalOcean là một lựa chọn tuyệt vời, sự phát triển hữu cơ của chúng tôi đã thúc đẩy ranh giới thiết lập của chúng tôi trong những năm qua. Chúng tôi phải đối mặt với những thách thức với nhiều lĩnh vực, một số có thể khắc phục được và có thể ngăn ngừa được, một số thì không. Các lỗi khác nhau Các cửa sổ bảo trì không báo trước đặc biệt đột ngột làm gián đoạn hoạt động sản xuất. Lỗi phần cứng trong một số trường hợp, ảnh hưởng đến thiết lập cơ sở dữ liệu chính - bản sao của chúng tôi (ví dụ: giọt đi vào "trạng thái di chuyển trực tiếp sang máy phần cứng khác" mà không cần thông báo, có nghĩa là thời gian ngừng hoạt động từ 1-2 giờ cho giọt đó.) Các vấn đề mạng không giải thích được với độ trễ giữa các máy của chúng tôi mà nhóm hỗ trợ của DigitalOcean không bao giờ giải quyết được (điều này rất quan trọng đối với độ trễ đọc bản sao Postgres của chúng tôi, các phiên bản Redis và HA nói chung). Khu vực AMS2 Ngừng sử dụng Khu vực DigitalOcean của chúng tôi (AMS2) đã được thông báo là “sẽ sớm ngừng hoạt động”, nghĩa là hỗ trợ có giới hạn. Chúng tôi không thể đảm bảo các tài nguyên bổ sung theo yêu cầu và việc thực hiện các tác vụ đơn giản thường đồng nghĩa với việc lập kế hoạch dài và lãng phí tài nguyên. Những việc đơn giản như nâng cấp phiên bản Postgres và cung cấp một máy mới để thực hiện một tác vụ đã trở nên không thể thực hiện được. Lựa chọn phần cứng hạn chế Ở trong không gian phân tích đăng ký có nghĩa là các hoạt động sử dụng nhiều dữ liệu, khối lượng lớn và khả năng thường mở rộng quy mô tương ứng. Máy móc hiện đại với nhiều tài nguyên phần cứng phong phú hơn chỉ có ở các khu vực khác. Sự suy giảm hiệu suất mạng là một điều thường xuyên xảy ra và chúng tôi sớm nhận ra rằng di chuyển sang một khu vực khác là lựa chọn tốt nhất của chúng tôi. Thiếu các tính năng đám mây hiện đại và dịch vụ được quản lý Khối lượng công việc vận hành để duy trì cơ sở hạ tầng của chúng tôi theo kịp tốc độ tăng trưởng (đồng thời giải quyết nợ công nghệ) tăng lên. Chúng tôi đã phải xem xét kỹ thiết lập của mình và hiểu liệu chuyển sang một khu vực DigitalOcean khác hay một nhà cung cấp đám mây mới là lựa chọn tốt nhất. Chúng ta nên ở lại hay nên đi? Chúng tôi bắt đầu xem xét những lợi ích của việc ở lại với DigitalOcean và chỉ cần chuyển đến một khu vực mới - một lựa chọn nhàn nhã hơn, nhanh hơn, rẻ hơn và ít đau đớn hơn. Nhưng đồng thời, chúng tôi coi động thái này như một cơ hội để hiện đại hóa các phần trong ngăn xếp của chúng tôi nhằm phục vụ sự tăng trưởng người dùng dự kiến và tốc độ tăng tiến độ. Vào cuối quá trình đánh giá của mình, chúng tôi nhận ra rằng sẽ khó đạt được các yêu cầu cụ thể bắt buộc phải có bằng cách ở lại và chỉ đơn giản là chuyển đổi khu vực. Những điều quan trọng nhất là: Tính linh hoạt trong các tài nguyên tính toán tự động mở rộng quy mô. Cơ sở dữ liệu được quản lý. Cung cấp tài nguyên dựa trên việc sử dụng tạm thời. Độ trễ (er) thấp. Khả năng tương tác của dịch vụ. Cơ sở hạ tầng dựa trên vùng chứa với sự điều phối của Kubernetes. Danh sách các yêu cầu này cùng với những thách thức được liệt kê trong phần trước đã nghiêng về quy mô có lợi cho việc chuyển đổi các nhà cung cấp. Tại sao lại sử dụng AWS? Chọn một nhà cung cấp đám mây mới để cung cấp năng lượng cho cơ sở hạ tầng ChartMogul là một hành trình dài. Chúng tôi đã nghiên cứu thị trường và phát hiện ra nhiều điểm cân bằng và lợi thế mà một nhà cung cấp mới có thể mang lại. Các tùy chọn của chúng tôi là Dịch vụ Web Amazon (AWS), Google Cloud (GCP) và Azure. Cuối cùng, chúng tôi quyết định sử dụng AWS. Chúng tôi liệt kê một số lý do chính dưới đây. Chuyên môn của nhóm Chúng tôi đã sử dụng một số dịch vụ AWS trong quá trình sản xuất (ví dụ: S3 để lưu trữ các bản sao lưu Postgres gia tăng). Quan trọng hơn, một số kỹ sư của chúng tôi đã có kinh nghiệm chuyên môn trước khi sử dụng nhiều dịch vụ AWS khác nhau trong các hệ thống sản xuất. Khả năng mở rộng Chúng tôi có thể tăng hoặc giảm các phiên bản AWS chỉ bằng một nút nhấn. Chúng tôi có thể cung cấp ngay lập tức các tài nguyên như cơ sở dữ liệu RDS và tạm thời tính toán các tài nguyên. Chúng ta có thể lặp lại các thí nghiệm và chứng minh khái niệm một cách nhanh chóng. Tính linh hoạt và khả năng mở rộng của các nhóm nút Kubernetes được hỗ trợ bởi tính năng tự động mở rộng EC2 rất khó bị đánh bại. Tuân thủ và Bảo mật Dữ liệu Bảo mật dữ liệu luôn được quan tâm hàng đầu. Trong những năm qua, khả năng bảo mật của AWS đã phát triển đáng kể. Số lượng dịch vụ mới AWS được phát triển xung quanh bảo mật dữ liệu đáp ứng hầu hết các nhu cầu của chúng tôi trong không gian vùng chứa / Kubernetes. Họ chơi tốt với các dịch vụ được thiết lập tốt như cách ly VPC riêng, kiểm soát chi tiết các chính sách và vai trò IAM. Về mặt tuân thủ, chúng tôi có kế hoạch trở thành được chứng nhận SOC II càng sớm càng tốt và chúng tôi nhận thấy AWS là một lợi thế có thể giúp theo dõi nhanh hành trình đó. các chương trình tuân thủ Dịch vụ được quản lý Postgres là trọng tâm của những gì chúng tôi làm tại ChartMogul và chúng tôi thường dành nhiều thời gian tích cực quản lý nhóm máy cơ sở dữ liệu của mình để hỗ trợ sự phát triển của chúng tôi. Tính khả dụng và độ tin cậy cao của cơ sở dữ liệu đang trở thành mối quan tâm ngày càng tăng, vì vậy chúng tôi quyết định đánh giá nhiều đề nghị từ các nhà cung cấp đám mây lớn với PostgreSQL được quản lý. AWS RDS rõ ràng là người chiến thắng. Kubernetes được quản lý là một yếu tố chính khác cần xem xét và điều này đối đầu trực tiếp với Google Cloud (GCP). Kubernetes do Google quản lý (GKE) cảm thấy tốt hơn so với những gì AWS có vào thời điểm đó, nhưng so sánh RDS với CloudSQL không phải là tính năng gần gũi. Tuy nhiên, ngày nay có vẻ như AWS đang bắt kịp với EKS; Chúng tôi được hưởng lợi từ các tính năng RDS tuyệt vời như tính linh hoạt của ảnh chụp nhanh, độ bền sao lưu (với SLA), đọc bản sao cho Postgres, nâng cấp không đau, IOPS chuyên dụng, số liệu Cloudwatch, Thông tin chi tiết về hiệu suất và danh sách tiếp tục. Số lượng điên cuồng của các dịch vụ AWS Tại thời điểm viết bài, AWS cung cấp hơn 200 dịch vụ. Hầu hết chúng cung cấp cho bạn khả năng truy cập tức thì vào các dịch vụ được quản lý từ rất nhiều lĩnh vực như máy tính, cơ sở dữ liệu, phân tích dữ liệu, kho dữ liệu, không cần máy chủ và lưu trữ. Các nhóm kỹ sư của chúng tôi hiện có thể tận dụng các tích hợp hàng đầu để giải quyết các vấn đề cốt lõi một cách nhanh chóng và ưu tiên mua so với xây dựng ở nơi phù hợp. Phục hồi sau thảm họa Đám mây AWS là một phần thiết yếu trong kế hoạch Khôi phục sau thảm họa của chúng tôi. Đó là bởi vì các phiên bản dễ dàng xoay vòng, chúng tôi có thể quảng bá bản sao đọc RDS thành bản sao chính chỉ bằng một lần nhấp vào nút, ảnh chụp nhanh thật dễ dàng, chúng tôi có thể lưu trữ ở nhiều khu vực và chúng tôi có tích hợp hàng đầu với công cụ IaC của chúng tôi sự lựa chọn. Tín dụng AWS Chúng tôi đã nhận được khoản tín dụng trị giá $ 100k thông qua chương trình AWS Startup. Chúng tôi đã có thể lập kế hoạch, kiểm tra và hoàn thành quá trình di chuyển của mình mà không cần chi phí đáng kể. Di chuyển sang AWS Quá trình di chuyển của chúng tôi từ DigitalOcean sang AWS là một hành trình kéo dài mười tháng. Toàn bộ nỗ lực được hỗ trợ bởi các tình nguyện viên từ tất cả các nhóm kỹ thuật của chúng tôi và được thúc đẩy bởi một kỹ sư DevOps, một kỹ sư phụ trợ và trưởng bộ phận kỹ thuật của chúng tôi. Một số điều liên quan đến thử và sai. Chúng tôi đã thử nhiều cách: Di chuyển dữ liệu từ Postgres sang RDS với thời gian chết gần như bằng không. Chuyển ứng dụng và dịch vụ của chúng tôi từ kiến trúc dựa trên máy ảo sang cấu trúc được chứa trong Kubernetes. Thay đổi cơ bản cách chúng tôi triển khai. Một kế hoạch hoàn hảo đã được đặt ra và mọi thứ có vẻ tốt trên giấy, nhưng chúng tôi đã học được một cách khó khăn rằng mọi thứ không phải lúc nào cũng đi đúng kế hoạch. Đôi khi, mục tiêu di chuyển thời gian chết gần như bằng 0 của chúng tôi gặp rủi ro nghiêm trọng và chúng tôi đã quay trở lại bảng vẽ. Sự kiên trì, động lực và nỗ lực tuyệt vời của nhóm đã giúp chúng tôi vượt qua những thách thức mà chúng tôi phải đối mặt. Lập kế hoạch cẩn thận cũng làm điều kỳ diệu; Với năng lực của mình, chúng tôi đã sớm xác định rằng chia nhỏ quá trình di chuyển thực tế thành ba giai đoạn (hoặc ngày) sẽ hoạt động tốt nhất. Tuần trước D-Day Bắt đầu sao chép Postgres từ phiên bản DigitalOcean sang RDS. Xem lại cơ sở hạ tầng sản xuất trong tương lai AWS của chúng tôi. Cấu hình bí mật (AWS Parameter Store). Đảm bảo các đường ống CI / CD đã sẵn sàng triển khai tới các cụm Kubernetes mới của chúng tôi. Ngày trước D-Day Chuẩn bị cơ sở hạ tầng trình ghi webhook tạm thời AWS của chúng tôi (việc mất các sự kiện trong quá trình di chuyển của chúng tôi không phải là một tùy chọn). Di chuyển trước một số dữ liệu (ví dụ: DigitalOcean Spaces sang S3). Cập nhật tất cả các bí mật của Cửa hàng tham số thành các giá trị sản xuất. Chuẩn bị các thay đổi DNS. Đặt tất cả các triển khai Kubernetes thành không nhóm để ngăn các dịch vụ truy cập vào dữ liệu sản xuất trong quá trình di chuyển. D-day: Nhấp vào công tắc Chuyển hướng tất cả webhook tới trình ghi tạm thời AWS. Dừng tất cả các dịch vụ trên DigitalOcean. Chờ nhân rộng Postgres để cập nhật các bản cập nhật mới nhất. So sánh dữ liệu DigitalOcean và RDS Postgres (để đảm bảo bắt kịp tính toàn vẹn và nhân rộng). Bỏ đăng ký từ RDS xuống Postgres đang chạy trong DigitalOcean. Tạo bản sao đọc RDS. Cập nhật bí mật về Cửa hàng tham số của chúng tôi với các điểm cuối và bí mật RDS mới. Triển khai tới Kubernetes và khởi động lại PgBouncer để tải các cấu hình mới. Chuyển bản ghi DNS cho sang AWS. app.chartmogul.com Tại thời điểm này, chúng tôi đang điều hành khối lượng công việc sản xuất của mình trên cơ sở hạ tầng mới sáng bóng! Chúng tôi đã hoàn thành toàn bộ công việc trong 10 giờ (chúng tôi ước tính ban đầu là 8 giờ - không quá tệ). Những thách thức với AWS Cuộc đấu tranh lớn nhất là với dịch vụ DMS (dịch vụ được AWS quản lý để chuyển cơ sở dữ liệu sang RDS). Nó không dễ sử dụng như quảng cáo. Trong trường hợp của chúng tôi với Postgres, nó không hữu ích. Cuối cùng, chúng tôi đã phát triển một cách tùy chỉnh để di chuyển dữ liệu vào AWS. Chúng tôi cũng nhận ra rằng việc di chuyển cơ sở dữ liệu không có thời gian chết sang AWS với hỗ trợ webhook là rất phức tạp. Chúng tôi đã phát triển một cách tiếp cận tùy chỉnh để hỗ trợ thiết lập này. Thông tin thêm về các phương pháp tiếp cận tùy chỉnh này trong các bài viết trong tương lai. Các bài viết trong tương lai trong loạt bài Hãy chú ý đến các bài viết trong tương lai ghi lại hành trình di chuyển của chúng tôi từ DigitalOcean sang AWS. Chúng tôi sẽ đề cập đến các chủ đề như: Tại sao chúng tôi chọn Kubernetes để cung cấp năng lượng cho ChartMogul. Cách chúng tôi di chuyển PostgreSQL sang RDS. Cách chúng tôi di chuyển ứng dụng Rails sang Kubernetes. Cách chúng tôi thiết lập đường hầm IPSEC tới AWS VPC.
