LINEのMySQL運用について

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

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

6. About LINE Database

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

8. プロダクトの割合 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

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

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

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

12. History

13. 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⼈

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

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

16. MySQL Operation

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

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

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

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

21. 統合管理ツール

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

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

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

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

26. 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 統合管理ツール

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

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

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

30. MySQL HA

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

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

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

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

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

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

37. MySQL Monitoring

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

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

40. 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

41. ≈ DBONE Project

42. DBONE Project DBONE for MongoDB DBONE for MySQL DBONE for Redis

43. DBONE Project

44. 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サイズ

45. MySQL Backup

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

47. 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 トランザクション未対応のストレージエンジンはテーブルロック

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

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

50. 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

51. 実⾏時間 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…..

52. 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. バックアップ完了どのようにバックアップが動くかざっくり説明

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

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

55. Next Step

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

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

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

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

60. QUESTIONS ?

61. THANK YOU

LINEのMySQL運用について

LINE Corporation

LINEのMySQL運用について