Yandex.Market অনুসন্ধান কীভাবে কাজ করে এবং সার্ভারগুলির একটি ব্যর্থ হলে কী হয়

হ্যালো, আমার নাম Evgeniy. আমি Yandex.Market অনুসন্ধান পরিকাঠামোতে কাজ করি। আমি হাবর সম্প্রদায়কে মার্কেটের ভিতরের রান্নাঘর সম্পর্কে বলতে চাই - এবং আমার অনেক কিছু বলার আছে। প্রথমত, মার্কেট সার্চ কিভাবে কাজ করে, প্রসেস এবং আর্কিটেকচার। আমরা কীভাবে জরুরী পরিস্থিতি মোকাবেলা করব: একটি সার্ভার ডাউন হলে কী হবে? যদি এমন 100টি সার্ভার থাকে?

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

আমাদের সম্পর্কে একটু: আমরা কি সমস্যা সমাধান করি

আপনি যখন পাঠ্য লিখুন, প্যারামিটার দ্বারা একটি পণ্য অনুসন্ধান করুন, বা বিভিন্ন দোকানে দাম তুলনা করুন, সমস্ত অনুরোধ অনুসন্ধান পরিষেবাতে পাঠানো হয়। অনুসন্ধান হল বাজারের সবচেয়ে বড় পরিষেবা।

আমরা সমস্ত অনুসন্ধান অনুরোধ প্রক্রিয়া করি: সাইটগুলি থেকে market.yandex.ru, beru.ru, সুপারচেক পরিষেবা, Yandex.Advisor, মোবাইল অ্যাপ্লিকেশন৷ এছাড়াও আমরা yandex.ru-এ সার্চ ফলাফলে পণ্যের অফার অন্তর্ভুক্ত করি।

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

কি কি: মার্কেট আর্কিটেকচার

আমি সংক্ষেপে মার্কেটের বর্তমান আর্কিটেকচার বর্ণনা করব। এটি নীচের চিত্র দ্বারা মোটামুটিভাবে বর্ণনা করা যেতে পারে:

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

এরকম অনেক সেভ করা xml আছে। এই ডাটাবেস থেকে একটি অনুসন্ধান সূচক তৈরি করা হয়। সূচকটি অভ্যন্তরীণ বিন্যাসে সংরক্ষণ করা হয়। সূচী তৈরি করার পরে, লেআউট পরিষেবা সার্ভার সার্ভারে আপলোড করে।

ফলস্বরূপ, একটি স্কুইকার সহ একটি রাগান্বিত বিড়াল ডাটাবেসে উপস্থিত হয় এবং বিড়ালের সূচক সার্ভারে উপস্থিত হয়।

আমি আপনাকে বলব কিভাবে আমরা সার্চ আর্কিটেকচারের অংশে একটি বিড়াল অনুসন্ধান করি।

বাজার অনুসন্ধান আর্কিটেকচার

আমরা মাইক্রো সার্ভিসের জগতে বাস করি: প্রতিটি আগত অনুরোধ market.yandex.ru অনেক সাবকোয়েরির কারণ, এবং কয়েক ডজন পরিষেবা তাদের প্রক্রিয়াকরণের সাথে জড়িত। চিত্রটি শুধুমাত্র কয়েকটি দেখায়:

সরলীকৃত অনুরোধ প্রক্রিয়াকরণ স্কিম

প্রতিটি পরিষেবার একটি বিস্ময়কর জিনিস রয়েছে - একটি অনন্য নামের সাথে তার নিজস্ব ব্যালেন্সার:

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

ব্যালেন্সারের অনন্য নাম ডেটা সেন্টারের উপর নির্ভর করে না। পরিষেবা A যখন B এর কাছে একটি অনুরোধ করে, তখন ডিফল্ট ব্যালেন্সার B দ্বারা বর্তমান ডেটা সেন্টারে অনুরোধটি পুনর্নির্দেশ করে। যদি পরিষেবাটি অনুপলব্ধ হয় বা বর্তমান ডেটা সেন্টারে বিদ্যমান না থাকে, তাহলে অনুরোধটি অন্যান্য ডেটা সেন্টারে পুনঃনির্দেশিত হয়।

সমস্ত ডেটা সেন্টারের জন্য একটি একক FQDN পরিষেবা A কে অবস্থান থেকে সম্পূর্ণরূপে বিমূর্ত করার অনুমতি দেয়। বি পরিষেবার জন্য তার অনুরোধ সর্বদা প্রক্রিয়া করা হবে। ব্যতিক্রম হল যখন পরিষেবাটি সমস্ত ডেটা সেন্টারে অবস্থিত।

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

অপ্রত্যাশিত সাথে মোকাবিলা করা: অনুসন্ধান পরিষেবা ভারসাম্য এবং স্থিতিস্থাপকতা

কল্পনা করুন যে একটি পতন আছে: আপনি একটি squeaker সঙ্গে একটি বিড়াল খুঁজে বের করতে হবে, কিন্তু সার্ভার ক্র্যাশ. অথবা 100 সার্ভার। কিভাবে বের হবে? আমরা কি সত্যিই বিড়াল ছাড়া ব্যবহারকারীকে ছেড়ে চলে যাচ্ছি?

পরিস্থিতি ভীতিজনক, তবে আমরা এর জন্য প্রস্তুত। আমি আপনাকে ক্রমে বলব।

অনুসন্ধান পরিকাঠামো বিভিন্ন তথ্য কেন্দ্রে অবস্থিত:

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

আসুন একটি একক ডেটা সেন্টার বিবেচনা করি। প্রতিটি ডেটা সেন্টারে একই ব্যালেন্সার অপারেশন স্কিম রয়েছে:

একটি ব্যালেন্সার কমপক্ষে তিনটি শারীরিক সার্ভার। এই অপ্রয়োজনীয়তা নির্ভরযোগ্যতার জন্য তৈরি করা হয়েছে। ব্যালেন্সার HAProx-এ চলে।

আমরা HAProx এর উচ্চ কর্মক্ষমতা, কম সম্পদের প্রয়োজনীয়তা এবং ব্যাপক কার্যকারিতার কারণে বেছে নিয়েছি। আমাদের অনুসন্ধান সফ্টওয়্যার প্রতিটি সার্ভারের ভিতরে চলে।

একটি সার্ভার ব্যর্থ হওয়ার সম্ভাবনা কম। কিন্তু আপনার যদি অনেকগুলি সার্ভার থাকে তবে অন্তত একটি ডাউন হওয়ার সম্ভাবনা বেড়ে যায়।

বাস্তবে এটিই ঘটে: সার্ভার ক্র্যাশ। অতএব, সব সার্ভারের অবস্থা ক্রমাগত নিরীক্ষণ করা প্রয়োজন। সার্ভার সাড়া দেওয়া বন্ধ করে দিলে, এটি স্বয়ংক্রিয়ভাবে ট্রাফিক থেকে সংযোগ বিচ্ছিন্ন হয়ে যায়। এই উদ্দেশ্যে, HAProxy-এর একটি অন্তর্নির্মিত স্বাস্থ্য পরীক্ষা রয়েছে। এটি HTTP অনুরোধ “/ping” সহ সেকেন্ডে একবার সমস্ত সার্ভারে যায়।

HAProxy-এর আরেকটি বৈশিষ্ট্য: এজেন্ট-চেক আপনাকে সব সার্ভার সমানভাবে লোড করতে দেয়। এটি করার জন্য, HAProxy সমস্ত সার্ভারের সাথে সংযোগ করে, এবং তারা তাদের ওজন 1 থেকে 100 পর্যন্ত বর্তমান লোডের উপর নির্ভর করে ফেরত দেয়। প্রক্রিয়াকরণের জন্য সারিতে থাকা অনুরোধের সংখ্যা এবং প্রসেসরের লোডের উপর ভিত্তি করে ওজন গণনা করা হয়।

এখন বিড়াল খোঁজার বিষয়ে। অনুসন্ধানের ফলাফল যেমন অনুরোধে: /search?text=angry+cat. অনুসন্ধানটি দ্রুত হওয়ার জন্য, সম্পূর্ণ বিড়াল সূচকটি RAM-তে ফিট করা আবশ্যক৷ এমনকি SSD থেকে পড়া যথেষ্ট দ্রুত নয়।

এক সময়, অফার ডাটাবেস ছোট ছিল, এবং একটি সার্ভারের RAM এর জন্য যথেষ্ট ছিল। অফার বেস বাড়ার সাথে সাথে, সবকিছু আর এই র‌্যামের সাথে খাপ খায় না, এবং ডেটা দুটি ভাগে বিভক্ত হয়েছিল: শার্ড 1 এবং শার্ড 2৷

তবে এটি সর্বদা ঘটে: যে কোনও সমাধান, এমনকি একটি ভাল, অন্যান্য সমস্যার জন্ম দেয়।

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

যেহেতু ব্যালেন্সার অনুরোধগুলি সমানভাবে বিতরণ করে, তাই সমস্ত সার্ভার পুনরায় র‌্যাঙ্কিংয়ে নিযুক্ত ছিল, শুধুমাত্র ডেটা পাঠাতে নয়।

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

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

একটি সার্ভার শুধুমাত্র একটি শার্ডের জন্য তথ্য ধারণ করে। অতএব, সম্পূর্ণ সূচক অনুসন্ধান করার জন্য, আপনাকে বিভিন্ন শার্ড ধারণকারী আটটি সার্ভারে অনুসন্ধান করতে হবে।

সার্ভারগুলি ক্লাস্টারে বিভক্ত। প্রতিটি ক্লাস্টারে আটটি সার্চ ইঞ্জিন এবং একটি স্নিপেট সার্ভার রয়েছে।

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

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

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

প্রয়োজনীয় তথ্য সংগ্রহ করার পর, অফার ডাটাবেসে একটি অনুসন্ধান শুরু হয়। এটি করার জন্য, ক্লাস্টারের সমস্ত আটটি সার্ভারে সাবকোয়ারি করা হয়।

একবার প্রতিক্রিয়া প্রাপ্ত হলে, ফলাফলগুলি একত্রিত হয়। শেষ পর্যন্ত, ফলাফলগুলি তৈরি করতে স্নিপেট সার্ভারে আরও কয়েকটি সাবকোয়েরির প্রয়োজন হতে পারে।

ক্লাস্টারের মধ্যে অনুসন্ধানের প্রশ্নগুলি দেখতে এইরকম: /shard1?text=angry+cat. উপরন্তু, ফর্মের সাবকোয়ারিগুলি ক্রমাগতভাবে ক্লাস্টারের মধ্যে সমস্ত সার্ভারের মধ্যে সেকেন্ডে একবার তৈরি করা হয়: /স্থিতি.

তদন্ত /স্থিতি সার্ভার উপলব্ধ নয় এমন একটি পরিস্থিতি সনাক্ত করে।

এটি নিয়ন্ত্রণ করে যে সার্চ ইঞ্জিন সংস্করণ এবং সূচী সংস্করণ সব সার্ভারে একই, অন্যথায় ক্লাস্টারের মধ্যে অসামঞ্জস্যপূর্ণ ডেটা থাকবে।

একটি স্নিপেট সার্ভার আটটি সার্চ ইঞ্জিন থেকে অনুরোধ প্রক্রিয়াকরণ সত্ত্বেও, এর প্রসেসরটি খুব হালকাভাবে লোড করা হয়। অতএব, আমরা এখন একটি পৃথক পরিষেবাতে স্নিপেট ডেটা স্থানান্তর করছি।

ডেটা স্থানান্তর করার জন্য, আমরা নথিগুলির জন্য সর্বজনীন কীগুলি চালু করেছি। এখন এমন পরিস্থিতির জন্য এটি অসম্ভব যেখানে একটি কী ব্যবহার করে অন্য নথি থেকে সামগ্রী ফেরত দেওয়া হয়।

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

এবং এখন সুখী সমাপ্তি সহ ভীতিজনক গল্পগুলিতে। আসুন সার্ভারের অনুপলব্ধতার কয়েকটি ক্ষেত্রে বিবেচনা করি।

ভয়ানক কিছু ঘটেছে: একটি সার্ভার অনুপলব্ধ

ধরা যাক একটি সার্ভার অনুপলব্ধ। তারপর ক্লাস্টারের অবশিষ্ট সার্ভারগুলি প্রতিক্রিয়া চালিয়ে যেতে পারে, তবে অনুসন্ধানের ফলাফলগুলি অসম্পূর্ণ থাকবে।

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

একটি ত্রুটির সাথে ব্যর্থ হওয়া অনুরোধগুলি অন্যান্য সার্ভারে ব্যালেন্সার দ্বারা পুনরায় পাঠানো হয়।
ব্যালেন্সারটি মৃত সার্ভারগুলিতে ব্যবহারকারীর ট্র্যাফিক পাঠানো বন্ধ করে, তবে তাদের স্থিতি পরীক্ষা করা চালিয়ে যায়।

সার্ভার উপলব্ধ হয়ে গেলে, এটি সাড়া দিতে শুরু করে /পিং. যত তাড়াতাড়ি মৃত সার্ভার থেকে পিংগুলিতে স্বাভাবিক প্রতিক্রিয়া আসতে শুরু করে, ব্যালেন্সাররা সেখানে ব্যবহারকারীর ট্র্যাফিক পাঠাতে শুরু করে। ক্লাস্টার অপারেশন পুনরুদ্ধার করা হয়, হুররে.

আরও খারাপ: অনেক সার্ভার অনুপলব্ধ

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

যখন একটি ডেটা সেন্টারের অনেকগুলি সার্ভার ডাউন হয়ে যায়, তখন ব্যালেন্সার বুঝতে পারে যে এই ডেটা সেন্টার সমস্ত ট্র্যাফিক প্রক্রিয়া করতে পারে না।

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

আমরা কিভাবে এটা করি: প্রকাশনা প্রকাশ

এখন আসুন আমরা কীভাবে পরিষেবাতে করা পরিবর্তনগুলি প্রকাশ করি সে সম্পর্কে কথা বলি। এখানে আমরা প্রক্রিয়াগুলি সরল করার পথ নিয়েছি: একটি নতুন রিলিজ তৈরি করা প্রায় সম্পূর্ণ স্বয়ংক্রিয়।
যখন একটি নির্দিষ্ট সংখ্যক পরিবর্তন প্রকল্পে জমা হয়, তখন একটি নতুন রিলিজ স্বয়ংক্রিয়ভাবে তৈরি হয় এবং এর নির্মাণ শুরু হয়।

তারপরে পরিষেবাটি পরীক্ষার জন্য চালু করা হয়, যেখানে অপারেশনের স্থিতিশীলতা পরীক্ষা করা হয়।

একই সময়ে, স্বয়ংক্রিয় কর্মক্ষমতা পরীক্ষা চালু করা হয়। এটি একটি বিশেষ পরিষেবা দ্বারা পরিচালিত হয়। আমি এখন এটি সম্পর্কে কথা বলব না - এর বিবরণ একটি পৃথক নিবন্ধের যোগ্য।

পরীক্ষায় প্রকাশনা সফল হলে, প্রেস্টেবলে প্রকাশনা স্বয়ংক্রিয়ভাবে শুরু হয়। প্রেস্টেবল হল একটি বিশেষ ক্লাস্টার যেখানে সাধারণ ব্যবহারকারীর ট্রাফিক নির্দেশিত হয়। যদি এটি একটি ত্রুটি ফেরত দেয়, ব্যালেন্সার উত্পাদনের জন্য পুনরায় অনুরোধ করে।

প্রেস্টেবলে, প্রতিক্রিয়ার সময় পরিমাপ করা হয় এবং উৎপাদনে আগের রিলিজের সাথে তুলনা করা হয়। যদি সবকিছু ঠিক থাকে, তাহলে একজন ব্যক্তি সংযোগ করে: লোড পরীক্ষার গ্রাফ এবং ফলাফলগুলি পরীক্ষা করে এবং তারপরে উত্পাদন শুরু করে।

সমস্ত ভাল ব্যবহারকারীর জন্য যায়: A/B পরীক্ষা

একটি পরিষেবার পরিবর্তন প্রকৃত সুবিধা নিয়ে আসবে কিনা তা সর্বদা স্পষ্ট নয়। পরিবর্তনের উপযোগিতা পরিমাপ করার জন্য, লোকেরা A/B পরীক্ষা নিয়ে এসেছিল। Yandex.Market অনুসন্ধানে এটি কীভাবে কাজ করে সে সম্পর্কে আমি আপনাকে একটু বলব।

এটি একটি নতুন CGI প্যারামিটার যোগ করার সাথে শুরু হয় যা নতুন কার্যকারিতা সক্ষম করে। আমাদের প্যারামিটার হতে দিন: বাজার_নতুন_কার্যকারিতা=1. তারপর কোডে আমরা এই কার্যকারিতা সক্ষম করি যদি পতাকাটি উপস্থিত থাকে:

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

নতুন কার্যকারিতা উৎপাদনে আনা হচ্ছে।

A/B পরীক্ষা স্বয়ংক্রিয় করতে, একটি নিবেদিত পরিষেবা রয়েছে যা বিস্তারিত তথ্য প্রদান করে এখানে বর্ণিত. সেবায় একটি পরীক্ষা তৈরি করা হয়। ট্রাফিক শেয়ার সেট করা হয়েছে, উদাহরণস্বরূপ, 15%। শতাংশ প্রশ্নের জন্য নয়, কিন্তু ব্যবহারকারীদের জন্য সেট করা হয়। পরীক্ষার সময়কালও নির্দেশিত হয়, উদাহরণস্বরূপ, এক সপ্তাহ।

একসাথে বেশ কয়েকটি পরীক্ষা চালানো যেতে পারে। সেটিংসে আপনি নির্দিষ্ট করতে পারেন যে অন্যান্য পরীক্ষার সাথে ছেদ করা সম্ভব কিনা।

ফলস্বরূপ, পরিষেবা স্বয়ংক্রিয়ভাবে একটি যুক্তি যোগ করে বাজার_নতুন_কার্যকারিতা=1 15% ব্যবহারকারীদের কাছে। এটি স্বয়ংক্রিয়ভাবে নির্বাচিত মেট্রিক্স গণনা করে। পরীক্ষা শেষ হওয়ার পর, বিশ্লেষকরা ফলাফল দেখেন এবং সিদ্ধান্তে আসেন। ফলাফলের উপর ভিত্তি করে, উৎপাদন বা পরিমার্জন করার জন্য একটি সিদ্ধান্ত নেওয়া হয়।

বাজারের নিপুণ হাত: উৎপাদনে পরীক্ষা

এটি প্রায়শই ঘটে যে আপনাকে উত্পাদনে একটি নতুন কার্যকারিতার ক্রিয়াকলাপ পরীক্ষা করতে হবে, তবে আপনি নিশ্চিত নন যে এটি ভারী বোঝার অধীনে "যুদ্ধ" পরিস্থিতিতে কীভাবে আচরণ করবে।

একটি সমাধান আছে: CGI প্যারামিটারের পতাকাগুলি শুধুমাত্র A/B পরীক্ষার জন্য নয়, নতুন কার্যকারিতা পরীক্ষা করার জন্যও ব্যবহার করা যেতে পারে।

আমরা এমন একটি টুল তৈরি করেছি যা আপনাকে হাজার হাজার সার্ভারের কনফিগারেশনকে তাৎক্ষণিকভাবে পরিবর্তন করার অনুমতি দেয় পরিষেবাটিকে ঝুঁকির মুখে না ফেলে। এটাকে স্টপ ট্যাপ বলা হয়। মূল ধারণাটি ছিল লেআউট ছাড়াই কিছু কার্যকারিতা দ্রুত নিষ্ক্রিয় করতে সক্ষম হওয়া। তারপর টুলটি প্রসারিত হয় এবং আরও জটিল হয়ে ওঠে।

পরিষেবা প্রবাহ চিত্রটি নীচে উপস্থাপন করা হয়েছে:

পতাকা মান API এর মাধ্যমে সেট করা হয়. ম্যানেজমেন্ট সার্ভিস এই মানগুলি ডাটাবেসে সংরক্ষণ করে। সমস্ত সার্ভার প্রতি দশ সেকেন্ডে একবার ডাটাবেসে যায়, পতাকা মান পাম্প করে এবং প্রতিটি অনুরোধে এই মানগুলি প্রয়োগ করে।

স্টপ ট্যাপে আপনি দুটি ধরণের মান সেট করতে পারেন:

1) শর্তাধীন অভিব্যক্তি। যখন একটি মান সত্য হয় তখন প্রয়োগ করুন। উদাহরণ স্বরূপ:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

DC3 অবস্থানে অনুরোধটি প্রক্রিয়া করা হলে মান "1" প্রয়োগ করা হবে। এবং beru.ru সাইটের জন্য দ্বিতীয় ক্লাস্টারে অনুরোধটি প্রক্রিয়া করা হলে মানটি "4" হয়।

2) শর্তহীন মান। কোনো শর্ত পূরণ না হলে ডিফল্টরূপে আবেদন করুন। উদাহরণ স্বরূপ:

মান, মান!

যদি একটি মান একটি বিস্ময়বোধক বিন্দু দিয়ে শেষ হয়, এটি উচ্চ অগ্রাধিকার দেওয়া হয়।

CGI প্যারামিটার পার্সার URL কে পার্স করে। তারপর স্টপ ট্যাপ থেকে মান প্রয়োগ করে।

নিম্নলিখিত অগ্রাধিকার সহ মান প্রয়োগ করা হয়:

1. স্টপ ট্যাপ (বিস্ময় চিহ্ন) থেকে বর্ধিত অগ্রাধিকার সহ।
2. অনুরোধ থেকে মান.
3. স্টপ ট্যাপ থেকে ডিফল্ট মান।
4. কোডে ডিফল্ট মান।

শর্তাধীন মানগুলিতে নির্দেশিত অনেকগুলি পতাকা রয়েছে - সেগুলি আমাদের কাছে পরিচিত সমস্ত পরিস্থিতির জন্য যথেষ্ট:

• তথ্য কেন্দ্র.
• পরিবেশ: উত্পাদন, পরীক্ষা, ছায়া।
• স্থান: বাজার, বেরু।
• ক্লাস্টার নম্বর।

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

আপনি যদি একটি সমস্যা লক্ষ্য করেন, আপনি অবিলম্বে পতাকাটিকে তার আগের মানটিতে ফিরিয়ে দিতে পারেন এবং পরিবর্তনগুলি ফিরিয়ে আনা হবে৷

এই পরিষেবাটির খারাপ দিকগুলিও রয়েছে: বিকাশকারীরা এটিকে খুব পছন্দ করে এবং প্রায়শই স্টপ ট্যাপে সমস্ত পরিবর্তনগুলি ঠেলে দেওয়ার চেষ্টা করে৷ আমরা অপব্যবহার প্রতিরোধ করার চেষ্টা করছি।

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

যাইহোক, স্টপ ট্যাপ উন্নয়নের সময় পরীক্ষার জন্য উপযুক্ত নয়। ডেভেলপারদের জন্য "শ্যাডো ক্লাস্টার" নামে একটি পৃথক ক্লাস্টার রয়েছে।

গোপন পরীক্ষা: ছায়া ক্লাস্টার

ক্লাস্টারগুলির একটি থেকে অনুরোধগুলি ছায়া ক্লাস্টারে নকল করা হয়েছে৷ কিন্তু ব্যালেন্সার সম্পূর্ণরূপে এই ক্লাস্টার থেকে প্রতিক্রিয়া উপেক্ষা করে. এর ক্রিয়াকলাপের চিত্রটি নীচে উপস্থাপন করা হয়েছে।

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

এবং যেহেতু ব্যালেন্সার সম্পূর্ণরূপে প্রতিক্রিয়া উপেক্ষা করে, শেষ ব্যবহারকারীরা ছায়া ক্লাস্টার থেকে প্রতিক্রিয়া দেখতে পাবে না। অতএব, ভুল করা ভীতিজনক নয়।

তথ্যও

সুতরাং, আমরা কিভাবে বাজার অনুসন্ধান তৈরি করেছি?

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

ছায়া ক্লাস্টার আমাদের সাহায্য করে: আমরা পরিষেবাগুলি বিকাশ করতে পারি, প্রক্রিয়াটিতে সেগুলি পরীক্ষা করতে পারি এবং ব্যবহারকারীকে বিরক্ত করতে পারি না।

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

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

উত্স: www.habr.com