2019.05.28はじめにこんにちは、LINEマンガ開発の伊藤です。今回はLINEマンガのデータベースをシャーディングした作業について、サーバーエンジニア編とデータベースエンジニア編に分けてご紹介したいと思います。本エントリでは、シャーディングに至った経緯や対応方針、アプリケーション側で改修したことについて書いていこうと思います。LINEマンガとは「LINEマンガ」は、アプリやWEBブラウザ、LINE上でマンガ作品が楽しめる電子コミックサービスです。2013年4月にサービスを開始し、2019年4月9日で6周年を迎えました(*1)。2018」の日本アプリ年間収益ランキング(非ゲームを除く)ではコミュニケーションアプリ「LINE」に続いて、なんと2位(*2)です!シャーディングの背景ありがたいことにユーザーが増え続けているので、以前からシャーディングは検討事項の一つでした。シャーディング前提の設計ではなかったことや、開発リソース等の問題もあり、データの増加にはスケールアップで対応していました。2018年の2月にもNVMe-SSDの3TBから6TBに換装し、「これであと3年はいける!」と見込んでいた所でした。その半年後、レプリケーション遅延のアラートが上がったことで状況が一変します。WEBTOONの人気電子コミックサービス「XOY」との統合でした。XOYで連載していた作品をLINEマンガへ移行し、全話無料にする施策をうった事によって、レコードのINSERTが急増したのです。遅延は一時的なものでしたが、想定よりもデータの増加量が多く、このペースだと半年持たなそうな事と、テーブルの肥大化が原因でIO性能が劣化していることが分かりました。肥大化していたのは主に以下のテーブルです。連載マンガの閲覧履歴マンガの未読・既読の機能に利用されていて、1話読むと1レコード作られます。これが全話無料キャンペーンによって大量のINSERTが発生したテーブルです。未読・既読の情報は、サービスの様々な箇所に利用されています。購入履歴ユーザーが課金して購入した単行本を管理するテーブル(無料分も含む)です。連載マンガのお気に入り読んで字のごとく、ユーザーのお気に入りを管理するテーブルで、お気に入りを解除するとレコードを削除します。配信されたマンガは基本的にずっと配信が続きますが、急遽停止することもあるため、これらのテーブルとmasterデータをJOINするような使い方をしています。基本的にレコード削除のオペレーションはなく、ユーザー数、コンテンツ数、運用期間に比例してデータが増える性質を持っています。今後もデータの増加は予想されるため、スペックアップで乗り切るのも難しく、抜本的な対策としてシャーディングに踏み切りました。移行方法の検討NAVER製のミドルウェア「NBase」を使うこれは無停止でシャードDBを追加できるMySQLライクなミドルウェアです。NBaseはJava/C向けのAPIしか提供がなく、Perlで実装されているLINEマンガではそのまま使うことができません。ライブラリを移植したり、LINEマンガをPerlからJavaで再実装するのは工数的に現実的ではなく、今回は導入を見送りました。Spiderエンジンを使う情報があまり多くなく、社内での運用実績もなかったため見送りました。既存DBとシャードDBでミラーリングし、両方に書き込み(ダブルライト)する。ダブルライト後、読み込み、書き込みの順で既存DBからシャードDBに向けていく比較的オーソドックスなやり方です。実装の修正が多く、二重に書き込み処理をすることによるレスポンスタイムの劣化や、データ不整合のリスクがありますが、不確定要素は少なかったので今回はこれを採用しました。シャーディングまでの軌跡サービスインに至るまで紆余曲折ありましたが、大きく6つのPhaseに分けて計画をたてました。アプリケーション側としては、Phaseを分けることで修正範囲が明確になり、実装漏れやレビュー観点の明確化に繋がります。この方針のおかげで、実装ミスはレビューでほぼ潰すことができ、QA工数の削減に成功しました。調査・準備サービスとして使っていないテーブルを洗い出し、Read/Writeがないテーブルと突き合わせて削除するリファクタリングを実行。容量を確保して時間を稼ぐのと、適度にリファクタリングをすることで、後のPhaseで修正箇所を減らす事が目的です。外部キーやINDEXを見直し、INSERTの性能を改善するのもこのPhaseで行いました。冗長構成にするシャード用のDBを新規に用意し、既存DBからレプリケーションを貼って冗長構成にしました。その際、5.6から5.7へのバージョンアップも同時に行いました。既存DBとシャードDBの両方に書き込む今回はシャードを8分割することにしました。書き込み先のシャードは、ユーザーのID(LINEマンガではmember_id)からハッシュスロットを計算して決めています。シャード8}ハッシュ値を分割する8の余りではなく、65535で割った余りでレンジを求めているのがポイントです。このやり方の利点は、シャード数の増減が容易なところにあります。columnとパーティショニング機能を組み合わせれば、ダブルライトしなくても良いのでは、という話が持ち上がりました。実装/QAは終わっていたものの、ダブルライトによる性能劣化は1番の懸念事項でしたし、面白そうなやり方だからチャレンジしてみたいという思いもあって、思い切って方針を変更しました。参照をシャードDBのみに向ける実装の修正で一番の難所がこのPhaseでした。修正パターンは大きく分けて3つあり、ユーザーに紐づくレコードを取得するような、修正自体は単純でも数が多いもの。売れ筋ランキングのような、シャードに散らばったデータを集約しサマリーを作るバッチ系のもの。master情報とJOINしている箇所をバラして、クエリを分離するもの。3つ目はクエリのバリエーションも多く、SQLの実行計画を見ながらクエリのチューニング、ロジック自体の見直しも行いました。書き込みをシャードDBのみに向けるPhase3で対応した箇所を粛々と修正しました。シャーディング対応と平行して定期リリースの開発も進んでいるため、関連箇所の修正漏れがないように注意を払う必要がありました。不要なレコードを削除する最初に全てのデータをミラーリングしているため、本来不要なレコードが残っている想定でした。こちらを削除するタスクも計画していましたが、パーティショニング方式に切り替えたため、タスクはスキップすることができました。前述の通り、シャーディングするとmaster系テーブルとのJOINができなくなります。その際、特に本棚の連載マンガ一覧を返すAPIが悩ましい所でした。本棚の連載マンガ一覧についてLINEマンガでは、出版社のコンテンツ、LINEマンガオリジナルのコンテンツ、一般の作家が投稿するインディーズマンガを「連載マンガ」として扱っています。これらはお気に入り登録することで、LINEマンガのLINE公式アカウントから作品の更新通知を受け取る事が可能になります。このお気に入り登録したマンガを一覧で見れるのが本棚機能です。Modeが実装されており(*3)、目に優しいUIでお楽しみいただけます。本棚では更新されたものを探しやすいように、最新話が未読のものを上に表示しています。今までは、お気に入りしているマンガ、マンガの最新話、最新話の閲覧履歴を全てJOINして並べ替えるという実装をしていましたが、シャーディングによってマンガの最新話がJOINできなくなりました。並べ替えの要件が「最新話が未読のもの」である以上、どうにかロジックでカバーする必要があります。対応したことJOINができないため、シャーディングされたテーブルと、既存DBからそれぞれSELECTしなければなりません。最新話すべてを都度DBから参照するのは、負荷の観点から望ましくない事は予想されていました。そこで、最新話のデータをRedisに保存し、HMSET()/HMGET()でやり取りするロジックに修正しました。デコードするコストはかかりますが、都度データベースを参照するよりかは遥かに高速です。benchmarkをとったところCache::Memcached::Fastのget_multi()/set_multi()を利用した実装と比べて約2倍の速度が出たため、今回はRedisを採用しました。終わりにシャーディングを行ったことで既存DBの容量と負荷は激減し、APIのレスポンスタイムが以前よりも改善されました。これでユーザーが増えても快適に使ってもらうことができそうです。LINEマンガでお気に入りのマンガをたくさん見つけてください。LINEマンガは電子コミックサービスの圧倒的なNo.1を目指しています。サーバーサイドエンジニアも絶賛募集中です。Developers。