Xin chào anh em, lại là mình NekoArcoder đây!!!

Nay mình đang học về AWS nên có hứng thú chia sẻ cho anh em mới nhập môn lập trình web một số kiến thức về SA cực kỳ hữu ích cho các bạn.

Nói về SA thì chắc bạn cũng nghe nhiều rồi, chắc cũng phải ngang ngửa với cái SOLID luôn á, vì vậy trong bài viết này mình sẽ giải thích và ví dụ về SA cực kỳ dễ hiểu để anh em tham khảo nha!!!

I. Solution Architecture là gì?

Solution Architecture (Kiến trúc giải pháp) là cách bạn thiết kế toàn bộ hệ thống để giải quyết một vấn đề cụ thể của business.

Bao gồm chọn công nghệ gì, các thành phần nào, kết nối ra sao, đảm bảo hiệu năng, bảo mật, mở rộng và chi phí hợp lý.

Nói cho đơn giản thì là:

Nếu business đưa ra một bài toán, thì Solution Architecture là bản thiết kế kỹ thuật để giải bài toán đó.

Ví dụ bạn là một kỹ sư ở P***hub ...

Giả sử business nói với bạn: “Chúng ta cần xây một hệ thống cho phép 10 triệu người xem video đồng thời và trả kết quả nhanh.”

Lúc này, bạn sẽ không nhảy vào code ngay. Bạn sẽ phải thiết kế kiến trúc trước.

SA giúp bạn tư duy như thế nào?

Thay vì hỏi: “Làm sao code cái này?”

Một engineer thực thụ sẽ tự hỏi thế này:

• Hệ thống này chịu được bao nhiêu traffic?
• Có Single Point of Failure không?
• Làm sao scale?
• Làm sao rollback khi deploy lỗi?
• Chi phí mỗi tháng bao nhiêu?

Và đó chính là Solution Architecture.

II. Các giai đoạn của ứng dụng Hello World của bạn.

Giả sử chúng ta có một web đơn giản xuất ra cho người dùng chữ Hello world (Không quan trọng là bạn dùng ngôn ngữ gì hay framework nào nhé).

Bạn và mình sẽ cùng đi qua từng giai đoạn thiết kế để giải quyết từng vấn đề của giai đoạn để hiểu về SA là thế nào.

Giai đoạn 1 – Ứng dụng cực kỳ đơn giản (PoC)

Yêu cầu:

• Không cần database
• Chấp nhận downtime
• Bắt đầu nhỏ, sau này nếu nổi tiếng sẽ mở rộng

Lúc này ta sẽ chỉ cần 1 con server tối thiểu 1 vCPU và RAM 1 GiB.

Đến đây thì bạn có thể lựa chọn 1 con VPS giá rẻ ở đâu đó, hoặc tạo một con EC2 với loại là EC2 T2.micro.

Bây giờ ứng dụng của bạn hoạt động như sau:

• Người dùng truy cập vào server của bạn bằng IP
• Xuất hiện câu Hello World

Xong. Ứng dụng hoạt động ngon lành.

Lưu ý với EC2 thì bạn phải gán Elastic IP để giúp giữ IP cố định, vì nếu restart instance mà không có Elastic IP thì public IP sẽ thay đổi.

Đây là bản Proof of Concept (PoC) đầu tiên đã chạy tốt, người dùng hài lòng.

Giai đoạn 2 – Traffic tăng → Vertical Scaling

Người dùng bắt đầu giới thiệu bạn bè vì câu Hello World nó wow quá.

Traffic tăng lên T2.micro hoặc VPS nhỏ đó không đủ nữa.

Giải pháp đầu tiên của một engineer sẽ là:

Thay instance nhỏ bằng instance lớn hơn → ta gọi là Vertical Scaling

Ví dụ: Bạn sẽ mua một con VPS to hơn, khỏe hơn, để đáp ứng được lượng traffic tăng lên. Đối với EC2 thì bạn sẽ stop con hiện tại, đổi loại thành m5.large rồi start lại, Elastic IP vẫn giữ nguyên → người dùng vẫn truy cập được.

Vấn đề hiện tại:

Trong lúc stop & start:

• Ứng dụng bị downtime
• Người dùng không truy cập được

→ Lúc này Vertical scaling hoạt động, nhưng không lý tưởng lắm.

Giai đoạn 3 – Horizontal Scaling

Bây giờ web của bạn đã quá nổi tiếng, đếm số lượng người truy cập như muối bỏ biển.

Giải pháp lúc này:

• Tạo thêm nhiều VPS hoặc EC2 loại m5.large (Mỗi instance cần có 1 Elastic IP)

Bây giờ chúng ta đang có:

• 3 VPS hoặc EC2
• 3 IP (Hoặc 3 Elastic IP nếu dùng EC2)

Đây là Horizontal Scaling hay được các dũng sĩ phương Nam gọi là scale theo chiều ngang.

Ta lại tiếp tục gặp vấn đề như sau:

• Người dùng phải biết tất cả IP của tất cả các instance (Riêng Aws thì mặc định chỉ có 5 Elastic IP / region)
• Quản lý rất phức tạp

→ Ta bắt đầu thấy giới hạn kiến trúc này.

Giai đoạn 4 – Thêm Load Balancer và Hostname

Chúng ta cần phải tìm ra giải pháp là người dùng không cần nhớ hết IP, họ chỉ cần truy cập một thứ dễ nhớ hơn đó là tên miền, ví dụ helloworld.com chẳng hạn (Đó chính là Hostname).

Lúc này request của người dùng sẽ tự động được di chuyển ngẫu nhiên hoặc có tính toán đến các VPS hoặc EC2 mà bạn đang có (Công cụ giúp bạn lúc này đó chính là Load Balancer).

Lúc này ta cần phải đảm bảo các VPS hoặc EC2 chỉ nhận request đến từ Load Balancer, mà không được truy cập từ các địa chỉ khác.

Từ đây tùy thuộc vào bạn chọn loại server nào thì sẽ có cách cấu hình khác nhau, nhưng về bản chất nó vẫn giống nhau nhé anh em:

Đối với VPS

Anh em sẽ làm thế này:

User

↓ Truy cập helloworld.com, request được đưa tới DNS để phân giải tên miền

DNS (Ta có thể chọn Cloudflare hoặc domain provider nào đó)

↓ Sau đó trỏ CNAME của DNS về IP hoặc Hostname của Load Balancer

Load Balancer (Ở đây ta dùng Nginx, HAProxy hoặc Managed LB của provider cũng được)

↓ Cấu hình Load Balancer trỏ về IP của các VPS, nhớ cấu hình các VPS chỉ nhận request từ LB này thôi nhé!

VPS instances

Lúc này người dùng chỉ cần biết về tên miền, request sẽ tự phân bổ đều đến tất cả các VPS một cách tự động cho anh em.

Đối với AWS

Lúc này ta bỏ các Elastic IP trên các EC2 đi, vì ta sẽ không truy cập trực tiếp bằng IP nữa.

Ta chuyển EC2 thành private, tạo target group với các EC2 có sẵn, tạo và thêm Load Balancer public-facing. Ta sẽ có được 1 hostname từ ELB này.

Sau đó dùng Alias Record trong Route 53 (Đảm bảo lúc này bạn đã có hostname rồi) trỏ thẳng đến ELB hostname.

Kiến trúc sẽ đại khái thế này:

User
↓
Route 53 (Đóng vai trò là DNS)
↓
ALB (Load Balancer)
↓
EC2

Khác về mặt triển khai nhưng tựu chung thì kiến trúc nó vẫn là như vậy.

Giai đoạn tiếp theo đây thì với VPS sẽ không còn phù hợp nữa, vì với các VPS thì nó chỉ phù hợp với giai đoạn đầu của dự án, khi mà lượng user còn ít, khả năng scale không cần nhiều.

Nhưng một khi dự án đã đạt lượng user lớn, thì bạn cần phải nghĩ ngay tới việc sử dụng Cloud computing, mà trong đó nổi tiếng nhất là như của AWS hoặc Azure của Google.

Vì mình đang học AWS nên ở giai đoạn tiếp theo mình sẽ nói về các service của AWS thôi nhé.

Giai đoạn 5 – Thêm Auto Scaling Group (Giai đoạn triển khai trên AWS)

Việc thêm EC2 thủ công rất cực. Vì vậy chúng ta cần có một thứ linh hoạt hơn.

Giải pháp:

• Dùng Auto Scaling Group
• Tự động scale in / scale out

Ví dụ:

• Ban ngày ít người truy cập → giảm instance
• Buổi tối nhiều người truy cập → tăng instance

Lợi ích lúc này:

• Không downtime
• Tối ưu chi phí
• Luôn có đúng số instance cần thiết

Lúc này cứ rung đùi mà tận hưởng thành quả của bạn, hay chưa chắc nhỉ?

Giai đoạn 6 – Thảm họa xảy ra (AZ bị sập)

Giả sử nơi đặt EC2 của bạn có động đất. Availability Zone 1 bị sập. Toàn bộ EC2 trong AZ đó mất hết.

Nếu bạn chỉ chạy web của bạn trên 1 AZ → ứng dụng down toàn bộ. Xin là xin vĩnh biệt cụ luôn.

Lúc này Amazon hiện ra và nói:

"Hết cứu... à nhầm. Phải là: Do bạn chưa triển khai Multi-AZ đó."

Giải pháp:

• ELB chạy trên nhiều AZ
• ASG trải rộng nhiều AZ
• Ví dụ: AZ1: 2 instance, AZ2: 2 instance, AZ3: 1 instance

Nếu 1 AZ sập:

• 2 AZ còn lại vẫn phục vụ
• Ứng dụng vẫn hoạt động

→ Đây là High Availability thực sự.

Giai đoạn 7 – Tối ưu chi phí

Với ứng dụng của chúng ta hiện tại thì:

Luôn cần tối thiểu 2 instance chạy 24/7

Chỉ có một khoảng thời gian nhất định trong ngày, hoặc trong tháng là ta cần thêm các instance, không phải lúc nào cũng có lượng traffic lớn.

Lúc này, ta sẽ có giải pháp để tối ưu chi phí các instance được scale này:

• Mua Reserved Instances cho 2 instance base
• Instance scale thêm → dùng On-Demand
• Hoặc nếu muốn tiết kiệm hơn → dùng Spot

→ Lúc này ta sẽ giảm được chi phí đáng kể mà vẫn giữ khả năng scale

III. Tổng kết

Qua 7 giai đoạn của một ứng dụng cơ bản, anh em có thể thấy một điều rất rõ:

Kiến trúc không phải là thứ cố định. Nó tiến hóa theo quy mô hệ thống.

Dĩ nhiên đây chỉ là những giai đoạn của một ứng dụng đơn giản chưa có database, mọi thứ sẽ không màu hường như bài viết này, nhưng mình đảm bảo khi bạn hiểu được đại ý của bài viết này thì bạn đang dần tiến tới hành trình của một kỹ sư rồi.

Nếu bạn là người mới, bạn bắt đầu từ những thứ nhỏ nhất, cứ chạy được là được, khi phát sinh vấn đề hoặc dự đoán vấn đề sắp xảy ra thì bạn chỉ cần triển khai nâng cấp nó, cái khó là bạn có nhìn ra được điểm nghẽn của hệ thống không thôi.

Và đó là hết rồi, đây là bài viết cuối cùng của mình trước thềm 2026 sắp tới, kính chúc anh em sẽ thành công rực rỡ với con đường phía trước, và cùng mình tiếp tục đồng hành trên chặng đường học hỏi những kiến thức mới.

Và đó là mình, NekoArcoder, hãy để lại cho mình một upvote nếu thấy hay, bình luận nếu thấy những chỗ sai sót của mình. Xin chào và hẹn anh em trong bài viết sau nhé!