Health Check আর DNS Failover

এই লেসন শেষে তুমি পারবে

• বুঝিয়ে বলতে, সাধারণ DNS কেন মরা server-এর দিকেই user পাঠাতে থাকে, আর Route 53 health check কীভাবে DNS-কে নিজে থেকে failover করতে শেখায়।
• Health check-এর তিনটা ধরন (endpoint, calculated, CloudWatch alarm) চিনতে, আর পরীক্ষার scenario দেখে ঠিকটা বেছে নিতে।
• Endpoint check কীভাবে চলে তা বলতে: কয়েকটা Region-এ প্রায় ১৫টা checker, ৩০ s বা ১০ s interval, failure threshold, ১৮%-এর নিয়ম, 2xx/3xx, প্রথম ৫,১২০ byte-এ string matching, আর checker-দের যে IP range তোমার firewall-এ খুলে দিতে হয়।
• AND, OR আর “M-এর মধ্যে অন্তত N” দিয়ে calculated health check বানাতে, আর maintenance-এর কাজে লাগাতে।
• Private resource (private EC2, RDS, DynamoDB, SQS, on-premises) monitor করতে একটা CloudWatch alarm আর সেই alarm-এর ওপর health check দিয়ে।
• আগেই বলে দিতে, record healthy, unhealthy, check ছাড়া, বা সবগুলো unhealthy হলে Route 53 কী উত্তর দেয়, আর Alias record-এ Evaluate Target Health কীভাবে কাজ করে।
• Interval, threshold আর TTL থেকে DNS failover-এর সময় হিসাব করতে, আর কখন Application Recovery Controller বেশি ভালো, তা জানতে।

#DNS-এর কেন health check লাগে

একটা IP address-এর পেছনের server বেঁচে আছে কি না, DNS server তা জানে না। ধরো www.example.com দেখাচ্ছে 198.51.100.10-এর দিকে, আর সেই server crash করল। কেউ হাতে record বদলে না দেওয়া পর্যন্ত সাধারণ DNS 198.51.100.10-ই বিলিয়ে যাবে। রাত তিনটায় user-রা timeout পাচ্ছে, অথচ record দেখতে একদম ঠিকঠাক। (Resolver, caching আর TTL সাধারণভাবে কীভাবে কাজ করে, তা দেখো System Design-এর DNS লেসনে।)

Route 53 health check হলো ছোট্ট একটা পাহারাদার, যেটা Route 53 তোমার হয়ে চালায়। সে কোনো একটা জিনিস (একটা web server, আরেকটা health check, বা একটা CloudWatch alarm) বারবার পরীক্ষা করে, আর একটা status ধরে রাখে: healthy নয়তো unhealthy। এরপর তুমি health check-টা DNS record-এর সাথে জুড়ে দাও। Status unhealthy হলেই Route 53 ওই record দিয়ে উত্তর দেওয়া বন্ধ করে, একটা healthy record দিয়ে উত্তর দেয়। এটাই automated DNS failover: outage চলার সময় কাউকে হাতে record বদলাতে হয় না।

চেনা ছবিটা এরকম: us-east-1-এ একটা Application Load Balancer আর একটা Auto Scaling group, eu-west-1-এ হুবহু একই stack, প্রতিটার জন্য একটা health check, আর record (latency, failover, weighted, geoproximity…) যেগুলো ওই health check ব্যবহার করে। এক Region-এর stack উত্তর দেওয়া বন্ধ করলে Route 53 সবাইকে অন্যটায় পাঠিয়ে দেয়।

#Health check-এর তিন ধরন

Route 53-এ health check ঠিক তিন রকমের। পরীক্ষায় প্রায়ই চতুর্থ একটা ধরন দেখানো হয়, যেটার অস্তিত্বই নেই।

CloudWatch হলো AWS-এর metric আর alarm-এর service; পরে এর আলাদা chapter আছে। আপাতত এটুকু জানলেই চলবে: service-গুলো প্রতি মিনিটে সেখানে সংখ্যা (metric) পাঠায়, আর একটা alarm একটা metric-এর দিকে নজর রাখে, সীমা পার হলেই alarm অবস্থায় চলে যায়।

#Endpoint health check

#Checker-রা কীভাবে সিদ্ধান্ত নেয়

Endpoint health check বানালে দুনিয়ার নানা data centre-এর Route 53 health checker তোমার endpoint-এ request পাঠাতে শুরু করে।

• প্রায় ১৫টা checker। AWS নির্দিষ্ট কোনো সংখ্যা প্রকাশ করে না; course-এর slide আর বেশিরভাগ পরীক্ষার material বলে প্রায় ১৫টা, ছড়ানো health checker-এর Region-গুলোতে (us-east-1, us-west-1, us-west-2, eu-west-1, ap-southeast-1, ap-southeast-2, ap-northeast-1, sa-east-1)। Documentation বলে, ৩০ সেকেন্ডের interval-এ তোমার endpoint গড়ে প্রায় প্রতি দুই সেকেন্ডে একটা request পায়, যেটা মোটামুটি ১৫টা checker-এর সাথেই মেলে।
• Interval: ৩০ সেকেন্ড (standard) বা ১০ সেকেন্ড (fast)। প্রতিটা checker দুটো check-এর মাঝে এতক্ষণ অপেক্ষা করে। Fast-এর জন্য বাড়তি টাকা লাগে। Health check বানানোর পর interval আর বদলানো যায় না। Checker-রা নিজেদের মধ্যে সময় মেলায় না, তাই কখনো এক সেকেন্ডে কয়েকটা request আসে, তারপর কিছুক্ষণ চুপচাপ।
• Failure threshold: ১ থেকে ১০, default ৩। একজন checker endpoint-কে unhealthy ধরার আগে পরপর কয়টা check ফেল করতে হবে; আবার healthy ধরতেও পরপর ততগুলো পাস লাগে।
• Protocol: HTTP, HTTPS আর TCP।
  • TCP: checker-কে ১০ সেকেন্ডের মধ্যে TCP connection খুলতে পারতে হবে।
  • HTTP / HTTPS: ৪ সেকেন্ডের মধ্যে TCP connection, তারপর আরও ২ সেকেন্ডের মধ্যে 2xx বা 3xx HTTP status code। 4xx আর 5xx ফেল। Redirect (301, 302) পাস।
  • HTTPS check certificate যাচাই করে না, তাই মেয়াদ ফুরানো certificate-এর জন্য check ফেল হয় না। ঠিক certificate বাছতে যদি তোমার endpoint-এর TLS handshake-এ host name লাগে, SNI চালু করো। Endpoint-কে TLS 1.0, 1.1 বা 1.2 সমর্থন করতে হবে।
• কোন দিকে তাক করবে: একটা IP address (IPv4 বা IPv6, শুধু public; EC2 instance হলে Elastic IP দাও, যাতে address কখনো না বদলায়) বা একটা domain name (প্রতি interval-এ Route 53 নামটা resolve করে, শুধু IPv4)। সাথে একটা port, আর HTTP(S)-এর জন্য একটা path, যেমন /health।
• Route 53 সব checker-এর ফল মিলিয়ে হিসাব করে। যথেষ্ট data না আসা পর্যন্ত নতুন health check healthy গণ্য হয়।

#১৮%-এর নিয়ম

প্রত্যেক checker নিজে নিজে একটা রায় দেয়। তারপর Route 53 গুনে দেখে:

• ১৮%-এর বেশি checker endpoint-কে healthy বললে health check healthy।
• ১৮% বা তার কম healthy বললে health check unhealthy।

সীমাটা ইচ্ছে করেই এত নিচে। Route 53 চায় কয়েকটা Region-এর checker একমত হোক, কিন্তু network-এর কোনো গোলমালে এক-দুটো checker-এর জায়গা তোমার endpoint থেকে বিচ্ছিন্ন হয়ে গেল বলেই যেন failover না হয়। ১৫টা checker-এর মধ্যে ৩টা healthy (২০%) বললে check healthy থাকে; ২টা (১৩.৩%) হলে unhealthy। AWS নিজেই বলেছে এই সংখ্যা ভবিষ্যতে বদলাতে পারে, তাই হুবহু এই সংখ্যার ওপর কোনো logic দাঁড় করিও না।

#String matching

Status code মিথ্যা বলতে পারে। Maintenance page, বা “একটু পরে চেষ্টা করুন” লেখা ভদ্র page প্রায়ই 200 দিয়েই ফেরত আসে। String matching চালু করলে (শুধু HTTP বা HTTPS-এ, health check বানানোর সময়েই বাছতে হয়, বাড়তি খরচ) checker response-এর body-ও পড়ে, আর তোমার দেওয়া একটা লেখা খোঁজে:

• লেখাটা পুরোপুরি body-র প্রথম ৫,১২০ byte-এর মধ্যে থাকতে হবে।
• Status code আসার ২ সেকেন্ডের মধ্যে body পৌঁছাতে হবে।
• খোঁজাটা case-sensitive, সর্বোচ্চ ২৫৫ অক্ষর।
• Compressed body খোলা হয় কেবল gzip বা deflate হলে; অন্য কোনো compression হলে খোঁজা প্রায় সবসময় ব্যর্থ হয়।

ভালো একটা উপায়: ছোট একটা /health page বানাও, যেটা আসল dependency-গুলো (database, cache) সত্যি সত্যি পরীক্ষা করে, আর একদম শুরুতেই "status":"ok"-এর মতো একটা চিহ্ন লিখে দেয়।

#কোন কোন Region থেকে check হবে

Default-এ Route 53 সব recommended Region-এর checker ব্যবহার করে। চাইলে তালিকাটা নিজের মতো সাজাতে পারো, যেমন যখন তোমার সব user এশিয়ায়, বা checker-দের traffic নিজেই একটা বোঝা। তবে অন্তত তিনটা Region রাখতেই হবে। কোনো Region সরিয়ে দিলে সেখানকার checker-রা আরও প্রায় এক ঘণ্টা check চালিয়ে যায়, যাতে endpoint কখনো পাহারা ছাড়া না থাকে।

#Checker-দের ঢুকতে দাও

Health checker-রা internet-এর আর দশটা client-এর মতোই। ওদের আর তোমার endpoint-এর মাঝে কেউ যদি packet ফেলে দেয়, প্রতিটা checker timeout পায়, check unhealthy হয়, আর Route 53 একটা সুস্থ application ছেড়ে failover করে বসে।

• AWS checker-দের range প্রকাশ করে https://ip-ranges.amazonaws.com/ip-ranges.json-এ, "service": "ROUTE53_HEALTHCHECKS" নামে। (ROUTE53 হলো name server-দের range, লাগে শুধু তুমি DNS query আটকালে; ROUTE53_HEALTHCHECKS_PUBLISHING AWS-এর ভেতরের কাজে, ওটার জন্য কোনো rule লাগে না।) পুরনো GetCheckerIpRanges API এখনো একই তালিকা দেয়।
• Security group-এ সবচেয়ে সহজ হলো AWS-managed prefix list com.amazonaws.<region>.route53-healthchecks (IPv6-এর জন্য com.amazonaws.<region>.ipv6.route53-healthchecks), যেটা Route 53 নিজেই হালনাগাদ রাখে। এই list ২০২৩ থেকে আছে।
• একই range খুলে দাও network ACL-এ (লেসন ৩.৫), আর নিজের data centre-এর endpoint হলে on-premises router আর firewall-এ। শুধু health check-এর port-টাই খোলো।

#Health check-এর ওপর নজর: CloudWatch metric, latency graph আর alarm

Health check CloudWatch-এর সাথে জোড়া লাগানো।

• Route 53 health check-এর metric পাঠায় AWS/Route53 namespace-এ, dimension HealthCheckId, আর শুধু US East (N. Virginia), মানে us-east-1-এ। অন্য Region-এর CloudWatch console-এ খুঁজলে পাবে না।
• HealthCheckStatus হয় 1 (healthy) নয়তো 0 (unhealthy); HealthCheckPercentageHealthy বলে কত ভাগ checker healthy বলছে (endpoint check); ChildHealthCheckHealthyCount গোনে কয়টা child healthy (calculated check)।
• Latency graph (ঐচ্ছিক, বাড়তি খরচ, বানানোর সময়েই বাছতে হয়): প্রতিটা Region-এর checker থেকে ConnectionTime, SSLHandshakeTime আর TimeToFirstByte, console-এ দেখা যায়।
• খবর পাওয়া: HealthCheckStatus-এর ওপর একটা CloudWatch alarm বানাও (Minimum < 1), যেটা একটা SNS topic-এ পাঠাবে, আর সেখান থেকে তোমার team e-mail বা page পাবে। Metric যেহেতু us-east-1-এ, alarm আর তার SNS topic-ও সেখানেই বানাতে হয়। নষ্ট হওয়া থেকে e-mail আসা পর্যন্ত কয়েক মিনিট লাগতে পারে।
• Console-এ প্রতিটা checker-এর last failure reason (timeout, HTTP 503, string not found, connection refused) দেখা যায়; লাল হয়ে যাওয়া check-এর কারণ খুঁজতে এটাই সবচেয়ে দ্রুত রাস্তা।

SNS (Simple Notification Service) হলো AWS-এর publish/subscribe messaging service; পরে এর আলাদা chapter আছে।

#Health check-এর খরচ

লেখার সময়ের us-east-1-এর দাম (ভরসা করার আগে Route 53-এর pricing page দেখে নিও):

AWS endpoint-এর প্রথম ৫০টা health check বিনা পয়সায়। Disable করা health check-এরও বিল হয়। উদাহরণ: একটা ALB-এ string matching আর fast interval-সহ HTTPS check-এর খরচ ০.৫০ + ৩ × ১.০০ = মাসে $3.50।

#Calculated health check

একটা calculated health check (এটাই parent) অন্য কয়েকটা health check-এর (এরা child) দিকে নজর রাখে, আর তাদের status মিলিয়ে একটা status বানায়:

• AND: সব child healthy হলে তবেই healthy।
• OR: অন্তত একটা child healthy হলেই healthy।
• M-এর মধ্যে অন্তত N: N বা তার বেশি child healthy হলে healthy। N = ০ মানে সবসময় healthy; N যদি child-এর সংখ্যার চেয়ে বড় হয়, সবসময় unhealthy।
• NOT: parent-কে (বা কোনো child-কে) উল্টে দাও, healthy হয়ে যায় unhealthy, আর উল্টোটাও।

একটা parent সর্বোচ্চ ২৫৫টা child health check দেখতে পারে (console আর API ২৫৬ নেয়)। Child হতে পারে endpoint check বা CloudWatch alarm check, কিন্তু অন্য calculated check না: স্তর মাত্র একটাই।

Note-এর উদাহরণটা: তোমার তিনটা web server আছে। তুমি একটা calculated check বানালে, নিয়ম “৩টার মধ্যে অন্তত ২টা healthy থাকলে healthy”, আর সেটা primary failover record-এর সাথে জুড়ে দিলে। এখন একটা server মরে গেলে, বা maintenance-এর জন্য নামিয়ে রাখলে, পুরো site failover করে না। এটাই সবচেয়ে চেনা ব্যবহার: সব health check ফেল না করিয়েই maintenance।

দুটো খুঁটিনাটি, যেখানে অনেকে আটকে যায়:

• Disable করা health check সবসময় healthy গণ্য হয়, child হিসেবেও। কোনো child-কে ইচ্ছে করে unhealthy গোনাতে চাইলে (একটা server থেকে traffic সরাতে) disable না করে invert করো।
• Child-দের নিজেদের threshold খাটেই: child unhealthy হয় তার নিজের failure threshold পার হলে, তারপর parent আবার হিসাব করে।

#Private resource: CloudWatch alarm-এর ওপর health check

Route 53 health checker-রা থাকে তোমার VPC-র বাইরে, internet-এ। ওরা private endpoint-এ পৌঁছাতে পারে না: শুধু private IP-ওয়ালা EC2 instance, private subnet-এর RDS database, internal load balancer, বা VPN কিংবা Direct Connect দিয়ে জোড়া তোমার data centre-এর server (এই private link-গুলোর আলাদা chapter পরে আছে)। Private, local বা non-routable address-এর জন্য Route 53 endpoint health check বানাতেই দেয় না।

সমাধান তিন ধাপের একটা শিকল:

1. একটা metric পাঠাও

   Resource AWS-এর ভেতর থেকেই CloudWatch-এ একটা সংখ্যা পাঠায়, তাই internet-এর পথ লাগে না: EC2-এর StatusCheckFailed metric, RDS-এর ReplicaLag বা FreeStorageSpace, DynamoDB-এর throttled request, SQS-এর ApproximateNumberOfMessagesVisible, বা তোমার application কিংবা on-premises server-এর CloudWatch agent থেকে আসা custom metric।

2. সেটার ওপর একটা CloudWatch alarm বানাও

   যেমন: StatusCheckFailed 1 হলে alarm, বা queue-তে পাঁচ মিনিট ধরে ১০,০০০-এর বেশি message থাকলে alarm।

3. Alarm-টা monitor করে এমন একটা health check বানাও

   “State of CloudWatch alarm” বাছো। Alarm OK → healthy; alarm অবস্থায় → unhealthy। তারপর endpoint check-এর মতোই এই health check record-এর সাথে জুড়ে দাও।

Route 53 documentation অনুযায়ী alarm-এর শর্ত:

• Health check যে AWS account-এ, alarm-ও সেখানেই থাকতে হবে (cross-account alarm চলে না)।
• শুধু standard-resolution metric, সাধারণ statistic দিয়ে (Average, Minimum, Maximum, Sum, SampleCount); extended (percentile) statistic চলে না, metric math চলে না, “M out of N” alarm-ও না।
• Route 53 দেখে alarm-এর data stream, alarm-এর state নিজে না, তাই SetAlarmState API দিয়ে জোর করে failover ঘটানো যায় না।
• Alarm বদলালে health check-ও update করো।
• Insufficient data: CloudWatch-এর হাতে data না থাকলে health check কী বলবে, তুমিই বেছে দাও: healthy, unhealthy, নাকি last known status (ইতিহাস না থাকা নতুন check healthy গণ্য হয়)। Metric যদি ঘণ্টার পর ঘণ্টা না আসতে পারে, AWS last known status না নিতে বলে।

Note-এর practice question, পুরোটা:

#Record কীভাবে health check ব্যবহার করে

একা একটা health check শুধু একটা status ধরে রাখে (আর alert পাঠাতে পারে)। DNS-এর উত্তর বদলায় কেবল তখনই, যখন তুমি সেটা record-এর সাথে জুড়ে দাও।

Record বাছার সময় Route 53 যে নিয়মগুলো মানে:

1. Query আসার মুহূর্তে সে কোনো check চালায় না। Check পেছনে সারাক্ষণ চলছে; query শুধু সর্বশেষ status পড়ে।
2. Health check ছাড়া record সবসময় healthy। একটা group-এ কয়েকটায় health check আছে আর একটায় নেই, তো check-ছাড়াটা সবসময়ই বাছাইয়ের যোগ্য। Group-এর প্রতিটা non-Alias record-এ health check দাও।
3. Alias record এর বদলে Evaluate Target Health ব্যবহার করে (লেসন ৮.২)। Evaluate Target Health = Yes দিলে Alias record তার target-এর health উত্তরাধিকারসূত্রে পায়:
   • ALB / NLB: healthy কেবল তখন, যখন target আছে এমন প্রতিটা target group-এ অন্তত একটা healthy target আছে; কোনো target register না থাকা target group unhealthy গণ্য হয়। এগুলো load balancer-এর নিজের health check (লেসন ৬.২), বিনা পয়সায়, আর AWS বলে load balancer-এর পেছনের instance-গুলোর জন্য Route 53 health check বানিও না।
   • একই hosted zone-এর আরেকটা record: target group-এর অন্তত একটা record healthy হলেই healthy; এভাবেই গাছ বানানো হয় (latency Alias → weighted record → endpoint check)।
   • CloudFront: Evaluate Target Health Yes করাই যায় না। S3 website, API Gateway, VPC interface endpoint, Global Accelerator: করা যায়, কিন্তু অর্থহীন, কারণ এই service-গুলো নিজেই highly available করে বানানো; তার বদলে এমন Route 53 health check দাও, যেটা ওদের ভেতর দিয়ে তোমার application পরীক্ষা করে।
4. Group-এর কোনো record healthy না থাকলে সবগুলোকেই healthy ধরা হয়। Route 53-কে কিছু একটা উত্তর দিতেই হবে, আর বাছার কোনো ভিত্তি নেই, তাই সে এমনভাবে স্বাভাবিক routing করে যেন সবাই healthy। Failover জোড়ায় দুটোরই health check থাকলে আর দুটোই unhealthy হলে সে primary দেয়।
5. Weight 0-এর record ব্যবহার হয় কেবল তখন, যখন শূন্য-নয় এমন weight-এর সব record unhealthy।

#DNS failover-এ কত সময় লাগে

Server মারা যাওয়ার কতক্ষণ পরে user-রা secondary-তে পৌঁছায়? তিনটা টুকরো যোগ করো:

1. ধরা পড়া (detection): সর্বোচ্চ interval × failure threshold। Default: ৩০ s × ৩ = ৯০ s (একটা সফল check-এর ঠিক পরেই server মরতে পারে)। ধীর checker-রা যখনো গুনছে, তখনই ১৮%-এর নিয়ম status বদলে দেয়, তাই প্রায়ই কয়েক সেকেন্ড কম লাগে।
2. ছড়িয়ে পড়া (propagation): নতুন status Route 53-এর name server-দের কাছে পৌঁছায়, সাধারণত কয়েক সেকেন্ডে।
3. Cache: যে resolver-রা পুরনো উত্তর cache করেছে, তারা TTL শেষ না হওয়া পর্যন্ত সেটাই রাখে। সবচেয়ে খারাপ অবস্থায় পুরো এক TTL। কিছু client আর application (পুরনো Java setting, browser) TTL-এর চেয়েও বেশি সময় cache রাখে।

হাতে-কলমে হিসাব। একজোড়া failover record, TTL ৬০ s, আর default health check (৩০ s, threshold ৩):

• ধরা পড়া ≤ ৯০ s, সাথে TTL ≤ ৬০ s, সবচেয়ে খারাপ অবস্থায় প্রায় ১৫০ s, মানে আড়াই মিনিট;
• fast interval আর threshold ১ দিলে (১০ s × ১ = ১০ s) আর TTL ৬০ s: প্রায় ৭০ s;
• default check কিন্তু TTL এক দিন (৮৬,৪০০ s) হলে: ধরা পড়তে তবু ৯০ s, কিন্তু কিছু user মরা address-টা ২৪ ঘণ্টা পর্যন্ত রেখে দেয়। Health check ঠিকঠাকই কাজ করেছে; হারিয়ে দিয়েছে TTL।

AWS resource-এর দিকে যাওয়া Alias record-এ তুমি TTL দিতে পারো না: Route 53 target-এর TTL ব্যবহার করে (load balancer-এর জন্য ৬০ সেকেন্ড, লেসন ৮.২)। ছোট threshold আর fast interval দ্রুত ধরে, কিন্তু flapping হতে পারে: একটা ধীর উত্তরেই traffic চলে যায়, আবার ফিরে আসে। একই threshold failback-কেও ধীর করে: ঠিক হওয়ার পর endpoint-কে পরপর ততগুলো check পাস করতে হয়, তারপর Route 53 নিজে থেকেই primary-তে ফিরে যায়।

#কোথায় গোলমাল হয়

#Health check-এর বাইরে: Application Recovery Controller (পাশের কথা)

Health check failover-কে স্বয়ংক্রিয় করে, বেশিরভাগ outage-এ এটাই চাই। কিন্তু বড়, নিয়মকানুনে বাঁধা বা খুব দামি application-এ team-রা প্রায়ই উল্টোটা চায়: মানুষের অনুমোদনে, আগে থেকে বোঝা যায় এমন একটা switch, যেটা কোনো probe-এর রায়ের ওপর নির্ভর করে না যে Region “যথেষ্ট খারাপ” হয়েছে কি না, আর AWS-এর কিছু অংশ গোলমালে থাকলেও কাজ করে যায়।

• Amazon Application Recovery Controller (ARC) (আগের নাম Route 53 ARC) দেয় routing control: control panel-এ সাজানো সরল on/off switch। প্রতিটা routing control একটা বিশেষ recovery control ধরনের Route 53 health check-এর সাথে বাঁধা: switch on = healthy, off = unhealthy। ওই health check failover record-এ জুড়ে দাও, তাহলে switch ঘোরালেই traffic সরে যায়।
• Routing control চলে পাঁচটা AWS Region-এর endpoint নিয়ে গড়া একটা cluster-এ (highly available data plane), তাই একটা Region, বা control plane, গোলমালে থাকলেও failover করা যায়। Safety rule operator-কে একসাথে সব বন্ধ করে দেওয়া থেকে আটকায়।
• Readiness check (standby Region-এ একই capacity আর configuration আছে কি না যাচাই) নতুন customer-দের জন্য আর খোলা নেই; তার বদলে AWS বলে ARC Region switch ব্যবহার করতে, এটা একটা managed multi-Region recovery orchestrator (২০২৫), সাথে plan evaluation। Zonal shift আর zonal autoshift load balancer-এর traffic একটা AZ থেকে সরিয়ে নেয়।
• Route 53 accelerated recovery (নভেম্বর ২০২৫) একটা public hosted zone-এর record-এর একটা কপি US West (Oregon)-এ রাখে, যাতে us-east-1 গোলমালে পড়লেও প্রায় এক ঘণ্টার মধ্যে তুমি record বদলাতে পারো। DNS-এর উত্তর কখনোই আটকায়নি; এটা রক্ষা করে edit করার ক্ষমতা।
• আরও কিছু সাম্প্রতিক বদল: নতুন health check console (২০২৪) আর checker IP-র জন্য managed prefix list (২০২৩), দুটোই ওপরে বলা হয়েছে। Health check-এর নিয়মগুলো নিজে (১৮%, ৩০/১০ s, threshold, ৫,১২০ byte) বদলায়নি।

পরীক্ষার জন্য: স্বয়ংক্রিয় DNS failover → health check + failover routing; “health check বা control plane-এর বদলের ওপর ভরসা না করে Region-এর মধ্যে traffic হাতে আর নির্ভরযোগ্যভাবে সরাও” → ARC routing control।

#System design-এ health check

• Active-passive DR (লেসন ৮.৩-এর failover policy): endpoint বা calculated check-ওয়ালা একটা primary, যার secondary-ও check করা, TTL ৬০ s। সব বন্ধ হয়ে গেলে শেষ ভরসা হিসেবে একটা static S3 “sorry” page রাখো।
• Active-active: প্রতিটা Region-এর জন্য latency বা weighted record, প্রত্যেকটা load balancer-এর দিকে Alias, Evaluate Target Health = Yes দিয়ে, যাতে healthy target না থাকা Region নিজে থেকেই বাদ পড়ে।
• ঠিক স্তরে check করো। Load balancer-এর health check ঠিক করে কোন instance request পাবে (লেসন ৬.২); Route 53-এর health check ঠিক করে কোন Region বা endpoint user পাবে। দুটোর কাজ দ্বিগুণ কোরো না।
• Private tier-এর health CloudWatch alarm দিয়ে; একটা Region-এর সামগ্রিক health একটা calculated check দিয়ে (web tier AND database alarm, বা ৩টা web server-এর “অন্তত ২টা”)।
• প্রতিটা health check-এ alert দাও, us-east-1-এ একটা CloudWatch alarm আর SNS দিয়ে: কেউ জানে না এমন failover মানে secondary নষ্ট হওয়ার অপেক্ষায় থাকা দ্বিতীয় একটা outage।
• নিয়মিত failover পরীক্ষা করো (game day-তে primary-র check invert করে)। অনেক DR plan ব্যর্থ হয় শুধু কারণ secondary কখনো চালিয়েই দেখা হয়নি।

#নিজে করে দেখো

# ১. String matching-সহ HTTPS endpoint check, threshold 3, standard 30 s interval
aws route53 create-health-check --caller-reference web-use1-$(date +%s) \
  --health-check-config '{
    "Type": "HTTPS_STR_MATCH",
    "FullyQualifiedDomainName": "us-east-1-www.example.com",
    "Port": 443, "ResourcePath": "/health",
    "SearchString": "\"status\":\"ok\"",
    "RequestInterval": 30, "FailureThreshold": 3,
    "EnableSNI": true, "MeasureLatency": true,
    "Regions": ["us-east-1", "eu-west-1", "ap-southeast-1"]
  }'

# ২. প্রতিটা checker এই মুহূর্তে কী দেখছে, আর শেষবার কেন ফেল করেছিল
aws route53 get-health-check-status --health-check-id 1a2b3c4d-1111-2222-3333-444455556666
aws route53 get-health-check-last-failure-reason --health-check-id 1a2b3c4d-1111-2222-3333-444455556666

# ৩. একটা calculated check: ৩টা child-এর অন্তত ২টা healthy হলে healthy
aws route53 create-health-check --caller-reference web-tier-$(date +%s) \
  --health-check-config '{
    "Type": "CALCULATED", "HealthThreshold": 2,
    "ChildHealthChecks": ["<web-1-id>", "<web-2-id>", "<web-3-id>"]
  }'

# ৪. একটা CloudWatch alarm-এর ওপর health check (private resource-এর জন্য)
aws route53 create-health-check --caller-reference db-alarm-$(date +%s) \
  --health-check-config '{
    "Type": "CLOUDWATCH_METRIC",
    "AlarmIdentifier": {"Region": "eu-west-1", "Name": "orders-db-replica-lag"},
    "InsufficientDataHealthStatus": "LastKnownStatus"
  }'

# ৫. Primary failover record-এ health check জুড়ে দাও
aws route53 change-resource-record-sets --hosted-zone-id Z0123456789EXAMPLE \
  --change-batch '{"Changes": [{"Action": "UPSERT", "ResourceRecordSet": {
    "Name": "www.example.com", "Type": "A", "TTL": 60,
    "SetIdentifier": "primary", "Failover": "PRIMARY",
    "HealthCheckId": "1a2b3c4d-1111-2222-3333-444455556666",
    "ResourceRecords": [{"Value": "198.51.100.10"}]}}]}'

# ৬. Game day: primary-র check invert করে জোর করে failover, তারপর আগের মতো
aws route53 update-health-check --health-check-id 1a2b3c4d-1111-2222-3333-444455556666 --inverted
aws route53 update-health-check --health-check-id 1a2b3c4d-1111-2222-3333-444455556666 --no-inverted

# ৭. Check unhealthy হলে e-mail পাও (metric আর alarm থাকে us-east-1-এ)
aws cloudwatch put-metric-alarm --region us-east-1 --alarm-name www-primary-unhealthy \
  --namespace AWS/Route53 --metric-name HealthCheckStatus \
  --dimensions Name=HealthCheckId,Value=1a2b3c4d-1111-2222-3333-444455556666 \
  --statistic Minimum --period 60 --evaluation-periods 1 \
  --threshold 1 --comparison-operator LessThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:oncall

Checker-দের ঢুকতে দাও, আর ওদের range দেখো:

# Security group-এর জন্য managed prefix list (endpoint-এর Region)
aws ec2 describe-managed-prefix-lists \
  --filters Name=prefix-list-name,Values=com.amazonaws.eu-west-1.route53-healthchecks
aws ec2 authorize-security-group-ingress --group-id sg-0web0123456789abc \
  --ip-permissions 'IpProtocol=tcp,FromPort=443,ToPort=443,PrefixListIds=[{PrefixListId=pl-0123456789abcdef0}]'

# ip-ranges.json থেকে কাঁচা range
curl -s https://ip-ranges.amazonaws.com/ip-ranges.json \
  | jq -r '.prefixes[] | select(.service=="ROUTE53_HEALTHCHECKS") | "\(.region) \(.ip_prefix)"'

বাইরে থেকে failover দেখো (game day-তে কয়েক সেকেন্ড পরপর চালাও):

dig +noall +answer www.example.com          # তোমার resolver-এর উত্তর আর বাকি TTL
dig +noall +answer www.example.com @ns-123.awsdns-15.com   # সরাসরি Route 53 থেকে, cache ছাড়া

প্রথম command দেখায় তোমার resolver কী cache করে রেখেছে আর TTL-এর কত সেকেন্ড বাকি; দ্বিতীয়টা তোমার zone-এর একটা Route 53 name server-কে সরাসরি জিজ্ঞেস করে, তাই health check উল্টানো মাত্রই নতুন উত্তর দেখায়।

#সারসংক্ষেপ

মূল কথা

• Health check একটা healthy/unhealthy status ধরে রাখে; record-এর সাথে জুড়লে দেয় automated DNS failover। ঠিক তিন ধরন: endpoint, calculated (অন্য health check monitor করে) আর CloudWatch alarm। SQS, RDS বা DynamoDB health check বলে কিছু নেই।
• Endpoint check: কয়েকটা Region-এ প্রায় ১৫টা checker, HTTP, HTTPS বা TCP, interval ৩০ s বা ১০ s (fast, বাড়তি খরচ), failure threshold ১–১০, default ৩, ১৮%-এর বেশি checker বললে healthy, পাস শুধু 2xx/3xx-এ (৪ s-এ TCP, তারপর ২ s-এ উত্তর), ঐচ্ছিক string match প্রথম ৫,১২০ byte-এ, checker Region বাছো অন্তত ৩টা, HTTPS certificate যাচাই করে না।
• Checker-দের ঢুকতে দাও: ip-ranges.json-এর ROUTE53_HEALTHCHECKS range, বা managed prefix list com.amazonaws.<region>.route53-healthchecks, security group, NACL আর on-premises firewall-এ।
• Calculated check: সর্বোচ্চ ২৫৫টা child (API ২৫৬), AND / OR / NOT / M-এর মধ্যে অন্তত N, স্তর একটাই, disabled child healthy গণ্য; failover ছাড়াই maintenance-এর কাজে লাগে।
• Private resource (private EC2, RDS, on-premises, private hosted zone, SQS-এ জট, DynamoDB throttle): checker-রা VPC-র বাইরে, তাই CloudWatch metric → alarm → alarm-এর ওপর health check (একই account, standard resolution, insufficient data-তে কী হবে বেছে নাও)।
• Record: simple-এ health check নেই; failover-এর primary-তে একটা লাগবেই; check ছাড়া record সবসময় healthy; Alias ব্যবহার করে Evaluate Target Health (ALB/NLB: target আছে এমন প্রতিটা target group-এ একটা healthy target লাগবে; CloudFront-এ চলে না); সব unhealthy → সবাই healthy গণ্য (failover-এ primary)।
• Failover-এর সময় ≈ interval × threshold + TTL (default ৯০ s + ৬০ s ≈ আড়াই মিনিট)। যে record failover করে তার TTL ছোট রাখো; একই সংখ্যক পাসের পর failback নিজে থেকেই হয়।
• Health check-এর metric আর alarm থাকে us-east-1-এ; alert-এর জন্য SNS। হাতে, নির্ভরযোগ্যভাবে Region বদলাতে ARC routing control।

নিজেকে যাচাই করো: Route 53 health check আর DNS failover৩১টি প্রশ্ন