কুবারনেটসে টিন্ডারের রূপান্তর

বিঃদ্রঃ. অনুবাদ: বিশ্ব বিখ্যাত টিন্ডার পরিষেবার কর্মচারীরা সম্প্রতি কুবারনেটসে তাদের অবকাঠামো স্থানান্তরের কিছু প্রযুক্তিগত বিবরণ শেয়ার করেছেন৷ প্রক্রিয়াটি প্রায় দুই বছর সময় নেয় এবং এর ফলে K8s-এ একটি খুব বড় মাপের প্ল্যাটফর্ম চালু হয়, যেখানে 200 হাজার কন্টেইনারে 48টি পরিষেবা হোস্ট করা হয়। টিন্ডার ইঞ্জিনিয়াররা কোন আকর্ষণীয় সমস্যার সম্মুখীন হয়েছিল এবং তারা কী ফলাফল পেয়েছিল? এই অনুবাদটি পড়ুন।

কেন?

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

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

প্রক্রিয়া কঠিন হতে পরিণত. 2019 সালের প্রথম দিকে আমাদের মাইগ্রেশনের সময়, Kubernetes ক্লাস্টারটি গুরুতর আকারে পৌঁছেছিল এবং আমরা ট্র্যাফিকের পরিমাণ, ক্লাস্টারের আকার এবং DNS এর কারণে বিভিন্ন সমস্যার সম্মুখীন হতে শুরু করি। পথের মধ্যে, আমরা 200টি পরিষেবা স্থানান্তরিত করা এবং 1000টি নোড, 15000টি পড এবং 48000টি চলমান কন্টেইনার সমন্বিত একটি কুবারনেটস ক্লাস্টার বজায় রাখার সাথে সম্পর্কিত অনেকগুলি আকর্ষণীয় সমস্যার সমাধান করেছি৷

কিভাবে?

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

Kubernetes জন্য বিল্ডিং ইমেজ

কুবারনেটস ক্লাস্টারে চলমান মাইক্রোসার্ভিসের জন্য আমাদের কাছে 30টিরও বেশি সোর্স কোড সংগ্রহস্থল রয়েছে। এই সংগ্রহস্থলের কোড একই ভাষার জন্য একাধিক রানটাইম পরিবেশ সহ বিভিন্ন ভাষায় (উদাহরণস্বরূপ, Node.js, Java, Scala, Go) লেখা হয়।

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

চিত্র 1-1। বিল্ডার কন্টেইনারের মাধ্যমে প্রমিত বিল্ড প্রক্রিয়া

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

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

কিছু পরিষেবার জন্য, রানটাইম এনভায়রনমেন্টে কম্পাইলেশন এনভায়রনমেন্ট ম্যাপ করার জন্য আমাদের আরেকটি কন্টেইনার তৈরি করতে হয়েছিল (উদাহরণস্বরূপ, Node.js bcrypt লাইব্রেরি ইনস্টলেশনের সময় প্ল্যাটফর্ম-নির্দিষ্ট বাইনারি আর্টিফ্যাক্ট তৈরি করে)। সংকলন প্রক্রিয়া চলাকালীন, পরিষেবাগুলির মধ্যে প্রয়োজনীয়তা পরিবর্তিত হতে পারে এবং চূড়ান্ত ডকারফাইলটি ফ্লাইতে সংকলিত হয়।

কুবারনেটস ক্লাস্টার আর্কিটেকচার এবং মাইগ্রেশন

ক্লাস্টার আকার ব্যবস্থাপনা

আমরা ব্যবহার করার সিদ্ধান্ত নিয়েছি kube-aws Amazon EC2 দৃষ্টান্তে স্বয়ংক্রিয় ক্লাস্টার স্থাপনার জন্য। একেবারে শুরুতে, সবকিছু নোডের একটি সাধারণ পুলে কাজ করেছিল। সম্পদের আরও দক্ষ ব্যবহার করার জন্য আমরা আকার এবং উদাহরণের ধরন দ্বারা কাজের চাপগুলিকে আলাদা করার প্রয়োজনীয়তা দ্রুত উপলব্ধি করেছি। যুক্তিটি ছিল যে একাধিক লোড করা মাল্টি-থ্রেডেড পড চালানো অনেক বেশি সংখ্যক একক-থ্রেডেড পডের সাথে তাদের সহাবস্থানের চেয়ে কর্মক্ষমতার দিক থেকে আরও অনুমানযোগ্য বলে প্রমাণিত হয়েছিল।

শেষ পর্যন্ত আমরা স্থির হয়েছি:

• m5.4x বড় — পর্যবেক্ষণের জন্য (প্রমিথিউস);
• c5.4x বড় - Node.js ওয়ার্কলোডের জন্য (একক-থ্রেডেড ওয়ার্কলোড);
• c5.2x বড় - জাভা এবং গো (মাল্টিথ্রেডেড ওয়ার্কলোড);
• c5.4x বড় — কন্ট্রোল প্যানেলের জন্য (3 নোড)।

অভিপ্রয়াণ

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

এই শেষ পয়েন্টগুলি DNS রেকর্ডগুলির ওজনযুক্ত সেটগুলি ব্যবহার করে তৈরি করা হয়েছিল যাতে প্রতিটি নতুন ELB-এর দিকে নির্দেশ করে CNAME গুলি ছিল৷ স্যুইচ ওভার করার জন্য, আমরা 0 এর ওজন সহ Kubernetes পরিষেবার নতুন ELB-এর দিকে নির্দেশ করে একটি নতুন এন্ট্রি যুক্ত করেছি। তারপরে আমরা এন্ট্রি সেটের টাইম টু লাইভ (TTL) সেট করেছি 0। এর পরে, পুরানো এবং নতুন ওজন ছিল ধীরে ধীরে সামঞ্জস্য করা হয়, এবং অবশেষে 100% লোড একটি নতুন সার্ভারে পাঠানো হয়। স্যুইচিং সম্পন্ন হওয়ার পর, TTL মান আরও পর্যাপ্ত স্তরে ফিরে আসে।

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

পাঠ

নেটওয়ার্ক ফ্যাব্রিকের সীমাবদ্ধতা

8 জানুয়ারী, 2019 এর ভোরে, টিন্ডার প্ল্যাটফর্মটি অপ্রত্যাশিতভাবে বিধ্বস্ত হয়। সেই সকালে প্ল্যাটফর্ম লেটেন্সিতে একটি সম্পর্কহীন বৃদ্ধির প্রতিক্রিয়ায়, ক্লাস্টারে পড এবং নোডের সংখ্যা বৃদ্ধি পেয়েছে। এর ফলে আমাদের সমস্ত নোডে ARP ক্যাশে নিঃশেষ হয়ে যায়।

এআরপি ক্যাশে সম্পর্কিত তিনটি লিনাক্স বিকল্প রয়েছে:

(উৎস)

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

আমরা ব্যাবহার করি পশমী কাপড় Kubernetes একটি নেটওয়ার্ক ফ্যাব্রিক হিসাবে. প্যাকেট VXLAN এর মাধ্যমে প্রেরণ করা হয়। VXLAN হল L2 নেটওয়ার্কের উপরে উত্থিত একটি L3 টানেল। প্রযুক্তিটি MAC-in-UDP (MAC Address-in-User Datagram Protocol) এনক্যাপসুলেশন ব্যবহার করে এবং লেয়ার 2 নেটওয়ার্ক সেগমেন্টের সম্প্রসারণের অনুমতি দেয়। ফিজিক্যাল ডাটা সেন্টার নেটওয়ার্কে ট্রান্সপোর্ট প্রোটোকল হল আইপি প্লাস ইউডিপি।

চিত্র 2-1। ফ্ল্যানেল চিত্র (উৎস)

চিত্র 2-2। VXLAN প্যাকেজ (উৎস)

প্রতিটি Kubernetes কর্মী নোড একটি বড় /24 ব্লক থেকে /9 মাস্ক সহ একটি ভার্চুয়াল ঠিকানা স্থান বরাদ্দ করে। প্রতিটি নোড জন্য এই হয় মানে রাউটিং টেবিলে একটি এন্ট্রি, এআরপি টেবিলে একটি এন্ট্রি (ফ্ল্যানেল.1 ইন্টারফেসে), এবং একটি এন্ট্রি সুইচিং টেবিলে (এফডিবি)৷ প্রথমবার একটি কর্মী নোড শুরু হলে বা প্রতিবার একটি নতুন নোড আবিষ্কৃত হলে এগুলি যোগ করা হয়।

উপরন্তু, নোড-পড (বা পড-পড) যোগাযোগ শেষ পর্যন্ত ইন্টারফেসের মধ্য দিয়ে যায় eth0 (উপরের ফ্ল্যানেল ডায়াগ্রামে দেখানো হয়েছে)। এর ফলে প্রতিটি সংশ্লিষ্ট উৎস এবং গন্তব্য হোস্টের জন্য ARP টেবিলে একটি অতিরিক্ত এন্ট্রি রয়েছে।

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

ব্যর্থতার সময়, ক্লাস্টারে 605টি নোড ছিল। উপরে উল্লিখিত কারণগুলির জন্য, এটি তাত্পর্য অতিক্রম করার জন্য যথেষ্ট ছিল gc_thresh3, যা ডিফল্ট। যখন এটি ঘটে, শুধুমাত্র প্যাকেটগুলি বাদ দেওয়া শুরু করে না, তবে /24 মাস্ক সহ পুরো ফ্ল্যানেল ভার্চুয়াল ঠিকানার স্থান ARP টেবিল থেকে অদৃশ্য হয়ে যায়। নোড-পড কমিউনিকেশন এবং ডিএনএস ক্যোয়ারী বাধাগ্রস্ত হয় (ডিএনএস একটি ক্লাস্টারে হোস্ট করা হয়; বিস্তারিত জানার জন্য এই নিবন্ধে পরে পড়ুন)।

এই সমস্যা সমাধানের জন্য, আপনাকে মান বাড়াতে হবে gc_thresh1, gc_thresh2 и gc_thresh3 এবং অনুপস্থিত নেটওয়ার্কগুলি পুনরায় নিবন্ধন করতে ফ্ল্যানেল পুনরায় চালু করুন।

অপ্রত্যাশিত DNS স্কেলিং

মাইগ্রেশন প্রক্রিয়া চলাকালীন, আমরা ট্র্যাফিক পরিচালনা করতে সক্রিয়ভাবে DNS ব্যবহার করেছি এবং ধীরে ধীরে পুরানো অবকাঠামো থেকে Kubernetes-এ পরিষেবা স্থানান্তর করেছি। আমরা Route53 এ সম্পর্কিত রেকর্ডসেটের জন্য তুলনামূলকভাবে কম TTL মান সেট করেছি। যখন পুরানো অবকাঠামো EC2 দৃষ্টান্তে চলছিল, তখন আমাদের সমাধানকারী কনফিগারেশন Amazon DNS-এর দিকে নির্দেশ করে। আমরা এটিকে মঞ্জুর করে নিয়েছি এবং আমাদের পরিষেবা এবং অ্যামাজন পরিষেবাগুলিতে (যেমন DynamoDB) নিম্ন TTL-এর প্রভাব অনেকাংশে নজরে পড়েনি৷

যখন আমরা Kubernetes পরিষেবাগুলি স্থানান্তরিত করেছি, আমরা দেখতে পেয়েছি যে DNS প্রতি সেকেন্ডে 250 হাজার অনুরোধ প্রক্রিয়া করছে৷ ফলস্বরূপ, অ্যাপ্লিকেশনগুলি DNS প্রশ্নের জন্য ধ্রুবক এবং গুরুতর টাইমআউট অনুভব করতে শুরু করে। DNS প্রদানকারীকে CoreDNS-এ অপ্টিমাইজ করার এবং স্যুইচ করার অবিশ্বাস্য প্রচেষ্টা সত্ত্বেও এটি ঘটেছে (যা সর্বোচ্চ লোডে 1000 কোরে চলমান 120 পডগুলিতে পৌঁছেছে)।

অন্যান্য সম্ভাব্য কারণ এবং সমাধান গবেষণা করার সময়, আমরা আবিষ্কার করেছি প্রবন্ধ, প্যাকেট ফিল্টারিং ফ্রেমওয়ার্ককে প্রভাবিত করে রেসের অবস্থা বর্ণনা করে Netfilter লিনাক্সে। ক্রমবর্ধমান কাউন্টারের সাথে মিলিত সময়সীমা আমরা পর্যবেক্ষণ করেছি insert_failed ফ্ল্যানেল ইন্টারফেসে নিবন্ধের ফলাফলের সাথে সামঞ্জস্যপূর্ণ ছিল।

সোর্স এবং ডেস্টিনেশন নেটওয়ার্ক অ্যাড্রেস ট্রান্সলেশন (SNAT এবং DNAT) এবং পরবর্তী টেবিলে প্রবেশের পর্যায়ে সমস্যাটি ঘটে কনট্র্যাক. অভ্যন্তরীণভাবে আলোচনা করা এবং সম্প্রদায়ের দ্বারা প্রস্তাবিত সমাধানগুলির মধ্যে একটি হল ডিএনএসকে কর্মী নোডে নিজেই স্থানান্তর করা। এক্ষেত্রে:

• SNAT এর প্রয়োজন নেই কারণ ট্র্যাফিক নোডের ভিতরে থাকে। এটি ইন্টারফেসের মাধ্যমে রাউট করার প্রয়োজন নেই eth0.
• DNAT এর প্রয়োজন নেই যেহেতু গন্তব্য আইপি নোডের স্থানীয়, এবং নিয়ম অনুসারে এলোমেলোভাবে নির্বাচিত পড নয় iptables- র.

আমরা এই পদ্ধতির সাথে লেগে থাকার সিদ্ধান্ত নিয়েছি। CoreDNS কে Kubernetes-এ ডেমনসেট হিসাবে স্থাপন করা হয়েছিল এবং আমরা একটি স্থানীয় নোড DNS সার্ভার প্রয়োগ করেছি solve.conf একটি পতাকা সেট করে প্রতিটি পড --ক্লাস্টার-ডিএনএস কমান্ড কুবলেট . এই সমাধানটি DNS টাইমআউটের জন্য কার্যকর হতে দেখা গেছে।

যাইহোক, আমরা এখনও প্যাকেটের ক্ষতি এবং কাউন্টারে বৃদ্ধি দেখেছি insert_failed ফ্ল্যানেল ইন্টারফেসে। কাজটি কার্যকর করার পরেও এটি অব্যাহত ছিল কারণ আমরা শুধুমাত্র DNS ট্র্যাফিকের জন্য SNAT এবং/অথবা DNAT বাদ দিতে সক্ষম হয়েছি। অন্যান্য ধরনের ট্র্যাফিকের জন্য রেসের অবস্থা সংরক্ষিত ছিল। সৌভাগ্যবশত, আমাদের বেশিরভাগ প্যাকেট টিসিপি, এবং যদি কোনো সমস্যা দেখা দেয় তবে সেগুলিকে পুনরায় প্রেরণ করা হয়। আমরা এখনও সব ধরনের ট্রাফিকের জন্য একটি উপযুক্ত সমাধান খুঁজে বের করার চেষ্টা করছি।

উন্নত লোড ব্যালেন্সিংয়ের জন্য দূত ব্যবহার করা

যেহেতু আমরা ব্যাকএন্ড পরিষেবাগুলি কুবারনেটে স্থানান্তরিত করেছি, আমরা শুঁটির মধ্যে ভারসাম্যহীন ভার নিয়ে ভুগতে শুরু করেছি। আমরা দেখেছি যে HTTP Keepalive-এর কারণে রোল আউট করা প্রতিটি স্থাপনার প্রথম প্রস্তুত পডগুলিতে ELB সংযোগগুলি ঝুলে আছে। এইভাবে, ট্রাফিকের বড় অংশ উপলব্ধ পডের একটি ছোট শতাংশের মধ্য দিয়ে গেছে। আমরা পরীক্ষিত প্রথম সমাধানটি ছিল সবচেয়ে খারাপ পরিস্থিতির জন্য নতুন স্থাপনার উপর MaxSurge 100% সেট করা। বৃহত্তর স্থাপনার ক্ষেত্রে প্রভাবটি নগণ্য এবং অপ্রত্যাশিত বলে প্রমাণিত হয়েছিল।

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

আমরা দীর্ঘ সম্পূর্ণরূপে প্রশংসা করতে চেয়েছিলেন দূত. বর্তমান পরিস্থিতি আমাদের এটিকে খুব সীমিত উপায়ে স্থাপন করতে এবং তাৎক্ষণিক ফলাফল পেতে অনুমতি দিয়েছে। দূত হল একটি উচ্চ-পারফরম্যান্স, ওপেন-সোর্স, লেয়ার-XNUMX প্রক্সি যা বড় SOA অ্যাপ্লিকেশনের জন্য ডিজাইন করা হয়েছে। এটি স্বয়ংক্রিয় পুনঃপ্রচার, সার্কিট ব্রেকার এবং গ্লোবাল রেট লিমিটিং সহ উন্নত লোড ব্যালেন্সিং কৌশল প্রয়োগ করতে পারে। (বিঃদ্রঃ. অনুবাদ: আপনি এই সম্পর্কে আরও পড়তে পারেন এই নিবন্ধটি ইস্টিও সম্পর্কে, যা দূতের উপর ভিত্তি করে।)

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

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

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

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

ফলাফল অবিলম্বে এবং সুস্পষ্ট ছিল. আমরা সবচেয়ে ভারসাম্যহীন পরিষেবা দিয়ে শুরু করেছি, এবং এই মুহূর্তে এটি ক্লাস্টারের সবচেয়ে গুরুত্বপূর্ণ 12টি পরিষেবার সামনে কাজ করছে৷ এই বছর আমরা আরও উন্নত পরিষেবা আবিষ্কার, সার্কিট ব্রেকিং, আউটলিয়ার সনাক্তকরণ, হার সীমিতকরণ এবং ট্রেসিং সহ একটি সম্পূর্ণ পরিষেবা জালের রূপান্তরের পরিকল্পনা করছি৷

চিত্র 3-1। দূতে রূপান্তরের সময় একটি পরিষেবার CPU কনভারজেন্স

সর্বশেষ ফলাফল

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

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

মাইগ্রেশনে প্রায় দুই বছর সময় লেগেছিল, কিন্তু আমরা মার্চ 2019 এ এটি সম্পন্ন করেছি। বর্তমানে, টিন্ডার প্ল্যাটফর্মটি 200টি পরিষেবা, 1000 নোড, 15 পড এবং 000টি চলমান কন্টেইনার সমন্বিত একটি কুবারনেটস ক্লাস্টারে একচেটিয়াভাবে চলে৷ পরিকাঠামো আর অপারেশন টিমের একমাত্র ডোমেইন নয়। আমাদের সমস্ত প্রকৌশলী এই দায়িত্ব ভাগ করে নেন এবং শুধুমাত্র কোড ব্যবহার করে তাদের অ্যাপ্লিকেশন তৈরি ও স্থাপনের প্রক্রিয়া নিয়ন্ত্রণ করেন।

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

আমাদের ব্লগে নিবন্ধগুলির একটি সিরিজও পড়ুন:

• «Kubernetes উৎপাদনে সাফল্যের গল্প। পার্ট 1: ইবে থেকে 4200 হার্ট এবং টেসমাস্টার».
• «Kubernetes উৎপাদনে সাফল্যের গল্প। পার্ট 2: একমত এবং SAP».
• «Kubernetes উৎপাদনে সাফল্যের গল্প। পার্ট 3: GitHub».
• «Kubernetes উৎপাদনে সাফল্যের গল্প। পার্ট 4: সাউন্ডক্লাউড (প্রমিথিউস দ্বারা)».
• «Kubernetes উৎপাদনে সাফল্যের গল্প। পার্ট 5: ডিজিটাল ব্যাংক মনজো».
• «Kubernetes উৎপাদনে সাফল্যের গল্প। পার্ট 6: BlaBlaCar».
• «Kubernetes উৎপাদনে সাফল্যের গল্প। পার্ট 7: কালো শিলা».
• «Kubernetes উৎপাদনে সাফল্যের গল্প। পার্ট 8: হুয়াওয়ে».
• «Kubernetes উৎপাদনে সাফল্যের গল্প। পার্ট 9: CERN এবং 210 K8s ক্লাস্টার».
• «Kubernetes উৎপাদনে সাফল্যের গল্প। পার্ট 10: Reddit».

উত্স: www.habr.com