Elasticsearch Bài học 41: ILM (Index Lifecycle Management) - Tự động xoay vòng và xóa Index theo thời gian

Khi vận hành hệ thống Automatic Fare Collection (AFC) cho Metro Line 1, với hàng triệu lượt quẹt thẻ mỗi ngày, lượng log đổ về Elasticsearch là khổng lồ.

Nếu bạn nhét tất cả vào một Index duy nhất tên là afc_logs, Index này sẽ nhanh chóng phình to lên hàng Terabyte. Các Shard sẽ vượt quá ngưỡng an toàn 50GB (đã học ở Bài 7), dẫn đến tốc độ ghi chậm dần và nguy cơ sập Node rất cao. Thêm vào đó, ổ cứng của server không phải là vô hạn. Những log cách đây 1 năm có thể không còn giá trị và cần được xóa đi để giải phóng dung lượng.

Thay vì phải tự viết cronjob (bằng PHP hoặc Golang) để tạo Index mới mỗi ngày và gửi lệnh DELETE các Index cũ, Elasticsearch cung cấp một cỗ máy tự động hóa hoàn hảo: ILM (Index Lifecycle Management).

1. Bản chất của ILM: Rollover (Xoay vòng)

ILM giải quyết bài toán dung lượng bằng cơ chế Rollover.

Hệ thống API Backend của bạn không ghi trực tiếp vào một Index cố định, mà ghi vào một Alias (Bí danh) tên là afc_logs_write. Phía sau Alias này, ILM sẽ âm thầm quản lý các Index được đánh số tuần tự: afc_logs-000001.

Khi afc_logs-000001 đạt đến một giới hạn nhất định (Ví dụ: Đạt 50GB hoặc đủ 30 ngày tuổi), ILM sẽ tự động:

1. Tạo một Index mới tinh tên là afc_logs-000002.

2. Trỏ Alias afc_logs_write sang Index mới. Mọi log mới từ Backend sẽ tự động chảy vào Index số 2.

3. Chuyển Index số 1 sang trạng thái "nghỉ ngơi" (chỉ đọc).

Tất cả quá trình này diễn ra với Zero-downtime, code Backend của bạn không cần thay đổi bất cứ dòng nào.

2. 4 Giai đoạn vòng đời (Phases) của ILM

Một Index trong Elasticsearch có thể trải qua 4 giai đoạn sinh lão bệnh tử:

1. Hot (Đang ghi): Index đang liên tục nhận dữ liệu mới. Yêu cầu tốc độ ghi (I/O) cực cao.

2. Warm (Ấm): Index không còn nhận dữ liệu mới nữa, chỉ dùng để tìm kiếm (read-only).

3. Cold / Frozen (Lạnh / Đóng băng): Dữ liệu cũ, ít khi bị truy vấn. Có thể bị nén lại để tiết kiệm ổ cứng. Tốc độ tìm kiếm chậm.

4. Delete (Xóa): Vòng đời kết thúc, Index tự động bị xóa khỏi ổ đĩa để tiết kiệm tiền mua server.

3. Thực hành: Viết ILM Policy bảo vệ hệ thống Log

Hãy định nghĩa một chính sách (Policy) quy định:

• "Rollover sang Index mới khi Index hiện tại đạt 50GB hoặc đủ 30 ngày. Xóa hoàn toàn các Index cũ hơn 90 ngày."

Vào Kibana Dev Tools, tạo ILM Policy tên là afc_log_policy:

JSON

PUT _ilm/policy/afc_log_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "50gb",
            "max_age": "30d"
          }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

(Tham số min_age: 90d trong giai đoạn delete được tính từ khoảnh khắc Index đó thực hiện Rollover, chứ không phải từ lúc nó sinh ra).

4. Gắn ILM Policy vào Dữ liệu (Index Template)

Tạo xong Policy, bạn phải "kết duyên" nó với dữ liệu bằng cách sử dụng Index Template. Bất cứ Index nào có tên bắt đầu bằng afc_logs- khi sinh ra sẽ tự động bị áp dụng Policy này.

JSON

PUT _index_template/afc_logs_template
{
  "index_patterns": ["afc_logs-*"],                 // Bắt tất cả index có tiền tố này
  "template": {
    "settings": {
      "index.lifecycle.name": "afc_log_policy",     // Tên policy vừa tạo ở Bước 3
      "index.lifecycle.rollover_alias": "afc_logs_write" // Tên Alias dùng để ghi
    }
  }
}

5. Kích nổ hệ thống: Bootstrap Index đầu tiên

Để chu trình ILM bắt đầu chạy, bạn phải tự tay tạo (Bootstrap) Index số 1 và gắn Alias cho nó ở lần đầu tiên duy nhất. Từ Index số 2 trở đi, ILM sẽ tự động làm.

JSON

PUT afc_logs-000001
{
  "aliases": {
    "afc_logs_write": {
      "is_write_index": true // Báo cho Elasticsearch biết đây là đích đến của lệnh POST
    }
  }
}

Từ bây giờ, trong code Golang của dự án AFC, bạn chỉ cần cấu hình endpoint ghi log là:

JSON

POST afc_logs_write/_doc
{
  "card_id": "CARD-999",
  "station": "Ben Thanh",
  "status": "IN"
}

Hệ thống của bạn đã chính thức bước vào chế độ "Tự trị" (Autopilot). Ổ cứng sẽ không bao giờ bị đầy, và các Shard sẽ luôn duy trì ở dung lượng lý tưởng (Dưới 50GB) giúp tốc độ tìm kiếm và ghi luôn đạt đỉnh.

Một khi bạn đã phân tách được dữ liệu thành các cục Hot (Mới nhất) và Warm/Delete (Đã cũ), bạn sẽ nhận ra một sự lãng phí rất lớn về phần cứng: Tại sao chúng ta lại lưu trữ những cái log 3 tháng tuổi trên cùng ổ cứng SSD siêu tốc đắt đỏ với những log của ngày hôm nay?

Đó là tiền đề để ra đời một kiến trúc phần cứng đẳng cấp Enterprise: Kiến trúc Data Tiers.