大量データをFirestoreに効率的に移行する勘所

Slide 1

Slide 1 text

Copyright © 2020 Present ANDPAD Inc. This information is confidential and was prepared by ANDPAD Inc. for the use of our client. It is not to be relied on by and 3rd party. Proprietary & Confidential 無断転載・無断複製の禁止大量データをFirestoreに効率的に移行する勘所株式会社アンドパッド開発本部 SWE 椎野太喜 2021/02/25 ANDPAD & MediaDo 〜BtoB開発の舞台裏〜

Slide 2

Slide 2 text

自己紹介椎野太喜（しいのたいき） ● 出身 ○ 茨城県 ● 経歴 ○ 10人規模のベンチャー → 株式会社アンドパッド ● 専門領域 ○ Webフロントエンド。状況に応じてサーバーサイドなど他の領域にも日々チャレンジしている。 ● 好きなこと ○ 釣り、銭湯 @buena926

Slide 3

Slide 3 text

アジェンダ 1. 背景 2. Firestore移行のゴールは？ 3. データ移行の課題 4. データ移行の全体像 5. 処理パフォーマンス向上に向けてどのように進めていったか 6. データ同期後のデータ検証をどのように進めていったか 7. まとめ

Slide 4

Slide 4 text

1. 背景 Copyright © 2021 Present ANDPAD Inc. This information is confidential and was prepared by ANDPAD Inc. for the use of our client. It is not to be relied on by and 3rd party. Proprietary & Confidential 無断転載・無断複製の禁止

Slide 5

Slide 5 text

背景 ● 2020年7月チャットプロダクトを開発するチームへ参画 ● チャットプロダクトで使用するDBを、Firestoreへ移行が直近のミッション ○ 移行前は、MySQLとFirebase RealtimeDatabaseを使用

Slide 6

Slide 6 text

2. Firestore移行のゴールは？ Copyright © 2021 Present ANDPAD Inc. This information is confidential and was prepared by ANDPAD Inc. for the use of our client. It is not to be relied on by and 3rd party. Proprietary & Confidential 無断転載・無断複製の禁止

Slide 7

Slide 7 text

Firestore移行のゴールは？クライアントのデータの取得先をFirestoreに切り替えることでリリース ● システム構成を大きく変更をするリリースなので、いつでも旧バージョンにロールバックできる仕組み ● すべてのデータがFirestoreに同期できていることが前提条件

Slide 8

Slide 8 text

Firestore移行のゴールは？クライアントのデータの取得先をFirestoreに切り替えることでリリース ● システム構成を大きく変更をするリリースなので、いつでも旧バージョンにロールバックできる仕組み ● すべてのデータがFirestoreに同期できていることが前提条件変数を変更することで、クライアント側のデータの取得先が切り替わる仕組み

Slide 9

Slide 9 text

Firestore移行のゴールは？クライアントのデータの取得先をFirestoreに切り替えることでリリース ● システム構成を大きく変更をするリリースなので、いつでも旧バージョンにロールバックできる仕組み ● すべてのデータがFirestoreに同期できていることが前提条件今回お話するのはココ

Slide 10

Slide 10 text

3. データ移行の課題 Copyright © 2021 Present ANDPAD Inc. This information is confidential and was prepared by ANDPAD Inc. for the use of our client. It is not to be relied on by and 3rd party. Proprietary & Confidential 無断転載・無断複製の禁止

Slide 11

Slide 11 text

データ移行の課題 ● 対象データが約5000万件ある ● 本番DBへの負荷がかかるため、サービス停止前提のデータ移行を想定 → 1,2時間ほどでデータ同期しきる処理パフォーマンスが求められる ● 移行元のDBと移行先のFirestoreでデータ構造が異なる → データ同期後にデータ検証する仕組みが必要どうすればいいんだ...

Slide 12

Slide 12 text

データ移行の課題 Go言語のバッチ処理を使ってデータ同期しよう並行処理を使って、並行数を限界まで上げることで、データ同期のパフォーマンスはかなり上がると思う移行後のデータ検証の仕組みは、検証専用のツールとかがあった方が安全だと思う CDO 山下

Slide 13

Slide 13 text

4. データ移行の全体像 Copyright © 2021 Present ANDPAD Inc. This information is confidential and was prepared by ANDPAD Inc. for the use of our client. It is not to be relied on by and 3rd party. Proprietary & Confidential 無断転載・無断複製の禁止

Slide 14

Slide 14 text

データ移行の全体像 CircleCI

Slide 15

Slide 15 text

データ移行の全体像 CircleCI 同期ツール Create Jobにて、同期ツールを実行 RDSからデータ取得〜 Firestoreへの書き込みを並行処理で行う Delete Jobにて、緊急停止できる仕組み

Slide 16

Slide 16 text

データ移行の全体像 CircleCI 検証ツール Create Jobにて、検証ツールを実行並行処理で、RDS, Firestore からデータ取得〜データ付き合わせて検証して、不整合データを見つける Delete Jobにて、緊急停止できる仕組み

Slide 17

Slide 17 text

5. 処理パフォーマンス向上に向けてどのように進めていったか Copyright © 2021 Present ANDPAD Inc. This information is confidential and was prepared by ANDPAD Inc. for the use of our client. It is not to be relied on by and 3rd party. Proprietary & Confidential 無断転載・無断複製の禁止

Slide 18

Slide 18 text

● 検証用のDBを用意 ● 並行処理数の調整と以下の調整も合わせて行った ○ RDSからのデータ取得数 ○ クエリチューニング ○ コネクションを再利用する時間 ① 検証用DBを用意した上で、並行処理数の最適値を探る

Slide 19

Slide 19 text

● 検証用のDBを用意 ● 並行処理数の調整と以下の調整も合わせて行った ○ RDSからのデータ取得数 ○ クエリチューニング ○ コネクションを再利用する時間 ① 検証用DBを用意した上で、並行処理数の最適値を探る本番DBと同じデータ量のRDSを用意検証用のFirebaseプロジェクトを用意

Slide 20

Slide 20 text

Slide 21

Slide 21 text

処理パフォーマンスが思うように上がらない... 2000万件でも6時間以上かかってしまう... ① 検証用DBを用意して、並行数・データ取得数の最適値を探る

Slide 22

Slide 22 text

② Firestoreの書き込みをバッチ書き込みに変更 ※ 500件以上を一度に書き込めない制限があるので注意今まで1件ずつ書き込んでいたものを、 Firestoreのバッチ（一括）書き込みに変更した

Slide 23

Slide 23 text

③ 検証環境のスペックを見直し ● 検証用DBのリードレプリカの数を本番DBと同等にした ● k8s Node（バッチサーバー）のスペックを上げた

Slide 24

Slide 24 text

③ 検証環境のスペックを見直し ● 検証用DBのリードレプリカの数を本番DBと同等にした ● k8s Node（バッチサーバー）のスペックを上げたリードレプリカを3台追加して負荷分散した

Slide 25

Slide 25 text

③ 検証環境のスペックを見直し ● 検証用DBのリードレプリカの数を本番DBと同等にした ● k8s Node（バッチサーバー）のスペックを上げた専用Nodeなので、Podはフルにリソースを使える

Slide 26

Slide 26 text

②③ の結果ここまでで、全データを5,6時間ほどで同期できるパフォーマンスを実現！しかし、5,6時間もサービス停止しておくのは難しい...

Slide 27

Slide 27 text

④ 本番DBのスナップショットの復元DBを使う本番DBの前日分のバックアップを復元したDBを使用することで、サービス停止せずにデータ同期作業が実施できた昼間帯に一日かけてデータ同期を完了した前日分のバックアップをとっている

Slide 28

Slide 28 text

6. データ同期後のデータ検証をどのように進めていったか Copyright © 2021 Present ANDPAD Inc. This information is confidential and was prepared by ANDPAD Inc. for the use of our client. It is not to be relied on by and 3rd party. Proprietary & Confidential 無断転載・無断複製の禁止

Slide 29

Slide 29 text

① 検証ツール上で不整合データをリカバリーできるようにした以下の不整合データを想定 ● バックアップDBと本番DBの差分データ ● 同期ツール実行中のコネクションタイムアウトによる同期漏れ〜数十万件のリカバリー対象のデータを想定

Slide 30

Slide 30 text

② 本番実行 ● 本番DBへ負荷がかかるため、夜間帯に実施 ● データ不整合がなくなるまで、修正&実行の繰り返し ○ 同期ツールのデータ同期処理 ○ 運用によるSQS/Lambda経由での同期処理

Slide 31

Slide 31 text

② 本番実行 ● 本番DBへ負荷がかかるため、夜間帯に実施 ● データ不整合がなくなるまで、修正&実行の繰り返し ○ 同期ツールのデータ同期処理 ○ 運用によるSQS/Lambda経由での同期処理ここでは、同期ツールの処理を呼び出しているため、同期ツールに不備がある場合は修正＆流し直しが必要

Slide 32

Slide 32 text

② 本番実行 ● 本番DBへ負荷がかかるため、夜間帯に実施 ● データ不整合がなくなるまで、修正&実行の繰り返し ○ 同期ツールのデータ同期処理 ○ 運用によるSQS/Lambda経由での同期処理ここの同期処理に不備があると、データ不整合の穴が広がり続けるため修正＆実行し直しが必要

Slide 33

Slide 33 text

7. まとめ Copyright © 2021 Present ANDPAD Inc. This information is confidential and was prepared by ANDPAD Inc. for the use of our client. It is not to be relied on by and 3rd party. Proprietary & Confidential 無断転載・無断複製の禁止

Slide 34

Slide 34 text

まとめデータ移行を通して、これらのことが重要だと感じました。 ● 正しいパフォーマンス検証を行うためには、実際に本番で実行する環境のスペックと同等の環境を用意すること ● パフォーマンス検証は、どの箇所がボトルネックになっているかを仮説・検証して、ボトルネックをどんどん小さくしていくこと ● パフォーマンス検証とアプリケーション側の同期処理は、別物の作業として分けて行う