สถานการณ์สถาปัตยกรรมที่ยืดหยุ่นและพร้อมใช้งานสูง
ฝึกทำสถานการณ์การสลับระบบฐานข้อมูลแบบหลาย AZ การปรับขนาดอัตโนมัติเมื่อมีการรับส่งข้อมูลพุ่งสูง และการสลับระบบตามการตรวจสอบสุขภาพของ Route 53 เพื่อเสริมความเข้าใจด้านความน่าเชื่อถือ
สถานการณ์สถาปัตยกรรมที่ยืดหยุ่นและพร้อมใช้งานสูง เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
สถานการณ์ที่ 1: เว็บแอปพลิเคชันแบบหลาย AZ
สถานการณ์: บริษัทแห่งหนึ่งใช้งานเว็บแอปพลิเคชันแบบสองระดับ (ALB → EC2 → RDS) และต้องการกำจัดจุดล้มเหลวเพียงจุดเดียวทั้งหมดภายใน AWS Region วิธีแก้ไข: ติดตั้งอินสแตนซ์ EC2 ใน กลุ่มปรับขนาดอัตโนมัติที่ครอบคลุมโซนความพร้อมใช้งานอย่างน้อย 2 แห่ง โดยมี ALB อยู่ด้านหน้า (ซึ่งเป็นแบบหลาย AZ โดยธรรมชาติ) เปิดใช้ RDS Multi-AZ เพื่อจำลองข้อมูลไปยังระบบสำรองแบบซิงโครนัส กำหนดค่า การตรวจสอบสถานะบน ALB เพื่อเปลี่ยนเส้นทางออกจากอินสแตนซ์ที่ไม่พร้อมใช้งานโดยอัตโนมัติ ด้วยสถาปัตยกรรมนี้ หาก AZ ใด AZ หนึ่งสูญหาย จะเกิดการสลับระบบอัตโนมัติในทุกระดับ
# Create RDS with Multi-AZ enabled
aws rds create-db-instance \
--db-instance-identifier prod-mysql \
--db-instance-class db.t3.large \
--engine mysql \
--multi-az \
--master-username admin \
--master-user-password Pass123! \
--allocated-storage 100
# Create ASG across 3 AZs
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name web-asg \
--min-size 2 --max-size 10 --desired-capacity 3 \
--availability-zones us-east-1a us-east-1b us-east-1c \
--target-group-arns arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/web-tg/abcสถานการณ์ที่ 2: การเพิ่มความสามารถในการอ่าน RDS ภายใต้โหลดสูง
สถานการณ์: อินสแตนซ์ RDS ของแอปพลิเคชันอีคอมเมิร์ซแห่งหนึ่งกำลังถึงขีดจำกัด CPU ในช่วงเวลาใช้งานสูงสุด เนื่องจากคำสั่งวิเคราะห์ที่เน้นการอ่านจากทีมข่าวกรองธุรกิจ วิธีแก้ไข: สร้าง RDS Read Replicas และกำหนดให้คำสั่ง BI ใช้ปลายทางของแบบจำลอง Read Replicas ใช้การจำลองแบบไม่พร้อมกัน ซึ่งยอมรับความล่าช้าเล็กน้อยได้สำหรับงานวิเคราะห์ วิธีนี้ช่วยลดภาระการอ่านจากอินสแตนซ์ RDS หลัก ซึ่งสงวนไว้สำหรับการเขียนและการอ่านของแอปพลิเคชัน หากเป็นงานที่เน้นการอ่านอย่างมาก ให้เพิ่มชั้น ElastiCache ไว้ด้านหน้า RDS เพื่อเก็บข้อมูลที่มีการเข้าถึงบ่อย
# Create a Read Replica from the primary RDS instance
aws rds create-db-instance-read-replica \
--db-instance-identifier prod-mysql-replica \
--source-db-instance-identifier prod-mysql \
--db-instance-class db.t3.large \
--availability-zone us-east-1b
# Application code: use replica endpoint for reads
# Primary endpoint: prod-mysql.cluster.us-east-1.rds.amazonaws.com (writes)
# Replica endpoint: prod-mysql-replica.xyz.us-east-1.rds.amazonaws.com (reads)สถานการณ์ที่ 3: การปรับขนาดอัตโนมัติเมื่อ CPU เพิ่มขึ้น
สถานการณ์: API แบบไร้สถานะทำงานบน EC2 โดยมี ALB อยู่ด้านหน้า การใช้งาน CPU เพิ่มขึ้นถึง 90% ในเวลาทำการและลดลงเกือบเป็นศูนย์ในเวลากลางคืน บริษัทต้องการให้กลุ่มอินสแตนซ์ปรับขนาดโดยอัตโนมัติ วิธีแก้ไข: กำหนดค่า กลุ่มปรับขนาดอัตโนมัติ พร้อม นโยบายการปรับขนาดแบบติดตามเป้าหมาย โดยกำหนดเป้าหมายการใช้งาน CPU เฉลี่ยที่ 60% ASG จะเพิ่มอินสแตนซ์โดยอัตโนมัติเมื่อ CPU เกิน 60% และนำอินสแตนซ์ออกเมื่อค่าลดลงต่ำกว่าเป้าหมาย เพิ่ม การดำเนินการปรับขนาดตามกำหนดเวลา เพื่อเตรียมความจุขั้นต่ำล่วงหน้าก่อนเริ่มเวลาทำการ ซึ่งช่วยป้องกันความล่าช้าเมื่อปริมาณการใช้งานเพิ่มขึ้นในตอนเช้า
# Target tracking policy: scale to keep CPU at 60%
aws autoscaling put-scaling-policy \
--auto-scaling-group-name api-asg \
--policy-name cpu-tracking \
--policy-type TargetTrackingScaling \
--target-tracking-configuration '{
"PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
"TargetValue": 60.0,
"DisableScaleIn": false
}'
# Scheduled action: pre-warm to 5 instances at 8 AM weekdays
aws autoscaling put-scheduled-update-group-action \
--auto-scaling-group-name api-asg \
--scheduled-action-name morning-scale-out \
--recurrence '0 8 * * MON-FRI' \
--min-size 5สถานการณ์ที่ 4: การสลับไปยังไซต์ DR ด้วย Route 53
สถานการณ์: บริษัทแห่งหนึ่งใช้งานเว็บแอปพลิเคชันหลักใน us-east-1 และต้องการสลับไปยังหน้าบำรุงรักษาแบบคงที่ที่โฮสต์บน S3 ใน us-west-2 หากระบบหลักไม่พร้อมใช้งาน วิธีแก้ไข: สร้าง การตรวจสอบสถานะของ Route 53 เพื่อตรวจสอบปลายทาง ALB หลัก สร้างระเบียน Route 53 สองรายการพร้อม นโยบายการกำหนดเส้นทางแบบสลับระบบ: ระเบียนหลักชี้ไปยัง ALB (เชื่อมโยงกับการตรวจสอบสถานะ) และระเบียนสำรองชี้ไปยังไซต์แบบคงที่บน S3 หากการตรวจสอบสถานะล้มเหลว Route 53 จะส่งการตอบสนอง DNS ของระเบียนสำรองโดยอัตโนมัติ
# Create Route 53 health check for primary ALB
aws route53 create-health-check \
--caller-reference $(date +%s) \
--health-check-config '{
"Type": "HTTPS",
"FullyQualifiedDomainName": "app.example.com",
"Port": 443,
"RequestInterval": 30,
"FailureThreshold": 3
}'
# Primary failover record (associated with health check)
# Secondary failover record -> S3 static website endpoint
# Route 53 automatically switches if health check failsสถานการณ์ที่ 5: การแยกส่วนด้วย SQS เพื่อความทนทาน
สถานการณ์: Backend สำหรับประมวลผลคำสั่งซื้อเขียนข้อมูลลงฐานข้อมูล แต่บางครั้งฐานข้อมูลไม่พร้อมใช้งานระหว่างช่วงบำรุงรักษา ทำให้คำสั่งซื้อสูญหาย วิธีแก้ไข: วาง คิว SQS ไว้ระหว่าง Frontend (ซึ่งรับคำสั่งซื้อ) และ Backend (ซึ่งประมวลผลคำสั่งซื้อ) คำสั่งซื้อจะถูกใส่ลงในคิวทันที ทำให้ลูกค้าได้รับการยืนยันในทันที ผู้ปฏิบัติงานเบื้องหลังจะดึงคำสั่งซื้อจากคิวและประมวลผลเมื่อฐานข้อมูลพร้อมใช้งาน ระหว่างการบำรุงรักษา คำสั่งซื้อจะสะสมอยู่ในคิวแทนที่จะถูกทิ้ง ซึ่งช่วยเพิ่มความทนทานด้วยการแยกส่วนแบบไม่พร้อมกัน
# SQS-based order decoupling pattern
# 1. Frontend: PUT order to SQS (returns 200 immediately to customer)
aws sqs send-message \
--queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
--message-body '{"orderId": "ORD-123", "items": [...]}'
# 2. Backend worker: polls SQS when DB is available
aws sqs receive-message \
--queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
--max-number-of-messages 10
# 3. On success: delete message from queue
# 4. On failure: visibility timeout expires -> message reappears for retry
# 5. After max retries: message goes to Dead Letter Queue (DLQ)สถานการณ์ที่ 6: Pilot Light DR
สถานการณ์: บริษัทแห่งหนึ่งต้องการโซลูชันการกู้คืนจากภัยพิบัติที่มี RPO 1 ชั่วโมงและ RTO 4 ชั่วโมง ภายใต้งบประมาณระดับปานกลาง วิธีแก้ไข: ใช้กลยุทธ์ DR แบบ Pilot Light จำลองฐานข้อมูลหลักไปยัง DR Region ด้วย RDS Cross-Region Read Replica เซิร์ฟเวอร์แอปพลิเคชันจะไม่ทำงานใน DR Region ระหว่างการทำงานปกติ โดยจะเปิดใช้งานไว้เพียงส่วนแกนหลักขั้นต่ำ (ฐานข้อมูล) เท่านั้น เมื่อเกิดภัยพิบัติ ให้เลื่อนระดับ Read Replica เป็นระบบอิสระ และเปิดใช้เซิร์ฟเวอร์แอปพลิเคชันจาก AMIs ที่สร้างไว้ล่วงหน้าด้วย CloudFormation ค่า RTO อยู่ในระดับชั่วโมงแทนที่จะเป็นนาที เนื่องจากต้องเปิดใช้เซิร์ฟเวอร์ก่อน
# Pilot Light: replicate database to DR Region
aws rds create-db-instance-read-replica \
--db-instance-identifier prod-mysql-dr \
--source-db-instance-identifier prod-mysql \
--db-instance-class db.t3.large \
--source-region us-east-1 \
--destination-region us-west-2
# During disaster: promote replica in us-west-2 to standalone
aws rds promote-read-replica \
--db-instance-identifier prod-mysql-dr \
--region us-west-2
# Then launch app servers from AMIs using CloudFormation in us-west-2สถานการณ์ที่ 7: คิวจดหมายตาย SQS สำหรับข้อความที่ล้มเหลว
สถานการณ์: ข้อความในคิว SQS ล้มเหลวในการประมวลผลซ้ำแล้วซ้ำเล่าเนื่องจากข้อบกพร่องใน Lambda ที่รับข้อความ ข้อความเหล่านี้ปรากฏขึ้นอีกครั้งและขัดขวางคิวอยู่เรื่อย ๆ วิธีแก้ไข: กำหนดค่า คิวจดหมายตาย (DLQ) ให้กับคิวหลัก หลังจากข้อความล้มเหลวในการประมวลผลตามจำนวนครั้งที่กำหนดค่าได้ (maxReceiveCount) SQS จะย้ายข้อความนั้นไปยัง DLQ โดยอัตโนมัติ แทนที่จะส่งข้อความเดิมซ้ำตลอดไป วิธีนี้ช่วยเปิดทางให้ข้อความที่ปกติในคิวหลัก กำหนด การแจ้งเตือน CloudWatch บนเมตริก ApproximateNumberOfMessagesVisible ของ DLQ เพื่อแจ้งเตือนทีมวิศวกรรมเมื่อมีข้อความสะสมใน DLQ
# Set redrive policy to move failed messages to DLQ after 3 attempts
aws sqs set-queue-attributes \
--queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
--attributes '{
"RedrivePolicy": "{\"deadLetterTargetArn\": \"arn:aws:sqs:us-east-1:123:orders-dlq\", \"maxReceiveCount\": \"3\"}"
}'
# CloudWatch alarm on DLQ depth
aws cloudwatch put-metric-alarm \
--alarm-name orders-dlq-depth \
--metric-name ApproximateNumberOfMessagesVisible \
--namespace AWS/SQS \
--dimensions Name=QueueName,Value=orders-dlq \
--threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
--evaluation-periods 1 --period 60 --statistic Sumสถานการณ์ที่ 8: ฐานข้อมูล Aurora Global
สถานการณ์: บริษัทแห่งหนึ่งดำเนินงานใน US และยุโรป ผู้ใช้ในยุโรปพบความล่าช้าในการอ่านฐานข้อมูลสูง เนื่องจาก RDS อยู่ใน us-east-1 วิธีแก้ไข: ใช้ Amazon Aurora Global Database คลัสเตอร์หลักอยู่ใน us-east-1 และเพิ่มคลัสเตอร์รองแบบอ่านอย่างเดียวใน eu-west-1 Aurora จำลองข้อมูลไปยัง Region รองด้วย ความล่าช้าทั่วไปต่ำกว่า 1 วินาที โดยใช้การจำลองในระดับพื้นที่จัดเก็บ ผู้ใช้ในยุโรปอ่านข้อมูลจากคลัสเตอร์รองใน eu-west-1 หากเกิดภัยพิบัติระดับ Region ระบบสามารถเลื่อนระดับคลัสเตอร์รองเป็นคลัสเตอร์หลักได้ภายในเวลาไม่ถึง 1 นาที ซึ่งเป็น RTO ที่ดีที่สุดในบรรดาตัวเลือกฐานข้อมูลหลาย Region ของ AWS
# Add a secondary region to an Aurora Global Database
aws rds create-global-cluster \
--global-cluster-identifier prod-global \
--source-db-cluster-identifier arn:aws:rds:us-east-1:123:cluster:prod-aurora
# Add secondary Region cluster
aws rds create-db-cluster \
--db-cluster-identifier prod-aurora-eu \
--engine aurora-postgresql \
--global-cluster-identifier prod-global \
--region eu-west-1สถานการณ์ที่ 9: บริการ ECS พร้อม ALB และการปรับขนาดอัตโนมัติ
สถานการณ์: บริการ API แบบคอนเทนเนอร์ที่ทำงานบน ECS Fargate ต้องปรับขนาดตามการใช้งาน CPU และต้องทำงานต่อได้เมื่อ AZ ล้มเหลว วิธีแก้ไข: ลงทะเบียนบริการ ECS กับ กลุ่มเป้าหมายของ Application Load Balancer เพื่อกระจายการรับส่งข้อมูลไปยังงานที่กำลังทำงาน วางงานไว้ในหลาย AZ โดยระบุซับเน็ตหลายรายการในการกำหนดค่าบริการ กำหนดค่า การปรับขนาดอัตโนมัติของบริการ ECS พร้อมนโยบายการติดตามเป้าหมายตามการใช้งาน CPU ของบริการ ECS เพื่อเพิ่มหรือลดจำนวนงานโดยอัตโนมัติ หาก AZ ล้มเหลว ECS จะเริ่มงานที่ล้มเหลวใหม่ใน AZ ที่ยังพร้อมใช้งาน
# Create ECS Fargate service with ALB and multi-AZ placement
aws ecs create-service \
--cluster prod-cluster \
--service-name api-service \
--task-definition api-task:5 \
--desired-count 3 \
--launch-type FARGATE \
--network-configuration '{
"awsvpcConfiguration": {
"subnets": ["subnet-1a", "subnet-1b", "subnet-1c"],
"securityGroups": ["sg-app"],
"assignPublicIp": "DISABLED"
}
}' \
--load-balancers '[{
"targetGroupArn": "arn:...:targetgroup/api-tg/abc",
"containerName": "api",
"containerPort": 8080
}]'สถานการณ์ที่ 10: การสลับระบบด้วยการตรวจสอบสถานะของ Route 53
สถานการณ์: บริษัทแห่งหนึ่งใช้งานอินสแตนซ์ EC2 สองรายการใน AZ ที่แตกต่างกัน โดยให้บริการโดเมนเดียวกัน บริษัทต้องการให้ Route 53 หยุดส่งการรับส่งข้อมูลไปยังอินสแตนซ์ที่ไม่พร้อมใช้งานโดยอัตโนมัติ วิธีแก้ไข: ใช้ การกำหนดเส้นทางแบบถ่วงน้ำหนักของ Route 53 โดยใช้น้ำหนักเท่ากัน (50/50) และเชื่อมโยง การตรวจสอบสถานะปลายทาง กับแต่ละระเบียน เมื่อ Route 53 ตรวจพบปลายทางที่ไม่พร้อมใช้งาน ระบบจะนำระเบียนนั้นออกจากการตอบสนอง DNS และส่งการรับส่งข้อมูล 100% ไปยังปลายทางที่พร้อมใช้งาน เมื่ออินสแตนซ์กลับมาทำงานและการตรวจสอบสถานะผ่านอีกครั้ง Route 53 จะปรับสมดุลการรับส่งข้อมูลโดยอัตโนมัติ โดยไม่ต้องเปลี่ยนแปลง DNS ด้วยตนเอง
# Route 53 weighted record with health check association
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890 \
--change-batch '{
"Changes": [{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "app.example.com",
"Type": "A",
"SetIdentifier": "instance-1a",
"Weight": 50,
"HealthCheckId": "hc-abc123",
"TTL": 30,
"ResourceRecords": [{"Value": "10.0.1.10"}]
}
}]
}'สถานการณ์ที่ 11: DynamoDB Global Tables สำหรับ HA หลาย Region
สถานการณ์: แอปพลิเคชันเกมบนอุปกรณ์เคลื่อนที่ต้องสามารถอ่านและเขียนข้อมูลผู้เล่นได้ด้วยความล่าช้าต่ำจากทั้ง us-east-1 และ ap-southeast-1 ตาราง DynamoDB ใน Region เดียวทำให้ผู้ใช้ในเอเชียพบความล่าช้าสูง วิธีแก้ไข: เปิดใช้ DynamoDB Global Tables Global Tables จะจำลองข้อมูลข้าม Regions ที่ระบุโดยอัตโนมัติด้วย การจำลองแบบหลายตัวหลัก ซึ่งทำให้ทุก Region รับการเขียนข้อมูลได้ ผู้ใช้ในเอเชียจะเขียนและอ่านข้อมูลจากแบบจำลองใน ap-southeast-1 ด้วยความล่าช้าในพื้นที่ (~5ms) Global Tables จัดการแก้ไขข้อขัดแย้งด้วยกลยุทธ์ “ผู้เขียนล่าสุดชนะ” โดยอ้างอิงการประทับเวลา RTO เมื่อ Region ล้มเหลวทั้งหมดใกล้เคียงศูนย์ เพราะระบบเพียงเปลี่ยนเส้นทางการรับส่งข้อมูลไปยัง Region ที่ยังทำงานอยู่
# Convert a DynamoDB table to a Global Table
# (table must exist in all target Regions first)
aws dynamodb create-global-table \
--global-table-name PlayerData \
--replication-group '[{"RegionName": "us-east-1"}, {"RegionName": "ap-southeast-1"}]'
# Add another Region to an existing Global Table
aws dynamodb update-global-table \
--global-table-name PlayerData \
--replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]'ตรวจสอบอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิดของ AWS Solutions Architect (SAA-C03) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้ฝึกทำความเข้าใจสถานการณ์เกี่ยวกับ: Multi-AZ ASG และ RDS สำหรับ HA ภายใน Region, การกำหนดเส้นทางแบบสลับระบบของ Route 53 สำหรับ DR ข้าม Region, SQS DLQ เพื่อแยกข้อความที่ล้มเหลวโดยไม่ขัดขวางคิว และ Aurora Global Database สำหรับเพิ่มความสามารถในการอ่านข้าม Region และการสลับระบบด้วย RTO ต่ำกว่าหนึ่งนาที ต่อไปเราจะศึกษาสถานการณ์เกี่ยวกับสถาปัตยกรรมประสิทธิภาพสูงและประหยัดค่าใช้จ่าย
คำถามที่พบบ่อย
บทเรียน “สถานการณ์สถาปัตยกรรมที่ยืดหยุ่นและพร้อมใช้งานสูง” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “สถานการณ์สถาปัตยกรรมที่ยืดหยุ่นและพร้อมใช้งานสูง” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “สถานการณ์สถาปัตยกรรมที่ยืดหยุ่นและพร้อมใช้งานสูง”
ฝึกทำสถานการณ์การสลับระบบฐานข้อมูลแบบหลาย AZ การปรับขนาดอัตโนมัติเมื่อมีการรับส่งข้อมูลพุ่งสูง และการสลับระบบตามการตรวจสอบสุขภาพของ Route 53 เพื่อเสริมความเข้าใจด้านความน่าเชื่อถือ คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cloud & IT Cert Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน
บทเรียน “สถานการณ์สถาปัตยกรรมที่ยืดหยุ่นและพร้อมใช้งานสูง” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม
ได้ บทเรียน Cloud & IT Cert Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- สถานการณ์สถาปัตยกรรมที่ปลอดภัย
- สถานการณ์สถาปัตยกรรมที่ยืดหยุ่นและพร้อมใช้งานสูง
- สถานการณ์ประสิทธิภาพสูงและการเพิ่มประสิทธิภาพต้นทุน
- ข้อสอบจำลองฉบับสั้นแบบเต็มชุดจากหลายหมวด