- Kafka ประสบความสำเร็จในฐานะ distributed log ของยุคดาต้าเซ็นเตอร์ แต่บน public cloud กลับมีภาระด้าน ค่าเครือข่ายข้าม AZ และการดูแล local disk สูงขึ้น
- WarpStream เป็น แพลตฟอร์มสตรีมมิงแบบไม่มีดิสก์ ที่เข้ากันได้กับโปรโตคอล Apache Kafka ทำงานบน object storage อย่าง S3 โดยไม่ต้องใช้ local disk และไม่ต้อง rebalance broker
- คลัสเตอร์ Kafka แบบ 3 Availability Zone มีค่าโอนถ่ายข้าม AZ ประมาณ $0.053 ต่อการสตรีม 1GiB แม้ในกรณีดีที่สุด ซึ่งสูงกว่าค่าเก็บข้อมูล 1GiB บน S3 หนึ่งเดือนที่ $0.021
- WarpStream แยก storage·compute และ data·metadata ด้วย Agent ซึ่งเป็น Go binary แบบ stateless กับ metadata store แยกต่างหาก โดยข้อมูลยังอยู่ใน object storage ของบัญชีคลาวด์ผู้ใช้
- ต้นทุนอาจลดลงได้ 5~10 เท่า สำหรับ workload Kafka ส่วนใหญ่ แต่ implementation ปัจจุบันต้องแลกกับ latency: P99 ของคำขอ Produce ประมาณ 400ms และ P99 แบบ end-to-end จาก producer ถึง consumer ประมาณ 1 วินาที
โครงสร้างพื้นฐานของ Kafka ที่แพงขึ้นบนคลาวด์
- Apache Kafka เปิดเป็นโอเพนซอร์สในปี 2011 และได้กลายเป็นโครงสร้างพื้นฐานหลักของสถาปัตยกรรมสตรีมมิง
- ปัญหาไม่ได้อยู่ที่ Kafka เองเท่านั้น แต่คือดีไซน์ที่ปรับให้เหมาะกับดาต้าเซ็นเตอร์ของ LinkedIn ในปี 2011 นั้นไม่ค่อยเข้ากับ workload คลาวด์สมัยใหม่
- ต้นทุนและภาระการปฏิบัติการเห็นได้ชัดเป็นพิเศษ
- เศรษฐศาสตร์คลาวด์: วิธี replication ของ Kafka อาจทำให้ค่า bandwidth ข้าม AZ สูงมาก
- ภาระการปฏิบัติการ: การดูแลคลัสเตอร์ Kafka เองต้องมีทีมเฉพาะและเครื่องมือแบบปรับแต่งเอง
- ระบบลักษณะเดียวกันที่เก็บข้อมูลบน local disk ก็อาจเจอปัญหาต้นทุนและการปฏิบัติการแบบเดียวกัน
Kafka-nomics: ค่าโอนถ่ายข้าม AZ
- ในคลัสเตอร์ Kafka แบบ 3 Availability Zone ทั่วไป ข้อมูลที่ผลิตขึ้นมีโอกาส 2/3 ที่จะถูกเขียนข้ามโซนเพราะตำแหน่งของ partition leader จากนั้น leader จะ replicate ข้อมูลไปยัง follower ในอีกสองโซน
- เมื่่อข้อมูล 1GiB ถูกส่งข้ามโซน คิดค่าใช้จ่ายเป็น $0.022
- egress จากโซนต้นทาง $0.01
- ingress ไปยังโซนปลายทาง $0.01
- แม้ในกรณีดีที่สุด ค่าใช้จ่ายในการสตรีม 1GiB จะอยู่ราว
0.02 * 2/3 + 0.02 * 2 = $0.053
- ค่าเก็บข้อมูล 1GiB บน S3 หนึ่งเดือนคือ $0.021 และด้วยค่าใช้จ่ายในการคัดลอกข้อมูลจาก producer ถึง consumer ผ่าน Kafka สามารถเก็บข้อมูลเดียวกันบน S3 ได้นานกว่าสองเดือน
- ในคลัสเตอร์ Kafka ที่มี throughput สูง ค่า bandwidth ข้าม AZ จะครองต้นทุนมากกว่าฮาร์ดแวร์ และอาจคิดเป็น 70~90% ของต้นทุน workload
- แม้ throughput ต่ำ แต่ถ้า retention period ยาว ความจุ storage ก็จะโตขึ้น และวิธี replicate 3 ชุดบน local SSD แม้สมมติว่าใช้ดิสก์ได้ 100% ก็อาจแพงกว่า object storage อย่าง S3 ประมาณ 10~20 เท่าต่อ GiB
การปฏิบัติการคลัสเตอร์ที่ตกเป็นภาระของนักพัฒนา
- นักพัฒนานำ Kafka มาใช้เพื่อแก้ปัญหาธุรกิจ แต่ก่อนอื่นต้องเรียนรู้ Kafka และ ZooKeeper หรือ KRaft, leader election, partition, consumer group, rebalancing, การ tuning broker และการ tuning client
- broker ซึ่งเป็น data plane ของ Kafka และ controller·ZooKeeper ซึ่งเป็น control plane แบบ consensus ล้วนถูกดูแลโดยตรงบน local SSD
- คลัสเตอร์ Kafka แบบ self-hosted ต้องมีทีมผู้เชี่ยวชาญและเครื่องมือ custom เพื่อให้ทำงานพื้นฐานอย่างการเปลี่ยน node หรือขยายคลัสเตอร์ได้อย่างปลอดภัย
- เครื่องมือ partition reassignment ที่มากับ Apache Kafka ไม่สามารถสร้างแผน reassignment อัตโนมัติเมื่อปลดระวาง broker ได้ ผู้ดูแลระบบต้องเขียนแผนย้าย replica ของ partition เอง
- แม้บริการ hosted อย่าง AWS MSK ก็ไม่ได้ขจัดภาระการปฏิบัติการได้ทั้งหมด
- เอกสาร cluster rebalancing ของ MSK ลิงก์ไปยังเอกสาร Apache Kafka
- ขั้นตอนดังกล่าวรวมถึงการแก้ไข JSON ด้วยตนเองว่าจะย้าย partition ใดไปยัง broker ใด
- Cruise Control ช่วยลดภาระได้ แต่ก็เพิ่มสิ่งที่ต้องเรียนรู้ การ deploy·monitoring บริการ และจุดที่ต้องระวังในการใช้งานจริง
- Cruise Control เองก็เป็น JVM application ที่พึ่งพา Apache Kafka และ ZooKeeper
แนวทางวางสตรีมมิงบน object storage
- Husky ที่ Datadog สร้างขึ้นเป็นฐานข้อมูลแบบ columnar สำหรับข้อมูล observability ที่รันโดยตรงบน S3 และส่วนใหญ่ทำงานเป็น data lake แบบ stateless ที่ auto-scale ได้
- หลังจากสร้าง Husky แล้ว คลัสเตอร์ Kafka ก็ดูเหมือนสถาปัตยกรรมเก่าเมื่อเทียบกัน
- bandwidth ของ Kafka ที่ Datadog อยู่ในระดับเลขสองหลัก GiB/s และ storage ของ broker วัดได้เป็นระดับ PiB ของ NVMe
- workload การจัดเก็บขนาดใหญ่แข่งขันกับ ความคุ้มค่า·ความน่าเชื่อถือ·ความสามารถในการขยาย·ความยืดหยุ่น ของ object storage ในสภาพแวดล้อมคลาวด์ได้ยาก
- เทคโนโลยี big data อย่าง Snowflake และ Databricks ก็ออกแบบระบบโดยมี object storage อเนกประสงค์เป็นศูนย์กลาง
- หากสร้างระบบคล้าย Kafka บน S3 โดยตรง จะลดภาระได้สองด้านพร้อมกัน
- ลดต้นทุน
- ลดปัญหาการปฏิบัติการ Kafka แบบดั้งเดิม
- ความยากหลักคือการสร้างโครงสร้างพื้นฐานสตรีมมิง latency ต่ำที่ยังรักษาความหมายของโปรโตคอล Kafka ไว้ โดยไม่มี local disk บน สื่อจัดเก็บที่มี latency สูง อย่าง S3
สถาปัตยกรรม WarpStream
- WarpStream เป็นแพลตฟอร์มสตรีมมิงที่เข้ากันได้กับโปรโตคอล Apache Kafka และรันโดยตรงบน object store อเนกประสงค์อย่าง AWS S3, GCP GCS, Azure Blob Storage
- ไม่มีค่า bandwidth ข้าม AZ ไม่มี local disk ให้จัดการ และสามารถรันภายใน VPC ของผู้ใช้ได้
- ใช้ Agent แทน Kafka broker
- Agent เป็น Go binary แบบ stateless
- ไม่ใช้ JVM
- สื่อสารด้วยโปรโตคอล Kafka
- Agent ใดก็ได้สามารถทำหน้าที่เป็น topic leader, commit offset ของ consumer group และ cluster coordinator ได้
- WarpStream แทนที่โครงสร้าง stateful ของ Kafka ด้วยการแยกสองอย่าง
- แยก storage กับ compute และ offload ข้อมูลไปยัง S3
- แยก data กับ metadata และ offload metadata ไปยัง metadata store แบบปรับแต่งเฉพาะ
- เมื่อย้ายการจัดเก็บทั้งหมดไปยัง object storage ก็ไม่จำเป็นต้อง rebalance ข้อมูล เมื่อเพิ่มหรือลดจำนวน Agent ตามการเปลี่ยนแปลงของโหลด
- แม้เกิด failure ก็สามารถ retry คำขอที่ Agent อื่นได้ทันที ทำให้กู้คืนได้เร็ว
- ปัญหา hotspot ที่ broker บางตัวของ Kafka รับโหลดสูงเพราะข้อมูลแต่ละ partition ไม่สมดุลกันก็ลดลงเป็นส่วนใหญ่
- metadata ของ WarpStream Virtual Cluster ถูกเก็บในฐานข้อมูล metadata แบบปรับแต่งเฉพาะ
- การ replicate ข้อมูล, durability และ availability เป็นหน้าที่ของ object storage bucket และข้อมูลของผู้ใช้ยังคงอยู่ในบัญชีคลาวด์ของผู้ใช้
- สิ่งที่ออกไปนอกบัญชีคลาวด์มีเพียง metadata ของ workload ที่จำเป็นต่อ consensus เช่น ลำดับ batch ภายใน partition
- โครงสร้างโดยละเอียดสรุปไว้ใน เอกสารสถาปัตยกรรม WarpStream
ตัวอย่างต้นทุนและ trade-off ด้าน latency
- workload สตรีมมิงต่อเนื่องในสภาพแวดล้อมทดสอบผลิตข้อมูล 140MiB/s อย่างต่อเนื่อง และมี consumer เฉพาะ 3 ตัวคอยบริโภค ทำให้เกิดการส่งข้อมูลต่อเนื่องรวม 560MiB/s
- ค่าเครือข่ายข้าม AZ ของบัญชีคลาวด์ทั้งหมดวัดได้เฉลี่ยต่อวันต่ำกว่า $15
- หากรัน workload เดียวกันบนคลัสเตอร์ Kafka ค่าเครือข่ายข้าม AZ เพียงอย่างเดียวจะคำนวณได้เป็น $641 ต่อวัน
- สูตรคำนวณคือ
0.14GiB * $0.053/GiB * 60 * 60 * 24
- ค่าใช้จ่าย S3 API operation ของ workload เดียวกันต่ำกว่า $40 ต่อวัน
- ฮาร์ดแวร์ของ Agent ต้องการเพียง VM ขนาด 27 vCPU
- Total Cost of Ownership ของ workload Kafka ส่วนใหญ่บน WarpStream อาจต่ำลงได้ 5~10 เท่า
- ข้อเสียใหญ่ที่สุดคือ latency
- P99 ของคำขอ Produce ปัจจุบันอยู่ที่ประมาณ 400ms
- เพราะจะไม่ตอบรับจนกว่าข้อมูลจะถูกจัดเก็บอย่าง durable บน S3 และ commit ไปยัง control plane ของคลาวด์
- latency P99 แบบ end-to-end จาก producer ถึง consumer อยู่ที่ประมาณ 1 วินาที
- หาก workload ยอมรับ latency จาก producer ถึง consumer ที่ P99 ประมาณ 1 วินาทีได้ ก็สามารถลดต้นทุนสตรีมมิงต่อ GiB ลง 5~10 เท่า และแทบขจัดภาระการปฏิบัติการได้
- อินเทอร์เฟซไม่ใช่โปรโตคอลเฉพาะของตัวเอง แต่เป็น Kafka และสามารถรันในสภาพแวดล้อมที่ใช้ AWS S3, GCP GCS, Azure Blob Storage ได้
ประสบการณ์นักพัฒนาและวิธีใช้งาน
- WarpStream จัดการปัญหาหลักของ Kafka ด้านเศรษฐศาสตร์คลาวด์และภาระการปฏิบัติการก่อน
- Kafka ยังมีปัญหาด้านประสบการณ์นักพัฒนา และ partition ถูกมองว่าเป็น abstraction ระดับต่ำเกินไปสำหรับการเขียนแอปพลิเคชัน stream processing ที่ซับซ้อน
- มีแผนจะกล่าวถึงวิธีทำให้แอปพลิเคชัน stream processing ในอนาคตใกล้เคียงกับวิธีเขียนแอปพลิเคชันแบบดั้งเดิมมากขึ้น
- สามารถรันเดโมได้ภายใน 30 วินาที
$ curl https://console.warpstream.com/install.sh | bash
$ warpstream demo
- WarpStream เป็นการแนะนำผลิตภัณฑ์ของบริษัทที่ขายทางเลือกบน object storage แทน Apache Kafka และควรอ่านตัวเลขกับการเปรียบเทียบในบทความตามบริบทดังกล่าว
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมคิดว่าคำกล่าวที่ว่า “บริษัทเทคโนโลยีแทบทุกแห่งใช้ Kafka” น่าจะไม่ถูกต้อง
แม้เราไม่ได้ยกหลักฐานโต้กันโดยตรง แต่จาก 6 บริษัทที่ผมเพิ่งทำงานด้วยเมื่อไม่นานมานี้ ไม่มีที่ไหนใช้ Kafka เลย และในบริษัทก่อนหน้านั้นผมเคยเป็นคนผลักดันการนำมาใช้ แต่ภายหลังก็เลิกใช้ไป
LinkedIn สร้าง Kafka ขึ้นมาเพื่อแก้ ปัญหาระดับสเกลมหาศาล ที่ 99% ของคนไม่มี และถึงแม้นักเทคโนโลยีจะมีชื่อเสียงเรื่องใช้เทคโนโลยีที่ไม่จำเป็น แต่ผมคิดว่าส่วนใหญ่ก็หลีกเลี่ยงการใช้ Kafka ได้สำเร็จ
ถ้าสิ่งที่ต้องการมีแค่นั้น ก็ใช้งานได้ง่ายเหมือน message broker แบบธรรมดาที่ไม่มีช่วงเวลาเก็บรักษา และถ้าต้องทำงานพิเศษที่ใช้ประโยชน์จากความคงทนของข้อมูล ก็ไปทางนั้นได้
ถ้ามีความรู้สึกลบต่อเครื่องมือโอเพนซอร์สที่แข็งแรงและใช้กันแพร่หลายแม้ในรูปแบบพื้นฐาน ผมคิดว่าส่วนใหญ่น่าจะมาจากฟีเจอร์หรือกรณีใช้งานเฉพาะบางอย่างมากกว่า
กลับกัน การใช้ถ้อยคำแบบนี้ดูไม่ดีต่อผู้ขายรายนี้เสียมากกว่า คุณจะวิจารณ์หรือแข่งกับ Kafka ด้วยข้อดีข้อเสียทางเทคนิคก็ได้ แต่การบิดเบือนตำแหน่งของมันในตลาดนั้นไม่ค่อยดี
ผมไม่สงสัยว่ามี use case ที่ดีอยู่ แต่จนถึงตอนนี้ผมเห็นแต่ผู้ใช้สายศรัทธาที่พยายามยัดมันเข้าไปในทุกสถานการณ์ เลยเหลือความรู้สึกค้างคาไม่ดี และทำให้ผมอยู่ฝั่ง “ไม่ชอบ”
ผมเห็นด้วยกับส่วน “Accidental SRE” แต่ Kafka เป็นเทคโนโลยีที่แข็งแรง และนั่นจึงทำให้มีเครื่องมือแนว “Kafka ที่ดีกว่า Kafka” อย่าง Redpanda ออกมาเต็มไปหมด
ตอนท้ายเหมือนจะหลุดประเด็นไป ต่อให้ไม่ได้ถูกใช้กันแพร่หลาย ก็เป็นคนละเรื่องกับว่ามันเป็นเทคโนโลยีที่แบ่งขั้วหรือไม่ สำหรับคนที่กำลังแก้ปัญหาการสเกลระดับ 1% ที่พูดถึง มันก็ยังอาจเป็นสิ่งที่คนรักหรือเกลียดได้อยู่
คล้ายกับการบอกว่า “Lamborghini เป็นสิ่งที่คนมีทั้งชอบและไม่ชอบ” แล้วบอกว่าประโยคนี้ผิดเพราะคนส่วนใหญ่ไม่มี Lamborghini ผู้เขียนก็ระบุขอบเขตชัดเจนว่า “ในสายข้อมูล” ด้วย
มีคำถามอยู่สองสามข้อ
ดังนั้นค่า S3 PUT จึงแปรผันตามจำนวน Agent ที่กำลังรันและ interval การ flush ไม่ใช่จำนวน topic-partition ก่อนที่ข้อมูลจะถูกบันทึกอย่างทนทานใน S3 และ cloud control plane จะไม่มีการยืนยัน Produce request
ผมคิดว่าไม่ควรต้องเลือกระหว่างความน่าเชื่อถือกับต้นทุน WarpStream ให้ความน่าเชื่อถือและ availability ระดับการรันใน 3 Availability Zone ด้วยต้นทุนเท่ากับหนึ่ง Availability Zone
ส่วนลำดับนั้นจัดการโดย custom metadata database ที่รันอยู่ใน cloud control plane
วิธีที่มี Kafka cluster ในแต่ละ Availability Zone แล้วค่อย replicate เฉพาะจนกว่าจะนำมารวมกันทีหลังนั้น โดยตัวมันเองไม่ได้มีปัญหาอะไร เพียงแต่เมื่อมีระบบกระจายและ Availability Zone มาเกี่ยวข้อง วิศวกรรวมถึงความต้องการทางธุรกิจมักจะเลือก การตั้งค่าแบบหลาย Availability Zone กันโดยทั่วไป Region ก็เช่นกัน
ดังนั้น Kafka cluster ส่วนใหญ่จึงเป็นแบบหลาย Availability Zone แต่ความจริงหลายกรณีไม่จำเป็นต้องทำแบบนั้น และใบแจ้งค่าใช้จ่ายนั้นก็ถูกโยนให้เป็นความผิดของ Kafka
Kafka protocol ไม่ได้รักษาลำดับงานภายใน Kafka partition จริง ๆ มันรักษาลำดับงานภายในคู่ producer-partition และแม้แบบนั้นก็ทำได้เฉพาะเมื่อตั้งค่าด้วยวิธีเฉพาะเท่านั้น
implementation มาตรฐานคือการรักษาลำดับที่ broker ได้รับข้อความจาก producer แต่จากมุมมองของระบบภายนอก ความหมายจะใกล้เคียงกับว่า เมื่อกำหนดค่าอย่างถูกต้อง ข้อความของ key หนึ่ง ๆ และ producer หนึ่ง ๆ จะถูกเก็บตามลำดับที่ได้รับ
Cloud Metadata Store ทำหน้าที่แจก offset โดยพฤตินัยหรือเปล่า?
ผมคือ Ryan Worl ผู้ร่วมก่อตั้งและ CTO ของ WarpStream รู้สึกยินดีอย่างยิ่งที่ได้ประกาศ developer preview ของ ระบบสตรีมมิงที่เข้ากันได้กับโปรโตคอล Kafka ซึ่งสร้างขึ้นโดยตรงบน S3
ไม่มีดิสก์/โหนดแบบมีสถานะที่ต้องรัน ไม่มีการ rebalance ข้อมูล ไม่มี ZooKeeper และไม่มีค่าแบนด์วิดท์ข้าม Availability Zone จึงถูกลง 5–10 เท่า
หากมีคำถามเกี่ยวกับ WarpStream ผมจะตอบร่วมกับ richieartoul ผู้ร่วมก่อตั้ง
หนึ่งในเหตุผลที่ไม่ได้ทำคือ ผมรู้สึกถึงความย้อนแย้งว่า ถ้าขนาดไม่ได้สำคัญ ผู้ใช้ก็อาจเขียน SQLite โดยตรง แทนที่จะอยากได้ Kafka ฉบับย่อส่วนไม่ใช่หรือ
แต่ก็อาจมีคนที่ชอบ semantics ของโปรโตคอล Kafka หรือเคยใช้ Kafka อยู่แล้วแต่พบว่าขนาดงานไม่ได้ใหญ่เท่าที่คิด จึงไม่จำเป็นต้องแบกรับความซับซ้อนนั้น ขอให้โชคดี
ถ้ารองรับ Cloudflare R2 ก็น่าจะดีสำหรับมัลติคลาวด์ด้วย
มีการรับประกันลำดับเหมือนที่ Kafka ให้ในระดับ partition ด้วยไหม?
ถ้า “ถูกลง 5–10 เท่า” ส่วนใหญ่เกิดจากการลดค่าใช้จ่ายข้าม Availability Zone แล้ว AWS MSK ก็ไม่ได้ให้สิ่งนั้นหรือ?
มีอย่างหนึ่งที่แน่นอน ถ้ารัน Kafka “ตามตำรา” บน VM แยก ๆ บนผู้ให้บริการคลาวด์ มันแพงอย่างไร้เหตุผล
ผมจำได้ว่าเคยคุยเรื่องง่าย ๆ มากกับลูกค้าหลายรายเกี่ยวกับ Kafka และ Hadoop ว่า ในเมื่อดิสก์ถูกจัดมาให้เป็น ระบบ redundancy ที่สมบูรณ์อยู่แล้ว ทำไมต้อง replicate ข้อมูลซ้ำอีกในระดับ VM/ดิสก์
ในกรณีนี้คือ Azure Storage ซึ่งมีพื้นที่จัดเก็บแบบ local-redundant, zone-redundant และ geo-redundant โดยหลายแบบในนั้นใช้รัน managed disk ได้
ดังนั้นบริการจัดการ Hadoop/Kafka บนคลาวด์ที่ออกแบบมาดีจะใช้ storage adapter เพื่อใช้ประโยชน์จาก redundancy ที่ผู้ให้บริการมีมาให้ในตัว เหตุผลเดียวกันนี้เองที่ผู้ให้บริการคลาวด์บางรายมี event broker ที่เข้ากันได้กับ Kafka
ส่วนอื่น ๆ ของ WarpStream แทบจะเป็นของแถมชั้นดี แต่ผมสงสัยว่าโครงสร้างภายในและการหลีกเลี่ยงค่าใช้จ่ายข้าม Availability Zone ทำได้อย่างไร
หมายเหตุ: ผมทำงานที่ Microsoft แต่ก่อนเข้าทำงานเมื่อเกือบ 10 ปีก่อน ผมเคยสร้างคลัสเตอร์ Hadoop/Spark/Kafka
การทำ Raft บางแบบอนุญาตให้มีโหนดที่มีสิทธิ์โหวต แต่ไม่สามารถเป็น quorum leader ได้ ตัวอย่างเช่น สาขาที่ทราฟฟิกทั้งหมดต้องผ่านอุโมงค์ VPN แบบ asymmetric ไม่ควรถูกเลือกเป็น leader แต่ยังรู้ว่าเห็น candidate ตัวใดบ้าง
ดังนั้นต้นทุนพื้นฐานของการรันคลัสเตอร์จึงใกล้ 2.2 เท่ามากกว่า 3 เท่าของฮาร์ดแวร์ และสำหรับโซลูชันขนาดเล็กหรือ sandbox ของนักพัฒนา นั่นเป็นความต่างที่มาก กรณีที่ 3 shard รับโหลดได้ไม่ค่อยพอ แต่ 5 shard ก็มากเกินไป หรือแม้แต่ความต่างระหว่าง 6 กับ 7 ก็สำคัญ
ปัญหาคือในการทำ replication ข้ามภูมิภาค วิธีนี้แก้สองปัญหาที่เป็นประเด็นหลักของบทความนี้ไม่ได้ ในมุมเศรษฐศาสตร์คลาวด์ กลยุทธ์ replication ของ Kafka สร้างค่าแบนด์วิดท์ข้าม Availability Zone จำนวนมหาศาลโดยการออกแบบ และในมุมภาระการดำเนินงาน การรันคลัสเตอร์ Kafka เองแทบจะต้องมีทีมเฉพาะทางและเครื่องมือ custom ที่ซับซ้อน
ถึงอย่างนั้นก็ยังจำเป็นต้องเอาความสามารถนี้กลับมาในคลาวด์ โดยเฉพาะในช่วงที่กระแสเริ่มแกว่งกลับไปสู่การ self-host เพิ่มเติมอีกครั้ง เหมือนที่เคยเป็นมาเสมอ
โซลูชันคล้าย EBS มีต้นทุนตามมา โดยเฉพาะเมื่อจำเป็นต้องใช้ IOPS จำนวนมาก จะแพงมาก แม้จะประหยัดค่าทราฟฟิกข้าม Availability Zone ได้ แต่ก็ต้องจ่ายเงินมหาศาลให้กับ storage
ถ้าทำ replication เอง จะสามารถใช้ attached storage ที่ถูกกว่ามากได้
ถึง richieartoul: บล็อกโพสต์ออกจะใส่สีสันแรงไปหน่อย
โดยเนื้อแท้แล้ว Kafka ไม่ได้ต้องการทีมผู้เชี่ยวชาญเต็มเวลาและเงินหลายล้านดอลลาร์ จนกว่าจะรันคลัสเตอร์ขนาดใหญ่มาก ๆ
แต่ผมเห็นด้วยอย่างยิ่งว่า คลัสเตอร์ที่กระจายข้าม 3 Availability Zone จะดูดเงินไปกับค่าโอนถ่ายข้าม Availability Zone นั่นแหละคือวิธีที่ AWS ขาย MSK เขาบอกว่าการโอนถ่ายข้าม Availability Zone “ฟรี” แต่จริง ๆ แล้วมันรวมอยู่ในราคาแล้ว
ดูน่าสนใจ แต่หลังจากอ่าน “Accidental SRE” แล้วมีคำถามสองข้อ
bare metal มีมานานแล้ว และผมก็ไม่รู้สึกว่าการจัดการ bare metal เองจะง่ายขึ้นมากนัก ถ้ามันง่ายจริง ผู้ใช้ปลายทางคงจัดการสิ่งเหล่านี้เองมากกว่านี้
ถ้าอย่างนั้นบริการนี้บริหารจัดการอย่างไร? เป็นผู้ให้บริการคลาวด์ หรือ bare metal?
ทั้งสองคนมีประสบการณ์มากกับ FoundationDB ซึ่งปกติมักต้องจัดการเอง ดังนั้นจึงเลือก FoundationDB เป็น metadata store อีกครั้งหรือไม่? ถ้าเลือกหรือไม่ได้เลือก ก็อยากรู้เหตุผล
วิธีนี้ทำให้ข้อมูลของลูกค้าทั้งหมดยังคงอยู่ในบัญชีคลาวด์และบัคเก็ต S3 ของลูกค้า เราจึงมองเห็นหรือแตะต้องไม่ได้ แม้ลูกค้าต้องรัน WarpStream Agent เอง แต่ก็เป็นเพียงคอนเทนเนอร์แบบ stateless ที่จัดการง่าย
เราพิจารณา FoundationDB สำหรับ metadata store แล้ว แต่สุดท้ายไม่ได้ใช้ เพื่อให้ free tier คุ้มต้นทุน เราจำเป็นต้องทำ metadata store ให้มีประสิทธิภาพมากที่สุดสำหรับ use case เฉพาะนี้ และนั่นต้องการสิ่งที่ custom มากกว่า
ถึงอย่างนั้น FoundationDB ก็เป็นเทคโนโลยีที่ยอดเยี่ยม เป็นหนึ่งในฐานข้อมูลแบบกระจายที่ดีที่สุดเท่าที่ผมเคยใช้มา
คำพูดที่ว่า “ควรใช้พาร์ทิชันกี่อัน? ยังไม่ชัดเจน แต่พอเลือกแล้วจะเปลี่ยนไม่ได้เด็ดขาด ดังนั้นต้องเลือกให้ถูก” นั้นผิดไปเลย จริง ๆ แล้ว จำนวนพาร์ทิชัน เปลี่ยนได้
และข้อกล่าวอ้างที่พูดซ้ำ ๆ ว่า “การดูแล Kafka ต้องใช้ทีมวิศวกรทั้งทีม” ผมก็ไม่ค่อยเข้าใจ จากประสบการณ์แล้วไม่จริง ต้นทุนการดำเนินงานแพงก็ใช่ แต่ในทีมของเราไม่ได้ต้องใช้เวลาวิศวกรมากนัก
น่าสนใจมาก ผมเองก็เคยออกแบบอะไรคล้าย ๆ กัน และตั้งใจจะ implement ด้วย Zig https://github.com/fremantle-industries/transit
พลังส่วนใหญ่ของ Kafka มาจาก API และผมก็ได้ข้อสรุปคล้ายกันว่า สุดท้ายแล้วความซับซ้อนของการจัดการคลัสเตอร์จะถูก abstract ผ่าน implementation หลาย ๆ แบบ
ถ้าสามารถ implement ความคงทนของ Kafka บน key space ของ S3 ได้ ผมมองว่าสามารถเริ่มจากแนวทาง persist ลง S3 โดยตรงแบบ WarpStream แล้วหลังจากนั้นค่อยวางกลไก tiering ด้วย hot disk ที่เร็วกว่าและหน่วยความจำทับเข้าไป เพื่อลด end-to-end latency
ผมชอบทิศทางนี้ ถ้าอยากคุยลึกกว่านี้ ติดต่อทาง Twitter ได้ https://twitter.com/rupurt
ที่งานเก่า ผมเคยสร้างสิ่งที่น่าจะคล้ายกับผลิตภัณฑ์นี้มาก เรามี ทราฟฟิกแมชชีนเลิร์นนิง ระดับหลายสิบ TB ต่อวัน และไม่ได้ต้องการ latency แบบเรียลไทม์ เลยย้ายทั้งหมดไป S3 แล้วลดต้นทุนได้ประมาณ 90%
สร้างบน JVM และยังใช้คลัสเตอร์ Kafka 6 โบรกเกอร์เพื่อเก็บ metadata อยู่ ตอนที่ทุกอย่างอยู่บน Kafka เดิมทีน่าจะต้องใช้โบรกเกอร์ราว 300 ตัว
โมเดล compute/storage ของ Kafka ขยายตัวได้ไม่ดีใน use case สุดโต่งที่ยอมรับ latency ได้ และโมเดลของ Apache Pulsar เหมาะกว่า อย่างไรก็ตาม ตอนนั้น Pulsar ยังไม่เสถียรพอสำหรับใช้งาน production
หนึ่งในหัวใจของความคุ้มค่าด้านต้นทุนคือขนาดข้อมูลใหญ่พอ จึงไม่ต้องรอนานกว่าจะถึงขนาดไฟล์ที่ประหยัดต้นทุน ผมนึกภาพยากว่า pipeline ที่ต่ำกว่า 10MB ต่อวินาทีจะทำงานอย่างมีประสิทธิภาพด้วยวิธีนี้ได้
นี่คือ memq ของ Pinterest หรือว่าเป็นอย่างอื่นกันนะ?
ชื่อบทความควรเป็น “Kafka is dead. Long live WarpStream.” มากกว่า ส่วน “long live” หมายถึงผู้สืบทอด
https://en.wikipedia.org/wiki/The_king_is_dead,_long_live_th...!