Lộ trình
Microsoft AzureCơ bảnTuần 2: Đào sâu dịch vụ cốt lõiBài 11 / 30

Ngày 11: Storage Services

Thời lượng: 45 phút
Mục tiêu: 2 nhiệm vụ chính
Tiến độ lộ trình
az-900ngày 11
hoàn thành11 / 30 bài
Bối cảnh bài học

Chọn Azure Blob, Files, Queue và Table Storage theo data shape, access pattern, consistency, protocol, tier và lifecycle cost.

đọc hiểuthực hànhcheckpoint
Bài giảng hôm nay

Học hiểu, rồi mới thực hành

Chọn Azure Blob, Files, Queue và Table Storage theo data shape, access pattern, consistency, protocol, tier và lifecycle cost.

Bắt đầu đọc bài giảng

Nhiệm vụ bài học hôm nay

  • Tìm hiểu Blob, File, Queue, Table storage
  • So sánh các access tier: Hot, Cool, Archive
Instructor walkthrough

Bài giảng chi tiết: từ bài toán đến bằng chứng

Scenario xuyên suốt

Một ứng dụng cần lưu ảnh upload, mount shared folder cho nhiều VM, xếp hàng job và lưu metadata key-value. Dùng Blob cho mọi thứ hoặc chọn Archive cho dữ liệu đọc thường xuyên đều tạo lỗi kiến trúc và chi phí.

01Đọc bài toán

Xác định actor, workload, constraint và trạng thái cuối cần đạt.

02Vẽ luồng / boundary

Chỉ ra request, dependency, identity và failure domain trước khi chọn công cụ.

03Chọn và thực hành

Thay đổi nhỏ nhất trong lab cô lập; command nào cũng phải nói rõ nó kiểm tra điều gì.

04Kiểm chứng / recovery

Đối chiếu trạng thái thực tế, tạo một failure variant và ghi cách hoàn tác.

Cách nối lý thuyết với thực tế
  • Blob Storage là object storage cho unstructured data; access tier Hot/Cool/Archive phản ánh access frequency và retrieval/latency trade-off.
  • Azure Files cung cấp managed file share qua SMB/NFS tùy option; phù hợp workload cần file semantics/mount.
  • Queue Storage tách producer/consumer và cần thiết kế visibility timeout, poison message, retry và idempotency.
  • Table Storage là NoSQL key-value với PartitionKey/RowKey; query/access pattern và partition design quyết định performance.

Storage bắt đầu từ access pattern

Một image upload không cần file locking như shared folder; một job queue không nên dùng blob listing làm message broker; metadata key-value không tự nhiên trở thành relational table.

Need Service Câu hỏi cần chốt
Object/unstructured Blob tier, lifecycle, versioning, public access, redundancy
Shared file semantics Azure Files SMB/NFS, mount, identity, performance, snapshots
Producer/consumer Queue Storage retry, visibility, poison message, idempotency
Key-value Table Storage PartitionKey/RowKey, query, hot partition, schema flexibility

Access tier và lifecycle

Hot/Cool/Archive là trade-off access cost, storage cost, retrieval latency/fee và minimum retention. Lifecycle rule phải gắn với business retention; archive không phù hợp dữ liệu cần đọc ngay. Redundancy tăng durability/availability nhưng có cost và replication behavior.

Bài tập

Thiết kế storage cho photo service. Ghi source of truth, access frequency, retention, delete/recovery, encryption/access boundary, redundancy và egress. Thiết kế queue flow có duplicate message và worker crash.

Checkpoint

Bạn đạt bài khi chọn service bằng data semantics và chứng minh tier/redundancy không phá requirement hoặc budget.

Terminal reference

Command list và cách dùng

Chạy từng lệnh theo đúng thứ tự. Trước các lệnh có thể tạo hoặc thay đổi tài nguyên, hãy kiểm tra profile, account và region.

Commands · read-only checkpoints
az account show --output table
az account list --output table
az group list --output table
Hands-on lab

Thực hành theo scenario

  1. Lập storage decision table cho image, shared config, background job và user metadata.
  2. Vẽ producer → queue → worker flow, ghi retry/visibility/idempotency/poison message handling.
  3. Tạo lifecycle policy giả lập: hot → cool → archive theo age và business retention; ghi retrieval/cost risk.
  4. Kiểm tra storage account settings ở read-only; không upload data cá nhân hoặc bật replication/tier có phí nếu chưa có budget.
Evidence checkpoint

Kiểm chứng kết quả

Không coi lệnh chạy thành công là đủ. Hãy đối chiếu output với trạng thái mong đợi:

  • Chọn đúng storage type theo data shape/protocol/access pattern.
  • Giải thích Hot/Cool/Archive không chỉ là “rẻ hơn”.
  • Có queue failure handling và idempotency.
  • Partition/key design của Table có lý do.
  • Có redundancy, retention, deletion và egress considerations.
Transfer to exam / production

Bẫy thường gặp và trade-off

Blob là object, Files là file share, Queue là message buffer, Table là key-value NoSQL. Đọc protocol/access pattern trước, sau đó mới xét tier và redundancy.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Ứng dụng cần nhiều VM mount cùng một thư mục qua file protocol và giữ file semantics. Lựa chọn nào phù hợp nhất?

Kết thúc bài

Checklist trước khi sang Ngày 2