Captain Obvious nói với chúng tôi rằng vào mùa hè, cả hoạt động mua hàng và cường độ thay đổi cơ sở hạ tầng của các dự án web theo truyền thống đều giảm. Đơn giản vì ngay cả chuyên gia CNTT cũng có lúc đi nghỉ. Và cả CTO nữa. Điều đó càng khó khăn hơn đối với những người còn tại vị, nhưng đó không phải là vấn đề bây giờ: có lẽ đó là lý do tại sao mùa hè là khoảng thời gian tốt nhất để từ từ suy nghĩ về kế hoạch đặt chỗ hiện tại và vạch ra kế hoạch cải thiện nó. Và kinh nghiệm của Yegor Andreev từ , điều mà ông ấy đã nói đến tại hội nghị .
Có một số cạm bẫy mà bạn có thể gặp phải khi xây dựng các trang web dự phòng. Và hoàn toàn không thể bị cuốn vào chúng. Và điều hủy hoại chúng ta trong tất cả những điều này, cũng như trong nhiều thứ khác, là chủ nghĩa cầu toàn và... sự lười biếng. Chúng ta đang cố gắng làm mọi thứ, mọi thứ, mọi thứ một cách hoàn hảo, nhưng chúng ta không cần phải làm điều đó một cách hoàn hảo! Bạn chỉ cần làm một số việc nhất định, nhưng hãy thực hiện chúng một cách chính xác, hoàn thành chúng để chúng hoạt động tốt.
Chuyển đổi dự phòng không phải là một trò vui, thú vị; đây là việc cần làm chính xác một việc - giảm thời gian ngừng hoạt động để dịch vụ, công ty ít tổn thất hơn. Và trong tất cả các phương pháp đặt chỗ, tôi khuyên bạn nên suy nghĩ trong bối cảnh sau: tiền ở đâu?
Cái bẫy đầu tiên: khi chúng tôi xây dựng các hệ thống lớn, đáng tin cậy và sử dụng biện pháp dự phòng, chúng tôi sẽ giảm được số vụ tai nạn. Đây là một quan niệm sai lầm khủng khiếp. Khi chúng ta tham gia vào tình trạng dư thừa, chúng ta có khả năng làm tăng số vụ tai nạn. Và nếu chúng ta làm đúng mọi thứ thì chúng ta sẽ cùng nhau giảm thời gian ngừng hoạt động. Sẽ có nhiều tai nạn hơn nhưng chúng sẽ xảy ra với chi phí thấp hơn. Đặt chỗ là gì? - đây là sự phức tạp của hệ thống. Bất kỳ sự phức tạp nào cũng đều tệ: chúng ta có nhiều bánh răng hơn, nhiều bánh răng hơn, nói một cách dễ hiểu hơn, nhiều yếu tố hơn - và do đó, khả năng hỏng hóc cao hơn. Và họ thực sự sẽ phá vỡ. Và họ sẽ phá vỡ thường xuyên hơn. Một ví dụ đơn giản: giả sử chúng ta có một trang web có PHP và MySQL. Và nó cần phải được bảo lưu khẩn cấp.
Shtosh (c) Chúng tôi lấy địa điểm thứ hai, xây dựng một hệ thống giống hệt nhau... Độ phức tạp trở nên lớn gấp đôi - chúng tôi có hai thực thể. Chúng tôi cũng đưa ra một logic nhất định để truyền dữ liệu từ trang này sang trang khác - nghĩa là sao chép dữ liệu, sao chép dữ liệu tĩnh, v.v. Vì vậy, logic sao chép thường rất phức tạp và do đó, tổng độ phức tạp của hệ thống có thể lớn hơn không phải 2 mà là 3, 5, 10 lần.
Cái bẫy thứ hai: khi chúng tôi xây dựng các hệ thống thực sự phức tạp lớn, chúng tôi mơ mộng về những gì chúng tôi muốn đạt được cuối cùng. Thì đấy: chúng tôi muốn có được một hệ thống siêu đáng tin cậy, hoạt động mà không có thời gian ngừng hoạt động, chuyển đổi trong nửa giây (hoặc tốt hơn là ngay lập tức) và chúng tôi bắt đầu biến giấc mơ thành hiện thực. Nhưng cũng có một sắc thái ở đây: thời gian chuyển đổi mong muốn càng ngắn thì logic hệ thống càng trở nên phức tạp. Chúng ta càng phải đưa ra logic này phức tạp thì hệ thống sẽ càng bị hỏng thường xuyên hơn. Và bạn có thể rơi vào một tình huống rất khó chịu: chúng tôi đang cố gắng hết sức để giảm thời gian ngừng hoạt động, nhưng trên thực tế, chúng tôi đang khiến mọi thứ trở nên phức tạp hơn và khi có sự cố xảy ra, thời gian ngừng hoạt động sẽ kéo dài hơn. Ở đây bạn thường bắt gặp mình nghĩ: à... thà không đặt chỗ trước còn hơn. Sẽ tốt hơn nếu nó hoạt động một mình và có thời gian ngừng hoạt động dễ hiểu.
Làm thế nào bạn có thể chống lại điều này? Chúng ta cần ngừng lừa dối bản thân, ngừng tự tâng bốc rằng chúng ta sẽ chế tạo một con tàu vũ trụ ở đây ngay bây giờ, nhưng hãy hiểu đầy đủ rằng dự án có thể nằm trong bao lâu. Và trong thời gian tối đa này, chúng tôi sẽ chọn phương pháp nào chúng tôi sẽ thực sự sử dụng để tăng độ tin cậy cho hệ thống của mình.
Tất nhiên, đã đến lúc dành cho “những câu chuyện từ w”... từ cuộc sống.
Ví dụ số một
Hãy tưởng tượng một trang web danh thiếp của Nhà máy cán ống số 1 ở thành phố N. Nó ghi bằng chữ rất lớn - NHÀ MÁY CÁN ỐNG SỐ 1. Ngay bên dưới là khẩu hiệu: “Ống của chúng tôi là loại ống tròn nhất ở N.” Và bên dưới là số điện thoại và tên của CEO. Chúng tôi hiểu rằng bạn cần phải đặt chỗ trước - đây là một điều rất quan trọng! Hãy bắt đầu tìm hiểu xem nó bao gồm những gì. Html-statics - tức là một vài bức ảnh trong đó trên thực tế, tổng giám đốc đang thảo luận về một loại thỏa thuận tiếp theo nào đó tại bàn trong nhà tắm với đối tác của mình. Chúng tôi bắt đầu nghĩ về thời gian chết. Tôi chợt nghĩ: bạn cần nằm đó trong năm phút, không hơn. Và sau đó câu hỏi được đặt ra: nói chung có bao nhiêu doanh số bán hàng từ trang web này của chúng tôi? Bao nhiêu-bao nhiêu? "Số không" nghĩa là gì? Và điều đó có nghĩa là: bởi vì vị tướng này đã thực hiện cả bốn giao dịch vào năm ngoái tại cùng một bàn, với cùng những người mà họ vào nhà tắm và ngồi cùng bàn. Và chúng tôi hiểu rằng ngay cả khi trang web tồn tại trong một ngày, sẽ không có gì khủng khiếp xảy ra.
Dựa trên thông tin giới thiệu, có một ngày để nâng cao câu chuyện này. Hãy bắt đầu suy nghĩ về một kế hoạch dự phòng. Và chúng tôi chọn sơ đồ dự phòng lý tưởng nhất cho ví dụ này: chúng tôi không sử dụng dự phòng. Toàn bộ vấn đề này có thể được bất kỳ quản trị viên nào nêu ra trong nửa giờ với thời gian nghỉ giải lao. Cài đặt máy chủ web, thêm tệp - thế là xong. Nó sẽ hoạt động. Bạn không cần để mắt tới bất cứ thứ gì, không cần đặc biệt chú ý đến bất cứ thứ gì. Nghĩa là, kết luận từ ví dụ số một khá rõ ràng: các dịch vụ không cần đặt trước thì không cần phải đặt trước.
Ví dụ số hai
Blog của công ty: những người được đào tạo đặc biệt viết tin tức ở đó, chúng tôi đã tham gia vào một cuộc triển lãm như vậy, nhưng chúng tôi đã phát hành một sản phẩm mới khác, v.v. Giả sử đây là PHP tiêu chuẩn với WordPress, một cơ sở dữ liệu nhỏ và một chút tĩnh. Tất nhiên, bạn nên nhớ lại rằng trong mọi trường hợp bạn không nên nằm xuống - "không quá năm phút!" Chỉ vậy thôi. Nhưng hãy suy nghĩ xa hơn. Blog này làm gì? Mọi người đến đó từ Yandex, từ Google dựa trên một số truy vấn một cách tự nhiên. Tuyệt vời. Bán hàng có liên quan gì không? Hiển linh: không thực sự. Lưu lượng truy cập quảng cáo đi đến trang web chính trên một máy khác. Hãy bắt đầu suy nghĩ về một kế hoạch đặt phòng. Nói một cách tích cực, nó cần phải được nâng lên trong vài giờ nữa, và sẽ rất tốt nếu bạn chuẩn bị cho việc này. Sẽ là hợp lý nếu lấy một chiếc máy từ một trung tâm dữ liệu khác, đưa môi trường vào đó, tức là một máy chủ web, PHP, WordPress, MySQL và để nó ở đó. Tại thời điểm chúng tôi hiểu rằng mọi thứ đã hỏng, chúng tôi cần làm hai việc - tung bãi chứa mysql ra 50 mét, nó sẽ bay tới đó trong một phút và tung ra một số hình ảnh nhất định từ bản sao lưu ở đó. Điều này cũng không có ở đó vì Chúa biết bao lâu. Vì vậy, trong nửa giờ, toàn bộ sự việc sẽ tăng lên. Không sao chép, hoặc Chúa tha thứ cho tôi, chuyển đổi dự phòng tự động. Kết luận: những gì chúng tôi có thể nhanh chóng triển khai từ bản sao lưu thì không cần phải sao lưu.
Ví dụ số ba, phức tạp hơn
Cửa hàng trực tuyến. PhP với trái tim rộng mở được tinh chỉnh một chút, mysql với nền tảng vững chắc. Khá nhiều tĩnh (xét cho cùng thì cửa hàng trực tuyến có hình ảnh HD đẹp mắt và tất cả những thứ đó), Redis cho phiên và Elaticsearch cho tìm kiếm. Chúng tôi bắt đầu nghĩ về thời gian chết. Và ở đây, tất nhiên, rõ ràng là một cửa hàng trực tuyến không thể nằm yên một ngày mà không đau đớn. Rốt cuộc, nó càng nói dối lâu thì chúng ta càng mất nhiều tiền. Nó đáng để tăng tốc. Bao nhiêu? Tôi nghĩ nếu chúng ta nằm một tiếng thì sẽ không có ai phát điên. Đúng, chúng ta sẽ mất đi thứ gì đó, nhưng nếu chúng ta bắt đầu làm việc chăm chỉ, mọi chuyện sẽ chỉ trở nên tồi tệ hơn. Chúng tôi xác định sơ đồ thời gian ngừng hoạt động được phép mỗi giờ.
Làm thế nào tất cả điều này có thể được bảo lưu? Dù thế nào đi nữa bạn cũng cần một chiếc ô tô: một giờ là khá ít. Mysql: ở đây chúng ta đã cần sao chép, sao chép trực tiếp, vì trong một giờ rất có thể 100 GB sẽ không được thêm vào kết xuất. Số liệu thống kê, hình ảnh: một lần nữa, trong một giờ, 500 GB có thể không có thời gian để bổ sung. Vì vậy, tốt hơn hết bạn nên sao chép hình ảnh ngay lập tức. Redis: đây là lúc mọi thứ trở nên thú vị. Trong Redis, các phiên được lưu trữ - chúng ta không thể lấy nó và chôn nó đi. Bởi vì điều này sẽ không tốt lắm: tất cả người dùng sẽ bị đăng xuất, giỏ của họ sẽ trống rỗng, v.v. Mọi người sẽ buộc phải nhập lại tên người dùng và mật khẩu của mình, nhiều người có thể bỏ dở và không hoàn tất việc mua hàng. Một lần nữa, chuyển đổi sẽ giảm. Mặt khác, Redis được cập nhật trực tiếp và người dùng đăng nhập lần cuối có thể cũng không cần thiết. Và một giải pháp thỏa hiệp tốt là sử dụng Redis và khôi phục nó từ bản sao lưu từ ngày hôm qua hoặc nếu bạn thực hiện việc đó mỗi giờ thì từ một giờ trước. May mắn thay, khôi phục nó từ bản sao lưu có nghĩa là sao chép một tệp. Và câu chuyện thú vị nhất là Elaticsearch. Ai đã từng chọn bản sao MySQL? Ai đã từng chọn bản sao Elaticsearch? Và sau đó nó hoạt động bình thường đối với ai? Ý tôi là chúng ta thấy một thực thể nhất định trong hệ thống của mình. Nó có vẻ hữu ích - nhưng nó phức tạp.
Phức tạp ở chỗ các kỹ sư đồng nghiệp của chúng tôi không có kinh nghiệm làm việc với nó. Hoặc có một trải nghiệm tiêu cực. Hoặc chúng tôi hiểu rằng đây vẫn là một công nghệ khá mới với nhiều sắc thái hoặc sự thô sơ. Chúng tôi nghĩ... Mẹ kiếp, đàn hồi cũng tốt, khôi phục từ bản sao lưu cũng lâu, phải làm sao? Chúng tôi hiểu rằng đàn hồi trong trường hợp của chúng tôi được sử dụng để tìm kiếm. Cửa hàng trực tuyến của chúng tôi bán hàng như thế nào? Chúng tôi đến gặp các nhà tiếp thị và hỏi mọi người đến từ đâu. Họ trả lời: “90% từ Yandex Market đến trực tiếp với thẻ sản phẩm.” Và họ mua nó hoặc không. Vì vậy, việc tìm kiếm là cần thiết bởi 10% người dùng. Và việc duy trì sự sao chép linh hoạt, đặc biệt là giữa các trung tâm dữ liệu khác nhau ở các vùng khác nhau, thực sự có rất nhiều sắc thái. Lối ra nào? Chúng tôi lấy đàn hồi từ một trang web dành riêng và không làm gì với nó. Nếu vấn đề kéo dài, có thể một ngày nào đó chúng tôi sẽ nêu ra, nhưng điều này chưa chắc chắn. Trên thực tế, kết luận là như nhau, cộng hoặc trừ: một lần nữa, chúng tôi không đặt trước những dịch vụ không ảnh hưởng đến tiền bạc. Để giữ cho sơ đồ đơn giản hơn.
Ví dụ số XNUMX, thậm chí còn khó hơn
Tích hợp: bán hoa, gọi taxi, bán hàng nói chung là gì cũng được. Một điều nghiêm túc hoạt động 24/7 cho một số lượng lớn người dùng. Với một ngăn xếp đầy thú vị, nơi có những cơ sở, giải pháp thú vị, tải trọng cao và quan trọng nhất là nằm lâu hơn 5 phút sẽ rất đau. Không chỉ và không quá nhiều vì mọi người sẽ không mua, mà vì mọi người sẽ thấy rằng thứ này không hiệu quả, họ sẽ khó chịu và có thể không quay lại nữa.
ĐƯỢC RỒI. Năm phút. Chúng ta sẽ làm gì về điều này? Trong trường hợp này, chúng tôi, giống như người lớn, sử dụng tất cả tiền để xây dựng một trang web dự phòng thực sự, với bản sao của mọi thứ và thậm chí có thể tự động hóa việc chuyển sang trang web này nhiều nhất có thể. Và ngoài ra, bạn cần nhớ làm một điều quan trọng: thực tế là viết quy định chuyển đổi. Các quy định, ngay cả khi bạn tự động hóa mọi thứ, có thể rất đơn giản. Từ loạt bài “chạy tập lệnh ansible như vậy”, “nhấp vào hộp kiểm như vậy và như vậy trong tuyến đường 53”, v.v. - nhưng đây phải là một loại danh sách hành động chính xác nào đó.
Và mọi thứ có vẻ rõ ràng. Chuyển đổi bản sao là một nhiệm vụ tầm thường, nếu không nó sẽ tự chuyển đổi. Viết lại tên miền trong DNS là từ cùng một chuỗi. Vấn đề là khi một dự án như vậy thất bại, sự hoảng loạn bắt đầu và ngay cả những quản trị viên có râu, mạnh nhất cũng có thể dễ bị ảnh hưởng. Nếu không có hướng dẫn rõ ràng “mở thiết bị đầu cuối, đến đây, địa chỉ máy chủ của chúng tôi vẫn như thế này”, rất khó để đáp ứng thời hạn 5 phút được phân bổ để hồi sức. Ngoài ra, khi chúng ta sử dụng các quy định này, có thể dễ dàng ghi lại một số thay đổi về cơ sở hạ tầng chẳng hạn và thay đổi các quy định cho phù hợp.
Chà, nếu hệ thống đặt chỗ rất phức tạp và tại một thời điểm nào đó chúng tôi đã mắc lỗi, thì chúng tôi có thể phá hủy trang web dự phòng của mình, đồng thời biến dữ liệu thành một quả bí ngô trên cả hai trang web - điều này sẽ hoàn toàn đáng buồn.
Ví dụ số năm, hoàn toàn khó tính
Một dịch vụ quốc tế với hàng trăm triệu người dùng trên toàn thế giới. Có tất cả các múi giờ, tải cao ở tốc độ tối đa, bạn không thể nằm được. Một phút - và nó sẽ rất buồn. Phải làm gì? Dự trữ, một lần nữa, theo chương trình đầy đủ. Chúng tôi đã làm mọi thứ tôi đã nói trong ví dụ trước và hơn thế nữa. Một thế giới lý tưởng và cơ sở hạ tầng của chúng tôi tuân theo tất cả các khái niệm của các nhà phát triển IaaC. Tức là mọi thứ đều có trong git và bạn chỉ cần nhấn nút.
Cái gì còn thiếu? Một - bài tập. Không thể không có họ. Có vẻ như mọi thứ đều hoàn hảo với chúng tôi, nhìn chung chúng tôi đều kiểm soát được mọi thứ. Chúng tôi nhấn nút, mọi thứ sẽ xảy ra. Ngay cả khi điều này là như vậy - và chúng tôi hiểu rằng điều đó không xảy ra theo cách này - hệ thống của chúng tôi vẫn tương tác với một số hệ thống khác. Ví dụ: đây là dns từ tuyến 53, bộ lưu trữ s3, tích hợp với một số api. Chúng ta sẽ không thể thấy trước mọi thứ trong thí nghiệm suy đoán này. Và cho đến khi chúng ta thực sự kéo công tắc, chúng ta sẽ không biết liệu nó có hoạt động hay không.
Đó có lẽ là tất cả. Đừng lười biếng hoặc làm quá sức. Và có thể thời gian hoạt động sẽ ở bên bạn!
Nguồn: www.habr.com