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
IoT向けストレージにTiKVを採用したときの話 / 2024-10-25 TiUG Meet...
Search
kamijin_fanta
October 25, 2024
Programming
0
47
IoT向けストレージにTiKVを採用したときの話 / 2024-10-25 TiUG Meetup 3 Using TiKV as IoT storage
https://tiug.connpass.com/event/327074/
kamijin_fanta
October 25, 2024
Tweet
Share
More Decks by kamijin_fanta
See All by kamijin_fanta
TrinoとIcebergで ログ基盤の構築 / 2023-10-05 Trino Presto Meetup
kamijin_fanta
1
1.3k
Unicodeと符号化形式
kamijin_fanta
0
920
Reactとフォームとスキーマバリデーション / React forms with Schema Validation
kamijin_fanta
0
2.6k
2020/05/25 さくらのクラウド向けツールを使いこなす
kamijin_fanta
3
280
2019-01-24 業務でのOSSとの関わり方
kamijin_fanta
7
4.7k
関数型言語で始めるネットワークプログラミング
kamijin_fanta
0
960
2018-11-10 Akka-HTTPで作るAPIサーバ
kamijin_fanta
2
3.5k
2018-06-30 Dockerで手に入れるデプロイ環境
kamijin_fanta
1
420
2017-09-09 Scala Kansai Summit - Akka Streams
kamijin_fanta
3
1.5k
Other Decks in Programming
See All in Programming
Monixと常駐プログラムの勘どころ / Scalaわいわい勉強会 #4
stoneream
0
280
rails statsで大解剖 🔍 “B/43流” のRailsの育て方を歴史とともに振り返ります
shoheimitani
2
940
create_tableをしただけなのに〜囚われのuuid編〜
daisukeshinoku
0
260
Haze - Real time background blurring
chrisbanes
1
510
各クラウドサービスにおける.NETの対応と見解
ymd65536
0
110
今年のアップデートで振り返るCDKセキュリティのシフトレフト/2024-cdk-security-shift-left
tomoki10
0
210
Fibonacci Function Gallery - Part 1
philipschwarz
PRO
0
220
Beyond ORM
77web
7
910
PHPとAPI Platformで作る本格的なWeb APIアプリケーション(入門編) / phpcon 2024 Intro to API Platform
ttskch
0
260
Асинхронность неизбежна: как мы проектировали сервис уведомлений
lamodatech
0
820
useSyncExternalStoreを使いまくる
ssssota
6
1.1k
どうして手を動かすよりもチーム内のコードレビューを優先するべきなのか
okashoi
3
120
Featured
See All Featured
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
0
98
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
2
290
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.2k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
66k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
The Invisible Side of Design
smashingmag
298
50k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
127
18k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Transcript
IoT向けストレージに TiKVを採用したときの話 2024-10-25 TiUG Meetup #3 Tadahisa Kamijo
上條 忠久 • さくらインターネット 2016年 新卒入社 • ずっと大阪勤務 • クラウド事業本部
所属 • 今は監視基盤を開発中 ◦ Go, Kotlin, React, TypeScript, TiDB, Trino, Iceberg… ※今日の話は多分当時はこうだったという適当な話です
入社直後 • sakura.ioというIoTサービスの開発を行うことに ◦ 通信モジュール・LTE回線・バックエンドサービスを提供
無限にスケールする IoTストレージを作って えっ? ワイ えらい人
第一世代 • 当時DBはMySQL, Postgresql, Elasticsearchくらいしか知らなかった • Elasticsearch良さそう ◦ クラスタリング対応 スケーラビリティ・耐障害性高そう!
◦ レプリカ・シャードを割と自由に設定できるらしい! ◦ 自由にJSONでクエリ書ける! • 社内でも何台か動いているらしい • とりあえず作ってみよう ◦ Elasticsearchにデータを入れるところは JavaSDK + Scala + Akka http ◦ ユーザがアクセスする REST APIをPython + flask • 2016年6月から開発・同年12月にリリース
第一世代 つらかった • 実際にあった問題 ◦ メモリ使用量が異様に多い・開くファイルの数が多すぎて止まる ◦ データを投入する時にたまに止まる ◦ クラスタリングしているのに、サーバ
1台止まるだけで止まる ◦ クラスタにサーバを1台足すと止まる 調べると全部Elasticsearchが悪いんじゃなくて使い方が悪かった
なんで辛かったか • ElasticsearchにはIndexという保存領域が存在 • 毎日デバイス毎にIndexを作っていた ◦ 1000デバイスが3ヶ月間保存すると9万Index • どうやIndexあたり数MBのメモリが必要らしい ◦
9万Indexに必要なメモリ総量は 900GB…? ◦ 当時1台に割り当て可能なメモリは 32GBが最大 ◦ サーバ1台で30デバイスくらいしか収容できない … 1日1通のデバイスも居るんですが … • Index毎にPrimary/Secondaryの選出等が行われる ◦ ノードが追加・削除されたタイミングで全て選出し直される • ノード間のデータの容量に偏りが少なくなるようにリバランスが入る ◦ Indexあたり数十秒掛かる 並列でも数時間~数日単位で性能劣化 …
直した 毎日デバイス毎にIndexを作っていた ↓ 毎日全デバイスのメッセージを受け入れるIndexを作成
教訓 • パフォーマンステストやったほうが良い • ちゃんと仕組みを理解したほうが良い
どうしよう… • ElasticsearchのIndex毎にWriteのスケール限界がある • ”無限にスケール”からは遠ざかってしまった… • 運用性も改善はされたが課題は残る ◦ ノード追加・削除時にサービス断時間が減ったが …
第二世代の開発を開始 • 主な要件 ◦ デバイスから送信される JSONを保存・ユーザがHTTP APIでクエリできる事 ◦ 1日に1メッセージのデバイス・ 1秒に1メッセージのデバイス
数万倍の差を吸収できる事 • 色々なDBを調査 ◦ Cassandra, HBase, Hypertable, Kudu, MapR, Druid, InfluxDB, TimescaleDB ◦ 要件に合う・DB自体の運用が楽・アプリケーション側の実装が楽 なDBは意外と少ない • 色々試した結果TiKVが一番向いていそうだ
TiKV • TiDBの永続層として開発 • Google BigTable(恐らくHBaseも)を参考に作られている • 当時(2018年)日本で使っている人ぜんぜん居ない • 何か問題が有ったらRust(TiKV開発言語)を書くという決意で導入
https://docs.pingcap.com/ja/tidb/stable/tidb-architecture
第二世代 • ストレージはTiKV • 開発言語はGo ◦ TiKVのクライアントはGo向けが一番ちゃんとしていた • TiKVは便利なクエリ/Indexがない ◦
基本的に↓だけでアプリケーションを作る ◦ Get(key []byte) => []byte ◦ Put(key []byte, value []byte) ◦ Delete(key []byte) ◦ Scan(keyStart []byte, keyEnd []byte) => [][]byte • シンプルなので運用が比較的楽・コントロールしやすい
TiKVの扱い方 • TiKVはデカい「Sorted Map」 ◦ Keyの順番でソートされた Map(辞書) • 容量等に応じて透過的に分割・クラスタ内で分担 ◦
この要件にマッチする →1日に1メッセージのデバイス・ 1秒に1メッセージのデバイス ◦ 分割によって書き込みスループットがスケール https://blog.kamijin-fanta.info/2022/09/tikv-get-started/
TiKVでのキー設計 IoTストレージでの利用例 • Key: iotmsg_{deviceId}_{time}_{insertId} • Value: JSON Payload Scanの仕方
• 開始キー・終了キーを指定する 例: デバイス”aaa”の12:00:00~12:20:00 • 開始: iotmsg_aaa_2024-10-25_12-00-00_ • 終了: iotmsg_aaa_2024-10-25_12-20-00_ Key Value iotmsg_aaa_2024-10-25_12-10-00_AAAA {“paylaod”: … iotmsg_aaa_2024-10-25_12-20-00_BBBB {“paylaod”: … iotmsg_aaa_2024-10-25_12-30-00_CCCC {“paylaod”: … iotmsg_bbb_2024-10-25_12-05-00_DDDD {“paylaod”: … iotmsg_bbb_2024-10-25_12-15-00_EEEE {“paylaod”: … iotmsg_ccc_2024-10-25_12-08-00_FFFF {“paylaod”: … iotmsg_ddd_2024-10-25_12-09-00_GGGG {“paylaod”: …
第二世代リリース • 2020年5月にTiKVバックエンドとした第二世代ストレージをリリース • 運用性も非常に良かった ◦ ノードの追加・削除で停止することも無くなった ◦ スケーリングはTiKVが勝手にやってくれるので、サイジングの負荷軽減 ◦
消費リソース量は数十~数百分の 1 ◦ ユーザへのレスポンス時間は数十分の 1 • TiKVにPR送ったりもした https://github.com/tikv/tikv/pull/3724
さくらインターネットのIoTサービス 頑張って作ったが… • 2016年4月1日 sakura.io パブリックα提供開始 • 2017年4月18日 sakura.io 正式サービス提供開始
• 2022年3月24日 後継サービス モノプラットフォーム提供開始 • 2024年5月30日 モノプラットフォーム 新規申し込み停止 SIM 1枚月額13円から利用可能なセキュアモバイルコネクトは継続して提供中
なぜTiDBを使わなかった? • TiDBはTiKV上に保存する際のキーを自由に指定できない ◦ Key: table{tableId}_record{rowId} ◦ tableIdはテーブルを分けることで変更できる・ rowIdはPKのint64 •
1テーブルに書き込む場合はスケールに限界がある ◦ 基本的にテーブルの末尾に追記する形になるので Prefixが分散しない(調整可能) ◦ WriteよりReadが非常に多いサービスは特に問題にならない • Key Prefixを分けるためにはTableを分ける必要がある ◦ 今回のケースだと、1デバイス毎に1テーブル ◦ スキーマ管理などのオペレーションが煩雑になりそう ※性能検証した上で受け入れられるならTiDBを使いましょう
IoT向けストレージにTiKVを採用したときの話 まとめ • TiDBで利用されるTiKVの性質 ◦ 大きいSorted Map ◦ 便利クエリは存在しないが安定性・スケーラビリティに優れる •
アーキテクチャを理解・パフォーマンステストした上でリリースしよう • GoからTiKVを触る話ブログで詳しく書いているので興味あれば ◦ NewSQL TiDBを支える分散KVS "TiKV"入門 https://blog.kamijin-fanta.info/2022/09/tikv-get-started/ さくらインターネットでは“こういう”ストレージの話が出来る人も募集中です