Cloud & IT Cert Prep · पाठ

स्वास्थ्य जाँच, सर्किट ब्रेकर और पुनःप्रयास तर्क

विफलताओं की पहचान करने और ट्रैफ़िक को स्वचालित रूप से पुनर्निर्देशित करने के लिए ELB स्वास्थ्य जाँच, Route 53 एंडपॉइंट जाँच और अनुप्रयोग-स्तरीय सर्किट ब्रेकर का उपयोग कीजिए।

पाठ 4, कुल 4 में से13 चरण

स्वास्थ्य जाँच, सर्किट ब्रेकर और पुनःप्रयास तर्क, CoddyKit पर Cloud & IT Cert Prep का एक निःशुल्क पाठ है। यह 4 में से 4वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह Cloud & IT Cert Prep सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Cloud & IT Cert Prep पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

Automated Failure Detection क्यों महत्वपूर्ण है

Distributed Systems में Components लगातार विफल होते रहते हैं — Instances Crash हो जाते हैं, Network Partitions उत्पन्न होते हैं और Downstream Services पर अत्यधिक Load पड़ जाता है। Automated Failure Detection के बिना ट्रैफ़िक विफल Components तक पहुँचता रहता है, जिससे Cascading Failures हो सकती हैं। AWS Health Checking की कई Layers उपलब्ध कराता है: ELB Health Checks Unhealthy Instances का पता लगाते हैं, Route 53 Health Checks Unhealthy Endpoints का पता लगाते हैं और Auto Scaling विफल Instances को बदल देता है। Circuit Breakers और Retries जैसे Application-Level Patterns Resilience को और पूर्ण बनाते हैं।

ELB स्वास्थ्य जाँच

Elastic Load Balancer की स्वास्थ्य जाँच पंजीकृत लक्ष्यों को स्वस्थ होने या न होने का पता लगाने के लिए समय-समय पर अनुरोध भेजती है। आप स्वास्थ्य जाँच पथ (जैसे, /health), प्रोटोकॉल, पोर्ट, अंतराल (डिफ़ॉल्ट 30 सेकंड), और स्वस्थ/अस्वस्थ सीमा (लगातार सफलताओं/विफलताओं की संख्या) कॉन्फ़िगर करते हैं। जब कोई लक्ष्य स्वास्थ्य जाँच में विफल हो जाता है, तो ELB उस पर ट्रैफ़िक भेजना रोक देता है। लक्ष्य का लगातार पुनर्मूल्यांकन किया जाता है और स्वस्थ सीमा पूरी करने के बाद उसे फिर से शामिल कर लिया जाता है।

# Configure ALB target group health check
aws elbv2 modify-target-group \
  --target-group-arn arn:aws:elasticloadbalancing::123:targetgroup/my-tg/abc \
  --health-check-protocol HTTPS \
  --health-check-port 443 \
  --health-check-path /health \
  --health-check-interval-seconds 15 \
  --healthy-threshold-count 2 \
  --unhealthy-threshold-count 3 \
  --matcher HttpCode=200

Route 53 स्वास्थ्य जाँच

Route 53 स्वास्थ्य जाँच विश्वभर में कई स्थानों से एंडपॉइंट की निगरानी करती है और DNS failover रूटिंग के साथ मिलकर काम करती है। इसके तीन प्रकार हैं: एंडपॉइंट जाँच आपके एप्लिकेशन URL को सीधे जाँचती हैं। Calculated जाँच कई अधीनस्थ स्वास्थ्य जाँचों को AND/OR तर्क के साथ जोड़ती हैं (जटिल निगरानी के लिए उपयोगी)। CloudWatch अलार्म जाँच स्वास्थ्य का निर्धारण CloudWatch को सौंपती हैं—यह तब उपयोगी है जब आप सार्वजनिक स्वास्थ्य एंडपॉइंट उपलब्ध नहीं करा सकते या मेट्रिक-आधारित स्वास्थ्य निर्णयों की आवश्यकता हो।

# Create endpoint health check
aws route53 create-health-check \
  --caller-reference ref-$(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "api.example.com",
    "Port": 443,
    "ResourcePath": "/health",
    "RequestInterval": 10,
    "FailureThreshold": 2,
    "EnableSNI": true
  }'

स्वचालित स्केलिंग की स्वास्थ्य जाँच

Auto Scaling Groups दो प्रकार की स्वास्थ्य जाँचों का उपयोग कर सकते हैं: EC2 स्वास्थ्य जाँच हाइपरवाइज़र स्तर पर इंस्टेंस की विफलताओं का पता लगाती हैं (इंस्टेंस स्थिति जाँच की विफलता)। ELB स्वास्थ्य जाँच एप्लिकेशन की स्थिति को अधिक ध्यान में रखती हैं—कोई इंस्टेंस चल रहा हो सकता है, लेकिन त्रुटियाँ दे रहा हो, और ELB स्वास्थ्य जाँच इसका पता लगा लेती हैं। आप ASG को ELB स्वास्थ्य जाँचों का उपयोग करने के लिए कॉन्फ़िगर कर सकते हैं, ताकि केवल अंतर्निहित EC2 विफलताओं के बजाय एप्लिकेशन-स्तर की विफलताएँ भी इंस्टेंस को बदलने की प्रक्रिया शुरू करें।

# Configure ASG to use ELB health checks
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --health-check-type ELB \
  --health-check-grace-period 300

# Grace period: time after launch before health checks start
# Prevents premature termination during startup

Circuit Breaker पैटर्न

circuit breaker एक एप्लिकेशन-स्तरीय पैटर्न है, जो डाउनस्ट्रीम सेवा को किए जाने वाले कॉल की निगरानी करके और विफलताएँ सीमा से अधिक होने पर अस्थायी रूप से कॉल रोककर विफलताओं के फैलाव को रोकता है। Circuit की तीन स्थितियाँ होती हैं: Closed (सामान्य संचालन), Open (विफलताएँ सीमा से अधिक हो गई हैं, इसलिए कॉल तुरंत रोक दिए जाते हैं), और Half-Open (timeout के बाद, यह जाँचने के लिए कुछ test calls की अनुमति दी जाती है कि सेवा ठीक हुई है या नहीं)। AWS App Mesh और Resilience4j जैसे एप्लिकेशन SDK इस पैटर्न को लागू करते हैं।

# Circuit breaker states
# CLOSED: All calls pass through
#   failureCount < threshold -> stay CLOSED
#   failureCount >= threshold -> open circuit

# OPEN: All calls fail immediately
#   After timeout -> enter HALF-OPEN

# HALF-OPEN: Allow limited test calls
#   Success -> return to CLOSED
#   Failure -> return to OPEN

# Example threshold: 5 failures in 10 seconds -> OPEN

Circuit Breaking के लिए AWS App Mesh

AWS App Mesh एक service mesh है, जो कोड में बदलाव किए बिना infrastructure स्तर पर circuit breaking, पुनःप्रयास और timeout नीतियाँ लागू करता है। आप वर्चुअल नोड या वर्चुअल राउटर कॉन्फ़िगरेशन में circuit breaker नीतियाँ परिभाषित करते हैं। जब कोई upstream सेवा अस्वस्थ हो जाती है, तो App Mesh का Envoy proxy अपने-आप circuit खोल देता है और timeout की प्रतीक्षा करने के बजाय तुरंत त्रुटियाँ लौटाता है। यह ECS या EKS पर चलने वाली microservices architectures में विशेष रूप से उपयोगी है।

# App Mesh virtual node with circuit breaker
# (JSON configuration)
{
  'spec': {
    'listeners': [{
      'outlierDetection': {
        'consecutiveErrors': 5,
        'interval': {'unit': 'ms', 'value': 10000},
        'baseEjectionDuration': {'unit': 's', 'value': 30},
        'maxEjectionPercent': 50
      }
    }]
  }
}

पुनःप्रयास तर्क और घातीय बैकऑफ़

पुनःप्रयास तर्क विफल operations को अपने-आप फिर से करता है, लेकिन सरल पुनःप्रयास तर्क (बिना अंतराल के तंग लूप में तुरंत पुनःप्रयास) अधिक भार की स्थिति को और बिगाड़ सकता है। घातीय बैकऑफ़ हर पुनःप्रयास के बीच प्रतीक्षा समय को घातीय रूप से बढ़ाता है: 1s, 2s, 4s, 8s... Jitter (पुनःप्रयास अंतरालों को यादृच्छिक बनाना) उस thundering herd समस्या को रोकता है, जिसमें थोड़ी देर की सेवा-विघ्न के बाद सभी client एक साथ पुनःप्रयास करते हैं। AWS SDK घातीय बैकऑफ़ को jitter के साथ अपने-आप लागू करता है।

# AWS SDK retries with exponential backoff automatically
# Default retry config for most AWS services:
# Max retries: 3-5 (varies by service)
# Base delay: 100ms
# Max delay: ~20 seconds

# Python boto3 custom retry configuration
import boto3
from botocore.config import Config

config = Config(
    retries={'max_attempts': 5, 'mode': 'adaptive'}
)
client = boto3.client('s3', config=config)

सुरक्षित पुनःप्रयासों के लिए Idempotency

पुनःप्रयास तभी सुरक्षित होते हैं जब operations idempotent हों—एक ही operation को कई बार करने पर भी वही परिणाम मिले। उदाहरण के लिए, समान key के साथ S3 object बनाना idempotent है (परिणाम समान रहता है)। लेकिन किसी order को दो बार रखना दो orders बनाता है—यह idempotent नहीं है। client द्वारा दिए गए idempotency keys का उपयोग करके APIs को idempotent बनाएँ: server पहले request का परिणाम संग्रहीत करता है और उसी key वाले बाद के requests के लिए वही परिणाम लौटाता है। DynamoDB, SQS और API Gateway idempotency key पैटर्न का समर्थन करते हैं।

# SQS message deduplication ID for FIFO queues
aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders.fifo \
  --message-body '{"orderId":"ord-123","items":[...]}' \
  --message-group-id 'customer-456' \
  --message-deduplication-id 'ord-123-attempt-1'

# SQS deduplicates messages with same ID for 5 minutes

Timeout कॉन्फ़िगरेशन

स्पष्ट timeouts के बिना, धीमी downstream सेवा threads को अनिश्चित समय तक रोक देती है, connection pool को समाप्त कर देती है और विफलताओं के फैलाव का कारण बनती है। हर स्तर पर timeouts निर्धारित करें: connection timeout (TCP connection स्थापित करने में लगने वाला समय), read timeout (response प्राप्त करने में लगने वाला समय), और overall request timeout। AWS में ELB idle timeout (डिफ़ॉल्ट 60s), Lambda execution timeout (अधिकतम 15 min), और API Gateway integration timeout (अधिकतम 29s) कॉन्फ़िगर करें। Timeouts आपके retry या circuit-breaker तर्क को सक्रिय करते हैं।

# Lambda: set execution timeout
aws lambda update-function-configuration \
  --function-name my-function \
  --timeout 30

# ALB: configure idle timeout
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn <ALB-ARN> \
  --attributes Key=idle_timeout.timeout_seconds,Value=60

# API Gateway: integration timeout max 29000ms

विफल प्रोसेसिंग के लिए Dead Letter Queues

जब message processing बार-बार विफल होती है, तो Dead Letter Queue (DLQ) उन messages को संग्रहीत करती है जिन्हें receive attempts की अधिकतम संख्या के बाद भी process नहीं किया जा सका। SQS queues और Lambda event source mappings पर DLQs कॉन्फ़िगर करें, ताकि खराब messages आपकी queue को अनिश्चित समय तक अवरुद्ध न करें। DLQ में मौजूद messages का निरीक्षण किया जा सकता है, bug ठीक करने के बाद उन्हें फिर से चलाया जा सकता है या archive किया जा सकता है। DLQs resilient event-driven architectures का एक महत्वपूर्ण घटक हैं।

# Configure DLQ on SQS queue
aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/main-queue \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:123:dlq\",\"maxReceiveCount\":3}"
  }'

# After 3 failed processing attempts, message goes to DLQ

CloudWatch के साथ विफलताओं का अवलोकन

प्रभावी स्वास्थ्य जाँचों और circuit breakers के लिए failure patterns को समझने हेतु निगरानी आवश्यक है। CloudWatch observability layer है: ELB UnHealthyHostCount (स्वास्थ्य जाँच में विफल इंस्टेंस), Lambda Errors rate, SQS NumberOfMessagesSentToDLQ (DLQ तक पहुँचने वाले messages), और Target group RequestCountPerTarget पर alarms बनाएँ। SNS notifications सेट करें, ताकि automated health checks द्वारा degradation का पता चलते ही आपकी on-call team को तुरंत alert मिले।

# CloudWatch alarm for unhealthy hosts
aws cloudwatch put-metric-alarm \
  --alarm-name 'ALB-UnhealthyHosts' \
  --alarm-description 'Alert when targets fail health checks' \
  --metric-name UnHealthyHostCount \
  --namespace AWS/ApplicationELB \
  --period 60 \
  --evaluation-periods 2 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123:ops-team

त्वरित जाँच

इस lesson में AWS Solutions Architect (SAA-C03) concepts की अपनी समझ जाँचें।

इंटरैक्टिव पाठ में इसका उत्तर दें

Lesson का पुनरावलोकन

इस lesson में आपने सीखा: ELB और Route 53 स्वास्थ्य जाँचें infrastructure स्तर पर failure detection को स्वचालित करती हैं, circuit breakers अस्वस्थ services को किए जाने वाले calls रोककर cascading failures को रोकते हैं, और jitter के साथ exponential backoff load के दौरान retries को सुरक्षित बनाता है। Dead Letter Queues विफल messages को निरीक्षण के लिए संग्रहीत करती हैं। आगे हम RTO, RPO और disaster recovery tiers का अध्ययन करेंगे।

शुरुआत निःशुल्क

एआई शिक्षक के साथ Cloud & IT Cert Prep सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम: 150
पाठ: 600

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “स्वास्थ्य जाँच, सर्किट ब्रेकर और पुनःप्रयास तर्क” पाठ निःशुल्क है?

हाँ—“स्वास्थ्य जाँच, सर्किट ब्रेकर और पुनःप्रयास तर्क” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और Cloud & IT Cert Prep पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। Cloud & IT Cert Prep पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“स्वास्थ्य जाँच, सर्किट ब्रेकर और पुनःप्रयास तर्क” में मैं क्या सीखूँगा?

विफलताओं की पहचान करने और ट्रैफ़िक को स्वचालित रूप से पुनर्निर्देशित करने के लिए ELB स्वास्थ्य जाँच, Route 53 एंडपॉइंट जाँच और अनुप्रयोग-स्तरीय सर्किट ब्रेकर का उपयोग कीजिए। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Cloud & IT Cert Prep का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या Cloud & IT Cert Prep शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Cloud & IT Cert Prep शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 4वाँ पाठ है।

“स्वास्थ्य जाँच, सर्किट ब्रेकर और पुनःप्रयास तर्क” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस Cloud & IT Cert Prep पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर Cloud & IT Cert Prep पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

HA बनाम दोष-सहिष्णुता: परिभाषाएँ और समझौते
स्टेटफुल सेवाओं के लिए मल्टी-AZ पैटर्न
बहु-Region सक्रिय-सक्रिय और सक्रिय-निष्क्रिय
स्वास्थ्य जाँच, सर्किट ब्रेकर और पुनःप्रयास तर्क

← Cloud & IT Cert Prep पर वापस जाएँ