연구자료실
설비 연결, 품질 검사, 생산 분석과 제조 업무에 관련된 외부 논문입니다.
연구자료 검색
논문 목록
T13. 엣지 AI, 스트리밍 추론, 자원 스케줄링
- T13-2유사문제
Live Video Analytics at Scale with Approximation and Delay-Tolerance
VideoStorm
한국어 검토 보기
해결 문제
- 카메라 수천 대에서 들어오는 영상 질의를 한 클러스터에서 다 돌려야 한다.
- 질의마다 정확도 요구와 지연 허용치가 다른데, 자원을 똑같이 나눠 주면 둘 다 못 맞춘다.
핵심 구조
- 질의별로 설정값을 바꿔가며 자원과 품질의 관계를 미리 잰다(자원 품질 프로파일).
- 이 프로파일을 온라인 스케줄러에 넘긴다.
- 공평 분배 대신 품질과 지연 두 목표를 같이 최대화하도록 자원을 배분한다.
주요 결과
- Azure 101대 클러스터에 올려 실제 교통 카메라 영상을 처리했다.
- 실제 질의 품질을 최대 80% 개선했다.
- 지연(lag)은 7배 좋아졌다.
한계
- 사전 프로파일링이 필요하다. 질의가 새로 생기면 다시 재야 한다.
- 정확도 측정 기준을 만들려면 비교용 정답 데이터가 있어야 한다.
우리 기능과의 관계
- 영상 안전 판단을 여러 라인에서 동시에 돌릴 때 정확도와 자원을 한 저울에 놓고 배분하는 문제와 같은 문제다.
- 이 주제의 출발점 논문이다. 아래 AWStream, Chameleon, Reducto가 이 문제를 이어받는다.
- T13-3유사문제
AWStream: Adaptive Wide-Area Streaming Analytics
AWStream
한국어 검토 보기
해결 문제
- 공장이나 원격지에서 중앙으로 보내는 회선은 대역폭이 좁고 들쭉날쭉하다.
- 그냥 TCP로 보내면 지연이 쌓이고, UDP로 보내면 정확도가 떨어진다.
핵심 구조
- 해상도, 프레임 수, 품질 같은 조절 손잡이를 미리 프로파일링한다.
- 정확도와 대역폭의 맞바꿈 곡선을 만든다.
- 실행 중 대역폭 변화를 감지해 곡선 위에서 설정을 바꾼다.
주요 결과
- 같은 대역폭에서 정확도를 유지하면서 지연을 크게 줄였다.
- 비적응 방식 대비 지연과 정확도 양쪽에서 유리한 지점을 확보했다.
한계
- 사전 프로파일링 비용이 든다.
- 데이터 분포가 프로파일링 때와 달라지면 곡선이 어긋난다.
우리 기능과의 관계
- 영상 안전 판단과 설비 데이터를 현장에서 서버로 올릴 때 회선이 좁아도 정확도를 지키는 문제와 같은 문제다.
- T13-4유사문제
Chameleon: Scalable Adaptation of Video Analytics
Chameleon
한국어 검토 보기
해결 문제
- 영상 추론 설정값(해상도, 프레임 수, 모델 크기)의 최적값이 시간마다 바뀐다.
- 그렇다고 자주 다시 찾으면 탐색 비용이 절약분을 다 까먹는다.
핵심 구조
- 최적 설정을 좌우하는 요인(물체 속도, 크기 등)이 시간과 공간으로 이어져 있다는 점을 쓴다.
- 그래서 탐색 비용을 시간에 걸쳐, 그리고 여러 카메라에 걸쳐 나눠 부담시킨다.
- 그 위에서 설정값을 계속 바꿔가며 맞춘다.
주요 결과
- 교통 카메라 5대 영상으로 실험했다.
- 오프라인에서 고른 고정 최적 설정 대비, 같은 자원으로 정확도를 20~50% 높였다.
- 또는 같은 정확도를 자원 30~50%만으로 냈다(2~3배 속도 향상).
한계
- 장면 사이 상관성이 약하면 탐색 비용 분담 효과가 줄어든다.
- 설정 후보 공간을 미리 정해 둬야 한다.
우리 기능과의 관계
- 라인마다 조명과 속도가 다른 현장에서 영상 추론 설정을 계속 다시 맞추는 문제와 같은 문제다.
- AWStream, Reducto와 한 묶음으로 읽어야 한다.
- T13-5유사문제
Reducto: On-Camera Filtering for Resource-Efficient Real-Time Video Analytics
Reducto
한국어 검토 보기
해결 문제
- 영상 질의는 대부분의 프레임이 쓸모없는데도 전부 서버로 보내면 낭비가 크다.
- 실시간 응답을 지키려면 앞단에서 걸러야 한다.
핵심 구조
- 카메라에서 값싼 저수준 특징(픽셀 차이, 엣지 변화 등)만 계산한다.
- 질의 종류와 목표 정확도에 맞춰 필터 임계값을 동적으로 정한다.
- 변화가 없는 프레임은 아예 보내지 않는다.
주요 결과
- 목표 정확도를 지키면서 전송 프레임 수와 서버 연산을 크게 줄였다.
- 실시간 질의 응답 지연이 기존 방식보다 짧아졌다.
한계
- 값싼 특징으로 판별이 어려운 질의는 필터 효과가 떨어진다.
- 임계값 튜닝이 장면과 질의에 민감하다.
우리 기능과의 관계
- 영상 안전 판단에서 카메라 단에서 무의미한 프레임을 걸러 서버 비용을 줄이는 구조에 대응한다.
- T13-18유사문제
MillWheel: Fault-Tolerant Stream Processing at Internet Scale
MillWheel
한국어 검토 보기
해결 문제
- 끊임없이 들어오는 데이터를 지연 짧게 처리해야 한다.
- 그런데 장비는 고장 나고 데이터는 늦게 도착한다.
- 개발자가 상태 저장과 장애 복구를 매번 직접 짜면 감당이 안 된다.
핵심 구조
- 계산을 방향 그래프로 표현한다. 사용자는 노드마다 처리 코드만 쓴다.
- 상태 저장과 레코드 전달, 장애 복구는 프레임워크가 맡는다.
- 레코드마다 한 번만 처리되도록 보장한다.
- 워터마크(low watermark)로 어느 시각까지의 데이터가 다 들어왔는지 판단한다.
주요 결과
- 구글 사내에서 널리 쓰였다. 연속 이상 탐지기 사례로 쓰임새를 보였다.
- 워터마크 개념을 스트리밍 처리 시스템에 도입했다.
한계
- 2013년 사내 시스템 논문이다. 공개 구현체가 아니다.
- 이벤트 시각 기준 구간 처리와 결과 내보내는 시점의 의미론이 아직 정리되기 전이다. 그 정리는 아래 19번이 한다.
우리 기능과의 관계
- 아래 19번 Dataflow Model의 직계 선행 연구다. 워터마크 개념이 여기서 나왔다.
- 설비 데이터 수집에서 신호가 늦게 오거나 장비가 죽어도 집계를 빠뜨리지 않는 문제와 같은 문제다.
- T13-19유사문제
The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing
Dataflow Model
한국어 검토 보기
해결 문제
- 끝이 없는 데이터 흐름을 유한한 배치로 억지로 나누면 정확도가 깨진다.
- 데이터가 순서 없이 늦게 도착하는 상황을 다뤄야 한다.
핵심 구조
- 계산 내용, 이벤트 시각 기준 구간, 결과를 내보내는 시점, 늦게 온 데이터의 처리 방식을 네 축으로 분리한다.
- 워터마크로 늦은 데이터의 도착 여부를 판단한다.
- 트리거로 중간 결과를 먼저 내보내고 나중에 수정한다.
주요 결과
- 정확도, 지연, 비용을 상황별로 조절 가능한 하나의 모델로 통합했다.
- Apache Beam과 Flink 등 이후 스트리밍 엔진 설계의 기준이 됐다.
한계
- 모델과 의미론 제시가 중심이다. 성능 벤치마크 비교는 제한적이다.
- 워터마크를 잘못 잡으면 늦은 데이터를 놓치거나 지연이 늘어난다.
우리 기능과의 관계
- 설비 데이터 수집에서 신호가 늦게 오거나 순서가 뒤바뀌어도 집계 결과를 맞게 내는 문제와 같은 문제다.
- 위 18번 MillWheel과 이어서 읽어야 한다.
연구에서 제품 적용까지
운영 중인 기능, 시범 적용과 개발 중인 기술을 구분해 정리했습니다.
보유기술 보기