6千万記事レコードの大規模データマイグレーション

Tags
6千万記事レコードの大規模データマイグレーション
Page content

本記事では、ストックマークで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より開催いたします。本記事に興味をもっていただけましたら、こちらも是非ご参加ください!