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
180
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
IoT向けストレージにTiKVを採用したときの話 / 2024-10-25 TiUG Meetup 3 Using TiKV as IoT storage
https://tiug.connpass.com/event/327074/
kamijin_fanta
October 25, 2024
More Decks by kamijin_fanta
See All by kamijin_fanta
2026-06-11 Iceberg Trinoログ基盤の 設計ポイント - Design Points for an Iceberg + Trino Log Platform
kamijin_fanta
0
6
2025-09-22 Iceberg, Trinoでのログ基盤構築と パフォーマンス最適化
kamijin_fanta
1
850
2025-04-14 Data & Analytics 井戸端会議 Multi tenant log platform with Iceberg
kamijin_fanta
1
760
TrinoとIcebergで ログ基盤の構築 / 2023-10-05 Trino Presto Meetup
kamijin_fanta
1
2.5k
Unicodeと符号化形式
kamijin_fanta
0
1.2k
Reactとフォームとスキーマバリデーション / React forms with Schema Validation
kamijin_fanta
0
2.7k
2020/05/25 さくらのクラウド向けツールを使いこなす
kamijin_fanta
3
380
2019-01-24 業務でのOSSとの関わり方
kamijin_fanta
7
5k
関数型言語で始めるネットワークプログラミング
kamijin_fanta
0
1.2k
Other Decks in Programming
See All in Programming
symfony/aiとlaravel/boost
77web
0
120
Snowflake Summitでの新機能 CoCo / CoWork / snowflake-summit-2026-overall-what-new-coco
tatsuhiro
1
220
信頼性について考えてみる(SRE NEXT 2026 miniLT)
hayama17
0
160
【やさしく解説 設計編 #0】DDDのコード、読めるのに分からない人へ
panda728
PRO
2
260
Contextとはなにか
chiroruxx
1
390
トークンをケチるな、設計しろ:GitHub Copilotを賢く使うコンテキスト戦略
ochtum
0
310
その問い、本当に正しいですか?AI時代のエンジニアに必要な哲学と認知科学 / ai-philosophy-cognitive-science
minodriven
14
6.8k
【やさしく解説 設計編・中級 #1】一つの車に、運転手は一人 ~ある倉庫システムの事例から~
panda728
PRO
0
170
技術記事、 専門家としてのプログラマ、 言語化
mizchi
14
7.4k
Skillsは効率化、Agentsは"自分の拡張"——Builder時代のエージェント編成(CC Night 2026)
wemra
1
210
関数型プログラミングのメリットって何だろう?
wanko_it
0
160
【やさしく解説 設計編・中級 #6】良いアーキテクチャとは ~ 一本の登り道の、行き先 ~
panda728
PRO
0
150
Featured
See All Featured
KATA
mclloyd
PRO
35
15k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2.1k
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
350
Speed Design
sergeychernyshev
33
1.9k
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
0
340
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
My Coaching Mixtape
mlcsv
0
170
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
490
Embracing the Ebb and Flow
colly
88
5.1k
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
62
44k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
650
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/ さくらインターネットでは“こういう”ストレージの話が出来る人も募集中です