LINEのMySQL運用について
30 likes•3,164 views
日本語が正しく表示されていなかったため修正版をアップロードいたしました。 https://www.slideshare.net/linecorp/linemysql-115766814
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
- 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
- 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⼈
- 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 さまざまな内製ツールを作成して、運⽤の⾃動化
- 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スキーマの情報 プライベートクラウド
- 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