楽天における大规模データベースの运用
1 like1,534 views
Rakuten Developer Meetup vol.03 大規模クラウドの仕組みと秘密 https://rakuten.connpass.com/event/254762/
More Related Content
What's hot (20)
Similar to 楽天における大规模データベースの运用 (20)
![[db tech showcase Tokyo 2014] C34:[楽天] 詳説 楽天のデータベースアーキテクチャ史 -シングルノードから仮想化フラッシ...](https://cdn.slidesharecdn.com/ss_thumbnails/dbtstokyo2014c34hardware-141211191008-conversion-gate01-thumbnail.jpg?width=560&fit=bounds)
![[db tech showcase Tokyo 2018] #dbts2018 #D15 『5年連続！第三者機関の評価で（圧倒的）最強のピュアストレージが...](https://cdn.slidesharecdn.com/ss_thumbnails/dbts2018d15pureiwamoto-181004233917-thumbnail.jpg?width=560&fit=bounds)
More from Rakuten Group, Inc. (20)
Recently uploaded (13)
![ElasticsearchでSPLADEする [Search Engineering Tech Talk 2025 Winter]](https://cdn.slidesharecdn.com/ss_thumbnails/searchtech-250228102455-ddc5ce09-thumbnail.jpg?width=560&fit=bounds)
楽天における大规模データベースの运用
- 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
- 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 トラブル対応?問い合わせ対応