0Pricing
AWS Solutions Architect · Pelajaran

Pemeriksaan Kesehatan, Pemutus Sirkuit, dan Logika Percobaan Ulang

Gunakan pemeriksaan kesehatan ELB, pemeriksaan titik akhir Route 53, dan pemutus sirkuit tingkat aplikasi untuk mendeteksi kegagalan dan mengalihkan lalu lintas secara otomatis.

Pemeriksaan Kesehatan, Pemutus Sirkuit, dan Logika Percobaan Ulang adalah pelajaran AWS Solutions Architect gratis di CoddyKit. Ini adalah pelajaran 4 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar AWS Solutions Architect, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus AWS Solutions Architect mencakup 4 pelajaran total.

Mengapa Deteksi Kegagalan Otomatis Penting

Dalam sistem terdistribusi, komponen terus mengalami kegagalan — instans mengalami crash, partisi jaringan terjadi, dan layanan hilir menjadi kelebihan beban. Tanpa deteksi kegagalan otomatis, lalu lintas terus mengalir ke komponen yang gagal sehingga menyebabkan kegagalan berantai. AWS menyediakan beberapa lapisan pemeriksaan kesehatan: pemeriksaan kesehatan ELB mendeteksi instans yang tidak sehat, pemeriksaan kesehatan Route 53 mendeteksi Endpoint yang tidak sehat, dan Auto Scaling mengganti instans yang gagal. Pola pada tingkat aplikasi seperti pemutus sirkuit dan percobaan ulang melengkapi ketahanan sistem.

Pemeriksaan Health ELB

Pemeriksaan health Elastic Load Balancer secara berkala mengirimkan permintaan ke target yang terdaftar untuk menentukan apakah target tersebut sehat. Anda mengonfigurasi jalur pemeriksaan health (misalnya, /health), protokol, port, interval (default 30 detik), serta ambang batas sehat/tidak sehat (jumlah keberhasilan/kegagalan berturut-turut). Saat target gagal dalam pemeriksaan health, ELB berhenti merutekan lalu lintas ke target tersebut. Target dievaluasi ulang secara terus-menerus dan ditambahkan kembali setelah melewati ambang batas sehat.

# 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

Pemeriksaan Health Route 53

Pemeriksaan health Route 53 memantau titik akhir dari berbagai lokasi di seluruh dunia dan bekerja bersama perutean failover DNS. Ada tiga jenis: Pemeriksaan titik akhir secara langsung melakukan polling terhadap URL aplikasi Anda. Pemeriksaan terhitung menggabungkan beberapa pemeriksaan health turunan dengan logika AND/OR (berguna untuk pemantauan yang kompleks). Pemeriksaan alarm CloudWatch menyerahkan penentuan health kepada CloudWatch—berguna saat Anda tidak dapat membuka titik akhir health publik atau memerlukan keputusan health berbasis metrik.

# 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
  }'

Pemeriksaan Health Auto Scaling

Auto Scaling Groups dapat menggunakan dua jenis pemeriksaan health: pemeriksaan health EC2 mendeteksi kegagalan instance pada tingkat hypervisor (kegagalan pemeriksaan status instance). Pemeriksaan health ELB lebih memahami kondisi aplikasi—instance mungkin masih berjalan, tetapi menyajikan error, dan pemeriksaan health ELB dapat mendeteksinya. Anda dapat mengonfigurasi ASG agar menggunakan pemeriksaan health ELB sehingga kegagalan pada tingkat aplikasi juga memicu penggantian instance, bukan hanya kegagalan EC2 yang mendasarinya.

# 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

Pola Circuit Breaker

Circuit breaker adalah pola pada tingkat aplikasi yang mencegah kegagalan berantai dengan memantau pemanggilan ke layanan hilir dan menghentikan pemanggilan untuk sementara saat kegagalan melampaui ambang batas. Circuit memiliki tiga status: Closed (operasi normal), Open (kegagalan melampaui ambang batas, pemanggilan langsung diblokir), dan Half-Open (setelah timeout, sejumlah kecil pemanggilan uji diizinkan untuk memeriksa apakah layanan telah pulih). AWS App Mesh dan SDK aplikasi seperti Resilience4j menerapkan pola ini.

# 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

AWS App Mesh untuk Circuit Breaking

AWS App Mesh adalah service mesh yang menerapkan circuit breaking, percobaan ulang, dan kebijakan timeout pada tingkat infrastruktur tanpa perubahan kode. Anda menentukan kebijakan circuit breaker dalam konfigurasi virtual node atau virtual router. Saat layanan upstream menjadi tidak sehat, proxy Envoy milik App Mesh secara otomatis membuka circuit dan segera mengembalikan error, alih-alih menunggu timeout. Hal ini sangat bermanfaat dalam arsitektur layanan mikro yang berjalan di ECS atau EKS.

# 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
      }
    }]
  }
}

Logika Percobaan Ulang dan Backoff Eksponensial

Logika percobaan ulang secara otomatis mencoba kembali operasi yang gagal, tetapi logika percobaan ulang naif (percobaan ulang langsung dalam loop rapat) dapat memperburuk situasi kelebihan beban. Backoff eksponensial meningkatkan waktu tunggu antarpercobaan ulang secara eksponensial: 1d, 2d, 4d, 8d... Hal ini mengurangi beban pada layanan yang sedang kesulitan dan memberinya waktu untuk pulih. Jitter (pengacakan interval percobaan ulang) mencegah masalah kawanan yang menggelegar, yaitu keadaan ketika semua klien mencoba kembali secara bersamaan setelah gangguan singkat. AWS SDK secara otomatis menerapkan backoff eksponensial dengan 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)

Idempotensi untuk Percobaan Ulang yang Aman

Percobaan ulang hanya aman jika operasi bersifat idempoten—menjalankan operasi yang sama beberapa kali menghasilkan hasil yang sama. Misalnya, membuat objek S3 dengan key yang sama bersifat idempoten (hasilnya sama). Namun, menempatkan pesanan dua kali akan membuat dua pesanan—tidak idempoten. Rancang API agar idempoten dengan menggunakan key idempotensi yang diberikan client: server menyimpan hasil permintaan pertama dan mengembalikan hasil yang sama untuk permintaan berikutnya dengan key yang sama. DynamoDB, SQS, dan API Gateway mendukung pola key idempotensi.

# 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

Konfigurasi Timeout

Tanpa timeout eksplisit, layanan hilir yang lambat menyebabkan thread terblokir tanpa batas, menghabiskan connection pool, dan menimbulkan kegagalan berantai. Tetapkan timeout di setiap lapisan: timeout koneksi (waktu untuk membuat koneksi TCP), timeout pembacaan (waktu untuk menerima respons), dan timeout permintaan keseluruhan. Di AWS, konfigurasikan timeout idle ELB (default 60 d), timeout eksekusi Lambda (maksimal 15 mnt), dan timeout integrasi API Gateway (maksimal 29 d). Timeout memicu logika percobaan ulang atau circuit breaker Anda.

# 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 Queue untuk Pemrosesan yang Gagal

Saat pemrosesan pesan berulang kali gagal, Dead Letter Queue (DLQ) menampung pesan yang tidak dapat diproses setelah jumlah maksimum percobaan penerimaan. Konfigurasikan DLQ pada queue SQS dan pemetaan sumber peristiwa Lambda untuk mencegah pesan bermasalah memblokir queue tanpa batas. Pesan dalam DLQ dapat diperiksa, diputar ulang setelah bug diperbaiki, atau diarsipkan. DLQ merupakan komponen penting dalam arsitektur berbasis peristiwa yang tangguh.

# 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

Mengamati Kegagalan dengan CloudWatch

Pemeriksaan health dan circuit breaker yang efektif memerlukan pemantauan untuk memahami pola kegagalan. CloudWatch adalah lapisan observabilitas: buat alarm pada ELB UnHealthyHostCount (instance yang gagal dalam pemeriksaan health), tingkat Kesalahan Lambda, SQS NumberOfMessagesSentToDLQ (pesan yang masuk ke DLQ), dan RequestCountPerTarget grup target. Siapkan notifikasi SNS agar tim siaga Anda segera mendapat pemberitahuan saat pemeriksaan health otomatis mendeteksi penurunan kinerja.

# 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

Pemeriksaan Singkat

Uji pemahaman Anda tentang konsep AWS Solutions Architect (SAA-C03) dari pelajaran ini.

Rangkuman Pelajaran

Dalam pelajaran ini Anda mempelajari bahwa: pemeriksaan health ELB dan Route 53 mengotomatiskan deteksi kegagalan pada tingkat infrastruktur, circuit breaker mencegah kegagalan berantai dengan menghentikan pemanggilan ke layanan yang tidak sehat, dan backoff eksponensial dengan jitter membuat percobaan ulang aman saat terjadi beban. Dead Letter Queue menampung pesan yang gagal untuk diperiksa. Selanjutnya kita akan membahas RTO, RPO, dan tingkatan pemulihan bencana.

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Pemeriksaan Kesehatan, Pemutus Sirkuit, dan Logika Percobaan Ulang” gratis?

Ya — teks lengkap “Pemeriksaan Kesehatan, Pemutus Sirkuit, dan Logika Percobaan Ulang” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus AWS Solutions Architect, upgrade ke CoddyKit PRO. Kursus AWS Solutions Architect mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Pemeriksaan Kesehatan, Pemutus Sirkuit, dan Logika Percobaan Ulang”?

Gunakan pemeriksaan kesehatan ELB, pemeriksaan titik akhir Route 53, dan pemutus sirkuit tingkat aplikasi untuk mendeteksi kegagalan dan mengalihkan lalu lintas secara otomatis. Kamu berlatih AWS Solutions Architect dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai AWS Solutions Architect?

Tidak diperlukan pengalaman sebelumnya. AWS Solutions Architect di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 4 dari 4.

Berapa lama pelajaran “Pemeriksaan Kesehatan, Pemutus Sirkuit, dan Logika Percobaan Ulang” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran AWS Solutions Architect ini?

Ya. Setiap pelajaran AWS Solutions Architect menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

  1. HA vs Toleransi Kesalahan: Definisi dan Pertukaran
  2. Pola Multi-AZ untuk Layanan Stateful
  3. Aktif-Aktif dan Aktif-Pasif Multi-Region
  4. Pemeriksaan Kesehatan, Pemutus Sirkuit, dan Logika Percobaan Ulang
← Kembali ke AWS Solutions Architect