Service Discovery - নাম জানলেই ঠিকানা মেলে

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

সেশন ১১ তে আমরা একটা বড় application কে কয়েকটা ছোট service এ ভাগ করেছি। এখন order service কে payment service এর কাছে request পাঠাতে হয়। কিন্তু পাঠাবে কোন ঠিকানায়? এক machine এর জগতে উত্তরটা সহজ ছিলো: ঠিকানা একবার লিখে রাখলেই হতো।

Cloud এ machine আসে আর যায়। আজ যে IP তে payment service আছে, এক ঘণ্টা পরে সেখানে হয়তো কিছুই নেই। এই সেশনে আমরা দেখবো, ঠিকানা প্রতিনিয়ত বদলালেও service গুলো কীভাবে একে অপরকে খুঁজে পায়।

০১ Config এ hard-coded IP রাখলে autoscaling আর restart এর পর কী ভাঙে?

রাত দুইটা সাত মিনিট। আরিফের ফোন বেজে উঠলো। আরিফ একটা অনলাইন shopping site এর DevOps engineer, আর আজ রাতে on call এ আছে। Alert বলছে, শেষ চার মিনিটে একটা order ও সফল হয়নি। অথচ আজ রাত বারোটা থেকে midnight sale চলছে, মিনিটে প্রায় ১,২০০টা order আসছে। চোখ কচলাতে কচলাতে আরিফ laptop খুললো। Dashboard এ payment service এর ৮টা instance সবুজ, সবগুলো চালু। তাহলে payment হচ্ছে না কেন?

আধা ঘণ্টা খোঁজার পর আরিফ order service এর config file টা খুললো। সেখানে payment service এর তিনটা IP লেখা আছে, মাস ছয়েক আগে কেউ হাতে লিখেছিলো:

# order-service/application.properties
payment.hosts=10.0.1.11:8080,10.0.1.12:8080,10.0.1.13:8080
payment.timeout=3s

# রাত ২:০৩ এর log
02:03:11 ERROR PaymentClient: connect timed out (10.0.1.12:8080)
02:03:11 ERROR PaymentClient: connect timed out (10.0.1.11:8080)
02:03:12 ERROR OrderController: payment failed, order #58213 cancelled
02:03:12 ERROR PaymentClient: connect timed out (10.0.1.13:8080)

রাত দুইটায় কী হয়েছিলো, এবার পরিষ্কার। পুরোনো তিনটা payment machine এর memory প্রায় শেষ হয়ে আসছিলো। Autoscaling group ওদের অসুস্থ ধরে বন্ধ করে দিলো। Sale এর ভিড় সামলাতে সে একসাথে ৮টা নতুন machine চালু করলো। নতুন machine গুলো নতুন IP পেলো। Order service এর config কেউ বদলায়নি:

প্রতিটা payment call ৩ সেকেন্ড অপেক্ষা করে timeout হলো, আর order টা বাতিল হলো। আরিফ রাত দুইটা একচল্লিশে config ঠিক করে order service restart করলো। ততক্ষণে ৩৮ মিনিট পার হয়ে গেছে। মিনিটে ১,২০০টা করে ধরলে প্রায় ৪৫ হাজার order বাতিল হয়েছে। গড়ে ১,২০০ টাকার order ধরলে ক্ষতি সাড়ে পাঁচ কোটি টাকার মতো।

IP কেন এত বদলায়

আগের দিনে একটা server বছরের পর বছর একই IP তে চলতো। এখন একটা instance এর IP অনেক কারণে বদলায়:

• Autoscaling: Traffic বাড়লে নতুন machine আসে, কমলে কিছু machine বন্ধ হয়। প্রতিটা নতুন machine নতুন IP পায়।
• Crash আর replacement: কোনো machine অসুস্থ হলে cloud সেটা বন্ধ করে নতুন একটা চালু করে। নতুনটার IP আলাদা।
• Deploy: নতুন version deploy করার সময় পুরোনো machine বা container সরিয়ে নতুনগুলো আনা হয়।
• Container restart: Docker বা Kubernetes এ একটা container restart হলেই সাধারণত নতুন IP পায়।

একটু হিসাব করে দেখুন। ধরুন আপনার company তে মোট ৪০০টা instance চলে, আর প্রতিটা গড়ে এক দিন টেকে। তাহলে দিনে প্রায় ৪০০ বার কোনো না কোনো IP বদলায়, মানে গড়ে প্রতি চার মিনিটে একবার। এত ঘন ঘন বদলানো ঠিকানা কোনো মানুষ হাতে config এ লিখে রাখতে পারবে না।

০২ IP মুখস্থ না রেখে নাম দিয়ে খুঁজলে কেমন হয়?

হাসপাতালের reception desk

বড় একটা হাসপাতালের কথা ভাবুন। ডাক্তার রহমান সোমবার বসেন ৩০৪ নম্বর রুমে, বুধবার ৫১২ নম্বরে। ছুটিতে থাকলে তাঁর জায়গায় অন্য কেউ বসেন। রোগীরা কিন্তু রুম নম্বর মুখস্থ রাখেন না। তাঁরা reception desk এ গিয়ে জিজ্ঞেস করেন, “ডাক্তার রহমান আজ কোথায় বসেছেন?” Reception এর খাতায় সবসময় আজকের হিসাব থাকে, কারণ ডাক্তাররা এসেই সেখানে নিজের রুম নম্বর জানিয়ে যান।

Service এর জগতে এই reception desk এর নাম service registry। এটা একটা ছোট database, যেখানে লেখা থাকে কোন service এর কোন কোন instance এখন কোন IP আর port এ চালু আছে।

পুরো কাজটা চার ধাপে হয়। প্রতিটা payment instance চালু হয়েই registry তে নিজের নাম আর ঠিকানা লিখে দেয়। Order service এর payment দরকার হলে সে registry কে নাম দিয়ে জিজ্ঞেস করে। Registry তখন চালু থাকা instance গুলোর list ফেরত দেয়। শেষে order service সেই list থেকে একটা বেছে নিয়ে সরাসরি call করে।

খেয়াল করুন, registry শুধু ঠিকানা বলে দেয়। আসল payment request টা registry এর ভেতর দিয়ে যায় না। আর order service প্রতিটা request এর আগে registry কে জিজ্ঞেস ও করে না। সে list টা কিছুক্ষণ নিজের কাছে রেখে দেয়, তারপর মাঝে মাঝে নতুন করে আনে। এই ছোট্ট সিদ্ধান্তটা সেশনের শেষে খুব কাজে লাগবে।

০৩ Registry তে নাম ওঠে আর নামে কীভাবে?

Registry এর list ঠিক থাকলে তবেই পুরো ব্যবস্থাটা কাজ করে। তাই দুটো মুহূর্ত খুব জরুরি: instance চালু হওয়ার মুহূর্ত, আর বন্ধ হওয়ার মুহূর্ত।

নাম তোলা: registration

Instance চালু হয়ে নিজেই registry কে জানায়: “আমি payment, আমার ঠিকানা 10.0.2.23:8080।” এই কাজের নাম registration। Instance নিজের নাম নিজে তোলে বলে এই পদ্ধতিকে বলে self-registration। Netflix এর Eureka আর HashiCorp এর Consul এ এটাই প্রচলিত পদ্ধতি।

একটা জিনিস মনে রাখবেন: register করতে হয় instance পুরোপুরি ready হওয়ার পরে। Database connection তৈরি হয়নি, অথচ নাম উঠে গেছে, এমন হলে প্রথম কয়েক সেকেন্ডের request গুলো fail করবে।

আরেকটা পদ্ধতিও আছে। সেখানে instance নিজে কিছু বলে না। আলাদা একটা component সব machine এর উপর নজর রাখে, আর নতুন instance দেখলে তার হয়ে registry তে নাম তুলে দেয়। এর নাম third-party registration। সেশনের ০৭ নম্বর অংশে দেখবো, Kubernetes ঠিক এই কাজটাই করে।

নাম নামানো: deregistration

Instance বন্ধ হওয়ার আগে registry থেকে নিজের নাম সরিয়ে নেয়। এর নাম deregistration। স্বাভাবিকভাবে বন্ধ হওয়ার (graceful shutdown) সময় ভালো instance এই ক্রমে কাজ করে:

1. নাম সরায়: Registry কে বলে, “আমাকে list থেকে বাদ দিন।”
2. কয়েক সেকেন্ড অপেক্ষা করে: Caller দের cache এ পুরোনো list থাকতে পারে, তাই তাদের নতুন list আনার সময় দেয়।
3. হাতের কাজ শেষ করে: যে request গুলো এর মধ্যেই এসে গেছে, সেগুলোর উত্তর দেয়।
4. তারপর বন্ধ হয়।

কিন্তু crash এর সময় এসবের সুযোগ থাকে না। Power চলে গেলে বা process হঠাৎ থেমে গেলে instance কাউকে কিছু বলে যেতে পারে না। Registry এর খাতায় তখনো তার নাম লেখা থাকে। এই ফাঁকটা ধরার জন্যই দরকার health check।

০৪ Registry কীভাবে বোঝে কোন instance সত্যিই চালু আছে?

Registry একটা instance এর খবর দুইভাবে নিতে পারে। দুটো পদ্ধতিকে একসাথে বলে health check।

Heartbeat এর ধারণাটা আপনি সেশন ০২ এ দেখেছেন, যেখানে দুটো load balancer একে অপরের খবর রাখতো। এখানেও একই কৌশল। প্রতিটা registration এর সাথে একটা মেয়াদ থাকে, যাকে বলে TTL (সেশন ০৪ এর cache এর TTL এর মতোই)। প্রতিটা heartbeat মেয়াদটা আবার নতুন করে শুরু করে দেয়। মেয়াদ শেষ হওয়ার আগে heartbeat না এলে registry instance টাকে list থেকে বাদ দেয়।

উদাহরণ: Payment 3 এর crash

আরিফের নতুন setup এ heartbeat যায় প্রতি ১০ সেকেন্ডে, আর TTL ৩০ সেকেন্ড। Payment 3 এর শেষ heartbeat এসেছিলো t=20s এ। তারপর t=25s এ machine টা crash করলো:

Registry জানেই না যে crash হয়েছে। সে শুধু জানে, t=20s এর পর আর কোনো heartbeat আসেনি। তাই সে t=50s পর্যন্ত অপেক্ষা করে। মাঝের ২৫ সেকেন্ড registry একটা dead IP কে জীবিত বলে দেখায়। এই সময়টাকে বলে stale window, আর list এর ঐ ভুল লাইনটাকে বলে stale entry।

এই ২৫ সেকেন্ডে কতগুলো request বিপদে পড়ে, হিসাব করে দেখা যাক:

traffic        : 1,200 order/min = 20 request/s
instance       : 8টা, round robin, প্রতিটা পায় 20 ÷ 8 = 2.5 request/s
stale window   : 25s (crash থেকে registry থেকে বাদ পড়া পর্যন্ত)

dead IP তে যাওয়া request = 2.5 × 25 ≈ 62টা

retry নেই            : 62টা payment fail
অন্য instance এ retry : 0টা fail, শুধু ওই 62 জন ~1s বেশি অপেক্ষা করে
                       (connect timeout 1s ধরে)

Interval ছোট করলেই কি সমাধান?

Heartbeat প্রতি সেকেন্ডে পাঠালে stale window ছোট হয়, কিন্তু দুটো নতুন সমস্যা আসে। প্রথমত, ৪০০টা instance প্রতি সেকেন্ডে heartbeat পাঠালে registry কে সেকেন্ডে ৪০০টা request সামলাতে হয়। দ্বিতীয়ত, network এ এক সেকেন্ডের ছোট একটা ঝাঁকুনিতেই সুস্থ instance বাদ পড়ে যায়। তাই বেশিরভাগ team কয়েক সেকেন্ডের interval রাখে, আর stale window এর বাকি ঝুঁকিটা retry দিয়ে সামলায়।

০৫ Instance বাছাই করবে কে: caller নিজে, নাকি load balancer?

Registry এর কাছে ৮টা payment instance এর list আছে। কিন্তু কোন request কোন instance এ যাবে, সেই সিদ্ধান্তটা কেউ একজনকে নিতে হবে। এখানে দুটো পথ আছে:

Client-side discovery

এই পদ্ধতিতে caller নিজেই সব করে। Order service এর ভেতরে একটা ছোট library থাকে। Library টা registry থেকে list আনে, cache করে রাখে, আর প্রতিটা request এর জন্য একটা instance বেছে নেয় (যেমন round robin এ, মানে পালা করে একটার পর একটা)। এর নাম client-side discovery। Netflix অনেক বছর Eureka আর Ribbon library দিয়ে এভাবেই চালিয়েছে।

Server-side discovery

এই পদ্ধতিতে caller শুধু একটা ঠিকানা চেনে: একটা load balancer এর। সেশন ০২ এর load balancer এর কথা মনে করুন, যে request গুলো কয়েকটা server এর মধ্যে ভাগ করে দিতো। এখানে load balancer নিজে registry দেখে জানে কোন কোন instance চালু আছে, আর সে-ই একটা বেছে নেয়। এর নাম server-side discovery। AWS এর load balancer (ALB) আর Kubernetes Service এভাবে কাজ করে।

০৬ DNS দিয়েই discovery করলে সমস্যা কোথায়?

একটা প্রশ্ন মাথায় আসা স্বাভাবিক। নাম থেকে ঠিকানা বের করার জন্য তো আগে থেকেই একটা system আছে: DNS। সেশন ০৬ এ দেখেছি, DNS হলো ইন্টারনেটের phonebook, নাম দিলে IP ফেরত দেয়। তাহলে payment.internal নামে একটা DNS record বানিয়ে তাতে সব instance এর IP রাখলেই তো হয়?

এটা সত্যিই করা যায়, আর একে বলে DNS-based discovery। Consul এর মতো registry গুলো নিজেই একটা DNS interface দেয়, যাতে payment.service.consul নামে খুঁজলে চালু instance গুলোর IP পাওয়া যায়। সমস্যাটা অন্য জায়গায়: DNS এর উত্তর cache হয়।

প্রতিটা DNS উত্তরের সাথে একটা TTL থাকে। TTL শেষ না হওয়া পর্যন্ত caller আর DNS কে জিজ্ঞেস করে না, নিজের cache থেকেই IP নেয়। ধরুন TTL ৬০ সেকেন্ড:

DNS server নিজে মাত্র ৫ সেকেন্ডে ঠিক হয়ে গেছে। তবু order service আরো ৪০ সেকেন্ড dead IP তে request পাঠিয়েছে, কারণ উত্তরটা তার cache এ আটকে ছিলো। তার উপর আরো কয়েকটা সমস্যা আছে:

• সবাই TTL মানে না: কিছু language runtime আর library DNS এর উত্তর নিজের মতো করে আরো বেশি সময় cache করে। পুরোনো কিছু Java setting এ তো উত্তর চিরদিনের জন্য cache হয়ে যেতো।
• পুরোনো connection থেকে যায়: Caller একবার connection খুলে সেটা অনেকক্ষণ ধরে বারবার ব্যবহার করে (connection pool)। DNS বদলালেও খোলা connection পুরোনো IP তেই থেকে যায়।
• TTL খুব ছোট করলে DNS এর উপর চাপ বাড়ে: TTL ১ সেকেন্ড করলে প্রতিটা caller প্রতি সেকেন্ডে DNS কে জিজ্ঞেস করে।
• DNS কিছু জানায় না: DNS শুধু IP এর list দেয়। কোন instance ব্যস্ত, কোনটা অন্য data center এ, সেসব কিছুই বলে না।

০৭ Kubernetes এই কাজটা কীভাবে করে?

আজ অনেক company তার service গুলো Kubernetes এ চালায়। Kubernetes এ প্রতিটা চালু instance কে বলে pod। Pod খুব ঘন ঘন বদলায়: restart হয়, অন্য machine এ সরে যায়, আর প্রতিবার নতুন IP পায়। তাই Kubernetes এর ভেতরেই service discovery তৈরি করা আছে। এর নাম Kubernetes Service।

একটা Kubernetes Service এর একটা নাম থাকে (payment) আর একটা স্থির IP থাকে, যাকে বলে ClusterIP। এই IP টা Service যতদিন আছে ততদিন বদলায় না। Order pod শুধু http://payment:8080 এ call করে। এর পেছনের কাজ Kubernetes নিজেই করে:

• Kubernetes দেখে কোন pod গুলোর গায়ে app: payment label লাগানো আছে।
• প্রতিটা pod এর একটা readiness probe থাকে, মানে Kubernetes নিয়মিত দেখে নেয়, pod টা request নিতে প্রস্তুত কিনা। যে pod প্রস্তুত, শুধু তার IP list এ ওঠে।
• Service এর ClusterIP এ আসা request Kubernetes ঐ list এর একটা pod এ পাঠিয়ে দেয়।

Service বানানোর জন্য শুধু এটুকু লিখতে হয়:

apiVersion: v1
kind: Service
metadata:
  name: payment            # এই নামটাই order service ব্যবহার করবে
spec:
  selector:
    app: payment           # এই label যে pod গুলোর আছে, তারাই এর পেছনে থাকবে
  ports:
    - port: 8080           # Service এর port
      targetPort: 8080     # pod এর ভেতরের port

# order service এর config এ এখন IP নেই, শুধু নাম:
payment.url=http://payment:8080

খেয়াল করুন, Kubernetes এখানে আগের দুটো ধারণাই একসাথে ব্যবহার করছে। Pod নিজে register করে না; Kubernetes তার হয়ে list বানায়, তাই এটা third-party registration। আর order pod নিজে instance বাছে না; Service এর পেছনের ব্যবস্থা বাছে, তাই এটা server-side discovery। নাম থেকে ClusterIP বের করতে Kubernetes DNS ও ব্যবহার করে। কিন্তু ClusterIP কখনো বদলায় না বলে DNS এর TTL সমস্যা এখানে আর ঝামেলা করে না।

০৮ Registry তে stale entry থাকলে, বা registry নিজেই down হলে কী হয়?

Stale entry দুই রকমের

Registry এর list দুই দিক থেকে ভুল হতে পারে।

• Dead instance list এ রয়ে গেছে: ০৪ নম্বর অংশের stale window এর ঘটনা। এর সমাধান caller এর হাতে। প্রতিটা call এ ছোট timeout রাখুন, আর fail করলে list এর অন্য instance এ আবার চেষ্টা করুন। কোন instance বারবার fail করছে, সেটা caller নিজেও মনে রাখতে পারে আর কিছুক্ষণ তাকে এড়িয়ে চলতে পারে। Retry আর এর ঝুঁকিগুলো নিয়ে বিস্তারিত সেশন ২১ এ।
• সুস্থ instance list থেকে বাদ পড়েছে: Registry আর instance এর মাঝের network এ সমস্যা হলে instance ঠিকঠাক চললেও heartbeat পৌঁছায় না। Registry ভাবে সবাই down, আর একসাথে অনেক instance বাদ দিয়ে দেয়। Eureka তে এর জন্য একটা নিয়ম আছে: অল্প সময়ে অনেক বেশি heartbeat হারালে সে ধরে নেয় সমস্যাটা network এর, আর তখন কাউকে বাদ দেওয়া বন্ধ রাখে। এর নাম self-preservation mode। এর পেছনের যুক্তি সহজ: একটা পুরোনো list প্রায় খালি list এর চেয়ে অনেক ভালো।

Registry নিজেই down হলে

এবার সবচেয়ে ভয়ের প্রশ্ন। সব service ই registry এর উপর নির্ভর করে। Registry এর একটা মাত্র machine থাকলে সেটাই হয়ে যায় পুরো system এর SPOF (single point of failure, সেশন ০১)। তাই registry দুইভাবে নিজেকে রক্ষা করে:

প্রথম রক্ষা, cluster: Registry তিন বা পাঁচটা node এ চলে, আর প্রতিটা node এ একই data এর copy থাকে। বেশিরভাগ node চালু থাকলেই registry কাজ করে। তিনটার মধ্যে একটা down হলে কেউ টেরও পায় না। Node গুলো কীভাবে একমত হয় কোন list টা সঠিক, সেই কৌশলের নাম consensus। Consul আর etcd দুটোই Raft নামের consensus algorithm ব্যবহার করে। এর ভেতরের কথা সেশন ১৬ তে।

দ্বিতীয় রক্ষা, caller এর cache: ০২ নম্বর অংশে দেখেছি, order service প্রতিটা request এ registry কে জিজ্ঞেস করে না। সে শেষ জানা list নিজের কাছে রাখে, আর প্রতি ৩০ সেকেন্ডে নতুন করে আনে। তাই পুরো registry cluster down হলেও payment call থামে না। শুধু এই সময়ে নতুন instance এর খবর আসে না, আর কোনো instance crash করলে সেটা list এ রয়ে যায়। কাজ চলতে থাকে, যদিও একটু অন্ধভাবে।

আরিফের পরের sale

তিন সপ্তাহ পরে আবার midnight sale। এর মধ্যে আরিফের team order service এর config থেকে সব IP মুছে দিয়েছে। Payment instance গুলো এখন চালু হয়েই Consul এ register করে, প্রতি ১০ সেকেন্ডে heartbeat পাঠায়। Order service শুধু “payment” নামটা চেনে, আর fail হলে অন্য instance এ একবার retry করে।

রাত দুইটা দশে autoscaling আবার কয়েকটা পুরোনো machine বদলে দিলো, আর ৬টা নতুন machine যোগ করলো। নতুন machine গুলো ১৫ সেকেন্ডের মধ্যে traffic পেতে শুরু করলো। একটা order ও বাতিল হলো না। আরিফের ফোন সেই রাতে একবারও বাজেনি। সে ঘুমিয়ে ছিলো।

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

আগে নিজে ভাবুন। তারপর দেখুন: সবাই যেভাবে ভাবে, কেন সেটা অসম্পূর্ণ, আর আসল কথাটা কোথায়।

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

১১ শর্ট সামারি

১২ মনে রাখুন

• Config এ IP নয়, নাম লিখুন: IP বদলায়, নাম বদলায় না। এখনকার ঠিকানা বলার দায়িত্ব registry এর।
• Ready হওয়ার পরে register, বন্ধ হওয়ার আগে deregister: নাম সরিয়ে, একটু অপেক্ষা করে, হাতের কাজ শেষ করে তবেই বন্ধ হন।
• Stale window কখনো শূন্য হয় না: Crash থেকে বাদ পড়া পর্যন্ত কয়েক সেকেন্ড ভুল IP যাবেই, তাই ছোট timeout আর অন্য instance এ retry রাখুন।
• Health check দেখবে instance কাজ নিতে প্রস্তুত কিনা: শুধু process চালু থাকাই যথেষ্ট নয়।
• DNS এর TTL একটা অনুরোধ, আদেশ নয়: দ্রুত বদলানো ঠিকানার জন্য শুধু DNS এর উপর ভরসা করবেন না।
• Registry কে request এর পথে রাখবেন না: Caller শেষ জানা list cache করলে registry down হলেও কাজ চলে।
• Registry নিজেও redundant হতে হবে: তিন বা পাঁচ node এর cluster, যেখানে বেশিরভাগ একমত হলে তবেই list বদলায়।