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

cocone Teck Talk Vol.4 - 膨大になったDBを何とかする /dealing_huge_db

cocone
October 14, 2021

cocone Teck Talk Vol.4 - 膨大になったDBを何とかする /dealing_huge_db

長年運営をしてきた「ポケコロ」のDBに関して、現在の課題とその対応策についてお話します。

cocone

October 14, 2021
Tweet

More Decks by cocone

Other Decks in Programming

Transcript

  1. 膨大になったDBを何とかする
    ポケコロサーバー開発
    忻 楽鳴

    View Slide

  2. ¿名前
    忻 楽鳴
    ¿社歴
    2017年入社して、ポケコロサーバー開発
    を担当しております。
    その前職はSIerとして、5,6年ぐらい調査
    会社のシステム開発をやっていました。大
    量データの取り扱いがそこからです。
    ¿趣味
    ゲーム、寝る
    ¿出身
    上海@中国

    View Slide

  3. まず、現状どうなっている??
    mariaDB、mongoDB、redisDBなど、機能によって使い
    分けています。問題になっているのは mariaDBです。
    左のようにmaster-slave構成となっています。
    masterのdisk使用量が92%まで上昇されています。(月
    3~4%ぐらい増え続ける)
    簡単計算すると何もしないと余命2ヶ月です(笑)
    大量データがあって slow queryも出やすい状態です。
    slave遅延がひどくなるとサービスに影響も出てます。

    View Slide

  4. なにが入ってる??
    所持してるアイテム(約50%)
    アイテムの獲得履歴、異動履歴 (約15%)
    保存してるコーディネート (約15%)
    所持数制限がない
    何と履歴は削除しない!

    View Slide

  5. ・サーバースペックを上げても限界が
    あります
    ・仮に容量を拡張できたとしても、逆
    にslowqueryがもっと酷くなります

    View Slide

  6. まず、データを減らして、容量
    を確保しなきゃ!!!!
    1.  必要のないデータを消す
    2.  保存期間を設ける
    3.  格納するデータを軽量化する
    4.  似てようなデータを1つに

    View Slide

  7. 通帳など履歴データは基本
    3ヶ月しか見せなかった!!

    View Slide

  8. 1.  しょっちゅう問合せがあって、以前の
    データを調べたりする必要がある
    2.  警察に情報の提供を協力する場合も
    ある
    3.  履歴データは分析する材料でもある
    簡単に消すには行かなかった
    んです。。。

    View Slide

  9. 1年以上のデータのことな
    ら問合せがほぼ来ないの
    で、削除OKです
    CXチーム
    どうしても必要の場合、
    BigQueryに移します。
    BIチーム
    利用契約に追記してもらい
    ます
    運営チーム、法務
    バッチ実装して、一定期間
    過ぎたデータを継続的に削
    除しますように
    サーバーチーム
    メンテで過去のデータを削
    除します
    サーバーチーム
    CMSなど参照先を変更な
    ど対応します。
    サーバーチーム

    View Slide

  10. 不要なデータや期間のある履歴を
    消したけど、そこまで減っていなかっ
    たんです

    View Slide

  11. データを移動させ、容量を確保
    できるじゃん!!!!
    1.  同じDBの別インスタンスに移す
    2.  違うDBに移す
    3.  非アクティブユーザーデータのアーカ
    イブ

    View Slide

  12. 同じDBの別インスタンスに移すのは簡
    単そうに見えるんです。
    が、
    オンプレミスなので、DBサーバーを用意
    するのは結構時間が必要です。
    そして、RDBなので、別インスタンスにな
    ると、分散トランザクションに変えなけれ
    ば行けないんです。

    View Slide

  13. MariaDBからMongoDBに移します。
    ・可能の限り1User 1Docment
    ・予めshardingに
    非アクティブユーザーのデータをアーカイブ
    用DB移して削除します
    ・復帰した場合、自動的にデータを戻せる
    仕組みも用意

    View Slide

  14. 92%
    80%
    60%
    今ここ
    disk使用率

    View Slide

  15. View Slide

  16. 将来のために何かを準備しな
    いといけないんだ!!
       容量の危機が一旦回避しただけで
    す。いくつのテーブルが大きいすぎ、
    slow queryなどはまだ解消されていま
    せん
      倍以上のDAU、MAUになった時でも
    耐えられるようにアーキテクチャにシフト
    しないといけません。

    View Slide

  17. View Slide

  18. View Slide