실전 프로젝트로 이야기하는 AWS IoT::김민성::AWS Summit Seoul 2018

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
IOT
실전 프로젝트로 이야기하는
AWS IoT
이창화
수석 / IOT 개발팀 / Coway
김민성
Solutions Architect / Amazon Web Services

실전 프로젝트로 깨달은 경험들
• MQTT, 디바이스 쉐도우
• 코웨이의 경험
• IoT 정책 및 룰엔진

일반적인 IoT 시스템 구성
Database
급격히 증가하는 관리 부담
Thing
(Entity)
History
Control
Monitor
성능 병목
or Message Queue
MQTT adapter

AWS IoT Core
IoT 서비스 구현에 필요한 요소들
• 메시지 브로커
• 룰 엔진
• 디바이스 쉐도우
• 디바이스 등록
관리형 서비스
• 설치 불필요
• 자동 확장
• 사전 프로비저닝 불필요
• 가용역영에 걸친 이중화
• 사용량에 기반한 과금

디바이스와 AWS IoT와의 통신
지원하는 프로토콜 : MQTT, HTTP, MQTT over WebSocket
SUB: robotics/status/r27
{ “status”: “green” }
PUB: robotics/status/r27
“Alert Status Green”
MQTT
- MQTT는 경량의 Publish/Subscribe(Pub/Sub) 메시징 프로토콜
- M2M(machine-to-machine)와 IoT(Internet of things)
IoT를 위해서 낮은 전력, 낮은 대역폭 환경에서도 사용
Client ID : r27 Client ID : Monitor-Robotics
토픽 : “robotics/status/r27”

토픽 (Topic)
토픽이란?
Publishing Clients와 Subscribing
Client간의 메세지를 주고 받는 메세지
통로
• 토픽의 명명 단위는 어플리케이션를
반영
• (/)를 이용해 토픽 계층 구조 표현
• (#)또는 (+)를 토픽 필터로 활용
• 예약된 토픽은 ($)로 시작
AWS IoT
PUBLISH sensors/123
PUBLISH sensors/456
PUBLISH sensors/789

토픽 (Topic) 필터
PUB: robotics/building1234/rt5678
PUB: robotics/building1234/rt1234
SUB: robotics/building1234/#{“status”: “green” }
{ “status”: “red” }
{ “status”: “green” }
{ “status”: “red” }
토픽 필터 설명
#
• 현재 트리 및 모든 하위 트리를 일치시키는 와일드카드로 활용
• 구독 중인 토픽의 마지막 문자여야함
• Sensor/#을 구독할 경우 Sensor/의 모든 메세지 구독 (예: Sensor/temp, Sensor/temp/room1)
+ • 토픽 계층 표현시 간소화를 위하여 활용
• Sensor/+/room1을 구독할 경우 Sensor/temp/room1, Sensor/moisture/room1 등에 게시된 메시지를 수신

토픽 (Topic) 디자인
• 상위 Namespace 및 그룹 정보의 반영
• 어플리케이션 정보, 그룹 정보와 같은 맥략 정보
• 커뮤니케이션에 대한 주요 정보 반영
• thingName, clinedId, uuid 정보
• 데이터 토픽과 커멘드 토픽의 분리
Structure: dt/<namespace>/<group-id>/<thing-name>/<data-type>
Structure: cmd/<namespace>/<group-id>/<thing-name>/req-type
데이터 토픽
커멘드 토픽

커멘드 토픽의 구현
컨트롤 로직
PUBLISH
cmd/namespace/groupid/robot-123
{ "Pmode": "on" }
직접 Publishing
인터넷
• 메세지의 순서의 변화
• Thing의 커넥션 상태 또는 On/Off 여부
“기존 MQTT 만으로는
충분하지 않습니다.”
Shadow
State
Apps
offline
디바이스 쉐도우

디바이스 쉐도우와 Document
{
"state" : {
"desired" : {
"lights": { "color": "RED" },
"engine" : "ON"
},
"reported" : {
"lights" : { "color": "GREEN" },
"engine" : "ON"
},
"delta" : {
"lights" : { "color": "RED" }
}
},
"version" : 10
}
• Desired: 사용자가 원하는 상태
• Reported: Thing 보고한 현재 상태
• Delta: Desired와 Reported가 서로 다른 상태
“Document”

클라이언트에서는? (JS 예시)
공기 청정기 (Air Purifier)
- airPurifierIsOn : true / false
변경이 있을때마다 상태 업데이트를 해야함
Delta: Desired 와 Reported 가 상의함
공기 청정기의 현재 상태를
Desired의 값으로 변경

디바이스 쉐도우의 주요 토픽
UPDATE: $aws/things/{thingName}/shadow/update
GET: $aws/things/{thingName}/shadow/get
DELETE: $aws/things/{thingName}/shadow/delete
DELTA: $aws/things/{thingName}/shadow/update/delta
DOCUMENTS: $aws/things/{thingName}/shadow/update/documents

디바이스 쉐도우 토픽 활용
디바이스 쉐도우의 Update 토픽
$aws/things/AirpurifierBig001/shadow/update
원하는 컨트롤을 등록한 후 Publish
“desired” : {
“airPurifierIsOn”: false
}

디바이스 쉐도우와 버전
공기 청정기
컨트롤 로직
on (version=1)
off (version=2)off (version=2)
on (version=1)
이전 버전의 업데이트 요청은
409 에러와 함께 거부됨
이전 버전의 업데이트 요청을
무시 할 수 있음

디바이스 쉐도우와 버전
Coway에서는 기존 제품의 프로토콜
지원을 위하여 “호환 계층” 을
가지고 있습니다.
호환 계층
1. Delta 발생 (Desired 와 Reported의 차이)
2. Thing에 상태 정보 변경 요청
3. Thing의 상태 정보 변경 완료
4. Desired와 Reported 일치
호환 계층에서 디바이스 쉐도우 업데이트
• Document 삭제
• NULL 처리
• Desired state
• 특정 attribute

Coway “wellness appliaance”
Water Care, Air Care, Body Care, Sleep Case, Living Care
삶의 질을 향상 시키는 기업
2017년 기준 2조 3천억
아시아 최대 Wellness appliance

Coway IOCare

Coway Airmega

호환 계층으로 인한 경험
• MQTT 프로토콜의 In-Flight 메세지
제한(Thing Shadow) 수량이 커넥션을
기준으로 하고 있었음
(10 In-Flight 메시지/Second/커넥션)
• 단일 호환 계층 서버 (EC)는 약
10000대의 디바이스를 수용
• 위의 제약 요건으로 인해 활용 가능한
초당 In-Flight 메시지는 약 10~20개로
제한 (실제로는 30,000개 정도가 필요)
호환 계층
(G/W)
실
디바이스
Thing
Shadow
호환 계층의 리소스 절약 및 안정적인
연결 유지를 위하여 Backend (IoT)와는
1~2개의 커넥션을 맺고
상시 연결상태 유지
※ EC G/W (External Connector Gateway)

어떻게 해결 했는가?
1~2
커넥션
Republish
$shadow
update topic
호환 계층
(G/W)
AWS IoT
IoT rule
IoT
topic
IoT
shadow

대량 제어 요청
Bulk 컨트롤 시그널 (예: 환기 요청)
10ms내에 30,000개의 요청
Bulk 컨트롤 시그널 (예: 환기 알림)
큐를 활용한 지연된 처리
Consumer
Consumer Consumer
Consumer
Worker
Worker
Worker
Worker
Consumer
Worker
Http방식 topic publish
2ⁿ 병렬처리CloudWatch Event
Call Consumer
Per 30 sec
호환 계층
(G/W)
호환 계층
(G/W)
queue
Queue

성능 병목이 없음…
Lambda 함수 동시 호출
서버에서의 디비 연결의 경우
WAS에서의
”Connection Pooling”을
통해 Connection 수량 조정
Lambda의 Stateless 특성으로 인해
Connection Pooling 불가
“RDBMS” 최대 연결 갯수 초과

성능 병목이 없음…
Lambda 함수 동시 호출
서버에서의 디비 연결의 경우
WAS에서의
”Connection Pooling”을
통해 Connection 수량 조정
• NoSQL DB (DynamoDB)의 활용
• Lambda 함수 최적화
• 큐 (Kinesis, SQS)의 활용

NoSQL DB (DynamoDB)의 경험
파티션
1 .. N
테이블
• 파티션의 고른 분배를 위해 높은 성능 보장을
위하여 Cardinality 가 높은 Partition Key 활용
• 어플리케이션의 조회성 데이터 요구 사항 수용을
위해 Global Secondary Index (GSI) 활용
“GSI의 Cardinality가
낮다면?”
“Attribute 및 Code성
데이터 조합”

Lambda 함수에 대한 경험
• 람다 함수 Cold Start 성능 80% 개선
• 커넥션 재사용을 위해 외부 인터페이스
(예: DB등)는 Handler Faction 외부에 선언

큐 (Kinesis, SQS)의 활용
큐 선택의 원칙
SQS Kinesis
N:1 형태의 메세지 처리1:1 형태의 메세지 처리
• 파티션 키 기반 메세지 순차 적제
(디바이스별 발생 메세지 순차 발송 가능)
• 단일 샤드에 대한 다수의 컨슈머 활용
(외부 데이터 연계에도 활용)
• KCL를 통한 손쉬운 개발
(Check Point, 병렬화, 고 가용성 지원)
Kinesis

큐 (Kinesis)와 Serverless
Kinesis
Kinesis
• 예외 처리 및 디버깅용 데이터의 수집
- Kinesis 의 특성
• 배치 사이즈
• Latency 및 Polling Interval
• Payload 사이즈

AWS IoT 정책(policy)
Effect
• Allow 또는 Deny
Action
• "iot:Publish" - MQTT publish
• "iot:Subscribe" - MQTT subscribe
• "iot:UpdateThingShadow" – 섀도(shadow) 수정
• "iot:GetThingShadow" - 섀도(shadow) 조회
• "iot:DeleteThingShadow - 섀도(shadow) 삭제
Resource
• Client, Topic ARN 또는 topic filter ARN

사물의 인증과 식별
• 디바이스의 식별: clientId
• 디바이스의 인증: SigV4 또는 인증서
+
인증서 정책
인증 및 통신 암호화 (TLS 기반)
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [ "iot:*"],
"Resource": ["*"]
}]
}

AWS IoT 정책(policy)
arn:aws:service:region:account:resourceARN (Amazon Resource Name):
ClientId가 clientid1인 디바이스의 ARN : "arn:aws:iot:us-east-1:123456789012:client/clientid1"
정책 변수의 활용 ${iot:ClientId}

AWS IoT 룰 엔진
SELECT DATA FROM TOPIC WHERE FILTER
• 친숙함! : 데이타베이스 테이블 조회와 유사 (SUB SELECT 가능)
• MQTT 토픽을 데이타 소스로 적용
• 시그널 처리를 위한 기능들 : 노이즈 제거
- String 변환 (정규식 지원)
- 수학 연산
- 케이스 문
- 인코딩, 해쉬, 암호화
- UUID, Timestamp, rand, 등
• 조회 후 연속적인 action 수행
SELECT *
FROM ‘things/thing-2/color’
WHERE color = ‘red’

룰 생성
Clientid(), Topic()
주요 함수
get_thing_shadow(thingName, roleARN)
aws_lambda(functionArn, inputJson)
SELECT * FROM 'a/b'
WHERE
get_thing_shadow("MyThing","arn:aws:iam::123456789012:role/AllowsThingShadowAc
cess") .state.reported.alarm = 'ON'
SELECT
aws_lambda("arn:aws:lambda:us-east-1:account_id:function:lambda_function",
payload.inner.element).some.value as output
FROM 'a/b'

Native MQTT와의 차이
• Persistence Session
• Retain Flag
• MQTT QoS 2
라이프사이클 이벤트 토픽
• 연결 및 연결 해제
• 구독 및 구독 취소 이벤트
SDK를 기반한 빠른 개발
IoT Policy

프로덕션 전환을 앞두고
• Client ID 별 초당 연결 요청 : 1
• 연결 당 Publish : 100/sec
• 연결 당 Subscription : 50/sec
• 연결 당 최대 처리량 : 512KiB/sec
• …
• 계정 당 허용되는 연결 요청 : 500/sec
• 계정 당 총 연결 가능한 클라이언 수량 : 500,000
• 계정 당 Inbound Publish : 10,000/sec
• 계정 당 Outbound Publish : 20,000/sec
• 계정 당 Subscription : 500/sec
디바이스 및 연결 기준 제한 계정 (Account) 제한
“용량 증설 요청”

경험…

AWS Summit 모바일 앱과 QR코드를 통
해 강연 평가 및 설문 조사에 참여해 주
시기 바랍니다.
내년 Summit을 만들 여러분의 소중한 의
견 부탁 드립니다.
#AWSSummit 해시태그로 소셜 미디어에 여러분의 행사 소
감을 올려주세요.
발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜 채널로
공유될 예정입니다.
여러분의 피드백을 기다립니다!

실전 프로젝트로 이야기하는 AWS IoT::김민성::AWS Summit Seoul 2018

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 실전 프로젝트로 이야기하는 AWS IoT::김민성::AWS Summit Seoul 2018

Similar to 실전 프로젝트로 이야기하는 AWS IoT::김민성::AWS Summit Seoul 2018 (20)

More from Amazon Web Services Korea

More from Amazon Web Services Korea (20)

실전 프로젝트로 이야기하는 AWS IoT::김민성::AWS Summit Seoul 2018