どんな企業にとってもデータは「資産」ですが、ユーザーとクライアントのマッチングを軸に事業を展開するリクルートにとっては、ビジネスを支える存在の一つです。
リクルートではサービスに関わるデータを収集・蓄積するデータ基盤を構築し、マッチングの精度向上を含むプロダクト改善などに活用してきました。例えばWebサイトの回遊状況を元にユーザーの興味や関心を推測してリコメンデーションを行ったり、検索結果を提供したりするなど、ユーザーとクライアント、双方が満足できるマッチング機会の創出に取り組んでいます。
このような取り組みにおいて、新しく生まれた価値のある情報を、より素早く活用していく「データの鮮度」は大事な要素になります。データの鮮度とは、すなわちリアルタイム性のこと。多様かつ膨大な量のデータを取り扱うビジネスでは、このリアルタイム性をいかに高められるかが、意思決定の精度や速度に直結します。
リクルートのデータ推進室では今回、ニアリアルタイムなデータ転送を実現する技術、CDC（Change Data Capture）の導入を実施することにしました。
AWS Database Migration Service（DMS）やDatabricksなどを組み合わせ、ソース側のデータ生成・変更・削除が低遅延でデータ基盤に反映される仕組みを構築し、データ鮮度の向上を実現させました。
その背景と実現までの道のりを、データ推進室でデータエンジニアリンググループのグループマネージャー・テックリードを務め、プロジェクトをリードした山本航平さんと、 同じチームで実務を担当した川合真大さん、豊田陽さん、データ推進室の専門スキルマネジメントを主幹する阿部直之さんに伺いました。
※この記事は株式会社リクルートによるSponsoredContentです。
- シンプルながらさまざまな課題を抱えていたバッチによるデータ連携
- データは“一日後に来ます”じゃフル活用できない
- 前例のないプロジェクトを支えた「勝ちパターンのアーキテクチャ」
- 変化し続ける仕様に合わせ、あえてデータ基盤で引き受けた「帳尻合わせ」
- アーキテクチャ設計段階からコミットできたことで合理的なプロジェクトに
山本 航平（やまもと・こうへい）
株式会社リクルート プロダクト統括本部
プロダクト開発統括室 データ推進室
HR領域データソリューションユニット HRデータソリューション部
HRデータエンジニアリンググループ
エンジニアリングマネージャーとして、HRサービスのデータ分析基盤を担当する。
川合 真大（かわい・まさひろ）
株式会社リクルート プロダクト統括本部
プロダクト開発統括室 データ推進室
HR領域データソリューションユニット HRデータソリューション部
HRデータエンジニアリンググループ
山本さんの配下で、HRサービスの開発と運用を担当する。
豊田 陽（とよだ・あきら）
株式会社リクルート プロダクト統括本部
プロダクト開発統括室 データ推進室
HR領域データソリューションユニット HRデータソリューション部
HRデータエンジニアリンググループ
山本さんの配下で、HRサービスの開発と運用を担当する。
阿部 直之（あべ・なおゆき）
株式会社リクルート プロダクト統括本部
プロダクト開発統括室 データ推進室
データテクノロジーユニット
データ推進室の専門スキルマネジメントを主幹し、領域を横断して各案件に関わる。
シンプルながらさまざまな課題を抱えていたバッチによるデータ連携
── データビジネスを推進する上で、サービス側のデータベースとデータ基盤の連携速度をどう上げるか、というのは事業に直結する課題です。リクルートでもそうした課題はあったのでしょうか？
阿部 はい。データ基盤におけるデータ連携は、これまではバッチ形式で実行されていることが多かったのですが、バッチ形式では決まった区切りのタイミングでなければデータが連携されません。区切りのスパンを短くしていけばデータの鮮度は上げられますが、やはりどこかで限界は発生します。
しかもHR領域ではサービスの拡大に伴ってデータの容量自体も増大していました。当然ながら、データが増えれば処理時間も延び、基盤への負荷も大きくなります。
それに、たとえその日のデータ連携がうまくいかなかった場合でも、処理時間の制約から、すぐに再実行するわけにはいかないケースもあります。再実行した処理が終わりきらない場合は、翌日の処理に影響してしまう可能性等もあります。いわゆる「バッチジョブパズル」的な問題を解く難しさと言えばイメージしやすいでしょうか。
── 「バッチジョブパズル」が頻発することで運用面にどのような負荷がかかっていたのですか？
山本 テーブルのサイズや処理時間を考慮して並列数やリソース割り当てなどを決定する必要があるため、ジョブの中身が複雑になりやすく、今まで動いていたバッチでも処理順を入れ替えると思うように動かなくなったりするリスクが大きかったんです。
川合 例を挙げると、深夜帯に失敗したジョブを再実行するといった運用が発生した際に、昼間に同じバッチ処理を再実行しても、日中帯における他データ処理の影響などによってうまくデータが取得できないこともありました。
山本 バッチ処理のプロセス自体はシンプルながら、規模が大きくなることで発生する問題もあり、データ鮮度の担保も難しいという点に課題感を感じていました。
データは“一日後に来ます”じゃフル活用できない
── 上記のような課題に対する打ち手がニアリアルタイムなデータ基盤の構築だったと。
山本 はい。ちょうど新規サービスの開発プロジェクトが立ち上がったので、それと連動するかたちでニアリアルタイムデータ基盤の構築に取り組み始めました。
リクルートの事業構造を考えた時、データ活用の質とスピードは生命線であり、適切なデータが用意できないということはある種危機的状況です。
そもそも、データは“一日後に来ます”というのでは、鮮度の高いデータを活用した最適なデータ施策を打てません。かといって、単純に鮮度だけを上げようとすると限定されたデータしか使えなくなる可能性もあり、それでは本末転倒です。データの鮮度を上げつつ、活用の自由度も広くする。そうしたデータパイプラインを、今回のタイミングで実現できないか。そして新しい仕組みを作って標準化できれば、先ほどお伝えした課題を解消しつつ、より広い範囲においても適用できるのではないかと考えました。
── ニアリアルタイムなデータ基盤を構築する上で“もっとも適切な手段”がCDCの導入だったのでしょうか？
山本 一日あたり数テラバイトに上るデータを速く、鮮度を高く保った状態でいかに正確に連携させるか、複数の実現方法を検討した結果採用したのが、CDCでした。業界的にも徐々にスタンダードになりつつある技術をリクルートでも取り入れることにしたのです。
── なるほど。では、CDCを導入するメリットについて詳しく教えてください。
山本 決まったタイミングでしか連携されないバッチ形式から、変更が発生するたびに連携され、とめどなく逐次的にデータが入ってくる方式に切り替えることで、鮮度の問題を解決できます。同時に、一度に転送されるデータの量を減らし、データベースへの負荷を削減できるというメリットもありました。
また、日次のデータ連携ではデータベースのある瞬間の断面図しか取得できなかった（テーブルのデータモデルによっては途中の変更の記録は抜けてしまう）のですが、CDCを採用することでトランザクションの履歴を詳細にたどれるようになるのも利点でした。
豊田 今日の何時何分の時点でこうだ、という状態や、ユーザーの意思決定の履歴など、データがどのような更新をへて、現在の状態に至ったのかを把握することが可能になります。結果的に、システムの運用での詳細な調査を実現することや、より高い精度でユーザーに価値のある情報を届けることにつながります。
川合 CDCにはそうした、データの鮮度や転送速度を上げながらシステムへの負荷を下げられるメリットはあるのですが、一方で運用負荷が上がってしまう、というデメリットもあります。
CDCは「このテーブルにこのデータがインサートされました」というログが随時入ってくる仕組みです。ログ単体でも利活用はできますが、ある��ーブルの最新のスナップショットを得たい場合、変更データを過去断面に適用することで再現する必要があります。障害などで連携するデータに遅延や欠損が生まれてしまうと「いつからなぜズレたのか」を検証しなければならず、調査の難易度が高くなりがちです。
── そんなデメリットが。しかし、それを加味しても導入するメリットがあったということなのでしょうか？
川合 そうですね。先ほど申し上げたデメリットはデータの鮮度や転送速度を担保する上では当然発生しうるものであり、むしろデータ施策として価値を生み出すためにやるべき運用に注力できている状態とも言えます。
前例のないプロジェクトを支えた「勝ちパターンのアーキテクチャ」
── そもそも、ニアリアルタイムなデータ基盤の構築はリクルート社内でも前例のない取り組みだったと伺いました。
山本 ここで新しい方式を導入することで実績ができるため、他のサービスにも横展開でき、向こう数年のリクルートの事業にとっても大きなメリットをもたらします。ここは攻め時だと考えていました。
── そうした重要なプロジェクトである一方、技術的にも、プロジェクト設計の面でも不安はなかったのでしょうか？
山本 確かに初物には不安がつきものですが、リスクを下げるため、とにかく検証を行いました。想定されるデータパターンや運用をもとにテストケースを設計し、約2カ月かけて問題なく運用できそうなことを確認した上でプロジェクトを進めていきました。
そこで意識したのは、「最終的に自分たちが運用しないコンポーネントの設定も含め、全てについてベストプラクティスを出す」ということ。その上で、この取り組みがリスクとならないことを我々がきちんと担保していく、データ基盤はサービスの価値を高めるためにあるという前提をぶらすことなく当事者意識を持って自分たちで最後まで面倒を見る、といったことを徹底しました。
データパイプラインはデータ利活用の起点であり、同時にボトルネックでもあります。だからこそ、データ基盤の制約をなくせば、全体をもっとよくすることができると説明し、チーム間で丁寧に目的を共有しながらプロジェクトを進めるように心がけましたね。
阿部 データ連携によってシステムに想定外の負荷をかけ、サービスを不安定にさせるようなことがあっては、ユーザーの大切な機会を奪いかねません。
山本 システムの運用者は「ユーザーの機会を奪ってしまわないよういかにシステムを安定稼働させるか」ということにコミットしています。ギリギリいけるから導入しよう、ではなく、自分たちで絶対に大丈夫というところまで検証し切った上で自信を持って提案できる状態にする必要があります。
そして、システムは運用に入った後も重要で、一度機能を追加したらその後5年、10年と使われ続ける可能性もあります。そうした性質を理解した上で、仮にデータ基盤側の要因で何か障害が起きたとしても、事業システムに影響を及ぼさずにきちんと停止できるような、「勝ちパターンのアーキテクチャ」に沿って作り込みました。
── 運用者目線に立った地道なアクションのおかげで、サービス側の信頼が得られ、円滑にプロジェクトを進められたわけですね。
阿部 そうですね。開発者がただ作りたいものだけを作るような態度や自分たちの都合のゴリ押しをするのではなく、お互いが担保しなければならない価値の違いを理解しリスペクトするという、当たり前のことを真っ当にできたプロジェクトだと思っています。
変化し続ける仕様に合わせ、あえてデータ基盤で引き受けた「帳尻合わせ」
── ニアリアルタイムデータ基盤の技術的な導入プロセスについても掘り下げていきたいのですが、マネージドサービスも使いつつ自前で開発した部分もあったのでしょうか？
山本 AWSのDMSも活用しています。事業サービスのデータベースから変更ログをキャプチャして取り込み、テーブルとして再現してデータ基盤に反映する仕組みです。
ただ、キャプチャの部分はAWS DMSに任せつつ、それ以降の仕組みは全て自前で開発しました。
その他サービスへの横展開を考えていたので、なるべく汎用性を持たせた仕様で開発しなければなりませんでした。また、HR事業のデータには、数多くの個人情報も含まれるので社内のセキュリティ基準を満たす必要がありました。そういった点から、ある程度は自前で作った方がいいだろうという判断でした。
データ基盤のデータは、分析やモニタリングだけでなく、機械学習モデルのトレーニングにも活用されます。機械学習モデルはデータの質によって大きく変わってくるからこそ、データサイエンティストのチームとも緊密に連携し、「いかにタイムリーに、リッチで、かつ鮮度が高い特徴量を作れるか」について相談を重ねました。
そうして各部署との連携を進めていくには、データを使いやすいフォーマットに落とし込まなければならず、それにはデータのクレンジングやエンリッチなどの前処理が不可欠です。「データを取ってきます、入れます、以上」で終わるものではなく、そこから先でやらなければいけないことが非常に多くありました。
── 「そこから先でやらなければいけないこと」の処理実装は川合さんがメインで担ったとお聞きしましたが、開発時はどのような難しさに直面しましたか？
川合 データ取得先となる、サービス側のシステムがマイクロサービスで新しく開発されている最中、日に日に状況が変わり、走りながら作る状態でした。
そして、新規でカットオーバーするサービスなので、まだデータもなく、開発開始時には仕様も固まりきっていませんでした。にもかかわらず、最初からデータ基盤を活用したリコメンド機能を実装する必要があったので、ゴールまでのギャップをどう埋めればいいかはよく議論しましたね。
いわば、「データがない中で機械学習モデルを構築し、一定の精度も担保しなければならない」という困難な状況でした。かといって、システムの仕様が変わり続ける中、モデルの入力元となる特徴量までその影響を受けると、もっとカオスな状態になることは目に見えています。だから、あえて「仕様の帳尻合わせ」をデータ基盤で引き受け、出力されるデータのI/Fをロックした上で品質を担保しました。
── 先ほど伺った検証のフェーズでも、「事前の想定とは違う」ということが起こったのではないでしょうか？
豊田 はい、十分な検証を行ったつもりでしたが、実サービスならではの「例外」パターンに遭遇することもありました。
開発を進める中で、同一トランザクション内で同一のキーに対して複数の操作が実行された場合、その順番が厳密に決定できない、ということが発覚しました。トランザクション内の処理の順序を正確に再現するために、連携されたデータに行番号をふる、という地道な解決策での対応も行いました。
そうした問題を都度潰しながらリリースに漕ぎ着けました。
アーキテクチャ設計段階からコミットできたことで合理的なプロジェクトに
── ニアリアルタイムデータ基盤を構築し、鮮度の高いデータを取得する仕組みが整ったわけですが、今振り返って、プロジェクトを完遂できた理由はどこにあったと思いますか？
阿部 個々の技術を実現する難易度より、全体のインテグレーションの難易度が高かったプロジェクトと言えると思います。だからこそ、アーキテクチャの設計段階からコミットし、変えるべきところとそうでないところを見極めつつ、合理的なプロジェクト設計ができた点が成功の大きな要因だったと思います。
── そうしたリクルートならではのプロジェクト推進経験はエンジニアとしての経験値にもつながりましたか？
川合 リクルートのHR事業を支える大規模なデータ基盤をゼロから作ることで技術者としても多くのことを学びました。
豊田 社内での先行事例が少ない分野に取り組み、やりきれたことが自信につながっています。
── より良いデータ基盤の実現に向けて今後どんなアクションを想定されているか、その展望を教えてください。
山本 データ基盤は一度作って終わりではなく、サービスの進化に伴ってアップデートし続けていく必要があります。
これまで、まず多くのものをリリースするところに専念していたため、運用や保守には十分に力を割けていませんでした。今後は運用が始まったからこそ浮上してくる新たな課題に取り組みつつ、エンハンスしていかなければならないと考えています。
リクルートのデータ推進室に関するブログ記事はこちら
株式会社リクルートではエンジニアを募集中！
今すぐの転職を考えていなくても、希望職種に関する情報やスカウトを受け取れるキャリア登録の仕組みも用意されています。少しでも興味のある方は👇気軽にクリック！
さまざまな取り組みの裏側やナレッジ、厳選した採用情報もSNSで発信中！
🎁 Amazonギフトカードが当たる！ リクルートに関するアンケート 📝
※アンケートは終了しました。ご協力、ありがとうございました。
Amazon.co.jp は、本キャンペーンのスポンサーではありません（株式会社はてなのキャンペーンです）。
Amazon、Amazon.co.jp およびそのロゴは Amazon.com, Inc. またはその関連会社の商標です。
関連記事
リクルートの他部署に関連したSponsoredContent、および旧リクルート各事業会社によるSponsoredContentもあわせてお読みください。
[SponsoredContent] 企画・制作：はてな
取材・文：高橋睦美
撮影：関口佳代
