Upgrade to Pro — share decks privately, control downloads, hide ads and more …

120億レコードの金融資産データを扱うマネーフォワードのMySQL活用のこれまでとこれから

 120億レコードの金融資産データを扱うマネーフォワードのMySQL活用のこれまでとこれから

#dbts2017 #DBA採用 #マネーフォワード

http://www.db-tech-showcase.com/dbts/tokyo

現在 #500万人突破 #家計簿アプリシェアNo1 のマネーフォワードでは、120億レコードを超える金融資産関連データをMySQLで扱っています。
そんなマネーフォワードのDBインフラについてこれまでの成長で対応した課題やこれからについてお話します。

Ichikawa Takashi

September 06, 2017
Tweet

More Decks by Ichikawa Takashi

Other Decks in Technology

Transcript

  1. 自己紹介 2 市川貴志(いちかわたかし) 取締役執行役員 CISO(情報セキュリティ) https://www.wantedly.com/users/995  辻調グループ・フランス校卒業。西洋料理の本場でフ ランス料理を学び、Lyon郊外の二つ星レストランに て研修を受ける。

     2000年 マネックス証券株式会社入社、調理業界で の知識を活かし、株式取引システムインフラの開発・ 運用・PM業務を担当。  2008年 マネックスグループに転籍。子会社のシス テム統合などを担当。  2010年 大手金融システム開発会社にて、オンライ ン為替証拠金取引サイトの新規構築にインフラ担当の 責任者として参画。  2012年 株式会社マネーフォワードでシステムイン フラ・セキュリティ部門を担当(CISO)現在に至る。 © Money Forward,Inc.
  2. Mission/Vision/Value 個人のお金の悩みや不安の解消、事業者の経営改善に貢献し、 日本でNo1の「お金のプラットフォーム」になることを目指しています。 Mission お金を前へ。人生をもっと前へ。 「お金」は、人生においてツールでしかありません。しかし「お金」とは、自身と家族の身を守るため、また夢を実現するために必要不可 欠な存在でもあります。 私たちは「お金と前向きに向き合い、可能性を広げることができる」サービスを提供することにより、ユーザーの人生を飛躍的に豊かにす ることで、より良い社会創りに貢献していきます。 Vision

    すべての人の、「お金のプラットフォーム」になる。 オープンかつ公正な「お金のプラットフォーム」を構築すること、本質的なサービスを提供することにより、個人や法人すべての人のお金 の課題を解決します。 Value User Focus 私たちは、いかなる制約があったとしても、常に ユーザーを見つめ続け、本質的な課題を理解し、 ユーザーの想像を超えたソリューションを提供し ます。 Technology Driven 私たちは、テクノロジーこそが世界を大きく変え ることができると信じています。テクノロジーを 追求し、それをサービスとして社会へ提供してい くことで、イノベーションを起こし続けます。 Fairness 私たちは、ユーザー、社員、株主、社会などのす べてのステークホルダーに対してフェアであるこ と、オープンであることを誓います。 6
  3. 沿革 短期間で個人・法人向けサービスを次々とリリース。 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
  4. 今日のお話は © Money Forward,Inc. 17 - 1つのMySQLインスタンスで120億レコード以上の家計・資産デー タを本番運用している(苦労)話をします - (壊れた時の切り替え用スタンバイ機や、運用で使う遅延レプリDBなどは当然別にあります)

    - 現在、全面的にシステムアーキテクチャの見直しを行っているの で、MySQL DBAをマネーフォワードでは募集しています - スポンサーブースの前におりますので、質問などがあったら声を かけてください([email protected]) - 資料は後でTwitterで公開します #dbts2017 @Ich_chaan
  5. これまで(1年目~2年目) 2012年 β版のサービス開始、まずはサービスが動くこと - それまでの証券会社ではRDBMSなら「Oracle」が当たり前 - MySQL Community Edition(DBに限らず全部OSS) -

    お金は無い。PCもすべて中古でメモリ増設+SSD換装 - ユーザーも利用期間も増えれば指数関数的にデータが増える - ただし、サービスがどの程度使われるかはまだわからない時代 - 従業員6名+インターン。インフラの負荷課題はまだなかった - マスタでフルバックアップを mysqldump でとっても一瞬 20
  6. 言語とORMとDBMS © Money Forward,Inc. 22 - DBへの接続 - PC Web

    > Rails APP > MySQL - スマホ > Rails API > MySQL - アカウントアグリゲーション(Java) > MySQL - Rails Active Record(ORM) - 開発者はすぐアプリケーションが作れる - 発行されるSQLがなかなか開発者には見えづらい
  7. これまで(1年目~2年目) 2013年 順調にサーバー代が高くなり始める - β版から正式リリース版へ、ただし売り上げはまだない - ユーザーは順調に増え、データ量も増えていきサーバー代ツライ - チューニングされていないSQLがリリースされてスローダウン -

    安くて fusion-io 使える環境を探していた - さくらインターネット 専用サーバーエントリーモデル - IOとCPU負荷は当面何も気にしないでよい状態となる - インフラ担当は、まだ私一人(DBAではない) - サーバーは50台ぐらいだったかな? 23
  8. これまで(3年目) 2014年 プレミアムサービスが徐々に広がり始める - プレミアムユーザーとのSLA - システム稼働率、安定性 - バックアップリストア保障 -

    速いマスタを手に入れてハードウェアに頼る - リードレプリカが使われない、キャッシュも使われない - 1台のDBはアプリとしては処理はシンプル - スロークエリもあまり見なくなっていた、良くない - BLOGや料理サイトと異なり、自分の資産データはキャッシュでき る部分は少ない 25
  9. これまで(4年目) 2015年 スケール設計や負荷対策を本格的に着手 - 引き続きDB性能が良いことに頼りスケールアップを続ける - DBのスケールアウト、縦割り、横割り? - リードレプリカもっと使おう(時々レプリ遅延が。。) -

    データ移行時のインポート、工夫しないと2週間かかる - できるだけアプリに手は入れたくない - すると、MySQL Cluster が選択肢としては有力 - でも全データがメモリに乗るのは難しい - テーブルの圧縮しないとすでに1TBは超えている - そろそろ、MySQL 5.6 > 5.7 も考え始めないと 27
  10. これまで(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 クラッシュ! エンジニア全員で祭りが発生w - Bug #84107 Severe slowdown on partitioned table with simple ORDER BY ASC change to DESC 29
  11. これまで(5年目) 2016年 引き続き苦労している点 - 大きなテーブルのALTERが打てない - 小さなテーブルならオンラインでもできるが大きいと無理 - 裏側でリードレプリカでALTERしてマスタとひっくり返す -

    ロック関連 - サーバーの処理能力が上がってもロック関連は1インスタンス だとツライ - 早くDBやシステムの分割をしたい、2017年こそやる 30
  12. 使っているハードウェア © Money Forward,Inc. 31 - さくらの専用サーバ(エンタープライズシリーズ) - CPU 56コア(HT)(次は80コアへ)

    - メモリ 256 GB - SSD RAID 10大盛り+PCI SSD - IOPS は2万~3万 IOPS - メインのDB以外は - AWSや一部GCPも使っています - インフラ全体の台数は - 500台ぐらいでした(現在は700台以上)
  13. ちなみに(登壇後スライド追加) © Money Forward,Inc. 36 - 本日の資料(グラフ)に使ったレコード件数のカウント方法 - information_schema の

    table_rows は使っていません - 正しい件数が取得できないため - どうやっているか - 今日、この日のために select count 用レプリサーバーで - 日次バッチで全件カウントし、CSVに保存していました - 最近は24時間でも終わらず、3日に1回、回しています 某、O社の方から疑問の声が 上がったようなので このスライド追加 (実は、真面目に数えています)
  14. © Money Forward,Inc. 自己紹介 飯田 祐基(いいだゆうき) サービスインフラグループ ▪ 2006年 株式会社インターネットイニシアティブ入社

    、サーバ、ネットワークエンジニアとしてインフラ業 務に従事 ▪ 2009年 pixiv株式会社入社、インフラエンジニアとし てデータセンタの立ち上げ、ネットワーク構成全般、 画像配信、広告配信サーバの設計・構築などを行う ▪ 2012年 株式会社SKIYAKI入社、Railsエンジニアとし てアーティスト公式サイト運営プラットフォームの開 発に従事、その後CTOとしてエンジニア採用、チーム マネジメントをメインに携わる ▪ 2017年 株式会社マネーフォワード入社、サービスイ ンフラグループにて主にデータベース運用に従事 39
  15. 分割でのツラミ その1 論理分割時にテーブルのデータ量が多いと移設が困難 ❌ 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
  16. 分割でのツラミ その2 どうしてもjoinを止めるのが難しい処理はある。ユースケースの多い広告メー ル配信。サポートでの調査。 ❌ elastic search (ロジックの修正にかなりのコストがかかる) ❌ federatedエンジン

    (遅すぎる、データ量が多いテーブルだと実用的ではない) ❌ マルチソースレプリケーション (複数のマスタからレプリケーションを受ける)で対応 • 構成が複雑 • 分割する度にスレーブを新しく植え付けなければならない • 1つレプリケーションが潰れると、修復がかなり辛い マルチソースレプリケーションは麻薬 (確かに便利ではある、壊れさえしなければ) 51
  17. じゃあどうする? その2 処理が多すぎて、何が影響を与えているのかわからない。全量のクエリを集計 したい。 ❌ general log → 容量が大きくなりすぎる ❌

    tcpdump & pt-query-digest → 同じく容量が大きくなりすぎる ❌ binlog → 参照系クエリが取れない ❌ packet beats → SSL接続しているので無理 ❌ performance_schemaを利用する 特にevents_statements_summary_by_digestが便利 • どんなSQLが? • どのくらいの実行待ちや、ロック待ち、レコード数の操作をしてるかを • SQLの変数部分を無視してサマライズした形で • 起動時からの合計値を出してくれる 54
  18. 最適化事例 User.findメソッドをキャッシュ化 • 一つ一つのクエリは軽い(スロークエリには現れにくい) • とにかく量が多い。日中ずっと負荷が乗っている • 単純なクエリなのでキャッシュにしやすい • findメソッドを手入れして、開発者は意識せずにキャッシュを利用できるように

    朝の入出金メール通知を参照分割 • 朝8時くらいから極端に負荷をかけていた • DBでステート管理しているため、更新料が多い(未解決) • ほぼ全ユーザ分をなめるので、もちろん参照も多い • 参照分割(少しくらいの遅延は致命的じゃないので) どの時間に、何が負荷をかけているのか?が透けて見えてくる 57
  19. 今後の展望 • 更新量が多いデータはKVS化 • elastic searchを活用して、カウント、ソート負荷を分散 • 増えゆくデータと戦うためにシャーディング、分散DBなどを検討 • マネーフォワードのサービスはユーザがほとんど自分のデータを見ることしかない

    • ユーザの関心が高いのは時系列的に最近データがほとんど • 参照にかたよりが少ないため一般的なキャッシュ戦略はとりづらい サービス特性にあわせたキャッシュ戦略 自分のデータ分くらいなら、スマホアプリ側のローカルに十分に乗せられるはず ローカルデータならマシンリソースもユーザ側に分散できる レスポンスも速いし、オフラインでも使える ⬇❌ 58