InfluxDB를 지속성 공급자로 사용
개요
시스템에서 주로 시계열 데이터를 처리하고 구현이 데이터의 지속성/검색을 위해 가치 스트림 또는 스트림에 많이 의존할 경우 ThingWorx에서 InfluxDB를 지속성 공급자로 사용하는 것이 좋습니다. InfluxDB는 시계열 데이터에 맞게 작성된 고성능 데이터 저장소입니다. InfluxDB는 동일한 데이터에 대해 높은 처리량 수집, 압축 및 실시간 질의를 허용합니다. InfluxDB는 DevOps 모니터링, 로그 데이터, 응용 프로그램 메트릭, IoT 센서 데이터 및 실시간 분석을 포함하여 대량의 타임스탬프 데이터가 포함되는 모든 사용 사례에 데이터 저장소로 사용됩니다. 데이터 보존 정책(RP)을 비롯한 다른 기능도 제공합니다. InfluxDB Enterprise는 시계열 데이터 요구사항에 적합한 고가용성 및 확장성이 뛰어난 클러스터링 솔루션을 제공합니다.
InfluxDB 데이터 지속성 스토리지 공급자는 속성 공급자에 사용되는 PostgreSQL, MSSQL 또는 Azure SQL 기본 설치의 일부로 사용할 수 있습니다.
• InfluxPersistenceProviderPackage
• Influx2PersistenceProviderPackage
ThingWorx는 OSS, Enterprise 및 Cloud 버전을 지원합니다.
• InfluxDB OSS 1.x 및 InfluxDB Enterprise 1.x는 InfluxPersistenceProviderPackage를 통해 지원됩니다. InfluxDB Enterprise는 INfluxDB 1.x에서만 지원됩니다.
• InfluxDB OSS 2.x는 Influx2PersistenceProviderPackage를 통해 지원됩니다.
• InfluxDB Cloud는 Influx2PersistenceProviderPackage를 통해서만 지원됩니다.
지원되는 특정 버전은 Release Advisor를 참조하십시오.
 |
Influx 2.0 지원은 9.3.1부터 ThingWorx에 추가되었습니다.
|
|
|
InfluxDB 데이터 공급자는 현재 가치 스트림 및 스트림만 지원합니다. 데이터 테이블, Wiki 및 블로그는 지원되지 않습니다.
|
|
|
데이터 내보내기는 InfluxPersistenceProviderPackage를 사용하여 지원되며 ThingWorx 9.3.8 이후부터는 Influx2PersistenceProviderPackage를 사용하여 지원됩니다.
|
|
|
InfluxDB는 속성 공급자로 지원되지 않습니다.
|
|
|
ThingWorx 9.3.9 이상 및 ThingWorx 9.4.0 이상으로 업그레이드하고, InfluxDB OSS 2.0을 사용하여 Influx2PersistenceProviderPackage를 활용하려는 고객은 InfluxDB v2.6으로 업그레이드하기 전에 내보내기가 필요하므로 InfluxDB OSS v2.6으로 전환하려면 먼저 ThingWorx 9.3.8로 업그레이드해야 합니다. InfluxDB Cloud의 경우 사전 업그레이드를 내보낼 필요가 없으므로 ThingWorx 9.3.9 이상 및 ThingWorx 9.4.0 이상으로 업그레이드하기 전에 ThingWorx 9.3.8로 전환할 필요가 없습니다.
|
InfluxDB Enterprise 및 ThingWorx 시작 환경
| | 위의 다이어그램에는 InfluxDB Enterprise가 포함되어 있습니다. InfluxDB 오픈 소스의 경우 아키텍처 다이어그램은 동일하지만 노드 하나에서만 작동한다는 점이 다릅니다. 또한 InfluxDB Cloud의 경우 데이터베이스가 ThingWorx 환경 외부에서 호스팅되고 InfluxData 회사에 의해 관리됩니다. |
다음은 이 문서에서 InfluxDB Enterprise에 대한 구성을 언급할 때 사용되는 용어입니다.
• 부하 분산 - InfluxDB Enterprise는 부하 분산으로 작동하지 않습니다. 관리자가 이 기능을 구성해야 합니다.
• 클러스터 - InfluxDB Enterprise 클러스터는 두 가지 노드 유형인 메타 노드와 데이터 노드로 구성됩니다.
• 데이터 노드 - 모든 원시 시계열 데이터가 여기에 있습니다. 고가용성을 위해서는 둘 이상의 복제 요소가 필요합니다.
• 메타 노드 - 이러한 노드에는 일관된 상태를 유지하기 위한 단순 작업이 있습니다. 보존 정책, 사용자, 데이터베이스 등 상태에 대한 기본 정보만 포함합니다. 고가용성 환경에서는 세 개 이상의 메타 노드가 필요합니다.
HA에 대한 자세한 내용은 https://www.influxdata.com/blog/understanding-influxenterprise-what-is-a-cluster/를 참조하십시오.
올바른 Influx 데이터베이스 옵션 선택
다음은 PTC 온프레미스 고객들이 현재 사용할 수 있는 두 가지 InfluxDB 옵션에 관한 간략한 개요입니다. Influx 제품을 선택할 때 데이터베이스 소프트웨어 옵션 및 기본 지원 옵션을 신중하게 고려해야 합니다. 올바른 데이터베이스 옵션 선택과 관련된 질문은 Influx 제품지원(https://www.influxdata.com/contact-sales)으로 문의하십시오. 문의 시 PTC 고객은 자신을 PTC ThingWorx 사용자로 알려야 합니다.
• InfluxDB 오픈 소스 OSS(단일 노드)
◦ 단일 노드만 해당되며 확장할 수 없습니다.
◦ 무료
◦ Influx Community 사이트(InfluxData Community Forums(InfluxData Community 포럼))를 통해 커뮤니티 기반 Influx 지원을 이용할 수 있습니다.
◦ Influx 기술 지원 제한으로 인해 생산 인스턴스에는 권장되지 않습니다(긴급 상황에 대한 실시간 Influx 지원 없음).
◦ 데이터베이스 유지 관리 및 모니터링은 PTC 고객의 책임입니다.
◦ PTC는 Influx 권장 사항을 제공하기 위해 최상의 노력을 기울이지만, Influx 기술 리소스로의 에스컬레이션이 필요한 경우도 있습니다.
• InfluxDB Enterprise
현재 다른 데이터베이스에서 제공하는 것보다 대량의 데이터 볼륨과 높은 속도의 데이터에 더 적합한 데이터 저장소를 찾고 있는 경우 InfluxDB Enterprise를 사용하면 다음과 같은 이점을 얻을 수 있습니다.
◦ 데이터 수집 속도가 빨라짐.
◦ 런타임 데이터에 둘 이상의 데이터 저장소를 사용할 수 있음. 예를 들어, 관계형 데이터는 PostgreSQL에 저장하고 대량의 스트림 및 가치 스트림 데이터에는 InfluxDB를 사용할 수 있습니다. 스트림 또는 가치 스트림을 정의하면 ThingWorx는 기본 런타임 데이터 저장소 공급자를 사용하지만 정의한 지속성 공급자를 사용하도록 ThingWorx를 구성할 수 있습니다. 다른 데이터 공급자에서 데이터를 내보내고 InfluxDB로 가져올 수도 있습니다. ThingWorx는 데이터 추상을 처리합니다.
◦ 클라우드 친화적 아키텍처(수평 확장, InfluxDB Enterprise에서만 제공).
◦ 고가용성 사용 가능.
◦ Influx 지원 사이트(InfluxData)를 통해 Influx 담당자로부터 Influx 기술 지원을 받을 수 있습니다.
◦ PTC 고객은 Influx에 PTC/Influx 공동 작업에 필요한 티켓을 개설할 수 있습니다.
◦ 데이터베이스 유지 관리 및 모니터링은 PTC 고객의 책임입니다.
• InfluxDB Cloud(ThingWorx 환경 외부에서 호스팅되고 InfluxData 회사에서 관리)
InfluxDB Cloud를 사용할 경우 다음과 같은 이점이 있습니다.
◦ InfluxDB Cloud는 클라우드 네이티브, 다중 테넌트, 탄력적 규모, 서버리스 플랫폼으로 빌드됩니다.
◦ AWS, Google 및 Azure의 여러 영역에서 가용성, 내구성 및 확장성을 제공합니다.
◦ 모든 최신 보안 기능 및 패치의 설치 및 구성을 통해 보안이 강화됩니다.
◦ InfluxDB Cloud는 클러스터를 자동으로 재조정하고 분할을 처리하며 기본 제공 복제 요소를 활용합니다.
InfluxDB 설치 및 구성
| | Influx 데이터베이스를 설치하는 사용자는 누구나 InfluxDB에 대해 제공되는 모든 보안 관련 설명서를 읽고 이해해야 합니다. 사용자 이름 및 강력한 암호 사용을 포함한 보안 구성을 사용하여 InfluxDB를 설치하고 구성할 것을 강력히 권장합니다. |
| | 이 프로세스에서는 ThingWorx가 설치되어 있다고 가정합니다. ThingWorx 설치를 참조하십시오. |
| | InfluxDB 및 ThingWorx가 시간대가 서로 다른 시스템에 있는 경우 데이터를 가져오는 데 문제가 발생할 수 있습니다. 이러한 문제를 방지하려면 다음 배포 옵션 중 하나를 사용하는 것이 좋습니다. • InfluxDB 및 ThingWorx를 동일한 호스트/시스템에 배포합니다. • InfluxDB 및 ThingWorx가 서로 다른 호스트/시스템에 배포된 경우 질의 결과와 관련된 문제를 방지하도록 동기화된 클럭이 있는 -Duser.timezone Tomcat 매개 변수에 InfluxDB 서버 시간대를 맞춰야 합니다. |
1. Influx DB 다운로드 및 설치
◦ Influx DB 2.0 다운로드 및 설치 지침:
▪ InfluxDB Enterprise(고가용성): Influx 2.0에 사용할 수 없음
◦ Influx DB 1.x 다운로드 및 설치 지침:
| | InfluxDB는 Windows에서는 지원되지 않습니다. 아래 단계에서는 UNIX OS를 사용합니다. |
▪ InfluxDB 오픈 소스(단일 노드): Install InfluxDB(InfluxDB 설치) 참조
다운로드 링크:
▪ InfluxDB Enterprise(고가용성): Install an InfluxDB Enterprise cluster in your own environment(해당 환경에 InfluxDB Enterprise 클러스터 설치) 참조
다운로드 링크-데이터 노드:
다운로드 링크-메타 노드:
2. Influx1의 경우
InfluxDB에서 데이터베이스를 만듭니다. thingworxInfluxDBSetup.sh 스크립트를 가져와 실행하여 InfluxDB에서 데이터베이스를 만듭니다. 스크립트가 실행되는 위치에서 InfluxDB 명령줄 인터페이스를 사용할 수 있어야 합니다. 자세한 내용은 Launch influx(influx 시작)를 참조하십시오.
| | thingworxInfluxDBSetup.sh 스크립트는 PTC 지원 포털에서 제공하는 소프트웨어 다운로드 패키지의 install 폴더에서 사용할 수 있습니다. |
다음 명령 예는 기본 보존 정책을 사용하여 데이터베이스를 만듭니다.
CREATE DATABASE thingworx with DURATION 365d REPLICATION 1 SHARD DURATION 30d NAME autogen
| | InfluxDB 데이터 공급자는 현재 이름이 autogen인 보존 정책만 지원합니다. 데이터 공급자와 함께 사용할 데이터베이스를 생성하는 동안 정책 이름 및 다른 정책(예: 복제 요소 등)을 지정할 수 있습니다. |
InfluxDB 명령줄 인터페이스에서 InfluxDB 사용자를 만듭니다. 다음 예의 명령은 사용자를 만듭니다.
CREATE USER twadmin WITH PASSWORD 'password' WITH ALL PRIVILEGES
3. Influx2의 경우 influx setup 명령을 사용하여 초기 버킷 및 사용자를 만듭니다. 자세한 내용은 https://docs.influxdata.com/influxdb/v2.0/reference/cli/influx/setup/을 참조하십시오.
4. ThingWorx Composer에서 새 지속성 공급자를 만듭니다.
5. 지속성 공급자 패키지 필드에서 다음과 같이 선택합니다.
◦ Influx 2.0 이전 버전의 경우 InfluxPersistenceProviderPackage를 선택합니다.
◦ Influx 2.0 버전의 경우 Influx2PersistenceProviderPackage를 선택합니다.
6. 저장을 클릭합니다.
7. 구성 탭을 클릭하고 필요에 맞게 연결 정보를 구성한 후 저장합니다. 아래 표의 구성 옵션을 참조하십시오.
InfluxDB 지속성 공급자 패키지를 사용하여 작성된 지속성 공급자 인스턴스를 기본 지속성 공급자로 사용할 경우 다음 스트림 및 가치 스트림 대기열 구성 설정을 편집할 수 있습니다. 편집한 내용은 모든 스트림 및 가치 스트림에 적용됩니다. 특정 스트림 또는 가치 스트림에 대해 이러한 설정을 변경할 수 없습니다.
| | 가치 스트림의 지속성 공급자를 전환하면(예: ThingworxPersistenceProvider에서 InfluxPersistenceProviderPackage로 전환) 가치 스트림을 구현하는 모든 사물이 RestartThing 서비스를 호출하여 새 지속성 공급자에 쓰여진 엔트리를 검색해야 합니다. 사물이 재시작되지 않으면 엔트리가 데이터베이스에 쓰여질 수도 있지만 사물이 재시작될 때까지 이러한 엔트리를 검색하지 않습니다. |
이름 | 설명 | 기본값 | ||
|---|---|---|---|---|
연결 URL | 연결을 확보해야 하는 데이터베이스의 URL입니다. | http://localhost:8086 | ||
토큰 | 암호 대신 사용되는 시스템 액세스를 위한 보안 토큰입니다. 앱 키와 유사합니다. | |||
조직 이름 | 조직의 이름 | |||
버킷 이름 | 데이터 버킷(모든 데이터가 저장되는 스키마)의 이름입니다. | |||
버킷 자동 생성 | true로 설정하면 bucketName에 지정된 버킷이 아직 없는 경우 해당 버킷을 만듭니다. 그렇지 않으면 버킷이 없는 경우 오류가 발생합니다. | False | ||
보존 기간(일) | 데이터의 보존 일 수입니다. 이 기간 후에 데이터가 삭제됩니다. 기본값이 0이며, 이는 데이터를 영구 유지하는 것입니다. | 0 | ||
일괄 처리 크기 | 이는 Influx 클라이언트에서 사용하는 일괄 처리 크기입니다. 성능 향상을 위해 항상 데이터 요소를 일괄적으로 보냅니다. 이는 스트림 일괄 처리 크기에 추가됩니다. 일괄 처리 크기 수의 데이터 요소를 보낼 준비가 되면 데이터를 Influx에 보냅니다.
| 1000 | ||
플러시 간격 | Influx 클라이언트가 일괄 처리 크기에 도달하지 않은 경우 데이터를 플러시하는 빈도를 나타냅니다. 값은 밀리초로 지정됩니다.
| 초당 1000번 또는 한 번 | ||
지속성 공급자로부터 데이터 가져오기 크기 | 클라이언트 측에서 모든 행을 캐시하는 대신 일괄적으로 가져올 행의 수입니다. | 5000 | ||
연결 제한 시간에 대한 시간 | Influx에 연결을 시도하는 시간입니다. 값은 초로 지정됩니다. | 10 | ||
읽기 제한 시간에 대한 시간 | 요청에 대해 Influx에서 데이터를 읽는 시간입니다. 값은 초로 지정됩니다. | 10 | ||
쓰기 제한 시간에 대한 시간 | Influx에 데이터 쓰기를 시도하는 시간입니다. 값은 초로 지정됩니다.
| 10 | ||
로그 수준 | Influx 클라이언트 및 로그의 로그 수준이 콘솔 출력으로 전송됩니다. 이 값은 더 많은 정보를 제공하는 각 수준을 포함한 NONE, BASIC, HEADERS 또는 BODY일 수 있습니다. | 없음 |
이름 | 설명 | 기본값 |
|---|---|---|
연결 URL | 연결을 확보해야 하는 데이터베이스의 URL입니다. | http://localhost:8086 |
데이터베이스 스키마 | 연결할 스키마입니다. | thingworx |
사용자 이름 | 데이터베이스 연결을 확보해야 하는 사용자 이름입니다. | twadmin |
암호 | 데이터베이스 연결을 확보해야 하는 암호입니다. | 해당 없음 |
지속성 공급자로부터 데이터 가져오기 크기 | 지속성 공급자로부터 데이터 가져오기 크기입니다. | 5000 |
연결 제한 시간에 대한 시간 | 연결 제한 시간에 대한 시간(초)입니다. | 10 |
읽기 제한 시간에 대한 시간 | 읽기 제한 시간에 대한 시간(초)입니다. | 10 |
쓰기 제한 시간에 대한 시간 | 쓰기 제한 시간에 대한 시간(초)입니다. | 10 |
이름 | 설명 | 기본 유형 | 기본값 | ||
|---|---|---|---|---|---|
최대 대기열 크기 | 대기할 스트림 엔트리의 최대 수입니다. 지정된 값에 도달하면 후속 엔트리가 거부됩니다. | 숫자 | 250000 | ||
스트림 버퍼를 플러시하기 전 최대 대기 시간(밀리초) | 스트림 버퍼를 플러시하기 전에 시스템이 대기하는 시간(밀리초)입니다. | 숫자 | 2000 | ||
처리 스레드 수 | 스트림 전용 처리 스레드 수입니다.
| 숫자 | 5 | ||
스트림 버퍼를 플러시하기 전 최대 항목 수 | 스트림 버퍼를 플러시하기 전 누적되는 최대 항목 수입니다. | 숫자 | 1000 | ||
Process 블록의 가치 스트림 쓰기 최대 수 | 블록 하나에서 처리할 스트림 쓰기 최대 수입니다. | 숫자 | 2500 | ||
버퍼 상태 검색 속도(밀리초) | 지정된 속도 값(밀리초)에서 버퍼 상태를 확인합니다. | 숫자 | 5 |
이름 | 설명 | 기본 유형 | 기본값 | ||
|---|---|---|---|---|---|
최대 대기열 크기 | 대기할 가치 스트림 엔트리의 최대 수입니다. 지정된 값에 도달하면 다음 엔트리가 거부됩니다. | 숫자 | 500000 | ||
가치 스트림 버퍼를 플러시하기 전 최대 대기 시간(밀리초) | 가치 스트림 버퍼를 플러시하기 전에 시스템이 대기하는 시간(밀리초)입니다. | 숫자 | 10000 | ||
처리 스레드 수 | 가치 스트림에 할당된 처리 스레드 수입니다.
| 숫자 | 5 | ||
값 버퍼를 플러시하기 전 최대 항목 수 | 가치 스트림 버퍼를 플러시하기 전 누적되는 최대 항목 수입니다. | 숫자 | 1000 | ||
Process 블록의 가치 스트림 쓰기 최대 수 | 블록 하나에서 처리할 항목 최대 수입니다. | 숫자 | 2500 | ||
버퍼 상태 검색 속도(밀리초) | 지정된 속도 값(밀리초)에서 버퍼 상태를 확인합니다. | 숫자 | 5 |
8. 일반 정보 탭을 클릭하고 활성 확인란을 선택합니다. 
9. 저장을 클릭합니다.
모범 사례
계열 제한
계열은 InfluxDB에 로그인된 모든 사물의 총 속성 수입니다. InfluxDB는 대량의 데이터 볼륨이 소량의 사물 및 사물 속성(예: 10Ks 또는 100Ks)으로 향할 때 양호한 성능을 제공합니다. InfluxDB에서는 총 계열 수가 기본적으로 백만 개로 제한됩니다. 이 제한을 늘릴 수는 있지만 계열 수가 이 제한을 초과하면 InfluxDB 성능이 저하됩니다.
사물 및 속성이 많은 경우 데이터 볼륨이 가장 많은 항목을 선택한 후 이러한 사물 및 속성만 InfluxDB로 향하도록 지정하여 PostgreSQL 또는 MSSQL의 부하를 덜 수 있습니다.
또는 계열을 여러 서버로 나누려는 경우 InfluxDB 데이터 공급자의 여러 인스턴스가 서로 다른 InfluxDB 서버 인스턴스를 가리키도록 할 수 있습니다.
쓰기 제한
코어 32개에 60GB 메모리 VM을 사용하는 경우 초당 100K 쓰기가 가능합니다. 이 제한을 초과하면 ThingWorx에 문제가 발생할 수 있으며, 이로 인해 리소스가 고갈되어 요청이나 작업(예: 데이터베이스에 쓰기)을 처리할 수 없게 됩니다. 이때 ThingWorx는 정지되지만 InfluxDB는 데이터베이스에 계속 쓰고 있습니다. 이 문제는 PostgreSQL에서는 발생하지 않습니다. PostgreSQL이 병목 지점이 되므로 ThingWorx가 내부의 작업을 처리할 수 없을 만큼 리소스가 고갈되는 시점에 도달하는 일이 없기 때문입니다.
SSL/보안 연결
InfluxDB는 SSL 및 HTTPS 연결을 지원합니다. ThingWorx와 InfluxDB 간 네트워크가 지원되지 않는 경우 SSL 및 HTTPS 연결을 사용하여 보안을 강화할 수 있습니다. 서명 개인 키가 안전하게 보관되는 경우 자체 서명된 인증서가 적합합니다.
속성 기본 유형에 대해 알려진 InfluxDB 제한 사항
가치 스트림에 기록된 후에는 속성의 기본 유형을 변경할 수 없습니다. 자세한 내용은 Type conflict on insert int value in float field #3460(부동 필드 #3460에 int 값 삽입 시 유형 충돌)을 참조하십시오.
속성 제거
PurgeAllPropertyHistory, PurgeSelectedPropertyHistory 및 PurgePropertyHistory 서비스를 사용하여 InfluxDB에서 속성을 제거할 수 있습니다. startDate 및 endDate 매개 변수를 사용하여 범위를 지정합니다.
| | Influx2PersistenceProviderPackage 공급자를 사용할 경우에는 제거가 지원되지 않습니다. PurgePropertyHistory, PurgeAllPropertyHistory, PurgeSelectedPropertyHistory 서비스는 아무런 영향을 주지 않습니다. |