Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Billing the Cloud
Search
Pierre-Yves Ritschard
May 12, 2017
Programming
0
310
Billing the Cloud
Updated billing the cloud slides for We are Developers 2017 in Vienna
Pierre-Yves Ritschard
May 12, 2017
Tweet
Share
More Decks by Pierre-Yves Ritschard
See All by Pierre-Yves Ritschard
Meetup Camptocamp: Exoscale SKS
pyr
0
450
The (long) road to Kubernetes
pyr
0
310
From vertical to horizontal: The challenges of scalability in the cloud
pyr
0
71
Change Management at Scale
pyr
0
110
5 years of Clojure
pyr
2
1k
Taming Jenkins
pyr
0
51
Init: then and now
pyr
1
200
From Vertical to Horizontal
pyr
2
140
Billing the Cloud
pyr
7
2.2k
Other Decks in Programming
See All in Programming
チームのテスト力を鍛える
goyoki
3
510
MCPでVibe Working。そして、結局はContext Eng(略)/ Working with Vibe on MCP And Context Eng
rkaga
5
2.3k
時間軸から考えるTerraformを使う理由と留意点
fufuhu
16
4.8k
スケールする組織の実現に向けた インナーソース育成術 - ISGT2025
teamlab
PRO
1
120
Design Foundational Data Engineering Observability
sucitw
3
200
OSS開発者という働き方
andpad
5
1.7k
MCPとデザインシステムに立脚したデザインと実装の融合
yukukotani
4
1.4k
もうちょっといいRubyプロファイラを作りたい (2025)
osyoyu
1
450
はじめてのMaterial3 Expressive
ym223
2
860
Android端末で実現するオンデバイスLLM 2025
masayukisuda
1
160
テストコードはもう書かない:JetBrains AI Assistantに委ねる非同期処理のテスト自動設計・生成
makun
0
400
CloudflareのChat Agent Starter Kitで簡単!AIチャットボット構築
syumai
2
500
Featured
See All Featured
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
The Straight Up "How To Draw Better" Workshop
denniskardys
236
140k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Optimizing for Happiness
mojombo
379
70k
Agile that works and the tools we love
rasmusluckow
330
21k
Faster Mobile Websites
deanohume
309
31k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
The Cult of Friendly URLs
andyhume
79
6.6k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
850
How to train your dragon (web standard)
notwaldorf
96
6.2k
Transcript
@pyr Billing the cloud Real world stream processing
@pyr Three-line bio • CTO & co-founder at Exoscale •
Open Source Developer • Monitoring & Distributed Systems Enthusiast
@pyr Billing the cloud Real world stream processing
@pyr • Billing resources • Scaling methodologies • Our approach
@pyr
@pyr provider "exoscale" { api_key = "${var.exoscale_api_key}" secret_key = "${var.exoscale_secret_key}"
} resource "exoscale_instance" "web" { template = "ubuntu 17.04" disk_size = "50g" template = "ubuntu 17.04" profile = "medium" ssh_key = "production" }
None
None
@pyr Infrastructure isn’t free! (sorry)
@pyr Business Model • Provide cloud infrastructure • (???) •
Profit!
None
None
@pyr 10000 mile high view
None
Quantities
Quantities • 10 megabytes have been set from 159.100.251.251 over
the last minute
Resources
Resources • Account WAD started instance foo with profile large
today at 12:00 • Account WAD stopped instance foo today at 12:15
A bit closer to reality {:type :usage :entity :vm :action
:create :time #inst "2016-12-12T15:48:32.000-00:00" :template "ubuntu-16.04" :source :cloudstack :account "geneva-jug" :uuid "7a070a3d-66ff-4658-ab08-fe3cecd7c70f" :version 1 :offering "medium"}
A bit closer to reality message IPMeasure { /* Versioning
*/ required uint32 header = 1; required uint32 saddr = 2; required uint64 bytes = 3; /* Validity */ required uint64 start = 4; required uint64 end = 5; }
@pyr Theory
@pyr Quantities are simple
None
@pyr Resources are harder
None
@pyr This is per account
None
@pyr Solving for all events
resources = {} metering = [] def usage_metering(): for event
in fetch_all_events(): uuid = event.uuid() time = event.time() if event.action() == 'start': resources[uuid] = time else: timespan = duration(resources[uuid], time) usage = Usage(uuid, timespan) metering.append(usage) return metering
@pyr In Practice
@pyr • This is a never-ending process • Minute-precision billing
• Applied every hour
@pyr • Avoid overbilling at all cost • Avoid underbilling
(we need to eat!)
@pyr • Keep a small operational footprint
@pyr A naive approach
30 * * * * usage-metering >/dev/null 2>&1
None
@pyr Advantages
@pyr • Low operational overhead • Simple functional boundaries •
Easy to test
@pyr Drawbacks
@pyr • High pressure on SQL server • Hard to
avoid overlapping jobs • Overlaps result in longer metering intervals
You are in a room full of overlapping cron jobs.
You can hear the screams of a dying MySQL server. An Oracle vendor is here. To the West, a door is marked “Map/Reduce” To the East, a door is marked “Stream Processing”
> Talk to Oracle
You’ve been eaten by a grue.
> Go West
@pyr
@pyr • Conceptually simple • Spreads easily • Data locality
aware processing
@pyr • ETL • High latency • High operational overhead
> Go East
@pyr
@pyr • Continuous computation on an unbounded stream • Each
record processed as it arrives • Very low latency
@pyr • Conceptually harder • Where do we store intermediate
results? • How does data flow between computation steps?
@pyr Deciding factors
@pyr Our shopping list • Operational simplicity • Integration through
our whole stack • Room to grow
@pyr Operational simplicity • Experience matters • Spark and Storm
are intimidating • Hbase & Hive discarded
@pyr Integration • HDFS & Kafka require simple integration •
Spark goes hand in hand with Cassandra
@pyr Room to grow • A ton of logs •
A ton of metrics
@pyr Small confession • Previously knew Kafka
@pyr
None
@pyr • Publish & Subscribe • Processing • Store
@pyr Publish & Subscribe • Records are produced on topics
• Topics have a predefined number of partitions • Records have a key which determines their partition
@pyr • Consumers get assigned a set of partitions •
Consumers store their last consumed offset • Brokers own partitions, handle replication
None
@pyr • Stable consumer topology • Memory disaggregation • Can
rely on in-memory storage • Age expiry and log compaction
@pyr
@pyr Billing at Exoscale
None
None
None
@pyr Problem solved?
@pyr • Process crashes • Undelivered message? • Avoiding overbilling
@pyr Reconciliation • Snapshot of full inventory • Converges stored
resource state if necessary • Handles failed deliveries as well
@pyr Avoiding overbilling • Reconciler acts as logical clock •
When supplying usage, attach a unique transaction ID • Reject multiple transaction attempts on a single ID
@pyr Avoiding overbilling • Reconciler acts as logical clock •
When supplying usage, attach a unique transaction ID • Reject multiple transaction attempts on a single ID
@pyr Parting words
@pyr Looking back • Things stay simple (roughly 600 LoC)
• Room to grow • Stable and resilient • DNS, Logs, Metrics, Event Sourcing
@pyr What about batch? • Streaming doesn’t work for everything
• Sometimes throughput matters more than latency • Building models in batch, applying with stream processing
@pyr Thanks! Questions?