Tìm hiểu cách triển khai ứng dụng phục vụ người dùng trên toàn thế giới với độ trễ thấp và độ sẵn sàng cao, thông qua Route 53, CloudFront, S3 Transfer Acceleration, Global Accelerator, cùng các mô hình mở rộng hạ tầng ra ngoài Region như Outposts, WaveLength và Local Zones.
Một "ứng dụng toàn cầu" là ứng dụng được triển khai ở nhiều vị trí địa lý khác nhau, thay vì chỉ chạy tại một region duy nhất. Trên AWS, việc "trải rộng" này có thể thực hiện bằng cách dùng nhiều Region và/hoặc các Edge Location. Có ba lý do chính khiến việc này trở nên cần thiết:
Trước khi đi vào các dịch vụ cụ thể, hãy nhắc lại ba thành phần cấu thành hạ tầng toàn cầu của AWS, vì mọi giải pháp trong chương này đều xây dựng dựa trên chúng:
Region dùng để chạy hạ tầng "nặng" (compute, database...), còn Edge Location dùng để phục vụ nội dung nhanh nhất tới người dùng ở khắp nơi mà không cần họ phải kết nối trực tiếp tới Region xa xôi.
Route 53 là dịch vụ DNS (Domain Name System) được AWS quản lý hoàn toàn. DNS về cơ bản là một tập hợp các quy tắc và bản ghi (record) giúp máy khách (client) biết cách "tìm đường" tới đúng server khi gõ vào một địa chỉ URL — giống như một cuốn "sổ điện thoại" của Internet, dịch tên miền dễ nhớ (như www.example.com) thành địa chỉ IP mà máy móc thực sự dùng để kết nối.
Các loại record phổ biến nhất trong Route 53 mà bạn cần biết:
| Loại record | Chức năng | Ví dụ |
|---|---|---|
| A | Hostname → địa chỉ IPv4 | www.example.com → 12.34.56.78 |
| AAAA | Hostname → địa chỉ IPv6 | tương tự A nhưng cho IPv6 |
| CNAME | Hostname → một hostname khác | search.example.com → www.example.com |
| Alias | Hostname → một resource của AWS | trỏ tới ELB, CloudFront, S3, RDS... |
Luồng hoạt động cơ bản của một A record: trình duyệt gửi yêu cầu DNS cho myapp.mydomain.com → Route 53 trả về địa chỉ IP tương ứng (ví dụ 32.45.67.85) → trình duyệt gửi HTTP Request tới đúng địa chỉ IP đó → nhận về HTTP Response từ Application Server.
Ngoài việc "dịch" tên miền thành IP, Route 53 còn cho phép chọn chiến lược định tuyến — tức là quyết định trả về IP nào khi có nhiều đích đến khả dụng. Ở mức Cloud Practitioner, bạn chỉ cần biết ở mức tổng quan bốn chính sách sau:
Amazon CloudFront là dịch vụ Content Delivery Network (CDN) của AWS. Nhiệm vụ chính của CDN là cải thiện hiệu năng đọc (read performance) bằng cách lưu (cache) một bản sao nội dung tại các Edge Location trên khắp thế giới — khi người dùng ở gần một edge location yêu cầu nội dung, họ nhận được ngay từ edge gần nhất thay vì phải đi hết đường về server gốc ở xa.
CloudFront có hàng trăm Points of Presence (edge location dùng để cache) trên toàn cầu. Ngoài lợi ích về tốc độ, CloudFront còn tích hợp sẵn khả năng chống tấn công DDoS trên phạm vi toàn cầu, cùng với tích hợp AWS Shield và AWS WAF để bảo vệ ứng dụng khỏi các cuộc tấn công web phổ biến.
CloudFront có thể lấy nội dung từ nhiều loại "origin" (nguồn gốc) khác nhau:
Luồng hoạt động ở mức tổng quan: client gửi GET request → CloudFront Edge Location kiểm tra cache cục bộ (Local Cache) → nếu chưa có (cache miss), CloudFront chuyển tiếp yêu cầu tới Origin (S3 hoặc HTTP Origin) → nhận nội dung, lưu vào cache và trả kết quả về cho client. Từ lần sau, cùng nội dung đó sẽ được trả trực tiếp từ cache mà không cần hỏi lại Origin, cho tới khi cache hết hạn (TTL).
Một mô hình rất phổ biến là dùng S3 bucket làm Origin cho CloudFront. Ví dụ, các edge location đặt tại Los Angeles, Mumbai, Melbourne, São Paulo (và rất nhiều nơi khác) đều lấy nội dung gốc từ cùng một Origin S3 bucket. Điểm quan trọng là bucket S3 này hoàn toàn có thể được giữ ở trạng thái private (không public) — chỉ CloudFront mới được phép đọc từ bucket, thông qua Origin Access Control (OAC) kết hợp với bucket policy cho phép OAC đó.
Nhờ vậy, traffic đi từ CloudFront tới S3 (chặng "origin fetch") luôn đi trong mạng nội bộ (private) của AWS, trong khi traffic công khai (public www traffic) từ người dùng chỉ chạm tới các edge location, không bao giờ chạm trực tiếp vào S3 bucket. Đây là cách vừa tăng tốc độ phân phối, vừa giữ được tính bảo mật cho dữ liệu gốc.
Cả CloudFront và S3 Cross-Region Replication (CRR) đều giúp đưa nội dung tới gần người dùng hơn, nhưng chúng phục vụ mục đích khác nhau và dễ bị nhầm lẫn trong đề thi. Bảng dưới đây tóm tắt sự khác biệt then chốt:
| Đặc điểm | CloudFront | S3 Cross-Region Replication |
|---|---|---|
| Phạm vi | Mạng Edge toàn cầu (hàng trăm điểm) | Phải tự cấu hình riêng cho từng Region muốn có bản sao |
| Cách cập nhật nội dung | Nội dung được cache theo một khoảng thời gian (TTL) — có thể mất tới cả ngày mới cập nhật | File được cập nhật gần như real-time (near real-time) |
| Kiểu dữ liệu phù hợp | Read-heavy, nội dung tĩnh cần có mặt ở khắp mọi nơi | Read only, dữ liệu động cần độ trễ thấp chỉ ở một vài region cụ thể |
Nói ngắn gọn: chọn CloudFront khi cần phân phối nội dung ổn định, ít thay đổi, tới khắp thế giới với tốc độ cao nhất; chọn S3 CRR khi cần các bản sao dữ liệu cập nhật gần như tức thời, nhưng chỉ ở một số region nhất định mà bạn chủ động chọn trước.
Vấn đề: một người dùng ở xa (ví dụ Úc) muốn upload file vào một S3 bucket đặt ở Mỹ. Nếu đi thẳng qua Internet công khai (public Internet) toàn bộ hành trình, đường truyền có thể chậm và không ổn định vì phải qua nhiều "nút" trung gian không do AWS kiểm soát.
S3 Transfer Acceleration giải quyết vấn đề này bằng cách tách hành trình thành hai chặng: chặng đầu, file được gửi từ máy người dùng tới Edge Location gần nhất qua Internet công khai (chặng này thường ngắn nên vẫn nhanh); chặng sau, dữ liệu được chuyển tiếp từ edge location đó tới S3 bucket ở region đích thông qua mạng backbone riêng, tốc độ cao của AWS. Vì phần lớn hành trình dài đi trong mạng riêng của AWS thay vì Internet công khai, tốc độ tổng thể tăng lên đáng kể.
AWS Global Accelerator giúp cải thiện độ sẵn sàng và hiệu năng của ứng dụng toàn cầu bằng cách tận dụng chính mạng lưới nội bộ (global network) của AWS — AWS công bố có thể cải thiện hiệu năng tới khoảng 60% so với đi qua Internet công khai thông thường.
Khi dùng Global Accelerator, AWS tạo ra 2 địa chỉ IP Anycast cố định cho ứng dụng của bạn. "Anycast" nghĩa là cùng một địa chỉ IP đó được quảng bá (advertise) từ nhiều edge location cùng lúc — khi người dùng gửi request tới IP này, request sẽ tự động đi vào edge location gần người dùng nhất. Từ edge location, traffic sau đó được chuyển tiếp qua mạng riêng tốc độ cao của AWS tới ứng dụng thật sự — có thể đặt ở một hoặc nhiều Region (ví dụ traffic từ Mỹ, Úc, châu Âu, Ấn Độ đều được dẫn tới một Public ALB).
CloudFront và Global Accelerator dễ bị nhầm vì cả hai đều dùng mạng lưới Edge Location toàn cầu của AWS và đều tích hợp với AWS Shield để chống DDoS. Nhưng bản chất hoạt động của chúng khác nhau hoàn toàn:
| Đặc điểm | CloudFront | Global Accelerator |
|---|---|---|
| Bản chất | CDN — có cơ chế cache | Không cache, chỉ "proxy" gói tin ở edge tới ứng dụng thật |
| Phù hợp cho | Nội dung có thể cache được (ảnh, video, static asset) | Nhiều loại ứng dụng chạy trên TCP/UDP, không chỉ HTTP |
| Ưu điểm nổi bật | Tăng tốc nội dung tĩnh nhờ cache gần người dùng | IP tĩnh cố định; failover giữa các Region nhanh, có thể đoán trước (deterministic) |
Ghi nhớ đơn giản: nếu nội dung của bạn cache được (ảnh, video, file tĩnh) → dùng CloudFront. Nếu ứng dụng của bạn cần traffic động, không cache được, cần IP tĩnh, hoặc cần failover nhanh giữa nhiều Region → dùng Global Accelerator.
Nhiều doanh nghiệp không thể chuyển 100% hạ tầng lên cloud — vì lý do pháp lý, độ trễ, hoặc đã đầu tư sẵn hạ tầng on-premises — nên vẫn cần duy trì song song cả hạ tầng on-premises và hạ tầng cloud. Mô hình này gọi là Hybrid Cloud. Vấn đề là: quản lý hai hệ thống (cloud dùng console/CLI/API của AWS, on-premises dùng công cụ hoàn toàn khác) rất tốn công và thiếu nhất quán.
AWS Outposts giải quyết vấn đề này bằng cách đưa nguyên một "server rack" của AWS về đặt vật lý ngay tại trung tâm dữ liệu của bạn. Rack này cung cấp đúng hạ tầng, dịch vụ, API và công cụ giống hệt như trên cloud thật — nghĩa là bạn dùng chung một bộ công cụ, một cách làm việc, cho cả on-premises và cloud. AWS chịu trách nhiệm lắp đặt và quản lý (vận hành phần mềm/phần cứng) của "Outposts Rack" này, còn bạn chịu trách nhiệm về an ninh vật lý (physical security) cho rack đặt tại cơ sở của mình.
Lợi ích chính của Outposts: truy cập với độ trễ thấp tới các hệ thống on-premises hiện có, xử lý dữ liệu ngay tại chỗ (local data processing), đáp ứng yêu cầu về nơi lưu trữ dữ liệu (data residency — ví dụ luật yêu cầu dữ liệu phải nằm trong biên giới quốc gia), giúp việc di trú (migration) từ on-premises lên cloud dễ dàng hơn về sau, và vẫn là một dịch vụ được quản lý đầy đủ (fully managed). Một số dịch vụ AWS chạy được trên Outposts: EC2, EBS, S3, EKS, ECS, RDS, EMR.
AWS WaveLength nhắm tới một nhu cầu rất đặc thù: ứng dụng cần độ trễ siêu thấp (ultra-low latency) thông qua mạng di động 5G. WaveLength Zones là các cụm hạ tầng AWS được triển khai ngay bên trong trung tâm dữ liệu của các nhà mạng viễn thông (telecommunications provider), nằm ở biên (edge) của mạng 5G — nghĩa là AWS đặt server (ví dụ EC2, EBS, VPC) ngay tại nơi mạng 5G kết nối vào, thay vì để traffic phải đi vòng về Region AWS thông thường ở xa.
Vì traffic không cần rời khỏi mạng của nhà mạng viễn thông (Communication Service Provider – CSP) để đi tới ứng dụng, độ trễ giảm xuống mức tối thiểu. WaveLength vẫn có kết nối bảo mật, băng thông cao về Region AWS "mẹ" khi cần, và không có phụ phí hay hợp đồng dịch vụ bổ sung nào ngoài chi phí sử dụng thông thường.
WaveLength phù hợp cho các use case đòi hỏi phản hồi gần như tức thì: Thành phố thông minh (Smart Cities), chẩn đoán y tế có trợ giúp của Machine Learning, xe kết nối (Connected Vehicles), livestream video tương tác, AR/VR, và game thời gian thực (Real-time Gaming).
AWS Local Zones đặt các dịch vụ compute, storage, database và một số dịch vụ khác của AWS gần hơn với người dùng cuối, phục vụ các ứng dụng nhạy cảm với độ trễ (latency-sensitive). Về mặt khái niệm, một Local Zone hoạt động như "phần mở rộng của một AWS Region" (extension of an AWS Region) — bạn có thể mở rộng chính VPC hiện tại của mình để bao gồm cả các Local Zone, mà không cần tạo hạ tầng mạng hoàn toàn mới.
Local Zones tương thích với các dịch vụ như EC2, RDS, ECS, EBS, ElastiCache, và Direct Connect. Ví dụ: Region N. Virginia (us-east-1) có các Local Zone đặt tại các thành phố như Boston, Chicago, Dallas, Houston, Miami — cho phép một ứng dụng "gốc" nằm ở us-east-1 có thể đặt một phần compute ngay gần người dùng ở các thành phố đó để giảm độ trễ, mà vẫn quản lý như một phần của cùng một Region/VPC.
Khi thiết kế một ứng dụng phục vụ người dùng toàn cầu, có một "lộ trình" từ đơn giản tới phức tạp, đánh đổi giữa độ sẵn sàng/hiệu năng và độ khó khi xây dựng, vận hành:
Không có một mô hình nào "đúng" cho tất cả — lựa chọn phụ thuộc vào yêu cầu thực tế về độ sẵn sàng, độ trễ chấp nhận được, và ngân sách/độ phức tạp kỹ thuật mà tổ chức có thể duy trì.