Valkey ครบรอบ 1 ปี: คอมมูนิตี้ฟอร์กแซง Redis ได้อย่างไร

• Redis Inc ทำให้ความเชื่อมั่นของคอมมูนิตี้สั่นคลอนจากการตัดสินใจปิดซอร์สโค้ดบางส่วนด้วยการเปลี่ยนไปใช้ SSPL แต่คอมมูนิตี้นักพัฒนาก็รวมตัวกันรอบฟอร์ก Valkey จนเกิดนวัตกรรมและการมีส่วนร่วมอย่างต่อเนื่อง
• Redis 8.0 กลับมาเป็นโอเพนซอร์สอีกครั้ง และผู้ก่อตั้ง Antirez ก็กลับมามีส่วนร่วมในฟีเจอร์ใหม่และการปรับแต่งประสิทธิภาพ ทำให้ทั้งสองฝั่งพัฒนาอย่างรวดเร็ว
• จากผลเบนช์มาร์กล่าสุด Valkey 8.1.1 ในสภาพแวดล้อม 8vCPU ทำประสิทธิภาพ SET ได้ สูงกว่า Redis 8.0 อยู่ 37% และยังวัดค่า p99 latency ได้สั้นกว่าอีกด้วย (ประสิทธิภาพ GET ก็นำอยู่ 16%)
• ด้วยเทคนิคการจูนสำหรับใช้งานจริง เช่น IO thread และ core pinning ทำให้ Valkey เพิ่ม throughput ในสภาพแวดล้อมมัลติเธรดได้มากกว่า 3 เท่า พร้อมลด latency ให้น้อยที่สุด
• ยังมีการแชร์ทั้งเบนช์มาร์กที่ใกล้เคียงการใช้งานจริงและแนวทางการจูน พร้อมอธิบายข้อควรระวังในการตีความผลเบนช์มาร์กและวิธีนำไปใช้ในระบบจริง

---

การปิดซอร์สของ Redis และการมาของ Valkey

• เมื่อ 1 ปีก่อน Redis Inc (เดิมคือ Garantia Data) ทำให้ความสัมพันธ์ด้านความเชื่อมั่นกับคอมมูนิตี้แย่ลงจากการ เปลี่ยนไลเซนส์โอเพนซอร์ส (นำ SSPL มาใช้)
• ฟอร์กแบบเปิด Valkey ที่เกิดขึ้นเพื่อแก้ปัญหานี้ ได้กลายเป็นสินทรัพย์ทางเทคโนโลยีที่ถูกใช้อย่างกว้างขวางในระบบกระจายตัว แคช และการประมวลผลข้อมูลแบบเรียลไทม์
• ฝั่ง Redis เองก็พยายามกู้คืนความเชื่อมั่นในภายหลังด้วยการกลับมาของ Antirez (ผู้ก่อตั้ง) การเสริมประสิทธิภาพ/ฟังก์ชัน และการเปลี่ยน Redis 8.0 กลับไปเป็นโอเพนซอร์ส

Valkey 8.1 vs Redis 8.0: เปรียบเทียบประสิทธิภาพ

• เบนช์มาร์ก SET ภายใต้เงื่อนไขเดียวกัน: AWS c8g.2xl 8vCPU, item ขนาด 1KB, keyspace 3M, 500 connections
  • Valkey 8.1.1: 999.8K RPS (p99 0.8ms)
  • Redis 8.0: 729.4K RPS (p99 0.99ms)
  • Valkey สูงกว่าในงาน SET 37%, GET 16% และเร็วกว่าใน SET p99 30%, GET p99 60%
• เมื่อนำ 6 IO threads มาใช้ Valkey เพิ่มจาก 239K → 678K RPS (2.8 เท่า↑), p99 1.68ms → 0.93ms (44%↓)
• Redis ก็ได้ประโยชน์จาก IO threads เช่นกัน จาก 235K → 563K RPS, p99 1.35ms → 0.84ms (40%↓)

ผลของการจูนมัลติเธรด/คอร์

• IO thread เริ่มให้ผลชัดเจนตั้งแต่ 3 threads ขึ้นไป และ Valkey ทิ้งห่าง Redis มากขึ้นหลัง 4 threads
• หากจำกัดคอร์ IRQ (interrupt) ไว้ 2 คอร์ แล้วตรึง Redis/Valkey ไว้กับอีก 6 คอร์ที่เหลือ (pinning) จะได้ประสิทธิภาพเพิ่มขึ้นอีก
  • Valkey: 832K → 999.8K RPS (core/IRQ pinning, ใช้ CPU 80%)
  • การแยกคอร์ IRQ/แอปพลิเคชันช่วยเพิ่มประสิทธิภาพแคชและลด tail latency ให้น้อยที่สุด
  • มีตัวอย่างการใช้งานจริงผ่าน Docker เช่น cpuset-cpus, --io-threads

การทำซ้ำเบนช์มาร์กและเคล็ดลับสำหรับใช้งานจริง

• ใช้ instance รุ่นล่าสุด AWS Graviton4 (c8g.2xlarge) พร้อม cluster placement group
• ทำประสิทธิภาพสูงสุดด้วยการ pinning คอร์/แยก IRQ/ปรับจำนวน connection (ช่วง 400~500)
• ควรจูนทั้ง ขนาด keyspace/item ด้วย โดยค่าที่เล็กกว่าและ keyspace ที่เล็กกว่าจะช่วยเพิ่มอัตรา L3 cache hit
• แนะนำให้ใช้งานเครื่องมือเบนช์มาร์กแบบมัลติเธรดอย่าง valkey-benchmark หรือ rpc-perf (เครื่องมือพื้นฐาน Rust ที่ใกล้เคียงการใช้งานจริงมากกว่า) อย่างจริงจัง

  docker run --network="host" --rm --cpuset-cpus="2-7" \  
  valkey/valkey:8.0.1 valkey-benchmark \  
  -h 172.31.4.92 -p 6379 -t SET,GET -n 100000000 -c 256 \  
  -r 3000000 --threads 6 -d 1024  
  

ข้อจำกัดและข้อควรระวังในการวัดประสิทธิภาพ

• ผลเบนช์มาร์กอาจแตกต่างจากสภาพแวดล้อมการใช้งานจริง

  • เวิร์กโหลดจริงมีปัจจัยซับซ้อนหลายอย่าง เช่น สัดส่วนผสมของ SET:GET ความผันผวนของโหลด เป้าหมาย TPS และ network latency
  • เมื่อจำนวน connection เพิ่มสูงมาก อาจพบทั้ง queueing delay, throughput ลดลง และ tail latency สูงขึ้น
  • ผลลัพธ์อาจแตกต่างกันมากตามเครื่องมือ/ออปชันของเบนช์มาร์ก และ network topology

การเติบโตหลักและพัฒนาการของคอมมูนิตี้

ตลอด 1 ปีที่ผ่านมา โปรเจกต์ Valkey เติบโตอย่างคึกคักในหลายด้าน

• มีการเพิ่มฟีเจอร์ แก้บั๊ก และปรับปรุงความปลอดภัย ผ่าน ความร่วมมือของนักพัฒนาและบริษัทจำนวนมาก บน GitHub และที่อื่น ๆ
• ให้ความสำคัญกับเอกสารและการช่วยเหลือผู้ใช้ เพื่อ ลดอุปสรรคสำหรับผู้ใช้ใหม่
• ในกระบวนการบริหารโปรเจกต์ ยังเน้น การตัดสินใจอย่างโปร่งใส และ การโหวตโดยคอมมูนิตี้

คุณค่าต่ออุตสาหกรรมและเชิงเทคนิค

Valkey มีจุดแข็งดังต่อไปนี้

• ทุกคนสามารถใช้งานได้โดยไม่มีข้อจำกัดด้านไลเซนส์ จึงเป็นตัวเลือกที่น่าสนใจสำหรับ ผู้ให้บริการคลาวด์ และ บริษัทเว็บสเกลขนาดใหญ่
• มี ความเข้ากันได้กับ Redis สูง จึงย้ายระบบได้ง่าย
• ด้วยการพัฒนาที่ขับเคลื่อนโดยคอมมูนิตี้ จึงสามารถสะท้อนความต้องการที่หลากหลายและอัปเดตได้อย่างรวดเร็วต่อเนื่อง

บทสรุปและประเด็นที่น่าสนใจ

• Valkey แสดงให้เห็นภายใน 1 ปีหลังฟอร์กจาก Redis ว่าสามารถก้าวแซง Redis ได้ทั้งด้านเทคนิค ประสิทธิภาพ และคอมมูนิตี้
• เคล็ดลับการจูนสำหรับใช้งานจริงและเครื่องมืออย่าง IO threads, การแยก core/IRQ และการปรับจำนวน connection คือหัวใจสำคัญ
• ประสิทธิภาพไม่ได้เกิดขึ้นเองโดยอัตโนมัติ แต่ต้องอาศัยการปรับแต่งอย่างต่อเนื่องให้เหมาะกับระบบ เวิร์กโหลด และโครงสร้างพื้นฐาน
• ในสภาพแวดล้อมบริการจริง ควรใช้แนวทางเชิงปฏิบัติที่ทดสอบหลายสถานการณ์ด้วยตนเอง ไม่พึ่งตัวเลขเบนช์มาร์กเพียงอย่างเดียว

[ethanhur]

แม้ Redis จะตัดสินใจผิดพลาดไว้หลายอย่าง แต่ภาพที่คนลงแรงเป็นหมี ส่วนคนฝึกกลับเป็นฝ่ายรับเงิน ก็น่าเสียดายเหมือนกัน

[kgcrom]

เอกสารนี้เป็นการสรุปว่ามีการปรับปรุงอะไรบ้างใน Valkey 8
ซึ่งโพสต์ไว้ใน Facebook "Redis User Group"
https://www.facebook.com/groups/rediskorea/posts/3927030954110001/

หากอ่านควบคู่กับเนื้อหาข้างต้น ก็น่าจะช่วยให้เข้าใจได้มากขึ้น

[ndrgrd]

จริง ๆ แล้วไม่ใช่ว่า Valkey ทำอะไรเป็นพิเศษหรอก... แต่ฝั่งนั้นดันล่มสลายไปเอง...

[GN⁺]

ความเห็นจาก Hacker News

• ฉันดีใจที่ ValKey พัฒนาเรื่อง I/O threading ได้อย่างยอดเยี่ยม และยังเริ่มนำการเปลี่ยนแปลงที่น่าสนใจที่สุดในช่วงหลัง ๆ เข้ามาด้วย ขอขอบคุณผู้มีส่วนร่วมของ ValKey มาก ๆ แต่ฉันคิดว่าบทความนี้มีแนวโน้มทำให้เข้าใจผิดอยู่บ้าง เดิมทีใน Redis สถาปัตยกรรม shared nothing เป็นปรัชญาที่สำคัญมาก และในปี 2020 ฉันเองก็เป็นคนที่เพิ่ม I/O threading เข้าไปโดยตรง โดยไม่ทำลายแนวคิดของ shared nothing เราจึงออกแบบให้ในจังหวะที่ event loop กำลังจะคืนกลับ ซึ่งเป็นช่วงที่ write(2)/read(2) syscall อาจช้ามาก เราจะทำ I/O แบบขนานด้วย N threads ในสภาวะ zero contention เฉพาะช่วงนั้น แล้วกลับไปเป็น single-thread ทันทีหลังจากนั้น ขอชื่นชมทีม ValKey ที่พัฒนาระบบนี้ต่อไปได้อีก มันเป็นระบบที่ใช้งานได้มานานแล้ว และพูดตรง ๆ คือฉันไม่ค่อยสบายใจกับการที่สื่อชอบพูดเกินจริงกับข้อมูลที่ในความเป็นจริงไม่ได้เปลี่ยนมากนัก ฟีเจอร์แบบนี้จริง ๆ แล้วน่าจะสำคัญกับลูกค้าองค์กรหรือผู้ให้บริการคลาวด์อย่าง Amazon, Google มากกว่าผู้ใช้ Redis ทั่วไปส่วนใหญ่ ถ้าไม่ได้ต้องรับโหลดมหาศาลหรือผู้ใช้จำนวนมากพร้อมกัน โดยมาก Redis ก็ใช้ CPU ต่ำอยู่แล้วจนไม่จำเป็นต้องเปิดใช้ด้วยซ้ำ ช่วงนี้ใน Redis เรากำลังพัฒนา vector set data type และกำหนดให้ threading เป็นค่าเริ่มต้น รวมถึงทำให้การเขียน vector set ผ่าน VADD ทำงานแบบ threaded ได้ด้วย โครงสร้างข้อมูลอย่าง HNSW มี constant factor ขนาดใหญ่มากเป็นครั้งแรกในประวัติศาสตร์ Redis ทำให้พื้นที่การออกแบบเปลี่ยนไปเลย ก่อนหน้านี้ฉันก็เคยทำ thread support สำหรับโมดูลไว้แล้วเหมือนกัน การจะใช้ threads หรือไม่เป็นการตัดสินใจที่ขึ้นกับบริบท
  • มุมมองที่ละเอียดอ่อนแบบนี้ดึงคลิกไม่ได้จริง ๆ
  • รู้สึกว่าบทวิจารณ์แนวนี้ขึ้นหน้าแรก HN ทุกเดือน ฉันเองก็อยากเชียร์ antirez มาตลอด ฉันเห็นด้วยกับประเด็นทางเทคนิค แต่ก็คิดว่าคำวิจารณ์แบบนี้หลายครั้งไม่ใช่เรื่องรายละเอียดเชิงรูปธรรมเท่าไรนัก แต่เกี่ยวกับ tall poppy syndrome แบบคลาสสิก คือคนชอบโจมตีคนที่ประสบความสำเร็จมากกว่า เพราะเราไปควบคุมปฏิกิริยาของคนอื่นไม่ได้ การมองบทวิจารณ์เหล่านี้ว่าเป็นการยอมรับทางอ้อมว่าคุณทำผลงานได้ยิ่งใหญ่ อาจเป็นท่าทีที่ดีต่อสุขภาพใจกว่า และก็ขอบคุณที่เชื่อมต่อกันบน LinkedIn ด้วย ดูเรื่อง Tall poppy syndrome
• จำได้ว่า antirez เคยประกาศว่าจะทำให้ Redis กลับมาเป็นโอเพนซอร์สอีกครั้ง โพสต์ที่เกี่ยวข้อง เมื่อก่อน Node.js เองก็เกือบพังเพราะกรณีแตก fork เป็น Io.js แต่ชุมชนก็ช่วยกู้กลับมาได้ เลยสงสัยว่า Redis จะฟื้นแบบนั้นได้ไหม ฉันเคยใช้ Redis บ่อยมาก แต่ช่วงหลายปีหลังไม่ได้ตามความเคลื่อนไหวของชุมชนเท่าไร
  • เท่าที่เช็กครั้งล่าสุด Redis ยังบังคับใช้ CLA (Contributor License Agreement) อยู่ ซึ่งหมายความว่ายังมีสิทธิ์ผูกขาดที่จะปิดซอร์สอีกเมื่อไรก็ได้ ถ้ายังต้องให้ผู้ร่วมพัฒนายอมรับเงื่อนไขแบบนี้ ก็ไม่มีเหตุผลให้เชื่อว่าจะไม่เกิดเรื่องเดิมอีก
  • Redis แจกภายใต้ AGPL ส่วน Valkey ใช้ไลเซนส์ BSD (ซึ่งเป็นไลเซนส์ Redis เดิม) ทั้งคู่เป็นไลเซนส์โอเพนซอร์สอย่างเป็นทางการ แต่ BSD ให้อิสระมากกว่ามาก
  • เอาจริง ๆ ผู้ใช้ 99% ไม่สนหรอกว่าใครเป็นเจ้าของ ขอแค่ key-value store ฟรีที่ใช้งานได้ดีก็พอ ในเชิงธุรกิจ Redis อยู่ในตำแหน่งที่ค่อนข้างแปลก คือมีฟีเจอร์มหาศาลแต่ผู้ใช้จริงใช้แค่ 5% และก็ไม่ได้สนใจฟีเจอร์ซับซ้อนอย่าง Sentinel/Streams ด้วยซ้ำ พอจะทำเป็นของเสียเงิน ตัวเลือกของผู้ใช้ก็มีทั้ง “เลิกใช้ไปเลย”, “ย้ายไปคู่แข่ง”, “ทำเฉพาะฟีเจอร์ที่ต้องใช้เอง”, หรือ “fork เวอร์ชันโอเพนซอร์สตัวสุดท้ายแล้วดูแลเองเพื่อลดต้นทุน” เมื่อเทียบกับ PostgreSQL แล้ว Redis เวอร์ชันเรียบง่ายกว่าอย่างแฮชแมปบวก network interface นั้นสร้างใช้เองได้ง่ายกว่า จึงทำให้หลายธุรกิจมองว่าการ fork หรือทำเองคุ้มกว่า
  • ฉันก็คิดว่าอาจสายเกินไปแล้วเหมือนกัน หลัง Redis เปลี่ยนนโยบายแบบหักมุม สำหรับฉัน Redis กลายเป็นสิ่งที่ไม่น่าไว้ใจ และจากนี้ไป Valkey คือทางเลือกเริ่มต้น โดนหลอกครั้งหนึ่งแล้วจะไม่เชื่อเป็นครั้งที่สอง
  • หลังจากเรื่องที่ Redis ทำไว้ จะให้เชื่อใจได้อย่างไร
• ฉันคิดว่า Valkey ควรเข้าไปอยู่ใน package manager ของดิสโทรหลักเป็นค่าปกติ อย่างตอนจะติดตั้งบน GitHub Action runner ต้องคอยเพิ่ม key และอัปเดตดิสโทรทุกครั้ง มันวุ่นวาย
  • สงสัยว่าดิสโทรไหนที่ยังไม่มี ข้อมูลจาก repology ดูเหมือนว่ามีใน nixpkgs, Arch, Ubuntu, Fedora, Debian, EPEL แล้ว เพียงแต่ Debian ต้องเป็น 13 หรือ 12+backports
  • เพิ่มเติมคือบน Arch Linux ตอนนี้ Valkey แทนที่ Redis ไปแล้ว
  • ถ้าใน CI งานแรกหลังดึง container image มาคือต้องติดตั้งของพวกนี้เอง การทำ image ของตัวเองน่าจะดีกว่า
• รู้สึกดีมากที่การเปลี่ยนแปลงแบบนี้เกิดขึ้นและ Valkey ก็ไปได้สวยอย่างต่อเนื่อง หวังว่า Redis จะหายไปในไม่ช้า
  • น้ำเสียงประชดว่าโอเพนซอร์สมีไว้เพื่อบริษัทยักษ์ผูกขาด โดย hyperscaler อย่าง AWS หาเงินกับ Redis ได้หลายร้อยล้านดอลลาร์ แต่คนพัฒนาและผู้มีส่วนร่วมจริง ๆ กลับไม่ได้ประโยชน์นั้น จึงมองว่าสตาร์ตอัปฐานข้อมูลควรเริ่มต้นด้วย fair source ตั้งแต่แรก คือมีเงื่อนไข anti-hyperscaler อยู่ในไลเซนส์ เพื่อให้ใครจะเอาโค้ดไปใช้ก็ได้ แต่ถ้า AWS หรือ Google จะเอาไปทำ Managed Service ต้องจ่ายเงิน ส่วน Redis และ Elasticsearch ที่เริ่มต้นด้วยไลเซนส์แบบ permissive มาก ๆ ไปแล้ว ก็แทบย้อนกลับไม่ได้
• ช่วงนี้มีหลายโปรเจกต์ dotnet เปลี่ยนไปเป็นเชิงพาณิชย์มากขึ้น สำหรับนักพัฒนามันให้ความรู้สึกเหมือน rug pull หรือการหักหลังความเชื่อใจแบบฉับพลัน และบรรยากาศแบบนี้อาจกระทบการยอมรับไลบรารีโอเพนซอร์ส dotnet อื่น ๆ ด้วย
  • สำหรับ .NET แนวโน้มเชิงพาณิชย์แบบนี้ไม่ใช่เรื่องใหม่เลย เดิมทีโลกนี้ก็ผูกกับ freeware/open-core และธุรกิจมาโดยตลอดอยู่แล้ว
• ฉันได้ยินชื่อ Valkey มาตั้งแต่ปีที่แล้ว และก็ดีใจที่มันยังไปได้ดีอยู่
• สงสัยว่า Valkey มี client library ของตัวเองหรือไม่ ตอนนี้ในสภาพแวดล้อม GCP ฉันใช้ทั้ง Redis/Redis Cluster บน MemoryStore และแบบที่ดูแลเอง โดย official C library น่าผิดหวังมากเมื่อต้องใช้ Redis Cluster+TLS จนต้องพึ่ง client ที่ไม่เป็นทางการอย่าง hiredis-cluster (https://github.com/Nordix/hiredis-cluster) ส่วน Memorystore ของ GCP เองก็ไม่ค่อยประทับใจ กำลังพิจารณาย้ายไป Scylla
  • มี official fork ชื่อ libvalkey ที่รวม hiredis และ hiredis-cluster เข้าด้วยกัน โดยดูแลโดยผู้ดูแลเดิมของ hiredis/hiredis-cluster ดู libvalkey
• ตอนนี้ Redis เปลี่ยนนโยบายแล้ว เลยสงสัยว่า Valkey กับ Redis จะคุยกันแล้วรวมกลับมาได้ไหม
  • มีคนชี้ว่าไลเซนส์ไม่ได้กลับไปเหมือนเดิม แต่ย้ายไป AGPL ดังนั้นมันไม่ใช่การกลับลำจริง ๆ
• มีการแชร์ลิงก์บทความที่อธิบายเรื่อง GPL FUD (ความกลัว ความไม่แน่นอน และความสงสัย) ที่คาดว่าจะเกิดขึ้นได้ดีมาก บทความที่เกี่ยวข้อง
  • ฉันคิดว่าการบอกว่าไลเซนส์แบบ copyleft “เสรีกว่า” เป็นตรรกะที่ค่อนข้างง่ายเกินไป เพราะยิ่งมีภาระผูกพันมาก อิสระก็ยิ่งน้อยลงในอีกความหมายหนึ่ง ดังนั้นการถกกันว่าแนวไหน “เสรีกว่า” น่าจะเป็นประเด็นที่ลึกกว่านั้น
• ฉันใช้ Redis อยู่ในแอปหลายสิบตัว AWS มี Valkey ให้ใช้ในราคาลด เลยลองใช้เมื่อ 2 เดือนก่อน และก็ไม่รู้สึกถึงความต่างด้านประสิทธิภาพเลย แต่จู่ ๆ Valkey ก็หยุดตอบสนอง ทั้งที่ AWS ยังมองว่า instance ทำงานปกติ แต่การเชื่อมต่อขาดไปหมด เกิน 12 ชั่วโมงก็ยังกู้ไม่กลับ และยังเกิดซ้ำอีก AWS ใช้เวลาสืบสวน 2 สัปดาห์ก็ยังหาสาเหตุไม่เจอ หลังจากนั้นฉันคงใช้ Valkey กับงาน mission-critical ได้ยากแล้ว พอเปลี่ยนกลับไป Redis ด้วย workload เดิม ปัญหาก็ไม่เกิด
  • น่าจะเป็นปัญหาฝั่ง AWS ก็ได้ เราเองก็เคยเจอคล้ายกันกับ production RDS postgres cluster มันหยุดตอบสนองทางเครือข่าย และแม้จะมี AWS enterprise support สุดท้ายก็ต้องกู้จาก backup แล้วสร้างคลัสเตอร์ใหม่เอง ใช้เวลา 4 ชั่วโมง หลังจากนั้นเราก็หลีกเลี่ยงบริการแบบ encapsulated ของ AWS แล้วหันไปใช้ EC2 ปกติพร้อม replication, snapshot, และการทำสำเนาไป S3 แทน
  • อาจเป็นปัญหาด้านการปฏิบัติการของ AWS ก็ได้ ฉันเคยรันแต่ Redis เอง แต่ก็ยังคิดว่าอาจไม่ใช่ปัญหาของ Valkey โดยตรง
  • ทำไมถึงไม่รัน instance ของ Valkey เองล่ะ
  • อยากรู้ว่าใช้ instance type อะไร เผื่อเป็นข้อมูลอ้างอิง