FLOPI

architecture 현재 아키텍처

FLOPI는 두 개의 독립 서비스로 구성되며, HTTP로 통신합니다.

4-Agent Pipeline 흐름

speed 현재 한계치

코드 분석 기반 추정치입니다. 실제 환경에서는 네트워크/LLM 응답 시간에 따라 변동됩니다.

build_circle 자원 추가 vs 설계 변경

위 한계치 중 일부는 자원(DB 풀, LLM 키, 메모리)을 늘리면 즉시 해결됩니다. 그러나 나머지는 아무리 자원을 투입해도 코드 구조를 바꾸지 않으면 풀리지 않는 문제입니다.

loop 싱글 이벤트 루프 — 왜 12코어인데 1코어만 쓸까?

FLOPI의 거의 모든 확장성 문제를 관통하는 핵심 원인입니다. 이 구조를 이해하면 나머지 이슈들이 왜 발생하는지 자연스럽게 이해됩니다.

1. asyncio 이벤트 루프란?

2. FLOPI에서의 문제

3. 구체적 병목 시나리오

4. 왜 워커를 늘릴 수 없는가?

5. 해결 방향

API는 멀티워커로 4코어 활용, 스케줄러는 단독 프로세스로 중복 실행 방지, NiceGUI는 현행대로 단일 프로세스. 프로세스 간 통신은 DB 큐 또는 Redis로 연결합니다.

sync_problem Fire-and-Forget 태스크 유실 CRITICAL

워크플로우와 플레이북 트리거가 결과를 추적하지 않습니다.

# detection/scheduler.py
asyncio.create_task(trigger_event_workflows(...))  # 결과 추적 없음
asyncio.create_task(trigger_playbooks(...))         # 실패해도 모름

linear_scale 4-Agent 파이프라인 순차 블로킹 CRITICAL

파이프라인 내부(Diagnostician → Advisor → Validator)는 순차 실행이지만, 여러 이상 건의 파이프라인은 asyncio.create_task()로 동시에 뜰 수 있습니다. 문제는 DB 커넥션 풀(30개, 공유) + LLM Semaphore(30) + 단일 이벤트 루프를 공유하면서 발생하는 자원 경합입니다.

storage DB 커넥션 풀 경합 (단일 풀 공유) HIGH

Oracle 커넥션 풀이 max=30으로 설정되어 있지만, Detection과 API가 동일 풀을 공유하므로 동시 부하 시 경합이 발생합니다.

web NiceGUI 프레임워크 한계 HIGH

NiceGUI는 Python만으로 빠르게 UI를 만들 수 있지만, 구조적으로 수평 확장이 불가능합니다.

1. 서버사이드 UI 상태

2. 싱글 프로세스, 싱글 코어

3. WebSocket 상시 연결

NiceGUI는 모든 클라이언트와 WebSocket을 상시 유지합니다. 이것이 @ui.refreshable, ui.timer(), emitEvent()의 작동 기반입니다.

4. 브로드캐스트 없음

# 모든 페이지에서 이런 식으로 개별 폴링
ui.timer(30.0, header_status.refresh)  # 사용자마다 30초마다 API 호출

A가 이상 처리 완료해도 B 화면에 30초 후에야 반영. 사용자 50명이면 분당 100회 동일 API 중복 호출.

api FastAPI 운영 이슈 HIGH

FastAPI 자체는 확장성이 뛰어나지만, FLOPI에서의 사용 방식에 문제가 있습니다.

1. Uvicorn 단일 워커

2. SSE 스트리밍 연결 점유

# AI Chat 스트리밍 — 응답 올 때까지 연결 유지
@router.post("/api/ai-chat/stream")
async def chat(body):
    async def generate():
        # LLM 응답 5~30초간 이 연결 유지
        yield sse_event(...)
    return EventSourceResponse(generate())

AI Chat 사용자 5명이 동시에 질문하면 SSE 연결 5개가 수십 초간 점유. 이 동안 DB 커넥션도 물고 있을 수 있어 풀 고갈에 기여.

compare NiceGUI vs SPA 비교

timer Detection 틱 60초 고정 MEDIUM

refresh UI 30초 폴링 MEDIUM

NiceGUI 대시보드의 모든 데이터가 30초 간격 HTTP 폴링으로 갱신됩니다. 사용자 50명 × 페이지 평균 2개 타이머 = 분당 200회 API 호출 (대부분 중복).

psychology LLM 라운드 제한 MEDIUM

에이전트 수가 늘면 각각의 LLM 호출이 누적되어 Gemini API rate limit에 도달할 수 있습니다.

memory 글로벌 상태 의존 MEDIUM

# 모듈 레벨 전역 변수들
_pool = None           # Oracle 커넥션 풀 (싱글톤)
_thick_done = False    # Thick client 초기화 플래그
_current_module = ""   # LLM 호출자 컨텍스트

Uvicorn 멀티워커 전환 시 각 워커가 독립된 _pool을 생성합니다. _current_module은 contextvars가 아니라 일반 변수이므로 동시 요청 간 충돌 가능.

emergency Phase 1: 안정성 확보

# 현재: 단일 풀 max=30 (Detection + API 공유)
# 개선: Detection 전용 풀과 API 전용 풀 분리
detection_pool = create_pool_async(min=2, max=15)
api_pool = create_pool_async(min=2, max=20)

-- 새 테이블
CREATE TABLE job_queue (
    id           NUMBER GENERATED ALWAYS AS IDENTITY,
    job_type     VARCHAR2(50),    -- 'workflow' | 'playbook'
    payload      CLOB,             -- JSON (anomaly_id, params...)
    status       VARCHAR2(20),    -- pending | running | completed | failed
    retry_count  NUMBER DEFAULT 0,
    max_retries  NUMBER DEFAULT 3,
    created_at   TIMESTAMP DEFAULT SYSTIMESTAMP,
    started_at   TIMESTAMP,
    completed_at TIMESTAMP,
    error_msg    VARCHAR2(1000)
);

# 에이전트당 타임아웃
result = await asyncio.wait_for(
    diagnostician.run(anomaly),
    timeout=30  # 30초 초과 시 TimeoutError
)

# 서킷브레이커 (연속 5회 실패 → 60초간 우회)
from pybreaker import CircuitBreaker
llm_breaker = CircuitBreaker(fail_max=5, reset_timeout=60)

trending_up Phase 2: 처리량 개선

# 이상 건별 파이프라인 병렬 실행
pipeline_semaphore = asyncio.Semaphore(5)

async def run_with_limit(anomaly):
    async with pipeline_semaphore:
        return await pipeline.execute(anomaly)

await asyncio.gather(*[run_with_limit(a) for a in anomalies])

cloud Phase 3: 멀티 인스턴스 확장

gavel 최종 판단

남은 이슈

해결 완료