고성능 앱을 위한 모범 사례

이 가이드에서는 프로덕션 환경에서 효율적으로 확장되는 고성능 Tulip 애플리케이션을 설계하기 위한 모범 사례를 설명합니다. 이러한 권장 사항을 따르면 운영 규모가 확대되더라도 앱의 응답성과 안정성을 유지하는 데 도움이 됩니다.

:::(정보) (참고)
이 문서의 권장 사항은 솔루션에 Tulip API에 대한 커넥터 함수( Connector Functions) 사용이 포함된 모든 경우에 적용됩니다. 여기에는 다음이 포함됩니다:

앱 수준 트리거(예: 타이머, 버튼, 단계 진입)에서 실행되는 커넥터 함수(Connector Function) 또는 커넥터 함수 실행( API Call)
Node-RED에서 수행되는 API 호출
Tulip 솔루션 외부에서 시작된 API 호출이 포함된 스크립트
다른 시스템에서 테이블 API를 사용하여 Tulip 테이블에 데이터를 기록하는 경우
:::

고주파 트리거란 무엇입니까?

고주파 트리거는 5초마다 한 번 이상(0.2 Hz보다 빠르게) 실행됩니다. 머신 속성 이벤트, 디바이스 이벤트 및 타이머 트리거가 고주파 실행의 가장 일반적인 원인입니다.

Tulip은 앱 성능과 응답성을 유지하기 위해 트리거 실행 간격을 5초(0.2 Hz) 이상으로 유지할 것을 권장합니다.

트리거 큐에 미치는 영향

앱 트리거는 트리거 큐라고 하는 순차적 단일 스레드 큐에서 상단부터 하단으로 실행됩니다.

Trigger queue and events graphpic

큐가 효율적으로 작동하는지 여부는 다음 두 가지 요인에 의해 결정됩니다.

큐 진입 속도: 트리거 이벤트가 큐에 추가되는 빈도
큐 출구 속도: 트리거 로직이 실행을 완료하는 속도

트리거가 큐에서 빠져나가는 속도보다 더 빠르게 큐에 들어갈 경우, 큐에 트리거가 쌓이게 됩니다. 트리거 큐가 지속적으로 쌓이면 앱 지연이 발생하고, 경우에 따라 트리거 이벤트가 누락될 수도 있습니다.

트리거 빈도를 고속도로 교통 상황과 비교해 보세요. 짧은 시간 내에 너무 많은 차량이 고속도로에 진입하면 교통이 정체됩니다. 정체를 피하려면 차량이 고속도로가 수용할 수 있는 속도로 진입해야 합니다.

합산 빈도

앱 내 모든 트리거 이벤트의 합산 빈도가 전체 큐 진입 빈도를 결정합니다. 구성하는 각 트리거 이벤트는 이 합산 빈도에 추가됩니다.

합산 빈도의 예시는 아래 표를 참조하십시오:

구성	합산 빈도
1초마다 1개의 머신 속성이 업데이트됨	1Hz
1초마다 5개의 기계 속성이 업데이트됨	5Hz
기계 속성 1개(1초) + 타이머 1개(2초)	1.5Hz

트리거 로직 속도 척도

트리거 로직의 유형에 따라 트리거가 큐에서 빠져나가는 속도가 결정됩니다. 클라우드 통신, 전환 또는 외부 시스템 응답이 필요한 로직은 로컬 작업보다 실행하는 데 훨씬 더 오랜 시간이 걸립니다.

아래 표는 다양한 유형의 로직 속도를 설명합니다.

For high-frequency triggers, aim to use only logic rated Very fast or Fast.

속도	로직 유형	예시
매우 빠름	로컬 애플리케이션 로직	로컬 데이터(예: 변수) 읽기 또는 업데이트
빠름	캐시된 클라우드 데이터	이미 로드된 테이블 레코드 읽기
중간	Tulip Cloud	테이블 레코드 불러오기, 업데이트 또는 생성; 머신 상태 읽기 또는 업데이트
느림	Tulip Cloud	테이블 집계 및 쿼리
매우 느림	외부 시스템	커넥터 함수

NOTE

There is currently no easily accessible app performance log available for evaluating trigger performance. App performance can only be inferred through step times in completion records, which is useful in cases where steps involve extensive looping.

트리거 성능에 영향을 미치는 기술적 요인

로컬 하드웨어 - 트리거 로직은 로컬 하드웨어에서 실행되므로, 장치 사양은 트리거가 완료되어 큐에서 빠져나오는 속도에 결정적인 영향을 미칩니다. 장치 사양에 대해서는 Tulip Player 권장 장치를 참조하십시오.
외부 종속성 - 외부 종속성에는 클라우드 연결, 로컬 네트워크 지연 시간, ERP(전사적 자원 관리)와 같은 외부 시스템의 응답 시간이 포함됩니다.
Tulip Edge 장치를 통해 연결된 장치 - Tulip 앱은 클라우드 연결에 의존하므로 지연 시간이 발생할 수 있습니다. 예를 들어, 엣지 장치에 연결된 토크 컨트롤러도 여전히 Tulip 클라우드 서비스를 통해 Tulip Player와 통신합니다. 장치 연결을 이해하려면 Tulip 드라이버를 통한 장치 연결에 대한 다음 시퀀스 다이어그램을 참조하십시오.
커넥터 함수의 지연 문제 - 커넥터 함수를 통해 시스템(예: ERP)에서 응답이 느릴 경우, 특히 앱이 많은 레코드를 순차적으로 처리하고 각 레코드마다 최대 2초가 소요될 수 있는 API 호출이 필요한 경우 앱 지연이 발생할 수 있습니다. 시스템 연결을 이해하려면 엔터프라이즈 시스템 연결에 대한 다음 시퀀스 다이어그램을 참조하십시오.
생산 현장과 Tulip 클라우드 인프라 간의 지연 시간 - 지연 시간을 최소화하기 위해 Tulip 인스턴스는 생산 현장과 동일한 지역에 위치해야 합니다.

지침

고주파수 트리거는 피하십시오

가능한 한 고주파 트리거는 피하고, 대신 자동화( Automation)와 같은 다른 기능을 사용해야 합니다.

또한 애플리케이션 아키텍처를 재설계하여 더 낮은 빈도로 작동하도록 할 수도 있습니다. 예를 들어: * 쿼리 및 집계 기능을 활용한 데이터 보고 빈도 감소 * 비동기 사용 사례의 경우, Automations를 통해 루핑을 수행할 수 있습니다 * 동기 사용 사례의 경우, 순차적으로 수행해야 하는 루핑은 Functions를 통해 수행해야 합니다

고주파수 트리거를 반드시 사용해야 하는 경우, 트리거가 로컬 작업(예: 앱 변수 업데이트)만 실행하도록 구성해야 합니다. 그런 다음, 저주파수 트리거를 사용하여 더 느린 실행 작업(예: 테이블 레코드 업데이트)을 수행하십시오.

Tulip 앱 외부의 상황에 신속하게 대응하기 위해 고주파수 타이머 트리거를 사용하는 경우, 머신 및 디바이스 트리거가 포함된 “이벤트 스트림(Event Stream)” Tulip Machine을 활용할 수 있습니다.

Tulip 테이블 API 사용

초당 여러 번 테이블 API를 사용하여 데이터를 읽거나 쓰는 경우, 인스턴스의 성능에 영향을 미치고 데이터 읽기 또는 저장 시 지연이 발생할 수 있습니다. 아래 권장 사항은 Tulip 인스턴스에서 Tulip API를 실행하는 모든 스크립트 및 트리거 작업에 적용됩니다:

권장 사항

Tulip의 테이블 속도 제한을 준수하도록 로직 실행을 계획하십시오
테이블 내 동일한 레코드에 대한 빈번한 쓰기(초당 1회 초과)를 피하십시오

한도를 초과할 경우, Tulip은 속도 제한을 적용하고 오류 코드 429를 반환할 수 있습니다. 스크립트는 429 오류 코드에 대비하여 지연 후 재시도할 수 있도록 탄력적으로 구성되어야 합니다.

머신, 디바이스 및 타이머 트리거

간격이 짧은 타이머 트리거(1~2초마다)는 특히 타이머 트리거에 여러 API 호출(예: 테이블 쓰기 또는 커넥터 함수 실행)이 포함된 경우 앱에 과부하를 줄 수 있습니다.

Tulip no longer supports a timer trigger with <30sec frequency. For timer triggers used in an event-based architecture (i.e. a table record field changed or the current time is 7:00am), we recommend using Machines or [Automations]. Contact your Tulip representative if you have questions about this transition.

머신 트리거는 연결된 장비의 속성 변경 사항을 감지하고 이에 대응하여 로직을 실행합니다. machine attributes 에서 높은 빈도로 보고가 이루어지거나 여러 속성이 동시에 모니터링될 경우, 트리거 실행 속도가 앱이 트리거를 처리하는 속도를 초과할 수 있습니다. 이로 인해 성능 저하가 발생할 수 있습니다.

권장 사항

machine attribute 구독을 현재 단계나 워크플로우에 필요한 항목으로만 제한하십시오.
고주파수 로직을 클라우드 작업과 분리하고, 클라우드에 의존하는 작업 처리를 위해 주파수가 낮은 트리거를 사용하십시오

예시 시나리오: machine attribute 가 초당 4회 업데이트되며, 테이블 레코드에서 업데이트 횟수를 추적해야 하는 경우. 트리거 1(머신 이벤트): 수신된 머신 데이터로 앱 변수 업데이트 트리거 2(타이머, 10초마다): 누적된 데이터를 테이블 레코드에 기록

접근 방식	구성	성능
최적	머신 트리거가 앱 변수를 증가시키고, 타이머 트리거가 10초마다 테이블에 기록합니다.	양호 (0.1 Hz에서 클라우드 운영)
느림	머신 트리거가 업데이트될 때마다 테이블에 직접 기록합니다	나쁨 (4 Hz에서 클라우드 운영)

트리거 대기열의 처리 부하를 줄이기 위해 비동기 처리를 위한 자동화 기능을 사용하는 것을 고려해 보십시오. 예를 들어, 머신 데이터를 처리해야 하지만 앱 세션에서 운영자의 즉각적인 피드백이 필요하지 않은 경우
트리거에서는 앱 변수 읽기/업데이트 또는 테이블 레코드 읽기와 같은 빠른 작업만 사용하십시오
사용 사례에서 많은 속성을 높은 빈도로 모니터링해야 하는 경우, 앱 아키텍처를 평가하고 더 낮은 빈도로 작동하도록 재설계하는 것을 고려하십시오. 대안적인 접근 방식은 다음과 같습니다:
Tulip으로 데이터를 전송하기 전에 머신 또는 엣지 디바이스 수준에서 데이터를 집계하십시오
데이터 수집 및 처리에 자동화 기능을 활용하십시오
데이터 소스에서의 보고 빈도를 줄이십시오
엣지 디바이스에서 호스팅되는 드라이버 대신 Tulip Player 드라이버 사용을 고려하십시오
Torque 도구 Player 드라이버