How Booking.com cut Node.js costs by 38% with Watt

বড় স্কেলে Node.js অ্যাপ্লিকেশন রান করানো সবসময়ই চ্যালেঞ্জিং।

বিশেষ করে ট্রাফিক বাড়ার সাথে সাথে ইনফ্রাস্ট্রাকচার স্কেল করতে গিয়ে ক্লাউড সার্ভার বিল হু হু করে বাড়তে থাকে।

কিন্তু কেমন হতো যদি বলি, আপনার সার্ভিসের এক লাইন কোডও পরিবর্তন না করে আপনি আপনার Node.js costs বিশাল একটা অংকে কমিয়ে আনতে পারবেন?

ঠিক এমনটাই করে দেখিয়েছে বিশ্বের অন্যতম জনপ্রিয় ট্রাভেল প্লাটফর্ম Booking.com!

তারা সম্প্রতি তাদের মেইন Node.js রেন্ডারিং সার্ভিসে একটি বড়সড় পরিবর্তন এনেছে। pm2 থেকে Platformatic-এর Watt-এ মাইগ্রেট করার মাধ্যমে তারা তাদের Node.js costs ৩৮% কমিয়ে এনেছে।

এই আর্টিকেলে আমরা বিস্তারিত জানবো ঠিক কী কী আর্কিটেকচারাল ডিসিশন এবং টেকনিক্যাল কারণে এই অসাধারণ অপ্টিমাইজেশন সম্ভব হয়েছে।

What is Node.js and How Does It Work?

Node.js হলো একটি ওপেন-সোর্স, ক্রস-প্লাটফর্ম জাভাস্ক্রিপ্ট রানটাইম এনভায়রনমেন্ট (runtime environment), যা সার্ভার-সাইডে কোড রান করার জন্য ব্যবহৃত হয়। এটি গুগলের পাওয়ারফুল V8 জাভাস্ক্রিপ্ট ইঞ্জিনের ওপর ভিত্তি করে তৈরি।

How Node.js Works Behind the Scenes

Node.js মূলত Event-driven এবং Non-blocking I/O মডেলে কাজ করে।

সাধারণ সার্ভারগুলো যেখানে প্রতিটি রিকোয়েস্টের জন্য নতুন থ্রেড (thread) তৈরি করে মেমোরি জ্যাম করে ফেলে, সেখানে Node.js সিঙ্গেল-থ্রেডেড (single-threaded) ইভেন্ট লুপ (Event Loop) ব্যবহার করে অ্যাসিনক্রোনাস (asynchronous) কাজগুলো হ্যান্ডেল করে।

এর ফলে একই সাথে হাজার হাজার কনকারেন্ট (concurrent) রিকোয়েস্ট খুব ফাস্ট প্রসেস করা যায়।

তবে বড় স্কেলে যখন ট্রাফিক মিলিয়ন ছাড়িয়ে যায়, তখন এই আর্কিটেকচারকে ঠিকমতো অপ্টিমাইজ না করলে সার্ভার ওভারলোড হয়ে যায় এবং ফলশ্রুতিতে Node.js costs অনেক বেড়ে যায়।

What is Watt and How Does It Work?

Watt হলো Platformatic-এর তৈরি একটি লাইটওয়েট এবং হাই-পারফরম্যান্স প্রসেস ম্যানেজার (process manager) যা বিশেষভাবে Node.js অ্যাপ্লিকেশনের স্কেলিং এবং অপ্টিমাইজেশনের জন্য ডিজাইন করা হয়েছে।

The Core Mechanism of Watt

ট্রেডিশনাল প্রসেস ম্যানেজারগুলো প্রতিটি রিকোয়েস্টকে প্রথমে একটি মাস্টার প্রসেসের মাধ্যমে রিসিভ করে, তারপর সেটি ওয়ার্কারদের কাছে পাঠায়।

কিন্তু Watt এই এপ্রোচটি বদলে দিয়েছে। এটি ডিরেক্টলি Node.js-এর worker threads এবং লিনাক্স কার্নেলের SO_REUSEPORT ফিচার ব্যবহার করে।

এর ফলে ইনকামিং রিকোয়েস্টগুলো কোনো ইন্টারমিডিয়ারি বা মিডলম্যান ছাড়াই সরাসরি ওয়ার্কার থ্রেডে চলে যায়।

এই ডিরেক্ট কানেকশনের কারণে সিস্টেমের ওভারহেড (overhead) কমে যায়, মেমোরি বাঁচে এবং পারফরম্যান্স বুস্ট হওয়ার পাশাপাশি সার্ভারের Node.js costs উল্লেখযোগ্য হারে কমে আসে।

The Migration Game Changer: From pm2 to Watt

যারা Node.js নিয়ে কাজ করেন, তারা প্রোডাকশনে অ্যাপ্লিকেশন রান করানোর জন্য সাধারণত pm2 ব্যবহার করে থাকেন।

কিন্তু Matteo Collina (Platformatic-এর ফাউন্ডার) এর ভাষায় বলতে গেলে, “Friends don’t let friends use pm2.

Why pm2 Falls Short at Scale

সাধারণত pm2-এ প্রতিটা রিকোয়েস্ট একটা সুপারভাইজার বা IPC (Inter-Process Communication) এর মাধ্যমে পাস হয়।

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

The Power of SO_REUSEPORT

Booking.com তাদের ক্লাস্টার ম্যানেজমেন্টের জন্য pm2-এর cluster module ব্যবহার করা বাদ দিয়ে Watt-এর worker threads-এ শিফট করে।

Watt-এর ক্ষেত্রে প্রতিটা ওয়ার্কার সরাসরি কার্নেল (kernel) থেকে SO_REUSEPORT এর মাধ্যমে কানেকশন এক্সেপ্ট করে। এর মানে হলো রিকোয়েস্ট পাথে একটা ‘হপ’ (hop) পুরোপুরি কমে যাওয়া।

আন্ডার লোড সিচুয়েশনে এর বেনিফিট একেবারে পরিষ্কার মিক্সড-ওয়ার্কলোড টেস্টে দেখা গেছে, আগের চেয়ে ৪০-৫০% বেশি রিকোয়েস্ট হ্যান্ডেল করা যাচ্ছে, অথচ ল্যাটেন্সি SLO (Service Level Objective) একদম পারফেক্ট থাকছে।

The Mind-Blowing Stats: How Node.js Costs Dropped

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

মূলত অপ্টিমাইজড রিসোর্স অ্যালোকেশনের মাধ্যমেই তাদের Node.js costs উল্লেখযোগ্য হারে কমেছে।

নতুন কোনো হার্ডওয়্যার না কিনে এবং সার্ভিসের কোডে কোনো হাত না দিয়েই তারা যে রেজাল্ট পেয়েছে, তা দারুণ:

• Node.js costs কমেছে ৩৮%।
• আগের চেয়ে ৩০% কম pods ব্যবহার করতে হচ্ছে।
• প্রতিটি pod-এ মেমোরি ব্যবহার (memory usage) কমেছে ২০%।
• p75, p99, এবং p99.9 লেভেলে ল্যাটেন্সি কমেছে প্রায় ১০% পর্যন্ত।

Achieving More with Less Infrastructure

Watt-এ মাইগ্রেশনের পর তাদের আগের চেয়ে ৩০% কম pods ব্যবহার করতে হচ্ছে।

শুধু তাই নয়, প্রতিটি pod-এ মেমোরি ব্যবহার (memory usage) কমেছে ২০%।

কম রিসোর্স ব্যবহার করে সেম ট্রাফিক সার্ভ করার সরাসরি ইমপ্যাক্ট পড়েছে তাদের ক্লাউড কম্পিউট বিলের উপর।

Improved Latency Metrics

ল্যাটেন্সি হলো ইউজার এক্সপেরিয়েন্সের অন্যতম প্রধান মাপকাঠি।

Watt-এ মাইগ্রেট করার পর Booking.com-এর p75, p99, এবং p99.9 লেভেলে ল্যাটেন্সি কমেছে প্রায় ১০% পর্যন্ত। অর্থাৎ, ইউজাররা আগের চেয়ে ফাস্ট রেসপন্স পাচ্ছেন, যা একটা স্কেলড অ্যাপ্লিকেশনের জন্য অনেক বড় অ্যাচিভমেন্ট।

An Ingenious Approach to Load Balancing

SO_REUSEPORT ব্যবহারের একটা বড় চ্যালেঞ্জ হলো সঠিক লোড ডিস্ট্রিবিউশন।

যখন এটি ব্যবহার করা হয়, তখন সিস্টেম কানেকশনের আইপি এবং পোর্ট হ্যাশ করে ঠিক করে কোন ওয়ার্কার কাজটা করবে।

Solving the Loopback Hashing Issue

loopback কানেকশনের ক্ষেত্রে হ্যাশ সবসময় একই ওয়ার্কারে গিয়ে পড়ে।

এর ফলে ওয়ার্কারদের মধ্যে কাজের বৈষম্য বা আনইভেন ডিস্ট্রিবিউশন তৈরি হয় দেখা যায় কোনো থ্রেড ৪০% বেশি লোডেড হয়ে আছে, আবার কোনোটা অনেকটা ফ্রি বসে আছে।

Leveraging Nginx and The 4+1 Worker Strategy

এই প্রবলেম সলভ করতে Booking.com চমৎকার একটা ট্রিক অ্যাপ্লাই করে।

তারা সরাসরি কার্নেলের উপর নির্ভরশীল না হয়ে প্রতিটি ওয়ার্কারকে আলাদা আলাদা পোর্টে লিসেন করায় এবং সামনে থাকা Nginx-কে round robin মেথডে লোড ব্যালেন্সিং-এর দায়িত্ব দেয়।

এমনকি তাদের একটি স্পেসিফিক সার্ভিসের জন্য তারা ৪+১ (4+1) মডেলে রেন্ডার-ইন্টেনসিভ (ভারী) এবং লাইটওয়েট এন্ডপয়েন্টগুলোকে আলাদা ওয়ার্কারে ভাগ করে দেয়।

এরপর least_conn মেথড ব্যবহার করে টেল ল্যাটেন্সি (tail latency) আরো কয়েক পার্সেন্ট কমিয়ে আনে তারা।

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

Event Loop Monitoring and Auto-Restart

প্রোডাকশন এনভায়রনমেন্টে সার্ভার ডাউনটাইম এড়ানো অনেক বড় একটি চ্যালেঞ্জ।

Watt এখানে দারুণ একটি বিল্ট-ইন ফিচার প্রোভাইড করে যা সিস্টেমকে সবসময় সচল রাখে।

Self-Healing in Production

Watt-এর অটোমেটিক মনিটরিং সিস্টেম কন্টিনিউয়াসলি থ্রেডগুলো মনিটর করে।

Node.js-এর ইভেন্ট লুপ (Event Loop) যদি কোনো কারণে ব্লক হয়ে যায়, তবে Watt ম্যানুয়াল ড্যাশবোর্ড চেক করার সুযোগ না দিয়েই নিজে থেকেই সেই আনরেসপন্সিভ থ্রেড স্মুথলি রিস্টার্ট করে দেয়।

এই সেলফ-হিলিং প্রসেস প্রোডাকশন লেভেলে সিস্টেমকে অনেক বেশি রিলায়েবল করে তোলে।

A/B Testing and V8 Garbage Collection Tuning

যেকোনো বড় মাইগ্রেশন প্রোডাকশনে লাইভ করার আগে প্রপার টেস্টিং ভীষণ জরুরি। Booking.com এক্ষেত্রে চমৎকার ইঞ্জিনিয়ারিং স্ট্যান্ডার্ড এবং ডেটা-ড্রিভেন অ্যাপ্রোচ মেইনটেইন করেছে।

Transparent Migration Strategy

তারা এই পুরো মাইগ্রেশনটা একটি প্রপার A/B প্রোডাকশন ট্রায়াল হিসেবে রান করেছে। এ

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

Optimizing the V8 GC

Watt ব্যবহারের ফলে তাদের সিস্টেমে যে অতিরিক্ত মেমোরি এবং হেডরুম বেঁচে গিয়েছিল, তারা সেটাকে শুধুমাত্র ফেলে না রেখে V8 GC (Garbage Collection) টিউন করার কাজে লাগিয়েছে।

একটি মাইগ্রেশনকে ভ্যালিডেট করার জন্য এটি একটি অসাধারণ মেথড, যা তাদের ওভারঅল পারফরম্যান্স এবং Node.js costs অপ্টিমাইজেশনে বিশাল ভূমিকা রেখেছে।

Final Thoughts on Scaling Node.js Applications

সার্ভার স্কেলিং মানেই শুধু নতুন সার্ভার কেনা বা ক্লাউড বিল বাড়ানো নয়, বরং এক্সিস্টিং রিসোর্সের ম্যাক্সিমাম ইউটিলাইজেশন করা।

Platformatic-এর Watt ব্যবহার করে Booking.com প্রমাণ করে দিয়েছে যে, সঠিক আর্কিটেকচারাল ডিসিশন এবং স্মার্ট কনফিগারেশন ব্যবহার করলে অ্যাপ্লিকেশন কোডে হাত না দিয়েই বিশাল অংকের Node.js costs সেভ করা সম্ভব।

আধুনিক ক্লাউড-নেটিভ এনভায়রনমেন্টে পারফরম্যান্স অপ্টিমাইজেশনের ক্ষেত্রে এটি একটি দারুণ কেস স্টাডি!