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

2021/02/25 ANDPAD & Media Do 〜BtoB開発の舞台裏〜

Transcript

1. 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開発の舞台裏〜
2. 自己紹介 椎野 太喜（しいのたいき） • 出身 ◦ 茨城県 • 経歴 ◦ 10人規模のベンチャー → 株式会社アンドパッド • 専門領域 ◦ Webフロントエンド。状況に応じてサーバーサイドなど他 の領域にも日々チャレンジしている。 • 好きなこと ◦ 釣り、銭湯 @buena926
3. アジェンダ 1. 背景 2. Firestore移行のゴールは？ 3. データ移行の課題 4. データ移行の全体像 5. 処理パフォーマンス向上に向けてどのように進めていったか 6. データ同期後のデータ検証をどのように進めていったか 7. まとめ
4. 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 無断転載・無断複製の禁止
5. 背景 • 2020年7月チャットプロダクトを開発するチームへ参画 • チャットプロダクトで使用するDBを、Firestoreへ移行が直近のミッション ◦ 移行前は、MySQLとFirebase RealtimeDatabaseを使用
6. 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 無断転載・無断複製の禁止
7. Firestore移行のゴールは？ クライアントのデータの取得先をFirestoreに切り替えることでリリース • システム構成を大きく変更をするリリースなので、いつでも旧バージョンにロールバックできる仕組み • すべてのデータがFirestoreに同期できていることが前提条件
8. Firestore移行のゴールは？ クライアントのデータの取得先をFirestoreに切り替えることでリリース • システム構成を大きく変更をするリリースなので、いつでも旧バージョンにロールバックできる仕組み • すべてのデータがFirestoreに同期できていることが前提条件 変数を変更することで、 クライアント側のデータの取 得先が切り替わる仕組み
9. Firestore移行のゴールは？ クライアントのデータの取得先をFirestoreに切り替えることでリリース • システム構成を大きく変更をするリリースなので、いつでも旧バージョンにロールバックできる仕組み • すべてのデータがFirestoreに同期できていることが前提条件 今回お話する のはココ
10. 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 無断転載・無断複製の禁止
11. データ移行の課題 • 対象データが約5000万件ある • 本番DBへの負荷がかかるため、サービス停止前提のデータ移行を想定 → 1,2時間ほどでデータ同期しきる処理パフォーマンスが求められる • 移行元のDBと移行先のFirestoreでデータ構造が異なる → データ同期後にデータ検証する仕組みが必要 どうすればいいんだ...
12. データ移行の課題 Go言語のバッチ処理を使ってデータ同期しよう 並行処理を使って、並行数を限界まで上げることで、デー タ同期のパフォーマンスはかなり上がると思う 移行後のデータ検証の仕組みは、検証専用のツールとかが あった方が安全だと思う CDO 山下
13. 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 無断転載・無断複製の禁止
14. データ移行の全体像 CircleCI
15. データ移行の全体像 CircleCI 同期ツール Create Jobにて、 同期ツールを実行 RDSからデータ取得〜 Firestoreへの書き込み を並行処理で行う Delete Jobにて、 緊急停止できる仕組み
16. データ移行の全体像 CircleCI 検証ツール Create Jobにて、 検証ツールを実行 並行処理で、RDS, Firestore からデータ取得〜データ付き 合わせて検証して、不整合 データを見つける Delete Jobにて、 緊急停止できる仕組み
17. 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 無断転載・無断複製の禁止
18. • 検証用のDBを用意 • 並行処理数の調整と以下の調整も合わせて行った ◦ RDSからのデータ取得数 ◦ クエリチューニング ◦ コネクションを再利用する時間 ① 検証用DBを用意した上で、並行処理数の最適値を探る
19. • 検証用のDBを用意 • 並行処理数の調整と以下の調整も合わせて行った ◦ RDSからのデータ取得数 ◦ クエリチューニング ◦ コネクションを再利用する時間 ① 検証用DBを用意した上で、並行処理数の最適値を探る 本番DBと同じデータ量 のRDSを用意 検証用のFirebaseプロジェク トを用意
20. • 検証用のDBを用意 • 並行処理数の調整と以下の調整も合わせて行った ◦ RDSからのデータ取得数 ◦ クエリチューニング ◦ コネクションを再利用する時間 ① 検証用DBを用意した上で、並行処理数の最適値を探る
21. 処理パフォーマンスが思うように上がらない... 2000万件でも6時間以上かかってしまう... ① 検証用DBを用意して、並行数・データ取得数の最適値を探る
22. ② Firestoreの書き込みをバッチ書き込みに変更 ※ 500件以上を一度に書き込めない制限があるので注意 今まで1件ずつ書き込んでいたものを、 Firestoreのバッチ（一括）書き込み に変更した
23. ③ 検証環境のスペックを見直し • 検証用DBのリードレプリカの数を本番DBと同等にした • k8s Node（バッチサーバー）のスペックを上げた
24. ③ 検証環境のスペックを見直し • 検証用DBのリードレプリカの数を本番DBと同等にした • k8s Node（バッチサーバー）のスペックを上げた リードレプリカを3台追加し て負荷分散した
25. ③ 検証環境のスペックを見直し • 検証用DBのリードレプリカの数を本番DBと同等にした • k8s Node（バッチサーバー）のスペックを上げた 専用Nodeなので、Podは フルにリソースを使える
26. ②③ の結果 ここまでで、全データを5,6時間ほどで同期できる パフォーマンスを実現！ しかし、5,6時間もサービス停止しておくのは難しい...
27. ④ 本番DBのスナップショットの復元DBを使う 本番DBの前日分のバックアップを復元したDBを使用することで、 サービス停止せずにデータ同期作業が実施できた 昼間帯に一日かけて データ同期を完了した 前日分のバックアップを とっている
28. 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 無断転載・無断複製の禁止
29. ① 検証ツール上で不整合データをリカバリーできるようにした 以下の不整合データを想定 • バックアップDBと本番DBの差分データ • 同期ツール実行中のコネクションタイムアウトによる同期漏れ 〜数十万件のリカバリー対象 のデータを想定
30. ② 本番実行 • 本番DBへ負荷がかかるため、夜間帯に実施 • データ不整合がなくなるまで、修正&実行の繰り返し ◦ 同期ツールのデータ同期処理 ◦ 運用によるSQS/Lambda経由での同期処理
31. ② 本番実行 • 本番DBへ負荷がかかるため、夜間帯に実施 • データ不整合がなくなるまで、修正&実行の繰り返し ◦ 同期ツールのデータ同期処理 ◦ 運用によるSQS/Lambda経由での同期処理 ここでは、同期ツールの処 理を呼び出しているため、 同期ツールに不備がある場 合は修正＆流し直しが必要
32. ② 本番実行 • 本番DBへ負荷がかかるため、夜間帯に実施 • データ不整合がなくなるまで、修正&実行の繰り返し ◦ 同期ツールのデータ同期処理 ◦ 運用によるSQS/Lambda経由での同期処理 ここの同期処理に不備があると、 データ不整合の穴が広がり続ける ため修正＆実行し直しが必要
33. 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 無断転載・無断複製の禁止
34. まとめ データ移行を通して、これらのことが重要だと感じました。 • 正しいパフォーマンス検証を行うためには、実際に本番で実行する環境のスペックと 同等の環境を用意すること • パフォーマンス検証は、どの箇所がボトルネックになっているかを仮説・検証して、 ボトルネックをどんどん小さくしていくこと • パフォーマンス検証とアプリケーション側の同期処理は、別物の作業として分けて行 う