東京ガスの内製チームが「myTOKYOGAS」のデータベースに「TiDB」を選んだ理由：内製化で直面した「データベースの課題」

東京ガスは、利用者数500万人のアプリ「myTOKYOGAS」の内製化に伴い、データベースに「TiDB」を採用した。2025年10月に開催された「TiDB User Day」に登壇した東京ガスの内製開発チームが、TiDBを選定した理由、導入検証で明らかになった注意点、本番運用で工夫すべきポイントを解説した。

[＠IT]

　ビジネスにITが直結する今、迅速なアプリケーション開発と拡張性の両立が求められている。こうした背景の下、コンテナ、Kubernetes、マイクロサービスなどのクラウドネイティブ技術を活用する動きが広まって久しい。

　アプリケーションのアーキテクチャの変化は、データベースにも波及しつつある。先行する企業の間で昨今注目が集まっているのが、「NewSQL」だ。RDB（リレーショナルデータベース）の信頼性、NoSQLのスケーラビリティをいいとこ取りしたデータベースとして注目されている。

　NewSQLの一つに、PingCAPが開発するオープンソースの分散SQLデータベース「TiDB」がある。MySQLと高い互換性があり、オンライントランザクション処理（OLTP）とオンライン分析処理（OLAP）を同時にこなせるアーキテクチャを持つ。

　では、TiDBのような分散SQLデータベースを導入する上ではどのような点に気を付けるべきなのか。移行する上での課題や、本番運用に当たって気を付けるべきポイントとは何なのか。

　2025年10月3日に開催された「TiDB User Day」には、東京ガス、クラスメソッド、Cygames、メルカリといった企業が登壇し、各社がTiDBに関する取り組み事例を紹介した。本稿では、東京ガスの内製開発チームによる講演内容を要約してお伝えする。

「myTOKYOGAS」の内製化に着手も　開発の柔軟性に課題

　1885年（明治18年）に渋沢栄一が創立した東京ガス。文明開化の明治時代、ガスで街と人々の暮らしを明かりで照らすことから始まり、熱源、動力・電力へと用途を拡大してきた。社名に「東京」とあるものの、今では全国、世界に事業展開している。現在、都市ガス小売の顧客は約882.6万件、同じく電力小売は415.2万件（2025年3月時点）。

　電力・都市ガスの小売全面自由化により、各エネルギー会社は顧客獲得が重要な経営課題となっている。東京ガスもデジタル接点を通じた体験価値向上を目指し、早期からエンジニアリングチームの立ち上げやプロダクト開発の内製化へと踏み切った。創立から140年を迎えた同社は、今やデジタル化やDX（デジタルトランスフォーメーション）では先駆者となっている。

　同社でB2C（Business to Consumer）領域のプロダクト開発と運用を進めているのが、リビング戦略部デジタルプロダクト推進グループであり、東京ガスとその顧客の接点となる「myTOKYOGAS」サービスの内製開発に取り組んでいる。myTOKYOGASは、ガス・電気の料金や使用量の確認、ポイントの確認・交換ができる会員向けサービスだ。2025年10月時点では500万弱の顧客が利用しており、東京ガスの契約件数を考えるとユーザー数は今後も伸びる可能性がある。

　2023年11月にmyTOKYOGASをリニューアルしたタイミングで、フロントエンド領域の開発体制を内製化した。その理由は、フロントエンドはビジネスニーズに応じて改修頻度が高く、内製化の効果が高いと見込んだためだ。だが、内製化にかじを切ったものの、開発スピードが思うように伸ばせないもどかしさに直面したという。

　理由は主に2つあった。一つはフロントエンドにバックエンドとの接点としてBFF（Backend for Frontend）を用意したものの、フロントエンドで何か機能を追加しようとしてもバックエンドを担当する組織とのコミュニケーションが必要になってしまうこと。

　もう一つは、myTOKYOGASで扱うデータが他の自社システムでも利用できるようになっていたため、他システムの負荷やデータの取り扱いに関する問い合わせに、内製開発チームが対応しなくてはならなかったことだ。myTOKYOGASの周辺システムを考慮した開発が前提条件となってしまい、開発の柔軟性低下にもつながっていたという。

内製開発チームの講演資料より

東京ガス リビング戦略部 デジタルプロダクト推進グループ Software Engineering Team Lead 中島潤耶氏

　東京ガスの中島潤耶氏（リビング戦略部 デジタルプロダクト推進グループ Software Engineering Team Lead）は「フロントエンド領域だけ内製化しても、柔軟性や速度が出せないことが大きな課題となりました」と話す。そこで料金やポイントなど東京ガスとして汎用（はんよう）的に利用できるドメインの処理やデータ部分をマイクロサービスとして切り出し、共通利用できることを目指した。

　この共通基盤で新たなデータベースが必要になった。先述した通りサービス利用者は500万弱であり、利用者が1000万以上に伸びることを想定する必要があった。現在の規模のデータ量や負荷、今後の拡張性にも対応できるデータベースを選定し、運用する必要があった。

　同社では限られた人数のエンジニアで内製開発しており、データベース運用に多くのリソースはかけられない。Amazon Web Services（AWS）も活用しているためAWSの各種データベースサービスの存在は知っていたものの、シャーディング（大規模なデータベースを分割して複数の小さなデータベースに分散する方法）やログ管理を考慮すると決め手に欠けた。そうした中、2024年に開催されたTiDB User Dayに聴衆で参加し、NewSQLの盛り上がりを肌で感じていたこともあり、「まずはTiDBで試してみよう」と、導入検証に踏み切ったという。

　検証で重視したポイントは、「MySQLとの互換性」と「パフォーマンス」だ。特に互換性については警戒していた。

　「過去に互換性をうたう製品を採用したものの、機能面の差異により、個別の実装や運用が必要になった苦い経験がありました。また現状500万弱のユーザーデータを保存しても、性能劣化が生じないかどうか、書き込みのスパイク（大量アクセス）にも対応できるかどうかを確認する必要がありました」（中島氏）

TiDB検証で注意すべきポイント：ID採番、コネクションプール、外部キー制約など

　検証を踏まえ、結論としては「いける」と導入を決めたものの、IDの採番方法、コネクションプール、外部キー制約、バッチ処理の利用に関しては導入に当たって検討が必要だったという。

IDの採番方式

　TiDBのデフォルト（既定）のID採番方式は、MySQLと挙動が異なっていた。MySQLと挙動が同じになる互換モードもあるが、書き込み性能が劣化するリスクがあった。互換性と性能のどちらをとるかで悩ましかったものの、MySQL互換モードの性能劣化が許容範囲内だったため、MySQL互換モードを選んだという。

IDの採番方式（内製開発チームの講演資料より）

コネクションプール

　アプリケーションとTiDB Cluster間のコネクションはTiDBノードに対して張られ、どのノードに振り分けるかはTiDBが決定する。複数ノードで運用する場合、コネクションのライフサイクルが長過ぎるとコネクションに偏りが生じる場合があり、適切に負荷分散されないことが懸念された。そのためコネクションのライフサイクルを短めに設定し、短時間で接続を分散できるようにした。プロキシも検討したものの、シンプルな方法を選んだ。

外部キー制約

　TiDBの仕様では「外部キー機能は通常、参照整合性制約チェックを強制するために使用され、パフォーマンス低下を引き起こすリスクがある」とされる。東京ガスで負荷テストを実施した結果、多数のリクエストでタイムアウトが生じてしまうことが判明した。原因は外部キー制約を使用する場合には共有ロックではなく排他ロックが生じることや、分散環境における参照整合性チェックなどが影響していた。

　そこで東京ガスでは、アプリケーション側でINSERT前後にそのセッションにおける外部キー制約チェックをオフにする処理を実装した。これでAPIのレスポンスが大幅に改善したため、これで対応することにした。

外部キー制約の有無によるAPIレスポンスの違い（内製開発チームの講演資料より）

バッチ処理での利用

　バッチ処理を行う際、大規模なデータを取得するクエリを実行しているため、TiDBノードのメモリ使用量が高騰してしまう。中島氏は「夜間バッチなので耐えられるものの、（API Serverへの影響を考えると）あまり望ましくない」と懸念した。そこで暫定的な処置として、アプリケーション側でTiDBノードのメモリ解放のための待機時間を設けたところ、メモリの問題が緩和した。

　なお2025年4月から提供が開始された新機能「TiDB Node Group」を使うと、TiDBノードを複数のグループに分割して、エンドポイントを分けることが可能だ。現在は、これを用いてバッチ処理とAPI ServerのNode Groupを分けることを検証している段階だという（詳しくは後述）。

　あらためてTiDBの検証をまとめると、MySQLとの互換性についてはTiDBである故にアプリケーション側でいくらか実装や対応が必要になったものの「許容範囲内」とした。また性能に関しても東京ガスのユースケースにおいては「十分」と判断し、本番プロダクトでのTiDB採用が決まった。

　TiDB導入から1年が経過し、アプリケーション開発チーム視点では、データベースが起因となる問題は発生していないという。「データベースの設計・運用工数を抑え、限られた開発チームのリソースをよりビジネスに近い領域に充てられた」と中島氏は評価している。

TiDBはどのようなクラスタ構成にすべきか

東京ガス リビング戦略部 デジタルプロダクト推進グループ Software Engineer 迫田賀章氏

　講演の後半では、東京ガスの迫田賀章氏（リビング戦略部 デジタルプロダクト推進グループ Software Engineer）が登壇し、TiDBを導入するに当たって検討したポイントを解説した。

　まず、TiDBには自社でデータベースインフラを管理する「TiDB Self-Managed」、フルマネージドで従量課金サービスとなる「TiDB Cloud Serverless」（現在はStarterに名称変更）、専用VPC（仮想プライベートクラウド）に構築されたミッションクリティカルなアプリケーション向けの「TiDB Cloud Dedicated」がある。

　東京ガスの場合、運用負荷の低減やスモールスタートという観点からTiDB Cloud Serverlessを検討していたものの、幾つか懸念点があった。それはデータベースの監査ログが取得できないこと、シングルAZ（アベイラビリティーゾーン）で構成されること、バージョンが自動で更新されること、ユーザー名やパスワードが流出すると誰でもアクセスできてしまうことなどだ。

　もし、TiDB Cloud Dedicatedを採用する場合、クラスタの単位をどうするか。スモールスタートなので当初はシングルテナントから始めると仮定した場合、マイクロサービスが増えたらTiDBクラスタを（複数の）シングルテナントとマルチテナントのどちらで運用するのか。複数ある環境（開発環境、ステージング環境、本番環境）を集約するのか、環境ごとに分離するのかが迷うポイントになったという。

シングルテナントとマルチテナントの違い（内製開発チームの講演資料より）

　もしサービスごとにクラスタを分割する場合、他サービスや環境で高負荷処理や障害が起きた場合に影響を受けにくくなる。またサービスや環境ごとにバージョンアップを分けて実施できる。ただしクラスタ分の利用料がかかること、クラスタごとに監視やバックアップが必要になる。

　逆にクラスタを複数サービスで共有する場合は裏返しとなる。他サービスや環境の負荷や障害の影響が波及する可能性があり、バージョンアップなどは全体への影響を考慮して調整する必要がある。ただしクラスタ数を削減できるためコスト効率が良く、一元的に管理や監視ができるメリットもある。

　検討の結果、まず運用開始時の判断としては、全ての環境でTiDB Cloud Dedicatedを採用することにしたという。特に本番環境とステージング環境ではマルチAZで可用性確保すること、バージョン固定で安定運用すること、監査ログによる操作履歴の把握を重視することにした。開発環境はそこまでの要件はなかったものの、環境差異を避けるためTiDB Cloud Dedicatedで統一した。

　クラスタは暫定方針として「サービスや環境ごとにクラスタを分割する方針」とした。だが、運用してしばらくした後、将来的に運用コストが膨れ上がる懸念が生じたため、Platformチームは「基本は環境ごとで1クラスタに集約し、例外的なケースでは独立したクラスタの作成を検討する」ことを提案した。

　なお例外的なケースとは、高負荷で他サービスに重大な影響を与えるケース、独自の非機能要件があるケース、機密性やコンプライアンス要件で分離が必須となるケースなどだ。将来的にチームが増えて、チーム間の調整コストが増える場合も考えられる。

　またバッチ処理のところで触れた通り、TiDB Node Groupの追加も検討している段階だという。新たに作成したNode Groupにバッチ処理を割り当て、オンライン処理中にバッチ処理を実行する負荷テストを実施したところ、バッチ処理とオンライン処理のメモリ負荷を分散できることを確認した。検証はほぼ完了し、今後は本番環境への適用を目指している。

　迫田氏は「当初はバッチ処理で待機時間を設けて対応しようとしたものの、Node Groupを使用すればその必要はなく、バッチ処理自体も高速化できます。TiDBを起因とするトラブルは未発生で、日常的なメンテナンス工数が少ない印象です。専任の担当者を置かなくても運用可能であり手離れの良さを実感しています」とTiDBを評価している。

　一方、TiDB運用で工夫が必要な点として、TiDB Cloudユーザーの権限粒度、オートスケーリング、コスト管理を挙げた。権限粒度は、TiDBでは管理画面でユーザーのロールなどを設定できるものの、より細かい粒度で権限を設定したい場合には外部サービスから細かい権限を設定することにしている。

　オートスケーリングは、ネイティブ機能でないため、コンピューティングリソースを監視し、APIの活用を検討している。最後のコストは、開発環境とステージング環境ではAPIから朝にクラスタを自動起動し、夜に自動停止することでコストを最適化するようにしている。

　最後に迫田氏は「TiDBを導入して開発に携われる時間が増えたと感じています。TiDBの最大の利点はエンジニアが事業貢献に集中できるところにあると考えています」と講演を締めくくった。