6千万記事レコードの大規模データマイグレーション
Stockmark Tech Blog は、6000万件を超える大規模データ移行における実務上の課題と解決策を共有し、プロダクションデータを用いた試行とチーム意識統一の重要性を説いている。
キーポイント
大規模データ移行の背景と判断
Anews と Astrategy の 2 つのプロダクト間でデータ整合性を保ちつつ、共通基盤化の必要性が高まったため、6000万件超のレコードを移行する決断がなされた。
移行戦略とアーキテクチャ設計
開発アジリティを維持しつつデータ整合性を担保するため、既存資産を活用した共通バッチ処理パイプラインを採用し、プロダクトごとの基盤を別々に構築する方式を選定した。
実運用での予期せぬ課題と対応
長期間蓄積された本番データの改変や最適化処理が原因で想定外の問題が発生し、再構築に失敗したが、最終的に全件再構築の 2 度目のトライで成功した。
再現可能な知見と教訓
ミッションクリティカルでない既存系システムでは机上検討だけでなくプロダクションデータでの試行を織り込む計画が有効であり、チームの認識すり合わせにウォークスルーが不可欠である。
影響分析・編集コメントを表示
影響分析
この記事は、大規模データマイグレーションにおける「完璧な事前計画」の限界と、「本番環境での試行錯誤」の重要性を実証しており、スタートアップや成長企業におけるデータ基盤リファクタリングの実践的な指針となる。特に、過去の技術的負債（データ改変や最適化痕跡）が移行に与える影響への言及は、現場エンジニアにとって非常に示唆に富む内容である。
編集コメント
6000万件規模のデータ移行における「失敗と再挑戦」の実態を率直に共有しており、理論だけでなく現場の泥臭い経験則が学べる貴重なケーススタディです。
本記事では、ストックマークが2022年12月に実施した、6,000万件を超える記事レコードの大規模データ基盤マイグレーションについて紹介します。本記事を読むことで、大規模データマイグレーションの勘所を実例から学ぶことができます。
本記事でお伝えする内容は以下の4点です。
- 背景
- 検討の進め方
- 大変だったこと
- 再現可能な知見
背景
ストックマークには、大量の記事データを利用するプロダクトとして、AnewsとAstrategyの2つがあります。どちらのプロダクトも、共通の記事データストアにあるコンテンツに対し、プロダクトごとに独自の自然言語処理（NLP）を施して活用しています。アーキテクチャを簡単に示すと次のようになります。
(図: 移行前のアーキテクチャ)
AnewsとAstrategyが解決する顧客課題は異なります。それぞれのプロダクトの観点から顧客価値のディスカバリーを最優先した結果、両プロダクトは独自に進化を遂げ、現在の構成に至りました。
もちろん、プロダクト開発の最初期段階から将来を見据えて基盤を共通化するという考え方もあり得ました。しかし、共通化の必要性が明らかでない段階で着手すると、無駄に機能を作り込んでしまう可能性が高く、スタートアップとしては不適切と判断しました。
やがて事業が進化するにつれ、2つのプロダクト価値を接続することの重要性が高まってきました。今後も両プロダクトが大きく成長していくと見込まれたため、約3ヶ月前、このタイミングでデータストアのマイグレーションに着手することを決断し、実行に移しました。
検討の進め方と移行後の方式
マイグレーションを進めるにあたり、重要な観点を以下の2つに定めました。
- 自社の強みであるデータと自然言語処理技術が進化し続けられる基盤とすること
- 各プロダクトの開発アジリティを損なわないこと
- 現状の機能からデグレード（機能劣化）が発生しないこと
上記を満たす移行方式を数パターン検討し、移行コスト、移行後の運用性・拡張性などの観点から、最終的に以下のアーキテクチャを採用しました。
(図: 移行後のアーキテクチャ)
このアーキテクチャでは、記事マスタを基に、AnewsとAstrategyが参照するデータ基盤を別々に構築しています。ただし、データ基盤を構築するまでのパイプラインを共通化することで、両プロダクト間のデータ整合性を保っています。
この共通バッチ処理は、Astrategyのパイプラインをベースに構築しました。スクラッチ（一から）で作成する案もありましたが、移行コストを抑えるため、活用可能な既存資産を最大限利用しました。
大変だったこと
Anewsはサービス開始から5年以上が経過しています。5年以上もデータが蓄積されると、本番環境（プロダクション）の実データで試行しないとわからない問題があり、これが最も困難な点でした。
以前の記事でも紹介した通り、ストックマークではAWS Lambda x Node.jsを利用して記事データを日々蓄積しています。収集した記事データに処理を加え、プロダクトごとのマスターデータストアを作成しているのです。
今回の移行では、このプロダクトごとのマスターデータストアを再構築する必要がありました。再構築の対象となる記事データは6,000万レコードを超え、処理には約4～5日かかることが判明していました。
したがって、再構築に何度も失敗すると、4～5日×失敗回数だけ時間がかかってしまいます。そのため、一定の机上検討を行い、可能な限り精度の高い方法で移行に臨みました。
しかし、机上の検討だけでは、本番環境のデータでなければ発見できない問題も存在します。過去の緊急対応によるデータ改変や、暫定的な最適化処理が想定外の問題を引き起こすケースがあり、これらは移行後のテストで多く発見しました。可能な限りデータパッチで対応しましたが、復旧が困難な状況に陥ったため、全件の再構築を実施し、2度目の試行で移行を成功させています。
再現可能な知見
得られた知見は主に2点あります。
1点目は、前述の通り一度は移行をやり直したものの、机上検討の時間を一定に区切り、実際に試行を重ねた方法論です。ミッションクリティカルなシステムで失敗が許されない場合は別ですが、今回のように既存システムが稼働している場合は、本番データを用いた試行を計画に織り込むことが有効だと考えています。
2点目は、開発チームの意識統一です。移行に伴う開発工数を最小化するため、重要なポイントについてチームでウォークスルーを行い、認識をすり合わせました。全体方針は文書化されていましたが、理解度には個人差があり得ます。そこで、重要な箇所に絞り、チームで文書の項目を一つずつ確認する時間を設けたのです。
まとめ
本記事では、ストックマークが実施した大規模データ基盤移行の概要を紹介しました。
本記事で扱いきれなかった細かな工夫や技術的詳細は多数ありますので、ご興味があればぜひカジュアル面談でお話しさせてください。
また、本テーマをより深く掘り下げるイベント「Stockmark Tech Meetup #06 - スタートアップの成長フェーズに応じたデータストアのリファクタリングのタイミングと方法」を、2023年3月8日（水）19:30より開催いたします。本記事にご興味を持たれた方は、ぜひこちらにもご参加ください。
原文を表示
本記事では、ストックマークで2022年の12月に実施した、6千万件を超える記事レコードの大規模データ基盤マイグレーションについて紹介いたします。本記事を読むことで、大規模データマイグレーションの勘所を実例から学べます。
本記事でお伝えする内容は以下の4点となっています
背景 検討の進め方 大変だったこと 再現可能な知見 背景 ストックマークでは大量の記事データを利用するプロダクトとして、AnewsとAstrategyの2つのプロダクトがあります。どちらのプロダクトも共通の記事データストアにある内容に、プロダクトごとの弊社独自の自然言語処理を加えたものを活用しています。アーキテクチャを簡単に表すと次のようになっています。
移行前のアーキテクチャ AnewsとAstrategyでは解決する顧客課題が異なります。それぞれのプロダクト観点ごとに、顧客価値のディスカバリーを最優先としたことから、お互いのプロダクトで独自に進化してきた結果、本構成になっています。
もちろん、当時の時点でプロダクト開発に着手する最初の段階から将来を見据えて基盤を共通化する、という考え方も存在します。しかし、そもそも共通化の必要性が明らかでない状態で着手しても、無駄に機能を作りこんでしまう可能性が高いため、スタートアップとしては不適と判断しています。
やがて事業そのものが進化するにつれて、2つのプロダクト価値の接続の重要性が高まってきました。今後も両プロダクトが大きく成長していくことを考えると、このタイミングでのデータストアのマイグレーションへの着手を判断して実行したのが3ヶ月ほど前です。
検討の進め方と移行後の方式 マイグレーションを進めるにあたり、重要な観点を2つ定めました。
弊社の強みであるデータと自然言語処理技術が進化し続けられるデータ基盤となること 各プロダクトの開発のアジリティを落とさないこと 今できていることからデグレが起きないこと 上記を満たすように、移行方式を数パターン考えて、移行コスト、移行後の運用性・拡張性などの観点から、最終的に以下のアーキテクチャとしました。
移行後のアーキテクチャ 本アーキテクチャでは、記事マスタを元に、AnewsとAstrategyが参照するデータ基盤を別々に構築しています。ただし、データ基盤を構築するまでのパイプラインを共通化することで、2プロダクト間のデータ整合性を保ちます。
この共通バッチ処理は、Astrategyのパイプラインをベースに作成しました。スクラッチで作成する案もありますが、活用できる既存資産はできる限り利用して移行コストを抑えています。
大変だったこと Anewsはサービス開始から5年以上が経過しています。5年以上もデータがたまっていると、プロダクションの実データで試さないとわからないことがあった点が、最も大変だったことです。
以前の記事でもご紹介しましたが、ストックマークではAWS Lambda x Node.js を利用して、記事データを日々蓄積しています。収集した記事データに処理を加えてプロダクトごとのマスターデータストアを作成しています。
今回は移行では、そのプロダクトごとのマスターデータストアを再構築します。再構築の対象記事データは6000万記事レコードを超えており、再構築にはおよそ4-5日かかることがわかっていました。
そのため、仮に再構築に何度も失敗してしまうと、4-5日 x 失敗回数の時間がかかってしまいます。そこで、一定の机上検討をして、なるべく精度の高い方式で移行に取り組みました。
しかし、どれだけ机上検討を加えても、プロダクトションのデータでなければ分からないこともあります。過去に行われた、何らかの緊急対応によるデータ改変や、暫定的な最適化処理が想定外の問題を引き起こすことがあり、これらはデータ移行後のテストで多く発見しました。可能な限りデータパッチで凌ぎましたが、復旧が困難な状況に陥り全件の再構築を行い、2度目のトライで移行に成功しています。
再現可能な知見 2点あります。
1つ目は、前述のように1度は移行をやり直したものの、机上検討の時間を一定にして実際に試行した方法です。
ミッションクリティカルなシステムで、ミスが取り返しのつかない影響を引き起こす場合は別ですが、今回のように既存系が動いている場合は、プロダクションデータを利用して試行を織り込んだ計画にするのが良いと考えています。
もう1つは、開発チームの意識統一です。移行に伴う開発時間を最小化するために、重要な点をチームでウォークスルーして認識をすり合わせしていきました。全体方針などはドキュメントに起こしてあるため、それを読むことで一定の理解は得られますが、理解度には差が出ます。そこで、重要な箇所に絞ってチームでドキュメントの項目を1つずつ確認する時間をとりました。
まとめ 本記事では、ストックマークで実施した大規模データ基盤移行の概要を紹介しました。
本記事で取り扱っていない細かい工夫や技術詳細は多々あるので、もしご興味あれば是非カジュアル面談でお話させてください。
また、本記事をより詳細に扱うイベントとして、Stockmark Tech Meetup #06 - スタートアップの成長フェーズに応じたデータストアのリファクタリングのタイミングと方法を、2023/03/08(水) 19:30より開催いたします。本記事に興味をもっていただけましたら、こちらも是非ご参加ください！
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み