ในการพัฒนาและให้บริการเกมส์ เราสามารถจัดการข้อมูลได้หลายวิธี โดยเฉพาะอย่างยิ่งเกมส์ที่มีผู้ใช้บริการจำนวนมาก การจัดการกับข้อมูลจึงต้องมีประสิทธิภาพและรวดเร็ว, ELK System คืออีกระบบหนึ่งที่หลายเกมส์เลือกใช้
ELK Stack ประกอบด้วย Elasticsearch, Logstash และ Kibana ซึ่งเป็น Open Source ที่พัฒนาโดย Elastic และทั้งสาม product นี้ทำงานร่วมกันอย่างมีประสิทธิภาพ
Elasticsearch เป็นระบบการจัดการข้อมูล ที่สามารถค้นหา , วิเคราะห์, และเก็บข้อมูลต่างๆ ที่เกิดขึ้นเป็น Log search tools ที่้สามารถเข้าถึงข้อมูลแบบ real-time
Logstash คือเครื่องมือในการรวบรวม และแปลงข้อมูล โดยจะประกอบไปด้วย Inputs คือการรับข้อมูลในรูปแบบต่าง และทำการ Filters วิเคราะห์ เปลี่ยนแปลงข้อมูล และสร้าง Outputs เพื่อส่งต่อข้อมูลไปยัง Elasticsearch
Kibana คือ user interface ของ ELK ที่ช่วยให้ผู้ใช้สามารถจัดการกับข้อมูลได้ง่ายยิ่งขึ้น
ELK System Concept
Elastic Stack มีอะไรบ้าง ?
ตัวหลัก ๆ ที่น่าจะรู็จักกันคือ ELK stack ประกอบไปด้วย- Elasticsearch คือ search engine database
- Logstash เครื่องมือสำหรับสร้าง pipeline ของการ process ข้อมูล
- Kibana เครื่องมือสำหรับ visualization
แต่ในปัจจุบันนั้นใน Elastic stack มี product อื่น ๆ ออกมาอีก
ยิ่งนับวันจะมีมากขึ้นอีกด้วย
ยกตัวอย่างเช่น
- Beats เป็น product ที่มีเครื่องมือย่อย ๆ เฉพาะทางสำหรับเรื่องของ data shipper
- Elastic cloud เป็น hosting สำหรับ Elasticsearch cluster
- APM (Application Performance Monitoring)
- Machine Learning
ประกอบไปด้วยข้อมูล 2 รูปแบบคือ
1. Static data หรือ business transaction
2. Time-serie data
โดยสิ่งที่ต่างกันของข้อมูลทั้งสองแบบคือ
อัตราการเติบโตของข้อมูล ขนาดของข้อมูล
ทำให้ต้องมีการจัดการที่แตกต่างกันอย่างมาก
ทั้งเรื่อง index จัดเก็บ
ทั้งเรื่องของการ replicate ข้อมูล
ทั้งเรื่องการ sync ข้อมูล
ทั้งเรื่องการจัดการกับข้อมูลที่ไม่ถูกใช้งาน
Data modeling
Elasticsearch นั้นทั้งเร็วและสามารถ scale ได้ง่ายแต่จะเป็นไปไม่ได้เลยถ้าข้อมูลที่จัดเก็บไม่มีคุณภาพ
หรือไม่ตรงกับสิ่งที่ต้องการ ผลที่ตามมาคือจัดเก็บข้อมูลเยอะเกินไปค้นหาข้อมูลช้า หรือ ไม่เจอข้อมูลตามที่ต้องการ ดังนั้นขั้นตอนของการ indexing และค้นหาข้อมูลจึงสำคัญมาก ๆ เพราะว่าทั้งสองขั้นตอการทำงานนั้นจะมีการทำ data analysis หรือการวิเคราะห์ข้อมูลก่อนที่จะทำการ indexing และค้นหา
โดย data analysis ของ Elasticsearch ประกอบไปด้วย
- Character filter การกรองข้อมูลว่าจะใช้ข้อมูลอะไรมาตัดคำต่อไป
- Tokenizer การตัดคำข้อมูล โดยแต่ละคำที่ตัดจะเรียกว่า token เช่น Standard, Whitespace และ Thai เป็นต้น
- Token filter ทำการ filter token เช่น lowercase เป็นต้น
ทาง Elasticsearch จะมี build-in สิ่งต่าง ๆ ข้างต้นมาให้แน่นอนว่า เราสามารถนำทั้งสามเรื่องมารวมกันเพื่อสร้างให้ตรงตามที่ต้องการได้เลย
- 3 Master nodeการดึงข้อมูลจาก Elasticsearch
การดึงข้อมูลแยกออกเป็นสองส่วนคือ
- Query API สำหรับค้นหาข้อมูล
- Aggregation API สำหรับสรุปข้อมูล เหมือนกับการ group by และ count/sum/avg ใน SQL นั่นเอง
ทั้งสองเรื่องถือเป็นหัวใจสำคัญมาก ๆซึ่งคนที่นำไปใช้งานควรทำความรู้และเข้าใจให้ดีที่สำคัญจะสัมพันธ์กับ Data modeling อีกด้วย
หน้าที่ของแต่ละ Node ใน Elasticsearch cluster
Node ใน Elasticsearch cluster นั้นมีหน้าที่หลายอย่างประกอบไปด้วย
- Master สำหรับดูแล nodes, settings และจัดการ index ต่าง ๆ
- Data สำหรับเก็บข้อมูล
- Query/Coordinate สำหรับรับ request การค้นหาข้อมูล
- Ingest
- Machine learning (commercial เท่านั้น)
ค่า default นั้นในทุก ๆ Node สามารถทำได้ทุกอย่างซึ่งเหมาะสำหรับ Cluster ขนาดเล็ก
แต่ถ้า cluster มีขนาดใหญ่ขึ้น ควรต้องแบ่งหน้าที่ของแต่ละ node ให้ชัดเจนเพราะว่าแต่ละหน้าที่นั้น ใช้งาน resource ต่างกันไป ยกตัวอย่างเช่น
- Master node จะใช้ CPU, Memory และ Disk ที่น้อย
- Data node จะใช้ CPU, Memory และ Disk ที่สูงมาก
- Query node จะใช้ Memory สูง
- Ingest node จะใช้ CPU สูง
- 3 Master node
- 2 Query node
- Data node ขึ้นอยู่กับข้อมูลที่จัดเก็บ
*ที่สำคัญอย่าลืมทำ performance testing ด้วยว่ารองรับการใช้งานที่คาดหวังได้หรือไม่
เรื่องของ Sharding planning
หน่วยย่อยสำหรับการ scale ข้อมูลใน Elasticsearch cluster จะเรียกว่า Shardโดยใน version 7.1.1 นั้น ค่า default ของจำนวน shard ในแต่ละ index คือ 1นั่นหมายความว่า shard นี้จะอยู่เพียง 1 node เท่านั้น เรื่องของ scaling จึงเป็นไปไม่ได้เลย !!แต่สามารถ replicate ได้นะ
โดยคำถามที่มักได้รับเสมอคือ ควรกำหนดจำนวน shard ของแต่ละ index เป็นเท่าไรดี ?เนื่องจากค่านี้ จะต้องกำหนดตั้งแต่สร้าง index กันเลยดังนั้นจึงสำคัญมาก ๆ ต้องวางแผนกัน
แต่ความรู้พื้นฐานที่ควรรู้คือ
ในแต่ละ shard จะเก็บข้อมูลได้ประมาณ 20-40 GBดังนั้นการวางแผนต้องดูจากจำนวนข้อมูลหรือ growth rate รวมไปถึงขนาดของข้อมูล และ จำนวนของ memory ที่ใช้งานรวมทั้งเป้าหมายของ performance ที่กำหนดไว้ด้วย
ถ้ากำหนดจำนวน shard ผิด หรือไม่รองรับแล้ว ต้องทำการ reindex ข้อมูลไปยัง index ใหม่เท่านั้น
ไม่มีความคิดเห็น:
แสดงความคิดเห็น