24/7 백그라운드 클라우드 동작 원리

DashCloud는 일반적인 웹 호스팅(Vercel, Netlify)이나 범용 클라우드 가상머신(AWS EC2, VPS)과는 완전히 다른 **"상시 실행 백그라운드 워커"**에 특화된 전용 클라우드 아키텍처를 기반으로 설계되었습니다.

HTTP 요청이 들어왔을 때만 잠깐 켜지는 서버리스 함수로는 24시간 텔레그램 롱폴링을 유지하거나 실시간 거래소 웹소켓을 끊김 없이 감시할 수 없습니다. DashCloud가 어떤 인프라 설계로 꺼지지 않는 안정성을 제공하는지 상세히 알아봅니다.

전체 시스템 구조 (2-Tier 분리 아키텍처)

DashCloud는 시스템의 안정성과 보안을 극대화하기 위해 컨트롤 플레인 제어 계층과 워커 실행 인프라 계층을 물리적으로 엄격하게 분리하여 운영합니다.

[ 사용자 브라우저 / CLI / MCP ]
           │ (TLS 1.3 암호화 통신)
           ▼
┌─────────────────────────────────────────────────────────────┐
│ 컨트롤 플레인 API (Control Plane)                           │
│ ├─ 사용자 인증 및 대시보드 UI (Next.js 15 App Router)        │
│ ├─ 목표 상태 관리 데이터베이스                               │
│ ├─ AES-256-GCM 시크릿 암호화 스토리지                       │
│ └─ 5초 실시간 웹소켓 메트릭 및 로그 브로드캐스트              │
└─────────────────────────────────────────────────────────────┘
           │ (전자 서명 기반 내부 전용 통신망)
           ▼
┌─────────────────────────────────────────────────────────────┐
│ 실행 인프라 계층 (워커 노드 클러스터)                      │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ DashCloud Node Daemon (호스트 관리 데몬)                │ │
│ │ ├─ 컨테이너 라이프사이클 감시 및 자동 무중단 복구     │ │
│ │ ├─ 리소스(CPU/RAM) 실시간 측정 및 cgroup 제어          │ │
│ │ └─ 좀비 자식 프로세스 자동 감지 및 정리                 │ │
│ └─────────────────────────────────────────────────────────┘ │
│         │                                                   │
│         ├─► [ 프로젝트 A: 격리 샌드박스 ] ──► [/app 영구 볼륨]│
│         ├─► [ 프로젝트 B: 격리 샌드박스 ] ──► [/app 영구 볼륨]│
│         └─► [ 프로젝트 C: 격리 샌드박스 ] ──► [/app 영구 볼륨]│
└─────────────────────────────────────────────────────────────┘

1. 컨트롤 플레인 제어 계층

• 사용자의 웹 브라우저, 로컬 CLI(npx dashcloud deploy), Cursor/Claude Desktop의 MCP 서버와 통신합니다.
• 사용자가 요청한 설정(원하는 런타임, 환경변수, 깃 저장소)을 데이터베이스에 목표 상태로 기록합니다.
• 환경변수와 API 토큰은 데이터베이스 저장 즉시 AES-256-GCM 방식으로 암호화됩니다.

2. 워커 실행 노드 계층

• 실제 봇과 크롤러 프로세스가 가동되는 고성능 클라우드 노드 클러스터입니다.
• 호스트 상주 노드 데몬이 제어 플레인의 명령을 받아 격리된 컨테이너 샌드박스를 생성, 기동, 중지합니다.
• 제어 플레인이 일시적인 점검이나 배포에 들어가더라도, 실행 노드에서 돌고 있는 사용자의 봇 프로세스는 1초의 중단도 없이 계속 실행됩니다.

웹 호스팅과 백그라운드 런타임 분업 모델

최신 클라우드 생태계에서 가장 권장되는 개발 패턴은 도메인별 강점을 지닌 플랫폼을 조합하는 것입니다.

컨테이너 생명주기와 상태 머신

모든 프로젝트는 생성부터 종료까지 엄격한 상태 머신에 따라 관리됩니다.

[ 배포 트리거 ] ──► QUEUED (대기열 진입)
                        │
                        ▼
                    BUILDING (의존성 패키지 설치)
                        │
         ┌──────────────┴──────────────┐
      (빌드 성공)                    (빌드 실패)
         ▼                             ▼
      RUNNING (정상 실행)             FAILED (빌드 에러 로그 출력)
         │
    ┌────┴───────────────────────────┐
    │                                │
 (정상 중지 요청)              (예기치 않은 예외/메모리 초과)
    ▼                                ▼
  STOPPED (정상 중지)             CRASHED / OOM_KILLED
                                     │
                                     ▼ (웹훅 비상 경보 발송)

1. 배포 & 의존성 설치

• 사용자가 새 코드를 배포하면 데몬이 코드를 프로젝트 볼륨(/app)에 반영하고, 매니페스트 변경을 감지했을 때만 의존성을 설치합니다 (requirements.txt/package.json 해시를 .deps.hash에 기록해 재시작 시 재설치를 건너뜀).
• 설치는 별도의 일회성 설치 컨테이너(메모리/CPU 무제한, 네트워크 격리 동일 적용)에서 실행되어 저사양 봇도 OOM 없이 빌드할 수 있습니다. 설치 실패는 치명적이지 않으며 다음 부팅에서 자동 재시도됩니다.
• 런타임은 고정 이미지(Python 3.11/3.12, Node 20/22, Chromium, Quant)로 제공되며, 대시보드 설정에서 런타임을 전환할 수 있습니다(전환 시 컨테이너 재생성 + 의존성 재설치).

2. RUNNING

• 의존성 설치가 끝나면 /app 디렉터리(영구 볼륨)가 연결된 상태로 메인 진입점 프로세스가 기동됩니다.
• 호스트 데몬이 컨테이너 상태를 실시간 감시하며 메트릭을 수집합니다.

3. CRASHED & OOM_KILLED

• 프로세스가 처리되지 않은 예외로 중단되거나 메모리 한도에 도달해 강제 종료된 상태입니다.
• DashCloud는 비정상 종료를 즉시 감지해 상태를 갱신하고, 설정된 Discord/Telegram 웹훅으로 알림을 발송합니다.
• 크래시 시 1회 자동 재시작이 시도되며(노드 설정에 따라 비활성화 가능), 재시작 한도를 소진하면 CRASHED로 정지합니다. 재시작 후 정상 기동되면 이전 크래시 이벤트는 해결됨으로 표시되어 콘솔 진단 배너가 다시 뜨지 않습니다.

보안 샌드박스와 제로 인바운드 포트 설계

DashCloud는 멀티 테넌트 환경에서 보안 사고를 원천 차단하기 위해 3단계 격리 정책을 시행합니다.

1. 커널 레벨 격리와 리소스 격리

• 모든 프로젝트는 독립된 리눅스 네임스페이스(PID, Mount, Network, IPC) 및 cgroups v2로 하드웨어 자원이 엄격하게 격리됩니다.
• 한 사용자의 프로젝트에서 메모리 누수가 발생하거나 CPU를 100% 점유하더라도, 물리적으로 인접한 다른 사용자의 프로젝트에는 어떠한 성능 저하나 간섭도 발생하지 않습니다.

2. 제로 인바운드 포트 보안

• 일반적인 웹 서버와 달리, 텔레그램 롱폴링 봇이나 크롤러, 퀀트 프로그램은 외부에서 접속해 들어오는 인바운드 포트(예: 80, 443, 8080)를 열 필요가 전혀 없습니다.
• DashCloud는 컨테이너의 모든 인바운드 수신 포트를 기본적으로 전면 차단합니다.
• 외부의 무차별적인 DDoS 공격, 포트 스캐닝, 제로데이 원격 코드 실행 침투 시도가 물리적으로 불가능합니다.
• 오직 봇 내부에서 텔레그램이나 거래소, 타깃 웹사이트로 나가는 **아웃바운드 암호화 연결(HTTPS/WSS 443)**만을 허용합니다.

3. 좀비 프로세스 자동 정리

• Playwright나 Selenium 크롤러를 실행할 때 메인 파이썬 스크립트가 비정상 종료되면, 백그라운드에 수십 개의 Chromium 브라우저 프로세스가 숨겨진 채 남아 메모리를 갉아먹는 문제가 흔히 발생합니다.
• DashCloud 데몬은 프로젝트 종료 시 해당 cgroup 하위의 모든 자식 및 손자 프로세스 트리를 추적하여 메모리에 남지 않도록 깔끔하게 전수 정리합니다.

영구 스토리지 마운트 구조 (/app)

일반 PaaS나 클라우드 샌드박스는 컨테이너가 재부팅되면 로컬에 저장했던 파일이 모두 날아가는 휘발성 에페머럴 파일시스템을 사용합니다. DashCloud는 이를 방지하고자 물리 볼륨 매핑을 기본 탑재했습니다.

• HOME=/app: ~와 /home/container 모두 /app을 가리키므로 Wings 시절 코드의 경로가 그대로 동작합니다.
• /app 디렉터리 보존: 코드가 파일을 /app 또는 상대경로(./data/...)에 기록하면, 새 코드를 배포하거나 서버가 재시작되어도 데이터가 100% 손실 없이 보존됩니다.
• 대시보드 웹 파일 관리자: 대시보드의 파일 메뉴를 통해 언제든지 웹 브라우저에서 서버 내부의 SQLite DB 파일이나 수집된 CSV 파일을 확인하고 원클릭으로 로컬 컴퓨터에 다운로드할 수 있습니다.

메트릭 수집 및 128kbps 소프트 대역폭 정책

1. 실시간 텔레메트리 (5초 주기)

• 호스트 데몬은 가동 중인 컨테이너의 vCPU 사용률, 물리 메모리 RSS 점유량, 네트워크 수신/송신량을 5초마다 측정합니다.
• 대시보드 화면에 실시간 차트로 렌더링되며 최대 7일간의 히스토리가 보관되어 성능 병목을 쉽게 진단할 수 있습니다.

2. 128kbps 소프트 스로틀링 (생존성 보장)

• 타사 플랫폼(Railway, Heroku 등)은 월간 무료 대역폭이나 크레딧을 초과하면 프로젝트를 즉시 강제 중단(Freeze/Terminate)시켜 서비스가 마비됩니다.
• DashCloud는 월간 트래픽 한도를 초과하더라도 프로젝트를 강제 종료하지 않습니다.
• 네트워크 대역폭을 128kbps로 완만하게 대역폭을 감속하여, 대용량 이미지 다운로드는 느려지더라도 텔레그램 텍스트 메시지 송수신이나 긴급 청산 주문 같은 핵심 봇 기능은 정상 동작을 유지할 수 있도록 생존성을 최우선으로 보장합니다.

다음 추천 문서