Istio সার্কিট ব্রেকার: ত্রুটিপূর্ণ পাত্রে নিষ্ক্রিয় করা

ছুটি শেষ হয়ে গেছে এবং আমরা ইস্টিও সার্ভিস মেশ সিরিজে আমাদের দ্বিতীয় পোস্ট নিয়ে ফিরে এসেছি।

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

কিভাবে এই আদর্শভাবে কাজ করা উচিত

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

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

এটা সত্যিই কিভাবে কাজ করে

এখন কল্পনা করুন যে একটি মাইক্রোসার্ভিসের একটি নির্দিষ্ট উদাহরণ, অর্থাৎ একটি ধারক, অব্যবহারযোগ্য হয়ে উঠেছে: হয় এটি সাড়া দেয় না (ত্রুটি 503), বা, যা আরও অপ্রীতিকর, এটি সাড়া দেয়, তবে খুব ধীরে। অন্য কথায়, এটি গ্লিচি হয়ে যায় বা অনুরোধে সাড়া দেয় না, তবে এটি স্বয়ংক্রিয়ভাবে পুল থেকে সরানো হয় না। এই ক্ষেত্রে কি করা উচিত? আবার চেষ্টা করতে? আমি কি রাউটিং স্কিম থেকে এটি অপসারণ করব? এবং "খুব ধীর" এর অর্থ কী - এটি সংখ্যায় কত, এবং কে সেগুলি নির্ধারণ করে? সম্ভবত এটি একটি বিরতি দিন এবং পরে আবার চেষ্টা করুন? যদি তাই হয়, কত পরে?

ইস্টিওতে পুল ইজেকশন কি?

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

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

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

একটি ক্র্যাশ জন্য প্রস্তুত হচ্ছে

পুল ইজেকশন করার আগে, আপনাকে একটি ইস্টিও রাউটিং নিয়ম তৈরি করতে হবে। ধরা যাক আমরা 50/50 অনুপাতে পডগুলির মধ্যে অনুরোধগুলি বিতরণ করতে চাই৷ উপরন্তু, আমরা v2 কন্টেইনারের সংখ্যা এক থেকে দুই বাড়িয়ে দেব, যেমন:

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

এখন আমরা একটি রাউটিং নিয়ম সেট করেছি যাতে 50/50 অনুপাতে পডের মধ্যে ট্র্যাফিক বিতরণ করা হয়।

এই নিয়মের ফলাফল কেমন দেখায় তা এখানে:

আপনি এই স্ক্রীনটি 50/50 নয়, 14:9 এর সাথে ত্রুটি খুঁজে পেতে পারেন, তবে সময়ের সাথে সাথে পরিস্থিতির উন্নতি হবে।

একটি ত্রুটি করা

এখন আসুন দুটি v2 পাত্রের একটি নিষ্ক্রিয় করি যাতে আমাদের কাছে একটি স্বাস্থ্যকর v1 ধারক, একটি স্বাস্থ্যকর v2 ধারক এবং একটি ত্রুটিপূর্ণ v2 ধারক থাকে:

ত্রুটি ঠিক করা

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

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

স্থাপত্য নির্মাণ শুরু করা যাক

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

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

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

তত্ত্বে সার্কিট ব্রেকার

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

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

অনুশীলনে সার্কিট ব্রেকার

উদাহরণস্বরূপ, আমরা OpenShift-এ আমাদের সুপারিশ মাইক্রোসার্ভিসের দুটি সংস্করণ চালাব। সংস্করণ 1 ভাল কাজ করবে, কিন্তু v2 তে আমরা সার্ভারে স্লোডাউন অনুকরণ করতে বিলম্বে তৈরি করব। ফলাফল দেখতে, টুল ব্যবহার করুন নিরোধ:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

সবকিছু কাজ বলে মনে হচ্ছে, কিন্তু কি খরচে? প্রথম নজরে, আমাদের কাছে 100% প্রাপ্যতা রয়েছে, তবে আরও ঘনিষ্ঠভাবে দেখুন - সর্বাধিক লেনদেনের সময়কাল 12 সেকেন্ডের মতো। এটি স্পষ্টতই একটি বাধা এবং প্রসারিত করা প্রয়োজন।

এটি করার জন্য, আমরা ধীর কন্টেইনারে কলগুলি দূর করতে Istio ব্যবহার করব। সার্কিট ব্রেকার ব্যবহার করে সংশ্লিষ্ট কনফিগারেশনটি দেখতে কেমন লাগে:

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

ঠিক আছে, আমাদের সার্কিট ব্রেকার আছে, এরপর কি?

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

মনে রাখবেন যে একটি অ্যাপ্লিকেশনের একটি 503 ত্রুটির প্রতিক্রিয়া করার ক্ষমতা এখনও সোর্স কোড স্তরে সেট করা আছে৷ পরিস্থিতির উপর নির্ভর করে সার্কিট ব্রেকার ব্যবহার করার জন্য অনেক কৌশল রয়েছে।

পরবর্তী পোস্টে: আমরা ইতিমধ্যেই অন্তর্নির্মিত বা সহজেই ইস্টিওতে যোগ করা ট্রেসিং এবং মনিটরিং কভার করব, সেইসাথে কীভাবে ইচ্ছাকৃতভাবে সিস্টেমে ত্রুটিগুলি প্রবর্তন করা যায়।

উত্স: www.habr.com