Amazon Elasticsearch Service Best Practice – Sizing

Lời nói đầu:

  • Chào các bạn, mình là Duy Nam – Thành viên Group 1 VTI Japan. Hôm nay mình xin tiếp tục seri về Amazon Elasticsearch Service Best Practice.

Bài viết của mình chia ra làm 4 chương chính:

Chương 1: Kiến trúc tổng quan của Amazon ES

  • Kiến trúc tổng quan của Amazon ES
  • Giới thiệu vai trò của Master Node, Data Node, Shard
  • Lưu ý khi đặt Amazon ES vào trong VPC

Chương 2: Sizing Amazon ES

  • Tính toán dữ liệu đưa vào Amazon ES
  • Tính toán số Shard cần thiết cho Amazon ES
  • Lựa chọn instance type phù hợp cho Master Node và Data Node

Chương 3: Backup và Monitoring ES

  • Giới thiệu vai trò của Automated Backup và Manual Backup
  • Restore Data của Amazon ES, Migration Data từ Elasticseach on EC2
  • Giới thiệu các Metric cần theo dõi của Amazon ES

Chương 4: Một vài chia sẻ từ kinh nghiệm thực tế

  • Giới thiệu về Index, Document, Type
  • Một vài những câu query cơ bản của Elasticseach
  • Một vài option khác gặp trong thực tế

Chương 2: Sizing Amazon ES

  • Trong bất kỳ hệ thống nào các bạn đều sẽ phải tiến hành việc sizing Server. Có nhiều quan điểm trong vấn đề sizing, từ lượng dữ liệu lưu trữ, lượng connection đồng thời ...
  • Đối với Amazon ES cũng không ngoài phạm vi đó, có những quan điểm cho việc Sizing. Mình xin phép chia sẻ dưới đây.
  • Việc Sizing sẽ chia làm 2 bước: Sizing Storage và Sizing Performance

2.1 Các kiểu Index cơ bản:

2.1.1 Loại Index lưu lâu dài:

  • Được sử dụng với mục đích tìm kiếm
  • Source Data được lưu toàn bộ trong cùng Index

2.1.2 Index Loading:

  • Được sử dụng với mục đích phân tích Logs
  • Tại một khoảng thời gian như là hàng ngày, hàng tuần sẽ tạo thay thế Index mới
  • Với những Index cũ sẽ tiến hành giảm số lượng Replica hay xóa bỏ

2.2 Tính toán lượng storage của ES

  • Lượng lưu trữ của ES sẽ theo công thức dưới đây:
    Minimum Storage = 
     Source Data x 
     (1 + Number of Replicas) x 
     (1 + Indexing Overhead) ÷
     (1 - Linux Reserved Space) ÷
     (1 - Amazon ES Overhead) 

Source Data:

  • Về quan điểm Sizing Source Data có 2 quan điểm dưới đây:
    • Point 1: Sizing lượng data phù hợp với mục đích sử dụng.
    • Point 2: Suy tính đến khả năng dữ liệu tăng lên trong tương lai.
  • Source Data tùy vào dự án thực tế các bạn hãy đánh giá cho phù hợp nhé. Trong trường hợp không có căn cứ chúng ta có thể tiến hành test data ở môi trường develop để lấy căn cứ đánh giá thực tế

Number of Replicas:

  • Nếu tăng số lượng Replica thì đồng nghĩa với việc Copy dữ liệu của Primary Shard và được lưu tại Data Node khác
  • Việc này sẽ làm tăng Availability và Durability của Data, trường hợp với workload nặng thì hiệu suất tìm kiếm cũng được tăng lên do việc search sẽ được chia điều ra trong các Data Node
  • Tùy vào tình hình thực tế mà chọn số Replica của ES, tuy nhiên để phòng tránh việc mất Data tối thiểu chúng ta nên chọn 1 bản Replica

Indexing Overhead:

  • Mặc dù index size phụ thuộc vào đặc tính của data nhưng một cách tổng quan, index size sẽ lớn hơn khoảng 10% lượng data cho vào
  • Trường hợp đã có Source Data trước đó, chúng ta cũng có thể tiến hành đo đạc một cách thực tế dựa trên API _cat/indices
  • pri.store.size chính là lượng data thực tế đã lưu vào Amazon ES và cũng chính là Size của Index

Linux Reserved Space & Amazon ES Overhead:

Linux Reserved Space

  • Chiếm khoảng 5% dung lượng lưu trữ thực tế
  • Chính là Space để phục hồi hệ thống hay các process quan trọng của root user

Amazon ES Overhead

  • Với mỗi Node sẽ chiểm khoảng 20% lượng lưu trữ (Tối đa 20GB)
  • Các hoạt động nội bộ của ES như là Nơi tiến hành hợp nhất dữ liệu,lưu trữ log
    • Vd1: Trường hợp 500GB/Node x 3 Node: MIN(20GB, 500GB x 0.2) x 3 = 60GB
    • Vd2: Trường hợp 50GB/Node x 30 Node: MIN(20GB, 50GB x 0.2) x 30 = 300GB

Ví dụ về việc sizing lượng dữ liệu:

  • Trong 1 ngày thêm 30Gb log và được lưu trong 2 tuần. Để nâng cao High Avaibility sẽ set 2 Replica. Tính toán với mỗi Node sẽ lưu trữ khoảng 80 GB
  • Công thức:
    Minimum Storage = 
     Source Data x 
     (1 + Number of Replicas) x 
     (1 + Indexing Overhead) ÷
     (1 - Linux Reserved Space) ÷
     (1 - Amazon ES Overhead) 
  • Kết quả sizing:
    Minimum Storage = 
    (30 x 14) x
    (1 + 2) x 
    (1 + 0.1) ÷ 
    (1 – 0.05) ÷
    (1 – 0.2)
    = 1823.7GB

2.3 Sizing peformance cho Amazon ES

2.3.1 Chọn số Shard cho Elasticseach:

  • Shard là vùng chứa dữ liệu của Index
  • Số Shard – Sau khi tạo Index sẽ không thay đổi được nên cần phải tiến hành sizing trước
  • Việc quản lý shard cũng sẽ tốn tài nguyên như CPU hay Memory, nên không nên tạo nhiều shard với lượng dữ liệu nhỏ trong đó.
  • Trường hợp cần tăng số lượng shard chúng ta tiến hành tạo lại Index
  • Về tổng quan, 1 Shard được khuyến khích thiết kế cho vùng chứa khoảng từ 10-50GB dữ liệu là tốt nhất. Thông thường mình hay seting với giá trị 30GB
  • Công thức tính Shard sẽ như dưới đây:
    • Số Primary Shard = (Source Data + Phần dư) x (1 + Indexing Overhead) ÷ Shard Size
    • Phần dư: ví dụ 1 ngày đẩy khoảng 20GB data, tuy nhiên ngày cao điểm đẩy đến 25GB thì phần dư các bạn có thể để là 5GB. Các bạn không set phần này cũng OK

Ví dụ việc tính toán Shard:

  • Trong 1 ngày thêm 30Gb log và được lưu trong 2 tuần. Sau này hệ thống sẽ được mở rộng quy mô, lượng log lớn nhất sẽ tăng thêm 20% trong 1 ngày. Giả sử Shard Size lấy giá trị 30GB
  • Công thức:
    • Số Primary Shard = (Source Data + Phần dư) x (1 + Indexing Overhead) ÷ Shard Size
  • Kết quả sizing:
    • Số PrimaryShard= (30GB x 14 + 30GB x 14 x 0.2) x (1 + 0.1) ÷ 30GB = 18.48 → 19 Shard
  • Trường hợp không tính đến phần dư:
    • Số PrimaryShard= (30GB x 14) x (1 + 0.1) ÷ 30GB = 15.4 → 16 Shard
    • Do mình để 1 shard là 30GB data nên để 16 shard cũng ko ảnh hưởng đến performance nhé.

2.3.2 Việc lựa chọn Instance Type của Elasticseach

Lựa chọn Master Node Instance:

  • Master Node Chuyên dụng sẽ tiến hành quản lý resource cho cụm ES. Tùy vào quy mô của dự án mà lượng Master Node cũng sẽ được tăng lên
  • Ở phần sau mình sẽ nói đến khi nào cần tăng instance type ứng với metric của CloudWatch Metrics (Chương Monitoring)
  • Instance dòng T (bursting) không được khuyến khích cho môi trường Product
  • Việc sizing một cách tổng quát sẽ theo bảng bên dưới
Số Data Node Số Shard lớn nhất Khuyến khích Instance Type
1 - 10 2500 c5.large.elasticsearch
10 - 30 5000 c5.xlarge.elasticsearch
30 - 75 10000 c5.2xlarge.elasticsearch
75 - 200 30000 c5.4xlarge.elasticsearch

Lựa chọn Data Node Instance:

  • Tại Amazon ES , Đối với từng kiểu Instance đã bị giới hạn size của EBS. Tuy nhiên dung lượng lưu trữ tối đa cho 1 instance khá lớn.
  • Cũng giống với Master Node chúng ta không nên chọ dòng T (bursting) cho môi trường Product
  • AWS có khuyến khích với mỗi 1 GB Heap Memory của Data Node sẽ dành cho tối đa 20 Shard
  • Mặc dù đã tiến hành Sizing Data Node, chúng ta vẫn cần tiến hành Test Performance cho ES
  • Việc sizing một cách tổng quát sẽ theo bảng bên dưới
- Workload thông thường Workload có tải cao
Use case - Tốc độ đọc thấp cũng OK
- Tải của query tìm kiếm thấp
Thường xuyên thêm hoặc thay đổi Document
Có những câu query có tải lớn
Cấu trúc Cluster nên dùng Mỗi Active Shard sẽ gắn 1vCPU 100GB Storage sẽ gắn 2vCPU và 2GB Memory

Ví dụ của việc Sizing:

Quy mô Data Size (theo ngày) Storate cần thiết(lưu trong 1 tuần) Số Shard active(lớn nhất) Tổng số Shard(lớn nhất) Instance của data node và master node
Xsmall 〜10 GB 177 GB 4 300 2x M4/R4.large data
3x m3.medium masters
Small 10〜100 GB 1.7 TB 8 600 4x M4/R4.xlarge data
3x m3.medium masters
Medium 100〜500 GB 8.5 TB 30 3000 6x I3.2xlarge data
3x C4.large masters
Large 0.5〜1 TB 17.7 TB 60 3000 6x I3.4xlarge data
3x C4.large masters
Xlarge 1〜10 TB 177.1 TB 600 5000 30x I3.8xlarge data
3x C4.2xlarge masters
Huge 10〜80 TB 1.288 PB 3400 25000 85x I3.16xlarge data
3x C4.4xlarge masters

Lời Kết 2

  • Vừa rồi mình vừa chia sẻ về việc Sizing của Amazon ES. Khá là khó và phức tạp đúng không nào? Các bạn cứ lưu trước lại sau dự án thực thì lôi ra mà tính toán cũng ok nhé!
  • Chương tiếp theo mình sẽ hướng dẫn các bạn sao để Monitoring và Backup Elasticseach cho hiệu quả nhé.

See you soon

Leave a Reply