Contenu connexe Similaire à LINEのMySQL運用について 修正版 (20) Plus de LINE Corporation (20) LINEのMySQL運用について 修正版2. 北川 健太郎 / 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
3. • About LINE
• History
• Operation of MySQL
• HA
• Monitoring
• Backup
• Next Step
Agenda
12. データベース室 全体で17人
DBAについて
DB1 Team ・・Oracle, ElasticSearch
DB2 Team ・・ SQL Server
DB3 Team ・・MongoDB
BigDataPlatformTeam・・Hbase,Hadoop,Cubrid
MySQL
Redis
13. MySQL の 構築
スキーマ管理
バックアップ・リカバリ
Database ACL管理
クエリチューニング
障害対応
インデックス設計
テーブル設計(依頼があれば)
運用ツールの作成
業務について
19. MySQL Operation
標準化 自動化することで運用を改善
大規模運用における苦労点
台数が急激に増えて管理が大変
サービス数が多く、サービスごとにMySQLのバージョンやサーバスペックが異なる
手動になっている運用に時間を取られる
インストール ,Database ACL管理,スキーマ変更
サービス担当者や開発者とのコミュニケーションコストが高い
複雑なDB構成によって、属人化して障害対応が24時間体制になってしまう
20. 1 サーバ当たり1インスタンス
MySQL Operation
MySQL Enterprise EditionとMySQL Community Editionを併用
すべてOracle MySQLでフォークした製品はなし
同じマイナーバージョンで固定
最新のマイナーバージョンアップは基本なし。
メジャーバージョンアップは積極的に行う。
24. DBAの統合管理ツール (通称 mondb+)
統合管理ツール
すべてのDBエンジンに対応した内製の一元管理するツール
WEB画面上で操作
各自欲しい機能を開発して、組み込む
以下のような項目が閲覧・設定可能
サービス/インスタンス情報一覧
自動インストール
自動スレーブ追加
Slow log 情報
Backup 情報
Real time QPS 情報
アラート情報
などなど…
26. ≈
Slow log 情報(MySS)
long_query_time=1
日単位の合計数を取得
時間別でも取得可能
統合管理ツール
27. Real time QPS 情報
コネクション数
Com_xxx
Slow_logの数
Io_thread
SQL_thread
Second behind
master
等の情報を閲覧可能
統合管理ツール
28. 以下情報を定期的に収集し、表示
show engine innodb status
show processlist
show global variables
show global status
show slave status
MySQL Enterprise Backup や xtrabackupの履歴テーブル
データベースACL
統合管理ツール
29. プライベートクラウド
Verda DBS
MySQLとRedisを提供
VM/物理選択可能
ある程度の権限を開発者に
もたせることで運用コスト削
減
インスタンス作成
Database ACL権限
データベース作成
sysスキーマの情報
プライベートクラウド
31. MySQL Operation
まとめ
統合管理ツールや自動化ツールで、運用を楽にしている
プライベートクラウド
インストールや権限追加などの運用コストの削減
sys.statement_analysisでクエリの傾向を提供することやモニタリング画面を提供する
ことで、開発者とのコミュケーションコスト削減
属人化する対応をなくす
スペックや構成を標準化したことでアラート対応を当番制へ。
35. MySQL HA
課題
VIP枯渇問題
LINEのネットワーク設計の特性により、フェールオーバするサーバ間で物理
的制限がある
マルチソースレプリケーション未対応
最近要望が多い。。
指定した1台のスレーブのみマスター昇格可能
MHAのようにすべてのスレーブが昇格対象ではない。
スレーブの数が多いとフェールオーバが遅い
36. MySQL HA
現状の解決
VIP枯渇問題ー>○
DNS方式に改修することで、解決
マルチソースレプリケーション未対応ー>○
対応するように改修
指定した1台のスレーブのみマスター昇格可能ー>△
設定ファイルを自動で変更する
メンテナンスが大変。。HAソリューションの見直し時期!?
37. InnoDB Cluster
MySQL HA
Oracle推奨はMySQL RouterをAPサーバ
と相乗り
数千?数万?台のAPサーバにMySQL
Routerをインストール…
すべてのMySQL Routerの面倒を見るの
はちょっとつらい
38. MySQL HA
Group Replication + DNS or InnoDB Cluster + DNS
シングルプライマリーモードで運用
可用性はGroup Replicationで担保
マスターの切り替わりを監視するモニターを用意して、DNS Recordを切り替える
監視モニターにMySQL Routerを入れる
監視モニターがGroup Replication meta 情報をチェックする
40. MySQL Enterprise Monitor
商用版のMySQLで使用可能
MySQLのモニタリングであれ
ばこれを見れば大丈夫
Query Analyzerとか便利
MySQL Monitoring
しかし、MySQL Community Edition もあるし、管理してるプロダクトはたくさんある・・
42. 複数のソリューションを統合的にモニタリングする仕組み
低コストで実現するために、16のOSSの組み合わせ
変更や新しいソリューションの追加を簡単にする
サービス担当者にもわかりやすいUI、画面を共有することでコミュケーションコ
ストを下げる
Slack、メールやLINE notifyにアラート通知する
DBONE Project
Role Solution
Collector Prometheus exporter / td-agent
Stored Prometheus / Elastic Search
Display Grafana
Alert Alertmanager / alerta
46. 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サイズ
48. MySQL Backup
1st バックアップとして、デイリーでローカルにフルバックアップ取得
2nd バックアップとして、backup用storageへ転送する仕組み
LINE でのバックアップ
49. MySQL Enterprise Backup(MEB)
商用版のMySQLで使用可能。
xtrabackup
percona社が開発したOSS
xtrabackup2.3以降はinnobackupexでなくてもxtrabackupコマンドでMyISAMの
テーブルも取得してくれる
MySQL Backup
MEBもxtrabackupもオンラインバックアップ
稼働中のMySQLに対して、停止することなくバックアップを取得
アーキテクチャーはほぼ同じ
トランザクション未対応のストレージエンジンはテーブルロック
51. MEB
--sleep オプション
InnoDB テーブルから特定の量のデータをコピーした後に、スリープするミリ秒数を
指定します。(単位MS)
すでにsleep=200で設定して運用
MySQL Backup
xtrabackup
--throttle オプション
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
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
MEB
--sleepオプションはibdファイルのコピーにのみ有効
xtrabackup
--throttleオプションはibdファイルとトランザクションログにも有効
IO制御オプションの違った点
MEB
ibdファイルとトランザクションログを同時にコピー開始
xtrabackup
トランザクションログからコピー開始
最新の状態に追いつくまでコピーしつづける
追いついたらibdファイルのコピーを開始する
バックアップ開始時動作で違った点
56. MySQL Backup
原因
throttleオプションでIO量を制限してトランザクションログをコピーするため、更新が
多い環境ではトランザクションログの最新の更新に追いつかない。
よって、ibdファイルのコピーが開始できずにずっとトランザクションログのコピーを
し続けていた状態であった。
xtrabackupの場合はOSレイヤーで圧縮するようにしてIO制御することに変更
# xtrabackup --backup --stream=xbstream | pbzip2 -p${PLEVEL} > BACKUPDATA.bz2
58. MySQL8.0
導入に向けて、絶賛検証中
Amazon AWS(RDS)
データセンターを持たない海外案件の対応
Next Step
バックアップ統合管理システム開発
MySQL HA
Group Replication + DNS
59. MySQL Query Replayer 開発
MySQLのネットワークパケットからクエリを取得し、リプレイする
メジャーバージョンアップやハードウェアリプレースの負荷テストを目的
Next Step
60. Operation
標準化と自動化することで運用が楽になった
HA
現状安定はしているが、今後を考えると新しいソリューションの検討が必要
Monitoring
DBONE で統合監視が形になってきている
Backup
バックアップ統合管理システム開発
OSS化に向けた運用ツール開発
まだまだやりたいことはいっぱいある!
まとめ
Notes de l'éditeur LINEのMySQLの運用についてということで、
今までほとんど世に出てなかったLINEのデータベース事情全部公開したいと思います。
一歩的にしゃべてるとテンション下がってくので、途中でどんどん質問してください
はい、では始めます。 まず、自己紹介です。北川と申します、LINE株式会社に所属しているデータベースエンジニアです。
担当は主にMySQLとOracle Redisです。Twitterは以下 本日お話するアジェンダです。
まず、About LINEということで、LINE社についてとLINEでのデータベースやDBAについて紹介します。
その後はDBチームのヒストリー
MySQLのオペレーションについて、
どうやってHAやモニタリング、バックアップについて話します。
最後にnext stepとして現在進行中のプロジェクトなどお話したいと思います。 まずは、LINE社ついて、簡単に説明させていただきます。
LINEでは、「CLOSING THE DISTANCE」という言葉をミッションに掲げています。
人と人はもちろんのこと、人と情報、サービス、企業、ブランドなど、
人々が必要とするものとの距離を縮め、心地よいものにするという思いが込められています、
コミュニケーションアプリ「LINE」の国内のユーザー規模です。
月間利用者数は、7,600万人以上となっており、
スマートフォン利用者のほとんどの方に「LINE」をご利用頂いています。
特徴的なのは、エンゲージメントの高さです。
月に1回以上「LINE」を利用する方のうち、85%もの方が毎日「LINE」をご利用頂いています。
日常的に利用頂き、インフラ的なサービスになりつつあります。 LINE社ではLINEを入り口として様々なサービスを展開しています。
LINEが単純な入り口になるだけでなく、それぞれのサービスでスマートフォンでの使いやすさを追求し、
LINE上の人のつながりを活用することで、
ユーザーに支持される、各国でトップクラスのサービスをいくつも創ってまいりました。
我々はこれを「スマートポータル戦略」と呼んでいます。
特に重要な3つの事業
コア事業である「広告」と、戦略事業である「フィンテック」、「AI」となっています。
これらのほとんどのサービスでMySQLを使用しています。 つづいて、LINEのデータベースとチームについて紹介します。 現在うちのチームで運用しているプロダクトです。LINEマンガやLINEライブやゲームなどほとんどのLINEサービスのRDBMSとNOSQLを管理しています。
RDBMSでいうと。
Cubridって知ってる?
韓国のNavar社で開発されているRDBMSです。
特徴としてautosharding機能を持っていて、簡単にシャードできるというすごいDBです。
パフォーマンス面でやや他のRDBMSと劣る部分があるのと管理できる人が少ないので、直近では積極的に導入はしてないという現状です。
つづいて、NOSQLです。
これらの計8つのプロダクトを管理しています。 つづいて、プロダクトの割合です。
RDBMSだけで見てみると。
RDBMSとNOSQLのインスタンス数ですが、
REDISとMySQLを合わせると81%を占めています。
なんで、LINEのサービスはほとんどがRedisとMySQLで構成されているのがわかります。 MySQL versionの割合です。
MySQL5.7が32%で新規サービスはすべて5.7をインストールしています。
一番多いのMySQL5.6で44%, MySQL5.5 21%
5.1が3%ほど残っていて、現在version upするprojectが進行中です。
あと、LINEはいくつかの会社が合併してできているので、我々の管理していないMySQL群がいくつかあるようで、その中に百台規模のMySQL4.0が眠っているとの噂は聞いたことがあります。 つづいて、DBAについてです。
現在データベース室という部署に所属していて、その中にDBAは17人います
最近チームが分かれました。
DB1 2 3 bigdataplatformと4つのチームがあります。
まず
全チームは共通してMySQLとRedisの運用を行います。
あとはチームごとでそれぞれ異なるプロダクトを管理しています。
私の所属している1 teamはMySQL, Redis と Oracle es
2 teamはプラスでSQL Serverこのチームは韓国に所属してます, 3teamはmongo DB, BIgData は主にHbaseとHadoop。そして、cubridとなっています。 普段はどういうことしているのかというと、一般的なDBAのタスクをしてます。
テーブル設計は基本的にはサービス開発者側で行われることが多いです。
こういった業務を日々行っています。
10分ぐらい DBAの人数とMySQLのインスタンス数の推移なんですが、
2011年 - コミュニケーションアプリ LINEがリリースされたとき、DBAが5人でMySQLの100インスタンスたったようです。
情報としては残ってなかったんですが、古き方から聞いた情報です。
そこから飛んで、2015年このへんから情報がありました。
2015年 DBA 8人でMySQL 500インスタンスぐらい
2016年 DBA 10人でMySQL 1000インスタンスぐらい。これくらいのときに私が入社しました
2017年 DBA 11人でMySQL 2000インスタンスぐらい
この時期はDBAの人数は増えないんですが、インスタンス数はどんどん増えてる時期です。
2018年 DBA 17人で現時点でMySQL 3000インスタンスぐらい
一人あたり、200インスタンスぐらい管理しています。
うちのチームが管理するようになったプロダクトのヒストリーです。
NOSQLの管理するプロダクトが増えてきています。 今回調べて驚きました。そんなに増えてるのかと。。
こういった歴史がありました。
3 min LINEのように台数の多い運用をしていると困ることが多いと思います。
サービスが多いとそれぞれ開発者も異なるので、それぞれ連絡してみたいに、コミュケーションコストが高かったり。
カスケードレプリとかreplication do –tableであったり、
そういったことをLINEでは標準化 自動化することで運用を改善してます。
それらについて紹介したいとも思います。
MySQLについてです。
使い分けに明確な決まりはないですが、基本はcommuntyで、thread poolであったり導入したいときはenterpriseを使ってます
たとえばbug踏んでバージョンアップが必要な場合は最新のマイナーではなく基本メジャーバージョンアップします 物理サーバですが、MySQLに最適化された3つのスペックが用意されていて。
この中から選ぶという方法になります。 その中でたとえば、インストールの自動化があります。
今まではインストール前の事前チェックやmysqlインストール。。といった
手作業になっていた初期インストールをancibleを使用して、全て自動でインストールする仕組みなっています。
Redis cluster/hbase/mongodb elasticserchもインストールの自動化 そういった自動化ツールを動かすための統合管理ツールがあります。
自動スレーブ追加。これもansibleを使用しています。
その中からいくつか紹介します。 先程のダッシュボード画面からサービスの情報をベースにそれに紐づくサーバ一覧を見れます。
Long query time=1で運用しています。
サービス全体のslowlogを集計したり、
インスタンスごとの集計も確認できます。
特定の時間帯の集計情報を閲覧することできます。 サービス全体のMySQLインスタンスのrealtime QPS情報が見れます。
これが結構便利で、スマホからでも見れますし。
サービスによっては
かなりサーバ台数なので、アラートがなったらまずこれ見て状態を確認する。
そういった使い方をしています。 高負荷時だった情報を確認しようとすると取れてないことも多いですが。 あとは、LINEには社内に迅速にサーバ届けるために、開発しているオープンスタック基盤のプライベートクラウドもあります。
VerdaDBSと呼ばれていて、 このプライベートクラウドとも連携しています。
開発者がAWSのRDSのように簡単使えるようになっていて、DBAを介さずにインスタンス生成可能。
運用コスト削減
まだ、リリースされて間もないので、これから機能が追加予定 sysスキーマの情報とありましたが、
sys.statement_analysisを画面上に提供しています。
クエリの傾向など直接開発者が確認できるようにしています。 10 min つづいてMySQL HAです。どのようにHAしてるか紹介します。
画面にあるようにモニターがMySQLをヘルスチェックをして、マスターを切り替える方式。 簡単に自動フェールオーバに仕組みですが、
モニターがマスターのダウンを検知して、
まず、スレーブ群がスタンバイマスターに対してchange masterします。
スタンバイマスターのread_onlyをOFFにして、
VIPをつけるという流れでフェールオーバします。
あと、手動でのフェールオーバもできます。
動きとしては現在のマスターに対して、read_onlyをonにして接続中のセッションをkillしてVIPを外します。
その後は自動フェールオーバの仕組みと同様です。
この手動フェールオーバがよく使います。
たとえば、MySQLバージョンアップです。Slaveだけ先にバージョンアップして、手動フェールオーバする
オンラインDDLができれば、それでいいんですが。
デカ目のテーブルに対してのインデックス追加やカラム追加のときにも使用します。
このHAツールなんですが、今は割と安定してるのですが、昔は課題も多かった どういった課題があったかというと。
サーバ台数が増えすぎて、VIPが単純に枯渇
LINEのネットワーク設計の特性により、フェールオーバするサーバ間で物理的制限がある
これがいつもサーバチームを悩ませてしまっていました。 設定ファイルを自動で変更して、モニタープロセスを再起動させてます。あまりかっこいいやり方ではないので、直したいところです。
というわけで、MySQLの新機能に対応させるためなどメンテナンスが大変です。現状このHAツールの改善で稼働してるのは私だけなので、つらい。
HAソリューションの再検討が必要になってきました。 5 つづいてMySQL Monitoringです。どのようにモニタリングしてるか紹介します。 まずはMySQL EnterpriseMonitorです
Enterprise Editionの場合はこちらを使用しています。
MySQLのモニタリングであればこれを見れば間違いないです。
あと、Query analyzerとか便利です。
特定の期間のSQLを抽出して、そのとき多かったクエリの状況を確認できます。
Master-slaveの合計値も同時見れる。特定のクエリがマスターに寄ってるとか、簡単に出せるので便利です。
というようにMySQL Enterprise Monitorで満足なんですが、
MySQL Community Edition もあるし、管理してるプロダクトはたくさんある といったようにモニタリングツールが乱立して、障害とか開発側からこのときの負荷状況どうだった、聞かれたときにスムーズに見れなかった。 それを改善するために、統合的に監視する目的でDboneというプロジェクトがあります。
内部としては簡単にいうと、プロメテウスとgrafanaです。 ダッシュボード画面です。各プロダクトごとに選択できるようになってます。 モニタリング画面はこんな感じです。
統一されたUIで見やすくなってます。 各種Exporter => プロメテウス =>grafana
exporterインストールなどにancible
プロメテウスやelasticsearchのhelth check用にconsul
一つのシステムを構成しています。 DBONEでのMySQLの監視項目です。
InnoDB周りの情報など、一般的な監視項目は網羅されています。
あと、変わった監視としては、
5 min この仕組みで長年運用してきました。 バックアップにつかっているツールですが、
Enterorise editionであれば、Enterprise backup(MEB). Comminty editionであればxtrabackupを使用しています。
LINEでは数TBの大規模なデータベースであったり、書き込みの多いデータベースを数多く存在しています。
バックアップにはいろいろ考慮する点が多くて、
1st
2nd
Xtrabacupにも似たようなオプションがあって。
スロットルオプションを使用してIOを制御しようと考えてテストしました。 まずMySQLへの更新がない状態でテストした結果です。
データベースサイズは20Gほどで、MEBであればReak/writeのIOが76MBで5分ほどで完了しました。
Xtrabackupのほうでいくつかスロットルオプションを試して、スロットル4のときに同等の値がでたので、これでいけるかなと考えてました。 つぎに先程のデータベースに対してMySQLへの2000QPSほどで更新がある状態でテストした結果です。
MEBであれば先程と同じぐらい5分ほどで完了しました。
ただxtrabackupのほうは永久に終わらない状態がつづいたり、50に設定しても16分もかかるという結果でした。
ということでこれの原因ついていろいろ調べました。
まずその前にMEBとxtrabackupがどのようにバックアップを取得するかのざっくり説明します。
基本的にはこの流れです。
リストアするのには不完全なinnodbファイル群をクラッシュリカバリの仕組みでリカバリしていくという流れです。 まずIO制御のオプションで若干違いがありました。
あとはバックアップ処理開始直後の処理でも違いがありました。 Mebとxtrabackup併用するときは気をつけてねって話でした。
5 min 最後にnext stepとして、進行中のプロジェクトなど紹介して終わります。 先程話したようにLINEでは基本オンプレなんですが、データセンター…のためにRDSの運用も検証中です。
きっとここにはRDSの運用詳しい方多いと思うので、あとで教えてください。
管理してるプロダクトのすべてのバックアップを管理するシステムも開発中 MySQLueryreplay というものを今開発しています。
これはMySQLのネットワークパケットからクエリを取得して、ターゲットサーバに対して同じ並列度でリプレイするというものです。
Oracleのデータベースリプレイのようなものでしょうか。
更新はレプリケーションで、selectだけリプレイするとかならあると思うんですが、これは更新クエリもすべてキャプチャーして数秒遅らせることで、同じ並列度ですべてリプレイさせようというチャレンジなツールです。
できあがれば、来年のこの場所でこれについて発表したいです。
5min OSSにお世話になってるので、OSSへ貢献できるように運用ツールの開発も進んでます。
5min ぜひ興味があれば、ここをクリックするかツイッターでもいいですし私に話しかけてください。