運用コスト削減、スケーラビリティ向上のポイントは
記事公開日：2025年1月7日
統合コマースプラットフォーム｢ecforce｣は、1,400ショップ以上に導入されている。その傍ら、急激な事業拡大にともない、ショップ情報を管理するリソースや運用コストの増加が課題となっていた。2024年11月に開催されたアーキテクチャConference 2024では、ecforceを開発・提供するSUPER STUDIOが登壇。「NewSQLを用いたDB分離のマルチテナントアーキテクチャ〜ecforce編〜」と題したセッションでは、TiDBの特徴を踏まえながら、ecforceが抱えている課題をどのように解決したのか。また、TiDB Cloudを選択した理由や移行状況などが解説された。
｢ecforce｣のシンプルなアーキテクチャ、見えてきた課題とは
SUPER STUDIOの設立は2014年。メインプロダクトである「ecforce」は、2017年のプロダクトローンチからしばらく、ECショップを開設する顧客をサポートするためのカートシステムを展開してきた。
このカートシステムを中核に据えながらも、直近では「コマースDX」の実現に向け、マーケティングや販売チャネルの強化、アジャイルなデータ活用を可能にする統合プラットフォームとしてプロダクトを進化させている。そう語るのは、同社 プロダクトエンジニアリング本部／SREグループ グループマネージャを務める田幸久志氏だ。
株式会社SUPER STUDIO プロダクトエンジニアリング本部／SREグループ グループマネージャ 田幸久志氏
Web上の自動接客システムやEFO（入力フォーム最適化）、パーソナライズ機能など、従来のEC運営で必要とされてきたアプリケーションはもちろん、実店舗とのデータ連携や店舗予約・顧客管理が可能なプロダクトなどに加えて、データ活用関連のソリューションにも注力。複数のチャネルを跨いだデータの可視化・分析を可能にする「ecforce bi」や、顧客セグメントごとにパーソナライズされたCRM施策を打てる「ecforce ma」などのプロダクトも提供を開始したという。
こうしたecforceの進化を支えているのは、シンプルなアーキテクチャだ。Webサーバーとバッチサーバーが根幹を担い、それぞれがデータベースにアクセスする構成を採用。Amazon EC2インスタンスはWebサーバー約1,000台、バッチサーバー約450台の計1,500台ほどが稼働している。
データベースは、Amazon RDS for MySQLとAmazon Aurora MySQLを併用し、1,400以上のショップの情報を350以上のデータベースクラスタで管理しているという。田幸氏によると、ecforceはショップごとにデータベース・インスタンスが割り当てられる、いわゆる「マルチインスタンス」と、1つのデータベース・インスタンスに複数のショップが紐づいている「シングルインスタンス／マルチデータベース」を併用する形で運用されている。
MySQLを利用しているため、レコード単位での分離を実現する“ローレベル・セキュリティ（Row Level Security）”機能が担保されておらず、使い方としても想定されていない「シングルインスタンス／シングルデータベース」の構成は適さないともいう。一般的にマルチテナントのデータベースアーキテクチャは、下図のように大別できる。いずれもリレーショナルデータベースの特性から、自由な拡張は難しい。
そのため、ecforceはショップごとに論理データベースを分けている状況だ。ecforceはサービスの特性上ショップごとに使い方が異なるため、ショップごとにデータベースの使い方も変わる。たとえば、データベースのレスポンスが悪くなった際に、インデックスによって解決しようとすることは一般的な対策の1つだが、「すべてのショップに適用した際、こちらのショップはレスポンスが速くなる一方、別のショップではむしろ遅くなることがあり得ます。そのため、データベースをショップごとに分離しておくことも我々にとっては必要です」と田幸氏。さらにリソースの増加やデータベース・インスタンス管理の煩雑化といった課題も生じているという。
データベース・インスタンスは300以上存在し、メンテナンスや障害対応に手間がかかるだけでなく、データベースのスケールアップ時にはサービス停止も必要となる。加えて、データ活用を進めていく際にはショップ単位ではなく、ecforce全体で横断的なデータ分析を実現したい。とはいえ、すべてのデータベース・インスタンスにリクエストを投げ、集計することは現実的でないだろう。
つまり、ダウンタイムなしでのスケールアップやコスト削減、横断的なデータ活用に取り組みたいと考えても、現状のアーキテクチャが機能実装を阻んでしまっているような状況だ。
コミュニティ版に断念も「TiDB Cloud」を検討へ、その魅力は
先述した課題を抱える中、検証に着手したのは分散型のNewSQLである「TiDB」だ。まずはOSSである「TiDB Community Edition」のTiDBを検証してみたものの「自分たちの体制だけでは、TiDBをAmazon EKS（Elastic Kubernetes Service）などに載せて運用し続けることが難しいと感じました」と田幸氏。特にTiDBは、新機能開発や機能改善が日々行われているため、最新情報を追い続けながら適用すべきか否かを適宜判断し続けるような運用が難しいのではないか、と懸念したという。
加えて、OSSコミュニティへの問い合わせやサポート体制への不安も拭えず、コミュニティ版の採用は見送られた。その後、新たなアプローチを模索する中、PingCAPから紹介を受けたことで検討を進めたのが「TiDB Cloud」だ。
TiDB Cloudは、TiDBをフルマネージドでクラウド利用できるサービス。PingCAPからServerlessとDedicatedという2つの形式で提供されており、Serverlessはマルチテナント型、Dedicatedは専有型となる。PingCAP シニアソリューションアーキテクトの日下太智氏によると、TiDB Cloudではマシンスペックや台数を柔軟に変更でき、Serverlessはスケール操作が自動化され、DedicatedはGUIまたはAPI経由で変更可能な点が特徴的だという。なお、TiDBはMySQLとの互換性が高いことから関心を集めることも多いが、完全互換ではない点は留意したい。
PingCAP株式会社 シニアソリューションアーキテクト 日下太智氏
また、分散型SQLデータベースであることもTiDBの特徴だ。アプリケーションからは、単一のMySQLデータベースのようにも見えるが、実際には4つのコンポーネントで構成されており、ノード追加やスペックアップも容易だ。
TiDBは、各テーブルのプライマリキーの範囲でシャーディングを行い、2つのストレージコンポーネント「TiKV」「TiFlash」を有している。基本的にはTiKVを用いるが、アドホック・クエリによる大量データを集計するためには、カラム型のデータストアであるTiFlashも利用できるという。残る2つのコンポーネントは「TiDB」「PD」であり、TiDBノードは、SQLクエリを受け付け、TiKVまたはTiFlashに転送する役割を担う。そしてPDは、シャードされたデータの位置情報を管理するコンポーネントだ。
従来のRDBMSでは、書き込みスループットの限界に対処するために水平シャーディングが必要だった。しかし、TiDBではシャーディングが自動で行われるため、アプリケーションからは単一のデータベースとして見える。実際には、データは3つのコピーで冗長化され、単一AZ障害にも対応できるという。
なお、バージョンアップやDDLなどもオンライン実行可能だ。何よりも分散型アーキテクチャであるため、多少のネットワークオーバーヘッドが発生するものの、スループット向上を期待できる点が最大のメリットといっても過言ではないだろう。
スケーラビリティとコスト削減を両立、移行進める
TiDB Community Editionの検証で断念したものの、TiDB Cloudなら現状の体制でも負担は少ない。特にシングルインスタンス／マルチデータベースに寄せていく方針をとっていた中、サービス停止なしで拡張できる点は、バージョンアップの際にもショップ利用が継続できるなどのメリットもある。
また、データベースの構成を変えずに移行できるため、ショップへの影響を最小限に抑えられる点も評価したと田幸氏。実際にTiDB Cloudを検証した結果、コードをほぼ変更することなく正常稼働したという。
会場は満員となり、移行時のポイントについて耳を傾けていた
ただし、一部シナリオでパフォーマンスの低下が見られたため、その点のみアプリケーション側のコード修正で対応した。具体的には、N+1のような実装をとっていた場合、一つひとつのクエリのレイテンシーの累計がWebの表示速度に影響を与えたことなどがあったとのことだ。なお、コスト面では、データベースの数が多い場合はDedicated、少ない場合はServerlessを利用するほうがよかったり、データベース移行には「DM（Data Migration）」ツールが有効だったりと、移行時の参考となる情報も共有された。
そして現在、これらの検証結果に基づき、TiDB Cloudへの移行を段階的に進めている。既存のAWSリザーブドインスタンスの契約期間を考慮し、契約満了を迎えたデータベースから順に移行しているという。
実際の移行では、DMでデータを移行した後にエンドポイントを切り替えるが、このとき移行するショップのスキーマを抜き出し、TiDBにテーブルを作った上でデータを移行している。TiDBでは、オートインクリメント（AUTO_INCREMENT）の挙動がMySQLとは異なるためだ。ecforceでは、IDの順番に意味を持たせているため、ひと手間加える形で対処している。
また、MySQL 5.7から8.0へのバージョンアップにともない、キャラクターセットの混在も課題となった。これに対応するため、TiDBでは8.0互換のレギュレーションを採用。このように配慮すべき点はあるが、MySQLの互換性に関する問題はほとんどなく、移行は順調に進んでいる。スケールアップ／ダウンの運用も問題なく、高負荷時の対応も実運用の中で経験することを想定しているという。
現状、350ほどのデータベースの約40％をTiDBへ移行した。このベースで移行が進めば、50％ほどのコスト削減が見込めるとのことだ。「TiDB Cloudへの移行によるメリットは大きくなりそうです。特に夜間の対応を減らせる点が一番良いところでしょう。MySQL互換の観点からも問題はなく、開発者の手を煩わせません」と田幸氏。データベース・インスタンスの集約もできるため、データベースを横断したデータ活用も進められそうだ。最後に田幸氏は「ecforceをご利用いただく事業者にも、より良いサービス体験を提供できそうです」と話し、TiDBのさらなる活用とecforceの発展を見据えるのだった。
出典：EnterpriseZine / DB Online – 「1,400超のショップ支えるecforceをTiDB Cloudに移行 一度OSS版断念もなぜ導入？」(2025年1月6日)」
