東京ガス、「myTOKYOGAS」の開発内製化をTiDBで加速　エンジニアが事業を動かす環境へ

「ビジネスとデジタルが分離してしまう」　内製化への挑戦とTiDBという救世主

　「myTOKYOGAS」は、電気やガスの料金、使用量、ポイントなどを確認できるアプリケーション。東京ガスにとっては顧客との重要な接点であるが、アプリケーションの開発・運用は、長らく外部に委託されてきた。転換点となったのは2022年頃、外部委託のままでは顧客ニーズへの迅速な対応、フィードバック・サイクルの高速化などが困難になるという課題を長く抱えていた。

　同社 リビング戦略部の中島潤耶氏は、「開発者もビジネス担当者も、『プロダクトをただ作るのではなく、プロダクトを通じて事業に貢献する』という共通目的を持つことこそが、DX成功の秘訣だと感じていた」と当時を振り返る。この課題解消に向けて、東京ガスが着手したのは内製開発チームの発足だ。

　エンジニアがほぼゼロの状態からスタートすると、中島氏がソフトウェアエンジニアとして参画。その後、徐々にエンジニアも増えていき、現在はデザイナーやスクラムマスターを含めて数十人規模にまで成長している。

　手始めに取り組んだのは、主力アプリケーションであるmyTOKYOGASの内製化だ。決済や料金管理といった基幹システムに関わるバックエンド領域は安定稼働を優先させるため、基本的に従来からの開発体制を継続。まずは顧客体験に直結するUI周辺など、基幹システムに影響の少ない領域から着手された。

　当時のアプリケーションは、いわゆるモノリシックなアーキテクチャで構築されており、サービス画面ごとに強い依存関係が生じていた形だ。この状況を解消するため、まずはバックエンドからデータを取得し、アプリケーション向けにデータを加工するBFF（Backends For Frontends）に抽象化レイヤーを設け、ドメインを整理しながらシステム改修を進めていった。現在は、そこで整理されたドメインを少しずつマイクロサービスとして切り出しており、新たな機能追加にともなって生じるドメインについても、マイクロサービスとして構築している。このマイクロサービス化を進めるためのデータベースとして検討されたのが、TiDBだった。

　myTOKYOGASのユーザー数は数百万、潜在的には一千万近い契約者がいるため、「（将来的には）一瞬で何千万ものデータが溜まる可能性が予測できた」とリビング戦略部 迫田賀章氏は述べる。シャーディングやログのパーティショニング、大規模なログデータのAmazon S3へのアップロードといった、パフォーマンス維持のために複雑な対策が必要になることが見えていた。「当時、既にパフォーマンスに関するチケット（タスク）が積まれており、いずれ壁にぶつかることが見えていました。そこに救世主のように現れたのが『TiDB』です。結果的には、課題となっていたタスクがすべて消えました」と迫田氏。このときプラットフォーム側でも、運用面で課題を感じていたという。

　少人数のチームで既存サービスの運用と新規基盤構築を並行して行う必要があったため、データベースの運用にかかる工数を少しでも削減したかったからだ。同部 青木翔平氏は「運用負荷が大きく下がるならば、専門のDBAのようなメンバーを置かなくとも運用できるのでは」と考えていたという。たとえば、パブリッククラウドのマネージドサービスを利用することも一つの方策ではあるが、運用負荷を軽減できても、バージョンアップやメンテナンスには依然として時間と手間をかける必要があるだろう。

　そこで青木氏が参加したのは、TiDBのユーザーイベント。TiDB導入により専任の担当者がいなくても、PingCAPからのサポートを得ながら運用ができているという他社事例を聞いたことで、本格的な検討に乗り出す。

「ほぼ完璧に動いた」　MySQLとの高い互換性、迅速なサポート

　TiDBの本格的な検討に乗り出すと、まずはアプリケーションチームがローカル環境でTiDBを立ち上げ、MySQLとの互換性を検証するところから始めた。

　当初、アプリケーションはPostgreSQLを採用し、O/Rマッパーを利用してデータベースにアクセスすることで、PostgreSQL固有の機能には依存しないように構築していたという。そのためPostgreSQLからTiDBに切り替えてみたところ、「MySQL用にドライバを変えた程度でほぼ動いた」と迫田氏は説明する。MySQLとの互換性は高く、アプリケーションにもほとんど手を加えることなく動作したのだ。過去には「互換性のある」他のデータベースで期待通りの動作が得られず、手作業での対応が必要になった経験があったといい、TiDBの「ほぼ完璧に動いた」という結果は、TiDBを採用する決め手となった。

　他にも、大規模なユーザー数とデータ量に耐えうるかを確認するため、負荷テストも実施。検証を進める中、共有ロックに関する問題、モニタリングツールとして利用しているDatadogとの接続性など、いくつかの技術的な課題も見受けられたが、PingCAPによるサポートによって迅速に解決できたという。

　なお、TiDB導入にあたっては「TiDB Cloud Serverless」を検討していたものの、最終的には「TiDB Cloud Dedicated」が選択された。その理由として、当時はTiDB Cloud ServerlessがシングルAZ構成で、可用性に懸念があったことが挙げられる。また、バージョンアップのタイミングについては、ビジネス要件とあわせて自社でコントロールしたいという意向もあった。加えて、監査ログ機能をTiDB Cloud Dedicatedでしか利用できなかった点も大きかったとする。

　TiDB Cloud Dedicatedでは、ノードのサイジングやクラスタ構成の設計要素などは増えるものの、従来のデータベース運用と比較すればチューニングの労力は大幅に削減可能だ。これらの検証を経て、myTOKYOGASにおけるマイクロサービスのデータベースとして、2024年11月に「TiDB Cloud Dedicated for AWS」が本番導入された。

TiDBがもたらした安定稼働　エンジニアが“事業貢献”に集中できるように

　TiDBの導入は、東京ガスの内製開発チームに大きな効果をもたらしている。2024年11月の導入から半年近く経過しているが、大きな問題はこれまで発生していない。中島氏は、アプリケーションの稼働を確認するチームミーティングでは、「『今日も平和だね』という会話を交わすほど、運用は安定しています」と語る。青木氏も「われわれで手をかけるところは、日常の運用ではほぼないため、期待通りでした」と述べるなど、TiDBによる運用負荷の削減効果を実感しているようだ。

　現在、アプリケーションの運用状況は、先述したようにDatadogで定期的にモニタリングしている。Datadogのダッシュボードでも、TiDBには異常な動きが見られないという。また、「無停止でバージョンアップできると聞いており、将来的なメンテナンスについても懸念は少ないです」と迫田氏は述べる。これまで、TiDBが原因となるメンテナンスウィンドウやアプリケーション停止は発生していない。

　この安定稼働と運用負荷の低減効果は、エンジニアがビジネスロジックの改善、新機能の開発に注力できる環境を提供している。「エンジニアがインフラを意識せず、ビジネスロジックに集中できる環境となり、開発環境が大きく変わりました」と迫田氏。ビジネスとデジタル、双方の担当者が共通目標を掲げて変革に取り組んでいくため、運用負荷が極めて小さいTiDBの貢献は大きいという。

　今後、東京ガスは内製開発の領域をさらに広げていく方針だ。myTOKYOGASで培ったエネルギー料金や使用量、ポイントといったデータは、他のプロダクトにも共通利用していく。これらのデータを活用できるようにマイクロサービス化も続いている。何よりも東京ガスのエンジニアにとっては技術基盤の安定や維持にとどまらず、「事業へ直接的に貢献すること」が重要なミッションだ。

　その目標に向けてはTiDBへの期待も大きく、将来的に新たな大規模データを保存する必要が生じた場合、まずはTiDBを検討することになるという。（TiDBによって）エンジニアはデータベースから解放された、“ビジネスロジックに集中する”ための開発・運用スタイルを確立できる。それにより、エンジニアは事業貢献に全力を注いでいく。

　青木氏も、今後プロダクトが増えていく中で、専任のデータベースエンジニアを多数採用するのではなく、TiDBを最大限に活用しながらインフラをスケールさせていく方針を示す。TiDBのスケーラビリティと、マイクロサービス基盤を組み合わせることで、内製チームのエンジニアに高品質なインフラを提供していけるという。

　なお、今回取材に応じてくれた中島氏と青木氏は、2025年10月3日にハイブリッド開催される「TiDB User Day」でも、アプリケーションとインフラそれぞれの視点から、TiDBの活用事例について講演を行う予定だ。これは同社がTiDBの導入に成功し、それを積極的に外部に発信する意欲の表れでもあるだろう。TiDBは、東京ガスのDX推進と内製開発組織の強化において、不可欠なパートナーとして存在感を高めていると言えそうだ。