Lời nói đầu:
-
Chào các bạn, mình là Duy Nam – Thành viên Group 1 VTI Japan.
-
Việc sử dụng Elasticseach đã không còn quá xa lạ với các bạn làm về solution architect nữa. Nhờ ưu việt vượt trội với khả năng full text seach cũng như search speed mà Elasticseach được áp dụng cho việc phân tích data, đem lại các lợi thế trong business
-
Tuy nhiên, cái gì hiện đại thì đều hại điện cả, ngoài việc thiết kế data của Elasticseach, việc thiết kế kiến trúc của một cụm ES cũng phải cẩn trọng hơn.
-
Việc thiết kế đơn giản sẽ ảnh hưởng hậu quả sau này như phải tạo lại Index hay tạo lại Domain mới của Elasticseach vậy. Khi business đang chạy, chắc chúng ta đều không mong muốn điều đó. Chính vì vậy hôm nay mình xin được chia sẻ kiến trúc Best Practice của Amazon Elasticsearch (ES)
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 1: Kiến trúc tổng quan của Amazon ES
1.1 Kiến trúc tổng quan của Amazon ES
- Elasticseach Cluster sẽ được bao gồm một cụm các máy chủ bao gồm Master Node và Data Node. Các bạn có thể xem như hình dưới đây:
1.2 Giới thiệu Elasticseach Domain:
- Tại ES, người ta gọi cụm các node là Domain
- Sau khi tạo Domain của ES, chúng ta vẫn có thể tiến hành thêm node mới, thay đổi node type hay tăng thêm dung lượng lưu trữ của ES
1.3 Master Node và Dedicated Master Node:
- Tại Master Node của ES sẽ có 2 kiểu chính là Master Node và Dedicated Master Node
Dedicated Master Node chúng ta hiểu như là một node dự bị vậy, việc gọi health check giữa các Master Node để phát hiện Master có vấn đề gì không? Nếu có chúng sẽ tiến hành bầu ra Master Node mới. - Trường hợp chỉ có 2 Master Node (1 Master và 1 Dedicated Master): Nếu Master Node chết, Dedicated Master sẽ không call được sang Node Master khác, cơ chế này của ES đồng nghĩa với việc không thể Promote Dedicated lên thành Master Node được
- Nếu không thể bầu ra được Master Node thì việc thành lập ES Cluster sẽ bị mất đi, chúng ta hiểu là ES Cluster sẽ bị chết
- Để phòng tránh trở ngại liên quan đến AZ, việc chia 3 Master Node cho 3 AZ là AWS Best Practive
1.4 Data Nodes:
- Là nơi lưu trữ dữ liệu Index của ES
- Được access khi tiến hành việc tìm kiếm , sửa xóa dữ liệu trong ES từ phía client
- Amazon ES support lên tới 200 data node để lưu trữ dữ liệu
- Tại môi trường product AWS khuyến khích tăng High Avairibiiry bằng việc chia 3 Data Node và chia đều 3 Availability Zone (AZ)
- Đối với môi trường develop để giảm chi phí của ES chúng ta có thể chọn 1 Master Node và 1 Data Node là OK
- Một lưu ý là ES Domain không thể Stop được giống như là Database (RDS) nên sau khi đã tạo ra là các bạn để nó chạy luôn à
1.5 Shard:
- Là một đơn vị lưu trữ dữ liệu Index sau khi được phân chia
- Chúng ta có thể set Replica cho các shard, 1 shard có thể có nhiều Replica
- Nếu setting số lượng Replicas là 0, trường hợp 1 Data Node gặp trở ngại sẽ dẫn đến mất data index
- Nếu Data Node được chia đều cho các AZ thì Replica sẽ tự động phân chia ra các AZ
- Một điểm quan trong trong thiết kế Index của ES chính là Shard sẽ không sửa được sau khi tạo Index. Chính vì điều này chúng ta cần phải Sizing Shard một cách cẩn thận. Việc Sizing Shard mình sẽ nói ở chương sau
1.6 Lựa chọn Master Node và Data Node riêng biệt:
- Master Node và Data Node có khả năng dùng chung một loại instance. Tuy nhiên nếu tải của Data Node cao do việc tìm kiếm hay ghi data sẽ dẫn đến hoạt động của Master Node cũng sẽ bất ổn định.
- Chính vì điều này, việc sizing riêng biệt Master Node và Data Node là một Best Practive
1.7 Nâng cao Security cho ES:
- Để nâng cao vấn đề về Security, việc đặt ES vào trong VPC là một Best Practice
- Khi đặt ES vào trong VPC, AWS sẽ tự tạo các VPC Endpoint để các resource trong VPC có thể connect đến ES
- Có một lưu ý khi đặt ES vào trong VPC, đó chính là số lượng IP sử dụng của ES sẽ gấp 3 lần số lượng Data Node. Số lượng ENI này sử dụng cho mục đích Blue/Green deploy của ES khi tiến hành update version hay thay đổi ES
- Blue-Green deploy chính là một ưu điểm của Elasticseach, việc sử dụng Blue-Green deploy sẽ làm ES Service không bị down trong quá trình update sửa đổi -> tuyệt quá phải không nào
Lời kết 1
- Vừa rồi mình vừa chia sẻ về Kiến trúc tổng quan của Amazon ES. Chương tiếp theo mình sẽ hướng dẫn các bạn sao để Sizing Elasticseach cho hiệu quả nhé.
Leave a Reply