IOT308-One Message to a Million Things Done in 60 seconds with AWS IoT

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
AWS re:INVENT
One Message to a Million Things:
Done in 60 Seconds with AWS IoT
D i n k a r P a t a b a l l a , A W S I o T
V i n a y B a n s a l , A m a z o n M u s i c
N o v e m b e r 2 7 , 2 0 1 7
I O T 3 0 8

How many of you are building or have built
applications on AWS IoT?

Did you think of scale?

Scale

• Message Broker
• Securely connect devices
• Communicate over PubSub Messaging model
• MQTT, HTTPS, Websockets protocol support
• Rules Engine
• Thing Shadows

Examples
• Home automation
• Telemetry
• Device data delivery
• Broadcast notifications

Home automation
—C o n n e c t e d T V

Connected TV
Alexa, turn on the TV

Connected TV
PUBLISH
command/switchOn
command/switchOff
command/volumeUp
command/volumeDown
…
…
SUBSCRIBE
command/switchOn
command/switchOff
command/volumeUp
command/volumeDown
…
…

Wildcard subscriptions
SUBSCRIBE
command/switchOn
command/switchOff
command/volumeUp
command/volumeDown
…
…
SUBSCRIBE
command/+

Connected TV
PUBLISH
command/switchOn
command/switchOff
command/volumeUp
command/volumeDown
…
…
SUBSCRIBE
command/+

Wait! What if we had 1,000,000 TVs?
Sure, add a deviceId somewhere in your topic

Somewhere, where??
deviceId/command/+
or
command/deviceId/+
or
command/+/deviceId

AWS IoT subscriptions
Data store
Write Operation
Read Operation

P0 P1 P2
Customer Subscription key space
P9
1,000,000 subscriptions
Partitions are accessed based on prefix of the topics

P0
P1
P9
deviceId1- deviceId100k
deviceId100k- deviceId200k
deviceId900k- deviceId1M
deviceId/command/+
{deviceId = 125764}

P0
P1
P9
command/deviceId1-
command/deviceId100k-
command/deviceId900k -
command/deviceId/+
{deviceId = 125764}

P0
P1
P9
command/+/deviceId
Creates non-uniform
workload

How to choose topic structure?
scalable
NOT
scalable
scalable
deviceId/command/+
or
command/deviceId/+
or
command/+/deviceId

Takeaways
Use wildcards to consolidate subscriptions
Use deviceId to get high cardinality for your topics
When using wildcards, have wildcards to the
rightmost part of the topic structure (to the right of
high cardinality part)

Telemetry
—C o n n e c t e d W i n d F a r m

Connected Wind Farm

Connected Wind Farm
Amazon
Kinesis
AWS IoT
rule action
PUBLISH
sensor/windspeed

AWS IoT rule
{
"rule": {
"sql": "SELECT * FROM ‘sensor/windspeed'",
"ruleDisabled": false,
"actions": [{
"kinesis": {
"roleArn": "arn:aws:iam::123456789012:role/aws_iot_kinesis",
"streamName": "my_kinesis_stream",
"partitionKey": "${topic()}"
}
}],
}
}

AWS IoT rule
“A partition key in Amazon Kinesis is used to group data into shards within a
stream”
– Amazon Kinesis

Connected Wind Farm requirements
Number of sensors = 1,000,000
Time interval for publishing data per sensor = 50 sec
Rate of data published across all sensors = 1,000,000/50 per sec
20,000 publishes per second

Amazon Kinesis
“Each shard can support up to 1,000 records per second for writes”
– Amazon Kinesis
So, for 20,000 writes per second, we’d need?
20 Shards

AWS IoT rule
Shard1
Shard2
Shard12
Shard20
Amazon Kinesis
PUBLISH
sensor/windspeed

How do we distribute our writes?
High cardinality for partitionKeys!
For example: clientId(), newuuid() ...

AWS IoT rule
{
"rule": {
"sql": "SELECT * FROM ‘sensor/windspeed'",
"ruleDisabled": false,
"actions": [{
"kinesis": {
"roleArn": "arn:aws:iam::123456789012:role/aws_iot_kinesis",
"streamName": "my_kinesis_stream",
"partitionKey": "${topic()}"
}
}],
}
}
"partitionKey": "${clientId()}"

AWS IoT rule
Shard1
Shard2
Shard12
Shard20
Amazon Kinesis
PUBLISH
sensor/windspeed
partitionKey=<clientId>

Takeaways
Provision enough capacity for downstream services
Use high cardinality keys to write into those services

Device Data Delivery
—C o n n e c t e d c a r s

Connected cars
Data bundle
Common data like:
Device settings,
configuration files …

Connected cars
offline
PUBLISH
cars/CommonContent
SUBSCRIBE
cars/CommonContent

Connected cars
How will get the content delivered to it?
We need to store this content somewhere
Thing Shadows!

Thing Shadows
offline
AWS IoT
Thing Shadow

Do not use shared Shadows
SUBSCRIBE
$aws/thing/shadow/CommonContent/get/accepted
Car1 Car2 Car3 Car4 Car5

PUBLISH
$aws/thing/shadow/CommonContent/get
Car1 Car2 Car3 Car4 Car5 Car6

PUBLISH
$aws/thing/shadow/CommonContent/get/accepted
Car1 Car2 Car3 Car4 Car5 Car6

What’s the fix?
High cardinality for Thing Shadows!
Thing Shadow per device, no shared Shadows

Thing Shadows
$aws/thing/shadow/<thingName>/…

Takeaways
Avoid shared Thing Shadows

Broadcast notifications
—M o b i l e a d v e r t i s i n g

Mobile advertising
Advertising platform
Mobile users
User group2

Mobile advertising
Advertising platform
Mobile users
Geolocation = Las Vegas

Mobile advertising
SUBSCRIBE
Ads/City/LasVegas
PUBLISH
Ads/City/LasVegas

Mobile advertising requirements
Number of devices to fan-out = 1,000,000
Total time to deliver ads to all devices = < 60 sec

AWS IoT fanout
“For each inbound message onto AWS IoT, AWS IoT will deliver that message
to all subscribers at a rate of 10,000 per sec”
– AWS IoT
So, for 1,000,000 subscribers, it will take?
100 seconds
But we need it delivered in 60 seconds, so …?

Mobile advertising
SUBSCRIBE
Ads/City/LasVegas/group2
SUBSCRIBE
PUBLISH

AWS IoT fanout
Ads/City/LasVegas/group1 = 500,000 subscribers
Time to deliver to all subscribers = 50 seconds
“For each inbound message onto AWS IoT, AWS IoT will deliver that message
to all subscribers at a rate of 10,000 per sec”
– AWS IoT
Total time to deliver to all 1,000,000 subscribers = 50 seconds
Ads/City/LasVegas/group2 = 500,000 subscribers
Time to deliver to all subscribers = 50 seconds

Takeaways
Shard subscribers across topics to get desired SLAs

Amazon Music
V i n a y B a n s a l

Live soccer on Amazon Music
Amazon Music launched audio streaming of Bundesliga and other soccer
leagues for its Prime and Amazon Music Unlimited subscribers earlier this
year

Problem statement
Provide near real-time updates to all browse views for all users listening to
soccer games
GOAL! Red Card

Games page Now Playing page
1 2

Design goals
1. Latency – < 60 secs
2. Scalability – ~ 1 MM users
3. Development Support – Client SDKs availability
iOSAndroid JavaScript

Pull vs Push

Pull
All connected devices poll for new updates
periodically.
Rest
Service
mobile
Client
Pull

Disadvantages of Pull
1. Cost – REST Service needs to be able to handle up to 1 MM TPS
2. Latency – Added latency because of polling delay

Push
Updates are pushed by Push Service
to all connected devices
Push
Service
mobile Client
Push
Push
updates

Architecture

Topic schemas
We considered multiple topic schemas to meet our requirements.
• One topic per game
• One topic for multiple games
• One topic for all games
IoT
topic

Single topic per game
Publisher
Topic
Game 31
Topic
Game 32
Topic
Game 33

Single topic for pool of games
Publisher
Topic
Pool 1
Topic
Pool 2
Topic
Pool 3

One topic for all games
Publisher
Topic
All
Games

Future Topic Sharding
Pool 1
Pool 2
Pool 3
Publisher
Topic
Pool 1
Topic
Pool 2
Topic
Pool 3
Each pool consists
of several devices

Advantages of AWS IoT
Criteria AWS IoT
Latency < 60 secs
Message Size < 128 KB
Security (Auth) Amazon Cognito, IAM
QoS/Reliability 2 QoS modes (At most once, At least once)
Fully Managed/Hosted Yes
Rapid Prototype Yes
Operational Dashboards Through Amazon CloudWatch

Key takeaways

Key takeaways
command/+
deviceId/command/+ or command/deviceId/+
20k write records per second <=> 20 Shards
"partitionKey": "${clientId()}“
$aws/thing/shadow/<thingName>/…
SUBSCRIBE Ads/City/LasVegas/group1 & SUBSCRIBE
Amazon Music

Thank you!

IOT308-One Message to a Million Things Done in 60 seconds with AWS IoT

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to IOT308-One Message to a Million Things Done in 60 seconds with AWS IoT

Similar to IOT308-One Message to a Million Things Done in 60 seconds with AWS IoT (20)

More from Amazon Web Services

More from Amazon Web Services (20)

IOT308-One Message to a Million Things Done in 60 seconds with AWS IoT