#devdays Stackoverflowのイベントでの発表資料． http://devdays.peatix.com

1. Zaim 500万ユーザに向けて
株式会社 Zaim
西本 航 ( watura )
パーティションとシャーディング

2. 自己紹介
2
エンジニア
iOS WEB インフラ
株式会社Zaim 西本 航 ( @watura )

4. Zaimから2人目の発表なので，
もうZaimの説明大丈夫ですよね？

5. Zaimは
- iOS
- Android
- Web
- Windows
でうごいてます

6. iOS版Zaim
6
Titaniumで動いてます が，
時代はSwift Realm ReactiveCocoaへ
201X年Y月 リリース予定

7. エンジニア探してます
Web, インフラ等々やりながら
Swift版も作っているのでリソースが足りていません
• Swift
• Ruby (Ruby on Rails)
• Java ( Android )
• PHP
• ReactiveCocoa4
• Realm
• AWS
• MySQL
とかとかできるエンジニア探してます！
7

8. 注意
MySQL, RDS初心者が試行錯誤
→不正確，不適切である場合が多々あります
より良い方法，より適切な説明等あれば後で教えて
ください！！
間違っていても怒らないでください
8スライド作ったら以外と長かったので巻きでいきます

9. ZaimのDB構成
• おもに Amazon RDS for MySQLを利用
• user_idのRangeでパーティションを設定
- 家計簿情報はユーザごとに交わらない
• 今回対象のDB規模
- XXX億のレコード数
- ものすごく膨大なI/O
9

10. パーティションとは(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が

11. パーティションとは(2)
ルールに当てはまらないデータが来ると
11
user_idが51のデータ?
0から10
11から20
21から30
31から40
41から50
user_idが

12. パーティションとは(2)
ルールに当てはまらないデータが来ると
エラーが発生する
どこにいれたらいいかわからないってなる 12
user_idが51のデータ
0から10
11から20
21から30
31から40
41から50
user_idが

13. Zaimに危機が
13
ユーザ数が400万を超えている
パーティションの最大値を500万としている
Zaimを使えないユーザが出てきてしまう危機
まさかこれほどユーザが増えるとは

14. パーティション変更
目標: パーティションを1000万ユーザまでに設定する
利用: pt-online-schema-change
テスト環境: (他にI/Oがない環境)
- 何の問題もなく成功した
テスト環境その2：(膨大なI/Oがある環境)
- すごい勢いでデッドロックが発生
- そして失敗した
いろいろ試したがすべて失敗した
14

15. 迫る危機
• 試行錯誤1回1回に数時間はかかる
• 時間がたつにつれてDBは増大する
これは良くない
サービス停止メンテナンスをするしかない！
15

16. 停止メンテ
• せっかく停止するんだから普段できなことを!
- DBが大きすぎるのが悪い→シャーディング
• シャーディングとは： データベースの分割
16

17. やること
• 1つのDBを複数の少し小さいDBにする
- 今回は5つ
• 元DBのデータを5つに分割する
- mod(user_id, 5) = X みたいな
• 5つのデータベースの設定を調整
- auto_increment_increment
- auto_increment_offset とか
• サービス側が適切に接続するように変更
やることは簡単ですね 17

18. 準備編 (dump)
テスト環境でどれだけかかるか試してみた
• 愚直に以下を5回
- mysqldumpのwhere optionにmod(user_id, 5)＝0
- 冗談じゃないほど時間がかかる
• ↑を&でつないで5並列
- 冗談じゃないほど時間がかかる
18
24時間停止してメンテするの？

19. 準備編 (dump)
• パーティションごとにdumpする
- where で user_id>=0 and user_id < 10 and mod…
- 早い！
• パーティションごとに並列で接続
- めちゃめちゃ早くなった
20時間 → 80分
19

20. 準備編 (インサート)
• 普通にインサート
- 普通に遅い
• transactionやめたら → 並列で書き込んでくれる？
- めちゃくちゃ遅くなる → 書き込んでくれない
• パーティションごとに書き込む
- やっぱり早くなる
- でも，だんだん遅くなる
• Index削除してみる
- ずっと早い状態
• binlogとかを書かないようにする
- 早くなる
20

21. これらの処理ってメンテの時にじゃなくてもいいんじゃない？
事前にやっておいて，メンテのときは差分でいいんじゃない？
軽く測定してみた
1時間あれば全て終わる

22. 結論
• Index, パーティションを有効に使う
• 並列できるところは並列化する
• Transactionは大きいほど早い
• ログは書き込まない方が容量削減とかに繋がる
• 事前にできることがあるなら事前にする
• Amazonの動向をチェックしておく
22

23. 23

24. 24

25. Amazon Auroraを東京リージョンで
ご利用頂けるようになりました！！！

26. 既にデータサイズやデータベースサーバあたり
のトランザクションを減らすために、
複数のデータベースサーバにシャーディングを
行っている環境でAmazon Auroraを利用するこ
とで、
複数存在したデータベースサーバを少数の
Amazon Auroraクラスタに集約することができ

27. ちょっとだけAurora 使ってみようかな
と考えています
ご清聴ありがとうございました