가장 연결 가능한브로커

만약 증권사가 제공하는 윈도우옹 API와 같은 기능중 ZeroAOS가 필요로 하는 기능만 리눅스로 구현하면 어떨까?

LabVIEW와 산업용 IoT 연결을 위한 실무 가이드

이 백서에서는 사물인터넷(IoT) 어플리케이션용 클라우드 기반 개발 플랫폼에 연결할 수 있는 가장 널리 사용되는 세 가지 통신 프로토콜을 소개합니다. 또한 Amazon Web Services, IBM Bluemix, PTC ThingWorx 및 Microsoft Azure와 같은 가장 일반적인 IoT 클라우드 개발 플랫폼에 대한 정보도 확인할 수 있습니다. 그리고 LabVIEW 개방형 그래픽 개발 환경을 통해 CompactRIO와 같은 NI 임베디드 시스템을 이러한 클라우드 플랫폼에 연결하는 방법도 알아보십시오.

• 세상을 변화시키는 IoT
• MQTT
• AMQP
• DDS
• Amazon AWS IoT
• Bluemix용 IBM Watson IoT
• PTC ThingWorx
• Microsoft Azure IoT Suite

세상을 변화시키는 IoT

인터넷을 사용할 수 있는 새로운 어플리케이션이 세상에 나오면서 향후 10년 안에 세계 경제는 크게 변화할 것입니다. 이러한 어플리케이션 중 일부는 경제적으로 큰 영향을 미칠 뿐만 아니라 파괴적이고 혁신적일 수 있습니다. 이는 호텔(Airbnb)과 택시(Uber)와 같은 소비자 부문에서 이미 경험했듯이 많은 산업과 부문에 영향을 미칠 것입니다.

독일의 4차 산업혁명 이니셔티브 등 업계에서도 이런 경향이 두드러지게 나타나고 있습니다. 4차 산업혁명 또는 IIoT(산업용 IoT)에서는 기존 기술의 통합과 더 나은 사용에 초점을 맞추고 있습니다. 그런 의미에서 산업, 기계, 제품, 사람은 모두 디지털로 연결되어 있습니다. 제조업체는 1개의 수량으로 맞춤형 제품을 양산하고 있습니다. 클라우드의 지능형 소프트웨어는 엔터프라이즈 IT 시스템을 운영 환경, 기기, 디바이스, 센서와 연결하여 생산 흐름을 제어하고 최적화합니다.

그림 1 – 산업용 IoT의 일반적인 아키텍처: 지능형 에지 노드가 센서, 액추에이터 및 디바이스를 IT 시스템에 연결

연결 비용이 감소하면서 처리 디바이스 및 센서의 IIoT 도입이 엄청나게 증가했습니다. 센서 데이터는 CompactRIO 또는 PXI 자동화 테스트 시스템과 같은 스마트 에지 장치로 기기 가까이에서 캡처되고 사전 처리될 수 있습니다. 에지 디바이스는 데이터를 저장하고·모니터링하며·분석하거나 동작을 트리거할 수 있는 가상세계(가장 연결 가능한브로커 IT 클라우드 플랫폼)로 실시간으로 전송할 수 있습니다.

IIoT의 가치는 디바이스의 연결성에 있는 것이 아니라 스마트 디바이스가 제공하는 데이터 스트림에서 기업이 실현하는 것에 있습니다. 클라우드 컴퓨팅 플랫폼과 해당 서비스가 이러한 인사이트를 제공하는 데 도움이 됩니다.

IoT 솔루션을 구현할 때 중요한 여러 가지 문제를 고려해야 합니다. 표준화, 상호 운용성, 빅 아날로그 데이터™ 처리, 보안 및 개인 정보 보호와 같은 과제가 그것입니다. 이러한 과제를 인식하고 보안에 각별히 신경 쓰는 것이 중요합니다. 보안은 모든 IoT 어플리케이션에서 중요한 구성요소입니다. IIoT 디바이스에서는 강력한 보안 정책을 적용하고 최신 보안 패치를 정기적으로 업데이트해야 합니다. CompactRIO의 보안 모범 사례에 대해 자세히 알아보고 NI에서 최신 보안 정보를 받으시려면 ni.com/support/security를 방문하십시오. 모든 클라우드 컴퓨팅 플랫폼은 안전하게 데이터를 주고받으며 강력한 인증 및 승인 방식을 사용하는 것은 물론 암호화도 사용합니다. 대다수는 감사 기능도 갖추고 있습니다.

클라우드 컴퓨팅

클라우드 컴퓨팅은 로컬 컴퓨터에서 소프트웨어 어플리케이션을 실행하는 것과 달리, 사용자의 요청에 따라 네트워크를 통해 하드웨어, 소프트웨어 또는 데이터 리소스를 제공하는 유연한 방법입니다.

그림 2 - 클라우드 컴퓨팅 요소의 개요(이미지 출처: Sam Johnston https://commons.wikimedia.org/wiki/File:Cloud_computing.svg)

아래 표는 자주 사용되는 클라우드 컴퓨팅의 세 가지 서비스 레벨을 보여줍니다.

완전한 비즈니스 서비스를 제공합니다. 서비스 제공자는 전체 플랫폼을 실행하고 관리합니다. 예: Gmail, Salesforce.com

플랫폼을 제공합니다. 공급업체가 제공하는 실행 시간과 서비스를 활용하여 자체 클라우드 어플리케이션을 구축하고 배포해야 합니다. 예: IBM Bluemix, Microsoft Azure, AWS IoT

서버 하드웨어, 스토리지 및 네트워크 기능과 같은 기본 구성요소를 제공합니다. OS 및 어플리케이션을 설치해야 할 수도 있습니다. 예: Amazon EC2(Amazon에서 제공하는 가상 시스템), IBM SoftLayer

클라우드는 모든 서비스가 클라우드에서 호스팅되는 보안 환경에서 실행되며 다른 사용자와 서버를 공유할 수 있는 공용 클라우드로 또는 사용자 조직에서만 사용 가능하고 온프레미스 또는 오프프레미스 방식으로 실행되는 사설 클라우드로 배포할 수 있습니다. 또한 클라우드는 일부가 온프레미스에 있고 다른 서비스가 클라우드에 있는 하이브리드 방식으로도 배포할 수 있습니다.

IoT 어플리케이션 프로토콜

통신 프로토콜은 서버에 대한 네트워크를 연결합니다. Wi-Fi, 이더넷, 셀룰러 및 LoRaWAN과 같은 프로토콜은 모두 통신 프로토콜로 이러한 수준의 연결을 제공합니다. 어플리케이션 프로토콜은 어플리케이션별 메시지를 가장 연결 가능한브로커 통신하기 위해 통신 프로토콜 위에 위치합니다.

다양한 표준이 디바이스와 클라우드 간의 통신을 처리합니다. 어플리케이션 요구사항이 다르기 때문에 특정 IoT 프로토콜이 개발되었고 이로 인한 혼란이 자주 발생합니다. 프로토콜은 다양한 형태로 구현될 수 있으며 IoT 플랫폼에는 전용 IoT 솔루션이 있을 수 있습니다. 범용 솔루션을 제공하려면 디바이스, 어플리케이션 및 플랫폼의 상호 운용이 가능해야 합니다. NI 임베디드 시스템은 개방적이고 유연하므로 우수한 솔루션을 제공합니다. 이는 NI Linux Real-Time OS, LabVIEW 그래픽 및 Eclipse C 프로그래밍 환경 지원, 활기찬 에코시스템을 통해 사용할 수 있는 여러 Linux 패키지를 통해 실현됩니다.

상위 레벨에서 어플리케이션 프로토콜에는 세 가지 주요 사용 사례가 있는데 이는 디바이스 대 디바이스(D2D 또는 M2M), 디바이스 대 서버(D2S) 및 서버 대 서버(S2S) 통신입니다. IoT 어플리케이션 프로토콜은 다양한 레벨의 실시간 동작 및 기타 특성을 지녔습니다. 아래 표를 통해 개요를 확인하십시오.

가장 연결 가능한브로커

You are using an outdated browser. Please upgrade your browser to improve your experience.

이 항목에서는 Universal Broker 로의 전환을 스케줄링하고, 준비하고, 완료하는 단계를 안내합니다. 다음 절차에 따라 Universal Broker 서비스를 설정하고, 전환에 대한 시작 날짜와 시간을 정의하고, 성공적인 전환 프로세스의 단계로 원활하게 이동하는 방법을 알아보십시오.

브로커 전환을 스케줄링할 준비가 되면 Horizon Universal Console 맨 위에 스케줄링 버튼이 있는 알림 배너가 표시됩니다.

참고: 배너에 전환 스케줄링을 방지하는 오류 상태가 표시될 경우 전환을 위한 하나 이상의 사전 요구 사항을 충족하지 못한 것일 수 있습니다. 배너에서 오류 보기 를 클릭한 다음, 브로커 페이지의 전환 필요 링크 옆에 있는 오류 아이콘을 클릭하여 오류 조건에 대한 세부 정보를 볼 수 있습니다. 전환을 스케줄링하려면 먼저 필요한 단계를 수행하여 오류 조건을 지워야 합니다.

사전 요구 사항

1. 브로커 전환에 대한 알림 배너에서 스케줄링 을 클릭합니다.

이 작업을 수행하면 [브로커] 페이지로 리디렉션됩니다. 이 가장 연결 가능한브로커 페이지에는 단일 포드 브로커가 현재 테넌트에 대해 사용하도록 설정되어 있으며 브로커 전환을 스케줄링하기 위한 링크가 제공됩니다.

Universal Broker 에 대한 구성 마법사가 나타납니다. 이 마법사의 단계를 완료하여 Microsoft Azure의 포드에 대한 Universal Broker 를 설정하고 Universal Broker 로의 전환을 스케줄링해야 합니다.

참고: 일부 문자열은 시스템에서 허용되지 않거나 예약되어 있습니다. 이 범주의 문자열에는 일반 단어(예: book ), 잘 알려진 회사 소유 용어(예: gmail ) 및 프로토콜, 코딩 및 오픈 소스 용어(예: php 및 sql )가 포함됩니다. 또한 시스템은 mail0 , mail1 , mail2 등과 같은 문자열 패턴 범주를 허용하지 않습니다.

그러나 이 필드에 허용되지 않는 이름을 입력하는 즉시 시스템이 항목의 유효성을 검사하는 것은 아닙니다. 마법사의 마지막 요약 단계에 도달한 경우에만 여기에서 입력한 이름이 유효한지 검사하고, 항목이 허용되지 않는 이름 중 하나와 일치하는 경우 오류를 표시합니다. 이 문제가 발생하면 여기에 다른 고유한 이름을 입력하십시오.

Horizon Client 를 사용하여 Universal Broker 서비스에 연결할 수 있도록 하기 위해 최종 사용자에게 이 FQDN을 제공합니다.

사용자 지정 FQDN에 지정된 도메인 이름의 소유자여야 하며 해당 도메인의 유효성을 검사할 수 있는 인증서를 제공해야 합니다.

중요: 사용자 지정 FQDN을 Universal Broker 서비스의 내부 연결 주소를 나타내는 VMware 제공 FQDN에 매핑하는 CNAME 레코드를 DNS 서버에서 생성해야 합니다. 예를 들어 이 레코드는 vdi.examplecompany.com 을 <자동 생성 문자열>.vmwarehorizon.com 에 매핑할 수 있습니다.

찾아보기 를 클릭하고, 브로커링 FQDN을 검증하는 인증서(암호로 보호되는 PFX 형식)를 업로드합니다. 인증서는 다음 조건을 모두 충족해야 합니다.

• 인증서는 90일 이상 유효해야 합니다.
• 인증서에는 신뢰할 수 있는 CA의 서명이 있어야 합니다.
• 인증서의 CN(일반 이름) 또는 해당 SAN(주체 대체 이름)이 FQDN과 일치해야 합니다.
• 인증서의 컨텐츠는 표준 X.509 형식을 준수해야 합니다.

PFX 파일에 전체 인증서 체인과 개인 키, 즉 도메인 인증서 중간 인증서, 루트 CA 인증서, 개인 키가 포함되어야 합니다.

Universal Broker 서비스는 이 인증서를 사용하여 클라이언트와의 신뢰할 수 있는 연결 세션을 설정합니다.

VMware 제공 FQDN은 최종 사용자에게 보이지 않으며 Universal Broker 서비스의 내부 연결 주소를 나타냅니다. 사용자 지정 FQDN은 VMware 제공 FQDN에 대한 별칭으로 작동합니다.

중요: 사용자 지정 FQDN을 VMware 제공 FQDN에 매핑하는 CNAME 레코드를DNS 서버에 생성하여 별칭 연결을 설정해야 합니다. 예를 들어 이 레코드는 vdi.examplecompany.com 을 <자동 생성 문자열>.vmwarehorizon.com 에 매핑할 수 있습니다.

기본적으로 Universal Broker 는 Active Directory 사용자 이름 및 암호를 통해서만 사용자를 인증합니다. 추가 인증 방법을 지정하여 2단계 인증을 구현할 수 있습니다. 자세한 내용은 Universal Broker 환경에서 2단계 인증을 구현할 때의 모범 사례 항목을 참조하십시오.

중요: Universal Broker 에 2단계 인증을 사용하려면 먼저 모든 참여 포드 내의 각 외부 Unified Access Gateway 인스턴스에 적절한 인증 서비스를 구성해야 합니다. 외부 Unified Access Gateway 인스턴스의 구성은 참여 포드 내부 및 사이에서 동일해야 합니다.

예를 들어 RADIUS 인증을 사용하려는 경우 모든 참여 Horizon 포드 및 Microsoft Azure의 포드에 있는 각 외부 Unified Access Gateway 인스턴스에서 RADIUS 서비스를 구성해야 합니다.

참여 포드 내의 Unified Access Gateway 인스턴스는 삭제하지 마십시오. Universal Broker 는 Horizon Client와 가상 리소스 간의 프로토콜 트래픽에 대해 Unified Access Gateway 에 의존하므로 해당 포드에서 Unified Access Gateway 인스턴스를 삭제하면 참여 포드에서 프로비저닝된 리소스에 액세스할 수 없게 됩니다.

2단계 인증을 사용하려면 이 토글을 사용하도록 설정합니다.

이 토글을 사용하도록 설정하면 2단계 인증을 구성하기 위한 추가 옵션이 제공됩니다.

이 토글을 해제하는 경우 사용자는 로그인 화면에서 다른 사용자 이름을 입력할 수 있습니다.

Active Directory 사용자 이름 및 암호 외에 Universal Broker 가 최종 사용자에게 사용해야 하는 인증 방법을 지정합니다. 사용자 인터페이스에 두 가지 옵션( RADIUS 및 RSA SecurID )이 표시됩니다.

이 설정은 테넌트 전체에 적용됩니다. 최종 사용자 클라이언트의 동작은 다음과 같이 테넌트의 포드 그룹 구성 및 포드 게이트웨이에 구성된 2단계 인증 유형에 따라 달라집니다.

• 포드의 외부 게이트웨이에 구성된 유형과 일치하는 유형을 선택합니다.

혼합 그룹의 경우 여기에서 RSA SecurID 를 선택하면 클라이언트 동작은 Horizon Cloud on Microsoft Azure 배포가 외부 게이트웨이에서 RSA SecurID로 구성되었는지 여부에 따라 달라집니다.

• Horizon Cloud on Microsoft Azure 배포의 게이트웨이에 가장 연결 가능한브로커 RSA SecurID 유형이 구성되어 있지 않고 여기에서 RSA SecurID 를 선택하면 Horizon 포드의 Unified Access Gateway 인스턴스를 통해서만 사용자의 RSA 인증 요청이 시작됩니다. Active Directory 사용자 이름 및 암호 인증 요청은 Horizon 포드 또는 Horizon Cloud 포드의 Unified Access Gateway 인스턴스를 통해 시도됩니다.
• Horizon Cloud on Microsoft Azure 배포에 RSA SecurID 유형이 구성되어 있으면 두 포드 유형의 Unified Access Gateway 인스턴스를 통해 사용자의 RSA 인증 요청이 시도됩니다.

클라이언트 로그인 화면에 표시하려는 텍스트 문자열을 입력합니다. 지정된 힌트는 최종 사용자에게 Enter your DisplayHint user name and password 로 표시됩니다. 여기서 DisplayHint 는 사용자가 이 텍스트 상자에 입력하는 텍스트 문자열입니다.

이러한 금지된 문자를 힌트 텍스트에 포함하면 Universal Broker FQDN에 대한 사용자 연결이 실패합니다.

이 힌트는 사용자가 올바른 자격 증명을 입력하도록 안내합니다. 예를 들어, 회사 사용자 이름 및 도메인 암호 와 같은 구문을 지정하면 최종 사용자에게 Enter your Company user name and domain password below for user name and password 라는 메시지가 표시됩니다.

이 토글을 가장 연결 가능한브로커 사용하도록 설정하여 Universal Broker 서비스에 연결하는 내부 네트워크 사용자에 대해 2단계 인증을 우회합니다. Universal Broker에 대한 내부 네트워크 범위 정의에 설명된 대로 내부 네트워크에 속하는 공용 IP 범위를 지정했는지 확인합니다.

• 이 토글을 사용하도록 설정하면 내부 사용자는 Universal Broker 서비스에서 인증을 받기 위해 Active Directory 자격 증명만 입력하면 됩니다. 외부 사용자는 추가 인증 서비스에 대해 Active Directory 자격 증명과 해당 자격 증명을 모두 입력해야 합니다.
• 이 토글을 끄면 내부 및 외부 사용자 모두 추가 인증 서비스에 대한 Active Directory 자격 증명과 해당 자격 증명을 입력해야 합니다.

이 필드는 2단계 인증 건너뛰기 를 사용하도록 설정한 경우에 나타납니다.

[브로커] 페이지의 [네트워크 범위] 탭에 하나 이상의 공용 IP 범위가 이미 지정된 경우 이 필드는 읽기 전용이며 가장 연결 가능한브로커 해당 IP 범위를 나열합니다.

[브로커] 페이지의 [네트워크 범위] 탭에 공용 IP 범위가 아직 지정되지 않은 경우 이 필드를 사용하여 해당 범위에서 들어오는 트래픽에 대한 2단계 인증 프롬프트를 건너뛰기 위해 내부 네트워크를 나타내는 공용 IP 범위를 지정할 수 있습니다. Universal Broker 는 이러한 범위 중 하나에 속하는 IP 주소에서 연결하는 모든 사용자를 내부 사용자로 간주합니다.

이러한 범위를 지정하는 목적에 대한 자세한 내용은 Universal Broker에 대한 내부 네트워크 범위 정의 항목을 참조하십시오.

이러한 시간 초과 설정은 Horizon Client 와 Universal Broker 에서 할당된 데스크톱 간의 연결 세션에 적용됩니다. 이러한 설정은 할당된 데스크톱의 게스트 운영 체제에 대한 사용자의 로그인 세션에 적용되지 않습니다. Universal Broker 는 이러한 설정으로 지정된 시간 초과 조건을 감지하면 사용자의 Horizon Client 연결 세션을 닫습니다.

설정	설명
Client Heartbeat Interval	Horizon Client 하트비트 간 간격(분)과 Universal Broker 에 대한 사용자 연결 상태를 제어합니다. 이러한 하트비트는 Horizon Client 연결 세션 동안 경과된 유휴 시간을 Universal Broker 에 보고합니다.

Horizon Client 를 실행하는 끝점 디바이스와의 상호 작용이 발생하지 않을 때 유휴 시간이 측정됩니다. 이 유휴 시간은 사용자가 할당한 데스크톱의 기준이 되는 게스트 운영 체제에 대한 로그인 세션이 비활성 상태가 되어도 영향을 받지 않습니다.

대규모 데스크톱 배포에서 가장 연결 가능한브로커 클라이언트 하트비트 간격 을 늘리면 네트워크 트래픽이 줄어들고 성능이 향상될 수 있습니다.

최대 시간에 도달하면 사용자의 인증 기간이 만료되고 Universal Broker 는 모든 활성 Horizon Client 세션을 닫습니다. 연결 세션을 다시 열려면 사용자가 Universal Broker 로그인 화면에서 인증 자격 증명을 다시 입력해야 합니다.

MQTT Protocol

MQTT(Message Queue Telemetry Transport)는 IOT 기기간의 통신을 위한 프로토콜이다. MQTT 이외에도 IOT용으로 CoAP(Constrained Application Protocol), AMQP(Advanced Message Queuing Protocol), XMPP(eXtensible Messaging and Presence Protocol), DDS(Data Distribution Service), Stomp(Simple Text Orientated Messaging Protocol) 등의 다양한 프로토콜이 있고, 각각의 프로토콜은 활용 용도에 따라서 장단점을 가지고 있다.

여기에서는 MQTT의 특징에 대해서 정리하기로 한다.

MQTT의 특징

TCP 기반 프로토콜

UDP가 아닌 TCP 기반이라 작은 IOT 기기에서는 사용이 어려울 수 있다. MQTT 프로토콜에서 사용자 인증을 제공한다. 하지만 이를 위한 username, password 필드는 cleartext로 전달되므로 이들 정보와 송수신 데이타를 보호하기 위하여는 별도로 암호화를 하거나 SSL/TLS를 이용하여 암호화 채널을 이용하여야 한다. 결과적으로 public 망에서 운영되는 IOT 기기는 MQTT, TCP, TLS를 지원할 수 있는 OS와 메모리 사양이 되어야 한다.

Session Oriented

MQTT는 client-server protocol로, client는 센서 장치 또는 모니터링 장비(PC, 스마트 기기)가 될 수 있고, server는 broker라고 칭한다. Broker는 연결된 client 와의 session을 관리하고, 다른 broker와 연결하기도 한다. 초기 세션 수립은 client에서 broker로 MQTT CONNECT 메시지를 전송하여 이루어진다. 이후 이 TCP 세션은 client가 사용을 중단할 때까지 유지하여 메시지를 주고 받는 용도로 사용한다.

Exteremely Lightweight Publish / Subscribe Messaging Protocol

메시지 큐 프로토콜은 채팅과 유사한 개념이라고 생각하면 된다. IRC 채팅 개념과 비교하면 아래와 같다.

IRC 채팅	MQTT
IRC Server	MQTT Broker
Channel	Topic
Join a channel	Subscribe

IRC는 명시적인 channel에 join 하는 것이라면 MQTT는 wildcards 로 여러 topic을 한꺼번에 subscribe 할 수 있다.

Topic

Topic 은 아래의 예와 같이 계층적으로 구성할 수 있다. (아래 예는 HiveMQ 의 페이지 내용을 참고한 것으로 관련 내용을 읽어보는 것도 좋을 듯 하다)

여러 topic 을 한번에 subscribe 하기 위하여는 single level ’+’나 multi level ‘#’ 을 사용할 수 있다. Single level은 아래 처럼 topic 중간에 wildcard를 사용하는 가장 연결 가능한브로커 것이다.

위와 같이 subscribe 하게 되면 다음과 같은 topic 이 포함된다.

• myhome/groundfloor/livingroom/temperature
• myhome/groundfloor/kitchen/temperature

Multi level wildcard는 마지막에 사용할 수 있다.

위와 같이 subscribe 하게 되면 다음과 같은 topic 이 포함된다.

• myhome/groundfloor/livingroom/temperature
• myhome/groundfloor/livingroom/brightness
• myhome/groundfloor/kitchen/temperature

Subscribe / Publish

일반적인 센서 노드는 정보를 주기적으로 publish 한다(publisher). 반대로 모니터링을 위한 스마트 기기는 필요한 topic 을 subscribe 하여(receiver) 센서 노드에서 오는 정보를 활용한다.

단순한 예를 보면 다음과 같을 것이다.

• Receiver는 수신 받기를 원하는 topic 을 subscribe 한다.
• Publisher는 가장 연결 가능한브로커 필요 시점마다 publish 하면 broker는 이를 subscribe 되어 있는 client 로 전달하여 준다.

다수의 receiver가 동일 topic 으로 subscribe 할 수 있고, 이 경우 broker는 모든 subscriber에게 publish message를 전송한다.

동작 방식은 프로토콜 이름 처럼 ‘message queue’ 방식이다. 개념적으로 보면 broker는 다음과 같은 절차로 수행한다.

1. Publisher에서 수신된 message를 queue 에 저장
2. QoS 종류에 따라 publisher에 ack 응답
3. Queue에 저장된 메시지를 subscriber에게 전송 및 QoS 에 따라 ack 응답 확인
4. Queue에 저장된 메시지를 삭제하거나 설정에 따라 가장 연결 가능한브로커 유지 (retain field)

메시지를 전송하는 경우 메시지의 특성 및 중요도에 따라서 수신측이 정확히 전송을 받았는지를 확인할 필요가 있다. MQTT 에서는 QoS level로 이와 같은 설정을 할 수 있다.

• QoS 0 (at most once): 수신측 확인 없이 1회 전송
• QoS 1 (at least once): 수신측의 ACK를 확인 및 재전송 (재전송으로 수신측에서는 중복된 message를 받을 수 있음)
• QoS 2 (exactly once): 송신 및 수신측 모두 메시지가 정상적으로 전송되었는 지 확인

여기서 수신측이라 하는 것은 최종 receiver를 말하는 것이 아니라 client이면 broker를 broker이면 publish를 전달하는 client를 말한다.

각각의 QoS 레벨에 따라 전달되는 protocol 절차는 아래와 같다.

QoS0는 별도의 ACK 없이 전송하는 것이고, QoS1는 PUBACK(Publish Acknowledge)로 수신 확인을 한다. 만일 송신 측에서 PUBACK를 지정된 시간에 받지 못하면 PUBLISH를 동일한 ID로 duplicate flag를 설정하여 재전송한다. QoS2 의 경우 송신 측에서 응답을 받았는지도 확인하는 절차로 PUBREC(Publish Received), PUBREL(Publish Release), PUBCOMP(Publish Complete) 까지 4-way handshaking을 수행한다.

Lossless를 보장하는 TCP layer 위에서 운영하는 경우 이와 같은 QoS의 실효성이 의심스러울 수 있다. 또한 이 QoS 절차도 server-client 간의 절차로 아래처럼 QoS2를 사용하는 경우에도 최종단이 수신하기 전에 송신 절차는 종료된다.

이 부분은 다음과 같이 이해하여야 한다.

• QoS0는 client가 전송한 메시지를 broker가 받았는지 확인이 불가능하다. 예를 들어 송신중 연결이 끊어진 경우 이 메시지가 상대방에 전달이 되었는지를 확인할 수 없다. 주기적으로 전송되는 온도 값과 같은 경우 이와 같은 방식으로 전달하여도 문제는 없을 것이다.
• Broker 관점에서 QoS0 메시지는 별도로 queueing을 하지 않는다. QoS1/QoS2 의 경우 queueing 되어 offline 되어 있는 persistence session (아래 clean session 참고)이 이후 online 된 경우 전달할 수 있다.
• QoS2의 경우 동일 메시지가 중복되어 전달되는 경우 심각한 문제를 야기할 수 있는 경우에 사용할 수 있다. QoS1의 경우 PUBACK를 broker가 응답하는 시점에서 연결이 끊어졌다면 송신측은 미전송이지만, 수신측은 정상적으로 수신한 상태가 된다.

WiFi와 같이 채널 연결이 쉽게 끊어질 수 있는 경우라면 QoS 설정에 대하여 충분한 고려가 되어야 할 것이나 보통은 서버의 queueing 필요성에 따라서 QoS0, QoS1 중 선택하여 보내면 될 것 같다.

각각의 client는 초기에 MQTT CONNECT 시 자신이 받을 수 있는 최대 QoS를 지정할 수 있다. 이 경우 broker는 해당 client로 전송할 때 이 QoS보다 높은 경우 설정된 QoS로 낮추어 전송한다.

Others

Clean Session

Client는 CONNECT 시 cleanSession flag를 설정하여 보낼 수 있다. Persistence session을 유지하여야 하는 경우에는 이 flag를 false로 하여 보낸다. Broker는 이와 같은 persistence session을 요청하는 client에 대해서는 다음과 같은 정보를 저장 관리 하므로 연결이 끊어졌다 재 종료 시에도 재설정이 필요없다.

• 모든 subscription
• QoS1,2 (송수신) 메시지 중 해당 client가 응답하지 않은 메시지
• Client가 offline 중 발생된 QoS1,2 메시지

표준에는 broker가 이들 정보를 얼마만큼의 시간동안 유지 시켜줄지는 규정되어 있지 않다. Client는 CONNECT ACK 메시지의 sessionPresent 필드로 이전 가장 연결 가능한브로커 세션이 broker에 유지되고 있는지를 확인할 수 있다.

CONNECT 시 cleanSession을 true로 설정한 경우 broker는 해당 client에 대한 기존 유지되어 있던 session도 clear하고 향후 연결 종료시에도 session을 저장하지 않는다.

Retained Message

Client는 PUBLISH로 메시지를 전송 시 retained flag를 설정할 수 있다. 이 field가 true로 되어 있는 경우 broker는 해당 topic의 최종 메시지를 저장하여 차후 subscribe 되는 client가 있는 경우 이를 전송하여 준다.

새로 연결되어 subscribe하는 client 에게 최종 상태를 알려주는 용도로 사용할 수 있다.

lastWill

Client는 CONNECT 시 lastWill로 비정상용 publish 메시지를 설정할 수 있다. Client가 DISCONNECT와 같이 정상절차로 종료 되지 않고 비정상적으로 연결이 끊긴 경우 이 메시지를 subscriber에게 전송한다.

이를 이용하여 자신의 online, offline 여부를 알려주는 용도로 사용할 수 있을 것이다. 예를 들어 초기 connect시 lastWill message로 ’client/status’ topic 에 ‘offline’으로 payload를 설정해 두고, 처음에 ‘online’으로 publish를 한다면 비정상적으로 종료되는 경우 lastWill 메시지가 전송되어 subscriber는 상태를 알 수 있게 된다.

Keepalive

Client는 MQTT CONNECT 시 Keep Alive 필드를 이용하여 keep alive interval을 설정할 수 있다. 이 경우 client는 전송할 메시지가 없는 경우 connection 연장을 위하여 PINGREQ/PINGRESP 절차를 수행하여야 한다. Timeout이 되는 경우 broker는 연결을 끊고, lastWill 등의 처리를 해 줄 것이다.

참고로 여러 MQTT 서버를 연결하는 것도 bridge를 통하여 가능하다. Bridge는 MQTT client-server protocol 을 이용하여 MQTT broker 간의 메시지를 forwarding 하는 것으로 MQTT protocol 만으로 구현 가능하다. 물론 이 방법은 bridge로 forwarding 되는 메시지로 인하여 규모 확장에 문제가 될 수 있어 clustering 이 지원되는 broker를 검토해볼 필요가 있다.

기본적인 동작 시험은 설정이나 사용이 쉬운 Mosquitto MQTT broker를 이용하는 것이 좋다. Ubuntu 인 경우 아래처럼 mosquitto를 하거나, docker를 이용하여 설치해볼 수 있다.

Broker를 설치하면 같이 제공하는 mosquitto_sub, mosquitto_pub utility를 이용하여 subscribe, publish 를 시험해 볼 수 있다.

단말이 어느정도 가장 연결 가능한브로커 제한된 리소스를 가진 기기이지만, proxy 등의 도움없이 직접 public internet 접속이 가능하고, TCP, TLS 사용이 가능한 경우라면 MQTT를 검토해 볼 수 있을 것이다. TCP 연결 방식이고 모든 연결은 broker를 통하는 방식이라 NAT 상에서도 문제없이 사용가능하다.

가장 연결 가능한브로커

1.
ZeroAOS를 설계할 때 전제는 DMA(Direct Market Access)입니다. 시세나 주문체결을 처리하는 프로세스도 DMA가 기준입니다. DMA시장이 커지고 있었고 레이턴시(Latency)가 중요한 경쟁력이 조건에 의해 선택한 기술적 구조입니다. 만약 시장이 계속 성장을 하였으면 비즈니스적인 고민은 다른 방향으로 향했을 듯 합니다. 현실은 반대입니다. DMA서비스가 계륵인 곳도 많습니다. 성장기때 무료로 제공하던 서비스가 유료로 바뀐 곳도 있습니다. 숫자를 중요시하는 경영환경에 따른 변화입니다. ZeroAOS서비스도 타격을 받았습니다. 매출이 곤두박질하였습니다. 여의도에서 6년을 버티기은 현재의 고민을 정리해서 방향을 찾고자 하는 노력이었습니다.

유가증권시장으로 방향을 틀고자 하였을 때 질문을 하였습니다.

그래서 모바일 앱을 이용한 서비스로 나아갔습니다. 데이타사업자와 제휴를 하여 DIY형 로보어드바이저를 만들 구상을 하였슴니다. 발상의 전환을 한 계기는 ‘고객과의 대화’였습니다. 많은 증권사들이 미니원장을 경우하는 DMA서비스를 제공하지만 거래가능한 상품이 제한적입니다. 고객이 요청하는 상품을 거래하려면 DMA서비스를 제공해야 하는데 제공하지 않는다고 주저앉으면 새로운 고객을 확보할 수 없는 딜레마에 놓였습니다. 어떻게 할까, 고민을 하다가 이베스트투자증권이 리눅스용 API를 제공하는 소문을 떠올렸습니다.

만약 증권사가 제공하는 윈도우옹 API와 같은 기능중 ZeroAOS가 필요로 하는 기능만 리눅스로 구현하면 어떨까?

ZeroAOS는 HTS와 다른 시스템이라서 API중 많은 부분은 필요로 하지 않습니다.시세조회와 시세자동갱신, 주문체결송수신, 계좌조회와 같은 함수만 구현하면 됩니다. 오랜 동안 HTS를 개발했고 HTS미들웨어도 가지고 있기때문에 HTS통신구조를 분석하여 필요한 TR함수를 구현하는 것은 시간의 문제일 뿐입니다.

리눅스API를 개발한다고 하면 가장 먼저 떠오르는 의문이 ‘공인인증’일 듯 합니다. 2011년 BS투자증권 서비스를 개발할 때 비슷한 어려움을 겪었습니다. 여러가지 방법을 고민하다가 해결할 방법을 찾았습니다. 하나의 해결책이 아닌 여러 해결책이 가능할 듯 합니다.

2.
리눅스용 API를 직접 구현해서 ZeroAOS에 내장할 계획을 하니까 DMA기반의 ZeroAOS로는 상상할 수 없었던 서비스가 가능합니다.

먼저 멀티브로커(Broker)입니다. 코스콤이 제공하는 부산IDC를 제외하면 – 여의도에 있는 KT의 IDC도 가능할 수 있지만 – 외부의 데이타센터에서 여러곳의 증권사DMA서비스를 이용할 수 없습니다. 보안상의 이유입니다. 이 때문에 외국계 투자자를 제외하면 멀티브로커시스템은 그림의 떡입니다. 여러 증권사를 이용하더라도 각 증권사에 동일한 시스템을 설치해서 운영합니다. 그런데 증권사 API는 Open API입니다. 정해진 규칙만 따르면 어느 장소에서 누구라도 사용(Access)할 수 있습니다. ‘가’라는 투자자가 있습니다. 여러 증권사에 계좌가 있습니다. 각 증권사마다 HTS를 설치하여 모니터링할 수 있지만 비효율적입니다. Open API를 이용하고 DMA를 벗어던지면서 멀티브로커시스템이 현실화하였습니다.

둘째 멀티거래소(Exchange)입니다. DMA서비스는 미니원장과 전용FEP를 전제로 합니다. 지원하는 시장을 늘릴 때마다 별도의 IT투자를 필요로 합니다. 그랫 DMA서비스로 거래하는 상품은 제한적입니다. 그런데 API는 다릅니다. 대부분의 증권사가 유가증권부터 시작하여 국내파생상품, 해외파생상품을 거쳐서 FX까지 거래가능합니다. 멀티상품이고 멀티거래소입니다. 만약 증권사가 KRX뿐 아니라 HKeX(홍콩), TSE(일본) 및 CME등을 거래할 수 있도록 하고 이를 API로 제공하면 ZeroAOS도 역시 다 지원합니다. 로보어드바이저가 국내 주식, 국내ETF 및 해외ETF로 포트폴리오를 구성하면 주문관리시스템으로는 ZeroAOS 3.0이 딱 적합합니다.(^^)

셋째 자문형서비스입니다. 2015년 가을 어떤 자문사의 연락이 있었습니다. 비용때문이지 성사되지 않았지만 DMA서비스를 이용하여 복수의 계좌를 거래하는 방법을 문의받았습니다. 일임형자문서비스일 경우 여러 계좌를 관리하여야 합니다. 만약 고객들이 거래하는 증권사가 각각이라고 하면 복잡합니다. 어떤 자문사는 FIX프로토콜을 이용하여 주문관리시스템을 구축해서 해결한 사례가 있습니다만 IT투자를 해야 합니다. FIX가 아니라 API를 이용한 자문서비스라고 하면 비용이 줄지않을까요?

넷째 복수의 알고리즘와 복수의 계좌를 연결한 서비스입니다. 최초 BS투자증권과 제휴하여 ZeroAOS를 준비할 때 멀티계좌,멀티이용자, 멀티알고리즘 방식으로 설계하였습니다. A,B계좌는 ‘가’라는 알고리즘, C,D,E게좌는 ‘나’라는 알고리즘으로 매매할 수 있는 구조입니다. 멀티브로커와 연결하여 다양한 방식의 매매기법을 구현할 수 있습니다.

3.
오늘 쓴 검소한 혁신과 진화적 혁신중 Natural Innovation을 보면 Fidessa가 혁신을 하는 시작은 ‘고객’이었습니다. 인내를 갖고 고객의 요구를 분석하면서 혁신을 할 수 있는 업무를 발견(Discover)하였습니다.

이런 질문을 해보니 스스로 선입견에 사로잡혀 장벽을 쌓은 느낌이었습니다. 투자자를 자주 접하지 못한 저의 불찰입니다. 늦었지만 시작하였습니다. 그래서 ZeroAOS 3.0은 개발중입니다.

Roth IRA 브로커지 바꿀 수 있나요?

안녕하세요? 마모에서 은퇴관련 글들을 보며 어렵지만 조금씩 은퇴저축을 따라하고 있습니다. 올해 처음으로 Roth IRA를 개설해서 6000불 불입을 했는데요, 제 다른 은퇴계죄가 TIAA에 있어서 관리가 편할거란 생각으로 여기에 IRA를 개설하고 S&P 500 과 비슷해보이는 펀드로 설정을 해두었는데 expense 가장 연결 가능한브로커 ratio가 0.3% 더라구요 (이 상품이 가장 낮더라구요). 그런데 남편의 Fidelity계좌에 비슷한 IRA 펀드상품을 보니 0.015% 이더라구요.

궁금한 것은, 제가 다시 피델리티에 Roth IRA를 새로 열고, 내년부터는 여기에 불입을 하는 방식도 가능한건지요?

그리고 이미 불입한 TIAA의 Roth IRA를 피델리티로 옮길 수 있을까요?

무지해서 뭔가 복잡해진거 같은데 ㅠ 이제 시작이니 지금이라도 더 나은 선택으로 해보려고 합니다.

6 댓글

두번째는 찾는 쪽에서 수수료가 들어갈 수도 있다네요

자기들 손님인데 잡고 싶겠지요:)

Fidelity계좌에 비슷한 IRA 펀드상품을 보시면 0.0% 도 가장 연결 가능한브로커 있습니다

라이트닝 님 으로 검색해보세요

저도 예전거 0.03% 라서 옮겨야하는데 귀찮아서 미루는 중입니다 수수료도 칠십불 정도라네요

delight

아 zero 라이트닝님 글에서 본것 같아요. 검색해보겠습니다. 감사합니다 ^^

우리 친절한 Fidelity씨에게 Account Transfer를 요청하시면 친절히 다 옮겨주실꺼에요. Closing fee가 좀 들겠지만 장기적으로 (20년 30년 후) 볼 때 0.3% vs. 0%는 아마 어마무시한 차이를 만들것 같아요..

delight

네 장기적으로 차이가 클것 같아서요.. trasnfer를 요청하면 되는거군요. 감사합니다 ^^

금액이 어느 정도 되면 transfer fee를 받는 쪽 브로커리지에서 reimburse해주는 경우가 많은 것 같습니다.
먼저 한 번 물어보세요.