株式会社マネーフォワード 2017年09月06日 db tech showcase 2017 Tokyo 「120億レコードの金融資産データを扱うマネーフォワード のMySQL活用のこれまでとこれから」 9/6（水）A28 MySQL 17:30～18:20 前半：市川貴志 後半：飯田祐基

自己紹介 2 市川貴志（いちかわたかし） 取締役執行役員 CISO（情報セキュリティ） https://www.wantedly.com/users/995  辻調グループ・フランス校卒業。西洋料理の本場でフ ランス料理を学び、Lyon郊外の二つ星レストランに て研修を受ける。  2000年 マネックス証券株式会社入社、調理業界で の知識を活かし、株式取引システムインフラの開発・ 運用・PM業務を担当。  2008年 マネックスグループに転籍。子会社のシス テム統合などを担当。  2010年 大手金融システム開発会社にて、オンライ ン為替証拠金取引サイトの新規構築にインフラ担当の 責任者として参画。  2012年 株式会社マネーフォワードでシステムイン フラ・セキュリティ部門を担当（CISO）現在に至る。 © Money Forward,Inc.

自己紹介（フランス料理人から、社内給食当番へ転職） 3 © Money Forward,Inc.

自己紹介 4 給食の時間帯以外は CISOとしてセキュリティを インフラの安定化とスケールを アプリケーションの品質と価値の最大化を いつも考えて、仕事をしています © Money Forward,Inc.

マネーフォワードのご紹介 5

Mission/Vision/Value 個人のお金の悩みや不安の解消、事業者の経営改善に貢献し、 日本でNo1の「お金のプラットフォーム」になることを目指しています。 Mission お金を前へ。人生をもっと前へ。 「お金」は、人生においてツールでしかありません。しかし「お金」とは、自身と家族の身を守るため、また夢を実現するために必要不可 欠な存在でもあります。 私たちは「お金と前向きに向き合い、可能性を広げることができる」サービスを提供することにより、ユーザーの人生を飛躍的に豊かにす ることで、より良い社会創りに貢献していきます。 Vision すべての人の、「お金のプラットフォーム」になる。 オープンかつ公正な「お金のプラットフォーム」を構築すること、本質的なサービスを提供することにより、個人や法人すべての人のお金 の課題を解決します。 Value User Focus 私たちは、いかなる制約があったとしても、常に ユーザーを見つめ続け、本質的な課題を理解し、 ユーザーの想像を超えたソリューションを提供し ます。 Technology Driven 私たちは、テクノロジーこそが世界を大きく変え ることができると信じています。テクノロジーを 追求し、それをサービスとして社会へ提供してい くことで、イノベーションを起こし続けます。 Fairness 私たちは、ユーザー、社員、株主、社会などのす べてのステークホルダーに対してフェアであるこ と、オープンであることを誓います。 6

沿革 短期間で個人・法人向けサービスを次々とリリース。 7 2012年5月 会社設立 1期 2期 3期 4期 5期 6期 2012年12月 自動家計簿・資産管理サービス『マネーフォワード』 2013年11月 『MFクラウド会計・確定申告』 2013年12月 お金のウェブメディア『マネトク』（現くらしの経済メディア『MONEY PLUS』） 2014年5月 『MFクラウド請求書』 2015年3月 『MFクラウド給与』 2015年8月 Fintech研究所設立 2015年4月 『MFクラウド消込』 2015年8月 『MFクラウドマイナンバー』 2015年10月 ㈱NTTデータと「Open Bank API」の 共同検討開始 2015年11月 金融機関利用者向け『マネーフォワード』 2016年1月 『MFクラウド経費』 2016年9月 (一社)Business IT推進協会設立 2017年1月 2017年6月 2016年12月 ㈱MF Alpha Lab設立 2017年3月 MF KESSAI㈱設立 提供サービスの変遷 通帳アプリ 『かんたん通帳』 『MFクラウドファイナンス』 PFMサービス MFクラウドサービス 2017年6月 MF KESSAI 7

提供サービス PFM（Personal Financial Management） 事業 自動家計簿・資産管理サービス ビジネス向けクラウドサービス 8 MFクラウド事業 © Money Forward,Inc.

PFM事業 個人向け 9

PFMサービス 人々のライフステージに沿って起こるお金の課題を、 “個人のお金” という領域で多くのユーザーと複数の接点を持ちながら、 人生に寄り添って解決していくサービスを提供します。そして、 すべての人の人生をもっと前に進めていきたいと考えています。 個人のあらゆるお金の不安をなくし、 人生をもっと前へ。 10

自動家計簿・資産管理サービス『マネーフォワード』 家計簿アプリシェアNo.1。利用者数は500万人を突破(2017年4月)し、家計 簿アプリ利用者の約4人に1人は『マネーフォワード』を利用。 対応数No1(*) 2,600以上の金融関連サービスに対応。 口座一括管理で自動で家計簿作成 利用者数およびシェア 出所：2017年03月23日～2017年3月27日、楽天リサーチ 「現在利用している家計簿アプリ」 調査対象者：20～60代家計簿アプリ利用者685名 利用者数 シェア *自社調べ、2017年7月31日現在 11

自動家計簿・資産管理サービス『マネーフォワード』 利用者の約半数が収益改善を実感。金額平均月19,090円 (*1) 。 2017年2月 自社アンケート調査結果より *1：調査対象、調査対象：『マネーフォワード』利用者2,460名のうち、 「家計改善した」と回答した1,175名の平均値。 *2：家計改善したと回答したプレミアム会員448名の平均値。 *3：マネーフォワードを利用して意識や行動に変化があったと回答した利用者1,415名の回答より お金に対する行動や意識の変化(＊3) キャッシュレス生活へのシフト状況(*3) プレミアム会員は24,728円(*2)の改善を実感 *１ (*1) 12

MFクラウド事業 オフィス向け 13

MFクラウドサービス テクノロジーと、税理士や社会保険労務士等の専門家、金融機関との オープンなコラボレーションで企業の稼ぐ力を強化するとともに、 経営を強化させ、ひいては経済成長を実現し 人々のお金の課題を解決していきます。 事業者の経営課題を解決し、 日本経済をもっと前へ。 14

個人向け マネーフォワード エンジニアブログより 15

5.5年間（2012年～2017年）を インフラ・MySQL DB 観点で振返る 16

今日のお話は © Money Forward,Inc. 17 - 1つのMySQLインスタンスで120億レコード以上の家計・資産デー タを本番運用している（苦労）話をします - （壊れた時の切り替え用スタンバイ機や、運用で使う遅延レプリDBなどは当然別にあります） - 現在、全面的にシステムアーキテクチャの見直しを行っているの で、MySQL DBAをマネーフォワードでは募集しています - スポンサーブースの前におりますので、質問などがあったら声を かけてください（[email protected]） - 資料は後でTwitterで公開します #dbts2017 @Ich_chaan

すみません、初めに謝ります © Money Forward,Inc. 18 120億レコード ではなくて

すみません、初めに謝ります © Money Forward,Inc. 19 ちゃんと数えたら 140億でした

これまで（1年目～2年目） 2012年 β版のサービス開始、まずはサービスが動くこと - それまでの証券会社ではRDBMSなら「Oracle」が当たり前 - MySQL Community Edition（DBに限らず全部OSS） - お金は無い。PCもすべて中古でメモリ増設＋SSD換装 - ユーザーも利用期間も増えれば指数関数的にデータが増える - ただし、サービスがどの程度使われるかはまだわからない時代 - 従業員6名＋インターン。インフラの負荷課題はまだなかった - マスタでフルバックアップを mysqldump でとっても一瞬 20

システム構成（概要図） 21 © Money Forward,Inc.

言語とORMとDBMS © Money Forward,Inc. 22 - DBへの接続 - PC Web > Rails APP > MySQL - スマホ > Rails API > MySQL - アカウントアグリゲーション（Java） > MySQL - Rails Active Record（ORM） - 開発者はすぐアプリケーションが作れる - 発行されるSQLがなかなか開発者には見えづらい

これまで（1年目～2年目） 2013年 順調にサーバー代が高くなり始める - β版から正式リリース版へ、ただし売り上げはまだない - ユーザーは順調に増え、データ量も増えていきサーバー代ツライ - チューニングされていないSQLがリリースされてスローダウン - 安くて fusion-io 使える環境を探していた - さくらインターネット 専用サーバーエントリーモデル - IOとCPU負荷は当面何も気にしないでよい状態となる - インフラ担当は、まだ私一人（DBAではない） - サーバーは50台ぐらいだったかな？ 23

入出金関連主要4テーブルの合計レコード件数推移 まだ、レコード件数を計測していない時期だった 24

これまで（3年目） 2014年 プレミアムサービスが徐々に広がり始める - プレミアムユーザーとのSLA - システム稼働率、安定性 - バックアップリストア保障 - 速いマスタを手に入れてハードウェアに頼る - リードレプリカが使われない、キャッシュも使われない - 1台のDBはアプリとしては処理はシンプル - スロークエリもあまり見なくなっていた、良くない - BLOGや料理サイトと異なり、自分の資産データはキャッシュでき る部分は少ない 25

入出金関連主要4テーブルの合計レコード件数推移 2014年末には、10億レコードにはなっていた 26

これまで（4年目） 2015年 スケール設計や負荷対策を本格的に着手 - 引き続きDB性能が良いことに頼りスケールアップを続ける - DBのスケールアウト、縦割り、横割り？ - リードレプリカもっと使おう（時々レプリ遅延が。。） - データ移行時のインポート、工夫しないと2週間かかる - できるだけアプリに手は入れたくない - すると、MySQL Cluster が選択肢としては有力 - でも全データがメモリに乗るのは難しい - テーブルの圧縮しないとすでに1TBは超えている - そろそろ、MySQL 5.6 > 5.7 も考え始めないと 27

入出金関連主要4テーブルの合計レコード件数推移 2015年末には30億レコードに。データの持ち方も工夫し上昇カーブを変える この辺で 持ち方を変更 角度を緩やかに 28

これまで（5年目） 2016年 MySQL 5.7 化（そして、まだまだシングルインスタンス） - Yoku0825 さんの情報をたくさん参考にさせてもらった - https://www.slideshare.net/yoku0825/mysql-57-53449734 - 「MySQL 5.7 にやられないためにおぼえておいてほしいこと」 - 移行のツラミ - ダンプからのインポートでは2か月あってもインポートできない - パーティション化＆複数スレッド化プログラムで3日で投入 - OSパラメータ、Initパラメータ、新バージョンで普通に苦労 - 5.6で毎日動いていたバッチ（SQL）を5.7の新サーバに投げたら、 なんと mysqld クラッシュ！ エンジニア全員で祭りが発生ｗ - Bug #84107 Severe slowdown on partitioned table with simple ORDER BY ASC change to DESC 29

これまで（5年目） 2016年 引き続き苦労している点 - 大きなテーブルのALTERが打てない - 小さなテーブルならオンラインでもできるが大きいと無理 - 裏側でリードレプリカでALTERしてマスタとひっくり返す - ロック関連 - サーバーの処理能力が上がってもロック関連は1インスタンス だとツライ - 早くDBやシステムの分割をしたい、2017年こそやる 30

使っているハードウェア © Money Forward,Inc. 31 - さくらの専用サーバ（エンタープライズシリーズ） - CPU 56コア（HT）（次は80コアへ） - メモリ 256 GB - SSD RAID 10大盛り＋PCI SSD - IOPS は2万～3万 IOPS - メインのDB以外は - AWSや一部GCPも使っています - インフラ全体の台数は - 500台ぐらいでした（現在は700台以上）

入出金関連主要4テーブルの合計レコード件数推移 去年の dbts2016 の時、そろそろ100億レコードが見え始めていた この辺で 持ち方を変更 角度を緩やかに 32

これまで（6年目 今年） 2017年 モノリシックなシステムを疎に。DBも役割ごと割る。 - DBに限らずシステム全体がモノリシックだった課題 - あるフェーズまでは1つで全部扱ったほうが楽だし早い - でも、メリデメがひっくり返るタイミングが必ず来る - 同システム内であってもAPI連携し機能ごとに責務を分ける - 今取り組んでいることと、今後の話は - 次の飯田のスライドで 33

入出金関連主要4テーブルの合計レコード件数推移 計測した7月は120億だったが、9月時点では140億になっている この辺で 持ち方を変更 角度を緩やかに 34

全体を通して 35 どこまでスケールアップで運用できるか 140億レコード？（一番大きいテーブルは70億レコード）ぐらいは、苦 労しながらも本番サービスでの運用はできる でも運用しづらいので、そこまで大きくするのはやめたほうがよい PCI SSD の速さ 10年前にはできなかった構成が取れる、1台でこんなに処理できるとは 現在の体制 引き続きDBA専任はいない。急募！（サービスインフラは5名程度です） © Money Forward,Inc.

ちなみに（登壇後スライド追加） © Money Forward,Inc. 36 - 本日の資料（グラフ）に使ったレコード件数のカウント方法 - information_schema の table_rows は使っていません - 正しい件数が取得できないため - どうやっているか - 今日、この日のために select count 用レプリサーバーで - 日次バッチで全件カウントし、CSVに保存していました - 最近は24時間でも終わらず、3日に1回、回しています 某、O社の方から疑問の声が 上がったようなので このスライド追加 （実は、真面目に数えています）

Fintech インフラ・セキュリティに 興味があったらこちらまで 気軽にご連絡ください インフラ https://www.wantedly.com/projects/7727 セキュリティ https://www.wantedly.com/projects/58908 37

© Money Forward,Inc. 後半のAgenda 1 自己紹介 2 入社したころのお話 DB分割のお話 3 4 5 チューニングのお話 今後の展望 38

© Money Forward,Inc. 自己紹介 飯田 祐基（いいだゆうき） サービスインフラグループ ■ 2006年 株式会社インターネットイニシアティブ入社 、サーバ、ネットワークエンジニアとしてインフラ業 務に従事 ■ 2009年 pixiv株式会社入社、インフラエンジニアとし てデータセンタの立ち上げ、ネットワーク構成全般、 画像配信、広告配信サーバの設計・構築などを行う ■ 2012年 株式会社SKIYAKI入社、Railsエンジニアとし てアーティスト公式サイト運営プラットフォームの開 発に従事、その後CTOとしてエンジニア採用、チーム マネジメントをメインに携わる ■ 2017年 株式会社マネーフォワード入社、サービスイ ンフラグループにて主にデータベース運用に従事 39

おかげさま500万ユーザ突破！ ぐんぐん成長しています。 ※1 実査委託先：楽天リサーチ 調査手法：インターネット調査 調査日：2017年3月23日～2017年3月27日 調査対象者：20～60代家計簿アプリ利用者685名 40

サービスが大きくなるとどうなるか？ 41

運用が大変！ ＼(^o^)／ 42

入社当初の状況 • 家計簿アプリの他にもBtoBサービス「MFクラウドシリ ーズ提供」 • メインのデータベースが1つ ！ • 更新量が多すぎてスレーブで遅延が発生している • 参照分割も行ってはいるが、ごく一部だけ 43

そうすると、こうなる • DB落ちたら全部止まる！ • ちょっとしたスキーマの変更が一大事！ • 色々な負荷がかかっていて処理の特定が難しい！ • スケールアップがこれ以上出来ない！ 44

じゃあどうする？ DBを分割する。 入社1週間くらいでDB分割担当に。 45

なぜ分割するのか？ 1.サービス間の密結合を減らし、お互いの影響を減らす （サービス毎にスキーマをわける） 2.負荷の分散（特に良く読み書きされるデータベースを分ける） 大きく2つの意味合い 現在の状況 • ４サービス分のテーブルを分割 • 近々データ量の大きいテーブルも分割予定 デメリット • joinが出来なくなる • APIを作るなど、実装の修正がかなり必要な場合がある 46

データベース分割の流れ その１ データベーススキーマを分割して、アプリケーションの参照先を変更（論理分割） 47

データベース分割の流れ その２ スレーブサーバを用意する。全部受けると遅延解消できなかったりするので、 replicate_do_db / replicate_do_table で必要なもののみを受けとる 48

データベース分割の流れ その３ マスター昇格。アプリケーションの接続先を新しいDBへ変更 49

分割でのツラミ その１ 論理分割時にテーブルのデータ量が多いと移設が困難 ❌ dump / restore だと時間がかかり過ぎる。 ❌ レプリケーション → `RENAME DATABASE` ( 5.1.23で廃止 ) 論理分割をせずに一度に物理DB分割する必要があるのでリスクが高い ❌ 新しいDBスキーマを作る → `RENAME TABLE` → レプリケーション → マスター分割 RENAME TABLEはアトミックかつ、非常に高速 二つのテーブル名のスワップ（入れ替え）も可能 https://dev.mysql.com/doc/refman/5.6/ja/rename-table.html 50

分割でのツラミ その２ どうしてもjoinを止めるのが難しい処理はある。ユースケースの多い広告メー ル配信。サポートでの調査。 ❌ elastic search (ロジックの修正にかなりのコストがかかる） ❌ federatedエンジン （遅すぎる、データ量が多いテーブルだと実用的ではない） ❌ マルチソースレプリケーション （複数のマスタからレプリケーションを受ける）で対応 • 構成が複雑 • 分割する度にスレーブを新しく植え付けなければならない • 1つレプリケーションが潰れると、修復がかなり辛い マルチソースレプリケーションは麻薬 （確かに便利ではある、壊れさえしなければ） 51

じゃあどうする？ その２ チューニングする 52

大味なものから • キャッシュする • 参照分割する • 更新の多いテーブルをKVS化 • バッチ処理であれば負荷の低い時間に変更する もちろんスロークエリは地道に潰す。 もちろんスロークエリは地道に潰す。 特に負荷の高い処理を見つけ出し、対策を打つ。 53

じゃあどうする？ その２ 処理が多すぎて、何が影響を与えているのかわからない。全量のクエリを集計 したい。 ❌ general log → 容量が大きくなりすぎる ❌ tcpdump ＆ pt-query-digest → 同じく容量が大きくなりすぎる ❌ binlog → 参照系クエリが取れない ❌ packet beats → SSL接続しているので無理 ❌ performance_schemaを利用する 特にevents_statements_summary_by_digestが便利 • どんなSQLが？ • どのくらいの実行待ちや、ロック待ち、レコード数の操作をしてるかを • SQLの変数部分を無視してサマライズした形で • 起動時からの合計値を出してくれる 54

events_statements_summary_by_digestの例 何を言っているのかわからないと思うので、実例 55

events_statements_summary_by_digestを使った分析 定期的にdumpして差分（変化量）をKibanaで可視化 56

最適化事例 User.findメソッドをキャッシュ化 • 一つ一つのクエリは軽い（スロークエリには現れにくい） • とにかく量が多い。日中ずっと負荷が乗っている • 単純なクエリなのでキャッシュにしやすい • findメソッドを手入れして、開発者は意識せずにキャッシュを利用できるように 朝の入出金メール通知を参照分割 • 朝8時くらいから極端に負荷をかけていた • DBでステート管理しているため、更新料が多い（未解決） • ほぼ全ユーザ分をなめるので、もちろん参照も多い • 参照分割（少しくらいの遅延は致命的じゃないので） どの時間に、何が負荷をかけているのか？が透けて見えてくる 57

今後の展望 • 更新量が多いデータはKVS化 • elastic searchを活用して、カウント、ソート負荷を分散 • 増えゆくデータと戦うためにシャーディング、分散DBなどを検討 • マネーフォワードのサービスはユーザがほとんど自分のデータを見ることしかない • ユーザの関心が高いのは時系列的に最近データがほとんど • 参照にかたよりが少ないため一般的なキャッシュ戦略はとりづらい サービス特性にあわせたキャッシュ戦略 自分のデータ分くらいなら、スマホアプリ側のローカルに十分に乗せられるはず ローカルデータならマシンリソースもユーザ側に分散できる レスポンスも速いし、オフラインでも使える ⬇❌ 58

重ねてですが、仲間を募集しています インフラ https://www.wantedly.com/projects/7727 セキュリティ https://www.wantedly.com/projects/58908 ご静聴ありがとうございました！ 59