Tìm kiếm
40 kết quả cho “Pod cache”. Tìm không phân biệt dấu.
- Cache và invalidation Chủ đề Thành viên
Cache là cách rẻ nhất để một DB chịu được lượng đọc tăng nhiều lần. Vì vậy nó xuất hiện ngay từ giai đoạn đầu (Instagram 2011, Facebook 2004–2010). Cái giá đến sau, và lặp lại ở hầu hết các nguồn:
- How the controller-runtime Cache Actually Works, and Why Your Controller Does Not Crash the API Server Bài tóm tắt · Kubernetes · 2026
…c theo trường mà không có index thành quét O(n): cụm 50.000 Pod, hàng trăm reconcile/giây, mỗi lần quét toàn bộ dưới khoá đọc và chặn luồng ghi vào store. Sửa bằng index ngược đăng…
- A Kubernetes Resource That Doesn't Exist: Caching CI Images on Ephemeral Runners Bài tóm tắt · Mercari · 2026
…GKE, runner tạm (ephemeral), chế độ Docker-in-Docker : mỗi pod runner có container runner và một Docker daemon sidecar, job chạy trong daemon đó. - Pipeline bận nhất (monorepo IaC…
- Moving Velo to Multiple Container Sites: The Why, The How and The Lessons Learned Bài tóm tắt · Wix · 2021
…dùng được vì Wix có ràng buộc thời gian phản hồi chặt: tạo pod khi có request thì request đầu chậm (cold start); giữ một pod cho mỗi site thì lãng phí vì phân bố đuôi dài (ít site…
- How We Built a Cross-Region Caching Library Bài tóm tắt · Wix · 2022
…ới kho trong RAM. Lần 1: Kafka compact topic (thất bại) Mỗi pod khi khởi động đọc compact topic từ đầu để dựng KV trong RAM. Ổn với topic nhỏ; với topic lớn, đọc lại hàng trăm nghì…
- From Event-Driven Chaos to a Blazingly Fast Serving API Bài tóm tắt · Zalando · 2025
…ung gian (Alpha, Beta, Gamma). Thay đổi chính - 2022: dự án PODS tách dữ liệu Product khỏi Offer, bỏ product nặng khỏi event stream. Product Read API (PRAPI) phục vụ /products/{id}…
- Sitar-agent: Building a reliable dynamic configuration sidecar at scale Bài tóm tắt · Airbnb · 2026
…lần mỗi phút , phải tới hàng nghìn service, hàng chục nghìn pod , trong vài chục giây , không cần deploy lại. Config luôn phải đọc được kể cả khi Sitar Service sập (cũ một chút thì…
- Load Testing Kubernetes: Resolving bottlenecks and improving performance (Part 2) Bài tóm tắt · Achievers · 2023
…gRPC: gRPC giữ kết nối TCP sống lâu, nên khi autoscale thêm pod thì client vẫn bám pod cũ; có pod gần như không nhận request. Đổi DestinationRule của Istio từ round-robin sang LEAS…
- The Events Rail: Inside Atlassian's Webhook Delivery Platform Bài tóm tắt · Atlassian · 2026
…của consumer (bộ lọc), ghi bản khớp vào Webhooks Queue. Một pod matching đánh giá hàng chục nghìn lần/giây khi cache ấm. - Event Delivery (network-bound): giữ hàng trăm HTTP exchan…
- Session revocations at scale Bài tóm tắt · Canva · 2026
…ong 12 giờ; lúc làm mới thì tra MySQL). - Vấn đề: hàng trăm pod gateway, mỗi pod khi khởi động kéo hơn một triệu bản ghi thu hồi từ MySQL. Mỗi lần deploy thành một đợt dồn dập vào…
- Evolving Reddit's ML Model Deployment and Serving Architecture Bài tóm tắt · Reddit · 2021
…mỗi node, bật topology aware routing để request ưu tiên tới pod cùng node; cùng cơ chế áp cho model server pool để bù cho bước mạng mới thêm. - Lúc viết đang chuyển dần các model k…
- From One Horizontal Scaling Controller to Many: Evolving Uber's Compute Platform Bài tóm tắt · Uber · 2026
…ng 4.000 service trên 3 triệu core, 1,5 triệu lần khởi động pod mỗi ngày. Up là lớp federation: service owner deploy, khai báo miền lỗi và kỳ vọng scale. CRD UberDeployment mang th…
- Beyond synthetic testing: Capturing and replaying real database workloads at Airbnb Bài tóm tắt · Airbnb · 2026
…ocessor (offline): ProxySQL chạy trên Kubernetes thành pool pod stateless, mỗi file log trộn query của nhiều cụm → giải mã định dạng nhị phân, tách theo cụm, ghép lại câu lệnh của…
- NVIDIA Dynamo Snapshot: Fast Startup for Inference Workloads on Kubernetes Bài tóm tắt · NVIDIA · 2026
…ức container (cả lớp filesystem ghi được). Restore bằng một pod giữ chỗ nhẹ rồi khôi phục vào namespace của nó. Không dùng checkpoint/restore có sẵn của Kubernetes qua runc để khôn…
- Safeguarding Dynamic Configuration Changes at Scale Bài tóm tắt · Airbnb · 2026
…uardrail, chiến lược rollout (theo AWS zone, theo phần trăm pod Kubernetes); xử lý sự cố nhanh có audit và cho biết cái gì đổi, ai bị ảnh hưởng, khi nào, ai đổi. - Sitar có bốn phầ…
- Shadow Engine Recovery in NVIDIA Dynamo Bài tóm tắt · NVIDIA · 2026
…, graph, buffer communicator. - Bầu active bằng flock : một pod gồm hai container engine, sidecar GMS và một file khoá chung. Engine active giữ khoá; khi process chết (shutdown, se…
- An AKS Performance Journey: Part 2 — Networking It Out Bài tóm tắt · ASOS · 2021
…-out-e253f5bb4f69) Phần 2/2. Phần 1: (SNAT, SKU, kích thước pod). Bối cảnh - Sau phần 1, PLP trên AKS vẫn chậm hơn Cloud Services khoảng 100 ms ở percentile cao. Log có nhiều timeo…
- Nền tảng nội bộ cho service (đường ray chung) Chủ đề Thành viên
Tách hệ thống thành nhiều phần (service, hoặc component trong một monolith) giải được bài toán tổ chức. Nhưng nếu mỗi team tự làm RPC, retry, log, metric, contract theo cách riêng, thì ta chỉ đổi một kiểu hỗn loạn lấy…
- Hot partition và thundering herd Chủ đề Thành viên
Chia dữ liệu và tải ra nhiều máy chỉ hiệu quả khi tải chia đều. Thực tế tải lệch: một khách hàng khổng lồ, một kênh có @everyone, một bài của người nổi tiếng. Có hai dạng hay gặp:
- Độ tin cậy và multi-region Chủ đề Thành viên
Thay đổi kiến trúc lớn thường không đến từ kế hoạch mà từ một sự cố đau đớn. Khi đã chạy nhiều vùng, nhiều giả định của hệ thống một vùng không còn đúng.
- CI và build ở quy mô lớn Chủ đề Thành viên
Lúc nhỏ, CI là "mỗi commit chạy hết build và test". Khi codebase và số commit tăng, chạy hết trở thành bất khả (Stripe 2026: chạy tuần tự mất bốn tháng), và thời gian chờ của một thay đổi không còn chỉ là thời gian…
- Deploy và release an toàn Chủ đề Thành viên
Phần lớn sự cố bắt đầu bằng một thay đổi: code mới, cấu hình mới, hạ tầng mới. Khi hệ thống và tổ chức lớn lên, câu hỏi là làm sao đưa thay đổi lên production thường xuyên mà vẫn giới hạn được thiệt hại khi có lỗi.
- Chi phí hạ tầng và build vs buy Chủ đề Thành viên
Khi còn nhỏ, chi phí hạ tầng là chuyện phụ và cloud là lựa chọn hiển nhiên. Khi lớn lên, hoá đơn có thể chiếm phần lớn giá vốn. Hai câu hỏi xuất hiện: tối ưu chi phí trên nền đang có thế nào, và khi nào nên tự xây (hoặc…
- Sharding và tách database Chủ đề Thành viên
Một database quan hệ duy nhất là điểm khởi đầu của hầu hết sản phẩm. Đến một lúc nó không chịu nổi lượng ghi, dữ liệu không còn vừa một máy, hoặc một sự cố ở DB đó làm sập mọi tính năng.
- Sự cố và postmortem Chủ đề Thành viên
Nhiều bước ngoặt kiến trúc trong wiki bắt đầu từ một sự cố: Netflix lên cloud sau 3 ngày không gửi được DVD, Twitter viết lại hệ thống sau World Cup 2010, Instagram đi nhiều data center sau trận bão 2012. Trang này gom…
- Multi-tenancy và cô lập tenant Chủ đề Thành viên
Một hệ phục vụ nhiều khách (tenant: workspace, shop, organization, account, service nội bộ) trên cùng hạ tầng thì rẻ và dễ vận hành, vì tài nguyên được dùng chung. Cái giá là bốn câu hỏi đi theo hệ suốt đời:
- Tự động hoá vận hành và auto-remediation Chủ đề Thành viên
Khi số máy, shard, pod tăng lên hàng nghìn, lỗi "hiếm" (một node chết, một đĩa hỏng, một replica trễ) thành chuyện hằng ngày, và thao tác tay không còn theo kịp: Stripe có hàng trăm lần shard suy giảm mỗi năm, mỗi lần…
- Scale dọc trước khi scale ngang Chủ đề
Thêm máy (scale ngang) kéo theo độ phức tạp phân tán. Bắt mỗi máy làm được nhiều hơn (scale dọc, tối ưu) thì đơn giản hơn, nhưng có trần và dễ thành một điểm hỏng.
- Observability và monitoring Chủ đề Thành viên
Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:
- Tách compute khỏi storage Chủ đề Thành viên
Hệ có trạng thái kiểu cổ điển (database, broker Kafka, fileserver Git) đặt dữ liệu bền trên đĩa của chính máy xử lý. Máy đó vừa là compute vừa là storage, nên:
- Event-driven, message queue và Kafka Chủ đề Thành viên
Khi một hệ có nhiều bên cần biết "có gì vừa xảy ra" (đơn hàng đổi trạng thái, tin đăng được sửa, ticket được cập nhật), gọi đồng bộ từng bên một làm producer phải biết mọi consumer, và một consumer chậm kéo chậm cả…
- Migration không downtime Chủ đề Thành viên
Hệ thống đang chạy thật (gọi xe, chat, thiết kế) không được dừng, nhưng phải đổi ngôn ngữ, database hoặc hạ tầng bên dưới.
- Monolith và microservices — đi và quay lại Chủ đề Thành viên
Lúc nào nên tách hệ thống thành nhiều service, và cái giá của việc đó là gì? Các nguồn hiện có cho thấy đây không phải đường một chiều.
- Pipeline dữ liệu và analytics Chủ đề Thành viên
Lúc đầu, báo cáo chạy thẳng trên DB production. Đến một lúc truy vấn phân tích làm chậm giao dịch, dữ liệu cần gộp từ nhiều nguồn, và có thêm người dùng mới (analyst, ML, khách hàng xem dashboard). Khi đó cần một mặt…
- Stream processing Chủ đề Thành viên
Khi batch hằng ngày hay hằng giờ không còn đủ tươi (chi tiêu quảng cáo phải dừng đúng lúc chạm ngân sách, dashboard MRR không được trễ 24 giờ, alert phải bắn khi contest sắp đầy), hệ phải tính liên tục trên luồng sự…
- Load test và kiểm chứng capacity Chủ đề Thành viên
Trước một mốc tải chưa từng gặp (ra mắt game, tính năng mới gửi push toàn quốc, mùa giải, tăng trưởng nhanh), cần biết hệ chịu được bao nhiêu, cái gì gãy trước, và cần bao nhiêu máy. Test từng service riêng không đủ vì…
- Shopify Công ty Thành viên
Năm 2015 không còn mua được DB to hơn nên Shopify shard, rồi phát hiện thao tác lặp mọi shard làm mất cô lập lỗi. Kiến trúc pod (mỗi request chỉ chạm một tập datastore cô lập, Pod Mover dời pod sang DR) ra đời .…
- Wix Công ty Thành viên
Năm 2015 Wix dùng MySQL như một kho key/value (blob, không join, không transaction, GUID do client sinh) cho bảng phân giải URL → site, active-active 3 DC, đọc khoảng 1 ms; theo Wix, "MySQL là NoSQL tốt hơn" . Năm 2021,…
- Mercari Công ty Thành viên
PaymentService của Merpay (2019) giữ nhất quán thanh toán qua nhiều service bằng cách tự làm ở tầng ứng dụng: chia pha + state machine, idempotency key bắt buộc, bù trừ kiểu TCC, đối soát và fault injection . Ba năm…
- On-Demand Dagger Engines with Argo CD, EKS, and Karpenter Bài tóm tắt · Dagger · 2024
…cùng phiên bản. - Một engine mỗi node, nhiều runner: runner pod có request tài nguyên (1 core, 2 GB), engine không đặt giới hạn, để nhiều runner dùng chung cache của một engine. Mộ…