Classic Solutions Architecture — Theory (Bản gốc slide / Original slide)

Giới thiệu (Section Introduction)

Đây là phần ghép mọi công nghệ đã học lại thành kiến trúc thực tế — theo tác giả là phần hay nhất của khóa. Ta đi qua "hành trình tư duy của một Solutions Architect" qua các case study: WhatIsTheTime.com → MyClothes.com → MyWordPress.com → Instantiating apps quickly → Elastic Beanstalk.

1. WhatIsTheTime.com — Stateless Web App

Bài toán:

• WhatIsTheTime.com cho người dùng biết mấy giờ rồi
• Không cần database
• Bắt đầu nhỏ, chấp nhận downtime lúc đầu
• Muốn scale được cả dọc lẫn ngang, hướng tới no downtime

Ta sẽ đi từng bước để thấy kiến trúc "tiến hóa" ra sao.

The problem:

• WhatIsTheTime.com lets people know what time it is
• No database needed
• Start small, can accept downtime initially
• Want to scale both vertically and horizontally, aiming for no downtime

We'll evolve the architecture step by step.

1.1. Hành trình tiến hóa (The evolution)

1. Bắt đầu đơn giản: một Public EC2 duy nhất + Elastic IP → user gọi thẳng vào IP
2. Scale dọc (vertical): nâng instance lên loại lớn hơn (ví dụ M5) → có downtime khi nâng cấp
3. Scale ngang (horizontal): chạy nhiều EC2, mỗi cái một public IP
4. Thêm Route 53: tạo A record (api.whatisthetime.com) trỏ tới các IP, TTL 1 giờ
   • ⚠️ Vấn đề: khi một instance biến mất (INSTANCE IS GONE!), client vẫn còn cache DNS trỏ tới IP đã chết trong tối đa 1 giờ (TTL)
5. Thêm Load Balancer + Health Checks: đặt EC2 vào private subnet, siết Security Group (chỉ nhận traffic từ LB); Route 53 dùng Alias record trỏ tới LB → client chỉ biết LB, LB tự loại instance chết
6. Thêm Auto Scaling Group: tự tăng/giảm số instance theo tải
7. Multi-AZ: trải ASG + LB trên nhiều AZ để sống sót khi mất một AZ
8. Dự trữ capacity (reserve): đặt minimum capacity = số instance tối thiểu luôn chạy → có thể mua Reserved Instances cho phần này để tiết kiệm chi phí

1. Start simple: a single Public EC2 + an Elastic IP → users hit the IP directly
2. Scale vertically: upgrade to a bigger instance (e.g., M5) → downtime during the upgrade
3. Scale horizontally: run multiple EC2, each with its own public IP
4. Add Route 53: create an A record (api.whatisthetime.com) to the IPs, TTL 1 hour
   • ⚠️ Problem: when an instance is gone (INSTANCE IS GONE!), clients still cache DNS pointing to the dead IP for up to 1 hour (TTL)
5. Add a Load Balancer + Health Checks: move EC2 into a private subnet, tighten the Security Group (only LB traffic); Route 53 uses an Alias record to the LB → clients only know the LB, which removes dead instances
6. Add an Auto Scaling Group: scale instance count with load automatically
7. Multi-AZ: spread the ASG + LB across multiple AZ to survive an AZ loss
8. Reserve capacity: set a minimum capacity always running → buy Reserved Instances for it to save cost

Tóm tắt bài học WhatIsTheTime.com:

• Public vs Private IP và EC2 instance
• Elastic IP vs Route 53 vs Load Balancer
• Route 53: TTL, A record vs Alias record
• Quản lý EC2 thủ công vs Auto Scaling Group
• Multi-AZ để sống sót thảm họa
• ELB Health Checks
• Security Group Rules
• Dự trữ capacity để tiết kiệm chi phí

WhatIsTheTime.com recap:

• Public vs Private IP and EC2 instances
• Elastic IP vs Route 53 vs Load Balancers
• Route 53: TTL, A records vs Alias records
• Maintaining EC2 manually vs Auto Scaling Groups
• Multi-AZ to survive disasters
• ELB Health Checks
• Security Group Rules
• Reserving capacity for cost savings

2. MyClothes.com — Stateful Web App (3-tier)

Bài toán:

• MyClothes.com cho người dùng mua quần áo online → có giỏ hàng (shopping cart)
• Hàng trăm user đồng thời → cần scale ngang và giữ web app càng stateless càng tốt
• User không được mất giỏ hàng
• Thông tin user (địa chỉ…) phải lưu trong database

The problem:

• MyClothes.com lets people buy clothes online → there's a shopping cart
• Hundreds of concurrent users → must scale horizontally and keep the app as stateless as possible
• Users must not lose their cart
• User details (address…) must be stored in a database

2.1. Hành trình tiến hóa (The evolution)

1. Nền tảng: Auto Scaling Group Multi-AZ phía sau ELB
2. Stickiness (Session Affinity): bật ELB Stickiness → cùng một user luôn về cùng một instance → không mất giỏ hàng. Nhược điểm: mất một instance là mất session của user đó
3. User Cookies: gửi nội dung giỏ hàng trong web cookie → app stateless. Nhược điểm: HTTP request nặng hơn, rủi ro bảo mật (cookie có thể bị sửa → phải validate), cookie phải < 4KB
4. Server Session (khuyến nghị): chỉ gửi session_id trong cookie; dữ liệu session lưu/lấy từ ElastiCache (thay thế: DynamoDB)
5. Lưu user data trong RDS: lưu/lấy dữ liệu người dùng (địa chỉ, tên…) trong Amazon RDS
6. Scaling Reads:
   • Cách 1: RDS Read Replicas (master ghi, replica đọc)
   • Cách 2 (thay thế): ElastiCache Lazy Loading — cache hit đọc từ cache, cache miss đọc từ RDS
7. Multi-AZ sống sót thảm họa: bật ElastiCache Multi-AZ và RDS Multi-AZ
8. Security Groups tham chiếu lẫn nhau: LB mở HTTP/HTTPS ra 0.0.0.0/0; EC2 chỉ nhận từ SG của LB; ElastiCache & RDS chỉ nhận từ SG của EC2

1. Foundation: an Auto Scaling Group Multi-AZ behind an ELB
2. Stickiness (Session Affinity): enable ELB Stickiness → the same user always hits the same instance → cart preserved. Downside: losing an instance loses that user's session
3. User Cookies: send the cart content in web cookies → app is stateless. Downsides: heavier HTTP requests, security risk (cookies can be altered → must validate), cookies must be < 4KB
4. Server Session (recommended): send only a session_id cookie; session data stored/retrieved from ElastiCache (alternative: DynamoDB)
5. Store user data in RDS: store/retrieve user data (address, name…) in Amazon RDS
6. Scaling Reads:
   • Option 1: RDS Read Replicas (master writes, replicas read)
   • Option 2 (alternative): ElastiCache Lazy Loading — cache hit reads from cache, cache miss reads from RDS
7. Multi-AZ to survive disasters: enable ElastiCache Multi-AZ and RDS Multi-AZ
8. Security Groups referencing each other: LB opens HTTP/HTTPS to 0.0.0.0/0; EC2 only from the LB's SG; ElastiCache & RDS only from the EC2's SG

Tóm tắt bài học MyClothes.com — kiến trúc 3-tier:

• ELB sticky sessions
• Web cookies để lưu giỏ hàng, giúp app stateless
• ElastiCache: lưu session (thay thế: DynamoDB), cache dữ liệu từ RDS, Multi-AZ
• RDS: lưu user data, Read Replicas để scale đọc, Multi-AZ cho DR
• Bảo mật chặt bằng các Security Group tham chiếu lẫn nhau

MyClothes.com recap — 3-tier architecture:

• ELB sticky sessions
• Web cookies to store the cart, keeping the app stateless
• ElastiCache: store sessions (alt: DynamoDB), cache RDS data, Multi-AZ
• RDS: store user data, Read Replicas for read scaling, Multi-AZ for DR
• Tight security with security groups referencing each other

3. MyWordPress.com — Stateful Web App + Storage

Bài toán:

• Tạo website WordPress scale được hoàn toàn
• Website phải truy cập và hiển thị đúng ảnh (picture uploads)
• User data và nội dung blog lưu trong MySQL database

The problem:

• Build a fully scalable WordPress website
• The site must access and correctly display picture uploads
• User data and blog content stored in a MySQL database

3.1. Hành trình tiến hóa (The evolution)

1. RDS layer: dùng RDS Multi-AZ cho MySQL
2. Scale với Aurora: chuyển sang Aurora MySQL để có Multi-AZ + Read Replicas dễ dàng
3. Lưu ảnh với EBS: gắn EBS Volume vào một instance
   • ⚠️ EBS chỉ gắn vào một instance trong một AZ → nhiều instance/nhiều AZ không chia sẻ được ảnh → cách này chỉ hợp cho ứng dụng một instance (single instance)
4. Lưu ảnh với EFS (khuyến nghị cho phân tán): dùng EFS — network file system dùng chung, gắn vào nhiều instance qua ENI ở nhiều AZ → mọi instance thấy cùng bộ ảnh

1. RDS layer: use RDS Multi-AZ for MySQL
2. Scale with Aurora: move to Aurora MySQL for easy Multi-AZ + Read Replicas
3. Store images with EBS: attach an EBS Volume to an instance
   • ⚠️ EBS attaches to one instance in one AZ → multiple instances/AZs can't share images → only fits a single-instance application
4. Store images with EFS (recommended for distributed): use EFS — a shared network file system, mounted on many instances via ENI across multiple AZ → every instance sees the same images

Tóm tắt bài học MyWordPress.com:

• Aurora để có Multi-AZ và Read Replicas dễ dàng
• Lưu dữ liệu trong EBS → ứng dụng một instance
• Lưu dữ liệu trong EFS → ứng dụng phân tán (nhiều instance/AZ)

MyWordPress.com recap:

• Aurora for easy Multi-AZ and Read Replicas
• Store data in EBS → single-instance application
• Store data in EFS → distributed application (many instances/AZ)

4. Instantiating Applications quickly

Khi launch một full stack (EC2, EBS, RDS), việc cài app, nạp dữ liệu ban đầu, cấu hình, khởi động rất tốn thời gian. Ta tận dụng cloud để tăng tốc:

• EC2 Instances:
  • Golden AMI: cài sẵn app + dependencies + OS config vào AMI, rồi launch instance từ Golden AMI
  • Bootstrap bằng User Data: cấu hình động lúc khởi động bằng script User Data
  • Hybrid: kết hợp Golden AMI + User Data (chính là cách Elastic Beanstalk làm)
• RDS Databases: restore từ snapshot → DB đã có sẵn schema và dữ liệu
• EBS Volumes: restore từ snapshot → đĩa đã format sẵn và có dữ liệu

Launching a full stack (EC2, EBS, RDS) — installing apps, loading initial data, configuring, launching — takes time. Use the cloud to speed it up:

• EC2 Instances:
  • Golden AMI: pre-install app + dependencies + OS config into an AMI, then launch from it
  • Bootstrap with User Data: dynamic configuration at boot via User Data scripts
  • Hybrid: mix Golden AMI + User Data (exactly what Elastic Beanstalk does)
• RDS Databases: restore from a snapshot → DB already has schema and data
• EBS Volumes: restore from a snapshot → disk already formatted with data

4.1. Kiến trúc điển hình: Web App 3-tier (Typical 3-tier)

Mô hình chuẩn: Route 53 + ELB (public subnet) → ASG các EC2 (private subnet) → ElastiCache + RDS (data subnet). Session/cache ở ElastiCache, dữ liệu bền ở RDS.

The standard shape: Route 53 + ELB (public subnet) → ASG of EC2 (private subnet) → ElastiCache + RDS (data subnet). Sessions/cache in ElastiCache, durable data in RDS.

5. Elastic Beanstalk

Vấn đề của developer trên AWS: quản lý hạ tầng, deploy code, cấu hình DB/load balancer, lo scaling… Nhưng hầu hết web app có cùng kiến trúc (ALB + ASG), và điều dev muốn chỉ là code chạy được — nhất quán qua nhiều môi trường.

Elastic Beanstalk — Overview:

• Là góc nhìn thiên về developer để deploy ứng dụng lên AWS
• Dùng lại đúng các thành phần đã học: EC2, ASG, ELB, RDS…
• Là managed service: tự lo provisioning, load balancing, scaling, health monitoring, cấu hình instance… → dev chỉ chịu trách nhiệm phần code
• Vẫn toàn quyền kiểm soát cấu hình
• Beanstalk miễn phí — chỉ trả tiền cho instance bên dưới

Developer problems on AWS: managing infrastructure, deploying code, configuring DBs/load balancers, scaling concerns… But most web apps share the same architecture (ALB + ASG), and all developers want is their code to run — consistently across environments.

Elastic Beanstalk — Overview:

• A developer-centric view of deploying an application on AWS
• Reuses the exact components we've seen: EC2, ASG, ELB, RDS…
• A managed service: handles provisioning, load balancing, scaling, health monitoring, instance configuration… → the developer only owns the code
• You still have full control over the configuration
• Beanstalk is free — you only pay for the underlying instances

5.1. Components & Platforms

• Application: tập hợp các thành phần Beanstalk (environments, versions, configurations…)
• Application Version: một phiên bản (iteration) của code
• Environment:
  • Tập hợp tài nguyên AWS chạy một application version tại một thời điểm
  • Có 2 loại tier: Web Server Environment Tier & Worker Environment Tier
  • Có thể tạo nhiều environment (dev, test, prod…)
• Vòng đời: Create Application → Upload Version → Launch Environment → Manage Environment (deploy/update version)
• Nền tảng hỗ trợ: Go, Java SE, Java + Tomcat, .NET (Linux/Windows), Node.js, PHP, Python, Ruby, Packer Builder, Docker (Single/Multi-container/Preconfigured)

• Application: a collection of Beanstalk components (environments, versions, configurations…)
• Application Version: an iteration of your code
• Environment:
  • A collection of AWS resources running one application version at a time
  • Two tiers: Web Server Environment Tier & Worker Environment Tier
  • You can create multiple environments (dev, test, prod…)
• Lifecycle: Create Application → Upload Version → Launch Environment → Manage Environment (deploy/update version)
• Supported platforms: Go, Java SE, Java + Tomcat, .NET (Linux/Windows), Node.js, PHP, Python, Ruby, Packer Builder, Docker (Single/Multi-container/Preconfigured)

5.2. Web Server Tier vs. Worker Tier

• Web Server Tier: phục vụ user qua ELB + ASG (HTTP), có URL kiểu myapp.region.elasticbeanstalk.com
• Worker Tier: các EC2 kéo (pull) message từ SQS Queue để xử lý nền
  • Scale theo số lượng message trong SQS
  • Web Server Tier có thể push message vào SQS cho Worker Tier xử lý

• Web Server Tier: serves users via an ELB + ASG (HTTP), with a URL like myapp.region.elasticbeanstalk.com
• Worker Tier: EC2 that pull messages from an SQS Queue for background processing
  • Scales on the number of SQS messages
  • The Web Server Tier can push messages to SQS for the Worker Tier to process

5.3. Deployment Modes

Mode	Phù hợp	Kiến trúc
Single Instance	Dev	1 EC2 + Elastic IP, RDS Master trong một AZ
High Availability với Load Balancer	Prod	ALB + Auto Scaling Group qua nhiều AZ, RDS Master + Standby (Multi-AZ)

Mode	Best for	Architecture
Single Instance	Dev	1 EC2 + Elastic IP, RDS Master in one AZ
High Availability with Load Balancer	Prod	ALB + Auto Scaling Group across AZs, RDS Master + Standby (Multi-AZ)