Kubernetes-এ একটি কাফকা ক্লাস্টারের জন্য উপযুক্ত আকার নির্ধারণ করুন

বিঃদ্রঃ. অনুবাদ: এই নিবন্ধে, বানজাই ক্লাউড কীভাবে এর কাস্টম সরঞ্জামগুলি কুবারনেটসের মধ্যে কাফকাকে ব্যবহার করা সহজ করতে ব্যবহার করা যেতে পারে তার একটি উদাহরণ শেয়ার করেছে। নিম্নলিখিত নির্দেশাবলী ব্যাখ্যা করে যে আপনি কীভাবে আপনার অবকাঠামোর সর্বোত্তম আকার নির্ধারণ করতে পারেন এবং প্রয়োজনীয় থ্রুপুট অর্জনের জন্য কাফকা নিজেই কনফিগার করতে পারেন।

Apache Kafka নির্ভরযোগ্য, মাপযোগ্য এবং উচ্চ-পারফরম্যান্স রিয়েল-টাইম স্ট্রিমিং সিস্টেম তৈরি করার জন্য একটি বিতরণ করা স্ট্রিমিং প্ল্যাটফর্ম। কুবারনেটস ব্যবহার করে এর চিত্তাকর্ষক ক্ষমতা বাড়ানো যেতে পারে। এ জন্য আমরা উন্নয়ন করেছি ওপেন সোর্স কাফকা অপারেটর এবং একটি টুল বলা হয় সুপারটিউব. তারা আপনাকে Kubernetes-এ কাফকা চালানোর অনুমতি দেয় এবং এর বিভিন্ন বৈশিষ্ট্য ব্যবহার করতে দেয়, যেমন ব্রোকার কনফিগারেশনকে ফাইন-টিউনিং, রিব্যালেন্সিং সহ মেট্রিক-ভিত্তিক স্কেলিং, র্যাক সচেতনতা, "নরম" (সুন্দর) আপডেট রোল আউট, ইত্যাদি

আপনার ক্লাস্টারে সুপারটিউব ব্যবহার করে দেখুন:

curl https://getsupertubes.sh | sh и supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

অথবা যোগাযোগ করুন ডকুমেন্টেশন. আপনি কাফকার কিছু ক্ষমতা সম্পর্কেও পড়তে পারেন, যার সাথে কাজটি সুপারটিউব এবং কাফকা অপারেটর ব্যবহার করে স্বয়ংক্রিয় হয়। আমরা ইতিমধ্যে ব্লগে তাদের সম্পর্কে লিখেছি:

• ওহ না! কুবারনেটসের জন্য আরেকটি কাফকা অপারেটর;
• প্রমিথিউস মেট্রিক্সের উপর ভিত্তি করে কাফকা নিরীক্ষণ এবং পরিচালনা করুন;
• Kubernetes সম্পর্কে কাফকা রাক সচেতনতা;
• ইসটিওর উপরে অ্যাপাচি কাফকা চালানো - বেঞ্চমার্ক;
• কাফকা অপারেটরের সাথে ব্যবহারকারীর প্রমাণীকরণ এবং অ্যাক্সেস নিয়ন্ত্রিত ক্লাস্টার;
• Kubernetes-এ কাফকা রোলিং আপগ্রেড এবং গতিশীল কনফিগারেশন;
• কাফকার জন্য দূত প্রোটোকল ফিল্টার, মেশড.

আপনি যখন Kubernetes-এ একটি কাফকা ক্লাস্টার স্থাপন করার সিদ্ধান্ত নেবেন, তখন আপনি সম্ভবত অন্তর্নিহিত অবকাঠামোর সর্বোত্তম আকার নির্ধারণের চ্যালেঞ্জের মুখোমুখি হবেন এবং থ্রুপুট প্রয়োজনীয়তাগুলি পূরণ করার জন্য আপনার কাফকা কনফিগারেশনকে সূক্ষ্ম-সুর করার প্রয়োজন হবে। প্রতিটি ব্রোকারের সর্বাধিক কর্মক্ষমতা অন্তর্নিহিত অবকাঠামো উপাদানগুলির কার্যক্ষমতা দ্বারা নির্ধারিত হয়, যেমন মেমরি, প্রসেসর, ডিস্কের গতি, নেটওয়ার্ক ব্যান্ডউইথ ইত্যাদি।

আদর্শভাবে, ব্রোকার কনফিগারেশন এমন হওয়া উচিত যাতে সমস্ত অবকাঠামো উপাদানগুলি তাদের সর্বোচ্চ ক্ষমতার সাথে ব্যবহার করা হয়। তবে, বাস্তব জীবনে এই সেটআপটি বেশ জটিল। এক বা দুটি উপাদানের (ডিস্ক, মেমরি, বা প্রসেসর) ব্যবহার সর্বাধিক করার জন্য ব্যবহারকারীরা ব্রোকারদের কনফিগার করার সম্ভাবনা বেশি। সাধারণভাবে বলতে গেলে, একটি ব্রোকার সর্বাধিক কর্মক্ষমতা দেখায় যখন এর কনফিগারেশন ধীরতম উপাদানটিকে তার সম্পূর্ণ পরিমাণে ব্যবহার করার অনুমতি দেয়। এইভাবে আমরা একজন দালাল যে লোড পরিচালনা করতে পারে তার মোটামুটি ধারণা পেতে পারি।

তাত্ত্বিকভাবে, আমরা একটি প্রদত্ত লোড পরিচালনা করার জন্য প্রয়োজনীয় দালালের সংখ্যাও অনুমান করতে পারি। যাইহোক, অনুশীলনে বিভিন্ন স্তরে এত বেশি কনফিগারেশন বিকল্প রয়েছে যে একটি নির্দিষ্ট কনফিগারেশনের সম্ভাব্য কার্যকারিতা মূল্যায়ন করা খুব কঠিন (যদি অসম্ভব না হয়)। অন্য কথায়, কিছু প্রদত্ত কর্মক্ষমতার উপর ভিত্তি করে একটি কনফিগারেশন পরিকল্পনা করা খুব কঠিন।

সুপারটিউব ব্যবহারকারীদের জন্য, আমরা সাধারণত নিম্নলিখিত পদ্ধতি অবলম্বন করি: আমরা কিছু কনফিগারেশন (অবকাঠামো + সেটিংস) দিয়ে শুরু করি, তারপর এর কার্যকারিতা পরিমাপ করি, ব্রোকার সেটিংস সামঞ্জস্য করি এবং প্রক্রিয়াটি আবার পুনরাবৃত্তি করি। অবকাঠামোর ধীরতম উপাদানটি সম্পূর্ণরূপে ব্যবহার না হওয়া পর্যন্ত এটি ঘটে।

এইভাবে, একটি ক্লাস্টারকে একটি নির্দিষ্ট লোড পরিচালনা করার জন্য কতজন ব্রোকার প্রয়োজন সে সম্পর্কে আমরা একটি পরিষ্কার ধারণা পাই (দালালের সংখ্যা অন্যান্য কারণের উপরও নির্ভর করে, যেমন স্থিতিস্থাপকতা নিশ্চিত করার জন্য ন্যূনতম বার্তা প্রতিলিপির সংখ্যা, পার্টিশনের সংখ্যা। নেতা, ইত্যাদি)। উপরন্তু, আমরা অন্তর্দৃষ্টি অর্জন করি কোন অবকাঠামোর উপাদানগুলির উল্লম্ব স্কেলিং প্রয়োজন।

এই নিবন্ধটি প্রাথমিক কনফিগারেশনে সবচেয়ে ধীরগতির উপাদানগুলি থেকে সর্বাধিক পেতে এবং কাফকা ক্লাস্টারের থ্রুপুট পরিমাপ করার জন্য আমরা যে পদক্ষেপগুলি নিয়েছি সে সম্পর্কে কথা বলবে। একটি অত্যন্ত স্থিতিস্থাপক কনফিগারেশনের জন্য কমপক্ষে তিনজন চলমান দালালের প্রয়োজন (min.insync.replicas=3), তিনটি ভিন্ন অ্যাক্সেসিবিলিটি জোন জুড়ে বিতরণ করা হয়েছে। Kubernetes পরিকাঠামো কনফিগার, স্কেল এবং নিরীক্ষণ করতে, আমরা হাইব্রিড ক্লাউডের জন্য আমাদের নিজস্ব কন্টেইনার ম্যানেজমেন্ট প্ল্যাটফর্ম ব্যবহার করি - পাইপলাইন. এটি অন-প্রিমিস (বেয়ার মেটাল, ভিএমওয়্যার) এবং পাঁচ ধরনের ক্লাউড (আলিবাবা, এডব্লিউএস, অ্যাজুরে, গুগল, ওরাকল) এবং সেইসাথে তাদের যেকোন সমন্বয় সমর্থন করে।

কাফকা ক্লাস্টার অবকাঠামো এবং কনফিগারেশন নিয়ে চিন্তাভাবনা

নীচের উদাহরণগুলির জন্য, আমরা ক্লাউড প্রদানকারী হিসাবে AWS এবং Kubernetes বিতরণ হিসাবে EKS বেছে নিয়েছি। একটি অনুরূপ কনফিগারেশন ব্যবহার করে বাস্তবায়ন করা যেতে পারে PKE - Banzai ক্লাউড থেকে Kubernetes বিতরণ, CNCF দ্বারা প্রত্যয়িত।

ডিস্ক

অ্যামাজন বিভিন্ন অফার দেয় ইবিএস ভলিউম প্রকার. মুলে gp2 и io1 উচ্চ থ্রুপুট নিশ্চিত করার জন্য SSD ড্রাইভ রয়েছে gp2 সঞ্চিত ক্রেডিট গ্রাস করে (I/O ক্রেডিট), তাই আমরা টাইপ পছন্দ করেছি io1, যা সামঞ্জস্যপূর্ণ উচ্চ থ্রুপুট অফার করে।

উদাহরণ প্রকার

কাফকার কর্মক্ষমতা অপারেটিং সিস্টেমের পৃষ্ঠা ক্যাশের উপর অত্যন্ত নির্ভরশীল, তাই আমাদের ব্রোকার (JVM) এবং পৃষ্ঠা ক্যাশের জন্য যথেষ্ট মেমরি সহ দৃষ্টান্ত প্রয়োজন। দৃষ্টান্ত c5.2x বড় - একটি ভাল শুরু, যেহেতু এতে 16 গিগাবাইট মেমরি রয়েছে এবং EBS এর সাথে কাজ করার জন্য অপ্টিমাইজ করা হয়েছে. এর অসুবিধা হ'ল এটি প্রতি 30 ঘন্টায় 24 মিনিটের বেশি না সর্বোচ্চ কার্যক্ষমতা প্রদান করতে সক্ষম। যদি আপনার কাজের চাপের জন্য দীর্ঘ সময়ের জন্য সর্বোচ্চ কর্মক্ষমতা প্রয়োজন, তাহলে আপনি অন্যান্য উদাহরণের ধরন বিবেচনা করতে চাইতে পারেন। এটা ঠিক কি আমরা, এ থামানো c5.4x বড়. এটি সর্বোচ্চ থ্রুপুট প্রদান করে 593,75 Mb/s. একটি EBS ভলিউমের সর্বোচ্চ থ্রুপুট io1 উদাহরণের চেয়ে বেশি c5.4x বড়, তাই অবকাঠামোর সবচেয়ে ধীরগতির উপাদানটি এই ইন্সট্যান্স টাইপের I/O থ্রুপুট হতে পারে (যা আমাদের লোড পরীক্ষাগুলিও নিশ্চিত হওয়া উচিত)।

নেটওয়ার্কের

VM ইন্সট্যান্স এবং ডিস্কের পারফরম্যান্সের তুলনায় নেটওয়ার্ক থ্রুপুট যথেষ্ট বড় হতে হবে, অন্যথায় নেটওয়ার্ক একটি বাধা হয়ে দাঁড়ায়। আমাদের ক্ষেত্রে, নেটওয়ার্ক ইন্টারফেস c5.4x বড় 10 Gb/s পর্যন্ত গতি সমর্থন করে, যা একটি VM ইন্সট্যান্সের I/O থ্রুপুট থেকে উল্লেখযোগ্যভাবে বেশি।

দালাল স্থাপনা

CPU, মেমরি, নেটওয়ার্ক এবং ডিস্ক সংস্থানগুলির জন্য অন্যান্য প্রক্রিয়াগুলির সাথে প্রতিযোগিতা এড়াতে ব্রোকারদের ডেডিকেটেড নোডগুলিতে (কুবারনেটে নির্ধারিত) স্থাপন করা উচিত।

জাভা সংস্করণ

যৌক্তিক পছন্দ হল জাভা 11 কারণ এটি ডকারের সাথে সামঞ্জস্যপূর্ণ এই অর্থে যে JVM সঠিকভাবে নির্ধারণ করে যে কন্টেইনারে ব্রোকার চলছে তার জন্য উপলব্ধ প্রসেসর এবং মেমরি। CPU সীমাগুলি গুরুত্বপূর্ণ জেনে, JVM অভ্যন্তরীণভাবে এবং স্বচ্ছভাবে GC থ্রেড এবং JIT থ্রেডের সংখ্যা সেট করে। আমরা কাফকার ছবি ব্যবহার করেছি banzaicloud/kafka:2.13-2.4.0, যা Java 2.4.0-এ কাফকা সংস্করণ 2.13 (Scala 11) অন্তর্ভুক্ত করে।

আপনি যদি Kubernetes-এ Java/JVM সম্পর্কে আরও জানতে চান, আমাদের নিম্নলিখিত পোস্টগুলি দেখুন:

• কেন আমার জাভা অ্যাপ্লিকেশন OOMKilled হয়?;
• জাভা 10 অ্যাপ্লিকেশনের জন্য পাত্রে সঠিকভাবে আকার কিভাবে.

ব্রোকার মেমরি সেটিংস

ব্রোকার মেমরি কনফিগার করার দুটি মূল দিক রয়েছে: JVM এবং কুবারনেটস পডের জন্য সেটিংস। একটি পডের জন্য মেমরির সীমা সেট করা অবশ্যই সর্বোচ্চ হিপ সাইজের চেয়ে বেশি হতে হবে যাতে JVM-এর নিজস্ব মেমরিতে থাকা জাভা মেটাস্পেস এবং কাফকা সক্রিয়ভাবে ব্যবহার করা অপারেটিং সিস্টেম পৃষ্ঠা ক্যাশে জন্য জায়গা থাকে। আমাদের পরীক্ষায় আমরা প্যারামিটার সহ কাফকা ব্রোকার চালু করেছি -Xmx4G -Xms2G, এবং পড জন্য মেমরি সীমা ছিল 10 Gi. দয়া করে মনে রাখবেন যে JVM এর জন্য মেমরি সেটিংস স্বয়ংক্রিয়ভাবে ব্যবহার করে প্রাপ্ত করা যেতে পারে -XX:MaxRAMPercentage и -X:MinRAMPercentage, পডের মেমরি সীমার উপর ভিত্তি করে।

ব্রোকার প্রসেসর সেটিংস

সাধারণভাবে বলতে গেলে, আপনি কাফকা দ্বারা ব্যবহৃত থ্রেডের সংখ্যা বাড়িয়ে সমান্তরালতা বৃদ্ধি করে কর্মক্ষমতা উন্নত করতে পারেন। কাফকার জন্য যত বেশি প্রসেসর উপলব্ধ, তত ভাল। আমাদের পরীক্ষায়, আমরা 6টি প্রসেসরের সীমা দিয়ে শুরু করেছি এবং ধীরে ধীরে (পুনরাবৃত্তির মাধ্যমে) তাদের সংখ্যা 15 এ উন্নীত করেছি। উপরন্তু, আমরা সেট করেছি num.network.threads=12 ব্রোকার সেটিংসে থ্রেডের সংখ্যা বাড়াতে যা নেটওয়ার্ক থেকে ডেটা গ্রহণ করে এবং পাঠায়। অবিলম্বে আবিষ্কার যে অনুগামী দালালরা যথেষ্ট দ্রুত প্রতিলিপি পেতে পারে না, তারা উত্থাপন num.replica.fetchers অনুগামী দালালরা নেতাদের কাছ থেকে বার্তা প্রতিলিপি করার গতি বাড়াতে 4 থেকে।

লোড জেনারেশন টুল

কাফকা ক্লাস্টার (যা বেঞ্চমার্ক করা হচ্ছে) সর্বোচ্চ লোডে পৌঁছনোর আগে আপনার নির্বাচিত লোড জেনারেটরের ক্ষমতা শেষ না হয় তা নিশ্চিত করা উচিত। অন্য কথায়, লোড জেনারেশন টুলের ক্ষমতাগুলির একটি প্রাথমিক মূল্যায়ন করা প্রয়োজন, এবং পর্যাপ্ত সংখ্যক প্রসেসর এবং মেমরি সহ এটির জন্য দৃষ্টান্তের প্রকারগুলিও নির্বাচন করা প্রয়োজন। এই ক্ষেত্রে, আমাদের টুল কাফকা ক্লাস্টার পরিচালনা করতে পারে তার চেয়ে বেশি লোড তৈরি করবে। অনেক পরীক্ষা-নিরীক্ষার পর আমরা তিনটি কপিতে স্থির হয়েছি c5.4x বড়, যার প্রতিটিতে একটি জেনারেটর চলমান ছিল।

বেঞ্চমার্কিং

কর্মক্ষমতা পরিমাপ একটি পুনরাবৃত্তিমূলক প্রক্রিয়া যা নিম্নলিখিত ধাপগুলি অন্তর্ভুক্ত করে:

• অবকাঠামো স্থাপন (ইকেএস ক্লাস্টার, কাফকা ক্লাস্টার, লোড জেনারেশন টুল, সেইসাথে প্রমিথিউস এবং গ্রাফানা);
• সংগৃহীত কর্মক্ষমতা সূচকে এলোমেলো বিচ্যুতি ফিল্টার করার জন্য একটি নির্দিষ্ট সময়ের জন্য একটি লোড তৈরি করা;
• পর্যবেক্ষণ করা কর্মক্ষমতা সূচকের উপর ভিত্তি করে ব্রোকারের অবকাঠামো এবং কনফিগারেশন সামঞ্জস্য করা;
• কাফকা ক্লাস্টার থ্রুপুটের প্রয়োজনীয় স্তর অর্জন না হওয়া পর্যন্ত প্রক্রিয়াটি পুনরাবৃত্তি করুন। একই সময়ে, এটি অবশ্যই ধারাবাহিকভাবে পুনরুত্পাদনযোগ্য হতে হবে এবং থ্রুপুটে ন্যূনতম বৈচিত্র্য প্রদর্শন করতে হবে।

পরবর্তী বিভাগে পরীক্ষা ক্লাস্টার বেঞ্চমার্কিং প্রক্রিয়ার সময় সম্পাদিত পদক্ষেপগুলি বর্ণনা করা হয়েছে।

যন্ত্র

বেসলাইন কনফিগারেশন দ্রুত স্থাপন করতে, লোড তৈরি করতে এবং কর্মক্ষমতা পরিমাপ করতে নিম্নলিখিত সরঞ্জামগুলি ব্যবহার করা হয়েছিল:

• বনজাই ক্লাউড পাইপলাইন আমাজন থেকে একটি EKS ক্লাস্টার সংগঠিত করার জন্য c প্রমিথিউস (কাফকা এবং অবকাঠামো মেট্রিক্স সংগ্রহ করতে) এবং গ্রাফানা (এই মেট্রিক্স কল্পনা করতে)। আমরা সুবিধা নিলাম সমন্বিত в পাইপলাইন পরিষেবাগুলি যা ফেডারেটেড মনিটরিং, কেন্দ্রীভূত লগ সংগ্রহ, দুর্বলতা স্ক্যানিং, দুর্যোগ পুনরুদ্ধার, এন্টারপ্রাইজ-গ্রেড নিরাপত্তা এবং আরও অনেক কিছু প্রদান করে।
• সাংগ্রেনেল - একটি কাফকা ক্লাস্টার লোড পরীক্ষার জন্য একটি টুল।
• কাফকা মেট্রিক্স এবং অবকাঠামো ভিজ্যুয়ালাইজ করার জন্য গ্রাফানা ড্যাশবোর্ড: কুবারনেটেস কাফকা, নোড এক্সপোর্টার.
• Kubernetes-এ কাফকা ক্লাস্টার সেট আপ করার সবচেয়ে সহজ উপায়ের জন্য Supertubes CLI। জুকিপার, কাফকা অপারেটর, দূত এবং অন্যান্য অনেক উপাদান ইনস্টল করা আছে এবং কুবারনেটসে একটি উৎপাদন-প্রস্তুত কাফকা ক্লাস্টার চালানোর জন্য সঠিকভাবে কনফিগার করা হয়েছে।
  • ইনস্টলেশন জন্য সুপারটিউব CLI প্রদত্ত নির্দেশাবলী ব্যবহার করুন এখানে.

EKS ক্লাস্টার

ডেডিকেটেড ওয়ার্কার নোড সহ একটি EKS ক্লাস্টার প্রস্তুত করুন c5.4x বড় কাফকা ব্রোকারদের সাথে পডের জন্য বিভিন্ন প্রাপ্যতা অঞ্চলে, সেইসাথে লোড জেনারেটর এবং পর্যবেক্ষণ পরিকাঠামোর জন্য ডেডিকেটেড নোড।

banzai cluster create -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/cluster_eks_202001.json

একবার EKS ক্লাস্টার চালু হয়ে গেলে, এটিকে ইন্টিগ্রেটেড সক্রিয় করুন পর্যবেক্ষণ পরিষেবা — সে প্রমিথিউস এবং গ্রাফানাকে একটি ক্লাস্টারে স্থাপন করবে।

কাফকা সিস্টেমের উপাদান

সুপারটিউব CLI ব্যবহার করে EKS-এ Kafka সিস্টেম উপাদান (Zookeeper, kafka-operator) ইনস্টল করুন:

supertubes install -a --no-democluster --kubeconfig <path-to-eks-cluster-kubeconfig-file>

কাফকা ক্লাস্টার

ডিফল্টরূপে, EKS প্রকারের EBS ভলিউম ব্যবহার করে gp2, তাই আপনাকে ভলিউমের উপর ভিত্তি করে একটি পৃথক স্টোরেজ ক্লাস তৈরি করতে হবে io1 কাফকা ক্লাস্টারের জন্য:

kubectl create -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "50"
  fsType: ext4
volumeBindingMode: WaitForFirstConsumer
EOF

দালালদের জন্য প্যারামিটার সেট করুন min.insync.replicas=3 এবং তিনটি ভিন্ন প্রাপ্যতা অঞ্চলে নোডগুলিতে ব্রোকার পড স্থাপন করুন:

supertubes cluster create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f https://raw.githubusercontent.com/banzaicloud/kafka-operator/master/docs/benchmarks/infrastructure/kafka_202001_3brokers.yaml --wait --timeout 600

বিষয়

আমরা সমান্তরালভাবে তিনটি লোড জেনারেটর দৃষ্টান্ত চালিয়েছি। তাদের প্রত্যেকেই তাদের নিজস্ব বিষয়ে লেখেন, অর্থাৎ, আমাদের মোট তিনটি বিষয় প্রয়োজন:

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest1
spec:
  name: perftest1
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
    name: perftest2
spec:
  name: perftest2
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

supertubes cluster topic create -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file> -f -<<EOF
apiVersion: kafka.banzaicloud.io/v1alpha1
kind: KafkaTopic
metadata:
  name: perftest3
spec:
  name: perftest3
  partitions: 12
  replicationFactor: 3
  retention.ms: '28800000'
  cleanup.policy: delete
EOF

প্রতিটি বিষয়ের জন্য, প্রতিলিপির ফ্যাক্টর হল 3—উচ্চ উপলব্ধ উৎপাদন ব্যবস্থার জন্য সর্বনিম্ন প্রস্তাবিত মান।

লোড জেনারেশন টুল

আমরা লোড জেনারেটরের তিনটি কপি চালু করেছি (প্রত্যেকটি একটি পৃথক বিষয়ে লিখেছেন)। লোড জেনারেটর পডের জন্য, আপনাকে নোড অ্যাফিনিটি সেট করতে হবে যাতে সেগুলি শুধুমাত্র তাদের জন্য বরাদ্দ করা নোডগুলিতে নির্ধারিত হয়:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: loadtest
  name: perf-load1
  namespace: kafka
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: loadtest
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: loadtest
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: nodepool.banzaicloud.io/name
                operator: In
                values:
                - loadgen
      containers:
      - args:
        - -brokers=kafka-0:29092,kafka-1:29092,kafka-2:29092,kafka-3:29092
        - -topic=perftest1
        - -required-acks=all
        - -message-size=512
        - -workers=20
        image: banzaicloud/perfload:0.1.0-blog
        imagePullPolicy: Always
        name: sangrenel
        resources:
          limits:
            cpu: 2
            memory: 1Gi
          requests:
            cpu: 2
            memory: 1Gi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

উল্লেখ্য কয়েকটি পয়েন্ট:

• লোড জেনারেটর 512 বাইটের দৈর্ঘ্যের বার্তা তৈরি করে এবং 500টি বার্তার ব্যাচে কাফকাকে প্রকাশ করে।
• একটি যুক্তি ব্যবহার করে -required-acks=all কাফকা দালালদের দ্বারা বার্তার সমস্ত সিঙ্ক্রোনাইজড প্রতিলিপি প্রাপ্ত এবং নিশ্চিত করা হলে প্রকাশনাটি সফল বলে বিবেচিত হয়। এর মানে হল যে বেঞ্চমার্কে আমরা শুধুমাত্র নেতাদের বার্তা গ্রহণের গতিই পরিমাপ করি না, তাদের অনুগামীরাও বার্তার প্রতিলিপি করে। এই পরীক্ষার উদ্দেশ্য ভোক্তা পড়ার গতি মূল্যায়ন করা নয় (ভোক্তা) সম্প্রতি প্রাপ্ত বার্তাগুলি যা এখনও OS পৃষ্ঠার ক্যাশে থেকে যায় এবং ডিস্কে সঞ্চিত বার্তাগুলির পড়ার গতির সাথে এর তুলনা।
• লোড জেনারেটর সমান্তরালভাবে 20 জন কর্মী চালায় (-workers=20) প্রতিটি শ্রমিকের মধ্যে 5 জন প্রযোজক থাকে যারা কাফকা ক্লাস্টারের সাথে শ্রমিকের সংযোগ ভাগ করে নেয়। ফলস্বরূপ, প্রতিটি জেনারেটরের 100 জন প্রযোজক রয়েছে এবং তারা সবাই কাফকা ক্লাস্টারে বার্তা পাঠায়।

ক্লাস্টারের স্বাস্থ্য পর্যবেক্ষণ

কাফকা ক্লাস্টারের লোড পরীক্ষার সময়, আমরা কোনো পড রিস্টার্ট, সিঙ্কের বাইরের কোনো প্রতিলিপি এবং ন্যূনতম ওঠানামা সহ সর্বাধিক থ্রুপুট নেই তা নিশ্চিত করতে এর স্বাস্থ্য পর্যবেক্ষণ করেছি:

• লোড জেনারেটর প্রকাশিত বার্তার সংখ্যা এবং ত্রুটির হার সম্পর্কে স্ট্যান্ডার্ড পরিসংখ্যান লেখে। ত্রুটির হার একই থাকা উচিত 0,00%.
• ক্রুজ নিয়ন্ত্রণ, কাফকা-অপারেটর দ্বারা মোতায়েন, একটি ড্যাশবোর্ড প্রদান করে যেখানে আমরা ক্লাস্টারের অবস্থা নিরীক্ষণ করতে পারি। এই প্যানেলটি দেখতে এটি করুন:

  supertubes cluster cruisecontrol show -n kafka --kubeconfig <path-to-eks-cluster-kubeconfig-file>

• আইএসআর স্তর ("ইন-সিঙ্ক" প্রতিলিপির সংখ্যা) সঙ্কুচিত এবং প্রসারণ 0 এর সমান।

পরিমাপের ফলাফল

3 দালাল, বার্তা আকার - 512 বাইট

তিনটি ব্রোকারের মধ্যে সমানভাবে বিভক্ত পার্টিশনের সাথে, আমরা কর্মক্ষমতা অর্জন করতে সক্ষম হয়েছি ~500 Mb/s (প্রতি সেকেন্ডে প্রায় 990 হাজার বার্তা):

JVM ভার্চুয়াল মেশিনের মেমরি খরচ 2 GB অতিক্রম করেনি:

ডিস্ক থ্রুপুট সর্বোচ্চ I/O নোড থ্রুপুটে পৌঁছেছে যে তিনটি ক্ষেত্রে ব্রোকাররা চলছিল:

নোডগুলির দ্বারা মেমরি ব্যবহারের ডেটা থেকে, এটি অনুসরণ করে যে সিস্টেম বাফারিং এবং ক্যাশিং ~10-15 GB নিয়েছে:

3 দালাল, বার্তা আকার - 100 বাইট

বার্তার আকার হ্রাস পাওয়ার সাথে সাথে, থ্রুপুট প্রায় 15-20% কমে যায়: প্রতিটি বার্তা প্রক্রিয়াকরণে ব্যয় করা সময় এটিকে প্রভাবিত করে। এছাড়াও, প্রসেসরের লোড প্রায় দ্বিগুণ হয়েছে।

যেহেতু ব্রোকার নোডগুলিতে এখনও অব্যবহৃত কোর রয়েছে, তাই কাফকা কনফিগারেশন পরিবর্তন করে কর্মক্ষমতা উন্নত করা যেতে পারে। এটি একটি সহজ কাজ নয়, তাই থ্রুপুট বাড়ানোর জন্য বড় বার্তাগুলির সাথে কাজ করা ভাল।

4 দালাল, বার্তা আকার - 512 বাইট

আপনি সহজে নতুন ব্রোকার যোগ করে এবং পার্টিশনের ভারসাম্য বজায় রেখে কাফকা ক্লাস্টারের কার্যক্ষমতা বাড়াতে পারেন (এটি নিশ্চিত করে যে লোডটি দালালদের মধ্যে সমানভাবে বিতরণ করা হয়েছে)। আমাদের ক্ষেত্রে, একটি ব্রোকার যোগ করার পরে, ক্লাস্টার থ্রুপুট বেড়েছে ~580 Mb/s (~1,1 মিলিয়ন বার্তা প্রতি সেকেন্ডে). প্রবৃদ্ধি প্রত্যাশার চেয়ে কম দেখা গেছে: এটি প্রধানত পার্টিশনের ভারসাম্যহীনতার দ্বারা ব্যাখ্যা করা হয়েছে (সমস্ত দালাল তাদের ক্ষমতার শীর্ষে কাজ করে না)।

JVM মেশিনের মেমরি খরচ 2 GB এর নিচে ছিল:

ড্রাইভ সহ দালালদের কাজ পার্টিশনের ভারসাম্যহীনতার দ্বারা প্রভাবিত হয়েছিল:

তথ্যও

উপরে উপস্থাপিত পুনরাবৃত্তিমূলক পদ্ধতিকে আরও জটিল পরিস্থিতি কভার করার জন্য প্রসারিত করা যেতে পারে যাতে শত শত গ্রাহক, পুনঃবিভাগ, রোলিং আপডেট, পড রিস্টার্ট ইত্যাদি জড়িত থাকে। এই সমস্ত কিছু আমাদেরকে বিভিন্ন পরিস্থিতিতে কাফকা ক্লাস্টারের ক্ষমতার সীমা মূল্যায়ন করতে, এর অপারেশনে বাধাগুলি চিহ্নিত করতে এবং সেগুলি মোকাবেলার উপায় খুঁজে বের করতে দেয়।

আমরা সুপারটিউবগুলিকে দ্রুত এবং সহজে একটি ক্লাস্টার স্থাপন করতে, এটি কনফিগার করতে, ব্রোকার এবং বিষয়গুলি যোগ/সরানোর জন্য, সতর্কতার প্রতিক্রিয়া জানাতে এবং কাফকা সাধারণভাবে Kubernetes-এ সঠিকভাবে কাজ করে তা নিশ্চিত করার জন্য ডিজাইন করেছি। আমাদের লক্ষ্য হল আপনাকে মূল কাজগুলিতে মনোনিবেশ করতে সাহায্য করা (কাফকা বার্তাগুলি "উত্পন্ন" এবং "ব্যবহার") এবং সমস্ত কঠোর পরিশ্রম সুপারটিউব এবং কাফকা অপারেটরের উপর ছেড়ে দেওয়া।

আপনি যদি বানজাই ক্লাউড প্রযুক্তি এবং ওপেন সোর্স প্রকল্পগুলিতে আগ্রহী হন তবে এখানে কোম্পানিতে সদস্যতা নিন GitHub, লিঙ্কডইন বা Twitter.

অনুবাদক থেকে PS

আমাদের ব্লগেও পড়ুন:

• «K8s-এ Redis অপারেটরের সাথে একটি গল্প এবং এই ডাটাবেস থেকে ডেটা বিশ্লেষণের জন্য ইউটিলিটিগুলির একটি ছোট-পর্যালোচনা";
• «বিরামহীন RabbitMQ থেকে Kubernetes মাইগ্রেশন";
• «CoreOS থেকে zetcd: ZooKeeper কে...ইত্যাদি স্টোরেজ দিয়ে প্রতিস্থাপন করা হচ্ছে».

উত্স: www.habr.com