Giới thiệu

Trong kỷ nguyên ngân hàng số, độ tin cậy và khả năng phục hồi là hai yếu tố không thể thương lượng. Một phút gián đoạn có thể gây thiệt hại lớn về tài chính và niềm tin khách hàng. Đây là lý do Chaos Engineering (Kỹ thuật hỗn loạn) ngày càng được áp dụng rộng rãi để chủ động phát hiện điểm yếu và nâng cao tính ổn định của hệ thống.

Chaos Engineering là gì?

Chaos Engineering là thực tiễn chủ động đưa các lỗi có kiểm soát vào hệ thống để kiểm tra khả năng phục hồi và phát hiện vấn đề tiềm ẩn trước khi chúng ảnh hưởng đến người dùng.
Nguyên tắc cốt lõi của phương pháp này là giả thuyết trạng thái ổn định: xác định những hành vi “bình thường” của hệ thống (thời gian phản hồi, tỷ lệ lỗi, thông lượng) và kiểm tra xem liệu hệ thống có duy trì được các hành vi đó khi gặp sự cố hay không.

Ví dụ, trong môi trường ngân hàng, hệ thống cần chịu được:

  • Lỗi hạ tầng: EC2 hoặc Availability Zone (AZ) gặp sự cố.
  • Lỗi ứng dụng: độ trễ API, rò rỉ kết nối cơ sở dữ liệu.
  • Cạn kiệt tài nguyên: CPU/memory tăng đột biến, mạng bị bão hòa.

Nếu không kiểm tra chủ động, những vấn đề này có thể dẫn đến ngừng dịch vụ trong giờ cao điểm, gây hậu quả nghiêm trọng.

AWS Fault Injection Simulator (FIS)

Đối với workload ngân hàng trên AWS, công cụ AWS Fault Injection Simulator (FIS) mang đến một nền tảng được quản lý hoàn toàn, tuân thủ quy định, cho phép mô phỏng các lỗi trong thế giới thực mà vẫn giảm thiểu chi phí vận hành.

Điểm mạnh của FIS:

  • Mô phỏng sự cố hạ tầng, ứng dụng, mạng trong môi trường non-prod.
  • Tích hợp với CloudWatch để giám sát và thiết lập điều kiện dừng.
  • Hỗ trợ thiết kế kịch bản lỗi có thể lặp lại và kiểm soát chặt chẽ.

Quy trình thiết kế thí nghiệm hỗn loạn

Một thí nghiệm hỗn loạn hiệu quả thường trải qua 5 bước chính:

  1. Xác định phạm vi: chọn thành phần quan trọng (ví dụ: xử lý thanh toán, quản lý tài khoản).
  2. Xác định giả thuyết trạng thái ổn định: thiết lập KPI (API success > 99.9%, latency < 500ms).
  3. Tiêm lỗi có kiểm soát: chấm dứt EC2, điều tiết mạng, cạn kiệt tài nguyên.
  4. Quan sát: theo dõi logs, metrics, traces từ tài khoản giám sát.
  5. Phân tích: xác định cơ chế phục hồi, điều chỉnh thiết kế hệ thống.

Ví dụ triển khai FIS

1. Tạo IAM Role và Policy

Trong tài khoản workload non-prod:

# workload-nonprod/dev/iam.tf
resource "aws_iam_role" "fis_experiment_role" {
  name = "fis-experiment-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [{
      Effect = "Allow",
      Principal = {
        AWS = "arn:aws:iam::OPERATION_NONPROD_ACCOUNT_ID:root"
      },
      Action = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_policy" "fis_ec2_termination" {
  name = "fis-ec2-termination"
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [{
      Effect   = "Allow",
      Action   = ["ec2:TerminateInstances"],
      Resource = "*",
      Condition = {
        StringEquals = { "aws:ResourceTag/Environment" = "nonprod" }
      }
    }]
  })
}

Cấp quyền cho tài khoản non-prod để đảm nhận vai trò này thông qua IAM:

# operation-nonprod/dev/iam.tf
resource "aws_iam_policy" "fis_execution" {
  name = "fis-execution-policy"
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [{
      Effect   = "Allow",
      Action   = ["fis:StartExperiment", "sts:AssumeRole"],
      Resource = [
        "arn:aws:fis:*:*:experiment-template/*",
        "arn:aws:iam::WORKLOAD_NONPROD_ACCOUNT_ID:role/fis-experiment-role"
      ]
    }]
  })
}

2. Định nghĩa FIS Experiment Template

Ví dụ mô phỏng chấm dứt EC2 backend:

resource "aws_fis_experiment_template" "terminate_ec2" {
  description = "Terminate EC2 backend in Non-Prod"
  role_arn    = "arn:aws:iam::WORKLOAD_NONPROD_ACCOUNT_ID:role/fis-experiment-role"

  action {
    name      = "ec2-termination"
    action_id = "aws:ec2:terminate-instances"
    parameter {
      key   = "durationInMinutes"
      value = "PT5M"
    }
    target {
      key   = "Instances"
      value = "banking-backend-target"
    }
  }

  target {
    name           = "banking-backend-target"
    resource_type  = "aws:ec2:instance"
    selection_mode = "ALL"
    filter {
      path   = "tag:Environment"
      values = ["nonprod"]
    }
    filter {
      path   = "tag:Application"
      values = ["backend"]
    }
  }

  stop_condition {
    source = "aws:cloudwatch:alarm"
    value  = "arn:aws:cloudwatch:us-east-1:WORKLOAD_NONPROD_ACCOUNT_ID:alarm:High-ErrorRate"
  }
}

3. Chạy Fault Injection Simulator

aws fis start-experiment \
  --experiment-template-id ${FIS_TEMPLATE_ID} \
  --client-token $(uuidgen) \
  --region us-east-1

Khi AWS Fault Injection Simulator kết thúc EC2, bạn có thể xác minh hệ thống vẫn hoạt động bình thường. Bạn có thể sử dụng cronjob để kích hoạt mỗi giờ.

Xác thực bằng Công cụ quan sát

  • Nhật ký tập trung : Truyền nhật ký FIS đến Tài khoản quan sát thông qua Nhật ký CloudWatch.
  • Số liệu : Theo dõi tình trạng hoạt động của phiên bản EC2 và các sự kiện tự động mở rộng trong Amazon Managed Grafana.
  • Cảnh báo : Kích hoạt thông báo SNS nếu quá trình khôi phục mất nhiều thời gian hơn dự kiến.

Chấm dứt phiên bản EC2

Giả thuyết: việc chấm dứt các phiên bản backend sẽ kích hoạt Karpenter thay thế các nút.

Cấu hình FIS:

  • Mục tiêu: Các phiên bản EC2 được gắn thẻ Application=backendvà Environment=nonprod.
  • Điều kiện dừng: Dừng thử nghiệm nếu Tài khoản quan sát phát hiện tỷ lệ lỗi > 5%.

Mô phỏng lỗi AZ

Giả thuyết: các ứng dụng vẫn khả dụng nếu Vùng khả dụng bị lỗi.

Hành động của FIS:

  • Sử dụng aws:ec2:stop-instancesđể tắt tất cả các phiên bản trong us-east-1a.
  • Xác thực phân phối nhóm EKS trên nhiều vùng sẵn sàng và chuyển đổi dự phòng RDS Multi-AZ.

Kết nối mạng bị gián đoạn (chỉ sử dụng cho mục đích không phải sản xuất)

Giả thuyết: từ chối lưu lượng truy cập được chỉ định đến các mạng con đích. Sử dụng ACL mạng.

Hành động của FIS:

  • Sử dụng aws:network:disrupt-connectivity.
  • Hệ thống Validate có thể chạy khi gặp sự cố bất ngờ (chỉ sử dụng cho mục đích không phải sản xuất).

Thực hành tốt nhất cho khối lượng công việc ngân hàng

  1. Nhắm mục tiêu dựa trên thẻ : Hạn chế thử nghiệm bằng các thẻ như ChaosInjection=allowed.
  2. Hoàn nguyên tự động : Cấu hình điều kiện dừng FIS để dừng thử nghiệm nếu cảnh báo CloudWatch kích hoạt.
  3. Ghi nhật ký tập trung : Truyền nhật ký thử nghiệm FIS vào thùng S3 của Tài khoản quan sát.

Trong bài tiếp theo, chúng ta sẽ khám phá các Thực hành trực ban cho Hệ thống ngân hàng, bao gồm sổ tay hướng dẫn ứng phó sự cố, cảnh báo với Versus Incident và tích hợp với AWS CloudWatch.

Trích: Quân Huỳnh – Cloud Engineer, Tác giả trang devopsvn.tech

Leave a Reply

This site uses cookies to offer you a better browsing experience. By browsing this website, you agree to our use of cookies.