Successfully reported this slideshow.
Your SlideShare is downloading. ×

Zaim 500万ユーザに向けて

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 27 Ad
Advertisement

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to Zaim 500万ユーザに向けて (20)

Advertisement

Zaim 500万ユーザに向けて

  1. 1. Zaim 500万ユーザに向けて 株式会社 Zaim 西本 航 ( watura ) パーティションとシャーディング
  2. 2. 自己紹介 2 エンジニア iOS WEB インフラ 株式会社Zaim 西本 航 ( @watura )
  3. 3. Zaimから2人目の発表なので, もうZaimの説明大丈夫ですよね?
  4. 4. Zaimは - iOS - Android - Web - Windows でうごいてます
  5. 5. iOS版Zaim 6 Titaniumで動いてます が, 時代はSwift Realm ReactiveCocoaへ 201X年Y月 リリース予定
  6. 6. エンジニア探してます Web, インフラ等々やりながら Swift版も作っているのでリソースが足りていません • Swift • Ruby (Ruby on Rails) • Java ( Android ) • PHP • ReactiveCocoa4 • Realm • AWS • MySQL とかとかできるエンジニア探してます! 7
  7. 7. 注意 MySQL, RDS初心者が試行錯誤 →不正確,不適切である場合が多々あります より良い方法,より適切な説明等あれば後で教えて ください!! 間違っていても怒らないでください 8スライド作ったら以外と長かったので巻きでいきます
  8. 8. ZaimのDB構成 • おもに Amazon RDS for MySQLを利用 • user_idのRangeでパーティションを設定 - 家計簿情報はユーザごとに交わらない • 今回対象のDB規模 - XXX億のレコード数 - ものすごく膨大なI/O 9
  9. 9. パーティションとは(1) データを特定のルールに従って格納すること user_idでまとめてデータを取ってくるので早くなる 10 0から10 11から20 21から30 31から40 41から50 user_id が10のデータ user_id が15のデータ user_id = 44のデータ user_idが
  10. 10. パーティションとは(2) ルールに当てはまらないデータが来ると 11 user_idが51のデータ? 0から10 11から20 21から30 31から40 41から50 user_idが
  11. 11. パーティションとは(2) ルールに当てはまらないデータが来ると             エラーが発生する     どこにいれたらいいかわからないってなる 12 user_idが51のデータ 0から10 11から20 21から30 31から40 41から50 user_idが
  12. 12. Zaimに危機が 13 ユーザ数が400万を超えている パーティションの最大値を500万としている Zaimを使えないユーザが出てきてしまう危機 まさかこれほどユーザが増えるとは
  13. 13. パーティション変更 目標: パーティションを1000万ユーザまでに設定する 利用: pt-online-schema-change テスト環境: (他にI/Oがない環境) - 何の問題もなく成功した テスト環境その2:(膨大なI/Oがある環境) - すごい勢いでデッドロックが発生 - そして失敗した いろいろ試したがすべて失敗した 14
  14. 14. 迫る危機 • 試行錯誤1回1回に数時間はかかる • 時間がたつにつれてDBは増大する これは良くない サービス停止メンテナンスをするしかない! 15
  15. 15. 停止メンテ • せっかく停止するんだから普段できなことを! - DBが大きすぎるのが悪い→シャーディング • シャーディングとは: データベースの分割 16
  16. 16. やること • 1つのDBを複数の少し小さいDBにする - 今回は5つ • 元DBのデータを5つに分割する - mod(user_id, 5) = X みたいな • 5つのデータベースの設定を調整 - auto_increment_increment - auto_increment_offset とか • サービス側が適切に接続するように変更 やることは簡単ですね 17
  17. 17. 準備編 (dump) テスト環境でどれだけかかるか試してみた • 愚直に以下を5回 - mysqldumpのwhere optionにmod(user_id, 5)=0 - 冗談じゃないほど時間がかかる • ↑を&でつないで5並列 - 冗談じゃないほど時間がかかる 18 24時間停止してメンテするの?
  18. 18. 準備編 (dump) • パーティションごとにdumpする - where で user_id>=0 and user_id < 10 and mod… - 早い! • パーティションごとに並列で接続 - めちゃめちゃ早くなった 20時間 → 80分 19
  19. 19. 準備編 (インサート) • 普通にインサート - 普通に遅い • transactionやめたら  →  並列で書き込んでくれる? - めちゃくちゃ遅くなる →   書き込んでくれない • パーティションごとに書き込む - やっぱり早くなる - でも,だんだん遅くなる • Index削除してみる - ずっと早い状態 • binlogとかを書かないようにする - 早くなる 20
  20. 20. これらの処理ってメンテの時にじゃなくてもいいんじゃない? 事前にやっておいて,メンテのときは差分でいいんじゃない? 軽く測定してみた 1時間あれば全て終わる
  21. 21. 結論 • Index, パーティションを有効に使う • 並列できるところは並列化する • Transactionは大きいほど早い • ログは書き込まない方が容量削減とかに繋がる • 事前にできることがあるなら事前にする • Amazonの動向をチェックしておく 22
  22. 22. 23
  23. 23. 24
  24. 24. Amazon Auroraを東京リージョンで ご利用頂けるようになりました!!!
  25. 25. 既にデータサイズやデータベースサーバあたり のトランザクションを減らすために、 複数のデータベースサーバにシャーディングを 行っている環境でAmazon Auroraを利用するこ とで、 複数存在したデータベースサーバを少数の Amazon Auroraクラスタに集約することができ
  26. 26. ちょっとだけAurora 使ってみようかな と考えています ご清聴ありがとうございました

×