1.
楽天における大規模データベースの運用
Sep. 29th , 2022
Kenichi Saito
Database Section
Cloud Services Department
Rakuten Group, Inc.

2.
2
About Me
2002年 インフラエンジニア (前職)
• データセンター運用・セキュリティ・バックアップ管理
• 製薬・金融業向け
2007年 楽天中途入社 データベースエンジニア
• MySQL・Informix
• 楽天市場・オークション
2016年 データベースマネージャ
• MySQL・Oracle・NoSQL
• 楽天グループ全体のデータベースを管理
データベース課
シニアマネージャー
Kenich Saito ( 斉藤 健一 )

3.
3
CONTENTS
1. 楽天 DB History
2. 楽天 DBA チーム
3. DB アーキテクチャと運用

4.
4
CONTENTS
1. 楽天 DB History
2. 楽天 DBA チーム
3. DB アーキテクチャと運用

5.
5
データベースの歴史: 楽天市場受注DB
Atago
1997年、たったひとつのデータベースからスタート
https://www.youtube.com/watch?v=T5YvciRzeTQ
参考資料: RNN: Rakuten’s Office Relocation History

6.
6
Atago
Atago rms01
rms01
db000
db050
….
分離 DB
データベースの歴史: 楽天市場受注DB
1999年~2000年、増加するデータ量に対応するため、複数データベースに分割
• RDBMS : Informix
• 店舗IDによる Data Sharding

7.
7
transaction
• 2002/5 E10K(Sun Enterprise 10000) started running.
• 2002/10 SF15K(Sun Fire 15000) started running. E10K was replaced as standby.
• 2004/11 SF25K(Sun Fire 25000) started running. SF15K was replaced as standby.
• 2006/5 Total 4 SF25K machines run as primary database servers.
• 2007/11 SF25K CPU board Upgrade
データベースの歴史: 楽天市場受注DB
2年に１回のペースでサーバのスケールアップ

8.
8
BunriDB
Informix
M9000 Exadata X4 Exadata X8M
RISE DB
Oracle
RISE DB
Oracle
2010 2015 ~ 2016 2020
データベースの歴史: 楽天市場受注DB
脱 Informix HW EOSL

9.
9
DBaaS
パフォーマンス：◎
高可用性：◎
コスト：低
データベース・プラットフォーム
Inexpensive
Cost
Excellent
Performance
Exadata
パフォーマンス：◎
コスト：高
IaaS VM
パフォーマンス：
△
コスト：低

10.
10
データベース・プラットフォーム
CPSD customers Oracle Exadata
DBaaS
IaaS (VM)
MySQL PostgreSQL
Oracle
MySQL
Couchbase
MariaDB
Cassandra
Couchbase
Cassandra
Oracle
1,000 nodes
10 racks
4,000 VMs

11.
11
2. 楽天 DBA チーム
1. 楽天 DB History
3. DB アーキテクチャと運用

12.
12
楽天 DBA
Office
US: 2
France: 1
India: 18
Japan: 18

13.
13
Team Japan (18) India (18) US (2) France (1)
Management
(3)
2 1
DevOps
(18)
10 8
DBA : DBaaS
(8)
3 3 1 1
DBA : Oracle
(10)
3 6 1
楽天 DBA

14.
14
CONTENTS
3. DB アーキテクチャと運用
1. 楽天 DB History
2. 楽天 DBA チーム

15.
15
### Primary Only ### ### Primary + Read Replica ### ### Primary + Read Replica + Backup ###
Primary Primary
Read Replica
Read Replica
Primary
Read Replica
Read Replica
Backup
シングル DB 構成
楽天では、IaaS レイヤーで VM 機
能による冗長性を担保している
リードクエリのオフロード用に
レプリカを追加
負荷に応じてレプリカノードを
追加することでスケールアウト可能
バックアップ専用のレプリカを追加
バックアップによるディスク IO 負荷が
本番サービスに影響を出さないようにできる
DB トポロジー : Primary/Replica

16.
16
### MHA ###
Primary
Read Replica
Read Replica
Backup
Candidate Primary
VIP
Failed
Read Replica
Read Replica
Backup
New Primary
VIP
• MHA により、プライマリ DB 障害時に別のレプリカにフェイルオーバーが可能
• 既存のレプリカのレプリケーション設定も、新しいプライマリ DB に接続されるよう自動で変更される
• アプリケーションからのDB接続ポイントはフェイルオーバー後も同じため、設定変更は不要
DBトポロジー : Primary/Replica for HA

17.
17
• クラスタ構成によって、より洗練された
HA 機能が実現可能
• クラスタ内の 1ノードで障害が発生しても、
別のノードにより透過的にサービスが継続可能
• 楽天では、MariaDB + Galera Cluster で実装。
サーバは、物理サーバと VM をユーザが選択可能
DBトポロジー : Clustering Solution

18.
18
DC1 DC2
クラスタを複数データセンターに構築し
両者をデータレプリケーションすることで
データセンターをまたがったHA を実現
DBトポロジー : HA across multiple datacenter

19.
19
Migration Flow (MySQL on VM to MariaDB on DBaaS)
事前確認 MySQL 5.7 InnoDB
Binlog format
row
Supported
connectors
デプロイ Deploy DBaaS
with MariaDB
Validate
components
integrity
QA データ
移行
Dump on
MySQL
Restore on
DBaaS
Setup MySQL
→ DBaaS
replication
QA テスト
Test APP
Connector
parameters
Test
transaction
persistence
QA tests
本番 データ
移行
Dump on
MySQL
Restore on
DBaaS
Setup MySQL
→ DBaaS
replication
メンテ計画 Maintenance
time FIX
Schedule
adjustment
移行メンテ Service
stop
MySQL VM
becomes
read_only
Stop
replication
Disable
read_only on
DBaaS
Apps switch to
DBaaS
Service
restart
移行後作業 MySQL VM
Stop
DBA
APP チーム
DBA
DBA & APP チーム
DBA
トラブル対応・問い合わせ対応