Tulip 클라우드 배포를 위한 네트워크 안정성 및 데이터 무결성 요구 사항

개요

Tulip Cloud 배포에서 실시간 성능과 데이터 무결성을 유지하려면 고품질의 안정적인 네트워크 연결이 필요합니다. 이 문서에서는 튤립 배포가 충족해야 하는 정량화 가능한 네트워크 요구 사항(대역폭, 지연 시간, 지터, 패킷 손실)을 정의하고, 네트워크 불안정성이 초래할 수 있는 기술적 위험(트리거 큐 내 데이터 손실 및 ALCOA 규정 준수 실패 포함)을 설명하며, 이러한 위험을 완화하기 위한 물리적, 논리적, 애플리케이션 수준의 권장 사항을 제시합니다.

순수한 속도보다 안정성이 더 중요합니다. 지터가 높거나 간헐적인 패킷 손실이 발생하는 불안정한 연결은 고대역폭 링크에서도 눈에 띄지 않는 영구적인 데이터 손실을 초래할 수 있습니다. 이 문서의 요구 사항을 충족하려면 견고한 IT/네트워크 인프라와 복원력 있는 애플리케이션 아키텍처라는 두 가지 요소가 함께 작동해야 합니다.

Tulip Cloud 인스턴스에 허용 목록에 추가해야 할 특정 도메인 및 IP 주소 목록은 Tulip Cloud 배포 네트워킹 요구 사항을 참조하십시오.

이 문서는 누구를 위한 것인가?

이 문서는 대규모 환경에 Tulip을 배포하고 있는 숙련된 Tulip 사용자에게 가장 유용합니다. 조직 내에서 Tulip을 새로 배포 중이거나 현재 평가판 사용 중인 경우, 이 정보는 현재 필요 수준보다 다소 고급일 수 있습니다.

오른쪽의 링크를 사용하여 원하는 주제의 내용으로 이동하십시오.

요약

이 문서는 Tulip Cloud 배포의 성능, 안정성 및 데이터 무결성을 보장하기 위한 필수 네트워크 요구 사항을 개괄적으로 설명합니다.

주요 요점

속도보다 안정성이 더 중요합니다: 15 Mbps의 안정된 유선 연결은 지터나 패킷 손실이 심한 100+ Mbps의 불안정한 연결보다 훨씬 우수합니다.

네트워크 불안정성은 데이터 손실을 유발합니다: 간헐적인 연결, 높은 지연 시간 또는 패킷 손실은 단순히 "속도 저하"를 유발하는 것 이상입니다. 이는 트리거 큐를 막히게 하고 이벤트를 드롭하게 하여, 영구적인 데이터 손실과 중요한 데이터 무결성(ALCOA) 실패로 이어집니다.

이를 완화하려면 두 가지 요소로 구성된 솔루션이 필요합니다: 견고한 IT 인프라(아래 요구 사항 충족)와 복원력 있는 애플리케이션 아키텍처(예: 자동화를 통한 로직 분리)가 모두 필요합니다.

중요 인프라 정책

유선 이더넷을 기본값으로 설정: 모든 고정형 Tulip 플레이어는 차폐된 유선 이더넷을 사용해야 합니다.

프록시 및 방화벽 구성 및 모니터링: 허용 목록(Allowlist)에 나열된 모든 Tulip 도메인은 SSL/TLS 패스스루가 구성되어야 합니다( 허용 목록 참조). 심층 패킷 검사(DPI)는 최소화해야 하며, 방화벽 및 프록시 성능은 사전에 적극적으로 모니터링해야 합니다.

스테이션별 네트워크 준비 상태 점검 목록

각 Tulip Player 스테이션에 대해 다음 사항을 확인하십시오:* [ ] 연결 유형: 고정형 플레이어는 유선 차폐 이더넷 (STP, Cat6a 이상) 을 사용합니다.* [ ] 대역폭: 다운스트림 및 업스트림 모두 최소 15 Mbps가 확보되어야 하며, 활성 스테이션당 10 Mbps 또는 계산된 최소값( ‘정량화 가능한 네트워크 요구 사항’ 참조)보다 낮아서는 안 됩니다.* [ ] 지연 시간: your-instance.tulip.co까지의 평균 왕복 지연 시간(RTT)이 80 ms 미만이며, 최대 RTT는 100 ms 미만이어야 합니다 .*[ ] 지터: 지터($RTT_{max}-RTT_{avg}$)가 10 ms 미만이어야 하며 (항상 30 ms 미만이어야 함)* [ ] 패킷 손실: 정상 작동 시 측정된 패킷 손실률은 0%이며, 최악의 경우 테스트에서는 0.1% 미만이어야 합니다.* [ ] 가동 시간: 플레이어에서 Tulip Cloud로 이어지는 경로는 불안정한 연결(임시 Wi-Fi, 게스트 네트워크, 빈번한 연결 끊김이 발생하는 VPN 등)에 의존하지 않습니다.* [ ] 프록시/방화벽: 허용 목록 (Allowlist) 에 포함된 모든 Tulip 도메인은 SSL/TLS 패스스루로 구성되어 있으며, SSL 가로채기, 프로토콜 재작성, 변조 또는 캐싱이 없어야 하며, 가급적 DPI가 없어야 합니다.* [ ] WebSockets: 프록시 및 방화벽은 대기 시간 초과나 연결 재설정 문제 없이 포트 443을 통한 장기 WebSocket 연결을 허용합니다.
[ ] 프로세스 활성 상태 유지*: 기기(특히 모바일 기기)는* 과도한 백그라운드 프로세스 최대 절전 모드*, 배터리 최적화, 또는 Tulip Player를 일시 중지하거나 사용 중일 때 네트워크 요청, TCP 연결, WebSocket 연결을 제한하는 OS 정책을* 피하도록 구성되어야 합니다 .* [ ] 복원력 있는 앱*: 이 스테이션의 중요 앱은* 복원력 있는 앱 아키텍처* 패턴을 따릅니다 (운영자 워크플로우 중 중요 트리거 경로에서 이벤트 발생 빈도와 API 호출을 최소화하고, Tulip 테이블을 우선시하며, 장시간 실행되는 커넥터를 최소화).

불안정성 위험 및 데이터 무결성

이 섹션에서는 안정적인 연결이 왜 중요한지, 그리고 성능과 데이터 무결성에 영향을 미치는 기술적 위험이 무엇인지 설명합니다.

단순한 메시지 지연 외에도, 간헐적인 연결 문제나 패킷 손실은 다음 두 가지 주요 문제를 야기할 수 있습니다: 1. 이벤트 누락 및 데이터 손실네트워크가 불안정하거나 오프라인 상태일 때에도운영자의 동작(버튼 누르기, 장치 입력, 바코드 스캔 등)은 여전히 이벤트를 생성합니다. 이러한 이벤트는 큐에 쌓이게 됩니다. 이 큐에는 정해진 한계(기본값 100개 이벤트)가 있으므로, 네트워크 복구를 기다리는 동안 이 한도를 초과하면 새로 들어오는 모든 이벤트가 누락되어 영구적으로 손실됩니다. 2. **시스템 과부하 및 “캐치업”으로 인한 속도 저하:**중단 후 연결이 복구되면, 대기열에 쌓인 전체 이벤트(최대 100개)가 빠르게 연속적으로 실행되려고 시도합니다. 이로 인해 Tulip 플랫폼과 연결된 모든 타사 시스템( Connector Functions 를 통해)에 갑작스럽고 막대한 부하가 발생할 수 있습니다. 특히 공유 네트워크 연결 문제로 인해 재연결되는 여러 스테이션 간에 이 현상이 조율될 때 더욱 그렇습니다. 이러한 “캐치업”으로 인한 이벤트 홍수는 상당한 속도 저하와 과부하의 원인이 될 수 있으며, API 스로틀링(HTTP 429 오류) 및 추가적인 오류로 이어질 수도 있습니다.

네트워크 문제가 트리거 큐에서 데이터 손실을 유발하는 방식

이러한 위험을 이해하려면 트리거가 어떻게 실행되는지 아는 것이 필수적입니다. 자세한 내용은 트리거를 참조하십시오.* 단일 스레드 큐: Tulip의 트리거 런타임은 순차적인 단일 스레드 큐에서 작동합니다. 각 트리거 이벤트(예: “버튼 누름”)는 이 큐에 추가되며, 큐에 있는 다음 이벤트가 시작되기 전에 해당 트리거의 모든 작업이 완료되어야 합니다.* 네트워크 “정체”: 네트워크 중단이나 심각한 불안정성은 트리거 내의 작업(예: “테이블 레코드 생성” 또는 “ Connector Function 실행”)이 멈추거나 장시간 재시도 상태에 빠지게 합니다. 예를 들어, LTS15 기준, 실패한 테이블 작업은 최대 2분 동안 재시도됩니다.* 병목 현상: 이 단 하나의 느린 트리거가 전체 큐를 차단합니다. 큐가 차단된 동안, 이후의 운영자 작업(예: 추가로 99번의 버튼 누르기)이 큐를 채웁니다.* 이벤트 손실: 큐 제한(기본값 100개 이벤트)에 도달하면, 그 이후의 모든 이벤트는 취소되고 삭제됩니다. 즉, 네트워크 중단 중에 운영자가 101번째 항목을 스캔하면 해당 이벤트는 영구적으로 손실되며, 네트워크가 복구된 후에도 처리되지 않습니다.

큐가 가득 차지 않은 상황에서도 일반적인 네트워크 불안정으로 인해 개별 API 호출( Connector Functions )이 실패할 수 있습니다. 이러한 작업은 (LTS15의 테이블 작업과 달리) 재시도되지 않으며, 이는 눈에 띄지 않는 데이터 오류 및 무결성 문제로 이어질 수 있습니다.

데이터 손실의 위험 요인

네트워크 연결 상태가 좋지 않을 때 발생하는 데이터 손실 위험은 일률적이지 않습니다. “이벤트 집약적”인 앱 아키텍처의 경우 이러한 위험이 상당히 높아집니다. 이러한 앱에 대한 모범 사례는 여기에서 확인하십시오.

앱에 다음 사항이 해당될 경우 데이터 손실 위험이 훨씬 더 높습니다. * 높은 이벤트 발생률: 짧은 시간 내에 많은 이벤트를 생성하는 앱. 여기에는 빠른 바코드 스캔, 빈번한 장치 입력, 또는 짧은 간격(예: 30초마다)으로 발동되는 타이머 트리거 등이 포함됩니다. * 복잡한 트리거: 많은 순차적 동작, 특히 여러 API 호출(Connector Functions)이나 테이블 쓰기 작업을 실행하는 트리거. 네트워크에 의존하는 각 작업은 중단 발생 시 잠재적인 "정체" 시간을 늘립니다.* Connector Functions 에 대한 의존: 중요한 데이터 캡처를 위해 Connector Functions 를 사용하는 경우. 네트워크 일시적 장애로 인해 Connector Function 호출이 실패하면 재시도되지 않아 트리거가 실패하게 되며, 이로 인해 프로세스가 중단되거나 데이터 손실이 발생할 수 있습니다. 가능한 경우 자동화 (및/또는 함수) 를 사용하십시오.

생명과학 분야의 ALCOA 준수

생명과학 분야 및 기타 GxP 규제 환경에 있는 고객의 경우, 이러한 네트워크 위험은 단순한 성능 문제가 아니라 데이터 무결성과 규정 준수에 대한 직접적인 위협입니다.

위에서 설명한 기술적 위험은 ALCOA 원칙과 직접적으로 연관됩니다:* 부정확하고 불완전함: 중단 기간 동안 트리거 대기열 한도에 도달하면, 그 이후의 모든 이벤트는 영구적으로 삭제됩니다. 운영자가 101번째 항목을 스캔하면 해당 이벤트는 영원히 손실됩니다. 그 결과 생성된 배치 기록은 근본적으로 부정확하고 불완전합니다.* 동시성이 보장되지 않음: 연결이 복구되면 “캐치업(catch-up)” 데이터 홍수가 대기열에 쌓인 이벤트들을 일괄 처리하게 되는데, 이는 종종 운영자가 작업을 수행한 지 몇 분이 지난 후에 발생합니다. 실제 공정과 비교해 명백히 지연된 타임스탬프 클러스터를 검토하는 감사관은 기록의 동시성 무결성에 의문을 제기할 것입니다.* 부정확성(시스템 간): Connector Functions (API 호출)에는 내장된 재시도 기능이 없습니다. 일시적인 네트워크 장애로 인해 트리거가 Tulip 테이블(원본 기록)에는 성공적으로 기록되었으나, 외부 MES 또는 QMS에는 업데이트되지 않을 수 있습니다. 이로 인해 검증된 시스템 전반에 걸쳐 부정확하고 동기화되지 않은 데이터 상태가 발생합니다.

데이터 무결성 오류로부터 시스템을 보호하고, 견고하며 검증 가능한 프로세스를 구축하기 위해서는 다음 섹션에 제시된 아키텍처 권장 사항을 따르는 것이 필수적입니다.

정량화 가능한 네트워크 요구 사항

앞서 논의한 트리거 큐 정체, 이벤트 손실 및 데이터 무결성 오류를 방지하려면 각 튤립 플레이어 스테이션이 고품질의 지속적 연결을 유지해야 합니다. 다음 네 가지 요소가 이 요구 사항을 정의합니다.

대역폭(처리량)

이는 연결의 “크기”로, 연결 포화를 방지합니다. 애플리케이션 데이터 페이로드는 대개 작지만, 대역폭이 부족하면 지연 및 패킷 손실이 발생하고, 이는 결국 트리거 큐를 차단하게 됩니다.

• 권장 사항: 활성 스테이션당 15 Mbps.
• 절대 최소값: 활성 스테이션당 10 Mbps 또는 계산된 필수 대역폭 중 더 높은 값.
• 정량화 가능한 기준: 최소 대역폭은 애플리케이션의 *기본 데이터 전송률(BDR)*에 네트워크 오버헤드 및 재전송을 고려하여 최소 2.0(100%) 의 여유 계수($H$) 를 곱한 값을 초과해야 합니다.
  • $R_{peak}$ = 피크 이벤트 속도(초당 이벤트 수)
  • $S_{event}$ = 이벤트당 평균 데이터 페이로드(바이트, 트리거가 송수 신한 모든 데이터 포함)
  • $H$ = 헤드룸 계수(무차원), $H > 2.0$을 권장

먼저 초당 비트 단위의 기본 데이터 전송률(BDR) 을 계산합니다:* $BDR (bps)=R_{peak}\times S_{event}\times 8$

그런 다음 필요한 대역폭을 계산합니다: * $필요한 대역폭 (bps)=BDR\times H=R_{peak}\times S_{event}\times 8\times H$

실제 적용 시, 이 계산된 값이 10 Mbps 미만이라 하더라도, 향후 확장성을 확보하고 충분한 여유 용량을 확보하며 동일한 링크상의 다른 트래픽을 고려하기 위해 활성 스테이션당 최소 10 Mbps (가급적 15 Mbps)를 할당해야 합니다.

예시

앱의 최악의 경우 피크 이벤트 발생 빈도가 $R_{peak}=2events/sec$이고, 각 이벤트가 약 $S_{event}=5,000 bytes$를 송수신한다면:* $BDR=2\times 5,000\times 8=80,000 bps$* $필요 대역폭(H=2.0)=160,000 bps=0.16 Mbps$

계산된 요구량이 낮더라도, 스테이션당 최소 10~15 Mbps를 할당합니다.

지연 시간(왕복 시간)

이는 패킷이 서버까지 이동했다가 돌아오는 데 걸리는 지연 시간입니다. 지연 시간이 길면 네트워크에 의존하는 모든 트리거 동작(테이블 쓰기나 connector function 등)의 실행 시간이 직접적으로 증가하여, 전체 큐가 막힐 위험이 커집니다.

• 권장 사항: < 80ms
• 절대 최대치: 100ms (사용자의 [instance].tulip.co 도메인 기준).
• 정량화 가능한 한계: 지연 시간은 트리거 내에서 네트워크에 의존하는 작업이 소요되는 시간을 직접적으로 결정합니다. 트리거 큐가 정체되는 것을 방지하려면, 네트워크 작업으로 인한 총 트리거 실행 시간이 이벤트 간 시간보다 훨씬 짧아야 합니다.

다음과 같이 정의합니다.* $R_{peak}$ = 최대 이벤트 발생률 (초당 이벤트 수)* $T_{between}$ = 이벤트 간 시간 (초).* $N_{net}$ = 트리거 내 연속적인 네트워크 작업 수 (예: 테이블 쓰기, 커넥터 호출)* $RTT_{avg}$ = 평균 왕복 지연 시간 (초)

이벤트 간격은 다음과 같습니다:* $T_{between}=\frac{1}{R_{peak}}$

네트워크 지연 시간이 트리거 시간에 기여하는 부분에 대한 간단한 근사식은 다음과 같습니다:* $T_{trigger,net}=N_{net}\times RTT_{avg}$

큐를 정상적으로 유지하려면, 네트워크에 의한 트리거 시간이 이벤트 간 시간보다 충분히 짧아야 합니다.실무상의 경험칙은 다음과 같습니다:* $N_{net}\times RTT_{avg}\leq 0.25\times T_{between}$* $N_{net}\times RTT_{avg}\leq \frac{0.25}{R_{peak}}$

다시 말해, 트리거 내의 모든 연속적인 네트워크 왕복 시간의 합은 피크 부하 시 운영자 이벤트 간 예상 시간의 1/4보다 작아야 합니다. 이 조건이 충족되지 않으면 큐가 점차 쌓여 결국 100개 이벤트 제한에 도달하게 됩니다. 가장 안정적인 성능을 얻으려면 $N_{net}\times RTT_{avg}\lt \lt \frac{0.1}{R_{peak}}$를 유지하도록 고려하십시오.

지터(지연 변동)

이는 지연 시간의 변동을 의미합니다. 지터가 큰 연결은 불안정합니다. 단일 패킷에서 발생하는 갑작스러운 지연 시간 급증은 높은 평균 지연 시간만큼이나 효과적으로 트리거를 중단시킬 수 있으며, 이로 인해 큐가 차단되고 “무작위적인” 정지 현상 및 이벤트 손실이 발생합니다.

• 정량화 가능한 한계: 지터는 시간에 따른 지연 시간의 변동입니다. 단 한 번의 지연 시간 급증만으로도 지속적으로 높은 지연 시간만큼 효과적으로 트리거를 정지시킬 수 있습니다.

다음과 같이 정의합시다:* $RTT_{avg}$ = 샘플링 창(초) 동안의 평균 왕복 지연 시간* $RTT_{max}$ = 동일한 창(초) 동안 관측된 최대 왕복 지연 시간

다음과 같이 정의합니다:* $Jitter=RTT_{max}-RTT_{avg}$

예측 가능한 트리거 성능을 보장하려면 이 값을 낮게 유지해야 합니다. Tulip 배포의 경우:* 권장 사항: $Jitter$ < 10ms * 절대 최대치: $Jitter$ < 30ms

측정된 지터가 30ms에 근접하거나 이를 초과할 경우, 운영자는 “무작위적인” 정지 현상을 목격하게 되며, 트리거가 큐를 차단할 만큼 오랫동안 실행 상태로 남아 있을 수 있습니다.

신뢰성 (패킷 손실 및 가동 시간)

이는 데이터 무결성을 위해 가장 중요한 요소입니다. 패킷 손실은 재전송을 유발하며, 이로 인해 트리거가 몇 초 동안 정지되어 심각한 큐 정체를 초래할 수 있습니다. 연결 끊김 (가동 시간 장애)은 치명적이며, 큐가 가득 차게(100개 이벤트) 되고 이후의 모든 데이터가 영구적으로 손실되어 기록이 불완전해질 수밖에 없습니다.

• 권장 사항: 패킷 손실 0% 및 지속적인 가동 시간.
• 절대 최대치: 패킷 손실 < 0.1%.
• **정량화 가능한 한계:**트리거 큐는 제한된 수의 이벤트만 저장할 수 있습니다. 네트워크가 다운된 상태에서도 운영자의 작업으로 인해 큐가 가득 찰 때까지 이벤트가 계속 생성됩니다. 큐가 한계에 도달하면 그 이후의 모든 이벤트는 버려지고 영구적으로 손실됩니다.

다음과 같이 정의합니다:* $Q_{max}$ = 최대 큐 크기(이벤트). 현재 기본값은 $Q_{max}=100$입니다.* $R_{peak}$ = 중단 기간 중의 최대 이벤트 발생률(초당 이벤트 수).

이벤트가 버려지기 시작하기 전까지 허용 가능한 최대 중단 지속 시간은 다음과 같습니다:* $T_{outage,max}=\frac{Q_{max}}{R_{peak}}$

예시: 이벤트 발생률이 높은 앱(예: $R_{peak}=2$ 이벤트/초, 빠른 토크 값 등)의 경우:* $T_{outage,max}=\frac{100}{2}=50$ 초

이 예시에서 50초보다 긴 지속적인 네트워크 중단이 발생하면 데이터 손실이 발생합니다. 즉, 처음 100개 이후의 모든 이벤트는 네트워크가 복구된 후에도 버려지고 처리되지 않습니다.

이 간단한 관계는 위험 평가에 있어 매우 중요합니다. 이벤트 발생 빈도가 높은 앱은 데이터 무결성이 훼손되기 전까지 매우 짧은 중단 시간만 견딜 수 있습니다.

물리적 인프라 권장 사항

정량화 가능한 네트워크 요구 사항을 충족하는 것은 단순히 ISP의 문제만이 아닙니다. 이는 시설 내부의 물리적 네트워크 인프라에 크게 좌우됩니다.

기본 권장 사항: 유선 이더넷

이전 섹션에서 정의한 안정성, 신뢰성 및 낮은 지연 시간 지표를 달성하기 위해서는 모든 고정형 Tulip Player 스테이션에 유선 이더넷 연결을 사용하는 것이 강력히 권장되는 기본 권장 사항입니다.

그러나 이것이 “한 번 설정하면 더 이상 신경 쓸 필요가 없는” 솔루션은 아닙니다. 물리 계층은 간헐적이고 진단하기 어려운 패킷 손실을 유발할 수 있는 흔하면서도 종종 간과되는 장애 지점입니다.

• 물리적 케이블 상태: IT 및 운영 팀은 이 인프라를 선제적으로 관리해야 합니다. 케이블에 결함, 마모, 연결 불량이 없는지 정기적으로 점검하십시오. 차트가 차폐되지 않았거나 배선이 부적절한 케이블 위를 반복적으로 지나가는 것이 흔한 고장 원인입니다.
• 전자기 간섭(EMI): 공장 현장에서는 진동이 심한 기계, 모터 또는 고전압 장비가 상당한 간섭을 유발할 수 있습니다. 이러한 환경에서는 신호 저하를 방지하기 위해 차폐 이더넷 케이블(예: STP, Cat6a 이상)을 사용하십시오.

Wi-Fi 및 모바일 기기 관련 고려 사항

많은 고객이 유선 연결이 불가능한 환경에서 모바일 기기(태블릿, 휴대폰)나 이동식 카트를 사용한다는 점을 잘 알고 있습니다. 이러한 상황에서는 안정적인 Wi-Fi 연결이 데이터 무결성을 위한 필수 조건입니다.

• 네트워크 설계: 견고하고 전문적으로 설계된 무선 네트워크를 구축해야 합니다. 목표는 연결 끊김을 유발하는 커버리지 공백이 없고, 액세스 포인트(AP) 중복이 최소화된 원활한 커버리지를 확보하는 것입니다. 과도한 중첩은 기기가 AP 간을 “이리저리 헤매게” 하여 DHCP 재협상을 강요하고, 트리거 큐를 차단하는 네트워크 정체를 유발할 수 있습니다.
• 간섭: Wi-Fi는 기계에서 발생하는 전자기 간섭(EMI)에 매우 취약합니다. 네트워크 설계 시 이 점을 반드시 고려해야 합니다.
• 위험 증가: 무선 연결은 유선 연결보다 본질적으로 안정성이 떨어지기 때문에, 이러한 기기의 애플리케이션은 피할 수 없는 네트워크 일시적 장애로부터 보호하기 위해 ‘탄력적인 앱 아키텍처 ( Resilient App Architecture )’ 권장 사항(예: 로직 분리)을 따르는 것이 더욱 중요합니다.
• 모바일 OS는 배터리 절약을 위해 백그라운드 앱을 적극적으로 일시 중지하거나 속도를 제한할 수 있습니다. Tulip Player는 사용 중일 때(키오스크/잠금 앱 모드 권장) 이러한 정책에서 제외되어야 합니다.

물리적 인프라 점검 목록

유선 스테이션

• [ ] 케이블 유형: 모든 고정형 Tulip Player는 전자기 간섭(EMI)이 심한 지역(모터, 구동 장치, 용접기 등)에서 차폐 이더넷 (STP, Cat6a 이상)을 사용합니다.
• [ ] 케이블 배선: 카트, 지게차 또는 의자가 정기적으로 지나가는 곳에는 케이블을 배치하지 않으며, 가능한 경우 케이블을 트레이, 도관 또는 천장 배선을 통해 배선합니다.
• [ ] 케이블 상태: 마모, 꼬임, 피복 파손 및 연결 불량 여부를 확인하기 위한 문서화된 점검 일정 (예: 분기별)이 마련되어 있습니다.
• [ ] 종단 처리: 모든 커넥터와 패치 패널은 적절하게 종단 처리되고 인장 완화 조치가 되어 있으며, “임시” 패치 케이블을 영구 배선으로 사용하지 않습니다.
• [ ] 스위치 포트: 플레이어 포트는 적절한 속도/듀플렉스로 고정되어 있으며, 정기적으로 포화 상태에 이르는 과부하 업링크를 공유하지 않습니다.
• [ ] 전원/PoE: PoE를 사용하는 경우, 스위치의 전원 예산이 과부하되지 않아야 하며, 전압 저하 또는 재설정 이벤트가 모니터링되고 경보가 발생합니다.
• [ ] 모니터링: 기본 스위치 모니터링(CPU, 메모리, 인터페이스 오류 및 사용률)이 활성화되어 있으며 주기적으로 검토됩니다.

Wi-Fi 및 모바일 기기

• [ ] 전문적인 설계: 무선 네트워크는 튤립(Tulip) 기기가 작동하는 생산 구역을 위해 전문적으로 설계 (또는 최소한 실측 조사)되었습니다.
• [ ] 커버리지: 작업자의 전체 이동 경로(“이동 경로”)를 따라 측정된 신호 강도는, 연결이 강제 종료되거나 로밍 “프리폴”을 유발하는 사각지대 없이 지속적인 커버리지를 보여줍니다.
• [ ] AP 중첩: 액세스 포인트는 과도한 중첩을 최소화하도록 배치되어 있으며, 클라이언트가 정지 상태일 때 AP 간을 “이리저리 찾아다니는” 현상이 발생하지 않습니다.
• [ ] 로밍 동작: 로밍 임계값과 대역 스티어링이 적절히 조정되어, 기기가 반복적인 DHCP 재협상이나 일시적인 연결 끊김 없이 원활하게 AP를 전환합니다.
• [ ] 간섭: 채널 계획 수립 시 알려진 EMI 발생원(기계, 용접기, 대형 모터, 마이크로파 링크 등)을 고려했습니다.
• [ ] 세그멘테이션: Tulip 기기는 게스트 Wi-Fi나 이탈률이 높은 소비자용 기기와 혼합되지 않고, 생산 시스템 전용 SSID/VLAN에 배치됩니다.
• [ ] 백홀: AP는 안정적이고 혼잡하지 않은 업링크를 갖추고 있으며, 컨트롤러 또는 클라우드 기반 Wi-Fi가 용량 한계에 근접하여 운영되지 않습니다.
• [ ] 복원력 있는 앱: Wi-Fi/모바일 기기에서 실행되는 앱은 무선 연결의 본질적으로 더 높은 위험을 고려하여 복원력 있는 앱 아키텍처를 더 엄격하게 따릅니다.

테스트

networkCheck를 실행 중인 플레이어와 함께 경로를 이동하며 직접 진단 작업을 수행하고, 10분 동안 연결 끊김이나 임계값을 초과하는 트래픽 급증이 발생하지 않는지 확인하십시오.

논리적 및 보안 인프라(프록시, 방화벽, DPI)

물리적 케이블 외에도, 논리적 네트워크 보안 인프라는 "원인을 알 수 없는" 지연, 지터 및 연결 실패의 가장 흔한 원인입니다.

• 병목 현상을 일으키는 프록시 및 방화벽: 모든 트래픽에 대해 심층 패킷 검사(DPI) 또는 SSL/TLS 복호화를 수행하는 보안 어플라이언스(방화벽, 프록시, CASB 등)는 불안정성의 주요 원인입니다. 이러한 검사 과정 자체만으로도 모든 네트워크 요청에 상당하고 변동성이 큰 지연(지터)이 발생하며, 이로 인해 <100ms 지연 및 <30ms 지터 요구 사항을 쉽게 위반하게 됩니다.
• 어플라이언스 상태 모니터링: 네트워크 팀은 이러한 어플라이언스의 CPU 및 메모리 사용량을 모니터링해야 합니다. 과부하가 걸린 방화벽이나 프록시는 패킷을 삭제하거나 지연 시간을 유발하여, 데이터 손실로 이어지는 불안정성을 야기합니다.
• Tulip 트래픽을 임의로 조작하지 마십시오: Tulip의 클라이언트-클라우드 간 통신은 실시간 데이터 전송을 위해 보안 WebSocket을 포함한 특정 웹 프로토콜에 의존합니다. 일부 보안 솔루션은 이 HTTPS 트래픽을 가로채거나, 재작성하거나, "간섭"하려고 시도합니다. 이러한 가로채기는 WebSocket 연결을 끊거나, 표준 API 호출을 크로스 오리진(CORS) 요청으로 잘못 재분류하여 호출이 실패하게 만들 수 있습니다.
• 요구 사항: 모든 Tulip 도메인( ‘허용 목록’ 섹션에 나열된)은 SSL/TLS 패스스루로 구성되어야 합니다. 트래픽은 모든 DPI, 프로토콜 검사 또는 캐싱을 우회 해야 합니다.

점검 목록

• [ ] Tulip 도메인 우회: 허용 목록( Allowlist )에 나열된 모든 Tulip 도메인은 SSL/TLS 패스스루로 구성되어 있으며, SSL 복호화/차단 대상에서 제외됩니다.
• [ ] DPI 및 프로토콜 재작성 비활성화 권장: Tulip 트래픽, 특히 WebSocket에 대해 심층 패킷 검사(DPI), HTTP 프로토콜 재작성 및 콘텐츠 캐싱이 비활성화되어 있습니다.
• [ ] WebSocket 지원: 방화벽 및 프록시는 짧은 유휴 타임아웃이나 강제 재설정 없이 포트 443을 통한 장기 WebSocket 연결을 허용합니다.
• [ ] 용량 모니터링: 보안 어플라이언스의 CPU, 메모리 및 처리량을 모니터링하며, 지연 시간이나 패킷 손실을 유발할 수 있는 지속적인 높은 사용률에 대해 경보가 설정되어 있습니다.
• [ ] 아웃바운드 규칙: 아웃바운드 규칙은 자산 저장소 엔드포인트(S3/Blob)를 포함하여 Tulip IP 범위/호스트 이름(가든 식별자별)을 명시적으로 허용합니다.
• [ ] 페일 오픈(Fail-open) 동작: 가능한 경우, Tulip 트래픽은 패킷을 무음으로 드롭하지 않고 페일 오픈(또는 명확하고 기록된 오류와 함께)하도록 구성됩니다.
• [ ] 변경 관리: Tulip에 영향을 미칠 수 있는 방화벽/프록시 구성 변경 사항은 모두 추적되며, 이상적으로는 변경 기간 동안 https://your-account.tulip.co/networkCheck을 대상으로 테스트를 수행합니다.

탄력적인 애플리케이션 아키텍처

이 섹션에서는 개발자가 인프라 위험을 완화할 수 있는 방법을 설명합니다.

개발자는 간헐적인 네트워크 문제에 견딜 수 있도록 애플리케이션을 설계해야 합니다. 네트워크 지연 및 사소한 플랫폼 성능 저하에 대비한 여유 공간을 확보하는 것이 매우 중요합니다. 자동화 기능 (및/또는 가능한 경우 함수 )을 활용하십시오.

• Tulip 테이블 쓰기 작업 우선순위 지정: 모든 중요한 데이터 캡처의 경우, 트리거에서 Tulip 테이블의 기본 “Create Record” 또는 “Store” 작업을 먼저 사용하십시오. 이러한 작업은 일시적인 네트워크 장애에 더 강하며, 내장된 재시도 로직(LTS15 기준 최대 2분)을 갖추고 있습니다.
• 이벤트 발생 빈도를 최소화하십시오: 앱 설계를 검토하십시오. 2분간의 네트워크 중단 기간 동안 운영자가 합리적으로 100개의 이벤트(예: 스캔)를 생성할 수 있다면, 아키텍처에 높은 위험이 존재합니다. 입력을 일괄 처리하거나 워크플로를 단순화하는 방안을 고려하십시오.
• 성능 모범 사례 준수: 고성능 앱을 위한 문서화된 지침을따르십시오. 고주파수 호출로 플랫폼에 과부하가 걸리면 네트워크 상태가 좋지 않은 것과 유사한 내부 지연이 발생합니다.

참조: ‘가상’ 튤립 머신을 통한 이벤트 기반 앱 트리거

체크리스트

• [ ] 테이블 우선: 모든 중요한 데이터 캡처 (스캔, 운영자 결정, 측정값)는 먼저 Tulip 테이블에 기록됩니다.
• [ ] 운영자 트리거에 긴 API 호출 없음: 운영자용 트리거에는 장시간 실행되는 Connector Functions 또는 복잡한 외부 API 로직이 포함되어 있지 않습니다.
• [ ] 분리 패턴: 가능한 경우 외부 API 호출에는 자동화 기능을 우선적으로 사용합니다.
• [ ] 상태 필드: 처리 테이블은 명확한 상태 필드(보류 중, 처리 중, 처리 완료, 오류)를 사용하여 오류 발생 시 재시도하거나 조사할 수 있도록 합니다.
• [ ] 제어된 이벤트 발생 빈도: 앱 설계상 운영자가 짧은 서비스 중단 기간 동안 큐를 가득 채울 정도의 지속적인 이벤트 발생 빈도를 생성하지 못하도록 합니다(위의 서비스 중단 관련 계산 참조).
• [ ] 타이머 및 루프: 타이머 트리거와 루프는 절대적으로 필요하고 검증된 경우가 아닌 한, 불필요하게 짧은 간격(예: 1~5초마다)으로 실행되지 않습니다.
• [ ] 커넥터 오류 처리: 네트워크 문제로 인해 실패할 수 있는 커넥터( Connector Functions )에는 오류 처리 및 재시도 메커니즘이 마련되어 있습니다(가급적 운영자 트리거가 아닌 자동화 기능을 통해).
• [ ] 성능 모범 사례: 앱은 고성능 앱을 위한 Tulip의 모범 사례를 준수해야 합니다.

기술적 구성 및 문제 해결

사용 중인 네트워크가 위에 명시된 정량적 요구 사항을 충족하지 못하거나, 네트워크와 관련된 것으로 의심되는 성능 문제가 발생하는 경우, 당사의 상세 가이드에 명시된 단계를 따르시기 바랍니다. 이 가이드는 기본적인 점검부터 고급 패킷 수준 분석에 이르기까지, 네트워크 성능 문제를 진단하고 해결하기 위한 우선순위가 지정된 흐름도를 제공합니다.

전체 네트워크 문제 해결 가이드는 여기에서 확인하세요.

네트워크 및 WebSocket 테스트 유틸리티

Tulip은 실시간 업데이트를 지원하기 위해 장기 연결 방식인 WebSocket을 광범위하게 사용합니다. 이러한 WebSocket은 443번 포트를 통해 SSL 암호화를 사용합니다. 일부 프록시는 이러한 연결을 지원하지 않을 수 있으며, 일부 네트워크 모니터에서는 이러한 연결을 명시적으로 허용해야 할 수도 있습니다. 호환성 여부는 위 섹션을 참조해 주십시오.

네트워크 연결의 지연 시간과 WebSocket 호환성을 테스트하는 데 도움이 되는 간단한 유틸리티가 제공됩니다:

• https://your-account.tulip.co/networkCheckOR
• https://your-account.dmgmori-tulip.com/networkCheckOR
• https://your-account.tulip-serendie.com/networkCheck

시운전 및 지속적인 모니터링 체크리스트

• [ ] 초기 테스트: 새로운 스테이션이 추가될 때마다, 정상적인 생산 부하 상태에서 https://your-account.tulip.co/networkCheck(또는 DMG MORI/Serendie URL)과 자체 진단 도구를 최소 10~15분 동안 실행하십시오.
• [ ] 지표 기록: 평균, 최소 및 최대 지연 시간, 지터, 그리고 관찰된 패킷 손실량을 기록하고, 이 문서에 명시된 임계값을 충족하는지 확인하십시오.
• [ ] 피크 부하 테스트: 공장 네트워크에서 알려진 피크 부하 시간대(교대 근무, 대량 배치 처리)에 테스트를 반복하여 부하가 가해지는 상황에서도 안정성을 확보하십시오.
• [ ] 변경 후 회귀 테스트: Tulip에 영향을 미치는 네트워크, Wi-Fi, 방화벽 또는 프록시 구성에 중대한 변경이 발생한 후 테스트를 다시 실행하십시오.
• [ ] 기준 데이터 보관: 테스트 결과(스크린샷 또는 내보낸 데이터)를 검증/시운전 기록의 일부로 보관하십시오.
• [ ] 정기적 재검증: 중요 스테이션의 경우 또는 이벤트 발생 빈도가 더 높은 새로운 앱이 배포될 때 정기적으로(예: 분기별) 재테스트를 실시하십시오.

원하시는 정보를 찾으셨나요?

community.tulip.co를 방문하여 질문을 게시하거나 다른 사용자들이 비슷한 문제를 겪은 적이 있는지 확인해 보세요!