Tự động mở rộng quy mô với Amazon Aurora Serverless

Amazon Aurora Serverless cung cấp cơ sở dữ liệu quan hệ theo yêu cầu, có thể mở rộng tự động, có tính khả dụng cao và chỉ tính phí bạn khi nó được sử dụng. Nó cung cấp một tùy chọn tương đối đơn giản, hiệu quả về chi phí cho khối lượng công việc không thường xuyên, không liên tục hoặc không thể đoán trước. Điều làm cho điều này có thể thực hiện được là nó tự động khởi động, chia tỷ lệ dung lượng tính toán để phù hợp với việc sử dụng ứng dụng của bạn và sau đó tắt khi không còn cần thiết nữa.

Sơ đồ sau cho thấy kiến ​​trúc cấp cao Aurora Serverless.

Với Aurora Serverless, bạn nhận được một điểm cuối (trái ngược với hai điểm cuối cho DB tiêu chuẩn được cung cấp Aurora). Về cơ bản, đây là một bản ghi DNS bao gồm một nhóm proxy nằm trên phiên bản cơ sở dữ liệu. Từ điểm máy chủ MySQL, điều đó có nghĩa là các kết nối luôn đến từ nhóm proxy.

Aurora Serverless Auto-Scaling

Aurora Serverless hiện chỉ khả dụng cho MySQL 5.6. Về cơ bản, bạn phải đặt đơn vị dung lượng tối thiểu và tối đa cho cụm DB. Mỗi đơn vị dung lượng tương đương với một cấu hình bộ nhớ và máy tính cụ thể. Aurora Serverless giảm tài nguyên cho cụm DB khi khối lượng công việc của nó dưới các ngưỡng này. Aurora Serverless có thể giảm dung lượng xuống mức tối thiểu hoặc tăng dung lượng lên đơn vị dung lượng tối đa.

Cụm sẽ tự động mở rộng quy mô nếu một trong các điều kiện sau được đáp ứng:

• Hiệu suất sử dụng CPU trên 70% HOẶC
• Hơn 90% kết nối đang được sử dụng

Cụm sẽ tự động giảm tỷ lệ nếu cả hai điều kiện sau được đáp ứng:

• Hiệu suất sử dụng CPU giảm xuống dưới 30% VÀ
• Ít hơn 40% kết nối đang được sử dụng.

Một số điều đáng chú ý cần biết về quy trình chia tỷ lệ tự động Aurora:

• Nó chỉ mở rộng quy mô khi phát hiện ra các vấn đề về hiệu suất có thể được giải quyết bằng cách mở rộng quy mô.
• Sau khi tăng tỷ lệ, thời gian hồi chiêu để thu nhỏ là 15 phút.
• Sau khi thu nhỏ lại, thời gian hồi chiêu cho lần thu nhỏ tiếp theo là 310 giây.
• Dung lượng sẽ giảm xuống mức 0 khi không có kết nối nào trong khoảng thời gian 5 phút.

Theo mặc định, Aurora Serverless thực hiện việc mở rộng quy mô tự động một cách liền mạch, mà không cắt bất kỳ kết nối cơ sở dữ liệu đang hoạt động nào với máy chủ. Nó có khả năng xác định điểm mở rộng (một thời điểm mà tại đó cơ sở dữ liệu có thể bắt đầu hoạt động mở rộng quy mô một cách an toàn). Tuy nhiên, trong các điều kiện sau, Aurora Serverless có thể không tìm thấy điểm mở rộng:

• Các truy vấn hoặc giao dịch kéo dài đang được tiến hành.
• Bảng tạm thời hoặc ổ khóa bảng đang được sử dụng.

Nếu một trong hai trường hợp trên xảy ra, Aurora Serverless tiếp tục cố gắng tìm điểm thay đổi tỷ lệ để có thể bắt đầu hoạt động mở rộng quy mô (trừ khi "Buộc mở rộng quy mô" được bật). Nó thực hiện điều này miễn là nó xác định rằng cụm DB nên được chia tỷ lệ.

Quan sát Hành vi mở rộng quy mô tự động của Aurora

Lưu ý rằng trong Aurora Serverless, chỉ có thể sửa đổi một số lượng nhỏ các tham số và max_connections không phải là một trong số đó. Đối với tất cả các tham số cấu hình khác, các cụm Aurora MySQL Serverless sử dụng các giá trị mặc định. Đối với max_connections, nó được Aurora Serverless điều khiển động bằng công thức sau:

max_connections =GREATEST ({log (DBInstanceClassMemory / 805306368) * 45}, {log (DBInstanceClassMemory / 8187281408) * 1000})

Trong đó, nhật ký là nhật ký ₂ (log base-2) và "DBInstanceClassMemory" là số byte bộ nhớ được cấp phát cho lớp cá thể DB được liên kết với cá thể DB hiện tại, ít hơn bộ nhớ được sử dụng bởi các quy trình Amazon RDS quản lý cá thể đó. Khá khó để xác định trước giá trị mà Aurora sẽ sử dụng, do đó, tốt hơn là bạn nên thực hiện một số thử nghiệm để hiểu giá trị này được chia tỷ lệ như thế nào cho phù hợp.

Đây là bản tóm tắt triển khai Aurora Serverless của chúng tôi cho thử nghiệm này:

Đối với ví dụ này, tôi đã chọn tối thiểu 1 đơn vị dung lượng Aurora, tương đương với 2GB RAM cho đến đơn vị dung lượng tối đa 256 với 488 GB RAM.

Các thử nghiệm được thực hiện bằng cách sử dụng sysbench, chỉ cần gửi nhiều luồng cho đến khi nó đạt đến giới hạn kết nối cơ sở dữ liệu MySQL. Nỗ lực đầu tiên của chúng tôi để gửi 128 kết nối cơ sở dữ liệu đồng thời cùng một lúc đã gặp sự cố:

$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=128 \
--delete_inserts=5 \
--time=360 \
--max-requests=0 \
--db-driver=mysql \
--db-ps-mode=disable \
--mysql-host=${_HOST} \
--mysql-user=sbtest \
--mysql-db=sbtest \
--mysql-password=password \
--tables=20 \
--table-size=100000 \
run

Lệnh trên ngay lập tức trả về lỗi 'Quá nhiều kết nối':

FATAL: unable to connect to MySQL server on host 'aurora-sysbench.cluster-cdw9q2wnb00s.ap-southeast-1.rds.amazonaws.com', port 3306, aborting...
FATAL: error 1040: Too many connections

Khi xem xét cài đặt max_connection, chúng tôi nhận được những điều sau:

mysql> SELECT @@hostname, @@max_connections;
+----------------+-------------------+
| @@hostname     | @@max_connections |
+----------------+-------------------+
| ip-10-2-56-105 |                90 |
+----------------+-------------------+

Hóa ra, giá trị bắt đầu của max_connections cho phiên bản Aurora của chúng tôi với một dung lượng DB (RAM 2GB) là 90. Con số này thực sự thấp hơn giá trị dự đoán của chúng tôi nếu được tính bằng công thức được cung cấp để ước tính giá trị max_connections:

mysql> SELECT GREATEST({log2(2147483648/805306368)*45},{log2(2147483648/8187281408)*1000});
+------------------------------------------------------------------------------+
| GREATEST({log2(2147483648/805306368)*45},{log2(2147483648/8187281408)*1000}) |
+------------------------------------------------------------------------------+
|                                                                     262.2951 |
+------------------------------------------------------------------------------+

Điều này đơn giản có nghĩa là DBInstanceClassMemory không bằng bộ nhớ thực cho cá thể Aurora. Nó phải là cách thấp hơn. Theo chuỗi thảo luận này, giá trị của biến được điều chỉnh cho phù hợp với bộ nhớ đã được sử dụng cho các dịch vụ hệ điều hành và daemon quản lý RDS.

Tuy nhiên, việc thay đổi giá trị max_connections mặc định thành giá trị cao hơn cũng không giúp ích gì cho chúng tôi vì giá trị này được điều khiển động bởi Aurora Serverless cluster. Do đó, chúng tôi đã phải giảm giá trị chủ đề bắt đầu sysbench xuống 84 vì các luồng nội bộ Aurora đã dành sẵn khoảng 4 đến 5 kết nối thông qua 'rdsadmin' @ 'localhost'. Ngoài ra, chúng tôi cũng cần một kết nối bổ sung cho mục đích quản lý và giám sát của mình.

Vì vậy, chúng tôi đã thực hiện lệnh sau để thay thế (với --threads =84):

$ sysbench \
/usr/share/sysbench/oltp_read_write.lua \
--report-interval=2 \
--threads=84 \
--delete_inserts=5 \
--time=600 \
--max-requests=0 \
--db-driver=mysql \
--db-ps-mode=disable \
--mysql-host=${_HOST} \
--mysql-user=sbtest \
--mysql-db=sbtest \
--mysql-password=password \
--tables=20 \
--table-size=100000 \
run

Sau khi hoàn thành thử nghiệm trên trong 10 phút (--time =600), chúng tôi chạy lại lệnh tương tự và lúc này, một số biến và trạng thái đáng chú ý đã thay đổi như hình dưới đây:

mysql> SELECT @@hostname AS hostname, @@max_connections AS max_connections, 
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'THREADS_CONNECTED') AS threads_connected, 
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'UPTIME') AS uptime;
+--------------+-----------------+-------------------+--------+
| hostname     | max_connections | threads_connected | uptime |
+--------------+-----------------+-------------------+--------+
| ip-10-2-34-7 |             180 | 179               | 157    |
+--------------+-----------------+-------------------+--------+

Lưu ý rằng max_connections hiện đã tăng gấp đôi lên 180, với một tên máy chủ khác và thời gian hoạt động nhỏ như máy chủ mới bắt đầu. Từ quan điểm của ứng dụng, có vẻ như một "phiên bản cơ sở dữ liệu lớn hơn" khác đã tiếp quản điểm cuối và được định cấu hình bằng một biến max_connections khác. Nhìn vào sự kiện Aurora, điều sau đã xảy ra:

Wed, 04 Sep 2019 08:50:56 GMT The DB cluster has scaled from 1 capacity unit to 2 capacity units.

Sau đó, chúng tôi kích hoạt lệnh sysbench tương tự, tạo 84 kết nối khác đến điểm cuối cơ sở dữ liệu. Sau khi hoàn tất kiểm tra căng thẳng được tạo, máy chủ sẽ tự động mở rộng dung lượng lên đến 4 DB, như được hiển thị bên dưới:

mysql> SELECT @@hostname AS hostname, @@max_connections AS max_connections, 
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'THREADS_CONNECTED') AS threads_connected,
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'UPTIME') AS uptime;
+---------------+-----------------+-------------------+--------+
| hostname      | max_connections | threads_connected | uptime |
+---------------+-----------------+-------------------+--------+
| ip-10-2-12-75 |             270 | 6                 | 300    |
+---------------+-----------------+-------------------+--------+

Bạn có thể biết bằng cách xem tên máy chủ, max_connection và giá trị thời gian hoạt động khác nhau nếu so với giá trị trước đó. Một phiên bản khác lớn hơn đã "tiếp quản" vai trò từ phiên bản trước, trong đó dung lượng DB bằng 2. Điểm mở rộng thực tế là khi tải máy chủ giảm và gần như chạm sàn. Trong thử nghiệm của chúng tôi, nếu chúng tôi giữ kết nối đầy đủ và tải cơ sở dữ liệu luôn ở mức cao, thì việc mở rộng quy mô tự động sẽ không diễn ra.

Bằng cách xem cả hai ảnh chụp màn hình bên dưới, chúng ta có thể biết việc chia tỷ lệ chỉ xảy ra khi Sysbench của chúng tôi đã hoàn thành bài kiểm tra căng thẳng trong 600 giây vì đó là điểm an toàn nhất để thực hiện chia tỷ lệ tự động.

Khi xem xét các sự kiện Aurora, các sự kiện sau đã xảy ra:

Wed, 04 Sep 2019 16:25:00 GMT Scaling DB cluster from 4 capacity units to 2 capacity units for this reason: Autoscaling.
Wed, 04 Sep 2019 16:25:05 GMT The DB cluster has scaled from 4 capacity units to 2 capacity units.

Cuối cùng, chúng tôi đã tạo thêm nhiều kết nối cho đến gần 270 và đợi cho đến khi kết thúc, để có được dung lượng 8 DB:

mysql> SELECT @@hostname as hostname, @@max_connections AS max_connections, 
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'THREADS_CONNECTED') AS threads_connected,
(SELECT VARIABLE_VALUE FROM global_status WHERE VARIABLE_NAME = 'UPTIME') AS uptime;
+---------------+-----------------+-------------------+--------+
| hostname      | max_connections | threads_connected | uptime |
+---------------+-----------------+-------------------+--------+
| ip-10-2-72-12 |            1000 | 144               | 230    |
+---------------+-----------------+-------------------+--------+

Trong trường hợp 8 đơn vị dung lượng, giá trị max_connections của MySQL hiện là 1000. Chúng tôi lặp lại các bước tương tự bằng cách tăng tối đa các kết nối cơ sở dữ liệu và lên đến giới hạn 256 đơn vị dung lượng. Bảng sau đây tóm tắt đơn vị dung lượng DB tổng thể so với giá trị max_connections trong thử nghiệm của chúng tôi lên đến dung lượng DB tối đa:

Tỷ lệ bắt buộc

Như đã đề cập ở trên, Aurora Serverless sẽ chỉ thực hiện chia tỷ lệ tự động khi an toàn. Tuy nhiên, người dùng có tùy chọn để buộc quy mô dung lượng DB diễn ra ngay lập tức bằng cách đánh dấu vào hộp kiểm Buộc mở rộng quy mô trong tùy chọn 'Cấu hình chia tỷ lệ bổ sung':

Khi bật tính năng chia tỷ lệ bắt buộc, tỷ lệ sẽ xảy ra ngay khi hết thời gian đạt được là 300 giây. Hành vi này có thể gây ra gián đoạn cơ sở dữ liệu từ ứng dụng của bạn, nơi các kết nối đang hoạt động với cơ sở dữ liệu có thể bị ngắt. Chúng tôi đã quan sát thấy lỗi sau khi bắt buộc chia tỷ lệ tự động xảy ra sau khi hết thời gian chờ:

FATAL: mysql_drv_query() returned error 1105 (The last transaction was aborted due to an unknown error. Please retry.) for query 'SELECT c FROM sbtest19 WHERE id=52824'
FATAL: `thread_run' function failed: /usr/share/sysbench/oltp_common.lua:419: SQL error, errno = 1105, state = 'HY000': The last transaction was aborted due to an unknown error. Please retry.

Điều trên chỉ có nghĩa là, thay vì tìm thời điểm thích hợp để mở rộng quy mô, Aurora Serverless buộc việc thay thế phiên bản diễn ra ngay sau khi hết thời gian chờ, điều này khiến các giao dịch bị hủy bỏ và được lùi lại. Thử lại truy vấn đã hủy bỏ lần thứ hai có thể sẽ giải quyết được vấn đề. Cấu hình này có thể được sử dụng nếu ứng dụng của bạn có khả năng phục hồi khi kết nối bị rớt.

Tóm tắt

Tự động chia tỷ lệ Amazon Aurora Serverless là một giải pháp mở rộng quy mô theo chiều dọc, trong đó phiên bản mạnh hơn sẽ thay thế phiên bản kém hơn, sử dụng hiệu quả công nghệ lưu trữ được chia sẻ Aurora bên dưới. Theo mặc định, hoạt động chia tỷ lệ tự động được thực hiện liền mạch, theo đó Aurora tìm thấy điểm mở rộng an toàn để thực hiện chuyển đổi phiên bản. Một người có tùy chọn để buộc tự động mở rộng quy mô với rủi ro các kết nối cơ sở dữ liệu đang hoạt động bị ngắt.