Classic Solutions Architecture
WhatIsTheTime.com — Stateless Web App
วิวัฒนาการของ architecture จากง่ายไปซับซ้อน:
Phase 1: Single EC2 + Elastic IP
- เริ่มจาก EC2 ตัวเดียว กำหนด Elastic IP
- ปัญหา: ถ้า instance มีปัญหา ทุกอย่างหยุด
Phase 2: Vertical Scaling
- เปลี่ยน instance type เป็นตัวใหญ่ขึ้น
- ปัญหา: ต้อง downtime ระหว่างเปลี่ยน
Phase 3: Horizontal Scaling + DNS
- เพิ่มหลาย EC2, ใช้ Route 53 (A Record) ชี้ไปหลาย IPs
- ปัญหา: DNS TTL ทำให้ user ยังเชื่อมกับ instance เก่า
Phase 4: ELB + ASG
- ใช้ Elastic Load Balancer กระจาย traffic
- ใช้ Auto Scaling Group เพิ่ม/ลด instances อัตโนมัติ
- Health checks ตรวจจับ instance ที่มีปัญหา
Phase 5: Multi-AZ
- Deploy ข้าม หลาย Availability Zones เพื่อ HA
- ใช้ Route 53 Alias Record ชี้ไปที่ ELB
บทเรียนสำคัญ
- ใช้ Route 53 Alias Records แทน A Records
- ใช้ ELB + ASG แทน manual scaling
- Multi-AZ สำหรับป้องกัน AZ failure
- Reserved Instances สำหรับประหยัดค่าใช้จ่าย
MyClothes.com — Stateful Web App (3-Tier Architecture)
Session Management
- ELB Stickiness — ผูก user กับ instance เดิม (ปัญหา: ถ้า instance ตาย session หาย)
- User Cookies — เก็บ session ใน cookie ฝั่ง client (ปัญหา: จำกัด 4KB, security risk)
- Server Sessions + ElastiCache/DynamoDB — เก็บ session ID ใน cookie, ข้อมูลอยู่ใน cache (แนะนำ)
Data Layer
- RDS สำหรับเก็บข้อมูล user
- Read Replicas สำหรับ scale การอ่าน
- ElastiCache ด้วย lazy loading สำหรับ caching
- Multi-AZ สำหรับทุก tier (ELB, ElastiCache, RDS)
Security
- Security Groups reference กันเอง เพื่อควบคุมการเข้าถึงระหว่าง layers
MyWordPress.com — Scalable WordPress
Database
- ใช้ Aurora MySQL พร้อม Multi-AZ + Read Replicas
Image Storage
- EBS — เหมาะกับ single instance (ข้อจำกัด: locked ต่อ AZ เดียว)
- EFS — เหมาะกับหลาย instances (shared ข้าม AZs ผ่าน ENI)
Instantiating Applications Quickly
- Golden AMI — สร้าง AMI ที่ติดตั้งทุกอย่างพร้อมแล้ว
- User Data Script — สำหรับ configuration แบบ dynamic ตอน boot
- RDS/EBS Snapshot Restore — restore จาก snapshot ที่มีข้อมูลพร้อมแล้ว