日本語が正しく表示されていなかったため修正版をアップロードいたしました。 https://www.slideshare.net/linecorp/linemysql-115766814

1. LINEのMySQL運用についてKentaro Kitagawa, IT service center - database department - db1 team
DB Tech Showcase 2018 2018/09/20

2. l 北川 健太郎 / Kentaro Kitagawa
l LINE株式会社
l IT Service Center - Database dept.- DB1 Team
l データベースエンジニア
l MySQL / Oracle Database / Redis
l MySQL道普請: http://gihyo.jp/dev/serial/01/mysql-road-construction-news
Introduction
@keny_lala

3. • About LINE
• History
• Operation of MySQL
• HA
• Monitoring
• Backup
• Next Step
Agenda

4. About LINE

6. ※2018年3⽉時点
7,600万⼈ 85%
国内ユーザー規模

8. About LINE Database

9. RDBMS
運用しているプロダクト
NOSQL

10. プロダクトの割合
Redis
43%
MySQL
38%
Cubrid
7%
HBase
5%
MongoDB
5%
SQL Server
1%
Oracle
Database
1%
MySQL
82%
Cubrid
15%
SQLServer
2%
Oracle Database
1%
RDBMS RDBMS + NOSQL

11. MySQL Versionの割合
5.7
32%
5.6
44%
5.5
21%
5.1
3%
MySQL

12. l データベース室 全体で17⼈
DBAについて
DB1 Team ・・Oracle, ElasticSearch
DB2 Team ・・ SQL Server
DB3 Team ・・MongoDB
BigDataPlatformTeam・・Hbase,Hadoop,Cubrid
MySQL
Redis

13. l MySQL の 構築
l スキーマ管理
l バックアップ・リカバリ
l Database ACL管理
l クエリチューニング
l 障害対応
l インデックス設計
l テーブル設計（依頼があれば）
l 運⽤ツールの作成
業務について

14. History

15. History
2015
MySQL 500+
DBA 8⼈
2011
LINE Release
MySQL 100+
DBA 5⼈
2017
MySQL 2000+
DBA 11⼈
2016
MySQL 1000+
DBA 10⼈
2018
MySQL 3000+
現在DBA 17⼈

16. History
2015
Redis Cluster
Redis Sentinel
2017
Hbase
Hadoop
2016
MongoDB
2018
Elastic
2011
MySQL
Oracle
Cubrid
SQL Server

17. l 2016年以降、MySQLが年間1000インスタンス規模で増えている
l 海外(台湾、タイやインドネシアなど)のサービスも⾯倒みている
l それらのサービスが急激に増えてきているよう
l 管理するプロダクトも増えつづけている
l 運⽤に⼿⼀杯の時期があった
l 最近、やっと⼈が増えてきて、新ソリューションの検証や運⽤ツール作成などに注⼒
できる
History

18. MySQL Operation

19. MySQL Operation
l 標準化 自動化することで運⽤を改善
l ⼤規模運⽤における苦労点
l 台数が急激に増えて管理が⼤変
l サービス数が多く、サービスごとにMySQLのバージョンやサーバスペックが異
なる
l ⼿動になっている運⽤に時間を取られる
l インストール ,Database ACL管理,スキーマ変更
l サービス担当者や開発者とのコミュニケーションコストが⾼い
l 複雑なDB構成によって、属⼈化して障害対応が24時間体制になってしまう

20. l 1 サーバ当たり１インスタンス
MySQL Operation
l MySQL Enterprise EditionとMySQL Community Editionを併⽤
l すべてOracle MySQLでフォークした製品はなし
l 同じマイナーバージョンで固定
l 最新のマイナーバージョンアップは基本なし。
l メジャーバージョンアップは積極的に⾏う。

21. l MySQLに最適化されたサーバースペック
l 基本的にすべてオンプレで物理サーバ、社内⽤のシステムには⼀部VM
l Low Spec ・・ HDD
l Mid Spec ・・ SSD
l High Spec ・・NVMe
MySQL Operation
l マスター/スレーブ/バックアップの３台が最⼩構成
l すべて同じHA構成
l さまざまな内製ツールを作成して、運⽤の⾃動化

22. l インストール⾃動化
MySQL Operation
AS-IS
⼿動インストール
TO-BE
⾃動インストール

23. 統合管理ツール

24. l DBAの統合管理ツール (通称 mondb+)
統合管理ツール
l すべてのDBエンジンに対応した内製の⼀元管理するツール
l WEB画⾯上で操作
l 各⾃欲しい機能を開発して、組み込む
l 以下のような項⽬が閲覧・設定可能
l サービス/インスタンス情報⼀覧
l ⾃動インストール
l ⾃動スレーブ追加
l Slow log 情報
l Backup 情報
l Real time QPS 情報
l アラート情報
l などなど…

25. l サービス/インスタンス情報
l サーバ情報
l MySQLバージョン
l 担当者
l ロール(マスターorス
レーブ)
l などなど
l フェールオーバされれば即
時で反映
統合管理ツール

26. ≈
l Slow log 情報(MySS)
l long_query_time=1
l 日単位の合計数を取得
l 時間別でも取得可能
統合管理ツール

27. l Real time QPS 情報
l コネクション数
l Com_xxx
l Slow_logの数
l Io_thread
l SQL_thread
l Second behind
master
l 等の情報を閲覧可能
統合管理ツール

28. l 以下情報を定期的に収集し、表⽰
l show engine innodb status
l show processlist
l show global variables
l show global status
l show slave status
l MySQL Enterprise Backup や xtrabackupの履歴テーブル
l データベースACL
統合管理ツール

29. l プライベートクラウド
l Verda DBS
l MySQLとRedisを提供
l VM／物理選択可能
l ある程度の権限を開発者に
もたせることで運⽤コスト
削減
l インスタンス作成
l Database ACL権限
l データベース作成
l sysスキーマの情報
プライベートクラウド

30. ≈
プライベートクラウド
l sys.statement_analysisの情報提供

31. MySQL Operation
l まとめ
l 統合管理ツールや⾃動化ツールで、運⽤を楽にしている
l プライベートクラウド
l インストールや権限追加などの運⽤コストの削減
l sys.statement_analysisでクエリの傾向を提供することやモニタリング画⾯を提
供することで、開発者とのコミュケーションコスト削減
l 属⼈化する対応をなくす
l スペックや構成を標準化したことでアラート対応を当番制へ。

32. MySQL HA

33. l とあるツールをベースにカスタマイズして使⽤中
l 本家はすでにメンテナンス終了。。
l VIP付け替え⽅式
l 準同期レプリケーション(semi-sync)
l スタンバイマスターへフェールオーバする
MySQL HA

34. l ⾃動フェールオーバ(マスターダウン)
l スレーブがスタンバイマスターにchange
master
l スタンバイマスターをread_only = off
l スタンバイマスターにVIPに付与
l ⼿動フェールオーバも可能
l MySQL バージョンアップ
l HW障害 / サーバリプレース
l インデックスやカラム追加
l 割と安定してるが、課題も多かった
MySQL HA

35. MySQL HA
l 課題
l VIP枯渇問題
l LINEのネットワーク設計の特性により、フェールオーバするサーバ間で
物理的制限がある
l マルチソースレプリケーション未対応
l 最近要望が多い。。
l 指定した1台のスレーブのみマスター昇格可能
l MHAのようにすべてのスレーブが昇格対象ではない。
l スレーブの数が多いとフェールオーバが遅い

36. MySQL HA
l 現状の解決
l VIP枯渇問題ー＞○
l DNS方式に改修することで、解決
l マルチソースレプリケーション未対応ー＞○
l 対応するように改修
l 指定した1台のスレーブのみマスター昇格可能ー＞△
l 設定ファイルを⾃動で変更する
l メンテナンスが大変。。HAソリューションの見直し時期！？

37. l InnoDB Cluster
MySQL HA
l Oracle推奨はMySQL RouterをAPサー
バと相乗り
l 数千？数万？台のAPサーバにMySQL
Routerをインストール…
l すべてのMySQL Routerの⾯倒を⾒るの
はちょっとつらい

38. MySQL HA
l Group Replication + DNS or InnoDB Cluster + DNS
l シングルプライマリーモードで運⽤
l 可⽤性はGroup Replicationで担保
l マスターの切り替わりを監視するモニターを⽤意して、DNS Recordを切り
替える
l 監視モニターにMySQL Routerを⼊れる
l 監視モニターがGroup Replication meta 情報をチェックする

39. MySQL Monitoring

40. l MySQL Enterprise Monitor
l 商⽤版のMySQLで使⽤可能
l MySQLのモニタリングであ
ればこれを⾒れば⼤丈夫
l Query Analyzerとか便利
MySQL Monitoring
l しかし、MySQL Community Edition もあるし、管理してるプロダクトはたくさんある・・

41. DBONE Project
MySQL
Enterprise
Monitor
Enterprise Monitor
Remin/Relumin
Cloudera
MMS
nPod
l Monitoringツールの乱⽴問題

42. l 複数のソリューションを統合的にモニタリングする仕組み
l 低コストで実現するために、16のOSSの組み合わせ
l 変更や新しいソリューションの追加を簡単にする
l サービス担当者にもわかりやすいUI、画⾯を共有することでコミュケー
ションコストを下げる
l Slack、メールやLINE notifyにアラート通知する
DBONE Project
Role Solution
Collector Prometheus exporter / td-agent
Stored Prometheus / Elastic Search
Display Grafana
Alert Alertmanager / alerta

43. ≈
DBONE Project

44. DBONE Project
DBONE for MongoDB
DBONE for MySQL
DBONE for Redis

45. DBONE Project

46. l MySQLの監視項⽬
l percona mysql exporterがベース
DBONE Project
l サーバのリソース監視(CPU / Memory / Disk / NW)
l コネクション数
l QPS
l インスタンス単位
l クラスター単位の合計
l スキーマ単位のテーブルサイズ合計
l InnoDB周り
l Performance_schema_xxx_lost
l たとえば、Performance_schema_digest_lostが増えていれば
events_statements_summary_by_digestに保存されない
l Temporary tablespaceサイズ

47. MySQL Backup

48. MySQL Backup
l 1st バックアップとして、デイリーでローカルにフルバックアップ取得
l 2nd バックアップとして、backup⽤storageへ転送する仕組み
LINE でのバックアップ

49. l MySQL Enterprise Backup(MEB)
l 商⽤版のMySQLで使⽤可能。
l xtrabackup
l percona社が開発したOSS
l xtrabackup2.3以降はinnobackupexでなくてもxtrabackupコマンドでMyISAM
のテーブルも取得してくれる
MySQL Backup
l MEBもxtrabackupもオンラインバックアップ
l 稼働中のMySQLに対して、停⽌することなくバックアップを取得
l アーキテクチャーはほぼ同じ
l トランザクション未対応のストレージエンジンはテーブルロック

50. MySQL Backup
l 数TBの⼤規模かつ書き込み量が多いデータベースが多数
l 1st バックアップのために、IO 帯域を考慮する必要
l 2nd バックアップのために、 NW 帯域を考慮する必要
l MEBをメインで使⽤していたが、インスタンス急増のためxtrabackupも導⼊
l 導⼊の際にIO制御の微妙な違いでハマった

51. l MEB
l --sleep オプション
l InnoDB テーブルから特定の量のデータをコピーした後に、スリープするミ
リ秒数を指定します。(単位MS)
l すでにsleep=200で設定して運⽤
MySQL Backup
l xtrabackup
l --throttle オプション
l 1MB単位での1秒当たりの⼊出⼒操作の数を制限します。(単位IO)
IO制御 オプション

52. Read/Write (MB) 実⾏時間
MEB(sleep=200) 76 5:13
throttle=0(no limit) 220 1:51
throttle=1 40 10:40
throttle=4 70 6:15
throttle=10 160 3:19
throttle=50 198 2:10
バックアップ処理時間
MySQLへの更新なし parallel 3, Database size 20G

53. 実⾏時間
MEB(sleep=200) 5:10
throttle=0(no limit) 2:14
throttle=1 永久に終わらない
throttle=4 永久に終わらない
throttle=10 永久に終わらない
throttle=50 16:06
バックアップ処理時間
MySQLへの更新ありQPS 2000 parallel 3, Database size 20G
why…..

54. MySQL Backup
1. バックアップ開始
2. InnoDBテーブルのコピー
1. InnoDB log file(トランザクションログ)とInnoDB table file(ibdファイル)をコ
ピーする
3. FLUSH TABLES WITH READ LOCK
1. InnoDB以外のテーブルをコピー
4. UNLOCK TABLES
5. バックアップ完了
どのようにバックアップが動くかざっくり説明

55. MySQL Backup
l MEB
l --sleepオプションはibdファイルのコピーにのみ有効
l xtrabackup
l --throttleオプションはibdファイルとトランザクションログにも有効
IO制御オプションの違った点
l MEB
l ibdファイルとトランザクションログを同時にコピー開始
l xtrabackup
l トランザクションログからコピー開始
l 最新の状態に追いつくまでコピーしつづける
l 追いついたらibdファイルのコピーを開始する
バックアップ開始時動作で違った点

56. MySQL Backup
l 原因
l throttleオプションでIO量を制限してトランザクションログをコピーするため、
更新が多い環境ではトランザクションログの最新の更新に追いつかない。
l よって、ibdファイルのコピーが開始できずにずっとトランザクションログ
のコピーをし続けていた状態であった。
l xtrabackupの場合はOSレイヤーで圧縮するようにしてIO制御することに変更
# xtrabackup --backup --stream=xbstream | pbzip2 -p${PLEVEL} > BACKUPDATA.bz2

57. Next Step

58. l MySQL8.0
l 導⼊に向けて、絶賛検証中
l Amazon AWS(RDS)
l データセンターを持たない海外案件の対応
Next Step
l バックアップ統合管理システム開発
l MySQL HA
l Group Replication + DNS

59. l MySQL Query Replayer 開発
l MySQLのネットワークパケットからクエリを取得し、リプレイする
l メジャーバージョンアップやハードウェアリプレースの負荷テストを⽬的
Next Step

60. l Operation
l 標準化と⾃動化することで運⽤が楽になった
l HA
l 現状安定はしているが、今後を考えると新しいソリューションの検討が必要
l Monitoring
l DBONE で統合監視が形になってきている
l Backup
l バックアップ統合管理システム開発
l OSS化に向けた運⽤ツール開発
l まだまだやりたいことはいっぱいある！
まとめ

61. LINE DBA 絶賛募集中!
https://linecorp.com/ja/career/position/23

62. QUESTIONS ?

63. THANK YOU