AncomWiki

CloudWorker 아키텍처 및 통신 프로토콜 설계 검토

Properties1
description이 노트는 CloudWorker 시스템의 핵심 아키텍처 변경 사항과 구현 이슈를 기록한 개발 메모이다. 주요 내용은 WebSocket을 AJAX/Rx 기반 비동기 통신으로 대체하는 타당성 검토, 연결 끊김 등 실패 시나리오에 대한 복구 전략(재큐잉, 결과 대기), Middleware의 리소스 현황 보고를 통한 Customer 측 실행 환경 결정 로직, 그리고 Provider(RP) 측의 Web Worker 기반 멀티쓰레딩 구…

38 min read

CloudWorker 아키텍처 및 통신 프로토콜 설계 검토

Source

  • Field Notes/KAIST/MNLab/cloudworker 개발 이슈.md

Summary

이 노트는 CloudWorker 시스템의 핵심 아키텍처 변경 사항과 구현 이슈를 기록한 개발 메모이다. 주요 내용은 WebSocket을 AJAX/Rx 기반 비동기 통신으로 대체하는 타당성 검토, 연결 끊김 등 실패 시나리오에 대한 복구 전략(재큐잉, 결과 대기), Middleware의 리소스 현황 보고를 통한 Customer 측 실행 환경 결정 로직, 그리고 Provider(RP) 측의 Web Worker 기반 멀티쓰레딩 구현 방식(WorkerPool 대비 단순 함수 오프로딩 모델)에 대한 고찰이다. 또한 Runner Interface의 큐 구현 유무에 대한 성능적 판단도 포함된다.

Key Points

  • 통신 프로토콜 변경: WebSocket 유지의 어려움(재접속 시 소켓 변경 등)을 이유로 Delegator-Middleware 간은 AJAX, Middleware-Provider 간은 AJAX+Rx로 변경 검토.
  • 실패 시나리오 대응: Middleware-Provider 통신 단절 시 Task 재큐잉(우선순위 조정), Customer-Middleware 통신 단절 시 Middleware 결과 홀딩 후 재전송 전략.
  • 리소스 협상 로직: Customer가 Middleware의 리소스 현황을 확인하여 외부 Worker 사용 여부를 결정하며, 리소스 부족 시 Customer 내부 실행으로 폴백.
  • Provider(RP) 구현 방식: WorkerPool(인스턴스 재사용)과 달리 CloudWorker RP는 요청당 Runner Web Worker 생성/종료 방식으로 단순 함수 오프로딩 처리.
  • Runner Interface 큐: 태스크 밀집 시 Middleware에서 처리하므로 RP 측에는 큐 구현을 배제하고 성능 최적화 고려.

그래프 뷰

백링크