Zaim 500万ユーザに向けて〜Aurora 編〜

家計簿サービス
株式会社 Zaim
西本航
500万ユーザに向けて
Aurora編

© 2016 Zaim Inc. All rights reserved.
自己紹介
2
エンジニア
iOS Web インフラ
株式会社 Zaim 西本航（@watura)

家計簿サービス「Zaim」
3
クチコミで普及した国内最大級のオンライン家計簿
もうすぐ500万ダウンロード!!

info@zaim.net
一緒に働く仲間を募集中!
https://www.wantedly.com/companies/Zaim

目次
5
•DB構成
•パーティション？
•危機到来
•DB分割
•Aurora移行
•発生した障害
しっかりとしたログがあったらよかったんですが，今回はそこまで気が回らなかった
のでありません

DB構成
6
•おもに Amazon RDS for MySQL を利用
•user_id の Range でパーティションを設定
•家計簿情報はユーザごとで，他ユーザと交わらない
•対象DB:
•XXX億のレコード数
•膨大なI/O
•日々増大するレコード

パーティション？
7
•データを特定のルールに従って格納すること
•userごとのデータを取得するとき早くなる
0から10
11から20
21から30
31から40
41から50
user_idが
user_id が 10 のデータ
user_id が 44のデータ

8
→ user_id = 51のデータは？？？
0から10
11から20
21から30
31から40
41から50
user_idが

9
→ user_id = 51のデータは？？？ → エラー!
0から10
11から20
21から30
31から40
41から50
user_idが

最大ユーザ数危機
10
ダウンロード数が400万を超えている
パーティションの最大値を500万としている

最大ユーザ数危機
11
ダウンロード数が400万を超えている
パーティションの最大値を500万としている
Zaimを使えないユーザが出てきてしまう危機
過負荷，容量不足などとは違う洒落にならない危機
まさかこれほどユーザが増えるとは

alter tableすればいいじゃない
12
目的：パーティションを1000万ユーザまでにする
利用：pt-online-schema-change
テスト環境：（他にI/Oがない環境）
•何の問題もなく成功
テスト環境その2：（本番さながらなI/Oを用意）
•すごい勢いでデッドロックが発生
•失敗した
少ない知恵を絞って色々試したが全て失敗した

迫り来る危機
13
一回の試行に数時間はかかる
レコード数は刻一刻と増える

迫り来る危機
14
一回の試行に数時間はかかる
レコード数は刻一刻と増える
負荷は時間が経てば経つほど増える！
本当はやりたくないけど，
サービス停止メンテナンスをするしかない

DB分割開き直って！
15
•せっかく停止するんだから普段できないことを！
•DBが大きすぎるのが悪い → シャーディング
•シャーディング: DBの分割
今回やることは
•1つのDBを5つに分割 (mod(user_id, 5))
•auto_increment_oﬀset
auto_increment_increment,
•サービス側が適切に接続するように設定
簡単だ！

長い長い前置きが終わってAurora
16
•10月頭試行錯誤してメンテするか！
•そういえば re: Invent がある．ちょっと待とう

長い長い前置きが終わってAurora
17
•10月頭試行錯誤してメンテするか！
•そういえば re: Invent がある．ちょっと待とう
•10月7日http://aws.typepad.com/aws_japan/2015/10/amazon-aurora-is-available-in-tokyo.html
•AuroraがTokyo Regionでも使えるだと！！

Auroraいっちゃう？
18
•せっかく停止するんだから普段できないことを！
•部分的にAuroraにしてみる？
•ストレージが勝手にスケールするの嬉しい
•性能いいんだ？
•やるしかない！
•調査
•国内で大きなところが移行してないかなぁ
•安定動作するの？
→Tokyoリージョン出た当初，あんまり情報がなかった
•テーブルにアクセスできなくなることがあった
•alter tableを途中でキャンセルした時？

移行手順
19
• 調査もそこそこに時間もないのでAuroraにする
•シャーディング 5台 → やっぱりしない
•やりたいことはパーティションを1000万にすること！
•手順はほとんど↓を参考に
「わずかなダウンタイムでの Amazon RDS MySQL または MariaDB
DB インスタンスへのデータのインポート」
• http://amzn.to/1PwbLoa
•いきなりはAurora信用しきれない
•MySQL+Auroraとして動かしてみる

やったこと - 登場DB -
20
•元DB(A)
•(A)のMySQLレプリカ(B)
•(B)をもとに作ったMySQLインスタンス(C)
•(C)のSnapshotで作ったAuroraレプリカ(D)
(A)
(B)
(C) (D)
レプリカ
レプリカ
Aurora
アイコンサイズに意味はありません

やったこと（1）
21
•(A)のRead Replica(B)を作る
•同期できたら(B)のReplicationをストップする
•(B)からデータをdumpする
•元DB(A)
•(A)のmysqlレプリカ(B)
•(B)をもとに作ったmysqlインスタンス(C)
(A)
(B)
Dump
Replicate dump

22
•(C)を作成する
•(C)にパーティションを1000万までにしたス
キーマを適用する
•(B)からdumpしたデータを(C)にinsertする
(C)
•元DB(A)
Dump
Schema
replicaをalter partitionするよりこちらの方が早かった

23
•(C)のSnapshotからAuroraDB(D)を作る
•(D)に不要なテーブルをBlackholeEngineにする
•(D)をCのRead Replicaにする
(C)
•元DB(A)
(D)
Aurora
Read
Replica

24
•(C)を(A)のRead Replicaにする
(C)
•元DB(A)
(D)
Aurora
Read
Replica
(A)
Read
Replica
Access

25
•サービス停止メンテ
•アプリ, サービスが(C)に接続するようにする
•(C)のReplicationをストップする
•一回目メンテ終了
(C)
•元DB(A)
(D)
Aurora
Read
Replica
Access
(A)

26
•停止メンテ2回目
•(D)のReplicationをやめる
•条件によって接続先を変更する
(C) (D)
Aurora
Access
•元DB(A)

使用感
27
•一つ小さいインスタンスにしてみた
•CPU利用率60-80%
•レスポンス，メモリ使用量は問題なし
•突発的な高負荷が怖いのでインスタンスサイズUP
→それでもCPU利用率はMySQL時より高い
•Failover早いおよそ1minで切り替わる
•ほぼ障害に気付かれることなく切り替えられた
•インスタンスサイズの変更がやりやすかった
•テレビ露出にも耐えられた
•CPU利用率80%以上まで上がったが問題なし

CPUの利用率
28
•リソースを最大限利用するように設計されている
•MySQLと比較すると利用率が高い傾向がある
•高い状態でもMySQLよりも性能が出る
•もしくは，性能劣化が緩やかである
•利用率が高い == あっぷあっぷ状態ではない！
•モニタを眺めた時に高利用率は心臓に良くない気
がするので大きめなインスタンスに

発生した障害
29
•突然Auroraが劇重になる
•Free Local Storageが枯渇
詳細にログを残しておいたらよかったんですが……

突然Auroraが劇重になる
30
突然
•CPU使用率 100%
•show processlist → unauthenticated user 大量発生
•クエリが詰まる
•再起動すれば復活(特定のプロセスをkill すれば？）
みたいな状態に移行直後からちょくちょくなった
原因調査
•general log, slow queryをDBに出力させた
原因
•重い (全探索に近い) Selectクエリ
対策
•クエリの最適化

Free Local Storageが枯渇
31
•突然Auroraが言う事を聞いてくれなくなる
•SQLコマンドが効かない
•show processlistも動かない
•前ページのように再起動したら復活する？？
→Auroraが再起動しない. 失敗している
•原因解明よりも動くようにすることが先決
•リードレプリカを作成してみる
•最新のデータを諦めてBackupから復元
•Backupに接続する準備している間に再起動完了

Free Local Storageが枯渇
32
•時間
•再起動: 40分
•レプリカ作成: 27分（再起動と同時?)
•バックアップから復元 20分
•原因
•モニタを眺めているとFree Local Storageが枯渇
•「突然Auroraが劇重になる」の時にログをtable
に書き出すようにしたままだったのが原因?
•対策
•ログをtableに書き出すのをやめた
•Free Local Storageを監視するようにした

Free Local Storage??
33
•CloudWatchにある一要素
•モニタリングを表示した時には下の方にいる
•各インスタンスサイズで固定?
知らない子, 誰なんでしょう？？

補足 Free Local Storage
34
•各インスタンス付属のインスタンスストレージ
•tmpテーブル等一時的なテーブルデータを保存
•disk fullになると動作が不安定になってしまう
•この問題をAurora開発チームは認識しており、
修正を行っている最中だそうです
•「Aurora劇重」もこれが原因と考えられる
教えてもらいました

まとめ
35
•パーティションを1000万にしようと思っていた
•最初はMySQLでシャーディング予定だった
•実施直前にTokyo RegionにAurora登場
•やっぱりAuroraにする！
•概ね問題なかったけど，ちょくちょく障害発生
•クエリの最適化不足
•人為的ミスによる障害
•以降は重大なエラーに遭遇していない気がする

info@zaim.net
ご静聴ありがとうございました

Zaim 500万ユーザに向けて〜Aurora 編〜

More Related Content

What's hot

Viewers also liked

Similar to Zaim 500万ユーザに向けて〜Aurora 編〜

Zaim 500万ユーザに向けて〜Aurora 編〜