DATUM STUDIOPublicationへの投稿
🤓

TiDB User Day 2025 参加レポート

miutaku
に公開
MySQL
分散システム
TiDB
事例
イベント参加レポート
idea

TiDB User Day 2025リモート視聴で参加しました！

みなさんはじめまして！今年3月にDATUMSTUDIOにjoinしました、みうたくと申します。

今回は、2025年10月3日に開催されたTiDB User Day 2025にリモート視聴で講演を見てきましたのでレポートします！
業務の合間での視聴だったため、一部聞き間違いや認識漏れがあるかもしれませんがご容赦くださいmm

https://pingcap.co.jp/tidb-user-day/#agenda

東京ガス株式会社｜東京ガス内製開発チームリーダーが語る TiDB本番運用の今

東京ガスでは、内製の会員サービスシステムとしてmy TOKYO GASがある。
ガスと電気の小売り自由化が始まり、ポイントサービスまで提供できるシステムとして、Webとモバイルアプリ(以下フロントエンド)で提供されている。このシステムにTiDBを採用した話。

summary

  • BFF配下の機能を内製ドメイン/共通基盤へ再編し、バックエンドも内製・マイクロサービス化へ
  • 500万超ユーザー規模を見据えた高負荷耐性と、少人数運用での運用コスト削減がTiDB採用理由
  • MySQL互換（AUTO_INCREMENT/AUTO_RANDOM）など互換性検証を実施
  • コネクション偏りは接続のライフサイクル短縮で分散
  • FK制約は一時的に外部キー検証を無効化→有効化→INSERTの実装で回避
  • 夜間バッチのメモリ圧はインターバル調整＋将来的にNode GroupでAPI/バッチ分離
  • これまでTiDB起因の大障害なし、パーティション/手動シャーディング不要で設計・運用工数を削減
本文

システム構成

これまでは、歴史的に存在する基幹システムを取りまとめるバックエンドとDBが存在する構成だった。
グループ会社製の歴史的なバックエンド(以下レガシー領域)が存在している。
my TOKYO GASでは、このバックエンドに対し、BFFが存在。フロントエンドはこのBFFにアクセスするという構成。レガシー層のAPI改変が困難なため。
ただし、外部サービスとの連携によって、BFFのアクセス量を考慮すると、もうバックエンドの内製化やドメイン層のマイクロサービス化(BFFからの切り出し)、さらには共通基盤化までしてしまおうということになった。
つまり、

  • 内製側
    フロントエンド→BFF→共通基盤(マイクロサービス)
    • バックエンドまで内製して共通基盤化！
  • レガシー
    → 従来通りの基幹システム

という構成を目指した。

なぜ歴史のある企業なのにTiDBを使ったのか

東京ガスといえば歴史のある企業である。それなのになぜNewSQLであるTiDBを採用するに至った理由は大きく分けて2つある。

高負荷でも耐えうる性能

1つ目の理由は、大規模なユーザーアクセスをさばきたいから。
ガスと電気の小売り自由化が始まった
↓
ガスに加えて電気を扱うことになった。
↓
それらが扱える会員サービスを内製で作ることになり、ポイントサービスも提供。
↓
500万ユーザー以上をさばけるDBを使いたい

ヒューマンコスト削減

my TOKYO GASのエンジニアメンバーはあまり多くないため、障害対応・保守運用の負担を下げたい。
そのためDBのヒューマンコストを削減することができるとうれしい。

検証したこと

MySQLとの互換性

MySQLにはIDの採番方式として、以下がある。MySQL互換のAUTO_INCREMENTでも結構さばけるらしい

  • 単調増加しないAUTO_INCREMENT(デフォルト)
  • MySQL互換のAUTO_INCREMENT
    • 単調増加し、MySQLと同じ挙動だが、書き込み性能で劣る
  • TiDB独自のAUTO_RANDOM
    • 一意性があるランダム採番。

コネクションの偏り問題

複数TiDBノード(ここでは2台とする)での運用時、落ちたノードとのコネクションが破棄され、生存しているノードとコネクションが張られる。このコネクションのライフサイクルが長いと、偏りが発生して負荷分散できない。
→コネクションのライフサイクルを短めに設定して接続の分散を促して対処。

FK制約による性能劣化

FK(外部キー)制約を使った場合、TiDBがLOCK IN SHARE MODEをサポートしていないことにより、排他ロックにより性能の劣化が発生する。
→FK checkを無効にしたらいいのでは？と思って調べてみたら、ちょうど東京ガスさんのテックブログで解説されていました！ https://tech-blog.tokyo-gas.co.jp/entry/2025/02/26/123110

→ アプリケーション側のTiDB向けの独自実装で、外部キーを無効→有効→INSERTによって、セッションの外部キー制約チェックを一時的に無効化する処理を入れて対処

メモリ負荷が高くなる問題

夜間のバッチ処理にてTiDBを利用する際、TiDBノードに分割してクエリ実行されていたが、メモリの開放がすぐに行われないため高負荷になりやすい問題があった。これは、バッチ処理のインターバルを用意することで緩和対応した。
TiDBの2025年4月1日の新機能のNode Groupにより、TiDBノードを複数グループに分割し、エンドポイントを分けることができるようになったため、バッチ処理とAPI側のアクセスをNode Groupで分離して対処する見込み。

運用

TiDB起因の障害は特に起こっていないし、パーティション分割やシャーディングをしたりして負荷を抑えるとかもしなくていいので、データ量の影響が少なく、設計・運用工数を大幅に削減できている。

株式会社カプコン｜モンスター級のデータを捌け！ “助けて！”を助ける モンスターハンターワイルズのDB

モンスターハンターワイルズの「救難信号」のテーブルが仕様上厄介かつ、超高負荷環境をさばくインフラについて解説。

summary

  • Go製backend、 救難信号 のDBをTiDB、フレンド等のDBはDynamoDB
  • 同接100万+／100万rps+、最大30万pods級の超高負荷を想定
  • 条件のカーディナリティが低い「救難信号」にTiDBを採用、無停止スケール重視
  • 条件多様・需要偏在に備え、約200テーブル分割で現実的な性能確保
  • TiDBの自動水平シャーディングで読み書きスケール、履歴データは減らして滞留対策
  • OBT/本番期でも無停止でスケールイン/アウト、TTLで自然消滅レコードも自動管理
本文

インフラ構成

  • lang: Go
  • DB:
    • DynamoDB: 自身のフレンド一覧、相手のクエスト履歴
      • 筆者の推測としては、KVSだし複雑な検索に弱いからと考えます。
    • TiDB: 救難信号
      • ワイルズの救難信号は、以下のような項目を好きに設定できる。
      • システム上、カーディナリティが非常に低い(そのためTiDB採用)
        • 特定フィールド
        • クエスト参加最大人数
        • プラットフォーム
        • etc
  • EKS on fargate
    • 通常のWebアプリのようなAPIサーバに加え、リアルタイムサーバ系が存在。
    • リアルタイムサーバ系はレイテンシを抑えるため、複数のリージョンに配置されている。
      • Agonesを利用した、最大100人/1podのロビーシステム

非常に高負荷

まず負荷感から。
ピーク時で

  • プレイヤー: 同接100万以上
  • APIサーバ: 合計1600vCPU
  • リアルタイムサーバ: 合計18000vCPU
  • pods: 最大30万pods
  • リクエスト: 100万rps以上

と非常に高負荷。

TiDBを採用した理由

複数のDBを検討した中で、

  • 救難信号の仕様上、カーディナリティが非常に低いのでこれに対処できる
  • ダウンタイムなしでスペックを変更できてスケーラビリティ
    な点を重視。

TiDBのほかに検討したDBとその採用しなかった理由は以下。

  • AWS DSQL
    • 開発当時は利用できなかった
  • Google Cloud Spanner
    • 外部のクラウドサービスなので原則論外
  • CockroachDB
    • ドキュメントが少ない

性能でゴリ押す

単一のDBで処理しきれないことがゲーム業界だと多くある。特にBig IPだとそう。
そこで、水平分散をすることで、書き込み/読み込み両方の性能をノード数に比例して増やすことができる。
また、アプリケーションの複雑化・プレイヤー数の増減のたびに対応コストをかけたくない。
筆者は元ゲーム業界出身であり、このような手法やモチベーションは非常に理解できる。

立ちはだかる壁

  • クエストセッション(実態)は外部サービスを利用
    • 独自サーバ
    • セッション開始/終了が取得できないが、終了クエストのレコードは消えてほしい
  • 検索条件の種類
    • 10種類ある
    • 条件の傾向予測が難しい
  • 全世界かつ全プラットフォームでのリリース経験がなく、同接数が推測しにくい

RDBを救難信号テーブルに使う懸念

救難信号レコードの特性

非常に揮発性が高い。

  • クエスト時間が最大値になる
    • 平均10分～20分
      • クエストに参加したプレイヤーの攻撃値や練度によってすぐにクエストが終わるためだと考えられる
  • レコードの作成/削除が常に発生し続ける

懸念

この特性上、RDBではなくてKVSとか使うべきでは？という葛藤があった
(カーディナリティ、揮発性の高さ、全文検索不要、総レコード数は数万～数十万件想定)

救難信号テーブルにおいて、全パターンをカバーするインデックスは非常に多くなってしまうし、インデックスの再構築が頻発

対処

分割した。200テーブル程度になる。パフォーマンスを出しながらの場合これしかない。

  • ゲームというプロダクトはそもそも、当初の要件定義から仕様変更が多く発生しがち。
  • プレイヤーがプレイするフィールドの偏りもありうる。

TiDBの導入

TiDBを導入して解決したこととして、自動データベースシャーディングによる水平方向のシャーディング→複数ノードでの負荷分散ができたるので、負荷問題が大幅に解消。

ボトルネックと対処

レコード追加・削除で詰まる問題。これは、TiDBが履歴データを追記するときにデータが滞留し、性能が劣化するため。そのため、履歴データを減らす/参照しないようにする対策をした。
筆者もかつてこれに似た問題を負荷試験にて経験。

運用

リリースタイミング

ゲームにおいて一番負荷がかかるOBT(Open Beta Test)や本番リリースにて、TiDBの障害が特に何も起きず。

  • 負荷が下がってきたタイミングでスケールインさえ実施できた。
    • 当然オンサービスでオフラインメンテナンス実施なし。
    • スケールイン後もトラブルは特に発生せず。
  • 一部クエストのみが遊ばれることで、一部レコードに負荷が集中
    • 分散処理をTiDBに任せたものの、特に問題なかった。
    • 最大レコード数は合計10万程度。

うれしかったこと

  • いつでも気軽にスケールイン/アウトがサービスがオンラインの状態でできる
  • TTLによって消え残るレコードが自動で消えてくれる
  • 自動で水平シャーディング
    • これがおそらくカプコンにとって一番うれしいはず
    • ただでさえ系統や分散したノード数分DBインスタンスの管理がいるのが不要になるので

クラスメソッド株式会社｜AI駆動開発時代におけるTiDB Cloud活用術

DBもAI-Readyであるべきというテーマ。

summary

  • 「AI-ReadyなDB＝AIが書きやすく扱いやすいDB」（知見の豊富さ／素直なスキーマ）
  • TiDB CloudはMySQL互換・方言少・API/MCP対応などでLLM連携しやすい
  • Chat2Queryやベクトル検索でセマンティック検索・自然言語クエリを後押し
  • 無料枠など導入ハードル低めで、PoC〜本番の橋渡しに適する
本文

AI-ReadyなDB

AIにとって"気が利く"DBのことをAI-Readyと定義。

Q. AIが書きやすいDBとは何か？

  • MySQLやPostgreSQLのようなナレッジの多いもの。
    • レガシーなDBは学習データが少ない。
  • シンプルで予測可能な構造。
    • 正規化されていてFKの高い運用性。

AI-ReadyなTiDB Cloud

TiDB Cloudは

  • MySQL互換
  • TiDB独自の方言があまりない
  • APIがある
    • MCP利用等
  • Chat2Query
  • ベクトル検索によるセマンティック検索が可能
  • 豊富な無料枠

株式会社Cygames｜リリース時のアクセス急増をいかにしてノーメンテで乗り越えたか 〜『Shadowverse: Worlds Beyond』におけるTiDB採用のゲームサーバー設計〜

略称について

  • 『Shadowverse』: シャドバ
  • 『Shadowverse: Worlds Beyond』: シャドバWB

summary

  • MySQL運用の限界（高負荷・オフラインメンテ・複雑化）を解消しつつ互換性を確保するためTiDB採用
  • ホットスポット回避と分散キー設計が肝要（例：ULID複合PK）
  • 稼働中は原則スケールアウトのみ、スケールアップは計画的に検証
  • リリース当日40万QPSから、その後50/60/70万QPSへ伸長してもノーメンテで追従
  • オンラインDDL中の一時的劣化は統計情報肥大が原因、8.2.0以降はデフォルトで緩和
  • Node GroupでDDL専用ノードの選択肢（Dedicated）
本文

TiDBを採用した理由

RDBMSの問題点として以下が挙げられる

  • 負荷
    • システムスケールで高負荷対応
    • スケールアウトはメンテナンスタイムが必要
    • オフラインメンテのサービス停止をするとプレイヤーに迷惑をかけてしまう
  • 複雑化
    • プレイヤーの増加に伴い単一DBでは限界
    • 分割するとシステムが複雑化
      • 運用コスト増

この問題を解消しつつ、MySQLとの互換性があるため採用。

MySQLとの違い

TiDBはMySQLの運用と違って意識しないといけない点がある。

  • ホットスポット
    • 特定ノードの負荷集中の危険性
    • スケーラビリティの検証が必要
  • インデックス設計: 分散キーを意識しないと性能劣化
    • スケーラビリティのあるDBであるため
    • ULID(時系列でソートできるランダム文字列)を利用して複合PKを張ることで解消させる。

スケーラビリティ検証

TiDBへの接続において、以下のタイミングでコネクションが切れてしまう。

  • スケールアップ/スケールダウンによる再起動
  • スケールイン

切断されると、アプリ側で再接続・再実行が必要になる。
TiKV(TiDBのデータレイヤにおける分散型KVS)だとこの問題は発生しない。

→ サービス稼働中はスケールアウトのみ実施の方針に。

リリース直後

  • 昼(ピークタイム)
    • APIサーバが80%近いCPU使用率
      • 急激な上昇のためスケールアウトさせて対応
      • 筆者的に、もしスケールアップにしていた場合、その間使えないノード分の負荷が他ノードにのしかかる可能性もあるのでこれが正解だと思う
      • ゲームはプロダクトの特性上、リリース直後に数十%もリソース負荷が急増しがち
    • TiDBノードが12:16にオートスケールしてスケールアウト
  • 昼(ピークタイム後)
    • TiKVのCPUが60%近い使用率に
    • 夜は昼以上のアクセスに加え、バックアップ処理の負荷もかかるためスケールアップ
    • スケールアウトとしなかった理由としては、
      • データリバランスを実施する際、CPUリソースを消費する
      • その処理時間がどれくらいかかるか不明
  • 夜(ピークタイム前)
    • ダウンタイム0でエラーを出さずTiKVのスケールアップできることを検証し確認
      • 負荷試験ツール(sysbenchとかかな)を実行中にTiKVのスケールアップ
      • いけるとわかり、夜ピークタイムの負荷増加に対応可能とわかる

運用

  • リリース日、40万QPS分、メンテナンスフリーにスケールアウトした。
  • しかも後日、50万、60万、70万...とQPS増加していったがノーメンテ。
    • 非常に高い体験価値の提供につながる。
    • スケールをすぐに負荷に応じてできたことが大きい。

Tips

検証時にオンラインDDLでエラーが発生した。

  • TiDBノードのうち1台だけメモリ使用率が高くなってガベージコレクション。
  • 結果、CPU使用率上昇。
  • このノードで走っていたトランザクション処理速度が低下。

→原因はanalyze tableの記録が肥大化したため。

  • 自動でanalyzeが実行されて統計情報が肥大化、結果としてメモリのひっ迫につながった。

ただし…

  • TiDB8.2.0からはこの問題は起きない(デフォルトで統計記録がOFFのため。)

    • 8.2.0以前のものはtidb_enable_historical_statsをOFFに。

  • DDL専用TiDBノード用意の方法もある。

    • TiDB CloudのNode Group(先述)でDDL専用インスタンスが作れるらしい。(Dedicatedのみ)

筆者の疑問

  • TiDBは、統計情報をもとに、CBO(Cost Based Optimizer)が実行計画を選定する。
  • 有効にしないと不適切なインデックスを選択したり、テーブルフルスキャンが発生するなど、結果的にクエリ性能の低下に寄与してしまう可能性があるのではないかと考えた。

株式会社メルカリ｜スケールと信頼性を求めて：メルカリ流TiDB移行とベストプラクティス

  • 4年で20TBが40TBになるレベルの非常にデータ量が大きいDBを扱っていて、TiDBに移行。
  • メルカリ本体・メルペイ(一部)のDB。

summary

  • DCのMySQL 40TB/50台超の巨大データをTiDB Cloudへ段階移行（本体&一部メルペイ）
  • 目的：キャパ限界・増設の遅さ・DDLの停滞を解消、書き込みスケールと運用柔軟性を獲得
  • レイテンシ評価／クエリリプレイ／ProxySQL切替／整合性検証を周到に実施
  • relay/fallback を併用し、Dumpling → DM → TiCDCで同期しつつ安全に切替
  • スケール中のconnection timeout等はgraceful maintenanceやPool調整で対処（GKE更新影響も考慮）
  • Resource Control機能の解説：セッション/Runaway検知/SPM等の制御を活用、TiKV側は優先度制御中心
本文

移行

移行前アーキテクチャ

クライアント→Google Cloudマイクロサービス→DB(MySQL)→CDC Pipeline→DWH(Google Cloud BQ)

DB:

  • DCにある
  • 50台~
  • 40TB~

課題感

  • ハードウェアのキャパシティの限界
  • リクエスト数ドリブンにサーバ台数を増やせない
  • DBが巨大すぎてサーバを用意する際、工数が非常にかかる。
    • インスタンスセットアップして、レプリ張って…で1.5日程度
  • レコード数が多いためDDLの適用に最大数日かかる

TiDBにすると

  • DCの運用工数やセキュリティの解消
  • スケーラビリティ(書き込み)
  • サーバの増減の柔軟性
  • オンラインDDL
  • MySQLとの高い互換性

これらのメリットがあるためTiDB Cloudを選定。

検証

実施したのは以下。

  • レイテンシ増加の検証
    TiDBが分散DBであるためレイテンシ増によるアプリケーション影響の評価。
  • クエリリプレイ検証
    独自ツールを開発し、クエリを再現させることに成功。
  • ProxySQLによる切り替え検証
  • 整合性チェック検証

移行手順

  • relay: TiDBと同期用
  • fallback: TiDBからMySQLへ切り戻しする際のMaster用のレプリカ
  1. Masterの下に2台の移行用レプリカ(relay, fallback)を用意
    master→{relay, fallback}の構成。TiDBCloudでクラスタも作成
  2. Dumpling(PingCAP製dump作成ツール)でrelayからダンプデータ作成
  3. relayからTiDBに差分データをData Migration(TiDB製移行ツール)で同期
  4. master→relay→fallbackのレプリケーション構成にし、master→relayのレプリケーション停止
  5. relay→fallbackのレプリケーションを解消し、TiDBからfallbackに同期するように。
    TiCDC(TiDBのデータを別のDB向けに同期するツール)を利用。
    つまり、 relay→(Data Migration)→TiDBCloud→TiCDC→fallback(masterは分離済み)
  6. relayとfallbackのデータ比較をsync-diff-inspectorで実施
    (一致していれば、Datamigration/TiCDCを使っても正しく差分が生まれていないことになるため)
    問題なければmasterからrelayにレプリケーションを再設定
  7. SELECTクエリのみ、DCにあるMySQLサーバのクエリをリプレイ(リプレイツールはなんと自社開発)
    eBPFベースなライブラリでパケット処理しているらしい。
  8. Google CloudのマイクロサービスのDBの向き先を、DNS切り替えでProxySQLに変更。
    書き込みだけDCのMasterに、読み取りだけTiDBのクラスターノードに。
    空のDDLをMasterに実行(DataMigrationがオンメモリで持っている同期状態をディスクに同期)
  9. GTIDが、fallbackとmasterで一致していることを確認。
    (=masterと、TiDBを経由したfallbackがのトランザクションの状態が同一であると保証される)
  10. timestampがMasterとTiDBで同一であることを確認
    (これでmasterとTiDBクラスタのトランザクションが同一であることが保障される)
  11. 問題なければProxySQLの宛先をTiDBに変更し、TiDBで書き込みもできるようにする
  12. masterにぶら下がっていたサービス用レプリカ群のGTIDのリセットを実施
    (TiCDCを経由するため、GTID値がmasterからぶら下がるインスタンスとでfallbackと異なる)

エラーについて

connection timeout

  • sysbenchしたところ、検証中にスケールアップなどを行うと死ぬ

    • graceful shutdown起因
      • 長いトランザクションが中断される→処理時間を避けてメンテ
      • graceful preiodの設定はメンテ時間とトレードオフで考える。

  • TiDB CloudのGKE updateで深刻な影響を受ける

  • connection poolingによって、新規接続の回数を減らす方針でコネクションが張られる。

    • pool作成はある程度backendで非同期化される
    • ただしパフォーマンス影響が出る

  • 責任の分界点

    • こちらのProxySQL: 切り離す際の責務
    • TiDBCloud:
      • node groupごとにendpointを持っている
      • TiDBが用意するLBにアクセスするしかない(managed serviceなので)

  • backendの切り離しなどは、秒間接続失敗回数がデフォルトで5回しか許容されていないので、注意

    • graceful-before-shutdownとか
    • その他気にしないといけないパラメータがいろいろある。

  • メルカリ提案による graceful maintenance機能が10月にリリース(Google Cloudノードのみ)

RC(Resource Control)

MySQL8.0から使えるようになったRC、TiDBにもある。いい感じにクエリの負荷とか面倒見てくれるらしい。
TiDBのRCは以下。
TiDB

  • クエリや負荷をいい感じに面倒見てくれるらしい。以下のような機能が提供される。
    • セッション管理
    • Resource Unit
    • Run Away Query検出
    • SQL Plan ManagementによるSQL Binding
      TiKV
  • 優先度の制御のみ

各講演を視聴して

共通項

視聴できた全講演から、各社とも共通していることを整理しました。

  • “無停止でスケールできるMySQL互換の分散RDB”が実務で効く。
    リリース直後の急増、イベント時のピーク、夜間バッチなど負荷変動に強い。

  • 手動シャーディングや複雑なパーティション設計から解放。
    アプリ側の分割・再配線コストを大幅に削減できる。

  • 少人数チームでも本番運用が回る。
    運用自動化（気軽なスケーリング、オートスケール、TTL、オンラインDDL等）でヒューマンコストを抑制。

TiDBを使う上で重要なポイント

  • キー設計／ホットスポット対策

    • 連番の偏り回避：AUTO_RANDOM やULID＋複合PKなどで分散性を担保。
    • 低カーディナリティ列の多用時はテーブル/インデックス設計を工夫（必要なら論理分割）。

  • 接続とスケール運用の前提づくり

    • スケール（再起動/縮退）で接続断が起きうる前提で、再実行・再接続の実装を徹底。
    • スケールアウト優先、スケールアップは計画的に（リバランス負荷を考慮）。

  • 統計情報とクエリ最適化

    • 統計の肥大化/鮮度はCBOの要。バージョン挙動を理解し、Analyzeや履歴統計設定を適切化。
    • SQL Plan Management（バインド）や実行計画の固定で安定性を確保。

  • リソース制御（Resource Control）と多系統運用

    • Runaway Query検知、セッション制御、優先度制御で“暴れるクエリ”を抑制。
    • Node GroupでAPI系／バッチ系／DDL系をエンドポイント分離し、相互干渉を低減。

  • 接続プールとライフサイクル

    • コネクションの寿命を短めにし、ノード偏りを回避。
    • graceful shutdown時のタイムアウト閾値や再試行をチューニング。

  • 移行とロールバック設計

    • Dumpling／DM／TiCDCなど公式ツールで段階移行＋差分同期＋切戻し手段を用意。
    • 移行の際は緻密な整合性検証を実施して本番切替のリスクを極小化。

得られるメリット（チーム/ビジネスへの効き方）

  • スケールの自由度：ピーク時は即スケールアウト、落ち着いたらスケールイン。無停止での容量・性能調整が標準運用になる。
  • 運用コスト削減：手動シャーディング・レプリカ再構成・大規模DDL停止…を回避し、少人数でも大規模運用が可能。
  • MySQL互換の安心感：既存資産（アプリ/ORM/運用知見）を活かしながら、分散RDBの恩恵を受けられる。
  • 開発速度の加速：インフラ都合の設計制約が減り、プロダクト要求の変化に追随しやすい。
  • データ寿命管理の自動化：TTLなどで “消えるべきものは自動で消える” 運用が可能。

所感

  • モンスターハンターワイルズは私もプレイしているが、やはりBig IPで高負荷が予想されたためか、非常にパフォーマンスを重視したテックスタックになっていると感じました。
  • TiDBは無料枠も結構太っ腹なので、小さい規模から始まるアプリケーションにとりあえずTiDBを採用してもいいのかもしれないなぁと思いました。
    • ソーシャルゲームのような非常に大きい負荷をさばいている前例がすでにあるのですから。
  • プロダクトの成長に合わせてDBをスケールさせられるメリットは、思っている以上に大きいと思っています。
    • 初期投資が少ないながらもプロダクトの成長度に合わせて現実的なインパクトでコストが増減するため。
  • DBを管理するヒューマンコストは尋常ではないものであり、スケーラビリティの高いマネージドDBサービスを利用することは、ヒューマンコスト・費用的コストを大幅に削減でき、しかも顧客への大きな価値提供につながると考えています。
    • 利用率が低い時間帯が深夜だろうが何時だろうがオートスケーリングします。
    • 手動でもスケーリングしたいときに気軽に実施できます。
    • しかもほぼメンテナンスフリーに実施できます。
DATUM STUDIO
DATUM STUDIOPublication

DATUM STUDIOはデータとテクノロジーを活用し、クライアントのビジネスに持続的な成長と新たな可能性をもたらす会社です。 ツール導入や分析コンサルティングなどを通じて支援します。 特にデータマイニング領域では、独自アルゴリズムの設計やカスタマイズを強みとし、課題やデータ構造に応じたアプローチで価値を創出します。

Discussion