商品マイクロサービス移行の残課題

商品データベースのリファクタリングへの挑戦

Transcript

1. 1 商品マイクロサービス移行の残課題 商品データベースのリファクタリングへの挑戦 Business Platform Item Shin Ohno(ganchiku) 2021/12/16
2. 2 Shin Ohno(ganchiku) • 2020年6月、バックエンドエンジニアとして入社 • 2021年5月、ハンズオンも行うエンジニアリングマネージャーに 現在やっていること • 商品情報、商品画像のマイクロサービスのエンジニアマネージャー • モノリスアプリケーションの Kubernetes 移行 自己紹介
3. 3 商品データベースの今、昔 MySQL Monolith service Admin service Google Spanner Monolith service Admin service CloudSQL Microservices Item Microservice Microservice A Microservices Microservices Microservices B Big Query Big Table MySQL MySQL MySQL MySQL Monolith service Admin service MySQL MySQL
4. 4 Exclusive Data Ownership 商品データベースの改善と運用の課題 Scalable Database Migration Database Refactoring 02 03 01
5. 5 データは一つのサービスのオーナーが責任を持つという設計指針 • Why? ◦ データの変更がどこで行われたかを追いやすくするため ◦ データストア上の依存を疎結合にするため ◦ データオーナーによる一貫性を保つため Exclusive Data Ownership
6. 6 • 商品マイクロサービスからの書き込み、読み込み
 • モノリスアプリケーションからの書き込み、読み込み
 • 管理アプリケーションからの読み込み
 Exclusive Data Ownership 商品情報のケース items table Item microservice Admin service Monolith service C microservice B microservice A microservice
7. 7 MySQL からよりスケーラブルなデータベースへ移行 • Why? ◦ データの管理を各マイクロサービスのチームへ移行したい。 ◦ データがより大きくなっても、水平ににスケールしたい。 Scalable Database Migration
8. 8 Scalable Database Migration 商品情報のケース 見出し MySQLのキャパシティが問題 
 MySQLの管理がSRE 
 • 問題が起きたときSREに頼る 必要がある。
 • チームがオーナーとしてデー タの管理をするようにした い。
 • 累計出品数25億品以上 （2021年12月時点）の商品情 報
 • Item テーブルも巨大になり、 自前MySQLでは限界が見え てきた。
 
 • Google Spanner
 • TiDB
 • Something else?
 
 移行先DBのPoC（未決定） 

9. 9 ソースコードのリファクタリング データベースのリファクタリング 設定ファイルのリファクタリング • Why? ◦ 修正や追加開発に時間がとてもかかるようになる。 ▪ 使われなくなったカラムの存在意義がわからない ▪ 複数のドメインが一つのテーブルにまたがっていて、独立してない ▪ テーブルのデータが大きくなる Database Refactoring
10. 10 • 今まで
 ◦ descriptionカラムを移動
 ▪ (https://engineering.mercari.com/blog/entry/2017-11-29-161124/
 ◦ photo_[1-4]_updatedカラムを移動 
 ▪ https://engineering.mercari.com/blog/entry/20201211-55e3c90f44/
 
 • これから
 ◦ いいねのカウント、コメントのカウントなど
 ◦ 他にも取引に関する情報もリファクタリング
 
 Database Refactoring 商品情報のケース
11. 11 Exclusive Data Ownership 商品データベースの改善と運用の課題 Scalable Database Migration Database Refactoring 02 03 01