Kiến trúc cho trang này

Chào anh em! 👋

Với một kỹ sư Cloud/DevOps, việc xây dựng một chiếc blog cá nhân không đơn thuần chỉ là chọn một nền tảng như WordPress rồi bắt đầu gõ phím. Đó còn là cơ hội tuyệt vời để tự tay thiết kế, triển khai và tối ưu một hệ thống theo đúng chuẩn mực Best Practices.

Hôm nay, mình sẽ “mổ xẻ” kiến trúc đằng sau Horashi Blog. Hệ thống này được thiết kế theo triết lý 100% Serverless trên AWS, kết hợp với sức mạnh của Astro ở Frontend, mang lại tốc độ tải trang tính bằng mili-giây và chi phí vận hành hàng tháng gần như bằng $0.

🏗️ Sơ đồ Kiến trúc Tổng thể

Thay vì đi theo lối mòn Monolithic truyền thống, mình tách biệt hoàn toàn Frontend (Giao diện) và Backend (API Dữ liệu động). Dưới đây là sơ đồ luồng dữ liệu của hệ thống:

graph LR
    %% Định nghĩa màu sắc cơ bản
    classDef client fill:#f8fafc,stroke:#334155,stroke-width:2px;
    classDef aws fill:#ff9900,stroke:#232f3e,stroke-width:2px,color:black;
    classDef database fill:#3b82f6,stroke:#1e3a8a,stroke-width:2px,color:white;
    
    %% Thành phần
    Client(("💻 User / Browser")):::client
    R53{"Route 53"}:::aws
    
    %% Nhánh Frontend
    CF["☁️ CloudFront"]:::aws
    S3["🪣 S3 Bucket<br/>(Static Files)"]:::aws
    
    %% Nhánh Backend
    APIGW["🚪 API Gateway"]:::aws
    Lambda["⚡ AWS Lambda"]:::aws
    DDB[("💾 DynamoDB")]:::database

    %% Luồng đi của Frontend (Lấy giao diện)
    Client -->|"1. Tải Giao diện<br/>(devops.horashi.com)"| R53
    R53 --> CF
    CF --> S3

    %% Luồng đi của Backend (Gọi API)
    Client -->|"2. Lấy Dữ liệu động<br/>(api.devops.horashi.com)"| R53
    R53 --> APIGW
    APIGW --> Lambda
    Lambda --> DDB

    %% Note cho IAM Role
    IAM(["🔑 IAM Role: OAC"]) -.-> S3

Nhìn vào sơ đồ, anh em có thể thấy rõ 2 luồng hoạt động song song khi một người dùng truy cập vào trang web.

1. Luồng Frontend (Nội dung tĩnh - Static Content)

Mình sử dụng Astro, một framework đỉnh cao trong việc tạo ra các trang web tĩnh (SSG - Static Site Generation). Khi code được push lên Github, hệ thống CI/CD sẽ build toàn bộ bài viết (Markdown) thành các file HTML, CSS và JS thuần.

• S3 Bucket: Đóng vai trò là ổ cứng lưu trữ các file tĩnh này.
• CloudFront (CDN): Đứng trước S3 để phân phối nội dung đến các Edge Location trên toàn cầu. Nhờ vậy, anh em ở VN hay ở Mỹ truy cập blog đều load nhanh như chớp.
• Bảo mật với OAC (Origin Access Control): S3 bucket được cấu hình chặn toàn bộ truy cập từ Internet (Block all public access). Chỉ duy nhất CloudFront (thông qua IAM Role) mới có quyền đọc file từ S3.

2. Luồng Backend (Dữ liệu động - Dynamic API)

Mặc dù là web tĩnh, nhưng blog vẫn cần những tính năng động như đếm lượt xem (View Counter), tìm kiếm (Search), hay nhận bình luận. Đây là lúc kiến trúc Serverless phát huy sức mạnh.

• Trình duyệt làm trung gian: Nội dung tĩnh từ S3 không tự động gọi API. Chính trình duyệt của anh em (Client) sau khi tải xong giao diện, sẽ chạy đoạn code JavaScript để bắn request lên một subdomain riêng biệt là api.devops.horashi.com.
• API Gateway + Lambda: Đóng vai trò tiếp nhận và xử lý logic (như validate dữ liệu, chống spam).
• DynamoDB: Cơ sở dữ liệu NoSQL Serverless của AWS. Nhanh, mở rộng tự động và miễn phí 25GB trọn đời.

🛡️ Bài toán Bảo mật API

Với việc phơi API ra public domain, mình sử dụng nhiều lớp bảo vệ để hệ thống không bị “luộc”:

1. CORS Policy: API Gateway chỉ chấp nhận các request có nguồn gốc (Origin) từ https://devops.horashi.com. Các trang web khác nhúng link API này vào sẽ bị trình duyệt chặn lập tức.
2. Rate Limiting: Thiết lập Throttling để chặn đứng các đợt tấn công DDoS cấp độ Application, đảm bảo hóa đơn DynamoDB không bị “thủng nóc”.

🎯 Kết luận

Bằng cách tận dụng sức mạnh của Astro kết hợp triệt để với triết lý Decoupled Serverless của AWS, Horashi Blog hiện tại đáp ứng đủ 3 tiêu chí: Tốc độ bàn thờ - Bảo mật chặt chẽ - Chi phí tiệm cận không.

Anh em nghĩ sao về kiến trúc này? Liệu có điểm nào có thể tối ưu hơn nữa không? Hãy để lại ý kiến hoặc kết nối với mình qua LinkedIn nhé! 🚀