LINEのMySQL運用について修正版

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

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

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

LINEのMySQL運用について修正版

※2018年3月時点
7,600万人 85%
国内ユーザー規模

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

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

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

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

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

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人

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

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

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

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

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

 インストール自動化
MySQL Operation
AS-IS
手動インストール
TO-BE
自動インストール

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

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

≈
 Slow log 情報(MySS)
 long_query_time=1
 日単位の合計数を取得
 時間別でも取得可能

 Real time QPS 情報
 コネクション数
 Com_xxx
 Slow_logの数
 Io_thread
 SQL_thread
 Second behind
master
 等の情報を閲覧可能

 以下情報を定期的に収集し、表示
 show engine innodb status
 show processlist
 show global variables
 show global status
 show slave status
 MySQL Enterprise Backup や xtrabackupの履歴テーブル
 データベースACL

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

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

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

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

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

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

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

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

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

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

DBONE Project
MySQL
Enterprise
Monitor
Enterprise Monitor
Remin/Relumin
Cloudera
MMS
nPod
 Monitoringツールの乱立問題

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

DBONE Project
DBONE for MongoDB
DBONE for MySQL
DBONE for Redis

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LINEのMySQL運用について修正版

Recommended

More Related Content

What's hot (20)

Similar to LINEのMySQL運用について修正版 (20)

More from LINE Corporation (20)