婚活会員の膨大なデータを効率よく処理するためにやったこと
こんにちは！株式会社IBJ 加盟店本部所属のエンジニア 小澤です。
弊社のエンジニアは事業部に所属し開発を行う人、全社横断的に開発を行う人の2パターンあります。
事業部所属エンジニアは、日々その事業部の重要指標達成のため開発を行っており、弊部では仲人と会員が結婚相談所で使用する全てのシステムの開発を行っています。
今回はどのような開発を行っているかの一例を簡単に紹介します！
今回何を作ったの？
今回は何歳の/どこ住みの会員から自分は検索されているかわかるようにするための元データを貯めるシステムを作成しました。
説明が難しいのでサラッとまとめると、、、
「会員Aがお相手を検索した時にヒットした会員Bさん」という状態の時、
「BさんがAさんの属性の人（神奈川県在住の30歳の男性）に1回検索された」とデータを保存するシステムです。
どのようにデータを保存しているの？
前書きが長くなりましたがここからが本題です。
上記の例では会員Aが検索したときに会員Bしかヒットしなかった仮定で記載していますが、実態はそうでは有りません。
IBJでは会員数が約8万人以上います。条件によっては1万人以上が検索結果として出てくることも当たり前のようにあるわけです( ﾟ∀ﾟ)
データを保存するために既存のシステムの負荷が上がるのは避けたかったため、専用のサーバを新設しシステムを組みました。
実際のシステムの構成は以下のような形です。
今回の一番の肝はSidekiqを導入したことです。
この処理後でやりたいな…といった処理をバックグラウンド（非同期）で行えるもの、それがSidekiqです。
会員が検索した時にリアルタイムで元データを保存する、、のではなく
Sidekiqを使用し非同期で処理を行い大量のデータをさばけるようにしています。
大変だった点や良かった所
① 1日あたり約5億件以上のデータが蓄積すること
IBJで活動されている会員の1日の総検索結果人数が、休日で5億件を超えていました。つまりデータベースへ同数回更新処理を行う必要があります。
（単純計算なので実態は少し違いますが）
5億件超の負荷に耐えられるように設計、実装、スペックのチューニングを行うのがとても大変でした。
1つの対応策としてDynamoDBのアトミックカウンタ機能を使用し、1日ごと会員ごとにデータを保持することでレコード数を減らし負荷低減してます。
【余談】
BigQueryやRedshift、S3×Athenaなど、様々なサービスを調査・検討しました。
コストやレスポンス速度、保守性など様々な面からDynamoDBでやることにしています。
② SidekiqGUIを使用し、いつでもモニタリングできるようにした
会員が検索した履歴をいつでもモニタリングできるように、Sidekiqに入っているGUIを見れるようにしました。
これがとても良く、あったおかげで負荷状況や失敗した処理の調査など、
痒い所に比較的簡単に手が届きました。
最後に
IBJでは「2027年までに25,000組（日本の婚姻組数の5%）の結婚を創出する」ミッションを達成するために、システムでできることを日々考えリリースしています。
今回も新しいことにチャレンジしたので、ここには書けていない大小色々なつまづきが沢山ありました。
問題を解決するために様々な技術を取り入れることが好きな方！ぜひぜひお待ちしています😉
■採用チームより■
まずはカジュアル面談しませんか？
社員の半数以上が新卒からの採用です♪
https://hrmos.co/pages/ibj/jobs/1851969773295775758
IBJについては、こちらをご覧ください↓
この記事が気に入ったらサポートをしてみませんか？