Zaim 500万ユーザに向けて

株式会社 Zaim

西本 航 ( watura )

パーティションとシャーディング

自己紹介

2

エンジニア iOS　WEB　インフラ

株式会社Zaim 西本 航 ( @watura )

Zaimから2人目

の発表なので

，

もうZaimの説明大丈

夫ですよね？

Zaimは- iOS- Android- Web- Windows

でうごいてます

iOS版Zaim

6

Titaniumで動いてます　が，

時代はSwift Realm ReactiveCocoaへ 201X年Y月　リリース予定

エンジニア探してますWeb, インフラ等々やりながら

Swift版も作っているのでリソースが足りていません

• Swift • Ruby (Ruby on Rails) • Java ( Android ) • PHP • ReactiveCocoa4 • Realm • AWS • MySQL

とかとかできるエンジニア探してます！7

注意MySQL, RDS初心者が試行錯誤 →不正確，不適切である場合が多々あります

より良い方法，より適切な説明等あれば後で教えてください！！

間違っていても怒らないでください

8スライド作ったら以外と長かったので巻きでいきます

ZaimのDB構成• おもに Amazon RDS for MySQLを利用

• user_idのRangeでパーティションを設定 - 家計簿情報はユーザごとに交わらない

• 今回対象のDB規模 - XXX億のレコード数

- ものすごく膨大なI/O

9

パーティションとは(1)データを特定のルールに従って格納すること

user_idでまとめてデータを取ってくるので早くなる10

0から1011から2021から3031から4041から50

user_id が10のデータ

user_id が15のデータ

user_id = 44のデータ

user_idが

パーティションとは(2)ルールに当てはまらないデータが来ると

11

user_idが51のデータ?0から1011から2021から3031から4041から50

user_idが

パーティションとは(2)ルールに当てはまらないデータが来ると

　　　　　　　　　　　　エラーが発生する 　　　　　

どこにいれたらいいかわからないってなる 12

user_idが51のデータ0から1011から2021から3031から4041から50

user_idが

Zaimに危機が

13

ユーザ数が400万を超えている

パーティションの最大値を500万としている

Zaimを使えないユーザが出てきてしまう危機

まさかこれほどユーザが増えるとは

パーティション変更目標: パーティションを1000万ユーザまでに設定する

利用: pt-online-schema-change

テスト環境: (他にI/Oがない環境)- 何の問題もなく成功した

テスト環境その2：(膨大なI/Oがある環境)- すごい勢いでデッドロックが発生 - そして失敗した

いろいろ試したがすべて失敗した14

迫る危機• 試行錯誤1回1回に数時間はかかる

• 時間がたつにつれてDBは増大する

これは良くない サービス停止メンテナンスをするしかない！

15

停止メンテ• せっかく停止するんだから普段できなことを!

- DBが大きすぎるのが悪い→シャーディング

• シャーディングとは： データベースの分割

16

やること• 1つのDBを複数の少し小さいDBにする

- 今回は5つ

• 元DBのデータを5つに分割する - mod(user_id, 5) = X　みたいな

• 5つのデータベースの設定を調整 - auto_increment_increment - auto_increment_offset とか

• サービス側が適切に接続するように変更

やることは簡単ですね 17

準備編 (dump)テスト環境でどれだけかかるか試してみた • 愚直に以下を5回

- mysqldumpのwhere optionにmod(user_id, 5)＝0 - 冗談じゃないほど時間がかかる

• ↑を&でつないで5並列 - 冗談じゃないほど時間がかかる

1824時間停止してメンテするの？

準備編 (dump)• パーティションごとにdumpする

- where で user_id>=0 and user_id < 10 and mod… - 早い！

• パーティションごとに並列で接続 - めちゃめちゃ早くなった

20時間 → 80分

19

準備編 (インサート)• 普通にインサート

- 普通に遅い

• transactionやめたら 　→　　並列で書き込んでくれる？ - めちゃくちゃ遅くなる　→ 　 書き込んでくれない

• パーティションごとに書き込む - やっぱり早くなる - でも，だんだん遅くなる

• Index削除してみる - ずっと早い状態

• binlogとかを書かないようにする - 早くなる

20

これらの処理ってメンテの時にじゃなくてもいいんじゃない？

事前にやっておいて，メンテのときは差分でいいんじゃない？

軽く測定してみた 1時間あれば全て終わる

結論• Index, パーティションを有効に使う • 並列できるところは並列化する • Transactionは大きいほど早い • ログは書き込まない方が容量削減とかに繋がる

• 事前にできることがあるなら事前にする

• Amazonの動向をチェックしておく22

23

24

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

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

ちょっとだけAurora 使ってみようかな と考えています

ご清聴ありがとうございました