@cosmeのTiDB採用までの道のり

@cosmeのTiDB採用までの道のり

自己紹介 鈴木 利房 # 所属 株式会社アイスタイル T&C開発センター 第1開発本部クラウドソリューション部 サービスインフラグループ DBREチーム # 主な役割 データベース構築・運用、クエリレビュー、テー ブル設計レビューなど ©︎ istyle Inc. No.1

会社紹介 アイスタイルは、クチコミDBを軸にした「@cosme」１メディアからスタート 現在、MAU1,900万人※の日本最大のメディアに成長し、クチコミ以外のDBも拡充し 事業領域も、リアル店舗・EC・グローバルメディア展開まで拡大 @cosme クチコミ 各事業実績 2,000万件突破予定 ＠cosme 2024年 @cosme25周年 @cosme クチコミ 1,000万件突破 ‐‐ 月間ユニークユーザー 1,900万人 2023年 フラッグシーップ2号店オープン （@cosme OSAKA） @cosme クチコミ 500万件突破 2020年 フラッグシップ 1号店オープン （@cosme TOKYO） 2018年 リテール事業拡大期突入 (@cosme BEAUTYDAY初開催) 2012年 グローバル事業開始 2007年 店舗事業開始 (@cosme 2002年 EC事業開始 (@cosme STORE 1号店 新宿にオープン) SHOPPINGオープン) リテール ー 店舗数 合計36店舗 ー 流通総額 EC＋店舗 合計292億円 グローバル ー 6か国展開 ※ 各国状況に合わせ展開 1999年 @cosmeオープン ※数値は2023年6月時点 No.2

アイスタイルグループの事業・サービス 美容に関するモノ・コト・ヒトが集まる仕組みを作り膨大なデータベースを創造し ビューティー領域において、様々な分野で一気通貫のサービスを提供しています Beauty Service事業 On Platform事業 MAU1,900万人20~30 代女性の過半数が毎月 利用する日本最大の美 容情報メディア。 広告・メディア 会員嗜好性にあわせた コスメを選別して毎月 届けする会員制サブス プリクションサービス 美容特化型のPRスペ シャリスト集団。プレ スイベントからデジタ ルPRまで幅広くサポー ト。 Youtuberを中心とし たインフルエンサー マーケティング事業 サンプリング PR インフルエンサー 取扱商品約47,000件。 @cosmeデータを活用 @cosme STOREの新 日本No.1の化粧品取扱 した、来店客数日本 形態！体験型フラッグ 数の“化粧品特化型EC No.1の化粧品専門店。 ショップ。国内外約 プラットフォーム” 全国25店舗※運営。 5~600ブランドが終結 ※＠cosmeTOKYO含む 化粧品EC 店舗 その他 Global事業 （台湾） 中国 香港 台湾 韓国 アメリカ 中国・香港・韓国では化粧品ECサイト、台湾・アメリカ・韓国では現地No.1の 化粧品レビューサイトの運営など、国毎にチューニングした 海外地域の美容総合メディアを姉妹メディアとして展開。 海外メディア事業・海外EC事業 ©︎ istyle Inc. 中国 香港 国毎にチューニングし た海外店舗展開。 2022年10月中国海南 島の免税店にOPEN 海外店舗 アジア圏を中心に、世 求人メディア運営、人材 界各国へ向けた化粧品 紹介・派遣、店舗運営代 の輸出事業＆グローバ 行など、美容人材に特化 ルマーケティング事業 した人材サービス 海外卸売 人材サービス ※数値は2023年6月時点 No.3

アイスタイルグループの事業・サービスを支えるシステム • 150以上のシステム • 数百台のDBサーバー • SQL Server • MySQL ©︎ istyle Inc. No.4

アイスタイルでのNewSQL採用状況 異機種移行事例 • SQL ServerからTiDBへ移行 同機種移行事例 • 複数のMySQLをTiDBへ集約 ©︎ istyle Inc. No.5

異機種移行事例 SQL ServerからTiDBへ ©︎ istyle Inc. No.6

異機種移行の背景 オンプレからAWSへの移行にあたり、SQL Serverをどうするかが議論 になった • 使い続けるのか • 別のDBMSに乗り換えるのか • 乗り換えるとしたら、乗り換え先はどれにするのか ©︎ istyle Inc. No.7

異機種移行の要件 SQL Server上の複数のDBは、アプリケーションが相互に共有利用し ており、物理的にサーバーが分かれている事の方が不自然な状態に なっていた • 異なるDBでのJOIN、異なるサーバー間でのJOINできる機能が必要 • 全てのDBをひとつのクラスターで運用でき、スケーラビリティの問 題が出ないことが望ましい ©︎ istyle Inc. No.8

異機種移行でTiDB採用の理由 全てのDBをひとつにまとめても、問題なく動いて、無制限のスケーラ ビリティがある。そしてほどほどの価格。そんなRDBMSが必要でした。 RDBMS 異なるDB間の テーブルJOIN 異なるサーバー 間の テーブルJOIN マネージドサー ビス スケーラビリ ティ 費用 SQL Server （EC2） RDS for SQL Server RDS Aurora MySQL TiDB ©︎ istyle Inc. No.9

同機種移行事例 MySQLからTiDBへ ©︎ istyle Inc. No.10

同機種移行の背景 MySQLからのAWS移行はAurora MySQLを選択していたが、いくつか 問題を感じていた 1. 相対的にコストが高い 2. 強制バージョンアップが存在する 3. バージョンアップ時に、更新ができない時間が発生する ©︎ istyle Inc. No.11

相対的にコストが高い • システム内でAuroraのコストが突出してしまう • 価格の安いTインスタンスクラスは、本番利用が非推奨 • Rインスタンスクラスを選ぶと、オーバースペックになる場合がある • 冗長構成を取ると当然2倍の金額が必要 • このため、社内向けシステムではシングル構成で運用する事例が出て きた ©︎ istyle Inc. No.12

強制バージョンアップが存在する • 強制的にバージョンアップを強いられることが結構ある • 自動バージョンアップまでの猶予期間が短いケースもある • クラスター数が増えてくると、バージョンアップ作業にうんざりする ©︎ istyle Inc. No.13

バージョンアップ時に、更新できない時間が発生する • 残念ながら、Aurora ブルー/グリーンデプロイでも書き込み遮断が発 生する • 更新ができないとサービスを止める必要があり、実施タイミングを調 整する必要がある • 年に何度もサービスを止められない ©︎ istyle Inc. No.14

TiDB採用の理由 • 高コスト対策 • 複数のMySQLをひとつのTiDBクラスターにまとめる事で、トータルコストを下げつ つ、冗長構成も諦めない事が可能 • リソース制御を使って、特定ユーザーがリソースを使いすぎないよう制限できる • 強制バージョンアップ対策 • TiDBには強制バージョンアップがない（サポート確認済み） • バージョンアップ時の更新不能対策 • ローリングアップデートで無停止バージョンアップが可能 ©︎ istyle Inc. No.15

移行の実際 ©︎ istyle Inc. No.16

SQL ServerからTiDBへ 現在、移行の計画段階 • データ移行はAWS DMSを利用予定 • 本番切り替え前の常時同期も、AWS DMSを利用予定 • TiDBからSQL Serverへの書き戻しはChangefeed、Aurora、DMSの 組み合わせがを利用予定 • 移行前後のデータ比較はAWS DMSを利用予定 ©︎ istyle Inc. No.17

MySQLからTiDBへ ツールが揃っているため、移行がやりやすい • データ移行はdumplingとTiDB Cloudのimportを利用 • 本番切り替え前の常時同期は、DMを利用予定 • TiDBからMySQLへの書き戻しは、TiCDCを利用予定 • 移行前後のデータ比較は、sync-diff-inspectorを利用予定 ©︎ istyle Inc. No.18

まとめ ©︎ istyle Inc. No.19

まとめ • NewSQLの採用は、もはや冒険ではない • 周辺ツールが充実しており、同機種移行であれば移行も容易 • 登場から数年を経て、機能向上が著しい ©︎ istyle Inc. No.20

おしまい 積極採用中です！ https://www.istyle.co.jp/recruit/ ©︎ istyle Inc. No.21

• https://www.istyle.co.jp/recruit/