事例公開日：2022年7月14日
コスメ・美容の総合サイト「@cosme」を運営する株式会社アイスタイルは、長期間の運用によって蓄積した技術的課題の解消とビジネス成長のためオンプレミス環境から脱却し、AWS環境へフルクラウド化を目指す一大プロジェクトを実施している。そのプロジェクトをきっかけにDBの抜本的見直しを行い、メインDBをSQL ServerからTiDB Cloudへ移行することを決断した。Amazon RDS for SQL ServerやSQL Server on EC2、Amazon Auroraなどさまざまな選択肢が挙げられた中で、株式会社アイスタイルが求める要件をクリアできる唯一のDBがフルマネージドサービスであるTiDB Cloudだった。
株式会社アイスタイル T＆C開発センター第一開発本部
クラウドソリューション部 サービスインフラグループ 鈴木 利房 氏
データ移行の検証で、データ型によっては移行がうまく行かなかったのですが、PingCAPの担当者が問題点をすぐに突き止めてくれ、修正パッチを当ててくれました。対応の迅速さは、実運用が始めったときにも同じサポートを期待できると安心材料になりました。日本法人があり、日本語でサポートが受けられるメリットも感じています。」
さらなる成長のためにフルクラウド環境への移行を決断
株式会社アイスタイルは、日本最大級のコスメ・美容の総合サイト「@cosme（アットコスメ）」を運営している。化粧品のクチコミサイトとして1999年にスタートした@cosmeは、ユーザーの率直なレビューや売れ筋ランキング、肌質や年齢に応じた検索などによって、最適な商品購入をサポートする人気サービスとなっている。化粧品ブランドに対しては、ブランド認知から利用者獲得・ファン化などのマーケティングが展開できるプラットフォームを提供している。@cosmeはこのほかにも、ECサービスの「@cosme SHOPPING」や実店舗の「@cosme STORE」の運営を行い、美容領域のあらゆる物事に関わっている。
@cosmeを支えるインフラは、オンプレミス環境で運営していたが、2018年から開催されているECサイトのスペシャルイベント「@cosme BEAUTY DAY」以来、急激なアクセスによるスパイクにも耐えられるよう、AWSの利用を始めた。その後フルクラウド化の方針を打ち出し、2021年から段階的な移行を実施している。
設立当初のシステムがWindows中心だったこともあり、コアとなるRDBMS（リレーショナルデータベース）はSQL Serverである。事業の成長とともに増えたサブシステムは150を超え、非常に複雑化した状態になっていた。「クラウド化が決まったときに、技術的負債の解消も方針として掲げました。プロジェクト名は『Rebornプロジェクト』です」と語るのは、アイスタイル T＆C開発センターで、DBA（Database Administrator）を務める鈴木利房氏。従来環境では一部にメインストリームのサポートが終了した製品もあったため、クラウド移行にはシステムの改修が必要なことがわかっていた。
密結合となったデータベース 移行か再構築かの検討を行う
Rebornプロジェクトには、利用する技術の選定や方針を検討する「技術選定ワーキンググループ」がある。鈴木氏はこのグループでSQL Serverの利用方針を定める「SQL Server分科会」のリーダーとなり、移行に最適なデータベース（DB）を検討していった。
DBの課題について鈴木氏は「非常に密結合な状態なのです。複数台の更新系サーバーに30以上のDBがあり、DB間でテーブルを結合したり、テーブル単位のレプリケーションをしていたり、複数のDBからテーブルを集めて参照専用のDBを作ったり、全体で一つの巨大なデータベースのような状態となっているのです」と説明した。
これらの状況から、アプリケーション側の改修コストを最小化できるのは、新しい環境においてもSQL Server以外にはないと思われた。そこで鈴木氏は、DBエンジンは変えずにそのままクラウド化する方法として、Amazon RDS for SQL Server（RDS）を検討する。「しかし、RDSではレプリケーションをサポートしていないことがわかりました。そこで、EC2でのSQL Server構築を検討したのですが、ライセンス費用もあって、運用コストがかなり高額となることがわかりました」（鈴木氏）。
再びRDSでの構築を検討し、レプリケーションができなくても動作するよう、一つのRDSにすべてのデータベースを集約する検討を行った。必要なCPU数やメモリ数でサイジングをすると、上から3番目のインスタンスタイプが適切だとわかった。それについて鈴木氏は「あと2段階しかスケールアップできないのは問題だと思いました。上限があるのは運用面で非常に不都合だと感じました」と話した。
分散RDBMSの検討からTiDBへの移行を検討する
鈴木氏は、DBを一つに集約するという発想から、分散RDBMSの検討を始める。DBサーバーを物理的に分割するのでなく、DB内部が物理的に分割されているのであれば、レプリケーションをしなくても負荷分散できる。DB間の結合も可能となり、移行時のアプリケーションの修正を最低限にできると考えたのだ。
鈴木氏は、開発者向けのナレッジ共有サイトをきっかけに数年前からTiDBを知っていた。TiDBは、トラディショナルなRDBMSであるMySQLと互換性を持ちながら、柔軟に拡張できる特性を持つ。SQLを解釈するTiDBレイヤーと、データストアを担当するTiKVレイヤーで構成され、各レイヤーを需要に応じて拡張できるアーキテクチャーとなっている。
TiDBのアーキテクチャー
分散RDBMSの検討を始めた2021年9月頃、「TiDBについて調べると、数年前はなかった日本法人が2021年の4月に設立されていることを知りました。公式Slackに参加したところ、PingCAPの担当者から連絡があり、相談を始めました」（鈴木氏）
TiDBの検証は、スキーマ移行から始めた。SQL Serverから移行できないものもあったが、致命的なものはなかった。
データ移行の検証は、EmbulkとAWSのDMS（Database Migration Service）で実施した。鈴木氏は「DMSは特定のデータ型での移行はうまく行かなかったのですが、PingCAPの担当者が問題をすぐに突き止め、TiDBに修正パッチを適用しました。この対応の迅速さは、実運用が始めったときにも同じサポートを期待できるという安心材料になりました。分散RDBMSは海外製のものばかりですので、日本語でサポートが受けられることにメリットを感じたのです」と述べた。
アプリケーションの主な改修はSQLの移行となり、想定通りに進んだ。鈴木氏は「SQL文の構造自体は変更する必要がなく、関数などの修正で済むので、移行工数は低かったです」と振り返る。
パフォーマンスの検証では、APIの呼び出しとSQLの実行を測定した。分散RDBMSの特徴でもあるネットワークを介しての処理の為、レイテンシーが許容範囲に入るかが心配されたが、複雑な条件式のあるクエリでも、ほとんどのケースにおいて数十ミリ秒で応答があるため、自社のワークロードに合わせたサイジングさえ行えば問題ないと判断した。
TiDBには、分析処理を高速化する列指向型ストア「TiFlash」があるためトランザクション処理とリアルタイム分析クエリを両立できるという利点もある。アイスタイルで行われている社内向けデータ分析システムのクエリで検証したところ、従来のSQL Serverで30秒かかっている集計クエリが、1秒以下になるケースも見られた。
また、TiFlashの追加作業もワンクリックで済むため、ETLが必要なく使いたい時にすぐ追加できる事も良かった。
適所でTiDBを選択し、レガシーな環境から脱却
およそ1ヶ月の検証の結果、アイスタイルでは、TiDBは、SQL Serverから移行可能であると評価し、2023年の第四四半期を目処に移行を完了する計画だ。
システム構成図
ただし、DBMSは用途に応じて選択していく。特定のアプリケーションのみが利用する独立したデータベースの場合は、Amazon Auroraのほうがコストは低い。TiDBは、結合のあるDB群に対して活用するなどの使い分けをしていく。なお、TiDB のコストは、検討中に想定したEC2にSQL Serverを構築する場合と比較して、半分のコストで運用できると見込んでいる。
鈴木氏は、PingCAPに対して次のように評価した。
「手厚いサポートで無事にPoCを完了できました。驚いた点は、PingCAPのR&Dが非常に優秀で、非対応だったSJIS（文字コード）の対応も示してくれたことです。結果的にSJISは採用を見送りましたが、開発力と実装のスピードを肌で感じました。PoCで生じた要望に関する開発をお願いしており、実装を楽しみにしております」
参考情報：
@cosmeがレガシーシステムをクラウドネイティブDBに載せ替える理由 ー TiDB User Day 2022
[講演資料] [動画]
