Zaim 500万ユーザに向けて

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