AWS Study Group

Hiện đại hóa mạng lưới tài chính: Triển khai multicast của Huatai Securities trên AWS

Tác giả: Kevin và Baoliang Cui
Ngày phát hành: 26 JAN 2026
Chuyên mục: AWS Transit Gateway, AWS Transit Gateway network manager, Networking & Content Delivery

Lưu ý: Bài viết này được xuất bản với sự hợp tác của Zhonghai Hu, Kiến trúc sư cấp cao tại Huatai Securities và Ricky Chu, Giám đốc dự án Hạ tầng, tại Huatai Financial Holdings (Hồng Kông).

Huatai Securities Co., Ltd., một tập đoàn chứng khoán định hướng công nghệ được thành lập vào năm 1991, cam kết chuyển đổi ngành công nghiệp chứng khoán Trung Quốc thông qua các công nghệ tài chính đổi mới. Gần đây, chúng tôi đã gặp phải một thách thức đáng kể khi triển khai các hệ thống giao dịch được container hóa của mình trên Amazon Web Services (AWS). Cấu hình mặc định của Amazon Elastic Kubernetes Service (Amazon EKS) thiếu hỗ trợ gốc cho multicast, một phương thức giao tiếp quan trọng cần thiết để đạt được khả năng truyền dữ liệu mà các hệ thống giao dịch của chúng tôi yêu cầu. Để vượt qua trở ngại này, chúng tôi đã phát triển một giải pháp sử dụng AWS Transit Gateway để kích hoạt khả năng multicast trong các cụm EKS của mình, dẫn đến việc tăng đáng kể hiệu suất giao dịch tổng thể.

Bài viết này giải thích cách Huatai Securities triển khai multicast cho các cụm EKS của mình bằng cách sử dụng Transit Gateway, trình bày chi tiết quy trình kỹ thuật và giải pháp này mang lại lợi ích đáng kể cho Huatai Securities bằng cách giảm mức sử dụng băng thông và cải thiện độ trễ gấp 10 lần cho các hoạt động giao dịch của họ.

Tổng quan giải pháp

Giải pháp của chúng tôi sử dụng plugin Amazon Virtual Private Cloud (Amazon VPC) CNI làm plugin mạng chính cho cụm EKS, sử dụng Transit Gateway để cung cấp khả năng multicast. Chúng tôi thêm Elastic Network Interface (ENI) từ subnet của miền multicast vào node, cho phép giao tiếp multicast cho cụm EKS dưới dạng Host-device và một plugin IP Address Management (IPAM) tùy chỉnh, đồng thời sử dụng plugin Multus để hỗ trợ nhiều giao diện mạng. IPAM ở đây đề cập đến chức năng chịu trách nhiệm phân bổ và quản lý địa chỉ IP cho các pod và dịch vụ trong một cụm Kubernetes. Điều này có nghĩa là các Pod có thể sử dụng VPC CNI để giao tiếp unicast, và để đạt được giao tiếp multicast với plugin Host-device và Transit Gateway cùng nhau. Hình 1 cho thấy sơ đồ kiến trúc của giải pháp.


Hình 1: Cụm EKS hỗ trợ multicast

Điều kiện tiên quyết

Những điều sau đây là cần thiết để triển khai và xác minh giải pháp của chúng tôi, cho phép multicast trong Amazon EKS:

  • Một VPC với ba subnet (một cho giao tiếp multicast, một cho giao tiếp non-multicast và một cho Transit Gateway ENI) trải rộng trên một AWS Availability Zone (AZ) duy nhất—thiết kế này được chọn để đáp ứng các yêu cầu về độ trễ thấp của chúng tôi
  • Một Transit Gateway với các VPC attachment
  • Một Multicast Domain với các liên kết subnet
  • Cụm EKS
  • Một phiên bản Amazon Elastic Compute Cloud (Amazon EC2) đã cài đặt eksctl và kubectl để triển khai giải pháp và kiểm thử giao tiếp multicast

Hướng dẫn chi tiết

Các bước sau đây sẽ hướng dẫn bạn thực hiện giải pháp này.

Bước 1: Tạo Transit Gateway Domain

Tạo một Transit Gateway và gắn VPC đã chuẩn bị vào đó. Sau đó, sử dụng Transit Gateway để tạo một IGMP multicast domain, và liên kết subnet multicast đã lên kế hoạch với multicast domain để xây dựng môi trường multicast cơ bản. Để biết hướng dẫn chi tiết về cách tạo IGMP Domain bằng Transit Gateway, hãy tham khảo tài liệu Tạo IGMP multicast domain trong AWS Transit Gateway. Hình 2 cho thấy một ví dụ về IGMP multicast domain được tạo bằng Transit Gateway:


Hình 2: Ví dụ về IGMP multicast domain được tạo bằng Transit Gateway

Bước 2: Tạo cụm EKS

Sử dụng VPC và các subnet EKS đã lên kế hoạch để tạo cụm. Bạn có thể sử dụng công cụ CLI eksctl để tạo nó bằng lệnh sau. Do các yêu cầu bảo mật, chúng tôi đang tạo một cụm EKS riêng tư.

eksctl create cluster -f {cluster_define_yaml_filepath}

Bạn có thể tham khảo ví dụ trong Hình 3 để biết định nghĩa tệp YAML:


Hình 3: Ví dụ về định nghĩa tệp YAML để tạo cụm EKS

Bước 3: Kiểm tra và cấu hình tham số warm pool ENI của plugin VPC CNI trong cụm EKS

Giá trị mặc định cho tham số WARM_ENI_TARGET của VPC CNI được đặt là 1 theo mặc định, có nghĩa là một ENI bổ sung được thêm vào một trong các node trong NodeGroup. Tuy nhiên, điều này dẫn đến số lượng ENI không nhất quán giữa các node, có thể làm phức tạp việc cấu hình multicast. Để tránh điều này, chúng tôi đặt rõ ràng WARM_ENI_TARGET thành 0, tắt warm pool. Điều này đảm bảo rằng mỗi node trong NodeGroup mới tạo chỉ có một ENI.

kubectl set env daemonset aws-node -n kube-system WARM_ENI_TARGET=0

Bước 4: Tạo NodeGroup cho giao tiếp multicast

Chúng tôi đã sử dụng eksctl để tạo một NodeGroup. Đảm bảo chỉ định khóa SSH để truy cập node nhằm tạo điều kiện thuận lợi cho các hoạt động sau này.

eksctl create cluster -f {cluster_define_yaml_filepath}

Bạn có thể tham khảo ví dụ trong Hình 4 để biết định nghĩa tệp YAML:


Hình 4: Ví dụ về định nghĩa tệp YAML để tạo NodeGroup

Bước 5: Tạo Multicast ENI, cấu hình nhóm bảo mật, đặt thẻ khóa và gắn ENI vào các node

Khi tạo multicast ENI (số lượng ENI phải khớp với số lượng node trong NodeGroup được tạo cho giao tiếp multicast), có hai điểm chính:

  • Lưu ý 1: Gán một nhóm bảo mật cho mỗi multicast ENI cho phép giao tiếp multicast.
  • Lưu ý 2: Theo mặc định, các ENI được gắn vào các node được quản lý bởi plugin VPC CNI. Để ngăn các multicast ENI bị quản lý bởi plugin, hãy đặt các thẻ sau trên mỗi ENI:
KhóaGiá trị
node.k8s.amazonaws.com/no_managetrue

Sau khi chúng tôi gắn ENI đã tạo vào node, chúng tôi có thể SSH vào node để xác minh rằng một giao diện mạng có tên eth1 hiển thị, như trong Hình 5.


Hình 5: Giao diện mạng có tên eth1 hiển thị trên node

Bước 6: Cài đặt plugin Multus

Tham khảo liên kết GitHub Apply AWS Auth Configmap để sửa đổi Auth ConfigMap, và liên kết GitHub Install Multus để cài đặt plugin Multus.

Sử dụng lệnh kubectl để xác nhận rằng việc cài đặt đã thành công. Bạn sẽ thấy một pod có tên kube-multus-xxxx đang chạy bình thường trong namespace kube-system.

Bước 7: Cấu hình tham số kernel IGMP trên các Node và thiết lập plugin IPAM tùy chỉnh

Chúng tôi đã đăng nhập vào mỗi node và đặt các tham số kernel sau:

sudo sysctl -w net.ipv4.conf.all.force_igmp_version=2
sudo sysctl -w net.ipv4.conf.default.force_igmp_version=2

Nếu bạn muốn các cài đặt này tồn tại vĩnh viễn, bạn có thể thêm hai tham số vào cuối tệp /etc/sysctl.conf và chạy lệnh sau:

sudo sysctl -p

Sao chép plugin IPAM tùy chỉnh đã phát triển vào thư mục /opt/cni/bin trên node và cấp quyền thực thi cho nó:

sudo cp {your ipam file path} /opt/cni/bin/{ipam_filename}
sudo chmod +x /opt/cni/bin/{ipam_filename}

Chức năng chính của plugin IPAM ở đây là gán IP của multicast ENI của node cho giao diện mạng multicast của pod. Điều này cho phép chương trình truy cập giao diện mạng multicast thông qua IP đó.

Mã mẫu của việc triển khai plugin IPAM tùy chỉnh như sau:

#!/bin/bash
# need to grant execute permissions with chmod +x.
# When configuring, it needs to be placed in the CNI plugin directory (typically /opt/cni/bin/).
# Logging function
log() {
    echo "{\"timestamp\":\"$(date -u '+%Y-%m-%dT%H:%M:%SZ')\",\"message\":\"$1\"}" >&2
}
# Function to get the EC2 subnet CIDR.
get_ec2_interface_info() {
    local mac=$1
    # Get IMDSv2 token
    local token=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
    if [ -z "$token" ]; then
    log "Failed to get IMDSv2 token"
    exit 1
    fi
    # Get the IP address corresponding to this MAC address (local-ipv4s may return multiple IPs, take the first one)
    local ip=$(curl -s -H "X-aws-ec2-metadata-token: $token" http://169.254.169.254/latest/meta-data/network/interfaces/macs/${mac}/local-ipv4s | head -n 1)
    if [ -z "$ip" ]; then
        log "Failed to get IP for MAC $mac"
        exit 1
    fi
    # Get subnet CIDR
    local cidr=$(curl -s -H "X-aws-ec2-metadata-token: $token" http://169.254.169.254/latest/meta-data/network/interfaces/macs/${mac}/subnet-ipv4-cidr-block)
    if [ -z "$cidr" ]; then
    log "Failed to get subnet CIDR from metadata service"
    exit 1
    fi
    local mask=$(echo "$cidr" | cut -d'/' -f2)
    echo "$ip/$mask"
}
# get the MAC address of the container
get_container_mac() {
    local ifname=$1
    local netns_path=$2
    local netns=$(basename "$netns_path")
    # Get the MAC address in the container network namespace
    local mac=$(ip netns exec "$netns" ip link show "$ifname" | grep ether | awk '{print $2}')
    if [ -z "$mac" ]; then
        log "Failed to get MAC address for interface $ifname"
        exit 1
    fi
    echo $mac
}
# Process CNI commands
case "$CNI_COMMAND" in
    ADD)
       # Verify required environment variables
       if [ -z "$CNI_IFNAME" ] || [ -z "$CNI_NETNS" ]; then
           log "Missing required CNI variables"
           exit 1
       fi
       log "Processing ADD for interface $CNI_IFNAME in netns $CNI_NETNS"
       # get container mac
       mac_addr=$(get_container_mac "$CNI_IFNAME" "$CNI_NETNS")
       log "Got container MAC address: $mac_addr"
       # Get the EC2 IP
       iface_ip=$(get_ec2_interface_info $mac_addr)
       log "Got Interface IP: $iface_ip"
       # Construct the CNI return result
       cat << EOF
{
    "cniVersion": "0.3.1",
    "interfaces": [
        {
            "name": "$CNI_IFNAME"
        }
    ],
    "ips": [
        {
        "version": "4",
        "address": "$iface_ip"
        }
    ]
}
EOF
        ;;
    DEL)
        # For DELETE operations, simply return success.
        log "Processing DEL for interface $CNI_IFNAME"
        cat << EOF
{
   "cniVersion": "0.3.1"
}
EOF
        ;;
    *)
        log "Unsupported CNI command: $CNI_COMMAND"
        exit 1
        ;;
esac
exit 0

Bước 8: Triển khai NetworkAttachmentDefinition cho giao tiếp Multicast

Tệp YAML định nghĩa NetworkAttachmentDefinition được hiển thị như sau:

apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
      name: hostdevice-multicast-network
      namespace: kube-system
spec:
    config: '
    {
        "cniVersion": "0.3.1",
        "type": "host-device",
        "device": "eth1",
        "ipam": {
           "type": "{ipam_filename}"
        }
    }'

ipam_filename ở đây phải giống với ipam_filename nằm trong /opt/cni/bin/ trên node.

Chúng tôi sử dụng lệnh sau để triển khai NetworkAttachmentDefinition:

kubectl apply -f {NetworkAttachmentDefinition_filepath}

Bước 9: Tạo các pod cho giao tiếp multicast

Trong tệp định nghĩa pod, đặt thuộc tính k8s.v1.cni.cncf.io/networks dưới metadata.annotations thành tên của NetworkAttachmentDefinition ở trên. Điều này cho phép pod hỗ trợ giao tiếp multicast.

Tham chiếu đến phần chính của tệp YAML được hiển thị như sau:

apiVersion: v1
kind: Pod
metadata:
      name: multitool-with-iperf-muti01
      annotations:
            k8s.v1.cni.cncf.io/networks: {hostdevice-multicast-network}
      labels:
            app: multitool-with-iperf-muti01
spec:
  …

Tại thời điểm này, cụm EKS có khả năng giao tiếp multicast giữa các pod cũng như giữa các pod và máy ảo (VM).

Minh họa hoạt động multicast

Bây giờ chúng ta có thể tạo các pod và kiểm thử lưu lượng multicast giữa các pod này:

Bước 1: Tạo ba pod để kiểm thử

Tạo ba pod hỗ trợ multicast để kiểm thử. Phần cốt lõi của tệp định nghĩa pod kiểm thử như sau:

spec:
    …
    containers:
    - name: multitool
      image: praqma/network-multitool
      command: ["/bin/bash"]
      args:
      - "-c"
      - "apk update && apk add iperf && /usr/sbin/nginx -g 'daemon off;' & while true; do sleep 3600; done"
…

Bước 2: Kiểm thử lưu lượng multicast giữa ba pod

Chúng tôi sử dụng pod3 để gửi các gói UDP đến địa chỉ multicast 224.0.0.13 thông qua giao diện mạng multicast, sử dụng lệnh sau:

iperf -B 10.9.1.40 -c 224.0.0.13 -u --ttl 5 -t 3600 -b10M

Trên pod1 và pod2, chúng tôi sử dụng lệnh sau để hướng dẫn giao diện mạng multicast nhận các gói UDP multicast từ địa chỉ multicast 224.0.0.13:

iperf -s -u -B 224.0.0.13%net1 -i 1

Kết quả được hiển thị trong Hình 6, nơi pod1 và pod2 nhận thành công các gói multicast.


Hình 6: pod1 và pod2 nhận thành công các gói multicast

Tại thời điểm này, bằng cách kiểm tra bảng điều khiển multicast domain của Transit Gateway, chúng ta có thể thấy thông tin hoạt động của nhóm multicast (224.0.0.13), như trong Hình 7.


Hình 7: Thông tin nhóm multicast hiển thị trong Transit Gateway

Tiếp theo, chúng tôi khởi chạy một phiên bản EC2 trong subnet multicast và yêu cầu nó gửi lưu lượng multicast đến nhóm multicast 224.0.0.13. Sau đó, chúng ta có thể quan sát thấy rằng pod1, pod2 và pod3 đều nhận thành công lưu lượng multicast, như trong Hình 8.


Hình 8: pod1, pod2 và pod3 đều nhận thành công lưu lượng multicast được gửi từ phiên bản EC2 mới

Kết quả

Trong giai đoạn kiểm thử giải pháp này, độ trễ mạng trung bình sử dụng hping3 (chế độ TCP) trong cùng một Availability Zone là 6 ms (vì lưu lượng unicast của hệ thống giao dịch được truyền qua TCP). Ngược lại, độ trễ mạng trung bình sử dụng mping cho lưu lượng multicast trong cùng một Availability Zone là 0,4 ms—đại diện cho mức tăng độ trễ hơn 15 lần đối với lưu lượng unicast dựa trên TCP. Mặc dù quá trình xử lý hệ thống giao dịch sản xuất thực tế phức tạp hơn và đường dẫn dài hơn, các thành phần của hệ thống giao dịch sử dụng giao tiếp multicast vẫn đạt được cải thiện độ trễ hơn 10 lần.

Giới hạn của Multicast

Tính năng multicast của Transit Gateway phù hợp nhất cho các ứng dụng multicast chung trong ngành tài chính và có thể không phù hợp cho giao dịch tần số cao hoặc khối lượng công việc hiệu suất cao. Hãy tham khảo ý kiến đại diện AWS của bạn để xác định sự phù hợp với các yêu cầu hiệu suất cụ thể của bạn.

Chúng tôi khuyên bạn nên xem lại phần Multicast của tài liệu Transit Gateway Quotas và lập kế hoạch triển khai của bạn cho phù hợp.

Kết luận

Trong bài viết này, chúng tôi giới thiệu một giải pháp giao tiếp multicast cho Amazon EKS, được xây dựng trên AWS Transit Gateway, cung cấp khả năng multicast cho các cụm EKS bằng cách thêm các ENI bổ sung, mà không ảnh hưởng đến plugin Amazon VPC CNI. Giải pháp này loại bỏ các trở ngại cho Huatai Securities trong việc triển khai các hệ thống giao dịch cốt lõi được container hóa của họ trên AWS. Hơn nữa, nó cung cấp những hiểu biết có giá trị cho những người dùng khác cần khả năng multicast trong các kịch bản mà VPC CNI là plugin mạng chính. Giải pháp này mang lại lợi ích đáng kể cho Huatai Securities bằng cách giảm mức sử dụng băng thông và cải thiện độ trễ gấp 10 lần cho các hoạt động giao dịch của họ. Hãy thử giải pháp của chúng tôi để cải thiện hiệu quả xử lý mạng của hệ thống của bạn, hoặc đọc tính năng multicast của Transit Gateway để xây dựng giải pháp của riêng bạn.

Về tác giả


Kevin Liu
Kevin Liu, Chuyên gia Mạng cấp cao tại Amazon Web Services Trung Quốc. Chịu trách nhiệm tư vấn và thiết kế kiến trúc giải pháp mạng điện toán đám mây dựa trên AWS. Hiện đang chuyên tâm nghiên cứu trong các lĩnh vực mạng và Network-as-a-Service.


Baoliang Cui
Baoliang Cui là kiến trúc sư giải pháp FSI tại AWS với 15 năm kinh nghiệm phát triển phần mềm và 5 năm làm kiến trúc sư. Anh đã tham gia vào hai công ty khởi nghiệp điện toán đám mây và hiện đang phục vụ các công ty chứng khoán hàng đầu tại FSI. Anh đam mê các phương pháp chăm sóc sức khỏe truyền thống của Trung Quốc và các nghi lễ trà đạo.


Zhonghai Hu
Zhonghai Hu, Kiến trúc sư, Ủy ban Kiến trúc, Huatai Securities


Ricky Chu
Ricky Chu, Giám đốc Dự án Hạ tầng, Phòng IT, Huatai Financial Holdings (Hồng Kông).

TAGS: AWS Transit Gateway, Multicast

←
→

Leave a comment