Ở các phần trước, chúng ta đã tìm hiểu về Khái niệm cũng như các loại cân bằng tải trên AWS, phần này chúng ta sẽ đi tiếp các phần còn lại mà chúng ta nên biết khi làm việc với các bộ cân bằng tải.
Sticky Sessions - Session Affinity
Phiên cố định, còn được gọi là mối quan hệ phiên hoặc tính bền vững của phiên, là một cơ chế được sử dụng trong cân bằng tải để đảm bảo rằng các yêu cầu của người dùng được chuyển hướng nhất quán đến cùng một máy chủ trong nhóm máy chủ.
Có một vấn đề mà chúng ta hay gặp phải (đặc biệt là các ứng dụng stateful) khi triển khai cân bằng tải, đó là "Làm thế nào để có thể điều hướng request từ một Client đến chính xác Server đang phục vụ họ?".
Đối với các ứng dụng mà server có lưu trạng thái và phục vụ client theo từng phiên (session), vấn đề căn bản là cần điều hướng request đến đúng nơi, tránh trường hợp "râu ông nọ cắm vào cằm bà kia". Có nhiều giải pháp có thể thực hiện trên AWS đối với các ứng dụng dạng này, tuy nhiên trong phạm vi bài viết nói về các bộ cân bằng tải, Sticky Session (Session Affinity) - có thể hiểu nôm na là các phiên làm việc sẽ được "dính" với một cặp Client - Server xác định sẽ giúp đảm bảo rằng các bộ cân bằng tải có thể điều hướng request đến đúng nơi.
Một ví dụ đơn giản cho trường hợp này: Khi đến ngân hàng, bạn đang làm việc với giao dịch viên (GDV) A, sau khi trình bày vấn đề của mình, việc tiếp theo bạn cần làm là cung cấp giấy tờ tùy thân. Ở đây nếu bạn đưa các giấy tờ này cho một GDV khác gọi là B, dĩ nhiên cô ấy không hiểu bạn đang làm gì. Điều này xảy ra tương tự đối với trường hợp của cặp Client - Server mà chúng ta nói ở trên.
Các đặc tính của Sticky Sessions:
- Sticky Sessions hoạt động trên cả Classic Load Balancers (trước đây) & Application Load Balancers (hiện nay).
- Có thể kiểm soát thời gian "dính" của mỗi phiên thông qua cookie. Sau khoảng thời gian hết hạn đã chỉ định, nếu người dùng đưa ra yêu cầu mới, bộ cân bằng tải có thể gán lại chúng cho một máy chủ khác và cấp cookie phiên mới.
- Việc kích hoạt Sticky Session có thể gây ra sự mất cân bằng tải cho toàn hệ thống, từ đó làm giảm hiệu quả của các bộ cân bằng tải.
Sticky Sessions – Cookie Names
Ở phần trên, chúng ta có nhắc đến Cookie khi làm việc với các bộ cân bằng tải, vậy cụ thể nó là như thế nào?
Application-based Cookies
Custom Cookie (Tùy chỉnh):
- Được tạo tùy theo mục đích sử dụng.
- Có thể bao gồm bất kỳ thuộc tính tùy chỉnh nào mà ứng dụng yêu cầu.
- Tên cookie phải được chỉ định riêng cho từng nhóm mục tiêu.
- Khi đặt tên, không sử dụng AWSALB, AWSALBAPP hoặc AWSALBTG (các tên này dành riêng cho ELB sử dụng).
Application Cookie: - Được tạo bởi bộ cân bằng tải, có tên mặc định là AWSALBAPP.
Duration-based Cookies
- Cookie được tạo bởi bộ cân bằng tải.
- Tên Cookie được cấu hình sẵn là AWSALB cho ALB và AWSELB cho CLB.
Cross-Zone Load Balancing
AWS hỗ trợ cân bằng tải cả trong và ngoài Availability Zone (AZ) thông qua tính năng Cross-Zone Load Balancing. Ở phần dưới, chúng ta sẽ thảo luận về sự khác biệt khi sử dụng/không sử dụng tính năng này.
Khi không sử dụng tính năng Cross-Zone Load Balancing
Requests sẽ bị phân bổ đến các instances thuộc các Node (ở các AZ khác nhau) của bộ cân bằng tải, từ đó gây ra vấn đề khi AZ 2 có nhiều Instances hơn sẽ thừa nhiều tài nguyên hơn trong khi đó AZ 1 lại đang bị quá tải, điều này xảy ra do lượng tải được chia đều giữa 2 nodes mà không quan tâm đến số lượng Instance trong mỗi node.
Khi sử dụng tính năng Cross-Zone Load Balancing
Tải đã được phân bố đồng đều giữa các Instances trong hệ thống, đảm bảo không server nào bị quá tải từ đó giúp tận dụng tối đa thế mạnh của bộ cân bằng tải.
Tính năng Cross-Zone Load Balancing trên các loại cân bằng tải
- Application Load Balancer:
- Cross-Zone Load Balancing là tính năng mặc định trên ALB.
- Bạn không phải chi trả bất cứ chi phí nào cho dữ liệu trao đổi giữa các Availability Zone.
- Cross-Zone Load Balancing là tính năng mặc định trên ALB.
- Network Load Balancer & Gateway Load Balancer:
- Mặc định tính năng này sẽ bị tắt đối với 2 bộ cân bằng tải nói trên.
- Khi bật tính năng Cross-Zone Load Balancing, cần lưu ý là người dùng sẽ phải trả phí cho dữ liệu trao đổi giữa các Availability Zone.
- Mặc định tính năng này sẽ bị tắt đối với 2 bộ cân bằng tải nói trên.
- Classic Load Balancer:
- Bị tắt theo mặc định.
- Bạn không phải chi trả bất cứ chi phí nào cho dữ liệu trao đổi giữa các Availability Zone, tuy nhiên CLB đã nghỉ hưu nhường chỗ cho ALB.
- Bị tắt theo mặc định.
SSL/TLS trên các bộ cân bằng tải
Cơ bản về SSL/TLS
- Chứng chỉ SSL cho phép lưu lượng truy cập giữa máy khách và bộ cân bằng tải được mã hóa trong quá trình chuyển tiếp (in-flight encryption).
- SSL (Secure Sockets Layer) - sử dụng để mã hóa dữ liệu trên đường truyền.
- TLS có nghĩa là Transport Layer Security - phiên bản mới hơn của SSL.
- Ngày nay, các ứng dụng chủ yếu sử dụng TLS, tuy nhiên một cách đơn giản, nhiều người vẫn đang gọi chung là SSL.
- Chứng chỉ SSL Public sẽ được cấp bởi một đơn vị gọi là Certificate Authorities (CA). Có thể kể tới nhiều đơn vị như Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Letsencrypt, etc… Trong số đó, Letsencrypt là một trong những tổ chức cung cấp chứng chỉ miễn phí và đơn giản nhất.
- Cần lưu ý rằng chứng chỉ SSL là có thời hạn (có thể tự cấu hình, thường là 1 năm) và cần renew sau một khoảng thời gian. Thao tác này cũng tương đối đơn giản và có thể thực hiện tự động, tùy vào nhà cung cấp chứng chỉ.
SSL Certificates
- Các bộ cân bằng tải sử dụng chứng chỉ X.509 (Chứng chỉ SSL/TLS cho server).
- Đối với AWS, chúng ta có thể quản lý các chứng chỉ thông qua ACM (AWS Certificate Manager).
- Người dùng có thể tự upload chứng chỉ của người dùng lên ACM.
- HTTPS listener:
- Cần phải cấu hình một chứng chỉ mặc định.
- Có thể thêm một danh sách các chứng chỉ hỗ trợ cho nhiều domains khác nhau.
- Client có thể sử dụng SNI (Server Name Indication) để chhỉ định máy chủ (hostname) mà chứng chỉ cần tiếp cận.
- Có khả năng chỉ định các chính sách bảo mật nhất định để hỗ trợ các phiên bản SSL/TLS cũ hơn để phục vụ hệ thống sẵn có của khách hàng.
- Cần phải cấu hình một chứng chỉ mặc định.
Server Name Indication (SNI)
- SNI giải quyết các vấn đề liên quan đến việc tải nhiều chứng chỉ SSL trên cùng 1 web server (nhằm phục vụ nhiều website trên cùng một server - điều này thường xuyên xảy ra đối với các ứng dụng web quy mô nhỏ, dùng cho một nhóm nhỏ người dùng).
- Đây có thể coi là một giao thức "mới hơn", nó yêu cầu người dùng chỉ ra hostname của server mà họ muốn kết nối đến trong khi khởi tạo quá trình SSL Handshake.
SL Handshake - quá trình "bắt tay" trao đổi SSL Certificate và Public Key giữa client và server, Public Key này sẽ được sử dụng để mã hóa nội dung tin nhắn sau này. Client sẽ sử dụng Public Key để mã hóa gói tin, Key này chỉ có thể mã hóa, không thể giải mã. Sau khi nhận được gói tin, server sẽ sử dụng Private Key để giải mã gói tin.
- Server sẽ tìm tới chứng chỉ chính xác với yêu cầu của client, trong trường hợp không tìm thấy, chứng chỉ default sẽ được trả về.
Note: Cần lưu ý rằng SNI chỉ hoạt động với 2 phiên bản Load Balancers mới hơn là ALB và NLB, bên cạnh đó là CloudFront. SNI không hoạt động với CLB (phiên bản cũ hơn đã bị ngừng hoạt động).
Chứng chỉ SSL hoạt động như thế nào qua các phiên bản ELB?
Classic Load Balancer (v1):
- Chỉ hỗ trợ 01 chứng chỉ SSL.
- Cần phải sử dụng nhiều CLB cho nhiều Hostname với nhiều chứng chỉ SSL khác nhau.
Application Load Balancer và Network Load Balancer(v2): - Hỗ trợ nhiều listeners với nhiều chứng chỉ SSL khác nhau thông qua tính năng Server Name Indication (SNI).
Connection Draining - Ngắt kết nối instance khỏi ELB
Đối với các bộ cân bằng tải, việc ngắt kết nối một hay nhiều instances không đơn giản chỉ là tắt chúng đi.
Quá trình ngắt kết nối này đã đổi tên qua các thế hệ cân bằng tải trên AWS, quá trình này được gọi là Connection Draining (Ngắt kết nối) đối với CLB và Deregistration Delay (Hủy đăng ký) đối với ALB & NLB.
Để ngắt một instance khỏi cân bằng tải, người dùng có thể kiểm soát thời gian cần thiết để một bộ cân bằng tải ngừng gửi các yêu cầu mới đến phiên bản EC2 đang bị hủy đăng ký hoặc bị đánh dấu là unhealthy (bị lỗi). Thời gian này có thể từ 1 đến 3600 giây (mặc định là 300 giây). Khoảng thời gian này có thể đặt về 0, tuy nhiên điều này có thể gây ra các lỗi không xác định. Trong trường hợp các requests không cần quá nhiều thời gian, có thể cấu hình một giá trị thấp để tiết kiệm thời gian chờ.