개요

이 문서는 Autonotify 백엔드 시스템의 아키텍처 진화 과정을 설명합니다.

기존 아키텍처에서 발견된 구조적 한계점들과, 이를 해결하기 위해 Event Driven Architecture로 전환한 과정을 다룹니다.

1. 기존 아키텍처의 한계

기존 아키텍처는 다음과 같은 구조를 가지고 있었습니다:

graph TB
    subgraph Edge["Edge Device (Raspberry Pi)"]
        Camera["과속 카메라"]
    end

    subgraph Backend["backend (Django)"]
        API["API Handler"]
        OCR["OCR 처리<br/>(동기 실행)"]
    end

    subgraph Workers["Celery Workers"]
        CW["celery_worker<br/>(알림 전송)"]
        DLQ["celery_worker_dlq"]
    end

    Camera -->|"HTTP POST"| API
    API --> OCR
    Backend --> RMQ["RabbitMQ"]
    CW --> RMQ
    Backend --> MySQL[("MySQL")]
    CW --> MySQL

    style Backend fill:#ffcccc,stroke:#cc0000
    style OCR fill:#ff9999

이 구조에서 다음과 같은 4가지 핵심 문제가 발생했습니다.

1.1 문제 1: OCR 동기 처리로 인한 서버 처리량 저하

문제 상황

Django 서버에서 OCR을 동기적으로 처리하면서, OCR 작업이 진행되는 동안 HTTP 스레드가 점유됩니다. OCR은 이미지에서 차량 번호판을 인식하는 CPU 집약적 작업으로, 건당 약 3초가 소요됩니다.

sequenceDiagram
    participant E1 as Edge Device 1
    participant E2 as Edge Device 2
    participant D as Django Server

    E1->>D: POST /detection (이미지)
    activate D
    Note over D: OCR 처리 중 (3초)<br/>스레드 점유
    E2->>D: POST /detection (이미지)
    Note over E2: ⏳ 대기...
    D-->>E1: 200 OK
    deactivate D
    activate D
    Note over D: OCR 처리 중 (3초)
    D-->>E2: 200 OK
    deactivate D

발생하는 문제

1.2 문제 2: 느린 응답으로 인한 Edge Device 블로킹

문제 상황

서버 응답이 3초 이상 걸리면서, Edge Device(Raspberry Pi) 측에서도 연쇄적인 문제가 발생합니다. HTTP 요청을 보낸 후 응답을 기다리는 동안 Edge Device의 스레드가 블로킹됩니다.

sequenceDiagram
    participant Camera as 카메라 모듈
    participant Pi as Raspberry Pi
    participant Server as Django Server

    Camera->>Pi: 과속 차량 감지!
    Pi->>Server: HTTP POST (이미지)
    activate Pi
    Note over Pi: ⚠️ 응답 대기 중<br/>다음 감지 처리 불가
    activate Server
    Note over Server: OCR 처리 (3초)
    Server-->>Pi: 200 OK
    deactivate Server
    deactivate Pi
    Note over Pi: 이제야 다음 감지 가능