こんにちは、ソフトウェアエンジニアリングチームでチームリーダーをしております中島です。
10/3(金)に開催されたTiDB User Day 2025に同じくソフトウェアエンジニアリングチームの迫田と登壇しましたので、今回はそのレポートです！
我々は、「myTOKYOGASのみならず、BtoCプロダクト開発を加速させ、事業に貢献する」ことを目指して、内製化領域をフロントエンドの領域からバックエンドの領域に広げ、マイクロサービス化を進めています。
マイクロサービス化を進めるにあたって考慮しなくてはならないことが２つありました。１つめはmyTOKYOGASが数百万のお客さまが利用するサービスであることです。２つめは、マイクロサービス化の計画として、「会員」、「料金」、「使用量」といった東京ガスにおける重要なドメインに関連するデータをmyTOKYOGAS以外のサービスにもマイクロサービスを経由して提供しようというものでした。東京ガスの契約アカウント数は大変ありがたいことに、1000万を超えており、myTOKYOGAS単体でもまだまだ利用者の増加が見込まれます。加えて、myTOKYOGAS以外のサービスにも利用されるとなると、生成されるデータは非常に大きなものになることが想定されました。また、「料金確定時」や「ポイント獲得」のタイミングではアクセスが集中するため、それらの負荷にも耐えうるアーキテクチャが必要でした。そこでデータベースとして採用したのが、TiDBでした。そして、一部のマイクロサービスのデータベースとしてTiDBを本番環境で利用し、1年弱大きな問題も発生せず安定稼動していることもあり、我々のような歴史ある日本企業での採用事例として、登壇させていただく運びになりました。
今回は「東京ガス内製開発チームリーダーが語る TiDB本番運用の今」というテーマで登壇しました。
myTOKYOGASやマイクロサービス化の取り組みは、アプリケーション観点では私がリーダーを務めるソフトウェアエンジニアリングチームが担当し、プラットフォーム観点では青木がリーダーを務めるプラットフォームチームが担当しています。TiDBの導入も２つのチームが連携した取り組みであり、それぞれのチームリーダーがアプリケーションとプラットフォームの観点から実際にTiDBを導入してどうだったか？という観点でお話させていただきました。ですが、青木が急遽登壇の都合がつかなくなったため、プラットフォーム観点については、導入当時プラットフォームチームでTiDBの導入を推進した迫田が代打で登壇しました。迫田は、その後チームを異動し、現在はソフトウェアエンジニアリングチームに在籍しています。ですが、ソフトウェアエンジニアリングチームとプラットフォームチームはそれぞれの役割を線引きすることなく、日々より良いプロダクトを作るべく連携していることや、チームリーダーでなくてもメンバーが常に高い視座で自分事として業務に取り組んでくれているからこそ、このような対応が可能でした。
登壇でお伝えしたこと
なぜTiDBを導入したのか？
我々はまさに組織拡大のフェーズであり、限られたエンジニアで内製化を推進しています。そして、事業会社で内製化をしているエンジニアに求められるのは、エンジニアリングを通じての事業への貢献であり、事業からの機能開発の要望は止むことはありません。昨今内製化を進める企業も増えてきましたが、同じような状況におかれている企業も多いのではないでしょうか。
そのような状況だからこそ、「エンジニアもビジネスに深く関わり、ビジネス価値に直結する開発に力を注ぎたい」と考えています。
マイクロサービス化を推進するにあたって、現時点で数百万のユーザーが生成するデータやそれらのデータが投入された状態で安定的なパフォーマンスを出し、スパイクも処理できるアーキテクチャが必要でした。しかし、これらの設計はエンジニアにとっても難易度の高いものであり、設計だけでなくリリース後の運用においても工数がかかります。これは、先に述べさせていただいた「ビジネス価値に直結する開発に力を注ぎたい」という想いとは真逆のものでした。その状況の中で、MySQLへの互換性を持ちながらスケーラビリティを兼ね備えたTiDBは、その問題を緩和してくれる可能性を感じました。そして、TiDBの導入検証に踏み切りました。
TiDBの導入検証で気にしたこと
TiDBの導入検証で気にしたことは、主に２つあります。
TiDBがMySQLへの互換性を持ちながらスケーラビリティを兼ね備えているという点は大変魅力的でした。ですが、昨年度時点では採用事例も多くなかったことに加え、マイクロサービスで採用するデータベース選定であったため、慎重にユースケースに合致するかどうかを確認しました。実際に、負荷テストのタイミングでパフォーマンスの問題が発生し、アプリケーションの作りを一部見直す必要がありました。
過去に互換性が謳われている製品を採用し、実際に実装を進めてみると互換性が基本的なものに止まり、アプリケーションのライブラリが正常に動作しないという経験がありました。そういった場合、アプリケーション側に製品に依存した実装が入ってしまいます。また、すでに採用しているORMなどが動かないという話になると、TiDBのための新たな検討コストや個別対応が入ってしまうことにもなりかねません。データベースは一度選定すれば、高頻度で変更するものではないものの、新興のデータベースということもあり、TiDBそのものへの強い依存は避けたいと考えていました。
登壇では、これらの観点について具体的な内容で検証結果についてお話させていただきました。結果的に、これらの問題はクリアし、我々はTiDBを導入することとなりました。
TiDBの導入
TiDBを採用して1年弱経ちましたが、運用上問題は起きていません。
また、ほとんど運用に工数を取られることもなく、当初の狙い通り、よりビジネス価値に直結する開発に集中ができています。
今回の記事では、あまり触れていませんがTiDBの採用でプラットフォームチームにおいても運用工数を削減できています。
この結果をもって今後はより大きなマイクロサービスなどでの活用を進めようと考えています。
TiDB User Day 2025では、ゲームなどの事例でより大きな問題を解決するためのTiDBの活用も紹介されていました。一方で、我々のシステムはそのようなレベルでの負荷がかかるわけではありません。ですが、TiDBが解決するのはそういった問題だけではなく、従来データベースの設計や運用にかかっていた時間を大きく削減し、「エンジニアの力をより事業貢献できる機能開発に注ぐことができる」という視点もあると考えています。これが我々のような歴史ある企業がTiDBを採用した理由として、登壇で伝えたかったメッセージでした。TiDBはエンジニアの力を事業に繋げるために、有用な選択肢の一つとなるのではないかと思います。
当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！
ソフトウェアエンジニア（プロダクトエンジニア）はこちらから！
tokyo-gas.snar.jp
