Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

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

14 317 vues

Publié le

日本語が表示されない部分があったため再アップロードいたしました

Publié dans : Technologie
  • Soyez le premier à commenter

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

  1. 1. LINEのMySQL運用についてKentaro Kitagawa, IT service center - database department - db1 team DB Tech Showcase 2018 2018/09/20
  2. 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. 3. • About LINE • History • Operation of MySQL • HA • Monitoring • Backup • Next Step Agenda
  4. 4. About LINE
  5. 5. ※2018年3月時点 7,600万人 85% 国内ユーザー規模
  6. 6. About LINE Database
  7. 7. RDBMS 運用しているプロダクト NOSQL
  8. 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. 9. MySQL Versionの割合 5.7 32% 5.6 44% 5.5 21% 5.1 3% MySQL
  10. 10.  データベース室 全体で17人 DBAについて DB1 Team ・・Oracle, ElasticSearch DB2 Team ・・ SQL Server DB3 Team ・・MongoDB BigDataPlatformTeam・・Hbase,Hadoop,Cubrid MySQL Redis
  11. 11.  MySQL の 構築  スキーマ管理  バックアップ・リカバリ  Database ACL管理  クエリチューニング  障害対応  インデックス設計  テーブル設計(依頼があれば)  運用ツールの作成 業務について
  12. 12. History
  13. 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. 14. History 2015 Redis Cluster Redis Sentinel 2017 Hbase Hadoop 2016 MongoDB 2018 Elastic 2011 MySQL Oracle Cubrid SQL Server
  15. 15.  2016年以降、MySQLが年間1000インスタンス規模で増えている  海外(台湾、タイやインドネシアなど)のサービスも面倒みている  それらのサービスが急激に増えてきているよう  管理するプロダクトも増えつづけている  運用に手一杯の時期があった  最近、やっと人が増えてきて、新ソリューションの検証や運用ツール作成などに注力できる History
  16. 16. MySQL Operation
  17. 17. MySQL Operation  標準化 自動化することで運用を改善  大規模運用における苦労点  台数が急激に増えて管理が大変  サービス数が多く、サービスごとにMySQLのバージョンやサーバスペックが異なる  手動になっている運用に時間を取られる  インストール ,Database ACL管理,スキーマ変更  サービス担当者や開発者とのコミュニケーションコストが高い  複雑なDB構成によって、属人化して障害対応が24時間体制になってしまう
  18. 18.  1 サーバ当たり1インスタンス MySQL Operation  MySQL Enterprise EditionとMySQL Community Editionを併用  すべてOracle MySQLでフォークした製品はなし  同じマイナーバージョンで固定  最新のマイナーバージョンアップは基本なし。  メジャーバージョンアップは積極的に行う。
  19. 19.  MySQLに最適化されたサーバースペック  基本的にすべてオンプレで物理サーバ、社内用のシステムには一部VM  Low Spec ・・ HDD  Mid Spec ・・ SSD  High Spec ・・NVMe MySQL Operation  マスター/スレーブ/バックアップの3台が最小構成  すべて同じHA構成  さまざまな内製ツールを作成して、運用の自動化
  20. 20.  インストール自動化 MySQL Operation AS-IS 手動インストール TO-BE 自動インストール
  21. 21. 統合管理ツール
  22. 22.  DBAの統合管理ツール (通称 mondb+) 統合管理ツール  すべてのDBエンジンに対応した内製の一元管理するツール  WEB画面上で操作  各自欲しい機能を開発して、組み込む  以下のような項目が閲覧・設定可能  サービス/インスタンス情報一覧  自動インストール  自動スレーブ追加  Slow log 情報  Backup 情報  Real time QPS 情報  アラート情報  などなど…
  23. 23.  サービス/インスタンス情報  サーバ情報  MySQLバージョン  担当者  ロール(マスターorスレー ブ)  などなど  フェールオーバされれば即時 で反映 統合管理ツール
  24. 24. ≈  Slow log 情報(MySS)  long_query_time=1  日単位の合計数を取得  時間別でも取得可能 統合管理ツール
  25. 25.  Real time QPS 情報  コネクション数  Com_xxx  Slow_logの数  Io_thread  SQL_thread  Second behind master  等の情報を閲覧可能 統合管理ツール
  26. 26.  以下情報を定期的に収集し、表示  show engine innodb status  show processlist  show global variables  show global status  show slave status  MySQL Enterprise Backup や xtrabackupの履歴テーブル  データベースACL 統合管理ツール
  27. 27.  プライベートクラウド  Verda DBS  MySQLとRedisを提供  VM/物理選択可能  ある程度の権限を開発者に もたせることで運用コスト削 減  インスタンス作成  Database ACL権限  データベース作成  sysスキーマの情報 プライベートクラウド
  28. 28. ≈ プライベートクラウド  sys.statement_analysisの情報提供
  29. 29. MySQL Operation  まとめ  統合管理ツールや自動化ツールで、運用を楽にしている  プライベートクラウド  インストールや権限追加などの運用コストの削減  sys.statement_analysisでクエリの傾向を提供することやモニタリング画面を提供する ことで、開発者とのコミュケーションコスト削減  属人化する対応をなくす  スペックや構成を標準化したことでアラート対応を当番制へ。
  30. 30. MySQL HA
  31. 31.  とあるツールをベースにカスタマイズして使用中  本家はすでにメンテナンス終了。。  VIP付け替え方式  準同期レプリケーション(semi-sync)  スタンバイマスターへフェールオーバする MySQL HA
  32. 32.  自動フェールオーバ(マスターダウン)  スレーブがスタンバイマスターにchange master  スタンバイマスターをread_only = off  スタンバイマスターにVIPに付与  手動フェールオーバも可能  MySQL バージョンアップ  HW障害 / サーバリプレース  インデックスやカラム追加  割と安定してるが、課題も多かった MySQL HA
  33. 33. MySQL HA  課題  VIP枯渇問題  LINEのネットワーク設計の特性により、フェールオーバするサーバ間で物理 的制限がある  マルチソースレプリケーション未対応  最近要望が多い。。  指定した1台のスレーブのみマスター昇格可能  MHAのようにすべてのスレーブが昇格対象ではない。  スレーブの数が多いとフェールオーバが遅い
  34. 34. MySQL HA  現状の解決  VIP枯渇問題ー>○  DNS方式に改修することで、解決  マルチソースレプリケーション未対応ー>○  対応するように改修  指定した1台のスレーブのみマスター昇格可能ー>△  設定ファイルを自動で変更する  メンテナンスが大変。。HAソリューションの見直し時期!?
  35. 35.  InnoDB Cluster MySQL HA  Oracle推奨はMySQL RouterをAPサーバ と相乗り  数千?数万?台のAPサーバにMySQL Routerをインストール…  すべてのMySQL Routerの面倒を見るの はちょっとつらい
  36. 36. MySQL HA  Group Replication + DNS or InnoDB Cluster + DNS  シングルプライマリーモードで運用  可用性はGroup Replicationで担保  マスターの切り替わりを監視するモニターを用意して、DNS Recordを切り替える  監視モニターにMySQL Routerを入れる  監視モニターがGroup Replication meta 情報をチェックする
  37. 37. MySQL Monitoring
  38. 38.  MySQL Enterprise Monitor  商用版のMySQLで使用可能  MySQLのモニタリングであれ ばこれを見れば大丈夫  Query Analyzerとか便利 MySQL Monitoring  しかし、MySQL Community Edition もあるし、管理してるプロダクトはたくさんある・・
  39. 39. DBONE Project MySQL Enterprise Monitor Enterprise Monitor Remin/Relumin Cloudera MMS nPod  Monitoringツールの乱立問題
  40. 40.  複数のソリューションを統合的にモニタリングする仕組み  低コストで実現するために、16のOSSの組み合わせ  変更や新しいソリューションの追加を簡単にする  サービス担当者にもわかりやすいUI、画面を共有することでコミュケーションコ ストを下げる  Slack、メールやLINE notifyにアラート通知する DBONE Project Role Solution Collector Prometheus exporter / td-agent Stored Prometheus / Elastic Search Display Grafana Alert Alertmanager / alerta
  41. 41. ≈ DBONE Project
  42. 42. DBONE Project DBONE for MongoDB DBONE for MySQL DBONE for Redis
  43. 43. DBONE Project
  44. 44.  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サイズ
  45. 45. MySQL Backup
  46. 46. MySQL Backup  1st バックアップとして、デイリーでローカルにフルバックアップ取得  2nd バックアップとして、backup用storageへ転送する仕組み LINE でのバックアップ
  47. 47.  MySQL Enterprise Backup(MEB)  商用版のMySQLで使用可能。  xtrabackup  percona社が開発したOSS  xtrabackup2.3以降はinnobackupexでなくてもxtrabackupコマンドでMyISAMの テーブルも取得してくれる MySQL Backup  MEBもxtrabackupもオンラインバックアップ  稼働中のMySQLに対して、停止することなくバックアップを取得  アーキテクチャーはほぼ同じ  トランザクション未対応のストレージエンジンはテーブルロック
  48. 48. MySQL Backup  数TBの大規模かつ書き込み量が多いデータベースが多数  1st バックアップのために、IO 帯域を考慮する必要  2nd バックアップのために、 NW 帯域を考慮する必要  MEBをメインで使用していたが、インスタンス急増のためxtrabackupも導入  導入の際にIO制御の微妙な違いでハマった
  49. 49.  MEB  --sleep オプション  InnoDB テーブルから特定の量のデータをコピーした後に、スリープするミリ秒数を 指定します。(単位MS)  すでにsleep=200で設定して運用 MySQL Backup  xtrabackup  --throttle オプション  1MB単位での1秒当たりの入出力操作の数を制限します。(単位IO) IO制御 オプション
  50. 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. 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. 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. 53. MySQL Backup  MEB  --sleepオプションはibdファイルのコピーにのみ有効  xtrabackup  --throttleオプションはibdファイルとトランザクションログにも有効 IO制御オプションの違った点  MEB  ibdファイルとトランザクションログを同時にコピー開始  xtrabackup  トランザクションログからコピー開始  最新の状態に追いつくまでコピーしつづける  追いついたらibdファイルのコピーを開始する バックアップ開始時動作で違った点
  54. 54. MySQL Backup  原因  throttleオプションでIO量を制限してトランザクションログをコピーするため、更新が 多い環境ではトランザクションログの最新の更新に追いつかない。  よって、ibdファイルのコピーが開始できずにずっとトランザクションログのコピーを し続けていた状態であった。  xtrabackupの場合はOSレイヤーで圧縮するようにしてIO制御することに変更 # xtrabackup --backup --stream=xbstream | pbzip2 -p${PLEVEL} > BACKUPDATA.bz2
  55. 55. Next Step
  56. 56.  MySQL8.0  導入に向けて、絶賛検証中  Amazon AWS(RDS)  データセンターを持たない海外案件の対応 Next Step  バックアップ統合管理システム開発  MySQL HA  Group Replication + DNS
  57. 57.  MySQL Query Replayer 開発  MySQLのネットワークパケットからクエリを取得し、リプレイする  メジャーバージョンアップやハードウェアリプレースの負荷テストを目的 Next Step
  58. 58.  Operation  標準化と自動化することで運用が楽になった  HA  現状安定はしているが、今後を考えると新しいソリューションの検討が必要  Monitoring  DBONE で統合監視が形になってきている  Backup  バックアップ統合管理システム開発  OSS化に向けた運用ツール開発  まだまだやりたいことはいっぱいある! まとめ
  59. 59. LINE DBA 絶賛募集中! https://linecorp.com/ja/career/position/23
  60. 60. QUESTIONS ?
  61. 61. THANK YOU

×