신뢰성 및 성능 효율성 원칙

# Reliability design principles:
# 1. Automatically recover from failure
# 2. Test recovery procedures
# 3. Scale horizontally to increase availability
# 4. Stop guessing capacity (use auto scaling)
# 5. Manage change in automation (IaC + CI/CD)

# Key AWS services for reliability:
# - Auto Scaling Groups
# - Elastic Load Balancing
# - Route 53 health checks
# - AWS Backup

# List service quotas for EC2
aws service-quotas list-service-quotas \
  --service-code ec2 \
  --query 'Quotas[?QuotaName==`Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances`]'

# Request quota increase
aws service-quotas request-service-quota-increase \
  --service-code ec2 \
  --quota-code L-1216C47A \
  --desired-value 500

# CloudWatch alarm to auto-recover a specific EC2 instance
aws cloudwatch put-metric-alarm \
  --alarm-name EC2-auto-recover \
  --metrics '[{"Id":"m1","MetricStat":{"Metric":{"Namespace":"AWS/EC2","MetricName":"StatusCheckFailed_System","Dimensions":[{"Name":"InstanceId","Value":"i-12345"}]},"Period":60,"Stat":"Maximum"}}]' \
  --comparison-operator GreaterThanThreshold \
  --threshold 0 \
  --evaluation-periods 2 \
  --alarm-actions 'arn:aws:automate:us-east-1:ec2:recover'

# Horizontal scaling: 10 t3.medium vs 1 r5.4xlarge
# 10 t3.medium:
#   - Failure of 1 = loss of 10% capacity
#   - ASG launches replacement automatically
#   - 9 instances absorb load during replacement

# 1 r5.4xlarge:
#   - Failure = 100% downtime until instance recovered
#   - Much higher RTO (new instance launch: 1-3 min)

# Prefer horizontal scaling for stateless tiers

# AWS FIS experiment: terminate random instance
aws fis create-experiment-template \
  --description 'Chaos: terminate 1 of 5 instances' \
  --targets '{"instanceTargets":{"resourceType":"aws:ec2:instance","selectionMode":"COUNT(1)","resourceTags":{"Env":"production"}}}' \
  --actions '{"terminateInstance":{"actionId":"aws:ec2:terminate-instances","targets":{"Instances":"instanceTargets"}}}' \
  --stop-conditions '[{"source":"aws:cloudwatch:alarm","value":"arn:aws:cloudwatch::123:alarm:high-error-rate"}]'

# Performance Efficiency areas:
# Selection:   Right compute, storage, database, network
# Review:      Continuously evaluate new services
# Monitoring:  CloudWatch metrics guide decisions
# Trade-offs:  Consistency vs performance, latency vs cost

# Example: choosing between services
# RDS vs DynamoDB vs Aurora vs ElastiCache
# → depends on access patterns, consistency needs, scale

# AWS Compute Optimizer: get right-size recommendations
aws compute-optimizer get-ec2-instance-recommendations \
  --instance-arns arn:aws:ec2:us-east-1:123:instance/i-12345

# Output shows:
# - Current instance utilisation (CPU, memory, network)
# - Recommended instance type
# - Estimated monthly savings
# - Performance risk of changing

# Lambda: match memory to actual usage
# Use Lambda Power Tuning tool for memory optimisation

# DAX cluster for DynamoDB microsecond latency
aws dax create-cluster \
  --cluster-name my-dax \
  --node-type dax.r6g.large \
  --replication-factor 3 \
  --iam-role-arn arn:aws:iam::123:role/DAXRole \
  --subnet-group my-dax-subnet-group

# Application connects to DAX endpoint
# Cache hits: microseconds
# Cache misses: fetches from DynamoDB and caches result

# EBS volume performance characteristics:
# gp3: 3,000-16,000 IOPS, 125-1,000 MB/s
# io2: 100-64,000 IOPS (up to 256k with Block Express)
# st1: 40-500 MB/s sequential throughput (HDD)
# sc1: 12-250 MB/s (cheapest, cold workloads)

# Create high-performance io2 volume
aws ec2 create-volume \
  --availability-zone us-east-1a \
  --volume-type io2 \
  --size 500 \
  --iops 50000

# CloudWatch: track API response latency percentiles
aws cloudwatch put-metric-alarm \
  --alarm-name 'API-P99-Latency' \
  --metric-name TargetResponseTime \
  --namespace AWS/ApplicationELB \
  --extended-statistic p99 \
  --dimensions Name=LoadBalancer,Value=app/my-alb/xxx \
  --period 60 \
  --evaluation-periods 5 \
  --threshold 2.0 \
  --comparison-operator GreaterThanThreshold

# Common performance vs cost trade-offs:
# Cache:         +Performance, +Cost, +Complexity
# Read Replicas: +Read performance, +Cost
# SSD vs HDD:    +IOPS, +Cost
# Multi-region:  -Latency for users, +Cost, +Complexity

# Common performance vs consistency trade-offs:
# DynamoDB eventually consistent reads: +Throughput, -Consistency
# Aurora Reader endpoint: +Read scale, potential replication lag