এক সার্ভার থেকে অনেক সার্ভার

০০ যে প্রশ্নগুলোর উত্তর খুঁজবো

এই প্রশ্নগুলোর উত্তর জানার পর আপনি বুঝবেন web layer কীভাবে scale করে। scale করার পরেও আমাদের architecture এর কোন জায়গাটা এখনো ভাঙতে পারে, সেটাও বুঝবেন।

০১ Single server দিয়েই তো সবকিছু চলছে। তাহলে সমস্যা কোথায়?

একটা সহজ server setup:

কিন্তু user বেড়ে ১০,০০০ হলে তিনটা জিনিস ভেঙে পড়ে:

1. CPU আর memory শেষ: এক machine একসাথে ১০,০০০ request সামলাতে পারে না। System slow হয়ে যায়। Request time out করে।
2. পুরোটাই একটা Single Point of Failure: ওই এক machine crash করলে পুরো application down হয়ে যায়। Data হারিয়ে যায়।
3. দূরের user, latency বেশি: US এর user, Bangladesh এর server। একটা request কে অর্ধেক পৃথিবী ঘুরে আসতে হয়। ফলে latency অনেক বেশি হয়।

তাহলে আমাদের কিছু একটা করতে হবে।

০২ সবচেয়ে ছোট কোন পরিবর্তন থেকে শুরু করবো?

এখন code আর database একই machine এ আছে। তারা একই CPU আর memory এর জন্য লড়ছে।

সবচেয়ে ছোট পদক্ষেপ: app server আর database কে আলাদা machine এ সরিয়ে নিন।

এটা কেন ভালো? চারটা কারণ:

1. আলাদা কাজের জন্য আলাদা machine: Web Server এর CPU বেশি দরকার। Database এর দরকার memory আর fast disk। এক machine এ থাকলে তারা resource এর জন্য লড়ে। আলাদা করলে প্রতিটা server নিজের কাজের জন্য tuned থাকে।
2. আলাদা আলাদা scale করার স্বাধীনতা: ১০টা Web Server এর সাথে ১টা database, অথবা ২টা Web Server এর সাথে ৫টা database। প্রয়োজন অনুযায়ী scale করার স্বাধীনতা পাওয়া যায়। App আর Database একই server এ থাকলে scale করার সময় পুরো server টাকেই scale করতে হয়। হয়তো শুধু database এর load বেশি, কিন্তু তখন app server ও অকারণে scale হয়ে যায়। এটা টাকার অপচয়।
3. Isolation (আলাদা রাখা): Web Server এর কোনো bug Web Server কে crash করলেও Database এর উপর তার কোনো প্রভাব পড়ে না। উল্টোটাও সত্য: Database Server crash করলে Web Server অক্ষত থাকে।
4. সহজ maintenance: Web Server restart, upgrade বা fix করার সময় Database কে ছুঁতেই হয় না।

এটাকে বলে Separation of Concerns: আলাদা machine আলাদা কাজ করে, প্রত্যেকে নিজের কাজের জন্য optimized থাকে।

০৩ আলাদা তো করলাম। এখন কি system safe?

না।

এখানে একটা গুরুত্বপূর্ণ বিষয় বুঝতে হবে। Separation আমাদের যা দিয়েছে:

• Better performance
• Independent scaling
• Isolation

কিন্তু এটা এখনো SPOF সরায়নি। এখনো একটাই Web Server আর একটাই database। এদের যেকোনো একটা down হলে পুরো system down হয়ে যায়।

০৪ আরো web server যোগ করলে user কোনটার সাথে কথা বলবে?

এক Web Server ১০,০০০ user সামলাতে পারে না। তাই আরো server যোগ করি।

প্রশ্ন: এখন একাধিক web server যোগ করা হলো। user application খুললে তার request কোন Web Server এ যাবে, সেটা কে ঠিক করবে?

উত্তর হলো Load Balancer (LB)।

Load Balancer (LB) কী?

এটা অনেকটা restaurant এর host এর মতো, যে বলে “Table 1 খালি, ওটাতে বসুন। Table 2 ব্যস্ত, Table 3 তে যান।” Load balancer আসা request গুলোকে একাধিক server এর মধ্যে ভাগ করে দেয়, যাতে কোনো একটা server এর উপর বেশি চাপ না পড়ে।

Load Balancer যা দেয়:

• Web layer এর SPOF সরিয়ে দেয়: Web1 crash করলে LB traffic কে Web2 আর Web3 এ পাঠায়। User টের ও পায় না।
• Resource এর ভালো ব্যবহার: Traffic সব server এ ভাগ হয়ে যায়। ফলে প্রতিটা server এর resource সমানভাবে কাজে লাগে।
• Server যোগ বা সরানো সহজ: শুধু LB তে server register করালেই হয়। User সরাসরি server এ connect করে না, LB এর সাথে connect করে। তাই নতুন server যোগ বা সরানোর সময় শুধু LB কে জানালেই হয় যে “এই নতুন server টাও আছে”। User এর দিক থেকে কিছুই বদলায় না, পেছনে কী হচ্ছে সে জানেও না।

০৫ Load balancer কি নিজেই Single Point of Failure?

হ্যাঁ। এটা একটা গুরুত্বপূর্ণ ফাঁদ।

Load balancer crash করলে কোনো request কোনো Web Server এ পৌঁছায় না, এমনকি ১০০টা web server থাকলেও না। Load balancer হলো single entry point (সব traffic এই একটা জায়গা দিয়ে ঢোকে)। আর single entry point মানেই নিজে থেকেই SPOF।

Real system এ সমাধান: redundant Load Balancer

LB এর দুটো mode:

• Active-Passive: এক LB সব traffic handle করে, অন্যটা অপেক্ষা করে। প্রথমটা down হলে অন্যটা দায়িত্ব নিয়ে নেয়।
• Active-Active: দুটো LB একসাথে traffic handle করে, load ভাগ করে নেয়। কোনো কারণে একটা down হলে অন্যটা পুরো load সামলাতে থাকে।

০৬ একাধিক web server অ্যাড করলাম। এখন login ভাঙলো কেন?

প্রায় সব engineer ই এই সমস্যায় পড়ে। চলুন বোঝার চেষ্টা করি কী ভুল হচ্ছে।

একজন user login করল। তার login request গেল Web1 এ। Web1 তার নিজের memory তে session টা store করল: “User Roy logged in, session ID = abc123।”

Web1 এর memory: {Roy: logged in, session abc123}
Web2 এর memory: (empty - কিছুই জানে না)
Web3 এর memory: (empty - কিছুই জানে না)

User এর পরের request LB এর মধ্য দিয়ে যায়। LB এবার request পাঠায় Web2 তে (load balancing এর কারণে)। কিন্তু Web2 তো Roy কে চেনেই না। ফলে user নিজেকে logged out অবস্থায় দেখে!

এটাই stateful server এর সমস্যা।

Stateful বনাম Stateless concept

Scaling এর জন্য stateless কেন সেরা

• যেকোনো সময় server যোগ বা সরানো যায়, তাতে user এর session হারায় না।
• যেকোনো server যেকোনো request সামলাতে পারে।
• কোন user কোন server এ আছে, সেটা load balancer কে মনে রাখতে হয় না।

তাহলে প্রশ্ন হলো session data কোথায় রাখবো? সেটার জন্যই দরকার Shared Session Store।

Shared Session Store

এখন যেকোনো Web Server এই shared store চেক করে user কে verify করতে পারে। এই কারণেই stateless server গুলো একে অপরের জায়গায় বসানো যায় (interchangeable)। distributed system এ এটাই বড় শক্তি।

০৭ System এখন দেখতে কেমন? এখনো কি breaking point আছে?

Database SPOF হলো পরের চ্যালেঞ্জ। এটাই সেশন ০৩ এর আলোচনার বিষয়।

০৮ মগজে প্রেশার দিন

নিচের প্রশ্নগুলোর উত্তর আগে নিজে ভাবুন। তারপর দেখুন সবাই যেভাবে ভাবে, কেন সেটা ভুল, আর সঠিক চিন্তা কী।

০৯ যে টার্মগুলো শিখলাম

১০ সংক্ষিপ্ত সারমর্ম

১১ মনে রাখুন

• SPOF এর সম্পর্ক system down হওয়ার সাথে, capacity এর সাথে নয়। Load এ fail করা LB হলো overloaded। Crash করা LB হলো SPOF।
• Statelessness একটা বড় শক্তি। “Memory” টা shared store এ সরিয়ে দিন, তাতে server গুলো একে অপরের জায়গায় বসানো যায়।
• Separation specialization দেয়, redundancy দেয় না। Role আলাদা করলে performance বাড়ে, কিন্তু SPOF সরে না।
• প্রতিটা entry point এর backup লাগে। User আর system এর মাঝে backup ছাড়া এমন একটা জিনিস থাকলে শেষমেশ সেটাই system কে down করে।