গত বছর, উবার ইঞ্জিনিয়ারিং দল তাদের মাইক্রোসার্ভিস আর্কিটেকচারের জন্য ডিজাইন করা তাদের নতুন লোডশেডিং মেকানিজমের উপর একটি নিবন্ধ প্রকাশ করেছে ।
এই নিবন্ধটি বিভিন্ন দৃষ্টিকোণ থেকে খুব আকর্ষণীয়. তাই, আমি কিছু নোট নিয়েছিলাম যখন আমি এটি পড়ছিলাম আমার বোধগম্যতা ক্যাপচার করার জন্য এবং এমন জিনিসগুলি লিখতে যা আমি পরে আরও গভীরে যেতে চাই যদি আমি শেষ পর্যন্ত উত্তর না পাই। আমি একাধিকবার খুঁজে পেয়েছি যে এটি আমার জন্য নতুন জিনিস শেখার সর্বোত্তম উপায়।
শুরু থেকে আমাকে যা পেয়েছিল তা হল এই সমাধানটি তৈরি করতে ব্যবহৃত শতাব্দী-পুরাতন নীতিগুলির উল্লেখ। এটি এমন কিছু যা আমি পছন্দ করি — বিভিন্ন ক্ষেত্র থেকে ধারণা/ধারণা ধার করা এবং একটি ভিন্ন ডোমেনে সমস্যা সমাধানের জন্য তাদের অভিযোজিত করা।
যদি সিস্টেমের স্থিতিস্থাপকতা এবং স্থিতিশীলতা আপনার আগ্রহের বিষয় হয়, তবে আমি 'রিলিজ ইট!' চমৎকার বইটি পড়ার পরামর্শ দিই। মাইকেল টি. নাইগার্ড দ্বারা।
এটি একটি পুরানো কিন্তু একটি ভাল জিনিস - একটি বই যা কৌশল, নিদর্শন এবং স্থিতিস্থাপক এবং স্থিতিশীল সফ্টওয়্যার সিস্টেম তৈরির জন্য ব্যবহারিক নির্দেশিকা, কীভাবে ব্যর্থতাগুলিকে কার্যকরভাবে পরিচালনা করতে হয় তার উপর জোর দেয়।
Uber দারুচিনি নামক একটি নতুন লোডশেডিং সমাধান প্রয়োগ করেছে যা পরিষেবার বর্তমান লোড এবং অনুরোধের অগ্রাধিকারের উপর ভিত্তি করে কোন পরিষেবা দ্বারা কোন অনুরোধগুলি প্রক্রিয়া করা বা বাতিল করা উচিত তা সিদ্ধান্ত নিতে একটি পিআইডি কন্ট্রোলার (শতবর্ষ-পুরাতন প্রক্রিয়া) এর সুবিধা নেয়৷
এটি পরিষেবা স্তরে কোনও টিউনিং জড়িত করে না (যদিও এটি সম্পর্কে আমার একটি প্রশ্ন ছিল), স্বয়ংক্রিয়ভাবে মানিয়ে নেওয়া যায় এবং তাদের আগের সমাধান QALM থেকে অনেক বেশি কার্যকর। এটাও মনে রাখবেন যে উবারের মাইক্রোসার্ভিসেস আর্কিটেকচার অজ্ঞান হৃদয়ের জন্য নয়...
একটি পিআইডি কন্ট্রোলার হল একটি যন্ত্র যা শিল্প নিয়ন্ত্রণ অ্যাপ্লিকেশনগুলিতে তাপমাত্রা, প্রবাহ, চাপ, গতি এবং অন্যান্য প্রক্রিয়ার ভেরিয়েবলগুলি নিয়ন্ত্রণ করতে ব্যবহৃত হয়। পিআইডি (আনুপাতিক অবিচ্ছেদ্য ডেরিভেটিভ) কন্ট্রোলারগুলি প্রক্রিয়া ভেরিয়েবলগুলি নিয়ন্ত্রণ করতে একটি নিয়ন্ত্রণ লুপ প্রতিক্রিয়া প্রক্রিয়া ব্যবহার করে এবং সবচেয়ে সঠিক এবং স্থিতিশীল নিয়ন্ত্রক।
আপনি যদি এই শতাব্দী প্রাচীন ধারণা সম্পর্কে আরও তথ্য চান, উইকিপিডিয়াতে যান।
এখন, নিবন্ধে ফিরে যান। পিআইডি মানে আনুপাতিক, ইন্টিগ্রাল এবং ডেরিভেটিভ। তাদের ক্ষেত্রে, তারা তিনটি উপাদান (বা ব্যবস্থা) এর উপর ভিত্তি করে একটি পরিষেবার (ইনপুট অনুরোধ) স্বাস্থ্য পর্যবেক্ষণ করতে একটি PID কন্ট্রোলার হিসাবে পরিচিত একটি উপাদান ব্যবহার করে।
"আনুপাতিক" শব্দটি নির্দেশ করে যে নেওয়া পদক্ষেপটি বর্তমান ত্রুটির সমানুপাতিক। সহজ কথায়, এর মানে হল যে প্রয়োগ করা সংশোধনটি পছন্দসই অবস্থা এবং প্রকৃত অবস্থার মধ্যে পার্থক্যের সরাসরি সমানুপাতিক। ত্রুটি বড় হলে, সংশোধনমূলক কর্ম আনুপাতিকভাবে বড় হয়।
যখন একটি এন্ডপয়েন্ট ওভারলোড হয়, তখন ব্যাকগ্রাউন্ড গোরুটিন অগ্রাধিকার সারিতে অনুরোধের প্রবাহ এবং বহিঃপ্রবাহ নিরীক্ষণ করতে শুরু করে।
সুতরাং, লোডশেডারের আনুপাতিক (P) উপাদানটি বর্তমান সারির আকার লক্ষ্য বা কাঙ্ক্ষিত সারির আকার থেকে কত দূরে তার উপর ভিত্তি করে শেডিং হার সামঞ্জস্য করে। যদি সারিটি পছন্দসই থেকে বড় হয়, তবে আরও শেডিং ঘটে; যদি এটি ছোট হয়, শেডিং হ্রাস করা হয়।
এটা আমার বোঝার.
পিআইডি কন্ট্রোলারের কাজ হল সারিবদ্ধ অনুরোধের সংখ্যা কমিয়ে আনা, যেখানে অটো-টিউনারের কাজ হল পরিষেবার থ্রুপুট সর্বাধিক করা, প্রতিক্রিয়া বিলম্বিত না করে (অত্যধিক)।
যদিও পাঠ্যটি সারি আকারের প্রসঙ্গে স্পষ্টভাবে "ইন্টিগ্রাল (আই)" উল্লেখ করে না, এটি ইঙ্গিত করে যে পিআইডি কন্ট্রোলারের ভূমিকা সারিবদ্ধ অনুরোধের সংখ্যা হ্রাস করা। সারিবদ্ধ অনুরোধের ন্যূনতমকরণ সময়ের সাথে জমা হওয়া ত্রুটিগুলি সমাধান করার ইন্টিগ্রাল উপাদানের লক্ষ্যের সাথে সারিবদ্ধ।
একটি এন্ডপয়েন্ট ওভারলোড হয়েছে কিনা তা নির্ধারণ করতে আমরা শেষবার অনুরোধ সারি খালি ছিল কিনা তা ট্র্যাক রাখি, এবং যদি শেষ 10 সেকেন্ডের মধ্যে খালি না করা হয় তবে আমরা শেষ পয়েন্টটিকে ওভারলোড বলে মনে করি (ফেসবুক দ্বারা অনুপ্রাণিত)।
লোডশেডারের মধ্যে, এটি অনুরোধ সারির ঐতিহাসিক আচরণের সাথে সম্পর্কিত সিদ্ধান্তের সাথে যুক্ত হতে পারে, যেমন এটি শেষবার খালি হওয়ার সময়।
সত্যি বলতে, এটা আমার কাছে পুরোপুরি পরিষ্কার নয়। এটা একটু হতাশাজনক, আমি বলতে হবে. যদিও তারা একটি শতাব্দী-প্রাচীন মেকানিজমকে কাজে লাগানোর কথা উল্লেখ করে, এটি সহায়ক হত যদি তারা স্পষ্টভাবে বলে যে কোন অংশটি কী বা কীভাবে এটি কাজ করে তার সাথে মিলে যায়। আমি তাদের আশ্চর্যজনক নিবন্ধের মান হ্রাস করতে চাই না। এটা এখানে শুধু আমার রট… সব পরে, আমি ফরাসি… ;)
আমি মনে করি এটি সনাক্ত করা সহজ।
একটি ক্লাসিক্যাল পিআইডি (আনুপাতিক-অখণ্ড-উত্পন্ন) কন্ট্রোলারে, "ডেরিভেটিভ (ডি)" অ্যাকশনটি বিশেষভাবে উপযোগী হয় যখন আপনি কন্ট্রোলারকে ত্রুটির পরিবর্তনের বর্তমান হারের উপর ভিত্তি করে সিস্টেমের ভবিষ্যত আচরণের পূর্বাভাস দিতে চান। এটি দোলনাকে স্যাঁতসেঁতে করতে এবং সিস্টেমের স্থিতিশীলতা উন্নত করতে সহায়তা করে।
নিবন্ধে উল্লিখিত লোডশেডার এবং পিআইডি কন্ট্রোলারের প্রেক্ষাপটে, অনুরোধের সারিটি কত দ্রুত পূরণ হচ্ছে তা মূল্যায়ন করার জন্য ডেরিভেটিভ উপাদান সম্ভবত নিযুক্ত করা হয়েছে। এটি করার মাধ্যমে, এটি একটি স্থিতিশীল সিস্টেম বজায় রাখা এবং আকস্মিক বা অপ্রত্যাশিত পরিবর্তনগুলি প্রতিরোধ করার লক্ষ্যে সিদ্ধান্ত নেওয়ার ক্ষেত্রে সহায়তা করে।
প্রত্যাখ্যানকারী উপাদানটির দুটি দায়িত্ব রয়েছে: ক) একটি এন্ডপয়েন্ট ওভারলোড হয়েছে কিনা তা বের করুন এবং খ), যদি একটি এন্ডপয়েন্ট ওভারলোড হয়, অনুরোধের সারিটি যতটা সম্ভব ছোট তা নিশ্চিত করতে অনুরোধের শতাংশ ভাগ করুন৷ যখন একটি এন্ডপয়েন্ট ওভারলোড হয়, তখন ব্যাকগ্রাউন্ড গোরুটিন অগ্রাধিকার সারিতে অনুরোধের প্রবাহ এবং বহিঃপ্রবাহ নিরীক্ষণ করতে শুরু করে। এই সংখ্যার উপর ভিত্তি করে, এটি একটি পিআইডি নিয়ামক ব্যবহার করে অনুরোধের অনুপাত নির্ধারণ করতে। পিআইডি কন্ট্রোলারটি খুব দ্রুত (যেমন খুব কম পুনরাবৃত্তির প্রয়োজন হয়) সঠিক স্তরটি খুঁজে বের করার জন্য এবং একবার অনুরোধের সারিটি নিষ্কাশন হয়ে গেলে, পিআইডি নিশ্চিত করে যে আমরা কেবলমাত্র ধীরে ধীরে অনুপাত কমিয়ে দিই।
উল্লিখিত প্রেক্ষাপটে, পিআইডি কন্ট্রোলারটি একটি এন্ডপয়েন্ট ওভারলোড হওয়ার সময় অনুরোধের অনুপাত নির্ধারণ করতে ব্যবহৃত হয় এবং এটি অনুরোধের প্রবাহ এবং বহিঃপ্রবাহ পর্যবেক্ষণ করে। পিআইডি কন্ট্রোলারের ডেরিভেটিভ কম্পোনেন্ট, যা পরিবর্তনের হারে সাড়া দেয়, অনুরোধের সারিটি কত দ্রুত ভরা বা নিষ্কাশন করা হচ্ছে তা মূল্যায়নে অন্তর্নিহিতভাবে জড়িত। এটি সিস্টেমের স্থিতিশীলতা বজায় রাখতে গতিশীল সিদ্ধান্ত নিতে সহায়তা করে।
ওভারলোড নির্ধারণের প্রেক্ষাপটে, অবিচ্ছেদ্য উপাদানটি ট্র্যাকিংয়ের সাথে যুক্ত হতে পারে অনুরোধের সারিটি কতক্ষণ খালি অবস্থায় নেই। এটি সময়ের সাথে ত্রুটি সংকেতের অবিচ্ছেদ্য জমা করার ধারণার সাথে সারিবদ্ধ।
"অখণ্ড — অনুরোধটি কতক্ষণ সারিতে ছিল তার উপর ভিত্তি করে..."
অন্যদিকে ডেরিভেটিভ উপাদানটি পরিবর্তনের হারের সাথে সম্পর্কিত। এটি অনুরোধ সারির অবস্থা কত দ্রুত পরিবর্তন হচ্ছে তার প্রতিক্রিয়া জানায়।
"ডেরিভেটিভ — প্রত্যাখ্যান কত দ্রুত সারি পূরণ হচ্ছে তার উপর ভিত্তি করে..."
ইন্টিগ্রাল কম্পোনেন্ট অ-খালি অবস্থার সময়কালের উপর জোর দেয়, যখন ডেরিভেটিভ কম্পোনেন্টটি সারির পরিবর্তনের হার বিবেচনা করে।
গেমের শেষে, তারা একটি অনুরোধের জন্য পদক্ষেপ নির্ধারণ করতে এই তিনটি ব্যবস্থা ব্যবহার করে।
আমার কাছে প্রশ্ন হল কিভাবে তারা এই তিনটি উপাদানকে একত্রিত করে, যদি তা হয়। আমি বুঝতে আগ্রহী যে তারা কীভাবে তাদের পর্যবেক্ষণ করে।
তবুও, আমি মনে করি আমি ধারণা পেয়েছি...
প্রান্তের শেষ পয়েন্টটি অনুরোধের অগ্রাধিকারের সাথে টীকা করা হয় এবং এটি Jaeger-এর মাধ্যমে প্রান্ত থেকে সমস্ত ডাউনস্ট্রিম নির্ভরতায় প্রচারিত হয়। এই তথ্য প্রচার করার মাধ্যমে, অনুরোধ চেইনের সমস্ত পরিষেবাগুলি অনুরোধের গুরুত্ব এবং আমাদের ব্যবহারকারীদের জন্য এটি কতটা গুরুত্বপূর্ণ তা জানতে পারবে।
মনের মধ্যে যে প্রথম চিন্তাটি আসে তা হল এটি নির্বিঘ্নে একটি পরিষেবা মেশ আর্কিটেকচারে একীভূত হবে।
আমি অনুরোধ অগ্রাধিকার প্রচার করার জন্য বিতরণ করা পরিষেবা ট্রেসিং এবং হেডার নিয়োগের ধারণার প্রশংসা করি। এই লাইনগুলির সাথে, কেন প্রতিটি মাইক্রোসার্ভিসে যোগ করা এই নির্ভরতা সহ একটি শেয়ার্ড লাইব্রেরি বেছে নেবেন, এটিকে পরিষেবার বাইরে রাখার পরিবর্তে, সম্ভবত একটি ইস্টিও প্লাগইন হিসাবে? এটি যে সুবিধাগুলি অফার করে তা বিবেচনা করে: স্বাধীন রিলিজ/ডিপ্লয়মেন্ট চক্র, পলিগ্লট সমর্থন ইত্যাদি।
এখানে কিছু অতিরিক্ত চিন্তা আছে:
ঠিক আছে, আমি পক্ষপাতদুষ্ট, কারণ আমি ভাগ করা লাইব্রেরিগুলির একটি বড় অনুরাগী নই, যদি আমি মনে করি যে তারা রিলিজ/ডিপ্লয়মেন্ট প্রক্রিয়াটিকে জটিল করে তোলে। যাইহোক, বিবেচনা করার জন্য একটি পরিষেবা-নির্দিষ্ট কনফিগারেশন দিক আছে কিনা তা আমি নিশ্চিত নই। সম্ভবত তারা কনফিগার করে যে পরিষেবাটি একটি প্রশ্ন প্রক্রিয়াকরণ শুরু করতে এবং এটি সম্পূর্ণ করতে কতক্ষণ অপেক্ষা করতে হবে?
সম্ভবত পরীক্ষা করার মতো একটি দিক হল ইজেক্টরের সিদ্ধান্ত গ্রহণের প্রক্রিয়া।
আমি যা বুঝি তা থেকে, এটি PID কন্ট্রোলারের উপর ভিত্তি করে একটি অনুরোধ প্রত্যাখ্যান করবে কিনা তা নির্ধারণ করে, যা পরিষেবাতে স্থানীয়করণ করা হয়েছে। একটি আরো বিশ্বব্যাপী পদ্ধতির জন্য একটি বিকল্প আছে? উদাহরণস্বরূপ, যদি এটি জানা যায় যে পাইপলাইনের একটি ডাউনস্ট্রিম পরিষেবাগুলি ওভারলোড করা হয়েছে (তার নিজস্ব পিআইডি কন্ট্রোলারের কারণে), কোন আপস্ট্রিম পরিষেবা কি এই ওভারলোডেড পরিষেবাতে পৌঁছানোর আগে অনুরোধটি প্রত্যাখ্যান করার সিদ্ধান্ত নিতে পারে (যা আরও নিচের ধাপ হতে পারে পথ)?
এই সিদ্ধান্ত পিআইডি কন্ট্রোলার বা ডাউনস্ট্রিম পরিষেবার অটো-টিউনার দ্বারা ফেরত দেওয়া মূল্যের উপর ভিত্তি করে হতে পারে।
এখন, আমি উল্লিখিত বিভিন্ন দিক নিয়ে চিন্তা করছি কারণ তারা নিবন্ধটি গুটিয়ে ফেলে এবং তাদের সিস্টেমের দক্ষতা প্রদর্শনের জন্য কিছু সংখ্যা প্রদান করে, যা বেশ চিত্তাকর্ষক
তারা কিছু সময়ে উল্লেখ করে যে 'প্রতিটি অনুরোধের সময়সীমা 1 সেকেন্ড থাকে।'
আমরা 5 মিনিটের পরীক্ষা চালাই, যেখানে আমরা একটি নির্দিষ্ট পরিমাণ RPS পাঠাই (যেমন, 1,000), যেখানে ট্রাফিকের 50% হল স্তর 1 এবং 50% হল স্তর 5৷ প্রতিটি অনুরোধের সময়সীমা 1 সেকেন্ড থাকে৷
বিতরণ করা সিস্টেমগুলিতে একটি নির্দিষ্ট মেয়াদ বা সময়সীমার সাথে একটি অনুরোধ যুক্ত করা সাধারণ, এই সময়সীমা কার্যকর করার জন্য দায়ী প্রক্রিয়াকরণ পথ বরাবর প্রতিটি পরিষেবার সাথে। অনুরোধটি সম্পূর্ণ হওয়ার আগে মেয়াদ শেষ হলে, চেইনের যেকোনো পরিষেবার অনুরোধ বাতিল বা প্রত্যাখ্যান করার বিকল্প রয়েছে।
আমি অনুমান করি যে এই 1-সেকেন্ডের সময়সীমা অনুরোধের সাথে সংযুক্ত আছে এবং প্রতিটি পরিষেবা, এই সময়সীমার মধ্যে আমরা কোথায় আছি তার উপর নির্ভর করে, অনুরোধটি বাতিল করার সিদ্ধান্ত নিতে পারে। এটি একটি পরিমাপ যা বিশ্বব্যাপী কারণ এটি পরিষেবার মাধ্যমে একত্রিত হয়। আমি মনে করি এটি সম্পূর্ণ সিস্টেমের স্বাস্থ্য বা নির্ভরতা সম্পর্কে একটি বিশ্বব্যাপী দৃষ্টিভঙ্গি রাখার বিষয়ে আগে যে পয়েন্টটি তৈরি করেছিলাম তার সাথে অনুরণিত হয় যদি অনুরোধটি যত তাড়াতাড়ি সম্ভব বাতিল করার সিদ্ধান্ত নেয় পথ
ডাউনস্ট্রিম পরিষেবাগুলির 'স্বাস্থ্য' (তাদের স্থানীয় পিআইডি নিয়ন্ত্রকদের থেকে ডেটা সমন্বিত) প্রতিক্রিয়াগুলির সাথে সংযুক্ত শিরোনাম হিসাবে ফেরত দেওয়া যেতে পারে এবং আরও উন্নত সার্কিট ব্রেকার/প্রাথমিক প্রিম্পিটিভ শেডিং মেকানিজম তৈরি করতে ব্যবহার করা যেতে পারে?
অবশেষে, আমি পূর্ববর্তী পদ্ধতি সম্পর্কে আরও জানতে আগ্রহী কারণ, এই কাগজে দেওয়া বর্ণনার উপর ভিত্তি করে, এটি সঠিক বলে মনে হচ্ছে।
আপনি যখন গুডপুট এবং বিলম্বের পরিমাপ পরীক্ষা করেন, তখন কোন সন্দেহ নেই, কোনটি, QALM বা দারুচিনি, সবচেয়ে ভালো পারফর্ম করে। উল্লেখ্য যে তারা নিবন্ধে QALM পদ্ধতির একটি লিঙ্ক উল্লেখ করেছে। সম্ভবত সেখান থেকে শুরু করা উচিত ;)
বরাবরের মতো, এই পদ্ধতিগুলি সবার জন্য নয়। উবারের আর্কিটেকচার এবং লোড তার নিজস্ব ধরনের। আমি আসলে এই সিরিজের পরবর্তী নিবন্ধগুলি পড়ার জন্য অধৈর্য, বিশেষ করে PID কন্ট্রোলার এবং অটো-টিউনার সম্পর্কে আরও জানতে।
দারুচিনির সাথে আমরা একটি দক্ষ লোড শেডার তৈরি করেছি যা পরিষেবাগুলির প্রত্যাখ্যান এবং অনুমান করার ক্ষমতা গতিশীলভাবে থ্রেশহোল্ড সেট করতে শতাব্দী-পুরনো কৌশল ব্যবহার করে। এটি QALM (এবং এইভাবে যেকোন CoDel-ভিত্তিক লোড শেডারের) সাথে আমরা লক্ষ্য করা সমস্যাগুলির সমাধান করে, যেমন, দারুচিনি করতে সক্ষম:
- দ্রুত একটি স্থিতিশীল প্রত্যাখ্যান হার খুঁজুন
- স্বয়ংক্রিয়ভাবে পরিষেবার ক্ষমতা সামঞ্জস্য করুন
- কোন কনফিগারেশন পরামিতি সেট না করে ব্যবহার করা হবে
- খুব কম ওভারহেড বহন
এই পদ্ধতির বিষয়ে যা আকর্ষণীয় তা হল যে তারা একটি (অগ্রাধিকার) সারি ব্যবহার করে প্রতিটি নতুন ইনপুট অনুরোধের জন্য কী করতে হবে তা সিদ্ধান্ত নেওয়ার জন্য সমস্ত অনুরোধগুলিকে প্রক্রিয়া করা হবে বলে বিবেচনা করে। উল্লিখিত হিসাবে, আমি কৌতূহলী যদি প্রক্রিয়াটি একই পিআইডি ব্যবস্থার উপর ভিত্তি করে সমস্ত নির্ভরশীল পরিষেবাগুলির স্বাস্থ্যকেও বিবেচনা করতে পারে…
এই নিবন্ধে অন্যান্য আকর্ষণীয় দিক রয়েছে, যেমন তারা কীভাবে তাদের কৌশলগুলির প্রভাব পরিমাপ করে এবং পূর্ববর্তী পদ্ধতির সাথে তুলনা করে। যাইহোক, এটি ইতিমধ্যে উপস্থাপিত করা থেকে আমার কাছ থেকে আরও বিস্তারিত নোটের প্রয়োজন নেই। তাই, আমি আপনাকে মূল নিবন্ধটি পড়তে উত্সাহিত করছি।
এই নিবন্ধটি দরকারী পাওয়া গেছে? লিঙ্কডইন , হ্যাকারনুন এবং মিডিয়ামে আমাকে অনুসরণ করুন ! অনুগ্রহ করে 👏 এই নিবন্ধটি শেয়ার করুন!
এছাড়াও এখানে প্রকাশিত.