Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Zaim 500万ユーザに向けて

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Wird geladen in …3
×

Hier ansehen

1 von 27 Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Andere mochten auch (20)

Anzeige

Ähnlich wie Zaim 500万ユーザに向けて (20)

Aktuellste (20)

Anzeige

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 使ってみようかな と考えています ご清聴ありがとうございました

×