Ghi chú. bản dịch.: vào đầu tháng 8, Red Hat đã công khai nói về việc giải quyết các vấn đề về khả năng tiếp cận mà người dùng dịch vụ của họ đã gặp phải trong những tháng trước (nó dựa trên cơ sở đăng ký hình ảnh vùng chứa mà công ty đã nhận được cùng với việc mua CoreOS). Bất kể bạn quan tâm đến dịch vụ này như thế nào, con đường mà các kỹ sư SRE của công ty đã thực hiện để chẩn đoán và loại bỏ nguyên nhân gây ra vụ tai nạn đều mang tính hướng dẫn.
Vào sáng sớm ngày 19 tháng XNUMX (Giờ ban ngày miền Đông, EDT), dịch vụ quay.io đã gặp sự cố. Vụ tai nạn ảnh hưởng đến cả người tiêu dùng quay.io và các dự án Nguồn mở sử dụng quay.io làm nền tảng để xây dựng và phân phối phần mềm. Red Hat coi trọng sự tin tưởng của cả hai.
Một nhóm kỹ sư của SRE ngay lập tức vào cuộc và cố gắng ổn định tuyến Quay càng sớm càng tốt. Tuy nhiên, trong khi họ làm điều này, khách hàng mất khả năng đẩy hình ảnh mới và chỉ thỉnh thoảng họ mới có thể kéo những hình ảnh hiện có. Vì một số lý do không xác định, cơ sở dữ liệu quay.io đã bị chặn sau khi mở rộng dịch vụ lên hết công suất.
«Điều gì đã thay đổi?" - đây là câu hỏi đầu tiên thường được hỏi trong những trường hợp như vậy. Chúng tôi nhận thấy rằng ngay trước khi xảy ra sự cố, cụm chuyên dụng OpenShift (chạy quay.io) đã bắt đầu cập nhật lên phiên bản 4.3.19. Vì quay.io chạy trên Red Hat OpenShift Chuyên dụng (OSD) nên các bản cập nhật thường xuyên diễn ra thường xuyên và không bao giờ gây ra sự cố. Hơn nữa, trong sáu tháng qua, chúng tôi đã nâng cấp cụm Quay nhiều lần mà không bị gián đoạn dịch vụ.
Trong khi chúng tôi đang cố gắng khôi phục dịch vụ, các kỹ sư khác đã bắt đầu chuẩn bị một cụm OSD mới với phiên bản phần mềm trước đó để nếu có chuyện gì xảy ra, họ có thể triển khai mọi thứ trên đó.
Phân tích nguyên nhân gốc rễ
Triệu chứng chính của sự cố là sự xuất hiện hàng chục nghìn kết nối cơ sở dữ liệu, khiến phiên bản MySQL không thể hoạt động được. Điều này gây khó khăn cho việc chẩn đoán vấn đề. Chúng tôi đã đặt giới hạn về số lượng kết nối tối đa từ khách hàng để giúp nhóm SRE đánh giá vấn đề. Chúng tôi không nhận thấy bất kỳ lưu lượng truy cập bất thường nào vào cơ sở dữ liệu: trên thực tế, hầu hết các yêu cầu đều được đọc và chỉ một số ít được ghi.
Chúng tôi cũng đã cố gắng xác định một mẫu trong lưu lượng cơ sở dữ liệu có thể gây ra hiện tượng tuyết lở này. Tuy nhiên, chúng tôi không thể tìm thấy bất kỳ mẫu nào trong nhật ký. Trong khi chờ đợi cụm mới với OSD 4.3.18 sẵn sàng, chúng tôi tiếp tục thử khởi chạy các nhóm quay.io. Mỗi khi cụm đạt hết công suất, cơ sở dữ liệu sẽ bị đóng băng. Điều này có nghĩa là cần phải khởi động lại phiên bản RDS ngoài tất cả các nhóm quay.io.
Đến tối, chúng tôi đã ổn định dịch vụ ở chế độ chỉ đọc và vô hiệu hóa nhiều chức năng không cần thiết nhất có thể (ví dụ: thu gom rác vùng không gian tên) để giảm tải cho cơ sở dữ liệu. Đóng băng đã dừng lại nhưng lý do không bao giờ được tìm thấy. Cụm OSD mới đã sẵn sàng và chúng tôi đã di chuyển dịch vụ, kết nối lưu lượng truy cập và tiếp tục giám sát.
Quay.io hoạt động ổn định trên cụm OSD mới, vì vậy chúng tôi đã quay lại nhật ký cơ sở dữ liệu nhưng không thể tìm thấy mối tương quan giải thích cho sự tắc nghẽn. Các kỹ sư của OpenShift đã làm việc với chúng tôi để tìm hiểu xem những thay đổi trong Red Hat OpenShift 4.3.19 có thể gây ra sự cố với Quay hay không. Tuy nhiên, không có gì được tìm thấy và Không thể tái tạo vấn đề trong điều kiện phòng thí nghiệm.
Thất bại thứ hai
Vào ngày 28 tháng XNUMX, ngay trước buổi trưa EDT, quay.io lại gặp sự cố với cùng một triệu chứng: cơ sở dữ liệu bị chặn. Và một lần nữa chúng tôi lại dồn hết nỗ lực vào cuộc điều tra. Trước hết, cần phải khôi phục dịch vụ. Tuy nhiên lần này khởi động lại RDS và khởi động lại nhóm quay.io không làm gì cả: một trận tuyết lở kết nối khác đã tràn ngập căn cứ. Nhưng tại sao?
Quay được viết bằng Python và mỗi nhóm hoạt động như một thùng chứa nguyên khối duy nhất. Thời gian chạy container chạy nhiều tác vụ song song cùng một lúc. Chúng tôi sử dụng thư viện gevent dưới gunicorn để xử lý các yêu cầu web. Khi có yêu cầu đến Quay (thông qua API của chúng tôi hoặc qua API của Docker), yêu cầu đó sẽ được chỉ định một nhân viên gevent. Thông thường, nhân viên này sẽ liên hệ với cơ sở dữ liệu. Sau lần thất bại đầu tiên, chúng tôi phát hiện ra rằng nhân viên gevent đang kết nối với cơ sở dữ liệu bằng cài đặt mặc định.
Với số lượng đáng kể các nhóm Quay và hàng nghìn yêu cầu gửi đến mỗi giây, về mặt lý thuyết, một số lượng lớn kết nối cơ sở dữ liệu có thể áp đảo phiên bản MySQL. Nhờ theo dõi, được biết Quay xử lý trung bình 5 nghìn yêu cầu mỗi giây. Số lượng kết nối đến cơ sở dữ liệu là gần như nhau. 5 nghìn kết nối nằm trong khả năng của phiên bản RDS của chúng tôi (không thể nói là khoảng hàng chục nghìn). Vì lý do nào đó đã có sự tăng đột biến bất ngờ về số lượng kết nốituy nhiên, chúng tôi không nhận thấy bất kỳ mối tương quan nào với các yêu cầu gửi đến.
Lần này chúng tôi quyết tâm tìm ra và loại bỏ nguồn gốc của vấn đề chứ không giới hạn việc khởi động lại. Đến cơ sở mã Quay những thay đổi đã được thực hiện để giới hạn số lượng kết nối đến cơ sở dữ liệu cho mỗi công nhân gevent. Con số này đã trở thành một tham số trong cấu hình: có thể thay đổi nó một cách nhanh chóng mà không cần tạo hình ảnh vùng chứa mới. Để tìm hiểu xem có thể xử lý thực tế bao nhiêu kết nối, chúng tôi đã chạy một số thử nghiệm trong môi trường chạy thử, đặt các giá trị khác nhau để xem điều này sẽ ảnh hưởng như thế nào đến các tình huống thử nghiệm tải. Kết quả là người ta đã phát hiện ra rằng Quay bắt đầu đưa ra lỗi 502 khi số lượng kết nối vượt quá 10 nghìn.
Chúng tôi ngay lập tức triển khai phiên bản mới này vào sản xuất và bắt đầu theo dõi lịch trình kết nối cơ sở dữ liệu. Trước đây, căn cứ bị khóa sau khoảng 20 phút. Sau 30 phút không gặp rắc rối, chúng tôi có hy vọng và một giờ sau chúng tôi có sự tự tin. Chúng tôi đã khôi phục lưu lượng truy cập vào trang web và bắt đầu phân tích sau khi khám nghiệm tử thi.
Đã tìm cách vượt qua vấn đề dẫn đến chặn, chúng tôi chưa tìm ra lý do thực sự của nó. Người ta xác nhận rằng nó không liên quan đến bất kỳ thay đổi nào trong OpenShift 4.3.19, vì điều tương tự cũng xảy ra trên phiên bản 4.3.18, phiên bản trước đây đã hoạt động với Quay mà không gặp vấn đề gì.
Rõ ràng có thứ gì đó khác đang ẩn nấp trong đám người đó.
Nghiên cứu chi tiết
Quay.io đã sử dụng cài đặt mặc định để kết nối với cơ sở dữ liệu trong sáu năm mà không gặp bất kỳ sự cố nào. Những gì đã thay đổi? Rõ ràng là trong thời gian qua lưu lượng truy cập trên quay.io đã tăng đều đặn. Trong trường hợp của chúng tôi, có vẻ như đã đạt đến một số giá trị ngưỡng, điều này đóng vai trò là yếu tố kích hoạt cho một loạt các kết nối. Chúng tôi tiếp tục nghiên cứu nhật ký cơ sở dữ liệu sau lần thất bại thứ hai, nhưng không tìm thấy bất kỳ mô hình hoặc mối quan hệ rõ ràng nào.
Trong thời gian chờ đợi, nhóm SRE đang nỗ lực cải thiện khả năng quan sát yêu cầu và tình trạng dịch vụ tổng thể của Quay. Các số liệu và bảng chỉ số mới đã được triển khai, cho thấy khu vực nào của Quay được khách hàng yêu cầu nhiều nhất.
Quay.io hoạt động tốt cho đến ngày 9 tháng XNUMX. Sáng nay (EDT), chúng tôi lại thấy số lượng kết nối cơ sở dữ liệu tăng lên đáng kể. Lần này không có thời gian chết, vì tham số mới đã giới hạn số lượng của chúng và không cho phép chúng vượt quá thông lượng MySQL. Tuy nhiên, trong khoảng nửa giờ, nhiều người dùng nhận thấy quay.io hoạt động chậm. Chúng tôi nhanh chóng thu thập tất cả dữ liệu có thể bằng cách sử dụng các công cụ giám sát bổ sung. Đột nhiên một mô hình xuất hiện.
Ngay trước khi số lượng kết nối tăng đột biến, một số lượng lớn yêu cầu đã được gửi tới API đăng ký ứng dụng. Đăng ký ứng dụng là một tính năng ít được biết đến của quay.io. Nó cho phép bạn lưu trữ những thứ như biểu đồ Helm và vùng chứa với siêu dữ liệu phong phú. Hầu hết người dùng quay.io không hoạt động với tính năng này, nhưng Red Hat OpenShift tích cực sử dụng nó. OperatorHub như một phần của OpenShift lưu trữ tất cả các toán tử trong Sổ đăng ký ứng dụng. Những toán tử này tạo thành nền tảng cho hệ sinh thái khối lượng công việc OpenShift và mô hình vận hành lấy đối tác làm trung tâm (Hoạt động của Ngày 2).
Mỗi cụm OpenShift 4 sử dụng các toán tử từ OperatorHub tích hợp sẵn để xuất bản danh mục các toán tử có sẵn để cài đặt và cung cấp các bản cập nhật cho những toán tử đã được cài đặt. Với sự phổ biến ngày càng tăng của OpenShift 4, số lượng cụm trên nó trên khắp thế giới cũng tăng lên. Mỗi cụm này tải xuống nội dung của nhà điều hành để chạy OperatorHub tích hợp sẵn, sử dụng Sổ đăng ký ứng dụng bên trong quay.io làm phụ trợ. Trong quá trình tìm kiếm nguồn gốc của vấn đề, chúng tôi đã bỏ lỡ một thực tế là khi OpenShift dần trở nên phổ biến, tải trọng trên một trong những chức năng quay.io hiếm khi được sử dụng cũng tăng lên..
Chúng tôi đã thực hiện một số phân tích về lưu lượng yêu cầu của Cơ quan đăng ký ứng dụng và xem xét mã đăng ký. Ngay lập tức, những thiếu sót đã bộc lộ, do đó các truy vấn tới cơ sở dữ liệu không được hình thành một cách tối ưu. Khi tải thấp, chúng không gây ra rắc rối gì, nhưng khi tải tăng lên, chúng lại trở thành nguồn gốc của vấn đề. Hóa ra, Cơ quan đăng ký ứng dụng có hai điểm cuối có vấn đề không phản hồi tốt khi tăng tải: điểm đầu tiên cung cấp danh sách tất cả các gói trong kho lưu trữ, điểm cuối thứ hai trả về tất cả các đốm màu cho gói.
Loại bỏ nguyên nhân
Trong tuần tiếp theo, chúng tôi đã dành thời gian tối ưu hóa mã của chính Cơ quan đăng ký ứng dụng và môi trường của nó. Rõ ràng các truy vấn SQL không hiệu quả đã được làm lại và các lệnh gọi lệnh không cần thiết đã bị loại bỏ tar (nó được chạy mỗi khi các đốm màu được truy xuất), bộ đệm được thêm vào bất cứ khi nào có thể. Sau đó, chúng tôi đã tiến hành kiểm tra hiệu suất trên diện rộng và so sánh tốc độ của Cơ quan đăng ký ứng dụng trước và sau khi thay đổi.
Các yêu cầu API trước đây mất tới nửa phút giờ được hoàn thành sau một phần nghìn giây. Tuần tiếp theo, chúng tôi đã triển khai các thay đổi trong quá trình sản xuất và kể từ đó quay.io đã hoạt động ổn định. Trong thời gian này, lưu lượng truy cập trên điểm cuối Cơ quan đăng ký ứng dụng đã tăng đột biến nhưng những cải tiến này đã giúp ngăn chặn tình trạng ngừng hoạt động của cơ sở dữ liệu.
Chúng ta đã học được gì?
Rõ ràng là bất kỳ dịch vụ nào cũng cố gắng tránh thời gian ngừng hoạt động. Trong trường hợp của chúng tôi, chúng tôi tin rằng những lần ngừng hoạt động gần đây đã giúp quay.io trở nên tốt hơn. Chúng tôi đã học được một số bài học quan trọng mà chúng tôi muốn chia sẻ:
- Dữ liệu về ai sử dụng dịch vụ của bạn và như thế nào không bao giờ thừa. Bởi vì Quay “vừa hoạt động” nên chúng tôi không bao giờ phải tốn thời gian tối ưu hóa lưu lượng truy cập và quản lý tải. Tất cả điều này đã tạo ra cảm giác an toàn sai lầm rằng dịch vụ có thể mở rộng vô thời hạn.
- Khi dịch vụ ngừng hoạt động, khôi phục và chạy nó là ưu tiên hàng đầu.. Vì Quay tiếp tục gặp sự cố với cơ sở dữ liệu bị khóa trong lần ngừng hoạt động đầu tiên nên các quy trình tiêu chuẩn của chúng tôi không mang lại hiệu quả như mong muốn và chúng tôi không thể khôi phục dịch vụ bằng cách sử dụng chúng. Điều này dẫn đến tình trạng phải dành thời gian để phân tích và thu thập dữ liệu với hy vọng tìm ra nguyên nhân gốc rễ - thay vì tập trung mọi nỗ lực vào việc khôi phục chức năng.
- Đánh giá tác động của từng tính năng dịch vụ. Khách hàng hiếm khi sử dụng Sổ đăng ký ứng dụng nên nhóm của chúng tôi không ưu tiên điều này. Khi một số tính năng của sản phẩm hầu như không được sử dụng, lỗi của chúng hiếm khi xuất hiện và các nhà phát triển sẽ ngừng theo dõi mã. Bạn rất dễ mắc phải quan niệm sai lầm rằng đây là cách nó phải như vậy—cho đến khi đột nhiên chức năng đó trở thành trung tâm của một sự cố lớn.
Cái gì tiếp theo?
Công việc đảm bảo tính ổn định của dịch vụ không bao giờ dừng lại và chúng tôi không ngừng cải thiện nó. Khi lưu lượng truy cập tiếp tục tăng trên quay.io, chúng tôi nhận thấy rằng mình có trách nhiệm làm mọi thứ có thể để đáp lại sự tin tưởng của khách hàng. Vì vậy, chúng tôi hiện đang thực hiện các nhiệm vụ sau:
- Triển khai các bản sao cơ sở dữ liệu chỉ đọc để giúp dịch vụ xử lý lưu lượng thích hợp trong trường hợp xảy ra sự cố với phiên bản RDS chính.
- Cập nhật phiên bản RDS. Bản thân phiên bản hiện tại không phải là vấn đề. Đúng hơn, chúng tôi chỉ muốn loại bỏ dấu vết sai lầm (mà chúng tôi đã theo dõi trong thời gian thất bại); Việc luôn cập nhật phần mềm sẽ loại bỏ một yếu tố khác trong trường hợp ngừng hoạt động trong tương lai.
- Bộ nhớ đệm bổ sung trên toàn bộ cụm. Chúng tôi tiếp tục tìm kiếm những lĩnh vực mà bộ nhớ đệm có thể giảm tải cho cơ sở dữ liệu.
- Thêm tường lửa ứng dụng web (WAF) để xem ai đang kết nối với quay.io và tại sao.
- Bắt đầu với bản phát hành tiếp theo, các cụm OpenShift của Red Hat sẽ từ bỏ Đăng ký ứng dụng để chuyển sang Danh mục nhà điều hành dựa trên hình ảnh vùng chứa có sẵn trên quay.io.
- Giải pháp thay thế lâu dài cho Cơ quan đăng ký ứng dụng có thể là sự hỗ trợ cho các đặc tả cấu phần của Sáng kiến vùng chứa mở (OCI). Nó hiện được triển khai dưới dạng chức năng Quay gốc và sẽ có sẵn cho người dùng khi thông số kỹ thuật được hoàn thiện.
Tất cả những điều trên là một phần trong kế hoạch đầu tư liên tục của Red Hat vào quay.io khi chúng tôi chuyển từ một nhóm nhỏ "kiểu khởi nghiệp" sang nền tảng định hướng SRE trưởng thành. Chúng tôi biết rằng nhiều khách hàng của mình dựa vào quay.io trong công việc hàng ngày của họ (bao gồm cả Red Hat!) và chúng tôi cố gắng minh bạch nhất có thể về những lần ngừng hoạt động gần đây cũng như những nỗ lực không ngừng để cải thiện.
Tái bút từ người dịch
Đọc thêm trên blog của chúng tôi:
- «»;
- «»;
- «'.
Nguồn: www.habr.com