こんにちは！ソフトウェアエンジニアリングチームの夏です。ドメイン層のマイクロサービス化に取り組んでいます。マイクロサービス化の取り組みの詳細については、以下の記事をご参照ください。
私たちのチームでは、マイクロサービスのデータベースの一つとして TiDB を採用しています。
TiDB Cloud Dedicated では、2025年4月1日に TiDB Node Group が GA になりました。 この機能は運用中のマイクロサービスで使用している TiDB に導入するメリットがあると判断し、本番環境で稼働中のサービスに導入しました。今回はその内容についてご紹介いたします。
TiDB Node Group とは？
TiDB は分散型の NewSQL データベースで、TiDB ノードがアプリケーションからの接続を受けて SQL を処理し、ストレージクラスターと通信してデータの読み書きを行います。
TiDB Node Group は、TiDB ノードを複数のグループに分割できる機能です。物理的にグループ化することで、グループごとにコンピューティングリソースを分離することが可能になります。
TiDB Node Group 導入の背景
私たちのチームでは、あるマイクロサービスにおいて TiDB を使用し、本番運用しています。新規開発中のマイクロサービスでも、データ量・リクエスト特性・運用コストの観点から TiDB を採用することになり、そのタイミングで TiDB におけるクラスター構成の見直しを行いました。
新規マイクロサービスで TiDB を利用するにあたり、選択肢は次の2つでした。
クラスターの集約方針についてはプラットフォームチームとソフトウェアエンジニアリングチームで議論しました。
クラスターを集約した場合は、金銭的なコストを削減できる点や管理・監視の対象が少なくなるため運用コストを下げることができる等のメリットがあります。 一方、特定のサービスによる高負荷が他のサービスに波及する可能性がある点やバージョンアップもサービス全体への影響を考慮した上で実施する必要がある点等のデメリットもあります。
私たちのチームでは、クラスター集約による運用コストおよび金銭的なコストの削減の面で大きなメリットがあると判断し、Resource Control や TiDB Node Group 等の機能を活用しながら基本的にはクラスターを集約する方針としました。 ただし、極端な高負荷ワークロードが他サービスへ重大な影響を与える場合や独自の非機能要件がある場合等でクラスターを独立させるべきケースは別途検討することにしています。
この方針に従い、今回新規開発するマイクロサービスについては、運用中のマイクロサービスと同じクラスターに集約することになりました。
クラスターを集約する上での課題
TiDB を使用して本番運用しているマイクロサービスは、API サーバーとバッチ処理の2つのコンポーネントで構成されています。 このマイクロサービスにおけるバッチ処理では、データの取得処理によって TiDB ノードのメモリを多く消費します。一方で、TiKV のリソースには十分な余裕がある状況でした。
そのため、新たなマイクロサービスで既存のクラスターを利用するには、バッチ処理による TiDB ノードのメモリ消費が他のサービスに影響を与えないよう、リソースを分離する必要がありました。 TiDB Node Group は、TiDB ノードをグループ分けすることで、コンピューティングリソースを分離できるため、バッチ処理による TiDB ノードの高負荷の影響を分離することができると考え、導入に向けて検証しました。
TiDB Node Group の検証
導入後のクラスター構成
TiDB Node Group 導入前のマイクロサービスの構成は以下のとおりで、クラスターは TiDB ノード2台と TiKV ノード3台で構成されています。
TiDB Node Group 導入後は、バッチ処理による高負荷の影響を API サーバーに波及させないために、新たに TiDB ノードを追加し、バッチ処理用の Node Group を作成しました。 API サーバーは従来どおり TiDB ノード2台の Default Group を利用します。各 Node Group は、エンドポイントが分かれているため API サーバーは Default Group、バッチ処理は専用の Node Group のエンドポイントへ接続するように設定しました。
検証結果
検証はプラットフォームチームと協力して実施しました。 検証では、大規模なテストデータを投入した状態で、API サーバーに負荷をかけながらバッチ処理を実行し、導入前後における TiDB ノードのメモリ使用量を比較しました。
まず1つ目のグラフは、TiDB Node Group 導入前の TiDB ノードのメモリ使用量です。バッチ処理の実行中にメモリ使用量が急増していることが確認できます。 バッチ処理では、データを一定の単位で段階的に取得しており、そのたびに TiDB ノードのメモリ増加が発生しています。 また、TiDB Node Group を作成していないため、2台の TiDB ノードの両方に接続してデータを取得していることが確認できます。この2台の TiDB ノードは API サーバーでも利用しているため、API の処理に影響が波及します。
2つ目のグラフは導入後の TiDB ノードのメモリ使用量です。バッチ処理用に用意した 1台の TiDB ノードのメモリ使用量のみ急増しています。
db-tidb-0 と db-tidb-1 は API サーバー用の TiDB ノードですが、バッチ処理の高負荷の影響を受けておらず、メモリに十分な余裕があることが確認できます。
この結果より、バッチ処理によるメモリの消費による影響を API サーバーから分離できていることが確認できました。
まとめ
今回は TiDB Node Group の導入事例を紹介しました。 TiDB Node Group を導入することで、バッチ処理の高負荷が API サーバーへ与える影響を分離できることが確認できました。 また、既に本番環境でも TiDB Node Group の導入が完了し、API サーバーもバッチ処理も問題なく動作しています。
さらに、新規マイクロサービスでの TiDB 利用については今後検証を進め、1つのクラスターに集約することを目指しています。 これにより、費用と運用コストを抑制し、その分を新たな価値創出に充てていきたいと考えています。
最後までお読みいただき、ありがとうございました！
当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！
ソフトウェアエンジニア（プロダクトエンジニア）はこちらから！ tokyo-gas.snar.jp
