</>Học Dev
Bài học

Tuần 2 - Ngày 5: Performance Efficiency Pillar

Tuần 2 – Ngày 5

Tuần 2 - Ngày 5: Performance Efficiency Pillar

Mục tiêu học tập

  • Hiểu design principles của Performance Efficiency
  • Nắm vững các selection strategies cho resources
  • Biết cách optimize performance trên AWS

1. Định nghĩa Performance Efficiency Pillar

Khả năng sử dụng computing resources hiệu quả để đáp ứng system requirements và duy trì efficiency khi demand thay đổi và technologies evolve.

4 Focus Areas

  1. Selection
  2. Review
  3. Monitoring
  4. Trade-offs

2. Design Principles

1. Democratize advanced technologies

Trước:                          Sau (AWS):
- Hire ML experts               - Use SageMaker
- Build infrastructure          - Use managed services
- Maintain and update           - AWS handles it

→ Focus on business value, not infrastructure

2. Go global in minutes

Deploygloballywithafewclicks:┌─────────────┐┌─────────────┐┌─────────────┐│us-east-1││eu-west-1││ap-southeast││┌───┐││┌───┐││┌───┐│││App││││App││││App│││└───┘││└───┘││└───┘│└─────────────┘└─────────────┘└─────────────┘│││└───────────────┴───────────────┘│CloudFrontCDN│EndUsers

3. Use serverless architectures

  • No server management
  • Automatic scaling
  • Pay for value

4. Experiment more often

  • Easy to test new configurations
  • A/B testing
  • Compare performance

5. Consider mechanical sympathy

Hiểu cách resources hoạt động để sử dụng hiệu quả nhất

Ví dụ:

  • SSD vs HDD cho random I/O
  • GPU vs CPU cho ML workloads
  • Memory-optimized vs Compute-optimized

3. Compute Selection

Decision Tree

┌─────────────────┐│Computeneeded?│└────────┬────────┘│┌─────────────────┼─────────────────┐│││▼▼▼┌──────────┐┌──────────┐┌──────────┐│Virtual││Container││Serverless││Machines│││││└────┬─────┘└────┬─────┘└────┬─────┘│││▼▼▼EC2,LightsailECS,EKS,Lambda,FargateFargate

EC2 Instance Type Selection

WorkloadInstance FamilyWhy
Web serversM (General)Balanced
Batch processingC (Compute)High CPU
In-memory cacheR (Memory)High RAM
Data warehouseI (Storage)High I/O
Machine LearningP, GGPU
Variable loadT (Burstable)Cost-effective

Lambda Optimization

Memory↑=CPU↑=Cost↑=Duration↓┌─────────────────────────────────────────────┐│Memory:128MB→Duration:10s→Cost:$X││Memory:512MB→Duration:3s→Cost:$X││Memory:1024MB→Duration:1.5s→Cost:$X│└─────────────────────────────────────────────┘→Testtofindoptimalmemorysetting→UseAWSLambdaPowerTuning

4. Storage Selection

Storage Decision Matrix

CharacteristicS3EBSEFSFSx
AccessObjectBlockFileFile
Latencymssub-msmssub-ms
Durability11 9s99.999%11 9svaries
SharingUnlimitedSingle EC2Multi EC2Multi EC2

EBS Volume Types

PerformanceRequirements:HighIOPS(Database):├──io2BlockExpress:Upto256,000IOPS├──io2:Upto64,000IOPS└──io1:Upto64,000IOPSHighThroughput(BigData):├──st1:Upto500MB/s└──sc1:Upto250MB/sGeneralPurpose:└──gp3:Upto16,000IOPS,1,000MB/s

S3 Performance Optimization

Baseline: 3,500 PUT + 5,500 GET per prefix per second

Strategies:
1. Use multiple prefixes
   bucket/images/user1/
   bucket/images/user2/
   → Each prefix = separate throughput

2. S3 Transfer Acceleration
   → Use CloudFront edge for uploads

3. Multi-part upload
   → Parallel upload chunks

4. Byte-range fetches
   → Parallel download chunks

5. Database Selection

Database Decision Tree

┌─────────────────┐│DataStructure│└────────┬────────┘│┌───────────────────┼───────────────────┐│││▼▼▼RelationalKey-ValueDocument│││▼▼▼RDS,AuroraDynamoDBDocumentDB

Database Performance Patterns

PatternSolutionUse Case
Read replicasAurora, RDSRead-heavy
CachingElastiCacheFrequent reads
ShardingDynamoDBHigh throughput
Connection poolingRDS ProxyMany connections

Caching Strategy

┌─────────────────────────────────────────────┐│Cache-AsidePattern││││Application││││││1.Readfromcache││▼││┌────────┐Miss┌────────┐│││Cache│────────►│Database││││(Redis)│2.Read└───┬────┘││└────────┘│││▲│3.Returndata││││││└──────────────────┘││4.Storeincache│└─────────────────────────────────────────────┘

6. Network Selection

CloudFront Optimization

UserRequest│▼EdgeLocation(closest)│├──CacheHit?→Returncachedcontent│└──CacheMiss→OriginFetch│┌─────┴─────┐││S3OriginCustomOrigin(ALB,EC2)

Global Accelerator vs CloudFront

FeatureCloudFrontGlobal Accelerator
ContentStatic + DynamicTCP/UDP traffic
CachingYesNo
Use caseWeb contentGaming, IoT, VoIP
Entry pointsEdge locationsEdge locations

VPC Optimization

Within Region:
- Use VPC Endpoints for AWS services
- Avoid NAT Gateway when possible
- Use Placement Groups for low latency

Cross Region:
- Use Transit Gateway
- Consider AWS backbone vs internet

7. Monitoring Performance

Key Metrics

LayerMetrics
ComputeCPU, Memory, Network
StorageIOPS, Throughput, Latency
DatabaseConnections, Query time
NetworkLatency, Packet loss
ApplicationResponse time, Error rate

CloudWatch Dashboards

┌─────────────────────────────────────────────┐│PerformanceDashboard│├──────────────┬──────────────┬───────────────┤│EC2CPU│RDSIOPS│ALBLatency││████████│████│████████││70%│5000│150ms│├──────────────┼──────────────┼───────────────┤│Lambda│S3Requests│CloudFront││Duration││HitRatio││████│████████│████████████││200ms│10K/min│95%│└──────────────┴──────────────┴───────────────┘

8. Trade-offs

Performance vs Cost

Higher Performance = Higher Cost

Example decisions:
- Provisioned IOPS vs GP3
- Reserved capacity vs On-demand
- More memory (Lambda) vs longer duration

Consistency vs Latency

Strong Consistency:
- Higher latency
- Data always current
- Example: Financial transactions

Eventual Consistency:
- Lower latency
- Data may be stale
- Example: Social media feeds

9. Câu hỏi ôn tập

  1. "Mechanical sympathy" nghĩa là gì?

    Xem đáp án

    Hiểu cách hardware và software hoạt động ở low level để chọn đúng tools. Ví dụ: CPU cache lines → data locality (DynamoDB partition key design), disk seek patterns → sequential vs random I/O (HDD vs SSD vs NVMe), network latency → batch requests thay vì individual calls. Trong cloud: hiểu instance families (compute/memory/storage-optimized) để chọn đúng, hiểu storage I/O patterns để chọn EBS type đúng.

  2. Khi nào nên dùng io2 vs gp3 cho EBS?

    Xem đáp án

    io2: cần > 16,000 IOPS (gp3 max), hoặc sub-millisecond latency (io2 Block Express: ~0.1ms), hoặc cần Multi-Attach (io2 only), hoặc high-performance databases (Oracle, SQL Server). gp3: hầu hết production workloads, boot volumes, medium-high IOPS needs (3,000-16,000 IOPS configurable). gp3 rẻ hơn io2 đáng kể — dùng io2 chỉ khi performance requirements vượt gp3 capabilities.

  3. S3 có thể xử lý bao nhiêu requests per prefix?

    Xem đáp án

    3,500 PUT/COPY/POST/DELETE + 5,500 GET/HEAD per prefix per second. Prefix trong S3 là phần của key path trước slash cuối. Để scale beyond single prefix: sử dụng multiple prefixes (random prefix hoặc hash-based prefix) để distribute requests. Ví dụ: user-photos/2024/01/ và user-photos/2024/02/ là 2 prefixes riêng biệt — không share request limit.

  4. CloudFront khác Global Accelerator như thế nào?

    Xem đáp án

    CloudFront: caches content tại Edge Locations, tối ưu cho cacheable HTTP/HTTPS (static assets, video). Global Accelerator: anycast IPs, không cache, tối ưu cho dynamic/non-cacheable traffic (APIs, gaming, IoT, any TCP/UDP). GA cũng hỗ trợ HTTP nhưng không cache. Cả hai dùng AWS edge network — GA cho low-latency routing, CloudFront cho caching + edge compute. GA cung cấp static IPs (hữu ích cho firewall whitelisting).

  5. Cache-aside pattern hoạt động như thế nào?

    Xem đáp án

    Application code handle caching: (1) Read: check cache → if hit: trả từ cache, if miss: fetch từ DB → store vào cache với TTL → trả cho client. (2) Write: write vào DB → invalidate cache entry (hoặc update cache). Application tự quản lý cache — flexible nhưng thêm code. Ngược với Write-through (write tự động update cache) hay Read-through (cache tự fetch từ DB khi miss). Cache-aside phổ biến nhất với ElastiCache Redis.

10. Bài tập thực hành

  • Compare Lambda performance với different memory settings
  • Setup CloudFront distribution cho S3
  • Configure ElastiCache cluster
  • Create CloudWatch Dashboard cho performance metrics

Tài liệu tham khảo chính thức

Ngày tiếp theo: Cost Optimization Pillar