임시저장 기능 고도화 해보기 (5)

마무리하며

앞선 글에서는 설계, CRUD(ORM), 소켓 관리, 백업에 이르기까지 각각의 고민 과정을 정리했습니다.

이번 글에서는 전체 아키텍처를 다시 한번 정리하며 연재를 마무리하려 합니다.

아키텍쳐 정리

전체적인 아키텍쳐는 이와 같다.

위 아키텍쳐를 점검하고, 아래 플로우차트로 정리해보았습니다.

flowchart TD
    subgraph User1[User 1]
        direction TB
        U1[User]
    end
    subgraph User2[User 2]
        direction TB
        U2[User]
    end

    subgraph Redis["Redis Adapter (Lock 관리, pub/sub)"]
    end

    subgraph Node["Node Cluster"]
        direction TB
        subgraph Pod1["Pod-1"]
            direction LR
            Lock1[Lock<br>submission 1 편집]
            Debounce1["Debounce"]
            SQLite1["임시 저장 데이터<br>SQLite"]
        end
        subgraph Pod2["Pod-2"]
            direction LR
            Lock2[Lock<br>submission 2 편집]
            Debounce2["Debounce"]
            SQLite2["임시 저장 데이터<br>SQLite"]
        end
    end

    subgraph Queue["Queue"]
    end

    subgraph MongoDB["MongoDB"]
    end

    subgraph S3Backup["S3버킷 백업"]
    end

    U1 -->|편집 요청| Lock1
    Lock1 --> Debounce1
    Debounce1 --> SQLite1

    U2 -->|편집 요청| Lock2
    Lock2 --> Debounce2
    Debounce2 --> SQLite2
    
	  SQLite1 -->|"@Interval('saveHistory', 50000)"| Queue
	  SQLite2 -->|"@Interval('saveHistory', 50000)"| Queue
	
    Queue -->|임시 저장업데이트 및 생성| MongoDB

    subgraph PodEvent["Pod 종료 이벤트 처리"]
        direction TB
        PodSchedule1[Pod scheduling<br>memory exceed, cpu exceed]
        PodSchedule2[Pod scheduling<br>memory exceed, cpu exceed]
        onDestroy1[onModuleDestroy, onApplicationShutdown]
        onDestroy2[onModuleDestroy, onApplicationShutdown]
    end

    Node --> PodSchedule1 --> onDestroy1
    Node --> PodSchedule2 --> onDestroy2

    onDestroy1 --> S3Backup
    onDestroy2 --> S3Backup

    subgraph SocketEvents["Socket Events"]
        heartbeat["heartbeat (socket 연결 확인)"]
        onGatewayDisconnect["onGatewayDisconnect<br>MongoDB 백업"]
    end

    heartbeat -->|연결 확인| MongoDB
    onGatewayDisconnect -->|연결 종료시 MongoDB에 임시 데이터 백업| MongoDB

    U1 -->|socket connect| SocketEvents
    U2 -->|socket connect| SocketEvents

임시 저장 액션

• 사용자가 특정 pod에 연결되어 설문조사를 편집하는 동안, 입력할 때마다 디바운스 처리하여 임시 저장을 수행합니다.
• 임시 데이터는 pod 내의 SQLite에 저장됩니다.

백업 및 소켓 관리

• 백업은 pod 내부의 인메모리 SQLite 데이터를 MongoDB로 이전하는 방식입니다.
• 5분마다 주기적으로 실행되는 Job을 큐에 등록하여 백업을 반복합니다.
• 소켓 연결이 끊어질 때, 사용자가 명시적으로 연결을 종료하거나 하트비트에 실패하는 경우에도 백업이 진행됩니다.
• pod가 종료되면 임시 저장 중인 모든 데이터가 소실되므로, pod에 연결된 모든 설문조사 데이터를 백업합니다. 이 경우에는 추가로 SQLite 데이터를 S3에도 백업합니다.

마치며

사실 임시저장 기능은 단순히 테이블이나 컬렉션을 하나 더 만들어 임시 데이터를 저장하고, 최종 제출 시 원본 데이터에 덮어쓰는 방식으로 구현할 수 있습니다.

하지만 단순한 방법에도 생각할 점이 많습니다. 데이터베이스 관점에서 디바운스 처리로 사용자가 한 글자 입력할 때마다 데이터베이스에 읽기/쓰기 요청이 발생하면, 사용자 수가 많아질 때 심각한 부하와 불필요한 데이터 누적이 발생할 수 있습니다.

사실 현재 저희 프로덕트는 아직 그 정도 트래픽이 아니지만요 ㅎㅎ

팀과 회사의 지원 덕분에 진행할 수 있었고, 더 큰 규모나 고부하 상황을 대비해 견고한 아키텍처를 설계하는 과정이 큰 도움이 되었습니다.

앞으로 운영하면서 예상치 못한 엣지 케이스를 극복하고 기능을 강화해 나가려고 하며, 빠르게 개선 사항을 반영하여 더욱 견고한 시스템을 만들어갈 계획입니다!