사물 인터넷(IoT) 애플리케이션에서 예측치 못한 대량의 메세지에 대한 처리는 필연적인 요구 사항입니다. 본 세션에서는 이를 해결하기 위해 서버리스 서비스인 AWS Lambda, Amazon SQS 및 Kinesis에 대한 이해와 함께 활용 시 고려사항들을 살펴 보고, IoT 측면에서 활용할 수 있는 기법을 고민해 봅니다. 비단 IoT 워크로드 뿐만 아니라 이와 유사한 패턴을 갖는 애플리케이션에서 견고한 클라우드 아키텍처의 요건이 무엇인지 확인 하실 수 있습니다.

2. AWS 서버리스를 이용하여
IoT 수준의 메세지 폭풍을 처리하는 방법
김민성 (Kim, Min Sung)
Solutions Architect | IoT Specialist
Amazon Web Services
A W S I o T

3. AWS IoT
Device간 통신 (M2M) 또는 Device와 Cloud간의 통신 (IoT) 제공
Message
Topic
Pub: 외출
Sub: 외출
잠금 설정
전원 설정
보안 모드 변경

4. AWS IoT
Device간 통신 (M2M) 또는 Device와 Cloud간의 통신 (IoT) 제공
Message
Topic
Pub: 외출
Sub: 외출
잠금 설정
전원 설정
보안 모드 변경

6. 일반적인 아키텍처
Rule Engine
AWS IoT
Device
Appliances #1
Appliances #2
Home appliance #
Thing Shadow
Mobile
Voice

7. 람다 기반의 메시지 인터페이스
Rule Engine
AWS IoT
Device
Appliances #1
Appliances #2
Home appliance #
Thing Shadow
Mobile
Voice
Rule Engine
Rule Engine은 람다를 동기적으로
호출
람다 스케일에 대한 이해
람다 동시성 (Concurrency)
- 람다 실행을 위한 확장 가능한 리소스 슬롯
- TPS을 의미 하지 않음
람다 스케일 업
- Initial Burst Limit 도달 시 1분의 Cooling time후
500씩 증가

8. 고려 사항 #1 – Rule Engine Error Action
예외 처리 방안
임시 저장소에 예외 관련 데이터를 적재한 후
부하 감소 시 재 처리
- 예외 데이터: X-Amz-Function-Error 해더
(에러 코드, Timestamp, Payload 포함)
- 재 시도 시 Back-off 및 Jitter 고려
- SQS Standard 또는 Kinesis 권고
(SQS Standard의 경우 별도의 스케일 관리가 필요
없음)
“데이터 소실 예방”

9. 고려 사항 #2 – 람다 성능 튜닝
100
“람다 성능 향상을
통한 동시 실행 가능
람다 수량 향상”
<중요: 테스트의 환경 및 설정에 따라 성능 수치는 달라질 수 있음>

10. 데모 구성도
Rule Engine

13. 고려 사항 #2 – 람다 성능 튜닝
Lambda Best Practice 적용
Global Variable 전환
• Warm-start 지연 시간 감소 효과
• Backend 서비스 (DB, FTP 등)에 가해지는 부하 절감
• 파일 핸들 수량 감소

14. 고려 사항 #2 – 람다 성능 튜닝
<참고> 새션 관리 필요
람다 Warm-Start의 경우 마지막 호출된 후 30분이 지나더라도 발생할 수 있음
데이터베이스 등의 Back-end 서비스의 idle timeout 이후에도 Warm-Start 발생
80 mins
Image source: https://spotinst.com/blog/best-practices-serverless-connection-pooling-database/

15. 고려 사항 #3 – 람다 함수 별 Concurrency 조절
단일 람다 함수가 모든 Concurrency 소모를 방지

16. 고려 사항 #4 – SQS 및 Kinesis 활용
Rule Engine
AWS IoT
Device
Legacy
Lagged Pulling
Direct Pulling
Thing Shadow
Mobile
Voice
1
2
3

17. 고려 사항 #4 – SQS 및 Kinesis 활용
SQS (Standard)
- 스케일 관리가 필요 없음
- One to one (최대 10개 메시지까지
한번에 읽어 처리 가능)
- For single application
람다를 큐로 사용 경우에도 Concurrency의 제약을 받음
Kinesis
- 샤드별 메시지 순서 보장
- Many to one (이론적으로 250개의
메시지까지 한번에 읽어 처리)
- 추가 비용과 함께 70ms까지 성능
개선 가능
- 동일 스트림에 다수의
어플리케이션활용 가능

18. 고려 사항 #4 – SQS 및 Kinesis 활용
중복
처리는?
QoS 0에서도 중복 메시지는 발생 할 수 있음
IoT 디바이스 데이터는 시계열 데이터
- 시간 값을 Constraint로 활용한 중복 처리
예: Unique, Primary
- Upsert (update/insert)
“ThingShadow”의 경우 timestamp, version,
token정보 활용
ElastiCache을 잠금 관리자로 활용

19. 고려 사항 #5 – SQS 와 람다
SQS 형태의 메시지 큐의 경우 짧은 Pooling Interval과 함께
Consumer수량을 늘리면 성능을 대폭 개선 할 수 있음
Rule Engine
Legacy SQS + Lambda
• Avg duration: 0.781 sec
• Error: 2
• Avg duration: 39.223 sec
• Error: 0
Rule Engine
SQS Standard에 대한 람다 성능 테스트
- Condition: 4000 TPS, 500 concurrency cap 람다 함수
Why?
<중요: 테스트의 환경 및 설정에 따라 성능 수치는 달라질 수 있음>

20. 고려 사항 #5 – SQS 와 람다
SQS에 대한 람다 스케일링에 대한 이해 필요
- 람다 콘솔에는 Consumer의 수량을 설정하는 부분이 없음
- Initial burst 는 5 에서 시작되며 1분의 cooling time을 거친 후 60
concurrent 씩 증가함
“Latency가 민감한 작업에는 EC2 또는 Container와 같이
공격적인 Auto-Sailing 구성이 가능한 Consumer 활용”
“단순 저장과 같이 Latency에 민감하지 않은 작업에 람다 활용.”

21. 5가지 고려 사항에 대한 적용
Rule Engine
AWS IoT
Device
Legacy
Lagged Pulling
Direct Pulling
Thing Shadow
Mobile
Voice

22. 더 빠르게 더욱 저렴한 비용으로
만약 모든 디바이스의 컨트롤을 사용자의 모바일 폰에 Delegation 시킨다면?
Rule Engine
AWS IoT
Device
Thing Shadow Mobile
Storing telemetry and command history
MQTT, HTTP, WebSocket

23. 사전 지식 – Thing 이란?
= Registry
= Device Shadow
= 일반 토픽 또는 Basic Ingest 토픽

24. 사전 지식 – Thing 이란?
Device Shadow
• 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
동적 데이터를 관리
토픽에 대한 접근 제어

25. AWS IoT Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iot:Connect",
"Resource": "arn:aws:iot:us-west-
2:549632206553:client/${iot:ClientId}"
},
{
"Effect": "Allow",
"Action": [
"iot:Publish",
"iot:Receive"
],
"Resource": "arn:aws:iot:us-west-
2:549632206553:topic/${iot:ClientId}"
},
{
"Effect": "Allow",
"Action": "iot:Subscribe",
"Resource": "arn:aws:iot:us-west-
2:549632206553:topicfilter/${iot:ClientId}"
}
]
}

26. AWS IoT Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iot:Connect",
"Resource": "arn:aws:iot:us-west-
2:549632206553:client/${iot:ClientId}"
},
{
"Effect": "Allow",
"Action": [
"iot:Publish",
"iot:Receive"
],
"Resource": "arn:aws:iot:us-west-
2:549632206553:topic/${iot:ClientId}"
},
{
"Effect": "Allow",
"Action": "iot:Subscribe",
"Resource": "arn:aws:iot:us-west-
2:549632206553:topicfilter/${iot:ClientId}"
}
]
}

27. AWS IoT Policy
Device Shadow Topic
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iot:Connect",
"Resource": "arn:aws:iot:us-west-
2:549632206553:client/${iot:ClientId}"
},
{
"Effect": "Allow",
"Action": [
"iot:Publish",
"iot:Receive"
],
"Resource": "arn:aws:iot:us-west-
2:549632206553:topic/${iot:ClientId}"
},
{
"Effect": "Allow",
"Action": "iot:Subscribe",
"Resource": "arn:aws:iot:us-west-
2:549632206553:topicfilter/${iot:ClientId}"
}
]
}
$aws/things/{thingName}/shadow/

28. AWS IoT Policy Variables
기본 Policy Variables
- iot:ClientId : AWS IoT에 연결하는 데 사용되는 클라이언트 ID
- aws:SourceIp : AWS IoT에 연결된 클라이언트의 IP 주소
x.509 인증서 Policy Variables
사물 Policy Variables
- iot:Connection.Thing.ThingName
- iot:Connection.Thing.ThingTypeName
- iot:Connection.Thing.Attributes[attributeName]
- iot:Connection.Thing.IsAttached

29. M:N 권한 관리
Mobile Device
Consumer Device (Bulb)
M:N으로 관리 할 수 있는 그룹 생성하고 GUID 할당
관리 대상 디바이스는 “Owner Group ID”로 이름 시작
모바일 디바이스 역시 해당 Owner Group을 인지하도록 Registry에 변수 등록
eRd2kc5CLAe7d21C-bulb01
eRd2kc5CLAe7d21C
bulb

30. M:N 권한 관리
${iot:Connection.Thing.Attributes[Owner_Group]}
Thing Registry Value of Attribute
“Owner_Group”
*Wildcard
사물 Policy Variable을 이용하여 ThingShdow 토픽 지정.

31. M:N 권한 관리 – 참고 Condition
Condition Example

33. Job 이란?
• Device들의 정보 수집 (Audit, Report 등)
• Device application installation
• Device firmware update
• 기타 디바이스와 약속된 작업 (Job)의 실행 요청
검색 엔진 배포 서버 배포 서버 모니터링 서버

34. 1. 대상 탐색 (Thing Group) 검색 엔진 배포 서버 배포 서버 모니터링 서버
attributes.sku: Airpurifier-ax312
AND attribute.location: Seoul
AND connectivity.connected: true
AND shadow.firmwareVersion: 1.1

35. 2. 작업 설정 검색 엔진 배포 서버 배포 서버 모니터링 서버
{JSON}
Pre signed URL
코드 사인
작업 유형

36. 2. 작업 설정 검색 엔진 배포 서버 배포 서버 모니터링 서버
“최소 1000대에 배포된 상황에서 실패가 70% 이상이면”

37. 3. 작업 배포 검색 엔진 배포 서버 배포 서버 모니터링 서버
$aws/things/thing-name/jobs/notify
$aws/things/thing-name/jobs/notify-next
$aws/things/thingName/jobs/get
$aws/things/thing-name/jobs/accepted
$aws/things/thing-name/jobs/rejected
true $aws/things/thingName/jobs/jobId/get
$aws/things/thing-name/jobs/jobId/accepted
$aws/things/thing-name/jobs/jobId/rejected

38. 4. 모니터링
$aws/things/thingName/jobs/jobId/update/
false $aws/things/thingName/jobs/jobId/get
$aws/things/thing-name/jobs/jobId/accepted
$aws/things/thing-name/jobs/jobId/rejected
병행 실행
검색 엔진 배포 서버 배포 서버 모니터링 서버

40. Take away
• AWS IoT Backend로써 람다 튜닝 방안
• 큐 활용 방안
• 디바이스에 대한 Control을 DeviceShadow (ThingShadow)로 Delegation
하는 방안
• 다수의 디바이스에 대한 작업 실행 방안

41. AWS IoT 아키텍처
IoT 데이터로부터 어떻게 가치를 확보 할것인가?
어떻게 디바이스들을 안전하게 관리 및 제어할 것인가?
엣지 디바이스를 어떻게 연결하고 운영할 것인가?

42. IoT 가치 사이클

43. IoT 가치 사이클
AWS IoT Events
AWS IoT Analytics
AWS IoT SiteWise
AWS IoT Device
Management
AWS IoT
Things Graph
AWS IoT Core
AWS IoT
Device Defender
AWS IoT
Device SDK
Amazon FreeRTOS
AWS IoT
Device Tester
AWS IoT
Greengrass

45. 여러분의 피드백을 기다립니다!
#AWSDEVDAYSEOUL