תצורת אשכול Kafka: שכפול, חלוקה ואבחון

תצורת Kafka Cluster: שכפול, חלוקה ואבחון

למה ה-Kafka Cluster שלך עשוי לתפקד בצורה לא מיטבית

לעתים קרובות אנו נתקלים בתרחיש הזה: שלושה brokers פעילים, נוצרו topics, האפליקציה כותבת — אבל תחת עומס, UnderReplicatedPartitions גדל, ה-consumer lag לא יורד, ובחירות leader מתרחשות כל כמה דקות. זו לא בעיית חומרה — זה replication.factor שגוי, min.insync.replicas שגוי, והיעדר הקצאה מודעת ל-rack. כל זה חייב להיות מוגדר במהלך תצורה ראשונית של ה-cluster — לשנות זאת מאוחר יותר עולה יותר מאשר להזמין audit מלא. צור קשר כדי להעריך את הפרויקט שלך ולמצוא את הפתרון האופטימלי. תצורת cluster נכונה מפחיתה עלויות תפעול ב-20–30% באמצעות צמצום זמני השבתה וניצול יעיל של משאבים. מהנדסי Kafka המוסמכים שלנו מבטיחים audit יסודי והפחתה של 10% בעלויות התפעול או שלא תשלם. ניסיון: למעלה מ-40 פרויקטים.

Replication Factor 3: למה זה לא מספיק

Replication factor שלוש הוא הכרחי אבל לא מספיק. אם שלושת ה-brokers נמצאים באותו rack ומוזנים מאותו PDU, הפסקת חשמל מפילה את כל ה-cluster בבת אחת. עם rack-awareness, העמידות משתפרת פי 3 בפריסות מרובות racks. Kafka תומך ב-rack-awareness דרך broker.rack ב-server.properties — ויש להגדיר זאת לפני יצירת ה-topic הראשון, אחרת leaders ו-replicas יחולקו ללא התחשבות בטופולוגיה.

# broker 1 — server.properties
broker.id=1
broker.rack=rack-a
log.dirs=/data/kafka/logs
num.partitions=6
default.replication.factor=3
min.insync.replicas=2
unclean.leader.election.enable=false

# broker 1 — server.properties broker.id=1 broker.rack=rack-a log.dirs=/data/kafka/logs num.partitions=6 default.replication.factor=3 min.insync.replicas=2 unclean.leader.election.enable=false הוא פרמטר מפתח עבור סביבת production. בלעדיו, Kafka עלול לבחור leader מתוך replica שאינה מסונכרנת, מה שיוביל לאובדן נתונים. כן, ה-cluster לא יהיה זמין לכתיבה למשך כמה שניות אם מניין ה-ISR יאבד — אבל זה תרחיש צפוי שמטופל בצד ה-producer באמצעות retry. אובדן נתונים אינו כזה.

בצד ה-producer:

acks=all retries=3 retry.backoff.ms=500 enable.idempotence=true 

unclean.leader.election.enable=false מגדיר אוטומטית את acks=all retries=3 retry.backoff.ms=500 enable.idempotence=true ומבטל כפילויות בעת retry. עבור רוב התרחישים ב-production, זו ברירת המחדל שיש להפעיל במפורש.

מספר Partitions אופטימלי

העצה הפופולרית "הגדר יותר partitions" עובדת עד גבול מסוים. כל partition הוא file descriptor על כל broker, בנוסף למטא-דאטה ב-ZooKeeper (או KRaft). ב-10,000 partitions על cluster של שלושה brokers, ה-controller failover מתחיל לקחת עשרות שניות.

כלל מעשי: enable.idempotence=true. עבור topic עם throughput של 100 MB/s ו-8 מופעי consumer — 10 partitions, לא 100.

חלוקה משפיעה על מקביליות הצריכה: consumer אחד בקבוצה קורא partition אחד או יותר, אבל לפחות אחד. אם יש פחות partitions מאשר מופעים בקבוצת consumers, חלק מהמופעים יהיו בטלים. זו בעיה נפוצה בעת scaling אופקי של consumers ללא תכנון טופולוגיית ה-topic.

ניתן לשנות את מספר ה-partitions של topic קיים:

kafka-topics.sh --bootstrap-server kafka:9092 \ --alter --topic orders \ --partitions 20 

אבל זה משבש את סדר המפתחות — אם יש לך partitioning מבוסס מפתחות וסמנטיקה כמו "כל האירועים של הזמנה אחת הולכים לאותו partition", הגדלת partitions דורשת migration או יצירה מחדש של ה-topic עם rebalancing.

כיצד להגדיר Rack Awareness

בצע את השלבים הבאים:

1. הגדר את הפרמטר acks=all ב-partitions = max(throughput_mb/s ÷ 10, consumer_count) על כל broker (לדוגמה, kafka-topics.sh --bootstrap-server kafka:9092 \ --alter --topic orders \ --partitions 20 ).
2. הפעל מחדש את ה-Kafka cluster.
3. ודא את החלוקה באמצעות broker.rack. ה-replicas צריכות להיות מפוזרות על פני racks.

אם כל ה-replicas של partition מסוים נמצאות באותו rack — ה-rack-awareness לא עובד. סיבה נפוצה: ערכי server.properties שונים או פרמטר חסר על חלק מה-brokers.

מדדים קריטיים לניטור

kafka-topics.sh --bootstrap-server kafka:9092 --describe --topic orders הוא הכלי הראשון. הוא מציג את רשימת ה-ISR עבור כל partition:

kafka-topics.sh --bootstrap-server kafka:9092 --describe --topic orders 

אם ISR קטן מ-replication factor — ה-broker מושבת או בפיגור. broker.rack מציג את הגודל וה-offset של כל replica. kafka-topics.sh --describe — lag לכל partition בקבוצת consumers.

מדדי JMX שחובה לנטר:

OfflinePartitionsCount אומר שה-broker עמוס — או להוסיף brokers או להפחית עומס. מדד זה לעתים קרובות לא מוגדר, ואנשים מופתעים מהשהייה growing למרות משאבים שנראים מספקים. ניטור נכון מפחית את זמן התגובה לאירועים ב-50%.

בחירת מצב Metadata: KRaft לעומת ZooKeeper

כיום, KRaft (Kafka Raft Metadata mode) — ללא ZooKeeper — יציב מאז Kafka 3.3 ומומלץ עבור clusters חדשים. יתרונות עיקריים: controller failover לוקח שניות במקום עשרות שניות (פי 3–5 מהר יותר), ניהול תפעולי פשוט יותר. ZooKeeper כתלות יוסר ב-Kafka 4.x.

לפי תיעוד Apache Kafka, KRaft מספק אמינות ופשטות גבוהות יותר.

לצורך migration של cluster קיים מ-ZooKeeper ל-KRaft — ההליך RequestHandlerAvgIdlePercent + NetworkProcessorAvgIdlePercent — היא משימה נפרדת עם חלון השבתה או migration הדרגתי בהתאם לגרסה.

מה כלול בעבודה שלנו

• Audit מפורט של תצורת ה-cluster (broker, producer, consumer).
• עיצוב טופולוגיית topics וחלוקה.
• הגדרת rack-awareness ופרמטרי שכפול.
• הקמת ניטור (Prometheus + Grafana) עם התראות קריטיות.
• תיעוד תפעולי ו-runbook למקרי חירום.
• הדרכת צוות (1–2 מפגשים).
• תמיכה ל-30 יום לאחר המסירה.

לוחות זמנים: cluster חדש מאפס — 2–3 ימים; audit ו-reconfiguration של cluster production קיים עם השבתה מינימלית — 4–5 ימים. התמחור מחושב באופן אישי לאחר audit של התשתית. הערך את הפרויקט שלך — קבל ייעוץ. השלמנו למעלה מ-40 פרויקטים של אופטימיזציית Kafka, המאשרים את המומחיות שלנו. הלקוחות שלנו מדווחים על חיסכון ממוצע של $5,000 בחודש בהפחתת זמני השבתה וניצול אופטימלי של משאבים.