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

• Ngoài ra các bạn có thể tham khảo thêm ở các link dưới đây
  • https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-dedicatedmasternodes.html
  • https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/cloudwatch-alarms.html

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

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

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

• Bài viết liên quan:
  Chương 1: Kiến trúc tổng quan của Amazon ES
  Chương 2: Sizing Amazon ES
  Chương 3: Backup và Monitoring ES
  Chương 4: Một vài chia sẻ từ kinh nghiệm thực tế