Upgrade to Pro — share decks privately, control downloads, hide ads and more …

IoT向けストレージにTiKVを採用したときの話 / 2024-10-25 TiUG Meet...

IoT向けストレージにTiKVを採用したときの話 / 2024-10-25 TiUG Meetup 3 Using TiKV as IoT storage

kamijin_fanta

October 25, 2024
Tweet

More Decks by kamijin_fanta

Other Decks in Programming

Transcript

  1. 上條 忠久 • さくらインターネット 2016年 新卒入社 • ずっと大阪勤務 • クラウド事業本部

    所属 • 今は監視基盤を開発中 ◦ Go, Kotlin, React, TypeScript, TiDB, Trino, Iceberg… ※今日の話は多分当時はこうだったという適当な話です
  2. 第一世代 • 当時DBはMySQL, Postgresql, Elasticsearchくらいしか知らなかった • Elasticsearch良さそう ◦ クラスタリング対応 スケーラビリティ・耐障害性高そう!

    ◦ レプリカ・シャードを割と自由に設定できるらしい! ◦ 自由にJSONでクエリ書ける! • 社内でも何台か動いているらしい • とりあえず作ってみよう ◦ Elasticsearchにデータを入れるところは JavaSDK + Scala + Akka http ◦ ユーザがアクセスする REST APIをPython + flask • 2016年6月から開発・同年12月にリリース
  3. なんで辛かったか • ElasticsearchにはIndexという保存領域が存在 • 毎日デバイス毎にIndexを作っていた ◦ 1000デバイスが3ヶ月間保存すると9万Index • どうやIndexあたり数MBのメモリが必要らしい ◦

    9万Indexに必要なメモリ総量は 900GB…? ◦ 当時1台に割り当て可能なメモリは 32GBが最大 ◦ サーバ1台で30デバイスくらいしか収容できない … 1日1通のデバイスも居るんですが … • Index毎にPrimary/Secondaryの選出等が行われる ◦ ノードが追加・削除されたタイミングで全て選出し直される • ノード間のデータの容量に偏りが少なくなるようにリバランスが入る ◦ Indexあたり数十秒掛かる 並列でも数時間~数日単位で性能劣化 …
  4. 第二世代の開発を開始 • 主な要件 ◦ デバイスから送信される JSONを保存・ユーザがHTTP APIでクエリできる事 ◦ 1日に1メッセージのデバイス・ 1秒に1メッセージのデバイス

    数万倍の差を吸収できる事 • 色々なDBを調査 ◦ Cassandra, HBase, Hypertable, Kudu, MapR, Druid, InfluxDB, TimescaleDB ◦ 要件に合う・DB自体の運用が楽・アプリケーション側の実装が楽 なDBは意外と少ない • 色々試した結果TiKVが一番向いていそうだ
  5. 第二世代 • ストレージはTiKV • 開発言語はGo ◦ TiKVのクライアントはGo向けが一番ちゃんとしていた • TiKVは便利なクエリ/Indexがない ◦

    基本的に↓だけでアプリケーションを作る ◦ Get(key []byte) => []byte ◦ Put(key []byte, value []byte) ◦ Delete(key []byte) ◦ Scan(keyStart []byte, keyEnd []byte) => [][]byte • シンプルなので運用が比較的楽・コントロールしやすい
  6. TiKVの扱い方 • TiKVはデカい「Sorted Map」 ◦ Keyの順番でソートされた Map(辞書) • 容量等に応じて透過的に分割・クラスタ内で分担 ◦

    この要件にマッチする →1日に1メッセージのデバイス・ 1秒に1メッセージのデバイス ◦ 分割によって書き込みスループットがスケール https://blog.kamijin-fanta.info/2022/09/tikv-get-started/
  7. 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”: …
  8. さくらインターネットのIoTサービス 頑張って作ったが… • 2016年4月1日 sakura.io パブリックα提供開始 • 2017年4月18日 sakura.io 正式サービス提供開始

    • 2022年3月24日 後継サービス モノプラットフォーム提供開始 • 2024年5月30日 モノプラットフォーム 新規申し込み停止 SIM 1枚月額13円から利用可能なセキュアモバイルコネクトは継続して提供中
  9. なぜTiDBを使わなかった? • TiDBはTiKV上に保存する際のキーを自由に指定できない ◦ Key: table{tableId}_record{rowId} ◦ tableIdはテーブルを分けることで変更できる・ rowIdはPKのint64 •

    1テーブルに書き込む場合はスケールに限界がある ◦ 基本的にテーブルの末尾に追記する形になるので Prefixが分散しない(調整可能) ◦ WriteよりReadが非常に多いサービスは特に問題にならない • Key Prefixを分けるためにはTableを分ける必要がある ◦ 今回のケースだと、1デバイス毎に1テーブル ◦ スキーマ管理などのオペレーションが煩雑になりそう ※性能検証した上で受け入れられるならTiDBを使いましょう
  10. IoT向けストレージにTiKVを採用したときの話 まとめ • TiDBで利用されるTiKVの性質 ◦ 大きいSorted Map ◦ 便利クエリは存在しないが安定性・スケーラビリティに優れる •

    アーキテクチャを理解・パフォーマンステストした上でリリースしよう • GoからTiKVを触る話ブログで詳しく書いているので興味あれば ◦ NewSQL TiDBを支える分散KVS "TiKV"入門 https://blog.kamijin-fanta.info/2022/09/tikv-get-started/ さくらインターネットでは“こういう”ストレージの話が出来る人も募集中です