একটা সার্ভারের দুটো সমস্যা, balancer-এর পরিবার আর কোনটা বাছবে, target group ও health check, scaling group-এর তিনটে সংখ্যা, zone জুড়ে ছড়ানো, grace period, খরচের সত্যিটা, আর একটা chaos পরীক্ষা — সার্ভার মেরে দেখা সেটা নিজে ফিরে আসে কি না।
পর্ব ২০-এর stack-টা কাজ করে। কিন্তু ওটায় একটাই সার্ভার, আর সেটা দুটো আলাদা সমস্যা — আর দুটোর সমাধান দুটো আলাদা জিনিস, যেটা মানুষ প্রায়ই গুলিয়ে ফেলে।
সমস্যা ১ — ওটা মরে গেলে সব শেষ।
সার্ভারটা মরতে পারে অনেকভাবে: হোস্ট মেশিনের হার্ডওয়্যার ব্যর্থতা, একটা kernel panic, একটা ভরে যাওয়া ডিস্ক, একটা অ্যাপ্লিকেশন যেটা মেমরি শেষ করে ফেলেছে। আর তখন সাইটটা বন্ধ, যতক্ষণ না কেউ টের পায় আর কিছু করে।
"কেউ টের পায়" — এটাই আসল খরচ। রাত তিনটেয় সেটা বিশ মিনিট হতে পারে, বা সকাল পর্যন্ত।
সমস্যা ২ — ট্র্যাফিক বাড়লে ওটা কিছু করতে পারে না।
একটা t3.micro একটা সীমা পর্যন্ত সামলাতে পারে। তার বেশি হলে তিনটে জিনিস হয়: অনুরোধ ধীর হয়, তারপর সারিতে জমে, তারপর ব্যর্থ হয়। আর পর্ব ৫-এর সেই burstable credit-এর সমস্যাটাও এখানে — ধীরে ধীরে খারাপ হতে থাকে, আর কারণটা স্পষ্ট নয়।
এখন গুরুত্বপূর্ণ অংশটা: দুটো সমস্যার দুটো আলাদা নাম আছে, আর সেগুলো আলাদা রাখা দরকার:
আর এই দুটো আলাদা, যদিও সমাধানের সরঞ্জাম একই। দুটো t3.micro একটা m5.large-এর চেয়ে কম শক্তিশালী হতে পারে — কিন্তু দুটো t3.micro উপলব্ধ, আর একটা m5.large নয়।
আর দুটো সমাধানের জন্য তিনটে জিনিস দরকার, আর সেগুলোর ক্রমটাই এই পর্বের গঠন:
১. একাধিক সার্ভার — পর্ব ৮-এর launch template থেকে। সেটা আমাদের আছে।
২. একটা ঠিকানা, তাদের সামনে — কারণ পর্ব ৮-এ তিনটে সার্ভার বানানোর পরে প্রশ্নটা উঠেছিল: ব্যবহারকারীকে কোন ঠিকানাটা দেবে? ওটার উত্তর load balancer।
৩. কেউ যে সংখ্যাটা দেখে — কারণ একটা সার্ভার মরলে কে নতুন বানাবে? ওটার উত্তর auto scaling group।
আর এই তিনটে মিলে যা দাঁড়ায়, সেটা একটা মানসিক পরিবর্তন, আর এটা পর্ব ৭-এর "cattle, not pets" ধারণাটার পরিণতি:
তুমি আর সার্ভার পরিচালনা করো না। তুমি একটা সংখ্যা পরিচালনা করো।
"আমার তিনটে সার্ভার দরকার" — আর কোন তিনটে, কোথায়, কখন তৈরি হলো, সেটা তোমার সমস্যা নয়। আর সেটাই পর্ব ৫ থেকে ২১ পর্যন্ত পুরো পথটার গন্তব্য।
AWS-এ তিন ধরনের load balancer আছে, আর নাম দেখে পার্থক্য বোঝা যায় না। কিন্তু বাছার নিয়মটা সরল, আর সেটা একটা প্রশ্নে:
Balancer-টাকে কি অনুরোধের ভেতরে দেখতে হবে?
ALB-ই ৯০% ক্ষেত্রের উত্তর, আর কারণটা ওই দ্বিতীয় সারি: সে HTTP বোঝে, আর তাই এমন কিছু করতে পারে যা একটা স্তর-৪ balancer পারে না:
• /api/* এক দলের সার্ভারে, বাকি সব অন্য দলে — একটা balancer, দুটো সেবা
• TLS এখানে শেষ করা, যাতে সার্ভারগুলোতে সার্টিফিকেট রাখতে না হয়
• একটা health check যেটা একটা নির্দিষ্ট path দেখে — আর এটাই পরের সেকশনের বিষয়
NLB কখন সত্যিই দরকার: যখন প্রোটোকলটা HTTP নয় (একটা গেম সার্ভার, একটা MQTT broker), বা যখন একটা স্থির IP ঠিকানা দরকার — কারণ ALB-র শুধু একটা DNS নাম থাকে, আর তার পেছনের ঠিকানাগুলো বদলায়।
আর ওই শেষ কথাটা আলাদা করে বোঝা দরকার, কারণ এটা একটা ব্যবহারিক ফাঁদ:
একটা ALB-র ঠিকানা একটা DNS নাম, একটা IP নয়। আর ওই নামের পেছনের IP-গুলো AWS যেকোনো সময় বদলাতে পারে।
তাই কখনো একটা ALB-র IP ঠিকানা কোথাও লিখে রাখবে না — কোনো firewall নিয়মে নয়, কোনো কনফিগে নয়। সবসময় DNS নামটা ব্যবহার করো।
আর যদি কারো কাছে একটা স্থির IP দরকার হয় (কিছু প্রতিষ্ঠানের firewall নিয়ম এটা চায়), তাহলে উত্তর একটা NLB — ওটার প্রতি zone-এ একটা স্থির IP থাকতে পারে।
এখন balancer-এর আসল মূল্যটা, আর এটা শুধু "ট্র্যাফিক ভাগ করা" নয়:
আর প্রথম সারিটাই সবচেয়ে কম প্রশংসিত, কারণ এটাই বাকি সব কিছু সম্ভব করে। পর্ব ৮-এ তিনটে সার্ভার বানিয়ে তিনটে ঠিকানা পেয়েছিলাম, আর সেটা একটা অচল পরিস্থিতি। একটা balancer ওই decoupling-টা দেয় — আর তার পরেই সার্ভারগুলো প্রতিস্থাপনযোগ্য হয়।
একটা balancer নিজে থেকে কিছু জানে না — সে একটা target group-এর দিকে তাকায়, আর সেই group-টাই জানে কোন সার্ভারগুলো আছে আর তারা সুস্থ কি না।
তিনটে জিনিস তৈরি করতে হয়, আর ক্রমটা এরকম:
aws elbv2 create-target-group --name devops-lab-tg --port 80 aws elbv2 create-load-balancer --name devops-lab-alb aws elbv2 create-listener # ← দুটোকে জোড়ে
তৃতীয়টা সহজে ভুলে যাওয়া যায়, আর ওটা ছাড়া balancer আর target group দুটো আলাদা জিনিস হয়ে বসে থাকে। একটা listener হলো নিয়ম: "balancer-এর ৮০ পোর্টে যা আসে, ওই target group-এ পাঠাও।"
এখন target group-এর সবচেয়ে বিভ্রান্তিকর অংশ — পোর্টটা।
--port 80 লেখার মানে কী? এটা instance-গুলোর পোর্ট, ক্লায়েন্টের পোর্ট নয়।
আর দুটো সম্পূর্ণ আলাদা:
১৮২টি অংশের ৩৭টি দেখানো হয়েছে, ১৪৫টি বাকি