etcd-এর মাধ্যমে এশিয়া প্যাসিফিক ভিডিও ট্রাফিক রাউটিং
এশিয়া-প্যাসিফিক অঞ্চলের আটটি বাজারকে পরিষেবা প্রদানকারী একটি ভিডিও-স্ট্রিমিং প্ল্যাটফর্ম অঞ্চল-ভিত্তিক কনফিগারেশন etcd-তে স্থানান্তরের মাধ্যমে একটি বারবার ঘটা রাউটিং ভুল বন্ধ করেছে। রাউটিং পরিবর্তনের প্রোপাগেশন টাইম কমে প্রায় এক সেকেন্ডে নেমে এসেছে। এডিটররা এখন কোড পরিবর্তন না করেই কয়েক ঘণ্টার জন্য একটি মিউজিক পুল বুস্ট করতে পারেন, এবং প্ল্যাটফর্মটি দক্ষিণ কোরিয়ার দর্শকদের টোকিও ফিড পাঠানো বন্ধ করেছে।
কেন পুরনো পদ্ধতিটি ব্যর্থ হয়েছিল
প্রতিটি রাউটার প্রতিটি রিকোয়েস্টের জন্য তিনটি ভ্যালু পড়ত: ট্রেন্ডিং পুল, ল্যাঙ্গুয়েজ-স্পেসিফিক টোকেনাইজার এবং একটি ফলব্যাক চেইন। কোড পরিবর্তনের পরিবর্তে ব্যবসায়িক সিদ্ধান্তগুলো—যেমন নতুন কোনো শিল্পীকে প্রোমোট করা, আঞ্চলিক কোনো বিভ্রাটের প্রতিক্রিয়া জানানো বা রিকমেন্ডেশন অ্যালগরিদম পরীক্ষা করা—এই ভ্যালুগুলোকে নিয়ন্ত্রণ করত।
শুরুতে প্রতিটি ডেপ্লয়মেন্টের সাথে রাউটিং টেবিলসহ একটি JSON ফাইল যুক্ত থাকত। কোনো সমস্যার সময় একজন অন-কল ইঞ্জিনিয়ার একটি নোডে ট্রাফিককে ব্যাকআপ পুলে পাঠানোর জন্য ফাইলটি এডিট করেছিলেন, কিন্তু অন্য সাতটি নোড আপডেট করেননি। এর ফলে 'কনফিগ ড্রিফট' (Config drift) দেখা দেয়: আটটি দেশ ভিন্ন ভিন্ন টেবিল ব্যবহার করছিল এবং কোনো একক উৎস থেকে তথ্যের সত্যতা যাচাই করা সম্ভব হচ্ছিল না। সিউল থেকে দর্শকদের টোকিওতে পাঠানোর বাগটি থেকে গিয়েছিল কারণ কোড একই ছিল; শুধুমাত্র লুকানো কনফিগারেশনে পার্থক্য ছিল।
সিঙ্গেল সোর্স অফ ট্রুথ হিসেবে etcd নির্বাচন
টিম তিনটি বিকল্পের মধ্যে তুলনা করেছিল:
- SQLite/MySQL – এটি প্রতিটি রাউটারকে একটি ডাটাবেস পোল করতে বাধ্য করত, যা ল্যাটেন্সি বাড়িয়ে দিত বা কুয়েরির চাপ সৃষ্টি করত।
- Consul – একটি শক্তিশালী সার্ভিস-ডিসকভারি টুল, কিন্তু প্ল্যাটফর্মটির এর সম্পূর্ণ মেশ (mesh) ফিচারের প্রয়োজন ছিল না।
- etcd – একটি স্ট্রংলি কনসিস্টেন্ট কী-ভ্যালু স্টোর যার একটি watch প্রিমিটিভ রয়েছে যা কোনো কী পরিবর্তন হওয়ার সাথে সাথে ক্লায়েন্টদের নোটিফাই করে।
watch ফিচারটি সিদ্ধান্ত নিতে সাহায্য করেছিল। প্রতিটি রাউটার বারবার "কিছু পরিবর্তন হয়েছে কি?"—এই প্রশ্ন করার পরিবর্তে, etcd আপডেট না পাঠানো পর্যন্ত রাউটারগুলো নিষ্ক্রিয় অবস্থায় থাকত। এর ফলে অপ্রয়োজনীয় নেটওয়ার্ক ট্রাফিক কমে গেল এবং প্রতিটি ইনস্ট্যান্স একই সাথে পরিবর্তনের কথা জানতে পারল।
সিস্টেমকে নিরাপদ রাখার প্যাটার্নসমূহ
Etcd একা সমস্ত ঝুঁকি সমাধান করেনি। ইঞ্জিনিয়াররা তিনটি পরিপূরক প্যাটার্ন যোগ করেছেন:
- Leases – একজন এডিটর একটি সাময়িক বুস্ট সেট করতে পারেন (যেমন, ছয় ঘণ্টার জন্য কোরিয়ান-পপ পুলের ওয়েট বাড়ানো)। লিজটি স্বয়ংক্রিয়ভাবে শেষ হয়ে যায়, তাই ম্যানুয়াল রোলব্যাক ছাড়াই বুস্টটি চলে যায়।
- Compare-and-swap (CAS) – যখন দুইজন ব্যক্তি একই সাথে একই সেটিংস এডিট করেন, তখন CAS একজনের জন্য ব্যর্থ হয় এবং এটি নীরবে ওভাররাইট হওয়া রোধ করে।
- Sidecar process – PHP দীর্ঘস্থায়ী কানেকশনের ক্ষেত্রে সমস্যার সম্মুখীন হয়। প্রতিটি বক্সে একটি ছোট Go সাইডকার প্রসেস etcd-কে পর্যবেক্ষণ করে এবং রাউটিং টেবিলের একটি স্ন্যাপশট একটি শেয়ার্ড-মেমরি ফাইলে (
/dev/shm) লিখে রাখে। PHP সেই লোকাল ফাইলটি পড়ে, ফলে রিকোয়েস্ট হ্যান্ডলিংয়ের সময় কোনো নেটওয়ার্ক রাউন্ড-ট্রিপের প্রয়োজন হয় না।
আর্কিটেকচারে বিল্ট-ইন রেজিলিয়েন্স
নতুন ডিজাইনটি বেশ কিছু সেফটি নেট যোগ করেছে:
- Zero-latency reads – PHP হট পাথ লোকাল মেমরি থেকে ডেটা পড়ে, তাই রিকোয়েস্টগুলো রিমোট স্টোরের জন্য অপেক্ষা করে আটকে থাকে না।
- Graceful degradation – যদি etcd ডাউন হয়ে যায়, রাউটারগুলো সর্বশেষ জানা সঠিক কনফিগারেশন ব্যবহার করে পরিষেবা প্রদান চালিয়ে যায়, যা হঠাৎ বিভ্রাট রোধ করে।
- Reliable updates – সাইডকার প্রসেসটি রিকানেকশন লজিক হ্যান্ডেল করে এবং নিশ্চিত করে যে etcd কানেকশন সাময়িকভাবে বিচ্ছিন্ন হলেও কোনো পরিবর্তন মিস হবে না।
বাস্তবে কী পরিবর্তন এসেছে
মাইগ্রেশনের পরে, টিম দেখতে পেল যে পুরনো বা ভুল রাউটিং ডেটার কারণে সৃষ্ট সমস্যার সংখ্যা নাটকীয়ভাবে কমে গেছে। এখন একটি মাত্র কনসোল থেকে বর্তমান কনফিগারেশন দেখা যায় এবং যেকোনো এডিট এক সেকেন্ডের মধ্যে আটটি অঞ্চলেই পৌঁছে যায়। সাময়িক বুস্টগুলো তাদের লিজ শেষ হওয়ার সাথে সাথে স্বয়ংক্রিয়ভাবে মুছে যায়, ফলে ম্যানুয়াল ক্লিন-আপের প্রয়োজন হয় না যা আগে মানুষের ভুলের কারণ হতো।
বিপরীত যুক্তি: সাইডকারের খরচ
একটি সাইডকার যোগ করার অর্থ হলো প্রতিটি সার্ভারে একটি দ্বিতীয় প্রসেস এবং একটি PHP-কেন্দ্রিক স্ট্যাকে একটি Go রানটাইম। কিছু অপারেটর অতিরিক্ত মেমরি ব্যবহার এবং আরেকটি বাইনারি মনিটর করার বিষয়ে চিন্তিত। বাস্তবে সাইডকারের মেমরি ব্যবহার খুবই সামান্য এবং এর ফলে প্রাপ্ত নির্ভরযোগ্যতা—বিশেষ করে এই নিশ্চয়তা যে PHP কখনোই নেটওয়ার্ক কলের জন্য ব্লক হবে না—অপারেশনাল ওভারহেডের চেয়ে অনেক বেশি মূল্যবান।
পরবর্তী করণীয়
যেসব টিম মাল্টি-রিজিয়ন সার্ভিস পরিচালনা করে তাদের নিচের বিষয়গুলো মনিটর করা উচিত:
- etcd health metrics – রাউটিং লেয়ার একটি একক স্টোরের ওপর নির্ভরশীল; তাই কোরাম স্ট্যাটাস এবং ল্যাটেন্সির দিকে নজর রাখুন।
- Lease expiration handling – লিজের সময়কাল ব্যবসায়িক প্রয়োজনের সাথে সামঞ্জস্যপূর্ণ রাখুন; অতিরিক্ত দীর্ঘ লিজ পুরনো বুস্টগুলোকে কার্যকর রেখে দিতে পারে।
- Scaling the watch load – রাউটার বাড়ার সাথে সাথে 'watch' কানেকশনও বাড়বে; সেই অনুযায়ী etcd সার্ভারের সক্ষমতা পরিকল্পনা করুন।
মূল কথা
যে কোনো সার্ভিসের জন্য যার অনেকগুলো অঞ্চলে দ্রুত এবং সমন্বিত কনফিগারেশন পরিবর্তনের প্রয়োজন, etcd-এর watch, lease, এবং transaction primitives ফাইল-ভিত্তিক কনফিগারেশন বা হেভিওয়েট মেশেসের একটি লাইটওয়েট এবং স্ট্রংলি কনসিস্টেন্ট বিকল্প হিসেবে কাজ করে। কনফিগারেশনকে একটি পুশ-চালিত (push-driven) এবং সেলফ-ক্লিনিং (self-cleaning) স্টোরে রূপান্তর করার ফলে এক ধরণের সম্পূর্ণ ইনসিডেন্ট বা সমস্যা দূর হয়েছে এবং প্ল্যাটফর্মটিকে তার রাউটিং লজিকের ওপর রিয়েল-টাইম নিয়ন্ত্রণ প্রদান করেছে।