2019.05.29はじめにこんにちは、データベース室の小田です。今回はLINEマンガのデータベースをシャーディングした作業について、サーバエンジニア編とデータベースエンジニア編に分けてご紹介したいと思います。本エントリでは、シャーディングに至った経緯、データベースエンジニア側で検討したことについて書いていこうと思います。シャーディングに至った経緯サービスを引継ぐ前段として少し昔の話をします。私がLINEマンガの担当データベースエンジニアとなったのは、2018年2月中旬のことでした。LINEマンガのサービス開始が、2013年4月9日だということですので、ちょうど5周年を迎える直前ですね。前任者からは、いいタイミングだからということで、一緒に移行作業を実施してからサービスを受け継ぎました。1台)となっていました。余談ですが、この時にもサービスの成長を見越してシャーディングを打診していました。諸々の事情(*1)により、上記の通りスケールアップのみの対応をしています。サービスの成長速度に気付かされる2018年10月。LINEマンガの担当として、だいぶ慣れてきた頃でした。WEBTOONの無料ウェブマンガサービス「XOY」との統合による人気作の移籍と、全話無料キャンペーンによるアクティブユーザの急増でした。下のグラフは、参照専用機のレプリケーション遅延のグラフです。x軸が時間経過、y軸が遅延時間を表し、時間の経過と共に遅延時間が増えています。レプリケーション遅延は、不適切な実装が原因で発生することが多く、当時もそういったものがないか探しました。きっかけはアクティブユーザの増加であって、不適切な実装の修正をすれば解決するような問題ではありませんでした。調査時は、バイナリログのローテーション速度の変化などから、更新量が異常に増加していることに気が付きました。LINEマンガでは、max_binlog_size=1Gで設定していたのですが、10分に1回のローテーション頻度となっていました。前日のピーク時が40分に1回のローテーション頻度だったので、当時のアクティブユーザがかなり多かったことが分かります。問題解決には、下記設定の変更を行いました。2後日追加の調査で判明したのは、データの増加速度が想定を超えていたことと残りディスク容量の問題でした。引き継いだ当初2.6TBだったディスク使用量が、8ヶ月後の2018年10月には、4.6TBに達していたのです。試算では、残り6ヶ月ほどでディスクフルとなることが判明したのです。問題1に対する恒久対策をとる時間として足りない可能性がある現行サーバ(NVMe-SSD6TB)が事実上の最高スペックLINEマンガの体制が抱える問題の整理サービス統合と、キャンペーンによってユーザの利用に影響を与えてしまったサービス統合とキャンペーンの情報が前もってデータベースエンジニアに共有されていなかった事前の検証ができない問題発生時に原因の特定/対策に時間が掛かる表面化した問題への対策レプリケーション遅延とディスク容量問題。そのどちらも、書き込み量の増加が根本です。以前から話にあがっていたシャーディングについて、具体的に考える必要性が出てきました。今までもシャーディングを検討して断念してきただけあって、全データを水平にシャーディングすることは困難でした。そこで、レプリケーション遅延時に更新量が増加していた特定テーブルを中核に、機能的に取り出せないかをサーバーサイドエンジニアと検討しました(垂直シャーディング)。検討に当たって、performance_schema.events_statements_summary_by_digestから該当テーブルに対するクエリを抜き出し、サーバーサイドエンジニアに提供しました。実現性の有無を検討して頂きました。検討の結果、対象5テーブルをメインMySQLから取り出すこととなりました。これらテーブルは、すべてをあわせると3TBほどあり、一番大きなテーブルで2TBもありました。当然ですが、INSERTの性能劣化もあり、対象テーブルをさらに水平にシャーディングすることも検討しました。対象テーブルはすべてユーザのログデータであり、ユーザID(member_id)で8個にシャーディングすることとなりました。65535そして、これらを実現する為にまず、喫緊の課題であるところのディスク容量の確保に取り組みました。具体的には、現在は未使用となったテーブルの削除を実施しました。影響が出ない状態であることを確認してテーブルを削除するこの対応によって、ディスク容量を500GBほど確保することが出来(下グラフ参照)、5テーブルの移行に十分な時間が出来ました。LINEマンガの体制が抱える問題への整理この件についてはシンプルですが、新規実装やプロモーション前などには、サーバーサイドへの事前の情報共有を徹底してもらうようにしました。これによって、新規実装をする場合は事前に相談してもらって問題を排除できるようになりました。デプロイタイミングでは、リアルタイムでモニタリングを実施し、デプロイ前後での差異などにも気を配っています。ME>]の掲載が始まりましたが、事前の共有をしてもらったので、あらかじめ参照専用機を追加するなどの対応が取れました。シャーディング案検討シャーディングに至った経緯を書いてきましたが、ここでは実際に検討した内容を書いていきます。詳細は下に書いていきますが、まずは、検討した内容についてまとめたテーブルをご覧ください。移行案3によるシャーディングの実施データサイズに依存する準備はとにかく時間が掛かるデータの移行データの移行は、中間MySQLで既存環境のフルバックアップ1TB(5TBのMySQLデータ)を展開するところからです。Xtrabackupで取得されたもので、リストアには4時間ほど掛かりました。リストア完了後、対象テーブル以外のテーブルを削除します。削除対象が大体2TBほどだったので、3TBの中間MySQLとなりました。そこからレプリケーション遅延の回復を行います。レプリケーションフィルターを利用して、対象5テーブルのみを同期します。バックアップ転送時間なども含めると、基本となる中間MySQLの構築にはほぼ1日掛かってしまいました。各テーブルに、パーティショニングキーとなるshard_hashカラムを追加し、主キーに構成していきます。TABLE文を叩いて放置する日々が続き、完了日時の想定をサーバーサイドエンジニアに共有し続ける日々になります。一週間に渡るshard_hashカラムの追加作業を終え、shard_hash値の更新作業に移ります。初回は、100億レコードほどの全件更新でした。こちらにも1週間ほど掛かりましたが、以降は定期更新を実装しています。member_idの変更はないサービス設計だった為(*4)、常に新しいレコードを更新し続ければ良かったのは非常に楽でした。ここまで実施したタイミングでバックアップ(3TBのMySQLデータ)を取得し、シャード環境の構築に取り掛かりました。パーティショニング次に、前段で取得したバックアップを各シャードMySQLにリストアしました。パーティショニングです。パーティショニングは今回の作業でもっとも時間が掛かったポイントです。TABLE文の完了に5日も掛かりました。この間、レプリケーションを停止していたので、その後の遅延復帰にも多くの時間が掛かりました。この工程で、当初予定していたメンテナンス日に間に合わないことが判明し、事業部に調整して頂くこととなりました。メンテナンス作業当日メンテナンス作業メンテナンス作業は、データサイズに依存しない作業のみで構成することが大切です。当日は複数環境で同時に作業を実施する為、すべてコピー&ペーストで完了できるような手順にすることを心掛けました。その甲斐あって、当日作業はスケジュールどおりに進行できました。メンテナンス開始から、データベース作業、アプリケーションのデプロイやQA作業に至るまで、問題はありませんでした。メンテナンス終了直後の高負荷メンテナンス終了直後、アプリが非常に重くなり、多くのユーザにご迷惑をお掛けしてしまいました。原因は、キャッシュの実装ミスによるもので、MySQLサーバが高負荷状況に陥っていました。特定のクエリが大量に実行されていた為、サーバーエンジニアに共有して対応して頂きました。メンテナンス作業結果メンテナンス前後の指標から1日あたりのデータ増加量は8分割され、今後6年余りはデータの増加に耐えうる環境となりました。ユーザが増加し続けたとしても、シャーディング機能の実装は終わっていますので、比較的簡単にリシャードが行える環境となりました。8シャードから16シャードに変更する場合アプリケーションは、シャードの計算式を8分割から16分割に変更データベースは、各シャードのデータをshard_hashのレンジで2分割してデータ移行また、サーバ負荷も大きく改善されました。今回の移行で、JOINクエリが分割された為、多くのスロークエリがなくなりました。ディスクサイズCPU使用率ディスクIOさいごにLINEマンガのサービスは、今回の対応が終わったことでさらに加速していくでしょう。データベースエンジニアは、サービスにどれだけ入っていけるかが時に重要になりますが、今回はその最たる作業だったかと思います。進化し続けるサービスにおいていかれないように一層コミットしていきますので、今後とも、LINEマンガをよろしくお願いします!というわけで今回は、LINEマンガのシャーディングをトピックにお話させていただきました。いかがだったでしょうか。LINEでは、他にもさまざまなサービスを提供していますが、その多くのサービスの裏側で私たちデータベースエンジニアも活躍しています。一緒に働いてくれる方を募集していますので、もし興味がある方がいらっしゃいましたら、お気軽にご応募ください。https://linecorp.com/ja/career/position/23では、またの機会に!注釈(*1)LINEマンガの大規模アップデートを目前に控え、開発リソースが不足した為(*2)注意点として、外部結合していてレコードが常に0件だったりするとレインテンシーも0になってしまいます。実装だけが残っていて、定義だけ使ってしまっている場合などです。Partitionを活用した理由は、以下の3点です。Partition文で取り出したデータは、元テーブルのデータの1/8のサイズのibdファイルである為、ibdファイルのシュリンクが不要(*4)実際には、CS対応などでmember_id間のデータ移行をしていたことがメンテナンス直後に発覚し、対応しています。Developers。