Kiến trúc OSRM Shared Memory trên Kubernetes: Vận Hành Live Traffic Zero-Downtime

Answer-first: Vận hành OSRM quy mô lớn trên Kubernetes giải quyết khởi động nguội và lãng phí RAM bằng POSIX Shared Memory (/dev/shm). Nhờ osrm-datastore và phân hoạch Multi-Level Dijkstra, một khối đồ thị duy nhất phục vụ hàng chục worker pod. Hoán đổi con trỏ nguyên tử cho phép nạp tốc độ giao thông trực tiếp không gián đoạn.

Điều kiện tiên quyết: Người đọc cần nắm vững cơ chế bộ nhớ chia sẻ Linux (POSIX shm_open, mmap, tmpfs), quản lý IPC trong vùng chứa Kubernetes (hostIPC, shareProcessNamespace), và các khái niệm xử lý đồ thị định tuyến OSRM (Contraction Hierarchies, Multi-Level Dijkstra).

🇬🇧 Read the English version of this article on tanhdev.com

1. Thách Thức Vận Hành OSRM Ở Quy Mô Doanh Nghiệp

Hệ thống định tuyến OSRM (Open Source Routing Machine) là tiêu chuẩn công nghiệp hiệu năng cao nhất để tính toán đường đi ngắn nhất (Shortest Path) và ma trận khoảng cách (Distance Matrix) cho các nền tảng gọi xe (Ride-hailing), giao hàng siêu tốc (Quick Commerce) và logistics chặng cuối (Last-mile Delivery).

Tuy nhiên, khi tự vận hành OSRM với tệp dữ liệu bản đồ toàn quốc hoặc toàn cầu (dung lượng từ 30GB đến 80GB tệp nhị phân đồ thị), đội ngũ Platform Engineering và SRE sẽ đối mặt với một bức tường kỹ thuật khắc nghiệt:

1. Vấn đề Khởi động nguội (The Cold Start Nightmare): Tiến trình osrm-routed thông thường nạp toàn bộ đồ thị vào Heap RAM độc lập của nó. Một Pod Kubernetes mất từ 5 đến 12 phút để đọc tệp từ đĩa SSD và giải mã đồ thị vào bộ nhớ trước khi vượt qua kiểm tra readinessProbe.
2. Auto-scaling Bị Vô Hiệu Hóa: Khi lưu lượng truy cập tăng đột biến vào giờ cao điểm, Horizontal Pod Autoscaler (HPA) ra lệnh tạo thêm 10 Pods mới. Trong 10 phút các Pod mới đang khởi động nguội, các Pod hiện tại bị quá tải và sập đổ dây chuyền (Cascading Failure).
3. Lãng Phí Bộ Nhớ Khủng Khiếp: Nếu bạn chạy 8 Pod osrm-routed trên cùng một Worker Node máy chủ (ví dụ AWS r6i.16xlarge 512GB RAM) để tận dụng đa lõi CPU, mỗi Pod nạp riêng một bản sao 40GB. Bạn sẽ tiêu tốn 320GB RAM vật lý chỉ để chứa 8 bản sao giống hệt nhau của cùng một tệp bản đồ.
4. Bế Tắc Khi Cập Nhật Dữ Liệu Giao Thông (Live Traffic): Tình trạng tắc đường thay đổi từng phút. Khởi động lại Pod để nạp dữ liệu giao thông mới đồng nghĩa với việc gây gián đoạn dịch vụ và làm rơi các request của tài xế.

Giải pháp kiến trúc hoàn hảo cho bài toán này là Tận dụng POSIX IPC Shared Memory kết hợp với thuật toán MLD (Multi-Level Dijkstra).

graph TB
    subgraph K8sWorkerNode ["Kubernetes Worker Node (AWS r6i.8xlarge)"]
        subgraph SharedMemSpace ["POSIX IPC Shared Memory (/dev/shm - tmpfs)"]
            ActiveBlock["Active Block 1 (45GB RAM)<br/>Đồ thị bản đồ hiện tại + Live Traffic v1"]
            InactiveBlock["Staging Block 2 (45GB RAM)<br/>Đang nạp Live Traffic v2 mới"]
        end

        subgraph PodReplicas ["Nhóm Pods OSRM-Routed (Cùng chia sẻ 1 IPC Namespace)"]
            Pod1["Pod 1 (osrm-routed --shared-memory)"]
            Pod2["Pod 2 (osrm-routed --shared-memory)"]
            Pod3["Pod 3 (osrm-routed --shared-memory)"]
            PodN["Pod N (osrm-routed --shared-memory)"]
        end

        subgraph SidecarAgent ["Bộ Điều Phối Tự Động (Sidecar Agent)"]
            UpdateAgent["Go Update Agent (Lắng nghe tín hiệu EFS)"]
            DatastoreCLI["osrm-datastore (Thực thi Atomic Pointer Swap)"]
        end
    end

    subgraph StorageLayer ["Tầng Lưu Trữ Chia Sẻ (Shared Storage)"]
        EFS["AWS EFS / CephFS Volume<br/>(Chứa tệp bản đồ .osrm mới nhất)"]
        TrafficFeed["TomTom / OpenTraffic CSV Stream (5 phút/lần)"]
    end

    TrafficFeed --> EFS
    EFS -.->|Theo dõi thay đổi| UpdateAgent
    UpdateAgent -->|Gọi lệnh nạp| DatastoreCLI
    DatastoreCLI -->|Nạp dữ liệu vào| InactiveBlock
    DatastoreCLI -->|Gửi tín hiệu IPC| ActiveBlock

    ActiveBlock === Pod1
    ActiveBlock === Pod2
    ActiveBlock === Pod3
    ActiveBlock === PodN

2. Nguyên Lý Hoạt Động Của OSRM Shared Memory & Atomic Pointer Swap

Thay vì để từng tiến trình tự cấp phát bộ nhớ Heap riêng biệt, OSRM cung cấp công cụ osrm-datastore tận dụng giao tiếp liên tiến trình của nhân Linux (POSIX IPC Shared Memory qua syscalls shmget, shmat).

Cơ Chế Ánh Xạ Bộ Nhớ Không Tốn RAM

1. Khi osrm-datastore chạy, nó đọc tệp đồ thị từ đĩa và nạp trực tiếp vào phân đoạn bộ nhớ ảo của hệ điều hành Linux tại không gian /dev/shm (được gắn dưới dạng tmpfs).
2. Sau đó, tất cả các tiến trình osrm-routed được khởi chạy với cờ --shared-memory=true.
3. Lúc này, tiến trình API server không cấp phát thêm bất kỳ byte RAM nào cho đồ thị; nó chỉ đơn thuần gọi shmat() để ánh xạ con trỏ bộ nhớ ảo của nó vào phân đoạn shared memory đã có sẵn.
4. Thời gian khởi động của Pod giảm từ 10 phút xuống chỉ còn dưới 0.5 giây! Bạn có thể triển khai hàng chục replicas trên một Node mà tổng dung lượng RAM tiêu tốn cho đồ thị vẫn chỉ là 40GB duy nhất.

Hoán Đổi Con Trỏ Nguyên Tử (Atomic Pointer Swapping)

Làm thế nào để cập nhật dữ liệu Live Traffic mà không làm đứt kết nối của các request đang xử lý dở?

1. osrm-datastore yêu cầu nhân Linux cấp phát một phân đoạn Shared Memory thứ hai (Staging Block) nằm song song với khối nhớ đang phục vụ (Active Block).
2. Tệp đồ thị mới cùng các trọng số giao thông cập nhật được nạp đầy đủ vào Staging Block.
3. Sau khi hoàn tất kiểm tra tính toàn vẹn (checksum validation), osrm-datastore thực hiện một Atomic Pointer Swap (Hoán đổi con trỏ nguyên tử) trên bảng phân đoạn IPC.
4. Mọi HTTP request mới đến sau thời điểm này sẽ lập tức đọc dữ liệu từ khối nhớ mới.
5. Khối nhớ cũ được đánh dấu là “mồ côi” (orphaned). Nhân Linux sẽ tự động giải phóng khối nhớ này ngay khi request cuối cùng đang đọc nó kết thúc.

sequenceDiagram
    autonumber
    participant EFS as AWS EFS Storage
    participant Agent as Go Sidecar Agent
    participant DS as osrm-datastore
    participant SHM as Linux /dev/shm (IPC)
    participant Routed as osrm-routed (API Replicas)
    participant Client as Traffic API Client

    EFS->>Agent: Phát hiện tệp vietnam.osrm.mld cập nhật timestamp
    Agent->>DS: Kích hoạt: osrm-datastore --spring-clean=false vietnam.osrm
    DS->>SHM: Cấp phát Segment B (Staging Block 45GB)
    DS->>SHM: Nạp dữ liệu đồ thị + Trọng số tốc độ xe mới
    Note over DS,SHM: Segment A (Active) vẫn đang phục vụ Client bình thường
    Client->>Routed: GET /route/v1/driving/106.6,10.7,106.7,10.8
    Routed->>SHM: Đọc đồ thị từ Segment A

    DS->>SHM: THỰC THI ATOMIC POINTER SWAP (Segment B -> Active)
    Note over SHM: Hoán đổi con trỏ diễn ra trong < 1 microsecond!
    
    Client->>Routed: GET /route/v1/driving/106.6,10.7,106.7,10.8 (Request mới)
    Routed->>SHM: Đọc đồ thị từ Segment B (Đã cập nhật Live Traffic)
    Note over SHM: Segment A tự động hủy khi hết request cũ

3. Thuật Toán MLD (Multi-Level Dijkstra) vs. CH (Contraction Hierarchies)

Để cập nhật dữ liệu tắc đường theo thời gian thực (ví dụ 3 đến 5 phút một lần), việc sử dụng thuật toán Multi-Level Dijkstra (MLD) là điều kiện bắt buộc.

Nhờ cơ chế phân hoạch ô, khi có sự cố kẹt xe hoặc đóng đường, ta chỉ cần chạy lệnh osrm-customize với một tệp CSV chứa tốc độ thực tế của từng đoạn đường (Edge Speeds). Quá trình này chỉ mất từ 15 đến 30 giây thay vì phải chạy lại toàn bộ đồ thị từ đầu.

4. Triển Khai Thực Chiến Trên Kubernetes: Cấu Hình Pod Spec Đa Container

Để hai container trong cùng một Pod có thể chia sẻ bộ nhớ IPC qua /dev/shm, Kubernetes bắt buộc phải có 2 thiết lập cốt lõi:

1. shareProcessNamespace: true: Cho phép các container nhìn thấy Process ID (PID) và chia sẻ IPC Namespace của nhau.
2. Volume mount emptyDir với medium: Memory: Đảm bảo /dev/shm được lưu trữ trên RAM ảo (tmpfs) của Worker Node, không bị ghi xuống đĩa cứng EBS.

Tệp Manifest Triển Khai Kubernetes Chuẩn Production (osrm-k8s-deployment.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: osrm-routing-service
  namespace: logistics
  labels:
    app: osrm-routing
    algorithm: mld
spec:
  replicas: 4
  selector:
    matchLabels:
      app: osrm-routing
  template:
    metadata:
      labels:
        app: osrm-routing
    spec:
      # 1. BẮT BUỘC: Chia sẻ Process Namespace để sử dụng chung IPC POSIX Shared Memory
      shareProcessNamespace: true
      
      # Gán Pod vào nhóm node tối ưu bộ nhớ (Memory-Optimized Node Group)
      nodeSelector:
        node.kubernetes.io/instance-type: r6i.8xlarge
      
      volumes:
      # 2. BẮT BUỘC: Mount /dev/shm vào RAM ảo (tmpfs) với giới hạn kích thước an toàn
      - name: dshm
        emptyDir:
          medium: Memory
          sizeLimit: "60Gi"
      - name: map-storage
        persistentVolumeClaim:
          claimName: efs-map-pvc

      containers:
      # CONTAINER 1: OSRM ROUTED API ENGINE
      - name: osrm-routed
        image: ghcr.io/project-osrm/osrm-backend:v5.27.1
        imagePullPolicy: IfNotPresent
        # Chạy ở chế độ lắng nghe Shared Memory
        command: ["osrm-routed"]
        args:
          - "--shared-memory=true"
          - "--algorithm=mld"
          - "--max-table-size=1000"
          - "--threads=8"
        ports:
          - name: http-api
            containerPort: 5000
        resources:
          requests:
            cpu: "4000m"
            memory: "2Gi" # Chỉ cần ít RAM vì đồ thị đã nằm trong /dev/shm chung
          limits:
            cpu: "8000m"
            memory: "8Gi"
        volumeMounts:
          - name: dshm
            mountPath: /dev/shm
        readinessProbe:
          httpGet:
            path: /nearest/v1/driving/106.660172,10.762622
            port: 5000
          initialDelaySeconds: 2
          periodSeconds: 5
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /nearest/v1/driving/106.660172,10.762622
            port: 5000
          initialDelaySeconds: 5
          periodSeconds: 10

      # CONTAINER 2: SIDECAR UPDATE AGENT (GOLANG)
      - name: osrm-update-agent
        image: internal-registry.tanhdev.com/osrm-update-agent:v1.2.0
        env:
          - name: MAP_PATH
            value: "/data/vietnam-latest.osrm"
          - name: POLL_INTERVAL_SECONDS
            value: "30"
        resources:
          requests:
            cpu: "200m"
            memory: "256Mi"
          limits:
            cpu: "2000m"
            memory: "2Gi"
        volumeMounts:
          - name: dshm
            mountPath: /dev/shm
          - name: map-storage
            mountPath: /data
            readOnly: true

5. Triển Khai Sidecar Update Agent Bằng Golang (cmd/agent/main.go)

Dưới đây là mã nguồn Go hoàn chỉnh cho Sidecar Container. Agent có nhiệm vụ theo dõi tệp bản đồ trên EFS, kích hoạt osrm-datastore nạp dữ liệu mới vào Staging Block và dọn dẹp các phân đoạn nhớ mồ côi:

package main

import (
	"context"
	"fmt"
	"log"
	"os"
	"os/exec"
	"os/signal"
	"syscall"
	"time"
)

type AgentConfig struct {
	MapFilePath  string
	PollInterval time.Duration
}

func main() {
	mapPath := os.Getenv("MAP_PATH")
	if mapPath == "" {
		mapPath = "/data/vietnam-latest.osrm"
	}

	cfg := AgentConfig{
		MapFilePath:  mapPath,
		PollInterval: 30 * time.Second,
	}

	log.Printf("Khởi động OSRM Update Agent. Theo dõi tệp: %s", cfg.MapFilePath)

	ctx, stop := signal.NotifyContext(context.Background(), syscall.SIGTERM, syscall.SIGINT)
	defer stop()

	var lastModTime time.Time

	// 1. Kiểm tra và nạp dữ liệu bản đồ lần đầu tiên khi Pod mới khởi động
	if info, err := os.Stat(cfg.MapFilePath); err == nil {
		log.Println("Nạp bản đồ khởi đầu vào POSIX Shared Memory...")
		if err := runOsrmDatastore(ctx, cfg.MapFilePath); err != nil {
			log.Fatalf("Lỗi nạp bản đồ lần đầu: %v", err)
		}
		lastModTime = info.ModTime()
	} else {
		log.Fatalf("Không tìm thấy tệp bản đồ tại %s: %v", cfg.MapFilePath, err)
	}

	ticker := time.NewTicker(cfg.PollInterval)
	defer ticker.Stop()

	// 2. Vòng lặp theo dõi bản cập nhật Live Traffic
	for {
		select {
		case <-ctx.Done():
			log.Println("Đang dừng OSRM Update Agent an toàn...")
			return
		case <-ticker.C:
			info, err := os.Stat(cfg.MapFilePath)
			if err != nil {
				log.Printf("Cảnh báo: Không thể đọc thông tin tệp bản đồ: %v", err)
				continue
			}

			if info.ModTime().After(lastModTime) {
				log.Printf("Phát hiện bản đồ mới cập nhật (Timestamp: %s). Tiến hành Atomic Pointer Swap...", info.ModTime())
				
				if err := runOsrmDatastore(ctx, cfg.MapFilePath); err != nil {
					log.Printf("LỖI: Cập nhật shared memory thất bại: %v", err)
				} else {
					lastModTime = info.ModTime()
					log.Println("Atomic Pointer Swap thành công! Dữ liệu Live Traffic đã được kích hoạt.")
					// Dọn dẹp các segment IPC mồ côi sau khi chuyển đổi
					cleanupOrphanSegments()
				}
			}
		}
	}
}

// runOsrmDatastore thực thi binary osrm-datastore để nạp dữ liệu vào block mới
func runOsrmDatastore(ctx context.Context, mapFile string) error {
	cmd := exec.CommandContext(ctx, "osrm-datastore", "--spring-clean=false", mapFile)
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr
	return cmd.Run()
}

// cleanupOrphanSegments dọn dẹp các phân đoạn bộ nhớ chia sẻ không còn tiến trình nào gắn kết
func cleanupOrphanSegments() {
	cmd := exec.Command("sh", "-c", "ipcs -m | awk '$6 == 0 {print $2}' | xargs -r ipcrm -m")
	if out, err := cmd.CombinedOutput(); err != nil {
		log.Printf("Cảnh báo dọn dẹp orphan IPC: %v, output: %s", err, string(out))
	}
}

6. Giám Sát Sức Khỏe Bộ Nhớ & Cảnh Báo Prometheus (osrm-alerts.yaml)

Khi vận hành Shared Memory trên Kubernetes, mối nguy hiểm lớn nhất là Rò rỉ phân đoạn IPC (Orphaned IPC Segments Leak) khiến /dev/shm chạm ngưỡng sizeLimit, dẫn đến việc Kubernetes gửi tín hiệu SIGKILL (OOMKill) hủy diệt toàn bộ Pod.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: osrm-shared-memory-alerts
  namespace: logistics
spec:
  groups:
  - name: osrm.memory.rules
    rules:
    # 1. Cảnh báo nguy cơ đầy bộ nhớ /dev/shm (>85% dung lượng)
    - alert: OSRMSharedMemoryHighUtilization
      expr: |
        container_memory_working_set_bytes{container="osrm-routed"} 
        / 
        container_spec_memory_limit_bytes{container="osrm-routed"} > 0.85
      for: 2m
      labels:
        severity: critical
        team: platform-sre
      annotations:
        summary: "Dung lượng Shared Memory của OSRM chạm ngưỡng báo động"
        description: "Pod {{ $labels.pod }} đang sử dụng hơn 85% hạn mức /dev/shm. Nguy cơ bị OOMKill trong ít phút tới."

    # 2. Cảnh báo phát hiện phân đoạn nhớ mồ côi không được giải phóng
    - alert: OSRMOrphanedIPCSegmentsDetected
      expr: node_memory_Shmem_bytes > 90000000000 # Lớn hơn 90GB (gấp đôi kích thước bản đồ chuẩn)
      for: 5m
      labels:
        severity: warning
        team: logistics-infra
      annotations:
        summary: "Phát hiện phân đoạn IPC mồ côi rò rỉ trên Worker Node"
        description: "Dung lượng Shared Memory trên node {{ $labels.instance }} vượt ngưỡng 90GB. Cần chạy dọn dẹp ipcrm ngay lập tức."

    # 3. Cảnh báo độ trễ Routing API tăng vọt (P99 > 25ms)
    - alert: OSRMHighLatencyP99
      expr: |
        histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{job="osrm-routing"}[2m])) by (le)) > 0.025
      for: 1m
      labels:
        severity: critical
      annotations:
        summary: "Độ trễ P99 định tuyến vượt quá SLA 25ms"
        description: "Hệ thống định tuyến OSRM đang bị nghẽn CPU hoặc tranh chấp khóa đọc bộ nhớ chia sẻ."

7. Bảng So Sánh Hiệu Năng & Chi Phí Vận Hành Thực Tế

8. Kết Luận: Chuẩn Hóa Hạ Tầng Định Tuyến Cho Logistics 2026

Bằng việc kết hợp POSIX IPC Shared Memory (/dev/shm), thuật toán Multi-Level Dijkstra (MLD) và bộ điều phối Sidecar Agent tự động bằng Golang, các nền tảng logistics và gọi xe có thể làm chủ hoàn toàn hạ tầng bản đồ của mình:

1. Đảm bảo tốc độ tính toán tuyến đường tức thì với độ trễ P99 dưới 10ms.
2. Tiết kiệm hàng chục nghìn USD tiền thuê máy chủ RAM dung lượng lớn mỗi năm.
3. Cung cấp lộ trình di chuyển chính xác nhất cho tài xế nhờ dữ liệu giao thông được cập nhật liên tục 5 phút một lần mà không gây ra bất kỳ giây phút gián đoạn dịch vụ nào.

🔗 Tài Liệu & Chuyên Đề Chuyên Sâu Liên Quan:

• Map Matching Xử Lý Nhiễu GPS Urban Canyon: HMM & Kafka
• GraphHopper vs OSRM: Đối Chiếu Đánh Đổi Kiến Trúc Hệ Thống Định Tuyến
• Kiến Trúc Đội Xe Logistics CVRP & Thuật Toán ALNS Bằng Golang
• Tối Ưu Hóa Dynamic Surge Pricing Trong Hệ Thống Gọi Xe Thời Gian Thực

❓ Câu Hỏi Thường Gặp (FAQ)