Tweet
Tweet

Slide 1

Slide 1 text

365 日 24 時間稼働必須サービスの 完全無停止 DB 移行 〜 MongoDB to Amazon Aurora 〜

Slide 2

Slide 2 text

Hi! I’m kyuden ● Github: kyuden ● Twitter: @kyuden_ ● Sorcery gem commiter ● https://github.com/Sorcery/sorcery ● Banken gem creator ● https://github.com/kyuden/banken ● WEB+DB Press Ruby 連載 (vol96~101)

Slide 3

Slide 3 text

どんなサービス ?

Slide 4

Slide 4 text

collection の規模感 RubyKaigi 2017

Slide 5

Slide 5 text

Ruby biz Grand prix 2017

Slide 6

Slide 6 text

Our Team

Slide 7

Slide 7 text

はじまりはじまり

Slide 8

Slide 8 text

昨年 7 月に 38 億レコード ( ドキュメント ) を 不整合データなし ダウンタイムゼロで MongoDB から Amazon Aurora に データ移行した

Slide 9

Slide 9 text

昨年 7 月に 38 億レコード ( ドキュメント ) を 不整合データなし ダウンタイムゼロで MongoDB から Amazon Aurora に データ移行した

Slide 10

Slide 10 text

このトークで主に話すこと ● 具体的なデータ移行方法 ● 移行のために作ったツールの設計 / 内部実装

Slide 11

Slide 11 text

移行対象のコレクション ● node_values ● 翻訳データが格納されたコレクション ● 約 12 億ドキュメント ● page_node_values ● どのページにどの翻訳データがあるかが格納されたコレク ション ● 大まかに言うと page と node_values のジャンクションテー ブル ( ジャンクションコレクション ) ● 約 26 億ドキュメント

Slide 12

Slide 12 text

制約 ● そもそもダウンタイムゼロである必要はあったのか ● 仮にダウンタイムがあっても翻訳データはキャッシュされ ているので 10000+ の Web サイト / サービスは翻訳可能 ● しかし、ダウンタイムがあるとその間は翻訳の作成 / 更新 / 削除は不可能 ● ユーザは日本だけでなく世界中に存在 ● たとえば、 EC サイトなどは頻繁に新しいページが公開され るが、その間新しい翻訳がなされないと元言語以外を使用 するユーザからの売上は確実に減少する ● ビジネスサイドと話し合いをした結果、数分であればダウ ンタイムの許可は取れそう ● しかし、ダウンタイムゼロにこしたことはないし、エンジ ニアとしはチャレンジングなのでやりたかった

Slide 13

Slide 13 text

なぜ MongoDB から移行するのか ● そもそもスキーマレスである必要がなかった ● 厳密な整合性求められるケースが増えてきた ● Mongos 突然の死 ( 不安定 ) ● クエリが激烈に重くなり調べてみるとある Mongo サーバー だけインデックスがはられていない ● Mongoid の機能不足 ● 小さなチームにはメンテナンスコストが高すぎた ● Etc ● ちゃんと話そうとすると時間足りないので省略。別の機会 にでも。なぜ Aurora なのかも同じく省略

Slide 14

Slide 14 text

移行手順

Slide 15

Slide 15 text

Step0: アプリケーションコードの修正 両方の DB を使えるようアプリケーションコードを修正する ● すべての DB アクセスを Abstracter クラス経由に書き換える ● ユーザごとにどちらの DB を使用するかのフラグを持たせる ● `use_mongo?` はフラグを参照している ● フラグは MongoDB にある users collection の field

Slide 16

Slide 16 text

移行ステップと対応するフラグ名一覧 Write Read Read Write 2 Read Write 1 Read Write Write 1 Write 2 aurora_write aurora_read aurora Step 1 Step 2 Step 3 Step 4 nil Aurora Aurora Aurora Aurora

Slide 17

Slide 17 text

移行ステップと対応するフラグ名一覧 aurora_write aurora_read aurora Step 1 Step 2 Step 3 Step 4 nil

Slide 18

Slide 18 text

移行ステップと対応するフラグ名一覧 aurora_write aurora_read aurora Step 1 Step 2 Step 3 Step 4 nil

Slide 19

Slide 19 text

移行ステップと対応するフラグ名一覧 aurora_write aurora_read aurora Step 1 Step 2 Step 3 Step 4 nil

Slide 20

Slide 20 text

移行ステップと対応するフラグ名一覧 aurora_write aurora_read aurora Step 1 Step 2 Step 3 Step 4 nil

Slide 21

Slide 21 text

移行ステップと対応するフラグ名一覧 aurora_write aurora_read aurora Step 1 Step 2 Step 3 Step 4 nil

Slide 22

Slide 22 text

移行ステップと対応するフラグ名一覧 aurora_write aurora_read aurora Step 1 Step 2 Step 3 Step 4 nil

Slide 23

Slide 23 text

移行ステップと対応するフラグ名一覧 aurora_write aurora_read aurora Step 1 Step 2 Step 3 Step 4 nil

Slide 24

Slide 24 text

移行ステップと対応するフラグ名一覧 aurora_write aurora_read aurora Step 1 Step 2 Step 3 Step 4 nil

Slide 25

Slide 25 text

Step1: Abstractor を経由していることを保証する Write Read ● フラグは nil ● これまで通り R/W が MongoDB に対して行わ れている状態 ● これまでと違うのは Abstractor を経由して R/W が行われていること ● Moped::Query#initialize にモンキーパッチをあ てクエリを組み立てる前に Abstractor を経由 して呼びだされていなければ警告を出すよ うにした ● Step1 をデプロイし 2,3 日様子をみて上記の 警告が出ていなければ全ての DB へのアクセ スが Abstractor 経由で行われていることをお およそ保証できる nil Aurora

Slide 26

Slide 26 text

Step 2: MongoDB に Write した後 Aurora にも Write する ● フラグは aurora_write ● Step1 と同じく R/W は MongoDB に対して行う ● Step1 と違うのは Mongo への Write に成功し た後 Aurora にも Write すること ● aurora_write フラグをつけるのはある時点の MongoDB のデータを Aurora に移行する Rake タスク Aurora inserter を実行した後 ● aurora_write フラグがついたら Aurora inserter タスク実行中に変更されたデータを aurora に移行する aurora_upserter タスクを実行する Read Write 2 Write 1 aurora_write Aurora

Slide 27

Slide 27 text

Aurora inserter Rake タスクとは ● Aurora Inserter とは実行開始時点 (A) 以前に更 新された MongoDB のデータを Aurora のスキ ーマに合わせて Insert する Rake タスク ● ユーザごとに実行しエラーなしで Insert が 完了した後、そのユーザに対して aurora_write フラグを付与する ● 地点 A での MongoDB のデータを Aurora に移 行できる ● タスク実行中の地点 A~B に変更のあったデ ータも関しては Aurora にはない状態 ( ユー ザごとなので A~B の期間は短い ) ● 地点 B 以降は aurora_write フラグにより MongoDB と同じのデータが Aurora にも書き 込まれる A B A: タスク実行開始 B: タスク実行終了

Slide 28

Slide 28 text

Step 2: MongoDB に Write した後 Aurora にも Write する ● フラグは aurora_write ● Step1 と同じく R/W は MongoDB に対して行う ● Step1 と違うのは Mongo への Write に成功し た後 Aurora にも Write すること ● aurora_write フラグをつけるのはある時点の MongoDB のデータを Aurora に移行する Rake タスク Aurora inserter を実行した後 ● aurora_write フラグがついたら aurora inserter タスク実行中に変更されたデータを aurora に移行する aurora_upserter タスクを実行する Read Write 2 Write 1 aurora_write Aurora

Slide 29

Slide 29 text

Aurora upserter Rake タスク ● Aurora upserter タスクとは指定された期間に 変更のあった MongoDB のデータを Aurora の スキーマに合わせて Insert or Update or Delete する Rake タスク ● Aurora upserter タスクの期間として Aurora Inserter タスク実行中の地点 AB を指定する ことでユーザごとにすべてのデータを Aurora に移行できる ● Aurora upserter タスク実行後、ユーザごとに すべてのデータが両方の DB に存在するかを チェックする Rake タスク consistency checker を実行する ● Aurora checker タスクに失敗する場合は Abstractor や Aurora へのデータコンバートな どにバグがある可能性があるので修正し て、再度 Aurora upserter タスクをかける A B A: タスク実行開始 B: タスク実行終了

Slide 30

Slide 30 text

Step 3: Aurora から Read する ● フラグは aurora_read ● R/W を Aurora に対して行う ● Aurora への Write に成功した後 MongoDB にも Write する (step2 とは逆 ) ● aurora_read フラグをつけるのは consistency checker タスクを実行し両方の DB に同じデ ータがあることを確認した後 ● MongoDB にも Write しているので、 Aurora へ の R/W でなにか問題が発生した場合、デプ ロイなしですぐに aurora_write フラグに戻し MongoDB の R/W に戻すことができる aurora_read Read Write 1 Write 2 Aurora

Slide 31

Slide 31 text

Step 4: Aurora のみを使う ● フラグは aurora ● Aurora のみを使う ● すべてのユーザに対して aurora フラグがつ いたらデータ移行完了 ● その後、 Abstractor を削除してフラグを参照 せず常に Aurora を使うようリファクタした 後、全ユーザーの Aurora フラグを削除する aurora Read Write

Slide 32

Slide 32 text

移行ステップと対応するフラグ名一覧 Write Read Read Write 2 Read Write 1 Read Write Write 1 Write 2 aurora_write aurora_read aurora Step 1 Step 2 Step 3 Step 4 nil Aurora Aurora Aurora Aurora

Slide 33

Slide 33 text

フラグ実装のポイント ● フラグを切り替えた瞬間に現在処理中のリクエストが MongoDB から Aurora に切り替わるとタイミングによってはエ ラー発生 or 不整合データができる ● リクエストごとに利用するフラグは同じものを利用する必 要がある

Slide 34

Slide 34 text

フラグ実装のポイント ● Controller のインスタンス変数として保持する方法 ● ● ● ● フラグは様々な箇所で参照されるため、この設計の場合 Controller から current_flag を引数で引き回すことになりいま いち

Slide 35

Slide 35 text

フラグ実装のポイント ● クラス変数にフラグを保持してグローバルで参照 ● ● ● ● こんなことはやってはいけない ● スレッドセーフではない

Slide 36

Slide 36 text

フラグ実装のポイント ● `Thread.local` に flag を保持しグローバルに参照 ver1 ● ● ● ● ● ● ● ● スレッドセーフだが同じスレッドが別のリクエストを処理 した場合、前回のリクエストでセットした値が格納された ままなので、これもよくない

Slide 37

Slide 37 text

フラグ実装のポイント ● `Thread.local` に flag を保持しグローバルに参照 ver2 ● ● ● ● ● ● ● ● リクエストごとに必ず値をクリアすれば OK ● もしくはフラグセット時に `||=` せず毎回上書きしてもよい ● もしくは steveklabnik/request_store gem 使うのがよい

Slide 38

Slide 38 text

フラグ実装のポイント ● Rails5.2 にマージされた ActiveSupport::CurrentAttributes もやりたいこ とは同じでリクエストごとにグローバルな値を保持できる

Slide 39

Slide 39 text

フラグベースのデータ移行のデメリット ● すべてのデータを一回で移行し新しいコードベースで動かす方 法と比べると、アプリケーションコードの修正コストがかかる ● ユーザごとのデータ移行なので一回で移行するより時間がかか る ● Step2,3 は両方の DB に書き込むので、増えた分多少レスポンスタ イムが増えサーバー負荷があがる

Slide 40

Slide 40 text

フラグベースのデータ移行のメリット ● ダウンタイムがない ● すべてのデータを一回で移行し移行先の DB を利用した新しいコ ードベースで動かす方法と比べると、ユーザごとにデータ移行 と新しいコードベースを徐々に使うことで、バグの影響範囲を 小さくしかつバグ早期発見が可能 ● なにか問題が発生したとき ● 小さいスコープで ( ユーザごとに ) ● できるだけはやく ( コード修正 && デプロイなしでフラグを 更新するだけで ) ● 正常に動く状態に戻すことができる ( 元の DB を利用しサー ビスを提供し続けることができる )

Slide 41

Slide 41 text

移行ツールの内部実装

Slide 42

Slide 42 text

移行ツールの内部実装 ● Aurora Inserter タスクとは ● 実行開始時点以前に更新された MongoDB のデータを Aurora のスキーマに合わせて Insert する Rake タスク ● Aurora Inserter タスクが内部でやっていること 1. node_values のデータ移行 2. page_node_values のデータ移行 3. page_node_values にある node_values の外部キーを更新 ● MongoDB では主キーに BSON::ObjectId を使用していたが、 Aurora 移行に伴い auto increment される id を使用したかっ たため。 ( なお MongoDB の主キーは mongo プリフィック スをつけて mongo_id として varchar で Aurora にも保持 )

Slide 43

Slide 43 text

移行ツールの内部実装 ● Aurora Inserter タスクのパフォーマンス ● 1500 レコード ( ドキュメント ) / 秒 ● (text 型のデータもあるのでレコード単位での計測結果は 正確とは言えないが、移行するレコード数からおおよそ の実行時間を見積もることができる位の精度 ) ● 7 億レコード保持するユーザも存在し、このユーザだけで 約 5.4 日かかる計算 ( そんなに待ちたくない ) ● Aurora Inserter タスク以外にも Aurora upserter や consistency checker タスクのことも考えるとさらに時間がかかる ● I / O の割合が多いんだから thread 使って書きなおすことに した

Slide 44

Slide 44 text

移行ツールの内部実装 ● Producer Consumer パターン Producer 1 Producer 3 Producer X Consumer 1 Consumer 2 Consumer X Queue ● Producer は仕事に必要なデータを生産して Queue に詰める ● Consumer は Queue からデータを取り出して仕事を消費する ● ある Producer が Queue を参照し書き込み終わるまで、他の Producer に割り込まれてはいけない ● ある Consumer が Queue を参照し取り出すまで、他の Consumer に割り込まれてはいけない ● Queue が上限まできたら書き込みを待ち、空なら取り出すの をまたなければいけない

Slide 45

Slide 45 text

移行ツールの内部実装 ● Producer Consumer パターン Producer 2 Consumer 2 Queue Producer 1 Producer 3 Consumer 1 Consumer X ● Producer は MongoDB から移行データを取得して Queue につめる ● Consumer は移行データを Queue から取りだし Aurora 用に加工し Aurora につめる ● Thread 数の調整や Queue の中継によって Producer と Consumer 間 の処理スピードの差異を吸収しパフォーマンスの向上が期待 できる ● 簡略化したサンプルコードは次のスライドに掲載 Aurora

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

作戦

Slide 48

Slide 48 text

マルチスレッド

Slide 49

Slide 49 text

移行ツールの内部実装 ● Aurora Inserter タスク ver マルチスレッドのパフォーマンス ● スレッド数 (producer 2, consumer 6) ● コア数 4 ● 2300 レコード ( ドキュメント ) / 秒 1.5x faster ● 7 億レコード保持するユーザが約 3.5 日かかる計算 ( そんな に待ちたくない ) ● コア数とスレッド数を上げればパフォーマンスは上がる が、 I / O 以外の処理も並列にできればさらなるパフォー マンスの向上が期待できた ● そこで

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

マルチサーバー

Slide 52

Slide 52 text

JRuby 採用理由 ● Real threading でマルチコアを活用したい ● jruby-9.1.8.0

Slide 53

Slide 53 text

JRuby 採用理由 ● Real threading でマルチコアを活用したい ● jruby-9.1.8.0 ● 余談 : ProducerConsumer パターンを実装する際、ひそかに JRuby でも動かせるよう書いていた

Slide 54

Slide 54 text

ディレクトリ構成 ● Rails アプリのルートディレク トリで `mkdir juby` して `rbenv local jruby-9.1.8.0` ● Gemfile には `activerecord- jdbcmysql-adapter` と `mongoid` を 指定。 DB の接続情報を jruby/config 配下に記載 ● jruby/models 配下に Rails の app/models 配下のモデルファイ ルなど今回使用するファイル をコピーする ● Rails アプリで使用していた Gem に依存したコードを削除 ● 細かいところはまだあるが、 おおよそこれで動く

Slide 55

Slide 55 text

移行ツールの内部実装 ● Aurora Inserter タスク (JRuby マルチスレッドのパフォーマンス ) ● スレッド数 (producer 2, consumer 6) ● コア数 4 ● 4300 レコード ( ドキュメント ) / 秒 2.8x faster ● 7 億レコード保持するユーザが約 1.9 日かかる計算 ( そんなに 待ちたくない ) ● 10x 以上はやくしたい ● そこで

Slide 56

Slide 56 text

マルチサーバー X マルチスレッド ● コア数 8 のサーバーを 20 台用意 ● 移行対象のドキュメントの主キーを 20 分割し、各サーバにファ イルとして配布 ● 事前に DB 負荷状況や同時接続数の上限などを確認 ● 実装の都合上、 Aurora Inserter の処理 (step1~3) の step3 は全サーバ ーが step1,step2 を終わってから実行する必要があった。ようは マルチサーバーとはいえ同期的に各 Step を行う必要があった

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

capistrano/sshkit gem ● Capistrano gem の dependency に指定されている gem で Capistrano の ssh 関連のコードはこの sshkit gem のラッパー ● ssh 経由でパラレルに実行する部分と同期的に実行する部分 を DSL で簡単に指定できる ● sshkit は JRuby で CI が回っていなかったため Rails アプリ側の gemfile に追加し Rails の rake タスクから jruby のコードを実行

Slide 59

Slide 59 text

所管

Slide 60

Slide 60 text

結果

Slide 61

Slide 61 text

2.4 時間 54x faster

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

FIN