Mail.ru ক্লাউড সলিউশন প্ল্যাটফর্মে কীভাবে একটি ত্রুটি-সহনশীল ওয়েব আর্কিটেকচার প্রয়োগ করা হয়

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

প্ল্যাটফর্মটির সামগ্রিক স্থিতিস্থাপকতা এর উপাদানগুলোর স্থিতিস্থাপকতার উপর নির্ভর করে। তাই, আমরা পর্যায়ক্রমে সেই সমস্ত স্তরগুলো নিয়ে কাজ করব যেখানে আমরা ঝুঁকিগুলো চিহ্নিত ও সমাধান করেছি।

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

ভৌত স্থাপত্যের ত্রুটি সহনশীলতা

এমসিএস ক্লাউডের পাবলিক অংশটি বর্তমানে দুটি টিয়ার III ডেটা সেন্টারে অবস্থিত, যা পৃথক ফিজিক্যাল রিডানডেন্সি এবং ২০০ জিবিপিএস থ্রুপুট সহ একটি ডেডিকেটেড ডার্ক ফাইবার নেটওয়ার্ক দ্বারা সংযুক্ত। টিয়ার III ফিজিক্যাল ইনফ্রাস্ট্রাকচারের জন্য প্রয়োজনীয় ফল্ট টলারেন্সের মাত্রা প্রদান করে।

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

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

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

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

ভৌত অবকাঠামোর স্থিতিস্থাপকতা

অ্যাপ্লিকেশন-স্তরের ত্রুটি সহনশীলতার জন্য আমরা যা ব্যবহার করি

আমাদের পরিষেবাটি বেশ কিছু ওপেনসোর্স উপাদানের ওপর ভিত্তি করে নির্মিত।

ExaBGP — একটি পরিষেবা যা BGP-ভিত্তিক ডাইনামিক রাউটিং প্রোটোকল ব্যবহার করে বিভিন্ন ফাংশন বাস্তবায়ন করে। আমরা আমাদের হোয়াইটলিস্টেড আইপি অ্যাড্রেসগুলো প্রচার করতে এটি সক্রিয়ভাবে ব্যবহার করি, যার মাধ্যমে ব্যবহারকারীরা এপিআই অ্যাক্সেস করেন।

HAProxy — একটি উচ্চ-লোড লোড ব্যালান্সার যা আপনাকে OSI মডেলের বিভিন্ন স্তরে অত্যন্ত নমনীয় ট্র্যাফিক ব্যালান্সিং নিয়ম কনফিগার করার সুযোগ দেয়। আমরা এটি সমস্ত পরিষেবা জুড়ে লোড ব্যালান্সিংয়ের জন্য ব্যবহার করি: ডেটাবেস, মেসেজ ব্রোকার, এপিআই পরিষেবা, ওয়েব পরিষেবা এবং আমাদের অভ্যন্তরীণ প্রকল্প—যার সবই HAProxy দ্বারা চালিত।

এপিআই অ্যাপ্লিকেশন — পাইথনে লেখা একটি ওয়েব অ্যাপ্লিকেশন, যার সাহায্যে ব্যবহারকারী তার পরিকাঠামো ও পরিষেবা পরিচালনা করেন।

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

ওপেনস্ট্যাক অ্যাপ্লিকেশন স্ট্যান্ডার্ড আর্কিটেকচার

ওপেনস্ট্যাকের জন্য তৈরি বেশিরভাগ সার্ভিস একটি সমন্বিত মডেল অনুসরণ করার চেষ্টা করে। একটি সার্ভিসে সাধারণত দুটি অংশ থাকে: একটি এপিআই (API) এবং ওয়ার্কার (ব্যাকএন্ড এক্সিকিউটর)। সাধারণত, এপিআই হলো পাইথনে লেখা একটি WSGI অ্যাপ্লিকেশন, যা একটি স্বতন্ত্র প্রসেস (ডেমন) হিসেবে অথবা Nginx বা Apache-এর মতো কোনো ওয়েব সার্ভার ব্যবহার করে চলে। এপিআই ব্যবহারকারীর অনুরোধ প্রসেস করে এবং এক্সিকিউশনের জন্য ওয়ার্কার অ্যাপ্লিকেশনে পরবর্তী নির্দেশনা পাঠিয়ে দেয়। এই আদান-প্রদান একটি মেসেজ ব্রোকারের মাধ্যমে ঘটে, যা সাধারণত RabbitMQ হয়ে থাকে; অন্য ধরনের ব্রোকার খুব একটা সমর্থিত নয়। মেসেজগুলো ব্রোকারে পৌঁছালে, ওয়ার্কাররা সেগুলো প্রসেস করে এবং প্রয়োজনে একটি রেসপন্স ফেরত পাঠায়।

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

ওয়ার্কার অ্যাপ্লিকেশনের সংখ্যার কোনো সীমা নেই, তাই পারফরম্যান্স ও ফল্ট টলারেন্স বাড়ানোর জন্য ব্যালেন্সারের পেছনে এপিআই-কে সহজেই হরাইজন্টালি স্কেল করা যায়।

কিছু পরিষেবার জন্য আন্তঃ-পরিষেবা সমন্বয়ের প্রয়োজন হয়—যখন এপিআই (API) এবং ওয়ার্কারদের মধ্যে জটিল অনুক্রমিক অপারেশন সংঘটিত হয়। এক্ষেত্রে, একটি একক সমন্বয় কেন্দ্র ব্যবহার করা হয়, যা হলো রেডিস (Redis), মেমক্যাশ (Memcache), ইটিসিডি (etcd)-এর মতো একটি ক্লাস্টার সিস্টেম। এটি একজন ওয়ার্কারকে অন্যজনকে জানাতে দেয় যে তাকে একটি কাজ বরাদ্দ করা হয়েছে ("দয়া করে এটি নিও না")। আমরা ইটিসিডি ব্যবহার করি। সাধারণত, ওয়ার্কাররা ডেটাবেসের সাথে সক্রিয়ভাবে যোগাযোগ করে এবং সেখান থেকে তথ্য লেখে ও পড়ে। আমরা আমাদের ডেটাবেস হিসেবে মারিয়াডিবি (mariadb) ব্যবহার করি, যা আমাদের মাল্টি-মাস্টার ক্লাস্টারে অবস্থিত।

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

পুরো পরিকল্পনাটির দুর্বল দিক হলো RabbitMQ এবং MariaDB। এদের স্থাপত্য নিয়ে একটি পৃথক প্রবন্ধ লেখা যেতে পারে। এই প্রবন্ধে আমি এপিআই ফল্ট টলারেন্সের উপর আলোকপাত করতে চাই।

ওপেনস্ট্যাক অ্যাপ্লিকেশন আর্কিটেকচার: একটি ক্লাউড প্ল্যাটফর্মের জন্য ভারসাম্য এবং ফল্ট টলারেন্স

ExaBGP ব্যবহার করে HAProxy লোড ব্যালেন্সারকে ফল্ট-টলারেন্ট করা

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

প্রথম যে সমস্যাটির সমাধান করা প্রয়োজন ছিল, তা হলো লোড ব্যালান্সারটির নিজস্ব ফল্ট টলারেন্স। শুধু লোড ব্যালান্সার ইনস্টল করলেই একটি একক ব্যর্থতার উৎস তৈরি হয়: লোড ব্যালান্সারটি ব্যর্থ হলে পরিষেবাটি বন্ধ হয়ে যায়। এটি প্রতিরোধ করার জন্য, আমরা ExaBGP-এর সাথে HAProxy ব্যবহার করেছি।

ExaBGP একটি সার্ভিস হেলথ চেক মেকানিজম সক্ষম করে। আমরা এই মেকানিজমটি ব্যবহার করে HAProxy-এর স্বাস্থ্য পরীক্ষা করেছি এবং কোনো সমস্যা দেখা দিলে BGP থেকে HAProxy সার্ভিসটিকে নিষ্ক্রিয় করে দিয়েছি।

ExaBGP+HAProxy স্কিম

1. আমরা তিনটি সার্ভারে প্রয়োজনীয় সফটওয়্যার, ExaBGP এবং HAProxy, ইনস্টল করি।
2. আমরা প্রতিটি সার্ভারে একটি লুপব্যাক ইন্টারফেস তৈরি করি।
3. তিনটি সার্ভারেই আমরা এই ইন্টারফেসে একই হোয়াইট আইপি অ্যাড্রেস রেজিস্টার করি।
4. হোয়াইট আইপি অ্যাড্রেসটি ExaBGP-এর মাধ্যমে ইন্টারনেটে ঘোষণা করা হয়।

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

HAProxy-তে সমস্যা হলে বা সার্ভার বিকল হয়ে গেলে, ExaBGP রাউটটির বিজ্ঞাপন দেওয়া বন্ধ করে দেয় এবং ট্র্যাফিক নির্বিঘ্নে অন্য একটি সার্ভারে স্থানান্তরিত হয়।

এইভাবে আমরা ব্যালান্সারটির ত্রুটি সহনশীলতা অর্জন করেছি।

এইচএপ্রক্সি লোড ব্যালেন্সার ফল্ট টলারেন্স

সেটআপটি নিখুঁত ছিল না: আমরা HAProxy-এর ব্যাকআপ নেওয়া শিখেছিলাম, কিন্তু সার্ভিসগুলোর মধ্যে লোড কীভাবে বন্টন করতে হয় তা শিখিনি। তাই আমরা সেটআপটি সামান্য প্রসারিত করে একাধিক পাবলিক আইপি অ্যাড্রেসের মধ্যে লোড ব্যালান্সিং শুরু করেছি।

ডিএনএস-ভিত্তিক লোড ব্যালেন্সিং প্লাস বিজিপি

আমাদের HAProxy-এর সামনে লোড ব্যালান্সিং-এর সমস্যাটি অমীমাংসিতই রয়ে গেছে। তবে, এটি বেশ সহজেই সমাধান করা যায়, যেমনটা আমরা আমাদের নিজেদের ক্ষেত্রে করেছি।

তিনটি সার্ভারকে ভারসাম্যপূর্ণ রাখতে আপনার তিনটি পাবলিক আইপি অ্যাড্রেস এবং প্রচলিত ডিএনএস প্রয়োজন হবে। এই অ্যাড্রেসগুলোর প্রত্যেকটি প্রতিটি এইচএপ্রক্সি (HAProxy)-এর লুপব্যাক ইন্টারফেসে বরাদ্দ করা হয় এবং ইন্টারনেটে প্রচার করা হয়।

ওপেনস্ট্যাক রিসোর্স ব্যবস্থাপনার জন্য একটি সার্ভিস ক্যাটালগ ব্যবহার করে, যা প্রতিটি সার্ভিসের জন্য এপিআই এন্ডপয়েন্ট নির্ধারণ করে দেয়। এই ক্যাটালগে, আমরা একটি ডোমেইন নেম—public.infra.mail.ru—নির্দিষ্ট করে দিই, যা ডিএনএস (DNS)-এর মাধ্যমে তিনটি ভিন্ন আইপি অ্যাড্রেসে রিজলভ হয়। এর ফলে ডিএনএস ব্যবহার করে এই তিনটি অ্যাড্রেসের মধ্যে লোড ব্যালান্সিং হয়।

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

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

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

DNS এবং BGP ব্যবহার করে HAProxy লোড ব্যালান্সিং

ExaBGP এবং HAProxy এর মধ্যে মিথস্ক্রিয়া

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

সুতরাং, পূর্ববর্তী পরিকল্পনার সম্প্রসারণ হিসেবে, আমরা ExaBGP এবং HAProxy-এর মধ্যে একটি হার্টবিট বাস্তবায়ন করেছি। এটি ExaBGP এবং HAProxy-এর মধ্যকার মিথস্ক্রিয়ার একটি সফটওয়্যার বাস্তবায়ন, যেখানে ExaBGP অ্যাপ্লিকেশনগুলোর অবস্থা পরীক্ষা করার জন্য কাস্টম স্ক্রিপ্ট ব্যবহার করে।

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

এইচএপ্রক্সি স্বাস্থ্য পরীক্ষা

HAProxy পিয়ার: সেশন সিঙ্ক্রোনাইজেশন

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

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

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

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

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

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

আমাদের একই প্রযুক্তি ব্যবহার করে নির্মিত একটি IaaS পরিষেবা রয়েছে। ওপেনস্ট্যাকের জন্য পরিষেবা হিসেবে লোড ব্যালেন্সারএর নাম অক্টাভিয়া। এটি দুটি HAProxy প্রসেসের উপর ভিত্তি করে তৈরি এবং এতে পিয়ারদের জন্য নেটিভ সাপোর্ট রয়েছে। এই পরিষেবার জন্য তারা নিজেদেরকে চমৎকার হিসেবে প্রমাণ করেছে।

চিত্রটিতে তিনটি HAProxy ইনস্ট্যান্সের মধ্যে পিয়ার টেবিলের চলাচল পরিকল্পিতভাবে দেখানো হয়েছে, এবং এটি কীভাবে সেট আপ করা যেতে পারে তা বোঝানোর জন্য একটি কনফিগারেশন প্রদান করা হয়েছে:

HAProxy পিয়ার্স (সেশন সিঙ্ক্রোনাইজেশন)

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

একই ক্লায়েন্ট থেকে একযোগে অনুরোধের সংখ্যা সীমিত করা

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

উভয় ক্ষেত্রেই, অতিরিক্ত নিরাপত্তা ব্যবস্থা গ্রহণ করা প্রয়োজন। একটি সুস্পষ্ট সমাধান হলো এপিআই (API) অনুরোধের সংখ্যা সীমিত করা এবং ক্ষতিকর অনুরোধ প্রক্রিয়াকরণে সিপিইউ (CPU)-এর সময় অপচয় করা থেকে বিরত থাকা।

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

বাস্তবে এটি কীভাবে কাজ করে? আমাদের এমন গ্রাহক আছেন যারা অটোস্কেলিংয়ের জন্য প্রতিনিয়ত আমাদের এপিআই (API) ব্যবহার করেন। তারা সকালে প্রায় দুই থেকে তিনশ ভার্চুয়াল মেশিন তৈরি করেন এবং সন্ধ্যায় সেগুলো মুছে ফেলেন। ওপেনস্ট্যাকের ক্ষেত্রে, একটি ভার্চুয়াল মেশিন তৈরি করতে, বিশেষ করে PaaS পরিষেবাগুলোর সাথে, কমপক্ষে ১,০০০টি এপিআই অনুরোধের প্রয়োজন হয়, কারণ পরিষেবাগুলোর মধ্যেকার মিথস্ক্রিয়াও এপিআই-এর মাধ্যমেই ঘটে থাকে।

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

ব্যবহারকারীদের জন্য কীভাবে আপনার কোডবেস নির্বিঘ্নে আপডেট করবেন

আমরা কোড ডেপ্লয়মেন্ট প্রক্রিয়ার স্তরেও ফল্ট টলারেন্স প্রয়োগ করি। ডেপ্লয়মেন্টের সময় ব্যর্থতা ঘটতেই পারে, কিন্তু পরিষেবার প্রাপ্যতার উপর এর প্রভাব ন্যূনতম রাখা সম্ভব।

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

এই সমস্যাটি সমাধান করার জন্য, ব্যালেন্সার ব্যবস্থাপনা এবং 'সঠিক' পরিষেবা বন্ধ করা নিশ্চিত করা প্রয়োজন ছিল:

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

এই দুটি বিষয়ের জন্য, আমাদের নিরাপদ ডেপ্লয়মেন্ট অ্যালগরিদমটি দেখতে এইরকম।

1. ডেভেলপার একটি নতুন কোড প্যাকেজ (আমাদের ক্ষেত্রে, এটি RPM) তৈরি করেন, সেটিকে ডেভ এনভায়রনমেন্টে পরীক্ষা করেন, স্টেজ এনভায়রনমেন্টে পরীক্ষা করেন এবং স্টেজ রিপোজিটরিতে রেখে দেন।
2. ডেভেলপার 'আর্টিফ্যাক্টস'-এর অত্যন্ত বিশদ বিবরণসহ একটি ডেপ্লয়মেন্ট টাস্ক সেট করেন: যেমন নতুন প্যাকেজের ভার্সন, নতুন কার্যকারিতার বিবরণ এবং প্রয়োজন হলে, অন্যান্য ডেপ্লয়মেন্ট সংক্রান্ত তথ্য।
3. সিস্টেম অ্যাডমিনিস্ট্রেটর আপডেটটি শুরু করেন। তিনি অ্যানসিবল প্লেবুকটি চালান, যা ফলস্বরূপ নিম্নলিখিত কাজগুলো করে:
   • স্টেজ রিপোজিটরি থেকে একটি প্যাকেজ নিয়ে তার উপর ভিত্তি করে প্রোডাকশন রিপোজিটরিতে থাকা প্যাকেজের ভার্সন আপডেট করে।
   • যে সার্ভিসটি আপডেট করা হচ্ছে, তার জন্য ব্যাকএন্ডগুলোর একটি তালিকা তৈরি করে।
   • HAProxy-তে আপডেট করা হচ্ছে এমন প্রথম সার্ভিসটি বন্ধ করে দেয় এবং এর প্রসেসগুলো টার্মিনেট হওয়ার জন্য অপেক্ষা করে। গ্রেসফুল শাটডাউনের মাধ্যমে আমরা নিশ্চিত করি যে ক্লায়েন্টের সমস্ত চলমান অনুরোধ সফলভাবে সম্পন্ন হয়।
   • API ও ওয়ার্কারগুলো সম্পূর্ণরূপে বন্ধ করার এবং HAProxy বন্ধ করার পর কোডটি আপডেট করা হয়।
   • অ্যানসিবল সার্ভিসগুলো চালু করে।
   • প্রতিটি সার্ভিসের জন্য নির্দিষ্ট 'হ্যান্ডেল' সংগ্রহ করা হয়, যা পূর্বনির্ধারিত কিছু মূল পরীক্ষার ভিত্তিতে ইউনিট টেস্টিং করে। নতুন কোডের প্রাথমিক যাচাইকরণ সম্পন্ন হয়।
   • পূর্ববর্তী ধাপে কোনো ত্রুটি না পাওয়া গেলে, ব্যাকএন্ড সক্রিয় করা হয়।
   • চলুন পরবর্তী ব্যাকএন্ডে যাওয়া যাক।
4. সমস্ত ব্যাকএন্ড আপডেট করার পর ফাংশনাল টেস্ট চালানো হয়। যদি কোনো টেস্ট অনুপস্থিত থাকে, তবে ডেভেলপার তার দ্বারা বাস্তবায়িত নতুন কার্যকারিতাগুলো পর্যালোচনা করেন।

এর মাধ্যমে স্থাপন প্রক্রিয়াটি সম্পন্ন হলো।

পরিষেবা আপডেট চক্র

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

উপসংহার

ফল্ট-টলারেন্ট ওয়েব আর্কিটেকচার বিষয়ে আমার চিন্তাভাবনা তুলে ধরতে গিয়ে, আমি এর মূল বিষয়গুলো পুনরায় উল্লেখ করতে চাই:

• ভৌত ত্রুটি সহনশীলতা;
• নেটওয়ার্ক ফল্ট টলারেন্স (ব্যালেন্সার, বিজিপি);
• ব্যবহৃত ও বিকশিত সফটওয়্যারের ত্রুটি সহনশীলতা।

সকলের আপটাইম স্থিতিশীল থাকুক!

উত্স: www.habr.com