#dbts2017 #DBA採用 #マネーフォワード
http://www.db-tech-showcase.com/dbts/tokyo
現在 #500万人突破 #家計簿アプリシェアNo1 のマネーフォワードでは、120億レコードを超える金融資産関連データをMySQLで扱っています。 そんなマネーフォワードのDBインフラについてこれまでの成長で対応した課題やこれからについてお話します。
株式会社マネーフォワード2017年09月06日db tech showcase 2017 Tokyo「120億レコードの金融資産データを扱うマネーフォワードのMySQL活用のこれまでとこれから」9/6（水）A28 MySQL 17:30～18:20前半：市川貴志後半：飯田祐基
View Slide
自己紹介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すべての人の、「お金のプラットフォーム」になる。オープンかつ公正な「お金のプラットフォーム」を構築すること、本質的なサービスを提供することにより、個人や法人すべての人のお金の課題を解決します。ValueUser Focus私たちは、いかなる制約があったとしても、常にユーザーを見つめ続け、本質的な課題を理解し、ユーザーの想像を超えたソリューションを提供します。Technology Driven私たちは、テクノロジーこそが世界を大きく変えることができると信じています。テクノロジーを追求し、それをサービスとして社会へ提供していくことで、イノベーションを起こし続けます。Fairness私たちは、ユーザー、社員、株主、社会などのすべてのステークホルダーに対してフェアであること、オープンであることを誓います。6
沿革短期間で個人・法人向けサービスを次々とリリース。72012年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 KESSAI7
提供サービスPFM（Personal Financial Management）事業自動家計簿・資産管理サービス ビジネス向けクラウドサービス8MFクラウド事業© 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.18120億レコードではなくて
すみません、初めに謝ります© 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 simpleORDER BY ASC change to DESC29
これまで（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/5890837
© Money Forward,Inc.後半のAgenda1 自己紹介2 入社したころのお話DB分割のお話345チューニングのお話今後の展望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.html50
分割でのツラミ その２どうしても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
ichikawatakashi
nttcom
mako5656
orgachem
seike460
you
kubukoz
bun913
bengo4com
koic
korodroid
aiji42
yayoi_dd
rmw
paulrobertlloyd
searls
thoeni
maltzj
lemiorhan
skipperchong
marcelosomers
paigeccino
lara
addyosmani
vanstee