আপনার build করা application-টি এতই viral হয়ে গেছে যে, এর user base lakh cross করে গেছে। এবং concurrent user লাখের কাছাকাছি। এই অবস্থায় আপনার যে server আছে, তা user-দের load নিতে পারছে না। Peak time-এ user-দের wait করতে হচ্ছে। Data inconsistency-র একটা issue দেখা দিচ্ছে। মাঝে মাঝে server crash করছে। মাঝে মাঝে database-এ data insert হচ্ছে না। অবস্থা একদম বেগতিক হয়ে গেছে।
এখন এর সমাধান হচ্ছে resource বাড়ানো। সহজ কথায় scale করা। আপনি ঠিক তাই করলেন, scale করে resource বাড়িয়ে দিলেন—user খুশি, আপনিও খুশি।
কিন্তু সমস্যা বাঁধল কিছুদিন পর। আপনার আগে যে concurrent user ছিল লাখের কাছাকাছি, সেটা 1 million ছাড়িয়ে গেল। আবার সেই আগের মতো situation তৈরি হলো। আপনি resource বাড়াতে গিয়ে দেখলেন যে, আপনার server-এর resource limit শেষ। মানে আর increase করতে পারবেন না।
এখন কী করবেন?
আসুন, এই বিষয়গুলো নিয়েই আলোচনা করি।
Vertical Scaling: A single big machine
Vertical scaling সহজভাবে বললে, আপনার machine থাকবে একটা। আমি শুধু এর CPU, memory, storage এগুলো increase করব। এই কাজটা কিন্তু already দুইবার করে ফেলেছেন। এটাই হলো vertical scaling।
For example:
- Core: আগে ২, এখন ৪
- Memory: আগে 8GB, এখন 16GB
- Storage: আগে 50GB, এখন 100GB
সুবিধা:
- Simple। Application-এ কোনো পরিবর্তন লাগে না।
- Database-এর জন্য অনেক সময় সহজতম সমাধান।
সমস্যা:
- একটা সীমা আছে। সবচেয়ে বড় server-ও finite। এই সম্মুখীন already হয়ে গেছেন।
- Single Point of Failure - এই একটা server dead হয়ে গেলে সব বন্ধ হয়ে যাবে।
- Downtime লাগতে পারে upgrade করতে।
Horizontal Scaling: Multiple Machine
Vertical scaling-এ একটা machine-এই শুধু resource increase করা হয়েছে। Horizontal scaling-এর ক্ষেত্রে এটা পুরোটাই উল্টো। এখানে resource increase করার বদলে নতুন machine introduce করা হয়। Theoretically, এই machine-এর সংখ্যা unlimited। মূলত user traffic-কে এই machine-গুলোতে distribute করে দেয়া হবে। এতে machine-এর ওপর load কমে গেলে ভালোভাবে perform করতে পারবে।
আপনি একটু চালাক আছেন, তাই আপনার মনে question জাগলো—যে ২-১টা machine-এর IP address তো আমি manually distribute করতেই পারি। কিন্তু machine বা server যদি ১০, ২০ বা তার অধিক হয়, তাহলে তো ঝামেলা বেধে যাবে!
এর solution হচ্ছে Load Balancer। Load Balancer-এর কাজ হচ্ছে user traffic-কে multiple server-এর ভেতর distribute করে দেয়া।
এখন আপনি নিশ্চিন্ত।
সুবিধা:
- Theoretically unlimited scaling।
- একটা server deah হলেও বাকিগুলো চলতে থাকে।
- Traffic বাড়লে server বাড়ানো জয়, কমলে server কমানোও যায়।
সমস্যা:
- Application-কে stateless হতে হবে।
Applicaiton with session based authentication is a Statefull apllication.
Stateless হওয়া কেন দরকার?
মনে করুন আপনার application authentication-এর জন্য session use করে।
আপনার system-এ ৩টি server আছে:
- Server A
- Server B
- Server C
এখন user login করার জন্য login route-এ hit করলো, এটা Load Balancer (LB)-এর কাছে আসলো, তারপর LB সেটাকে Server A-তে redirect করে দিলো। Server-এ session create হলো। এই পর্যন্ত ঠিকই আছে।
এরপর login করার পর user dashboard open করলো (dashboard public user-দের জন্য restricted), dashboard-এর জন্য server-এ request গেলো। প্রথমে LB-র কাছে, LB এবার request-টাকে Server B-তে redirect করলো। Server B দেখলো যে এখানে কোনো session-ই নাই। তারমানে এ public user, একে data দেয়া যাবে না। আপনার request reject করে দিলো এবং dashboard আর load হলো না।
এখন session-based authentication যদি খুব বেশি important হয়, তাহলে এর জন্য একটা solution আছে। Session store করার জন্য একটা আলাদা database use করতে হবে। এই database Redis হতে পারে।
Redis use করার সবচেয়ে বড় reason হচ্ছে এর TTL (Time To Live) based expiration। আপনার session তো একটা নির্দিষ্ট সময়ে গিয়ে expire হয়ে যাবে। Redis আপনাকে সেটা by default-ই দিয়ে দিবে, আপনাকে manually delete করতে হবে।
Database Scaling: আলাদা চিন্তা
আপনার সামনে নতুন একটা situation তৈরি হয়ে গেছে। ১০টা server তো add করে দিলেন, কিন্তু user-কে সেই wait করতেই হচ্ছে। আপনি একটু investigate করার পর বুঝতে পারলেন যে, এখন server problem না করলেও database problem করা শুরু করে দিয়েছে।
Server-এর load distribute হলেও, database-এর load কিন্তু সেই আগের মতোই আছে। এখন database-কেও scale করা লাগবে। তবে server-এর মতো database scaling এত easy না। একটু এদিক-সেদিক হলেই আপনার পুরো system-এ সমস্যা হতে পারে, user data গায়েব হয়ে যেতে পারে। Data inconsistency দেখা দিতে পারে। এছাড়াও আরও অনেক রকম problem আছে।
Database scaling-এর ক্ষেত্রে mainly vertical scaling যতটা possible করা হয়। তারপরেও যদি problem হয়, তাহলে-
- Vertical Scaling - একটাই big powerful server।
Read Replica - Read operations এর জন্য বাড়তি database server add করা।
Sharding - শুধু যখন সত্যিই দরকার। এটা নিয়ে পুরা একটা বই লিখে ফেলা যাবে।
তবে ক্ষেত্রবিশেষে caching করলেই database scaling করা লাগে না। For example, read-heavy application-এ database-এ load-ই আসবে না। Cache থেকেই সব data serve হয়ে যাবে।
Types of Scaling একসাথে
Load Shifting - Peak time-এর কাজ off-peak-এ করো। Batch jobs রাতে।
Auto Scaling - Traffic বাড়লে automatically নতুন instance, কমলে বন্ধ। AWS, GCP সব দেয়।
কোনটা করব?
| পরিস্থিতি | পদ্ধতি |
|---|---|
| Database bottleneck | Vertical scaling |
| Web server bottleneck | Horizontal scaling |
| Sudden traffic spike | Auto-scaling |
| Budget কম | Vertical দিয়ে শুরু |
| High availability দরকার | Horizontal |
বটম লাইন
শুরুতে Vertical scaling। সহজ, কোড পরিবর্তন লাগে না। তারপর stateless architecture বানান, তখন Horizontal scaling সহজ হয়ে যায়। Database আলাদাভাবে চিন্তা করুন।
আপনার system-এ এখন কোন scaling strategy? কমেন্টে শেয়ার করুন! 👇
Top comments (0)