Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu

Những đám mây giống như một chiếc hộp ma thuật - bạn hỏi bạn cần gì và tài nguyên sẽ xuất hiện bất ngờ. Máy ảo, cơ sở dữ liệu, mạng - tất cả những thứ này chỉ thuộc về bạn. Có những người thuê đám mây khác, nhưng trong Vũ trụ của bạn, bạn là người cai trị duy nhất. Bạn chắc chắn rằng bạn sẽ luôn nhận được các tài nguyên cần thiết, bạn không tính đến bất kỳ ai và bạn độc lập xác định mạng sẽ như thế nào. Phép thuật này hoạt động như thế nào để khiến đám mây phân bổ tài nguyên một cách linh hoạt và cách ly hoàn toàn những người thuê với nhau?

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu

Đám mây AWS là một hệ thống cực kỳ phức tạp đã được phát triển dần dần kể từ năm 2006. Một phần của sự phát triển này đã diễn ra Vasily Pantyukhin - Kiến trúc sư dịch vụ web của Amazon. Với tư cách là một kiến ​​trúc sư, anh ấy có được cái nhìn sâu sắc không chỉ về kết quả cuối cùng mà còn về những thách thức mà AWS phải vượt qua. Càng hiểu rõ cách thức hoạt động của hệ thống thì độ tin cậy càng lớn. Vì vậy, Vasily sẽ chia sẻ bí mật của dịch vụ đám mây AWS. Dưới đây là thiết kế của máy chủ AWS vật lý, khả năng mở rộng cơ sở dữ liệu linh hoạt, cơ sở dữ liệu Amazon tùy chỉnh và các phương pháp để tăng hiệu suất của máy ảo đồng thời giảm giá của chúng. Kiến thức về các phương pháp kiến ​​trúc của Amazon sẽ giúp bạn sử dụng dịch vụ AWS hiệu quả hơn và có thể mang đến cho bạn những ý tưởng mới để xây dựng giải pháp của riêng bạn.

Về diễn giả: Vasily Pantyukhin (Hen) bắt đầu với vai trò quản trị viên Unix tại các công ty .ru, làm việc trên phần cứng lớn của Sun Microsystem trong 6 năm và thuyết giảng về thế giới lấy dữ liệu làm trung tâm tại EMC trong 11 năm. Nó tự nhiên phát triển thành đám mây riêng và năm 2017 chuyển sang đám mây công cộng. Hiện anh cung cấp lời khuyên kỹ thuật để giúp tồn tại và phát triển trên đám mây AWS.

Tuyên bố miễn trừ trách nhiệm: mọi thứ bên dưới là ý kiến ​​​​cá nhân của Vasily và có thể không trùng với quan điểm của Amazon Web Services. Quay video Báo cáo làm cơ sở cho bài viết này có sẵn trên kênh YouTube của chúng tôi.

Tại sao tôi lại nói về thiết bị Amazon?

Chiếc xe đầu tiên của tôi có hộp số tay. Thật tuyệt vời vì cảm giác tôi có thể lái chiếc xe và có toàn quyền kiểm soát nó. Tôi cũng thích rằng ít nhất tôi đã hiểu được nguyên lý hoạt động của nó một cách đại khái. Đương nhiên, tôi tưởng tượng cấu trúc của chiếc hộp khá thô sơ - giống như hộp số trên xe đạp.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu

Mọi thứ đều tuyệt vời, ngoại trừ một điều - bị kẹt xe. Có vẻ như bạn đang ngồi không làm gì cả mà liên tục sang số, nhấn côn, ga, phanh - điều đó thực sự khiến bạn mệt mỏi. Vấn đề ùn tắc giao thông đã được giải quyết phần nào khi gia đình có được chiếc ô tô số tự động. Trong khi lái xe, tôi có thời gian để suy nghĩ điều gì đó và nghe sách nói.

Một bí ẩn khác xuất hiện trong cuộc đời tôi, bởi vì tôi hoàn toàn không hiểu cách thức hoạt động của chiếc xe của mình. Một chiếc ô tô hiện đại là một thiết bị phức tạp. Chiếc xe thích ứng đồng thời với hàng chục thông số khác nhau: nhấn ga, phanh, phong cách lái, chất lượng đường. Tôi không hiểu nó hoạt động như thế nào nữa.

Khi tôi bắt đầu làm việc trên đám mây Amazon, đối với tôi đó cũng là một điều bí ẩn. Chỉ có điều bí ẩn này là lớn hơn nhiều, bởi vì có một người lái xe trên ô tô và trong AWS có hàng triệu người trong số họ. Tất cả người dùng đồng thời đánh lái, nhấn ga và phanh. Thật ngạc nhiên khi họ đi đến nơi họ muốn - đối với tôi đó là một điều kỳ diệu! Hệ thống tự động điều chỉnh, chia tỷ lệ và điều chỉnh đàn hồi cho từng người dùng để anh ta dường như chỉ có một mình trong Vũ trụ này.

Phép màu đã mất đi một chút khi sau này tôi đến làm kiến ​​trúc sư tại Amazon. Tôi đã thấy những vấn đề chúng tôi gặp phải, cách chúng tôi giải quyết chúng và cách chúng tôi phát triển dịch vụ. Với sự hiểu biết ngày càng tăng về cách thức hoạt động của hệ thống, sự tự tin hơn đối với dịch vụ xuất hiện. Vì vậy, tôi muốn chia sẻ bức tranh về những gì bên trong đám mây AWS.

Chúng ta sẽ nói về điều gì

Tôi đã chọn một cách tiếp cận đa dạng - Tôi đã chọn ra 4 dịch vụ thú vị đáng nói đến.

Tối ưu hóa máy chủ. Những đám mây phù du với hiện thân vật lý: trung tâm dữ liệu vật lý nơi có các máy chủ vật lý hoạt động ồn ào, nóng lên và nhấp nháy ánh đèn.

Chức năng không có máy chủ (Lambda) có lẽ là dịch vụ có khả năng mở rộng cao nhất trên đám mây.

Chia tỷ lệ cơ sở dữ liệu. Tôi sẽ cho bạn biết về cách chúng tôi xây dựng cơ sở dữ liệu có thể mở rộng của riêng mình.

Mở rộng quy mô mạng. Phần cuối cùng mà tôi sẽ mở thiết bị của mạng của chúng tôi. Đây là một điều tuyệt vời - mọi người dùng đám mây đều tin rằng mình ở một mình trên đám mây và hoàn toàn không nhìn thấy những người thuê nhà khác.

Ghi chú. Bài viết này sẽ thảo luận về tối ưu hóa máy chủ và mở rộng quy mô cơ sở dữ liệu. Chúng tôi sẽ xem xét việc mở rộng mạng trong bài viết tiếp theo. Các chức năng không có máy chủ ở đâu? Một bản ghi riêng đã được xuất bản về họ “Nhỏ nhưng thông minh. Mở hộp vi ảo Firecracker" Nó nói về một số phương pháp mở rộng quy mô khác nhau và thảo luận chi tiết về giải pháp Firecracker - sự cộng sinh của những phẩm chất tốt nhất của máy ảo và vùng chứa.

May chủ

Đám mây là phù du. Nhưng sự phù du này vẫn có một hiện thân vật lý - máy chủ. Ban đầu, kiến ​​trúc của họ mang tính cổ điển. Chipset x86 tiêu chuẩn, card mạng, Linux, Xen hypervisor chạy trên đó các máy ảo.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu

Vào năm 2012, kiến ​​trúc này đã xử lý khá tốt các nhiệm vụ của mình. Xen là một hypervisor tuyệt vời nhưng nó có một nhược điểm lớn. Anh ấy có đủ chi phí cao cho việc mô phỏng thiết bị. Khi có sẵn các card mạng hoặc ổ SSD mới, nhanh hơn, chi phí này sẽ trở nên quá cao. Làm thế nào để đối phó với vấn đề này? Chúng tôi quyết định làm việc trên hai mặt trận cùng một lúc - tối ưu hóa cả phần cứng và bộ ảo hóa. Nhiệm vụ này rất nghiêm túc.

Tối ưu hóa phần cứng và hypervisor

Làm mọi thứ cùng một lúc và làm tốt nó sẽ không hiệu quả. Ban đầu, thế nào là “tốt” cũng không rõ ràng.

Chúng tôi quyết định thực hiện một cách tiếp cận tiến hóa - chúng tôi thay đổi một yếu tố quan trọng của kiến ​​trúc và đưa nó vào sản xuất.

Chúng tôi bước lên từng cái cào, lắng nghe những lời phàn nàn và góp ý. Sau đó chúng ta thay đổi một thành phần khác. Vì vậy, với từng bước nhỏ, chúng tôi thay đổi hoàn toàn toàn bộ kiến ​​trúc dựa trên phản hồi từ người dùng và bộ phận hỗ trợ.

Quá trình chuyển đổi bắt đầu vào năm 2013 với thứ phức tạp nhất - mạng. TRONG С3 trong các trường hợp, một card Tăng tốc Mạng đặc biệt đã được thêm vào card mạng tiêu chuẩn. Nó được kết nối theo đúng nghĩa đen bằng một cáp vòng lặp ngắn ở mặt trước. Nó không đẹp nhưng không hiển thị trên đám mây. Nhưng sự tương tác trực tiếp với phần cứng về cơ bản đã cải thiện độ giật và thông lượng mạng.

Tiếp theo, chúng tôi quyết định cải thiện quyền truy cập vào khối lưu trữ dữ liệu EBS - Elastic Block Storage. Nó là sự kết hợp giữa mạng và lưu trữ. Khó khăn là mặc dù thẻ Network Accelerator đã tồn tại trên thị trường nhưng không có lựa chọn nào đơn giản là mua phần cứng Storage Accelerator. Vì vậy chúng tôi chuyển sang khởi nghiệp Phòng thí nghiệm Annapurna, người đã phát triển chip ASIC đặc biệt cho chúng tôi. Họ cho phép gắn các ổ đĩa EBS từ xa dưới dạng thiết bị NVMe.

Trong trường hợp C4 chúng tôi đã giải quyết được hai vấn đề. Đầu tiên là chúng tôi đã triển khai nền tảng cho tương lai của công nghệ NVMe đầy hứa hẹn nhưng mới vào thời điểm đó. Thứ hai, chúng tôi đã giảm tải đáng kể cho bộ xử lý trung tâm bằng cách chuyển quá trình xử lý yêu cầu sang EBS sang thẻ mới. Mọi chuyện diễn ra tốt đẹp nên giờ đây Annapurna Labs là một phần của Amazon.

Đến tháng 2017 năm XNUMX, chúng tôi nhận ra rằng đã đến lúc phải thay đổi chính bộ điều khiển ảo hóa.

Trình ảo hóa mới được phát triển dựa trên các mô-đun hạt nhân KVM đã sửa đổi.

Về cơ bản, nó có thể giảm chi phí mô phỏng thiết bị và hoạt động trực tiếp với ASIC mới. trường hợp С5 là những máy ảo đầu tiên có bộ ảo hóa mới chạy ẩn. Chúng tôi đặt tên cho anh ấy Nitro.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệuSự phát triển của các trường hợp trên dòng thời gian.

Tất cả các loại máy ảo mới xuất hiện kể từ tháng 2017 năm XNUMX đều chạy trên bộ ảo hóa này. Các phiên bản Bare Metal không có bộ ảo hóa, nhưng chúng còn được gọi là Nitro, vì chúng sử dụng thẻ Nitro chuyên dụng.

Trong hai năm tiếp theo, số lượng phiên bản Nitro đã vượt quá vài chục: A1, C5, M5, T3 và các loại khác.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu
Các loại phiên bản.

Máy Nitro hiện đại hoạt động như thế nào

Chúng có ba thành phần chính: bộ ảo hóa Nitro (đã thảo luận ở trên), chip bảo mật và thẻ Nitro.

Chip bảo mật được tích hợp trực tiếp vào bo mạch chủ. Nó kiểm soát nhiều chức năng quan trọng, chẳng hạn như kiểm soát việc tải hệ điều hành chủ.

thẻ nitro - Có bốn loại. Tất cả chúng đều được phát triển bởi Annapurna Labs và dựa trên các ASIC phổ biến. Một số phần sụn của họ cũng phổ biến.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu
Bốn loại thẻ Nitro.

Một trong những thẻ được thiết kế để hoạt động với mạngVPC. Đây là những gì hiển thị trong máy ảo dưới dạng card mạng ENA - Bộ điều hợp mạng đàn hồi. Nó cũng đóng gói lưu lượng truy cập khi truyền qua mạng vật lý (chúng ta sẽ nói về vấn đề này trong phần thứ hai của bài viết), kiểm soát tường lửa của Nhóm bảo mật và chịu trách nhiệm định tuyến cũng như các vấn đề khác về mạng.

Chọn thẻ hoạt động với bộ nhớ khối EBS và các đĩa được tích hợp vào máy chủ. Chúng xuất hiện với máy ảo khách dưới dạng bộ điều hợp NVMe. Họ cũng chịu trách nhiệm mã hóa dữ liệu và giám sát ổ đĩa.

Hệ thống thẻ Nitro, hypervisor và chip bảo mật được tích hợp vào mạng SDN hoặc Mạng do phần mềm xác định. Chịu trách nhiệm quản lý mạng này (Control Plane) thẻ điều khiển.

Tất nhiên, chúng tôi tiếp tục phát triển ASIC mới. Ví dụ: vào cuối năm 2018, họ đã phát hành chip Inferentia, cho phép bạn làm việc hiệu quả hơn với các tác vụ học máy.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu
Chip xử lý học máy Inferentia.

Cơ sở dữ liệu có thể mở rộng

Cơ sở dữ liệu truyền thống có cấu trúc phân lớp. Để đơn giản hóa rất nhiều, các cấp độ sau đây được phân biệt.

  • SQL — khách hàng và người điều phối yêu cầu làm việc trên đó.
  • Điều khoản giao dịch - mọi thứ đều rõ ràng ở đây, ACID và tất cả những thứ đó.
  • bộ nhớ đệm, được cung cấp bởi vùng đệm.
  • ghi nhật ký — cung cấp công việc với nhật ký làm lại. Trong MySQL, chúng được gọi là Nhật ký Bin, trong PosgreSQL - Nhật ký ghi trước (WAL).
  • Lưu trữ – ghi trực tiếp vào đĩa.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu
Cấu trúc cơ sở dữ liệu phân lớp.

Có nhiều cách khác nhau để mở rộng quy mô cơ sở dữ liệu: phân chia, kiến ​​trúc Không chia sẻ, đĩa dùng chung.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu

Tuy nhiên, tất cả các phương pháp này đều duy trì cấu trúc cơ sở dữ liệu nguyên khối giống nhau. Điều này hạn chế đáng kể việc mở rộng quy mô. Để giải quyết vấn đề này, chúng tôi đã phát triển cơ sở dữ liệu của riêng mình - Amazon cực quang. Nó tương thích với MySQL và PostgreSQL.

Amazon cực quang

Ý tưởng kiến ​​trúc chính là tách các mức lưu trữ và ghi nhật ký khỏi cơ sở dữ liệu chính.

Nhìn về phía trước, tôi sẽ nói rằng chúng tôi cũng đã làm cho cấp độ bộ nhớ đệm trở nên độc lập. Kiến trúc không còn là nguyên khối và chúng tôi có thêm mức độ tự do trong việc mở rộng quy mô các khối riêng lẻ.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu
Các mức ghi nhật ký và lưu trữ tách biệt với cơ sở dữ liệu.

DBMS truyền thống ghi dữ liệu vào hệ thống lưu trữ dưới dạng khối. Tại Amazon Aurora, chúng tôi đã tạo ra bộ lưu trữ thông minh có thể nói được ngôn ngữ làm lại nhật ký. Bên trong, bộ lưu trữ biến nhật ký thành khối dữ liệu, giám sát tính toàn vẹn của chúng và tự động sao lưu.

Cách tiếp cận này cho phép bạn thực hiện những điều thú vị như nhân bản. Về cơ bản, nó hoạt động nhanh hơn và tiết kiệm hơn do không yêu cầu tạo một bản sao hoàn chỉnh của tất cả dữ liệu.

Lớp lưu trữ được triển khai như một hệ thống phân tán. Nó bao gồm một số lượng rất lớn các máy chủ vật lý. Mỗi nhật ký làm lại được xử lý và lưu đồng thời sáu nút thắt. Điều này đảm bảo bảo vệ dữ liệu và cân bằng tải.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu

Có thể đạt được tỷ lệ đọc bằng cách sử dụng các bản sao thích hợp. Lưu trữ phân tán loại bỏ nhu cầu đồng bộ hóa giữa phiên bản cơ sở dữ liệu chính mà qua đó chúng tôi ghi dữ liệu và các bản sao còn lại. Dữ liệu cập nhật được đảm bảo có sẵn cho tất cả các bản sao.

Vấn đề duy nhất là lưu trữ dữ liệu cũ trên các bản sao đã đọc. Nhưng vấn đề này đang được giải quyết chuyển tất cả nhật ký làm lại để sao chép qua mạng nội bộ. Nếu nhật ký nằm trong bộ đệm, nó sẽ bị đánh dấu là không chính xác và bị ghi đè. Nếu nó không có trong bộ đệm, nó sẽ bị loại bỏ.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu

Chúng tôi đã sắp xếp lại nơi lưu trữ.

Cách chia tỷ lệ các tầng DBMS

Ở đây, việc chia tỷ lệ theo chiều ngang khó khăn hơn nhiều. Vì vậy hãy đi theo con đường mòn chia tỷ lệ dọc cổ điển.

Giả sử rằng chúng ta có một ứng dụng giao tiếp với DBMS thông qua nút chính.

Khi chia tỷ lệ theo chiều dọc, chúng tôi phân bổ một nút mới sẽ có nhiều bộ xử lý và bộ nhớ hơn.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu

Tiếp theo, chúng tôi chuyển ứng dụng từ nút chính cũ sang nút mới. Vấn đề phát sinh.

  • Điều này sẽ yêu cầu thời gian ngừng hoạt động ứng dụng đáng kể.
  • Nút chính mới sẽ có bộ nhớ đệm nguội. Hiệu suất cơ sở dữ liệu sẽ chỉ đạt tối đa sau khi bộ đệm đã ấm lên.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu

Làm thế nào để cải thiện tình hình? Thiết lập proxy giữa ứng dụng và nút chính.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu

Điều này sẽ mang lại cho chúng ta điều gì? Bây giờ tất cả các ứng dụng không cần phải chuyển hướng thủ công đến nút mới. Việc chuyển đổi có thể được thực hiện thông qua proxy và về cơ bản là nhanh hơn.

Có vẻ như vấn đề đã được giải quyết. Nhưng không, chúng ta vẫn phải làm nóng bộ đệm. Ngoài ra, một vấn đề mới đã xuất hiện - hiện tại proxy có thể là một điểm có thể gây ra lỗi.

Giải pháp cuối cùng với Amazon Aurora serverless

Chúng tôi đã giải quyết những vấn đề này như thế nào?

Để lại proxy. Đây không phải là một phiên bản riêng biệt mà là toàn bộ nhóm proxy được phân phối thông qua đó các ứng dụng kết nối với cơ sở dữ liệu. Trong trường hợp thất bại, bất kỳ nút nào cũng có thể được thay thế gần như ngay lập tức.

Đã thêm một nhóm các nút ấm có kích cỡ khác nhau. Do đó, nếu cần phân bổ một nút mới có kích thước lớn hơn hoặc nhỏ hơn, nó sẽ có sẵn ngay lập tức. Không cần phải đợi nó tải.

Toàn bộ quá trình mở rộng quy mô được kiểm soát bởi một hệ thống giám sát đặc biệt. Giám sát liên tục theo dõi trạng thái của nút chính hiện tại. Ví dụ: nếu phát hiện thấy tải bộ xử lý đã đạt đến giá trị tới hạn, nó sẽ thông báo cho nhóm phiên bản ấm về nhu cầu phân bổ một nút mới.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu
Proxy phân phối, phiên bản ấm và giám sát.

Một nút có sức mạnh cần thiết có sẵn. Vùng đệm được sao chép vào đó và hệ thống bắt đầu chờ thời điểm an toàn để chuyển đổi.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu

Thông thường thời điểm chuyển đổi đến khá nhanh. Sau đó, giao tiếp giữa proxy và nút chính cũ bị tạm dừng, tất cả các phiên được chuyển sang nút mới.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu

Làm việc với cơ sở dữ liệu sơ yếu lý lịch.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu

Biểu đồ cho thấy thời gian đình chỉ thực sự rất ngắn. Biểu đồ màu xanh hiển thị tải và các bước màu đỏ hiển thị khoảnh khắc chia tỷ lệ. Các mức giảm ngắn hạn trong biểu đồ màu xanh chính xác là độ trễ ngắn đó.

Cách AWS xử lý các dịch vụ linh hoạt của mình. Mở rộng quy mô máy chủ và cơ sở dữ liệu

Nhân tiện, Amazon Aurora cho phép bạn tiết kiệm hoàn toàn tiền và tắt cơ sở dữ liệu khi không sử dụng, chẳng hạn như vào cuối tuần. Sau khi dừng tải, DB giảm dần công suất và tắt một lúc. Khi tải trở lại, nó sẽ tăng trơn tru trở lại.

Trong phần tiếp theo của câu chuyện về thiết bị Amazon, chúng ta sẽ nói về việc mở rộng mạng. Đặt mua thư và theo dõi để không bỏ lỡ bài viết nhé.

Trên HighLoad ++ Vasily Pantyukhin sẽ báo cáo “Houston chúng ta có một vấn đề. Thiết kế hệ thống khi có lỗi, mô hình phát triển cho các dịch vụ đám mây nội bộ của Amazon" Các mẫu thiết kế nào cho hệ thống phân tán được các nhà phát triển Amazon sử dụng, lý do dẫn đến lỗi dịch vụ là gì, kiến ​​trúc dựa trên tế bào, Công việc liên tục, Shuffle Sharding là gì - sẽ rất thú vị. Còn chưa đầy một tháng nữa là đến hội nghị - đặt vé của bạn. Ngày 24 tháng XNUMX tăng giá cuối cùng.

Nguồn: www.habr.com

Thêm một lời nhận xét