Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
みんなのオブザーバビリティプラットフォームを作ってるんだがパフォーマンスがや...
Search
さっちゃん
July 20, 2024
Programming
1.8k
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
みんなのオブザーバビリティプラットフォームを作ってるんだがパフォーマンスがやばい #mackerelio #srenext
さっちゃん
July 20, 2024
More Decks by さっちゃん
See All by さっちゃん
敎へない敎師と、考へる機械
ne_sachirou
0
34
火星曆
ne_sachirou
0
62
作ってよかったgraceful shutdownライブラリ #kyotogo
ne_sachirou
0
1.5k
path 依存型って何?
ne_sachirou
0
890
野生の onbording と onbording 設計 #kyototechtalk
ne_sachirou
0
780
メトリックはいかにして見え續ける樣になったか #devio2022
ne_sachirou
0
160
名實一致
ne_sachirou
0
800
まかれるあなとみあ ―Mackerel のしくみを理解する 30 分― @ Hatena Engineer Seminar #16
ne_sachirou
0
3.4k
tacit programming : Point-free, Concatenatives & J
ne_sachirou
0
1.2k
Other Decks in Programming
See All in Programming
Railsのためのパスキー実践入門 〜マルチテナントSaaSでの意思決定〜
utakaha
3
1.3k
見えないものを探る要求要件定義に必要な基本的思考 / invisible-requirement-thinking
minodriven
15
8.9k
コードで差別化できない時代の ソフトウェアエンジニアリング / Software Engineering in an Era Where Code Doesn’t Differentiate
kishida
2
200
[2026-10-14](C)Re:ゼロから始める異世界生活〜始まりの終わりと終わりの始まり〜
tosite
0
160
Atomic Design, Enforced: Scaling Mobile Design Systems (next.app devCon / droidCon Berlin 2026)
steliosf
PRO
0
190
学びを記事・スライド・Xへ高速展開する― AI-assisted Learning Loopで回すコンテンツ生成術
ochtum
0
150
[JA] Domain Modeling with Vanilla Rails: 「操作」から再考するRailsの設計論
yasaichi
4
1.1k
Web Framework Benchmark Battle 2026, Any%
a_matsuda
3
3k
PumaからFalconに移行したRailsアプリケーションでの実践
falcon8823
0
260
S3 TablesのIcebergデータに、AIエージェントからアクセスしてみた / 20261016developersio2026joetsu-accessing-iceberg-in-s3tables-via-agent
kasacchiful
PRO
0
220
AI時代のIaC入門 〜なぜインフラをコードで管理したいのか?〜 / Introduction to IaC in the AI Era
akihisaikeda
5
1.1k
[2026-10-09]一枚の布で作らなくてもいい。 信頼性は「パッチワーク」で紡がれる~既存の運用と新しい可能性をつなぎ合わせてきたCREの話~
tosite
0
110
Featured
See All Featured
How to make the Groovebox
asonas
2
2.5k
We Have a Design System, Now What?
morganepeng
55
8.4k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Music & Morning Musume
bryan
48
7.5k
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
530
sira's awesome portfolio website redesign presentation
elsirapls
0
470
Rails Girls Zürich Keynote
gr2m
96
14k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
290
How to build a perfect <img>
jonoalderson
1
6.2k
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
300
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.6k
Transcript
みんなのオブザーバビリティ プラットフォームを作ってるんだが パフォーマンスがやばい .。oO(さっちゃんですよヾ(〃l _ l)ノ゙☆)
None
.。oO(さっちゃんですよヾ(〃l _ l)ノ゙☆) はてなでMackerelを作っています オブザーバビリティプラットフォームを作ってゐる人閒です
※開發中の機能についての話です
Mackerelは今、オブザーバビリティプラットフォームへ向けて進化してゐます
None
None
OTelメトリックを受けるアーキテクチャ code nameは“michizane” ラベルを保存する 時系列DB メトリックを保存する
OTelメトリックを受けるアーキテクチャ Mackerel の PromQL 處理の內部 (2023/12 時點) #mackerelio - c4se記:さっちゃん
ですよ☆ https://c4se.hatenablog.com/entry/2023/12/08/011251 今日はここの話 時系列DB
最初に作ったstorage Prometheusのv1似 テナントID メトリックID テナントID メトリックID ラベルのkey ラベルの値 時系列DB テナントID
メトリックID 時系列data michizane
最初に作ったstorage Prometheusのv1似 テナントID メトリックID テナントID メトリックID ラベルのkey ラベルの値 時系列DB テナントID
メトリックID 時系列data michizane 書き込みも 讀み出しも 激重
最初に作ったstorage テナントID メトリックID ラベルのkey ラベルの値 ラベル(key=value)每に1行作られる
最初に作ったstorage テナントID メトリックID ラベルのkey ラベルの値 時系列に對應する。container×メトリック每に異なる ラベル(key=value)每に1行作られる
最初に作ったstorage テナントID メトリックID ラベルのkey ラベルの値 時系列に對應する。container×メトリック每に異なる ラベル(key=value)每に1行作られる 10 container ×100メトリック
×40ラベル ×deploy 10囘/日 ×365日 =
最初に作ったstorage テナントID メトリックID ラベルのkey ラベルの値 時系列に對應する。container×メトリック每に異なる ラベル(key=value)每に1行作られる 10 container ×100メトリック
×40ラベル ×deploy 10囘/日 ×365日 =1億4,600万行 ×microservice數 ×テナント數
今作ってゐるstorage 要求 • 投稿から1分以內にPromQLでクエリーできるやうにしたい • PromQLに充分高速にresponseしたい ◦ もし遲いなら、特に最近のメトリックに關しては高速に responseしたい •
メトリック一覽の檢索は高速にresponseしたい ◦ メトリック檢索のUIや、PromQL editorの補完に用ゐる • storage料金は安く抑へたい • 勿論、ラベルが增え過ぎて檢索できなくなる問題は解決したい
今作ってゐるstorage partitioningして 保存する ラベル 一覽用 時系列DB メトリックは變 はらず
今作ってゐるstorage Prometheusのv2似 テナント1で今日 投稿されたラベル テナント1で昨日 投稿されたラベル テナント2で今日 投稿されたラベル テナント2で昨日 投稿されたラベル
・・・ ・・・ ・ ・ ・ ・ ・ ・ 10 container 10 microservice ×100メトリック ×40ラベル ×deploy 10囘/日 ×1日 =4百万行 ※この例だと1万メトリックを投稿してゐるので結構 な金額になります。御利用は計畫的に。あと、いい 感じに上限を設定すると思ひます
がんばるぞヾ(〃l _ l)ノ゙ https://ja.mackerel.io